Префаб-решения для ИБ АСУ ТП: решение или иллюзия?

В этой статье Евгений Баклушин, независимый эксперт по ИБ АСУ ТП и КИИ, автор блога BESSEC, RUSCADASEC Coin №054, рассмотрит концепцию префаб-решений, которые могут выступить в роли такой серебряной пули. Но так ли это, давайте разбираться.

Почему «по накатанной» больше не работает

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

• Каждый проект требует повторной архитектурной проработки. Как бы мы не хотели, как бы не формировали унифицированные технические решения. Так или иначе, если у нас есть несколько одинаковых (или почти одинаковых) заводов, то требуется повторное проектирование. Может быть немного не так построена сеть, или одна из производственных линий может иметь другой состав (PLC, HMI, сервера и т.д.). Приходится проектировать, снова и снова.
• Сроки растут из-за интеграционных и проектных доработок. Мне почти ни разу, за редким исключением, не удалось увидеть объемных проектов по ИБ АСУ ТП, которые были бы выполнены с первого подхода. Всегда есть какие-то сложности с интеграцией. Тут не работает, там не работает и пошло-поехало. Все это еще должно быть отображено на бумаге, поэтому любая интеграционная сложность оказывает воздействие на бумагу. Как результат мы видим кучу версий технического проекта, начиная с версии 1.0 и заканчивая версией 1.Х.
• Результат зависит от локальной команды. Да, компетенции локальных команд Исполнителя и (или) Заказчика очень сильно влияют на результат. При чем я говорю не совсем про географическое распределение, скорее про команду, ответственную за проект. Она может состоять из одних экспертов или из вчерашних студентов, или может быть что-то смешанное. При этом не стоит обольщаться, если ваша команда состоит из одних экспертов, т.к. это далеко не гарант хорошего результата. У каждого эксперта будет мнение по каждому вопросу, что отдельно может повлиять на результат и срок его реализации. Как говорится, все фломастеры на вкус разные.
• Тиражирование на другие объекты затруднено. Это скорее не отдельная сложность, а результат вышеописанного. Постоянные повторные архитектурные проработки, сложности с интеграцией, зависимость от команд приводят к тому, что даже успешный проект по ИБ АСУ ТП на одном заводе очень сложно перенести на другие площадки и заводы, т.к. нужно учитывать все вышеописанные факторы.

Что на самом деле важно для отрасли? Два простых тезиса:

1. Для ИБ АСУ ТП важны не только средства защиты, но и управляемость их внедрения
2. Типовые, воспроизводимые и заранее проверенные подходы к обеспечению защиты

Префаб как ответ: продукт или метод?

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

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

Концептуально префаб строится на аппаратной платформе (может быть реализован и в виде набора виртуальных машин), куда входят NGFW/FW класса Д (тот самый, который умеет в промышленные протоколы, типа Modbus), антивирус для АСУ ТП, серверная отечественная ОС, система резервного копирования и платформенная основа — OT Data Layer Platform. Дополняют базовый стек продукты из категорий IRP, PAM+2FA, NTA/NDR и другие. Конкретные решения по направлениям (сеть, СРК и т.д.) выступают заменяемыми «кирпичиками» внутри уже готовой архитектуры, а не точкой отсчета проектирования.

OT Data Layer Platform — платформенное ядро

Сердцем префаб-решения выступает OT Data Layer Platform — единая платформа обеспечения ИБ АСУ ТП, построенная для анализа и управления данными, поступающими из разных сегментов АСУ ТП и подсистем ИБ. Т.е. это не просто SIEM, умеющая в промышленные протоколы и алерты для АСУ ТП. У платформы есть шесть базовых задач: анализ промышленного сетевого трафика, управление конфигурациями, управление уязвимостями, управление версиями проектов ПЛК с обнаружением аномалий в их работе, управление внешними событиями (OPC UA, SIEM, IRP, FW) и создание единой, так называемой Security CMDB (как класс решений отсутствует на российском рынке).

В части префаб-решения для ИБ АСУ ТП стоит остановить небольшое внимание на двух модулях:

1. «Контроль версий ПЛК», который дает инженерам и программистам АСУ ТП централизованное управление исходным кодом проектов ПЛК: хранение, контроль неизменности, аудит изменений, отображение различий, восстановление версий и непрерывную репликацию на компонент «менеджмента» платформы.
2. «Поведение ПЛК» решает другую задачу — безагентный поведенческий анализ ПЛК на основе машинного обучения, независимый от вендора контроллера и версии прошивки, без какого-либо влияния на сам ПЛК. Эталонная модель поведения формируется автоматически по копии сетевого трафика, а выявляемые аномалии — это то, что классические DPI и SCADA-системы просто не видят.

Мини-итог: внутри инфраструктуры префаб-решение работает как мини-SOC — своего рода дирижер, который собирает события со всех СЗИ, управляет уязвимостями и строит карту сети. Встроенный SIEM понимает OT-контекст, оркестрация позволяет запускать сбор дополнительной информации по расписанию, управление уязвимостями и конфигурациями гарантирует неизменность состава СЗИ, а Security CMDB связывает разнородные активы в единый слой данных и приоритизирует их согласно модели угроз (Привет Алексею Викторовичу!).

