Роман Овчинников, Security Vision: Автоматизация реагирования в промышленности — не утопия

Редакция Anti-Malware.ru взяла интервью у Романа Овчинникова, директора департамента внедрения Security Vision. В ходе интервью Роман поделился особенностями управления инцидентами и реагированием в промышленных сетях, подчеркнув технические и организационные отличия от классической ИТ-инфраструктуры. Он рассказал о роли asset management, ограничениях автоматизированного реагирования и возможностях адаптации платформ SOAR и SGRC под промышленный сегмент.

Мы на конференции KICS Conf 2025 в Сочи, сегодня поговорим о кибербезопасности промышленных предприятий, и не только. Мой гость — Роман Овчинников, директор департамента внедрения Security Vision. Роман, привет!

Р.О.: Привет, Илья. Тут действительно нужно быть.

Поговорить хотелось бы о специфике управления инцидентами и реагирования в промышленных сетях. В чём, на твой взгляд, принципиальные отличия таких процессов от управления в классической офисной ИТ-инфраструктуре?

Р.О.: Я бы разделил эти отличия на технические и организационные.

Промышленная инфраструктура изолирована, с ограниченным доступом, и даже базовый мониторинг там организовать сложно, не говоря уже о реагировании на инциденты. Второй момент — сама специфика среды. Это нетиповые устройства, специализированные протоколы, что сильно ограничивает возможности команды безопасности для мониторинга и реагирования. Есть и особенность, связанная с непрерывностью производственных процессов.

Например, установка обновлений, перезапуск систем или восстановление состояния возможны только в строго определённые технологические окна. Иногда их приходится ждать месяцами, что сильно затягивает реакцию. В классической ИТ-среде можно планово обновляться хоть раз в неделю, а здесь — раз в полгода.

Организационные различия также существенны. Если говорить о специалистах и администраторах, работающих в сегменте систем управления технологическими процессами, у них иной профиль деятельности. Постановка задач через Service Desk (систему управления процессами в компании, через которую обрабатываются запросы сотрудников, внутренние заявки в бухгалтерии, послепродажное обслуживание и так далее — прим. ред.), к которому они формально имеют доступ, как правило, неэффективна. 

На практике взаимодействие строится через электронную почту, телефон или чаты, что усложняет процесс. Можно направить указание: «нужно сделать то-то и то-то», но остаётся неясным, увидели ли его, когда ответят и будет ли выполнено. В итоге коммуникация становится узким местом, а контроль показателей, таких как SLA (Service Level Agreement, соглашение об уровне сервиса с чёткими критериями качества, по которым оценивается работа — прим. ред.), время реакции (time-to-response) и другие, затрудняется.

Но ведь промышленные сети, как мне кажется, проще корпоративных: конфигурация оборудования фиксирована, коммуникация между узлами также предсказуема, и любое аномальное поведение сразу, как правило, заметно.

Р.О.: Только если этот процесс действительно мониторится.

Да, если мониторишь. И на мой взгляд, задача по работе с инцидентами и реагированием, о которой мы чуть позже ещё поговорим, с технической точки зрения выглядит более простой.

Р.О.: Наоборот, всё усложняется. Когда есть отлаженный процесс — это просто. А когда процесс со спецификой, ограничениями по доступу и правам, да ещё и требует посредников — это уже сложность. Оперативные меры для локализации, возможно, удастся выполнить быстро, но само устранение инцидента часто превращается в длинную процедуру согласований и уточнений.

С моей точки зрения, основа эффективного реагирования — это управление активами (asset management). Нужно понимать, какие устройства есть в сети, насколько они критичны. Но как это реализовать в промышленной среде, где всё взаимосвязано и работает как единый организм?

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

Так формируется ресурсно-сервисная модель, где понятно, какие компоненты влияют на работу всего процесса. Промышленная инфраструктура — относительно стабильна: достаточно один раз собрать эталонное состояние сети, пусть даже вручную или с помощью пассивного анализа трафика. После этого поддерживать актуальность модели несложно.

Давай перейдём к самому интересному — автоматическому реагированию. В офисной инфраструктуре к нему уже привыкли, но возможно ли это в промышленности, где любое вмешательство может привести к сбою или аварии?

Р.О.: Нет, делать это нужно в любом случае. Мы здесь для того, чтобы обеспечивать безопасность, и этот процесс нельзя игнорировать. Пока же, наверное, мы остаёмся на стадии обсуждений: вот уже много лет ведутся разговоры о том, насколько возможно автоматизировать реагирование. В ИТ-инфраструктуре автоматический отклик уже широко применяется, вопрос только в зрелости и отладке системы. В промышленных сетях такой практики пока нет.

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

Речь идёт о выявлении инцидентов, приоритизации, оповещении и составлении плана действий. Если выстроить последовательность действий для локализации и устранения инцидента, это уже значительно помогает. Даже если действия не выполняются автоматически, а предоставляются как инструкция или подсказка для администраторов и операторов, эффект будет заметным.

