На практике, в процессе категорирования и определения перечня объектов критической информационной инфраструктуры или выполняя анализ уже проведенного категорирования объектов АСУ ТП, мы часто сталкиваемся со следующей позицией заказчика: если в случае кибератаки произойдет выход из строя системы управления, на помощь придут решения противоаварийной защиты, которые переведут систему и технологический процесс в безопасное состояние. Если злоумышленнику удастся воздействовать и на систему противоаварийной защиты, есть механические защиты – противоаварийные клапаны, разрывные мембраны и т.д. Они не имеют под собой цифровой основы, на них злоумышленник воздействовать не может. Соответственно, заказчики делают вывод, что в результате кибератаки не может случиться крупная авария.
Цепочка описанных рассуждений обычно приводит к тому, что либо занижается категория значимости объекта, либо данный объект вообще признается и классифицируется как незначимый.
Почему так происходит? Прежде всего, службы информационной безопасности не до конца понимают все нюансы, касающиеся функциональной безопасности. И данная ситуация в какой-то мере устраивает даже производственные службы: они свою позицию высказали, аргументами подкрепили и на какое-то время сняли головную боль в виде реализации мероприятий по 187-ФЗ.
В первую очередь в том, что организации редко проводят анализ опасностей и оценку рисков на производстве. Наиболее распространенный метод такого анализа – HAZOP (Hazard and Operability), то есть анализ опасности и работоспособности, который систематически проводится в иностранных и отечественных компаниях. Особенно это касается крупных проектов, где есть достаточно большие капитальные затраты, либо стратегических проектов, где уже не обращают внимание на общий уровень CAPEX. Важно понимать, что анализ рисков и уязвимостей надо проводить не только на этапе проектирования, что мы часто наблюдаем, но и на всех стадиях жизненного цикла производственного процесса (при выборе концепции проектирования, на этапе проверки готового проекта и перед этапом строительства). Многие должны проводить данную проверку для оценки надежности уже эксплуатируемого объекта, а также если вносятся изменения в технологический процесс. Отсутствие такого анализа приводит к тому, что службы информационной безопасности не всегда могут корректно оценить вероятность наступления того или иного события.
При проведении анализа случаются некоторые перегибы как в сторону завышения опасности, что накладывает отпечаток на стоимость разработки и внедрения решений, так и в сторону занижения, что неизбежно ведет к возникновению аварий на объектах.
Если вернуться к HAZOP, то часто мы наблюдаем ситуацию, что определенные меры действительно выполняются: в проекте появляется раздел либо книга "Промышленная безопасность", есть некие таблицы, похожие на "хазоповские". Хоть все и делается в режиме выпученных глаз и в последний день, чтобы Главгосэкспертиза пропустила проект дальше. В результате что мы видим на объектах? Различные проекты по разным видам безопасности: есть промышленная безопасность (она же функциональная безопасность), пожарная, информационная... но нет единого подхода к вопросу построения комплексной безопасности.
Область управления технологическими процессами в промышленности – это, наверное, одна из самых первых отраслей, в которой стали реализовывать функциональную безопасность. И до недавнего времени, когда говорили о безопасности промышленности, в первую очередь подразумевали функциональную безопасность.
На рис. 1 функциональная безопасность относится к Process Safety, и базовым стандартом в данном случае является МЭК 61511. Но основное оборудование, такое как программируемые логические контроллеры, приборы промышленной автоматики и исполнительные механизмы, действует в соответствии со стандартом МЭК 61508.
Сегодня под функциональной безопасностью мы подразумеваем корректное функционирование как системы управления, так и управляемого ею оборудования. в данном контексте указанные стандарты затрагивают:
С развитием цифровых технологий, продвижением концепции Индустрии 4.0, конвергенцией OT- и ИT-технологий и подключением АСУ ТП к корпоративной сети появляются новые риски. Один из них – возможность повлиять на работу физического устройства с точки зрения информации. И здесь необходимо выполнять условия соблюдения стандартов, которые касаются функциональной и информационной безопасности.
Свойство информационной безопасности – обеспечить конфиденциальность и доступность самого информационного процесса, а функциональной безопасности – обеспечить безопасность самого процесса в целом, в том числе при необходимости перевести его в безопасное состояние.
Как рассматривать взаимодействие этих двух типов безопасности? Для этого используем модель слоев защит, или модель "швейцарского сыра", и на этом примере разберем, как происходит авария на производстве и какова возможная роль атак в этом процессе.
Стандарт швейцарского сыра – наличие в нем дырок. Слои защиты, как и ломтики сыра, имеют "дырки". Каждая "дырка" в слое – это отдельная ошибка. Таких "дырок" в системах может быть много на любом уровне, они находятся в разных местах и обладают потенциальной разрушительностью различной степени. Однако нужно понимать, что следующий уровень/слой, в котором нет проблем на том же месте, может защитить всю систему от масштабной катастрофы. Количество слоев может разниться, но в данном примере мы имеем:
Проблемы начинаются тогда, когда на разных уровнях системы в одной и той же области имеется ошибка, то есть когда "дырка" уходит вглубь через все слои и все они имеют уязвимости. И тогда в случае кибератаки потенциальный злоумышленник может воздействовать на систему управления, спровоцировав аварийную ситуацию, и, влияя на систему противоаварийной защиты, выводя ее из строя, лишить технологический процесс системы защиты.
Говоря о функциональной безопасности, обратимся еще к одному инструменту – диаграмме LOPA (Layers of Protection Analysis), которая представляет собой "дерево отказов". Рассмотрим ее на примере такого события, как отказ контура регулирования давления (рис. 3).
У каждого события есть вероятность его наступления, которая может быть определена статистическим или расчетным методом, а у слоев защиты – вероятность успешной отработки этих событий. Ориентируясь на международные рекомендации, будем считать, что вероятность отказа контура регулирования давления – около 20–25% в год, успешные действия оператора на сигнализацию – 10%. Далее рассмотрим слои защиты на рис. 3. Все, что прописано под красным цветом, – это нормальная ситуация без киберинцидента. Соответственно, при возникновении киберинцидента первостепенная задача злоумышленников – вызвать отказ контура регулирования давления. Затем подменить данные, которые приходят на АРМ оператора в виде тех же самых режимных параметров, состояния пускорегулирующей аппаратуры, возможно, блокировать аварийную сигнализацию. То есть сделать все, чтобы оператор не смог среагировать на аварию.
Следующая задача – вывести из строя системы противоаварийной защиты, в зависимости от SIL (уровень полноты безопасности в процентах – SIL 2 или SIL 3). Если принять, что злоумышленнику удалось выполнить данную функцию, то дальше он остается один на один с механической защитой – предохранительными клапанами.
Нужно признать тот факт, что предохранительные клапаны и механические защиты неидеальны. У них нет 100%-ной успешности с точки зрения защиты. Причина аварии – это, как правило, фатальная комбинация ошибок проекта, отказов оборудования, нарушения процедур. Все упирается в характеристики используемого оборудования и систем, и у большинства предохранительных клапанов и других видов механических защит есть довольно высокая вероятность несрабатывания – так называемый коэффициент PFD. Он выражает вероятность того, что функция не сработает по запросу, когда это необходимо.
Подытожим факторы, которые могут привести к тому, что киберинцидент станет причиной аварии на производстве:
Таким образом, чтобы корректно оценить риски возникновения аварий на производстве и влияние киберинцидентов на технологические процессы, необходимо:
Следует рассматривать систему в комплекте и учитывать показатели надежности слоев защит. И наконец, помнить, что мы защищаем не сами промышленные системы управления, а технологический процесс, людей и основную деятельность компании – ее бизнес.