Аутсорсинг SOC для АСУ ТП: выход или угроза?

Идея аутсорсинга SOC в промышленности все чаще обсуждается как способ повысить устойчивость и снизить затраты. Однако эксперты сходятся во мнении: применять эту модель в индустриальной сфере напрямую, по шаблону ИТ-инфраструктур, рискованно. Промышленные процессы требуют не просто мониторинга инцидентов, а глубокого понимания технологической специфики и особенностей функционирования АСУ ТП. 

Как вы оцениваете перспективу перехода к модели аутсорсингового SOC в промышленном сегменте? Какие риски и ограничения вы видите в такой модели, и какие функции вы бы доверили внешнему провайдеру, а какие – оставили внутри компании?

Евгений Генгринович, ИнфоТеКС

В формулировке вопроса содержится классическая ошибка переноса методов решения ИБ-проблем из ИТ-инфраструктуры на промышленную. В промышленном сегменте решается задача устойчивого функционирования технологических процессов, настройка и тестирование систем лежат в сфере ответственности специалистов, отвечающих за их эксплуатацию. Киберинциденты в промышленном сегменте могут возникать в силу ряда причин, и кибератаки – только одна из них, поэтому АСУ/АСУ ТП/IED должны создаваться сразу с учетом особенностей функционирования в информационном окружении, обеспечивая на функциональном уровне возможность корректного функционирования при информационных воздействиях (адаптивность), прекращения функционирования при некорректном выполнении основных бизнес-функций (ответственность). То, что в международной практике называется Security-by-Design.

Роль SOC при этом не меняется, он получает из внешних источников (логи устройств, сообщения об инцидентах SCADA-систем и т.п.) информацию о киберинцидентах и проводит анализ их возникновения. Специалисты SOC привлекаются к расследованию аварий, анализируют корректность работы сетей передачи данных. Будет ли SOC развернут локально, в ЦОД инсорсинговой сервисной компании или на стороне сервис-провайдера, для решения данной задачи не важно.

Вячеслав Половинко, АМТ-ГРУП

Аутсорсинг SOC в промышленности может дать эффект экономии на масштабе, доступ к экспертизе и готовым ML-решениям, ИИ-аналитике, позволит высвободить внутренних ИБ специалистов. С другой стороны, такой SOC будет иметь ограниченный контекст в отношении контролируемого объекта, медленнее реагировать и координировать свои действия с производственными подразделениями на местах, должен будет учитывать возможность физической изоляции сегмента АСУ ТП, например диодами данных. Отдельно стоит юридический аспект: ответственность за инциденты, ограничения на передачу в SOC данных определенных категорий.

Илья Карпов, BI.ZONE

Часто АСУ ТП поддерживаются сторонними компаниями. Наряду с этим набирает популярность и модель аутсорса SOC. Однако подключение коммерческого SOC без учета промышленной специфики и понимания специфики АСУ ТП несет риски. Например, задержки, пропуски или неполное реагирование на инциденты. Модель аутсорса перспективна и эффективна только в случае, если SOC привлекает специалистов разного профиля, например сотрудников с опытом администрирования СЗИ АСУ ТП или инженеров АСУ ТП. При этом реагирование на инциденты и тестирование следует осуществлять сотрудникам внутри компании при плотном взаимодействии со специалистами коммерческого SOC. Такой SOC, в свою очередь, может осуществлять мониторинг, инвентаризацию активов, анализ уязвимостей и обработку событий низкого уровня.

Андрей Кузнецов, АйТи Бастион

Современные решения позволяют обезопасить даже такие процессы. Если потоки шифруются, жестко разграничены (желательно с участием систем разных классов), а удаленный доступ контролируется, то риски почти нивелируются. При организации подобных процессов больше стоит задуматься над вопросом что опаснее: оставить сегмент без какого-либо присмотра, потому что нет ресурсов на это, но зато он останется изолированным; или предоставить доступ к некоторым данным, нарушая изоляцию? На каждом предприятии условия будут индивидуальные, и решения принимать нужно тоже индивидуально.

Евгений Гончаров, Kaspersky ICS CERT

Квалифицированных специалистов по информационной безопасности вообще не хватает – это общая проблема для организаций всех секторов, не только промышленности. Поэтому помощь внешних экспертов из специализированных команд – единственно возможный выход. И это уже даже не неизбежное будущее, а объективная реальность, которую многие почему-то не хотят признавать. Если вас атаковали прицельно, вы вынуждены прибегать к посторонней помощи, даже если вы не называете это SOC. Продвинутые злоумышленники редко приходят со старым инструментарием, почти наверняка они подготовили для вас что-то новенькое. Например, мы в Kaspersky ICS CERT непрерывно занимаемся тем, что обнаруживаем атаки с использованием нового инструментария и тактик, и точечно уведомляем о возможной компрометации организации, которые, по нашим данным, могли стать жертвой. И мы, и наши коллеги из других подразделений постоянно ищем новые угрозы, нацеленные на пользователей наших продуктов, и стараемся защитить их от таких угроз. Что мы не можем сделать для вас без вашего разрешения и без вашей помощи – это оптимизировать средства защиты конкретно под вашу инфраструктуру. Например, мы не знаем, насколько легитимна установка на конкретный компьютер драйвера ОС, средства удаленного администрирования или компонента третьеcтороннего защитного решения, уязвимого к DLL Highjacking.

Во многих отраслях, включая промышленные, распространена внутренняя разработка, при которой нужные средства автоматизации создаются непромышленным способом, "из подручных материалов" (например, на основе небезопасных утилит или сомнительного кода с GitHub) находчивыми, но не всегда профессиональными разработчиками. В результате множество частных средств автоматизации используют подходы и решения, пересекающиеся с техниками злоумышленников, – это сильно затрудняет разработку универсальных мер защиты от этих техник, которые подошли бы всем клиентами.

Зато все это можно специализировать для конкретной организации и реализовать в инструментарии для SOC-команды. Не думаю, что идея подключения внешних экспертов к выполнению каких-либо функций SOC несет дополнительные объективные риски для организации. Понятно, что возможны субъективные (частные) риски для ответственных лиц (например, не удастся скрыть от руководства какие-либо существенные детали, свидетельствующие о неправильных действиях или бездействии ответственного сотрудника, которые могут всплыть при исследовании инцидента).

Что касается разделения полномочий между локальной командой и внешним подрядчиком, то оно естественным образом проходит по границе экспертизы и близости к команде разработки защитных средств. Большинство рутинных задач по отражению известных угроз и планомерному совершенствованию мер защиты (включая и дополнительную конфигурацию имеющихся защитных средств, и управление уязвимостями) должно лежать на локальной команде. Внешние специалисты при этом привлекаются в качестве третьей линии поддержки – для выявления новых угроз, оркестрирования процесса реагирования на них и для доработки средств защиты. Они же, как правило, становятся источником дополнительной информации об угрозах и уязвимостях на основе которой можно принимать тактические и стратегические решения об улучшении мер защиты.