NG+ и AI-слой: следующий шаг платформы

Сейчас потенциально вижу 3 конкретных решения, которые способны выполнять функцию OT Data Layer Platform, это: PT ISIM, KICS for Networks, UDV DATAPK. Какое развитие может быть у этих решений и их настоящих и будущих конкурентов? Давайте назовем ее «OT Data Layer Platform NG+». Все тоже самое, что было описано выше, но с семантическим ядром на базе AI-моделей.

Принципиальный момент: все вычисления происходят локально, модели версионируются и обновляются через контролируемый канал — данные и модели не покидают периметр Заказчика или конкретного промышленного объекта. Практическая ценность — данные из разрозненных продуктов нормализуются в единую семантическую модель, на которой AI-слой обнаруживает угрозы, моделирует путь атаки и выдает оператору обоснованные рекомендации, а не просто поток разрозненных алертов.

Фабрика префаб-решений: от концепции к производству

Чтобы поймать вора, нужно думать, как вор! Шутки шутками, а на самом деле, вендоры из кибербеза уже давно сами стали промышленными предприятиями в каком-то смысле. Особенно вендоры по сетевой безопасности, ведь они поставляют и железки. В таком разрезе логично, что префабы становятся своего рода «продуктами». Здесь идейно включается идеальный системный интегратор. В чем его роль? В построении так называемой «фабрики префаб-решений». Это большая лабораторная инфраструктура, где префаб-решения проходят обкатку до выхода к заказчику. У такой лаборатории есть три задачи:

1. Проверка совместимости компонентов и интеграций (как все вендоры и их решения могут работать друг с другом, не мешая работе АСУ ТП).
2. Разработка типовых архитектур и полного комплекта проектной, рабочей и эксплуатационной документации. Как говорится, «под ключ», ведь Заказчику нужно не только техническое решение, но и документация к нему. Причем сделаю акцент, что, конечно, это закрытие комплаенс-рисков, но все-таки главная цель, чтобы при смене ИБ-команды, новые игроки могли прочесть и понять, как все устроено и как все работает).
3. Отработка типовых сценариев эксплуатации. Давайте назовем их «плейбуками». Это здорово иметь все классы решений необходимые для обеспечения ИБ АСУ ТП, но если они живут сами по себе, то в чем смысл? Смысл должен быть в том, чтобы они работали в связке. Банальный пример: EPP находит вирус на каком-то узле, далее срабатывает плейбук через OT Data Layer Platform, и межсетевой экран, например, отрубает данный узел от общей сети, локализует инцидент так сказать.

В результате ИБ-команда, да и организация в целом получает три ключевых эффекта такого подхода:

• Обеспечение кибербезопасности АСУ ТП за счет единого контура видимости и реагирования.
• Стандартизация решений в холдинговых структурах и сокращение сроков проектов.
• Для холдингов с десятками однотипных производственных площадок это снимает главную боль — необходимость каждый раз изобретать «велосипед» заново.

Идеальное будущее: калькулятор вместо чертежа

Давайте наденем розовые очки и представим, что в ближайшие три года все Заказчики, интеграторы и вендоры перейдут на данную концепцию. Что это даст?

Самое важное — переход от единичного проекта к тиражируемой модели через «калькулятор префаб-решений». Представьте, вы CISO или архитектор ИБ, вы заходите на сайт интегратора в раздел «префаб-решения». Выбираете в каждом классе нужный продукт (вендор, модель, производительность), а система вам выдает:

• Процент (%) совместимости выбранных решений.
• Наличие проектной и эксплуатационной документации на данный префаб.
• Наличие «плейбуков» между решениями, которые вы включили в свой префаб.
• Все нужные циферки и буковки для технико-экономического обоснования (Спасибо Льву Палею за формулировку получаемой ценности для Заказчика!) Автор видит в этом четыре эффекта: типовые проектные решения, снижение вариативности внедрений, упрощение сопровождения и повышение прозрачности для службы ИБ и технического заказчика, в том числе для технико-экономического обоснования (ТЭО).

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

Красиво звучит?

Конечно красиво! Тут сразу скажу спасибо Алексею Комарову, который очень тактично надел шляпу критика на одном из семинаров, где я представлял данную концепцию.

Сформулирую сначала проблему префаб-решений, которую мне озвучил Алексей (недословная цитата, но смысл передает): «Здорово, звучит, все протестировано, апробировано, пошло в бой. Женя, но ты совсем ничего не сказал про вендоров АСУ ТП, особенно с учетом импортозамещения». Абсолютно согласен! Конечно, я упоминал, что префаб для ИБ АСУ ТП не должен оказывать воздействия на сами АСУ ТП. Но как этого достичь? Мы хорошо знаем решения от Siemens, Schneider Electric, Yokogawa и т.д. Но знаем ли мы все? Нет. А отечественных вендоров мы знаем так хорошо? Нет. Готовы ли пойти российские вендоры в бесконечные тестирования? Сомневаюсь.

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

Финал

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