Где-то благодаря самостоятельной инициативе организации, где-то – вследствие активных действий государства в части регулирования вопросов защиты АСУ ТП и в целом критических инфраструктур РФ, в большинстве компаний на текущий момент запущен, по крайней мере, один из процессов:

• Анализ текущего среза состояния ИБ в АСУ ТП (аудит).
• Проектирование и построение соответствующих систем защиты АСУ ТП.
• Либо в дополнение к этому – построение или модернизация непосредственно самих АСУ ТП с учетом соответствующих требований безопасности.

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


Одним из таких шагов также может быть и охват производственных и технологических сетей пассивным мониторингом.

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

Далее, по мере возможности и готовности, заказчик осуществляет мониторинг на верхнем уровне АСУ ТП – для операторских, диспетчерских и инженерных АРМ, промышленных SCADA-серверов с установленным на них общесистемным и прикладным ПО, а также соответствующего сетевого телекоммуникационного оборудования (коммутаторы, маршрутизаторы, межсетевые экраны и др.).

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


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



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

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

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

Безусловно, одного лишь мониторинга и выявления недостаточно, и он ни в коем случае не заменяет и не решает всех задач обеспечения ИБ АСУ ТП, являясь необходимым, но не достаточным условием обеспечения ИБ в АСУ ТП.


Подход к безопасности АСУ ТП – упрощенная блок-схема возможного движения.

В случае расширения сервиса мониторинга на АСУ ТП мы попадаем в одну из вышеуказанных ведущихся активностей на стороне Заказчика, но никакая из них не является препятствием для выполнения задач оперативного мониторинга и выявления инцидентов ИБ.

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

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



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