В сегодняшнем интервью мы рассмотрим один немаловажный вопрос для промышленных объектов: нужно ли организовывать мониторинг информационной безопасности (ИБ) в автоматизированных системах управления технологическими процессами (АСУ ТП)?
Следует обозначить, что для предприятий промышленного сектора наблюдается растущий с каждым годом интерес злоумышленников к промышленным объектам и, как следствие, рост числа кибератак. Также возрастают требования законодательства РФ, которые активно конкретизируются регуляторами. В то же время, со стороны самих предприятий, возрастает понимание необходимости общеуровневых изменений ИБ-инфраструктуры, повышение эффективности ИБ- и ИТ-подразделений, и, конечно же, целевое снижение рисков реализации угроз ИБ.
О наиболее эффективных инструментах мониторинга ИБ АСУ ТП, основных сложностях, существующих ограничениях и роли Security Operations Center (SOC) рассказывает Руслан Амиров, директор USSC-SOC – центра мониторинга и реагирования на инциденты ИБ компании УЦСБ.
Данный вопрос является первичным для любого бизнеса и развернутый ответ требует учета многих аспектов и должен рассматриваться в широком ключе возможностей.
Выделим ключевые моменты:
Во-первых, мониторинг позволяет обоснованно реализовать соответствие требованиям законодательства. Для организаций действует Федеральный закон 187-ФЗ «О критической информационной инфраструктуре Российской Федерации», приказы ФСТЭК России №31, 235, 239 и прочие подзаконные акты, которые задают вектор обеспечения ИБ АСУ ТП и объектов критической информационной инфраструктуры (КИИ) в РФ. За невыполнение требований законодательства в сфере защиты информации, предусмотрена уголовная и административная ответственность, в том числе, присутствует и ряд принятых судебных решений.
Во-вторых, мониторинг предоставляет объективную оценку состояния защищенности АСУ ТП в режиме, близком к реальному времени – режиме, который, конечно же, зависит от условий SLA. Причем полученная оценка управляема и ее изменение достижимо посредством экспертного подхода к реагированию на выявленные негативные сдвиги.
В-третьих, требуется выявлять инциденты не после того, как они были зафиксированы, а четко знать заранее, где именно и какой инцидент может возникнуть и по какой причине. В ходе анализа изменений АСУ ТП в ряде случаев можно превентивно определить, приведут ли последующие действия к инцидентам. Это сложная аналитическая работа, требующая понимания как особенностей функционирования АСУ ТП, так и имеющихся связей между различными АСУ ТП, их подсистемами, и внешними по отношению к АСУ ТП, системами и сетями.
В-четвертых, система мониторинга ИБ должна осуществлять сбор и обработку значительных объемов информации с высокой скоростью: ведь в конечном итоге цель заключается в том, чтобы максимально оперативно обеспечить реагирование на возможный инцидент ИБ (или угрозу инцидента) и не допустить или, в исключительных случаях, существенно снизить потенциальный ущерб в случае наступления инцидента. Причем система мониторинга ИБ не исключает собственный мониторинг АСУ ТП, органично дополняя технологический мониторинг: ведь реагирование в АСУ ТП производится обслуживающим персоналом, который глубоко разбирается в строении защищаемой системы и ее процессах, может оценить влияние того или иного действия и принять правильное решение в критической ситуации.
В-пятых, конечно же, необходимо учитывать такую цель мониторинга, как выявление инцидентов , которые уже произошли. Причем своевременная доставка сведений об инциденте ИБ ответственным подразделениям предприятия с понятным изложением выявленной ситуации играет ключевую роль в нейтрализации инцидентов и их возможных последствий. Взаимодействие между теми, кто осуществляет мониторинг, и выстраивание такого взаимодействия – обязательное условие для качественного мониторинга, без учета того, задействован собственный или внешний SOC в процессе мониторинга.
В-шестых, после выявления инцидента в рамках мониторинга проводится расследование и, при необходимости, восстановление хронологии событий, предшествующих возникновению инцидента. Эта информация критически важна для улучшения этапа реагирования и обязательно требуется при ликвидации возможных последствий инцидента, в связи с чем важно обеспечить своевременную локализацию инцидента.
Как правило, организации уровня Enterprise сегодня уже используют некоторые базовые средства и подходы к управлению и реализации ИБ. В случае с АСУ ТП, какие сложности могут возникнуть со стандартными SecOps?
Что же, еще один традиционный вопрос по стратегической и операционной составляющим безопасности АСУ ТП. Сосредоточимся на тех самых составляющих, которые на регулярной основе существуют в АСУ ТП.
Без должной подготовки нельзя обновить базовое, прикладное программное обеспечение (ПО) АСУ ТП или ПО наложенных средств защиты информации. Преимущественно экспоненциально растут риски невозможности функционирования АСУ ТП после проведения стандартных операций по обновлению операционных систем (ОС) или средств антивирусной защиты. Особенно проблематичным обновление становится в отношении устаревших ОС.
Ограниченные сроки на техническое обслуживание АСУ ТП
Техническое обслуживание (ТО) традиционно производится в период останова АСУ ТП, вынужденного или планового. Например, выделяются 1 сутки (или даже меньше) на выполнение ТО, причем не все время необходимые компоненты АСУ ТП доступны для проведения работ.
Высокий риск ошибок при проведении ТО по ИБ
Данный пункт возникает как следствие из предыдущего и зависит, в том числе, от предыдущих двух пунктов: во время ТО могут быть некорректно уточнены параметры мониторинга ИБ и до следующего ТО АСУ ТП останется невидимой для SOC или подразделения, отвечающего за мониторинг и реагирование на инциденты ИБ.
Сложно получить данные с активов АСУ ТП
Сложности связаны с отсутствием штатных решений и механизмов для получения данных в АСУ ТП, с отсутствием возможности внесения изменений в АСУ ТП для передачи необходимых данных. Появляется потребность в применении специализированных средств мониторинга ИБ АСУ ТП. Также сложности вносят нестандартные протоколы передачи информации программных решений для функционирования АСУ ТП.
Проблематичная изоляция устройств из состава АСУ ТП, в отношении которых зарегистрирован инцидент ИБ
Часто отсутствует возможность изоляции компонента АСУ ТП в штатном режиме работы АСУ ТП: в случае регистрации инцидента в АСУ ТП не всегда присутствует возможность изолировать устройство из состава АСУ ТП без прекращения работы всей АСУ ТП, что ведет к незапланированному останову системы.
Ограничения для проведения полноценного расследования инцидента
Затруднительно провести полноценное расследование потенциального, еще не подтвержденного инцидента – на этот процесс влияет ограниченный доступ к отдельным компонентам АСУ ТП и часто отсутствие возможностей передачи телеметрии для мониторинга и анализа.
Риски влияния средств мониторинга на компоненты АСУ ТП
Если для реализации мониторинга планируется взаимодействие, в рамках которого инструмент для мониторинга требует установки специального ПО (агента) на устройства АСУ ТП, то присутствует риск негативного влияния на функционирование АСУ ТП. Аналогичное влияние может оказывать наложенное средство защиты информации без прохождения должной процедуры тестирования совместимости с АСУ ТП.
Отсутствие вариантов передачи информации за пределы АСУ ТП
Причиной являются узкие низкоскоростные каналы связи, ограничение или отсутствие возможности подключения внешних носителей информации в пределах контура АСУ ТП, в результате довольно сложно получить информацию из АСУ ТП.
Проблематично выполнение рекомендаций по противодействию инциденту ИБ в АСУ ТП
Реагирование или дальнейшие действия по расследованию инцидента ИБ могут быть отложены до следующего технологического останова, который для некоторых систем наступает только раз год.
Отсутствие понимания эталонного состояния ИБ АСУ ТП
Сложно определить безопасное состояние системы в отсутствие разработчиков АСУ ТП или компетентных в вопросах функционирования АСУ ТП ответственных лиц.
Выбор действий, которые следует выполнять самостоятельно, зависит от того, какой формат SecOps используется в вашей организации: inhouse (собственные подразделения и мощности) или outsource (внешняя экспертная организация). Также существуют гибридные варианты, при котором внутренние службы занимаются закрепленным объемом обязанностей (например, реагированием), а внешний аутсорс осуществляет выявление инцидентов. Рекомендую организациям самостоятельно принимать решения по следующим вопросам:
Если на все вопросы получены уверенные положительные ответы, то inhouse-SOC будет эффективным инструментом для реализации вопросов мониторинга и реагирования на инциденты АСУ ТП. Однако, если хотя бы один из ответов был неопределенным или отрицательным, рекомендую обратить внимание на аутсорсинговые SOC, которые могут обеспечить требуемый или минимальный необходимый функционал мониторинга и реагирования. Кроме того, стоимость подключения к аутсорсинговому SOC будет существенно ниже, чем стоимость строительства и поддержки собственного SOC: при этом не стоит забывать о стоимости устранения последствий реализации угроз ИБ для имеющихся АСУ ТП.
Автор: Руслан Амиров, директор USSC-SOC
Источник: журнал CIS, №1 (19) / 2022
Наши специалисты рассмотрят заявку и свяжутся с вами в ближайшее время
Наши специалисты рассмотрят заявку и свяжутся с вами в ближайшее время
Наши специалисты рассмотрят заявку и свяжутся с вами в ближайшее время
Наши специалисты рассмотрят заявку и свяжутся с вами в ближайшее время