Все процессы, связанные с соблюдением SLA, отчётностью, проблем-менеджментом и устранением первопричин, также остаются важной частью общего процесса, и их можно эффективно реализовать.

То есть фактически речь идёт о том, что система информирует о проблеме и предлагает оператору инструкции для ручного реагирования?

Р.О.: Именно. Система помогает человеку действовать грамотно, но не реагирует сама. При этом она может обогащать данные по модели активов, чтобы рекомендации были точными.

Нужно ли адаптировать существующие решения, такие как системы управления безопасностью и соответствием (Security Governance, Risk, Compliance, SGRC) или платформы оркестрации и автоматизации реагирования (Security Orchestration, Automation and Response, SOAR), под промышленность?

Р.О.: Тематика решений класса SGRC полностью применима в промышленном сегменте. Почему? Потому что необходимо определять требования безопасности, проводить контроль и оценку соответствия в рамках нормативно-правового регулирования. Законодательство в области критической информационной инфраструктуры (КИИ) никто не отменял, и продукты класса SGRC в этом существенно помогают.

Регулярные аудиты для подтверждения должного уровня безопасности, оценка рисков и принятие решений на их основе также остаются обязательными. SGRC — в основном неинвазивное решение, выступает как стратегический инструмент контроля и поддержки принятия решений, и может применяться в промышленной среде так же, как и в классической ИТ-инфраструктуре.

Возможны некоторые отличия в моделях угроз или подходах к оценке рисков, но это мелочи: в целом как класс решений SGRC применим без изменений.

Что по поводу SOAR?

Р.О.: Что касается SOAR, с учётом обсуждаемых ограничений он может быть полезен как инструмент агрегации событий в одном источнике, а также для формирования единой модели активов, учёта используемого программного обеспечения, прав доступа и учётных записей. То есть как агрегатор и помощь в реагировании на инциденты он работает.

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

Вариант, когда SOAR развёрнут отдельно для технологического сегмента — скорее, исключение. Обычно так не делают: платформа ставится для всей компании, а промышленный сегмент становится просто частью того, что обслуживает SOAR наряду с классической ИТ-инфраструктурой, верно?

Р.О.: В этом направлении есть положительная динамика: многие переходят к формату единой инсталляции и единого центра операций безопасности (SOC) для обоих сегментов — корпоративного и промышленного. Однако это пока не универсально, поэтому встречаются случаи, когда в промышленном сегменте развёрнут отдельный компонент SOAR, и с ним работают отдельные специалисты.

Также бывают ситуации, когда из-за сетевых ограничений внутри инфраструктуры разворачивается элемент, выполняющий сбор и регистрацию инцидентов, и затем он особым образом передаёт данные в централизованный SOAR. Мы ещё не отошли полностью от таких схем, но в целом движение идёт в сторону единого центра мониторинга.

Хорошо, а как ты считаешь, что нужно для того, чтобы движение классической ИТ-инфраструктуры в сторону автоматизированного реагирования, которое уже происходит, начало распространяться и на промышленный сегмент? Или это утопия и никогда не станет реальностью?

Р.О.: Нет, это точно не утопия. Хотим мы этого или нет, бизнес, владельцы промышленных систем и специалисты по безопасности всё равно будут двигаться в этом направлении, чтобы обеспечить необходимый уровень безопасности и киберустойчивости. Процесс идёт с задержкой из-за специфики сегмента, но рано или поздно он догонит ИТ-инфраструктуру — вопрос лишь зрелости.

Вся автоматизация сначала проходит через формализацию процедур и их прогон вручную, то есть тестирование. Как только процедура отлажена, её легко автоматизировать: если мы сделали это вручную несколько десятков раз, теперь можно прогонять автоматически. Так формируется доверие, и начинают внедряться более сложные действия, начиная с простых, как это было в ИТ-инфраструктуре.

При этом всегда нужно учитывать непрерывность работы промышленных систем. Некоторые действия будут выполняться в отложенном режиме: задачи ставятся на выполнение в моменты, когда это возможно, и оператор должен их выполнить при наступлении соответствующего технологического промежутка.

Звучит очень обнадёживающе. При этом я считаю, что мы обязаны двигаться в этом направлении достаточно активно, так как Евгений Касперский прогнозировал в начале конференции учащение атак на энергетику, транспорт, медицинское оборудование и инфраструктуру ЖКХ. Это те области, где откладывать реагирование нельзя: если происходит инцидент, действовать нужно немедленно, иначе через несколько минут последствия могут быть критическими: например, авария или потеря контроля над системой.

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

Спасибо большое. Мне кажется, сам факт, что мы всерьёз говорим о реагировании в промышленном сегменте, — уже прогресс. Ещё несколько лет назад такую тему даже не поднимали.

Р.О.: Да, тогда даже повода для разговора не было. А сейчас мы обсуждаем реальные сценарии. Так что движение есть — и это главное.

Роман, спасибо за интересную беседу! Всего самого доброго и безопасного!