24 марта 2022
Статьи

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

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

О наиболее эффективных инструментах мониторинга ИБ АСУ ТП, основных сложностях, существующих ограничениях и роли Security Operations Center (SOC) рассказывает Руслан Амиров, директор USSC-SOC – центра мониторинга и реагирования на инциденты ИБ компании УЦСБ.

Нужно ли организациям с АСУ ТП осуществлять мониторинг ИБ? Что является результатом мониторинга, можно ли снизить риски?

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

Выделим ключевые моменты:

Во-первых, мониторинг позволяет обоснованно  реализовать соответствие требованиям законодательства. Для организаций действует Федеральный закон 187-ФЗ «О критической информационной инфраструктуре Российской Федерации», приказы ФСТЭК России №31, 235, 239 и прочие подзаконные акты, которые задают вектор обеспечения ИБ АСУ ТП и объектов критической информационной инфраструктуры (КИИ) в РФ. За невыполнение требований законодательства в сфере защиты информации, предусмотрена уголовная и административная ответственность, в том числе, присутствует и ряд принятых судебных решений.

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

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

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

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

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

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

Обновление ПО

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

Ограниченные сроки на техническое обслуживание АСУ ТП

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

Высокий риск ошибок при проведении ТО по ИБ

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

Сложно получить данные с активов АСУ ТП

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

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

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

Ограничения для проведения полноценного расследования инцидента

Затруднительно провести полноценное расследование потенциального, еще не подтвержденного инцидента – на этот процесс влияет ограниченный доступ к отдельным компонентам АСУ ТП и часто отсутствие возможностей передачи телеметрии для мониторинга и анализа.

Риски влияния средств мониторинга на компоненты АСУ ТП

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

Отсутствие вариантов передачи информации за пределы АСУ ТП

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

Проблематично выполнение рекомендаций по противодействию инциденту ИБ в АСУ ТП

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

Отсутствие понимания эталонного состояния ИБ АСУ ТП

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

Какие действия в АСУ ТП лучше выполнять самостоятельно или необходимо полностью полагаться на outsource-службы?

Выбор действий, которые следует выполнять самостоятельно, зависит от того, какой формат SecOps используется в вашей организации: inhouse (собственные подразделения и мощности) или outsource (внешняя экспертная организация). Также существуют гибридные варианты, при котором внутренние службы занимаются закрепленным объемом обязанностей (например, реагированием), а внешний аутсорс осуществляет выявление инцидентов. Рекомендую организациям самостоятельно принимать решения по следующим вопросам:

  • Повышать уровень защищенности, выбирать способы защиты и решать вопросы привлечения собственных специалистов, аутсорс/аутстафф или же выбрать гибридную основу.
  • Останавливать или не останавливать функционирование АСУ ТП в случае инцидента.
  • Координировать регламентные работы по ИБ, участвовать в расследовании и ликвидации последствий инцидентов.
  • В случае, если организация приняла решение о необходимости SOC в рамках своей ИБ-стратегии, то какой SOC для АСУ ТП вы советуете выбирать: собственный или аутсорсинговый?
  • Выбор между созданием собственного SOC или выбором аутсорсинга данной услуги определяется исходя из практической ситуации с кадровым обеспечением, а также возможностями создания соответствующих технической и организационной структур.
Чтобы определить нужный тип Security Operations Center для вашей промышленной инфраструктуры, предлагаю ответить на следующие вопросы:

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

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

Автор: Руслан Амиров, директор USSC-SOC
Источник: журнал CIS