Александр Оводов: «Нельзя откладывать защиту промышленной инфраструктуры до модернизации оборудования»

8 часов назад

© https://ovodov.su

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

О том, почему проектирование системы защиты необходимо начинать с требований эксплуатационного персонала, когда физическая изоляция технологических сетей создает дополнительные риски и как обеспечить безопасность устаревшего оборудования, журналу RUБЕЖ рассказал Александр Оводов, генеральный директор компании Ovodov CyberSecurity.

Основные ошибки при проектировании ИБ-систем объектов КИИ

RUБЕЖ: Какие ошибки чаще всего допускают промышленные предприятия при создании систем информационной безопасности объектов КИИ?

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

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

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

RUБЕЖ: С чего необходимо начинать проектирование системы защиты значимого объекта КИИ?

А. Оводов: Прежде всего — с результатов категорирования. Для значимых объектов КИИ система защиты строится с учетом требований приказа ФСТЭК России № 239 и связанных с ним нормативных документов.

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

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

RUБЕЖ: Чем требования к информационной безопасности на химических предприятиях отличаются от требований в машиностроении?

Александр Оводов: Главное различие связано с характером производственного процесса.

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

Предотвращение технологических аварий — задача специально предназначенных для этого систем противоаварийной защиты. Средства ИБ не должны нарушать их функционирование.

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

В машиностроении чаще встречается дискретное производство, где технологические операции разделены на отдельные этапы. Там могут существовать автономные станки с ЧПУ, изолированные производственные линии и оборудование, которое вообще не имеет сетевого подключения. Для таких объектов требуются другие подходы к защите.

RUБЕЖ: Какие требования производственного персонала чаще всего становятся неожиданностью для специалистов по информационной безопасности?

Александр Оводов: Например, привычный порядок работы операторов. Мы регулярно встречаем ситуации, когда SCADA-система изначально устанавливалась под учетной записью администратора, и все операторы продолжают работать с административными правами.

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

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

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

Защита технологических сетей:сегментация, изоляция и мониторинг киберугроз

RUБЕЖ: Насколько оправдан подход, при котором технологические сети полностью отделяются от корпоративной инфраструктуры?

Александр Оводов: На промышленном предприятии обычно существует несколько зон с разной степенью связности.

Первая — корпоративная сеть, в которой работают ERP, офисные приложения и почта. Вторая — MES и системы взаимодействия с корпоративной инфраструктурой. Третья — непосредственно технологическая сеть со SCADA-серверами, автоматизированными рабочими местами операторов, контроллерами и телеметрией. Четвертая — полностью изолированные производственные участки.

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

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

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

RUБЕЖ: Какое решение вы считаете более эффективным?

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

При проектировании важно искать баланс между сегментацией, изоляцией и необходимостью централизованного мониторинга.

Как защитить устаревшие АСУ ТП и SCADA-системы без остановки производства

RUБЕЖ: На многих промышленных предприятиях продолжают использоваться Siemens, Yokogawa, Honeywell и старые версии Windows. Что делать, если установить современные средства защиты невозможно?

Александр Оводов: Это одна из наиболее распространенных проблем. Мы  до сих пор сталкиваемся со случаями, когда на предприятиях продолжают использовать Windows XP, Windows 7 и даже Windows 3.1. На таком оборудовании работают специализированные приложения, SCADA-системы и программное обеспечение контроллеров.

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

RUБЕЖ: Какие компенсирующие меры позволяют обеспечить безопасность такого оборудования?

Александр Оводов: Мы используем несколько групп мер.

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

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

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

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

Но это не означает, что можно отказаться от защиты до модернизации. Система информационной безопасности должна функционировать уже сейчас.

RUБЕЖ: Как организовать резервное копирование, если установка специализированного программного обеспечения может нарушить работу АСУ ТП?

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

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

Главное — выбирать схему резервирования исходя из особенностей конкретного технологического процесса.

Сертификация средств защиты информации и требования приказа ФСТЭК №239

RUБЕЖ: Можно ли использовать встроенные функции межсетевых экранов, коммутаторов и другого оборудования вместо отдельных сертифицированных средств защиты?

Александр Оводов: Такой подход возможен, но здесь есть важный нюанс. Пункт 28 приказа ФСТЭК № 239 предусматривает применение средств защиты информации, прошедших оценку соответствия требованиям безопасности. Она может проводиться в форме обязательной сертификации, испытаний или приемки. При этом необходимо учитывать требования к уровню доверия. Для значимых объектов КИИ первой категории предусмотрен четвертый уровень доверия, второй категории — пятый, третьей — шестой.

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

А это может потребовать документации по архитектуре, функциональной спецификации, результатов испытаний, анализа уязвимостей и подтверждения сопровождения продукта. Если заказчик не является разработчиком оборудования, самостоятельно выполнить весь объем требований зачастую крайне сложно.

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

RUБЕЖ: А что делать, если срок действия сертификата уже установленного средства защиты закончился?

Александр Оводов: Здесь необходимо учитывать несколько обстоятельств.

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

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

RUБЕЖ: Какие проблемы возникают при закупке нового программного обеспечения для АСУ ТП?

Александр Оводов: Одна из серьезных проблем — выполнение требований к безопасной разработке. Пункт 29 приказа ФСТЭК № 239 предусматривает соответствующие требования к прикладному программному обеспечению. При проектировании необходимо учитывать результаты анализа безопасности ПО, включая статический анализ, а для определенных случаев — динамический анализ. Также важны документация по безопасной разработке, сопровождению продукта и устранению выявленных уязвимостей.

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

RUБЕЖ: Как избежать подобных ситуаций?

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

Необходимо заранее определить, какие испытания проводит разработчик, какую документацию он предоставляет и кто отвечает за устранение уязвимостей.

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

Кибербезопасность ИИ и цифровых двойников в промышленности

RUБЕЖ: На промышленных предприятиях активно внедряются цифровые двойники и системы искусственного интеллекта. Нужно ли рассматривать их как самостоятельные объекты КИИ?

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

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

RUБЕЖ: Какие киберугрозы наиболее опасны для ИИ в промышленности?

Александр Оводов: Главная опасность заключается в том, что атака может не приводить к очевидному отказу системы. Вместо этого злоумышленник способен незаметно исказить данные или результаты работы алгоритмов.

Можно выделить несколько характерных сценариев:

• Отравление данных, когда модель обучается на намеренно искаженной информации и начинает систематически ошибаться.
• Подмена входных данных. Даже небольшое изменение показаний датчиков может привести к неправильному прогнозу или рекомендации.
• Формирование ошибочных рекомендаций на основе уже искаженной картины технологического процесса.
• Компрометация самой модели или ее обновлений.

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

RUБЕЖ: Какой подход к проектированию систем информационной безопасности вы считаете наиболее эффективным для промышленных предприятий?

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

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

Читайте также на сайте журнала RUБЕЖ интервью Андрея Волкова, директором по безопасности ООО «ЕвроХим Северо-Запад-3»: «Мы должны перестать обсуждать безопасность как набор закупок и начать обсуждать её как свойство объекта»