Не так давно большая армия российских специалистов в сфере автоматизации и эксплуатационный персонал промышленных объектов стали сталкиваться с немного непонятными и устрашающими людьми, которые появляются на объектах и «суют нос» туда, куда собственно не всех своих без присмотра пускают. Оказалось, что эти люди пришли внедрять информационную безопасность АСУ ТП. В данной статье я постарался изложить свой взгляд на то, что отличает ИБ АСУ ТП от ИБ ИТ, какие факторы надо учитывать при проектировании ИБ АСУ ТП и разработке сценариев реагирования на инциденты или угрозы ИБ на промышленном объекте.
Вот уже более 15 лет я работаю в небольшой, но достаточно известной в узких кругах российской компании из Новосибирска «Модульные Системы Торнадо», которая занимается разработкой и внедрением программно-технических комплексов для АСУ ТП объектов энергетики. За эти годы я занимался совершенно разными направлениями: программированием специализированных программных систем верхнего уровня для МП РЗА, наладкой систем телемеханики и АСУ ТП, участием в разработке современного промышленного компьютера и продажей комплексных проектов на многие десятки миллионов рублей. Такое разнообразие производственных задач, возможно, предопределило то, что меня заинтересовало это новое направление — ИБ АСУ ТП.
Но обо всем по порядку. Сейчас может показаться, что текущий, можно сказать лавинообразный рост рынка оборудования, ПО и услуг для решения задачи ИБ АСУ ТП обусловлен появлением угроз влияния на технологические процессы извне, что приводит также к закономерному росту нормативной базы регулятора ФСТЭК и т.д. Это мнение во многом справедливо, однако, мне кажется, что фундаментом этих процессов является неконтролируемое распространение интерфейса Ethernet как стандарта де-факто для организации промышленных сетей АСУ ТП. Почему неконтролируемое? Разве можно так утверждать? На мой взгляд, для этого есть все основания. Тема ИБ АСУ ТП появилась не так давно, и до этого любой проектировщик АСУ или подсистемы легким движением руки соединял сети энергоблока, ОРУ станции, главного щита управления и еще многих мелких и не очень систем контроля и управления. Все это делалось по заданиям заказчика в целях обеспечения большей наблюдаемости объекта и повышения качества контроля и управления.
К каким результатам привели эти благие намерения? Специалисты по обслуживанию технологических систем контроля и управления во многом потеряли представление о процессах, происходящих в этих ЛВС, и об их возможном влиянии на сохранение работоспособности технологического процесса. Можно подумать, что это следствие низкой квалификации персонала. Но во многих случаях это не справедливо. Дело в том, что масштаб информации для анализа персоналом влияет на адекватность восприятия состояния объекта управления. Объем промышленных сетей и число активных устройств на сегодня таково, что даже ква��ифицированный специалист не может предвидеть возможные последствия внесения изменений в настройки контроллеров АСУ ТП, сетевого оборудования, установки новых устройств или даже вывода подсистем управления в режимы ремонта или режимной наладки. И я пока не касаюсь вопросов внешних хакеров с различными задачами и средствами проникновения и воздействия.
Таким образом появление специалистов по ИБ на проходных промышленных объектов в общем то органично совпало с этим возрастающим напором промышленных сетей, под которым уже начали сгибаться спины доблестного эксплуатационного персонала. Эти рыцари файрволлов, антивирусных защит и систем обнаружения вторжения должны были подхватить знамя безопасности промышленного объекта, и обеспечить его бесперебойную работу в современных условиях с подключениями к интернету, удаленными каналами связи, MES и ERP всасывающими гигабайтами данные с АСУ ТП.
Считаю, что во многом эта задача современными разработчиками систем ИБ для АСУ ТП решается, или будет решена в основном объеме в ближайшие годы. Конечно, есть трудности, не все АСУ стойко переносят интеграцию средств ИБ в свои чувствительные архитектуры. Но это рабочие моменты. Однако, я думаю, что существует и ряд концептуальных вопросов, которые должны быть проанализированы поставщикам и интеграторам средств ИБ АСУ ТП.
Для того, чтобы понять эффективность средств обеспечения ИБ АСУ ТП, полезно рассмотреть те средства, которые обеспечивают ее целевые задачи. Основными задачами АСУ ТП в порядке приоритета являются:
1. Поддержание технологического процесса
2. При невозможности 1го сохранение технологического оборудования и жизни персонала
В случае развития технологической аварии существуют два варианта развития ситуации. Развитие аварийной ситуации может быть остановлено автоматическим действием подсистемы защит в составе ПТК АСУ ТП, либо остановкой технологического процесса дежурным персоналом с помощью аварийной панели управления. В данном случае будет реализована штатная остановка технологического процесса. Если же по каким-то причинам данные меры не позволили штатно остановить технологический процесс, может произойти развитие аварийной ситуации с непредсказуемыми последствиями. Итак, все современные АСУ ТП включают в свой состав программно-технические и простые аппаратные средства, предназначенные для автоматической или ручной безопасной остановки технологического процесса.
Теперь рассмотрим целевые задачи ИБ АСУ ТП. Компании разработчики программных и аппаратных средств ИБ АСУ ТП исторически являются разработчиками таких же решений для рынка ИТ. Но задачи ИБ ИТ и ИБ АСУ ТП идеологически разные. В части ИБ ИТ задача заключается в сохранении работоспособности всей ИТ инфраструктуры организации, включая все связи (связь с интернет, vpn до филиалов и т.д.). Можно даже сказать, что работоспособность этих связей является одним из главных приоритетов, поскольку полезный продукт многих организаций при отключении, например, связи с сетью интернет стремится к нулю. В части же ИБ АСУ ТП сегодня основная задача формулируется как:
1. Обеспечение функционирования АСУ ТП включая все связи
Обращает на себя внимание то обстоятельство, что в случае развития инцидента ИБ его исход может быть любым, вплоть до технологической аварии, и практически никак не зависит от дежурного персонала объекта. В настоящее время SOC для объектов с АСУ ТП практически не встречаются, а их появление может сдерживаться оценкой их финансовой и особенно целевой эффективности для АСУ ТП. Это означает что существующая парадигма развития ИБ АСУ ТП отличается отсутствием средств активного влияния на развитие инцидента ИБ АСУ ТП после момента успешного проникновения в ЛВС АСУ ТП.
На самом деле, на промышленном объекте мы можем декомпозировать все промышленные сети на условно изолированные сегменты, которые сами по себе обеспечивают работу технологического процесса. Таким образом, в критических ситуациях, или ситуациях с повышенным уровнем опасности по ИБ промышленного объекта, связи таких подсетей не являются ценными с точки зрения технологического процесса. И здесь есть первый диссонанс – специалисты по ИБ привыкли видеть своей целью сохранение работоспособности всей инфраструктуры организации, в то время как в части ИБ АСУ ТП они должны начать понимать, что не все связи являются ценными. Следовательно, в определенных ситуациях их можно физически отключать для минимизации или остановки распространения деструктивных процессов в сети АСУ ТП.
Приведу один пример. Всем нам известна авария на Саяно-Шушенской ГЭС. Я не буду касаться собственно этого объекта, развитие аварии достаточно хорошо описано. Одним из факторов, приведших к ней, стал перевод Саяно-Шушенской ГЭС в режим регулирования частоты в энергосистеме. Причина этого перевода заключается в том, что в помещении связи Братской ГЭС, являющейся основным регулятором частоты в энергосистеме Сибири, произошел пожар. В результате чего основной диспетчерский центр ОДУ Сибири потерял в полном объеме связь со всеми автоматизированными системами Братской ГЭС, включая автоматическую систему регулирования частоты и мощности. Таким образом, один из ключевых объектов энергетики Сибири выпал из автоматического процесса регулирования. Связь автоматизированных систем наруши��ась. Как это повлияло на функционирование собственно Братской ГЭС? Да собственно почти никак. Конечно, станция больше не выполняла регулирование в автоматическом режиме, однако генераторы остались в работе, управление станцией велось по голосовым каналам связи из ОДУ Сибири, станционные системы автоматизации работали. Этот пример показывает, что даже потеря важных каналов контроля и управления может не приводить к остановке технологического процесса. Что же говорить про многочисленные, по сути, информационные связи АСУ ТП – передача данных в ERP и MES, общие щиты управления объектом, каналы удаленного доступа и т.д. Следовательно, в части обеспечения мер по ИБ АСУ ТП должен появиться новый принцип – не все связи ЛВС АСУ ТП являются ценными, такие связи должны выявляться при разработке проектов ИБ АСУ ТП, проектом необходимо предусматривать возможность физического отключения таких связей.
Второй диссонанс, который я чувствую, относится к реагированию на инциденты ИБ АСУ ТП. Мне, как человеку причастному к АСУ ТП, привычно, что при появлении какого-либо возмущения система управления своими алгоритмами компенсирует это возмущение. То есть имеет место активная реакция. А что же имеется в виду под термином «Реагирование на инцидент ИБ АСУ ТП»? В большинстве случаев на промышленном объекте данное действие подразумевает постанализ инцидента и принятие мер по корректировке защит и настроек в части ИБ и АСУ ТП для недопущения подобного случая в будущем. Один случай штатной остановки и последующего перезапуска крупного технологического узла может стоить десятки миллионов рублей, остановка технологического узла с повреждением технологического оборудования может стоить сотни миллионов рублей. И что, все атаки и проникновения происходят настолько быстро, что дежурный персонал (специалист по ИБ объекта по крайней мере сейчас дежурным персоналом не является) не может ничего предпринять? В большинстве случаев нет. Современные программные средства СОВ вместе с анализом ценности связей ЛВС АСУ ТП позволяют сформировать эффективные сценарии реагирования дежурного персонала объекта на инциденты в промышленных сетях АСУ ТП.
Отключение ненужных связей может остановить атаку, или предотвратить ее развитие на другие связанные ЛВС АСУ ТП. Конечно, в данном вопросе необходимо сформировать определенные сценарии анализа сообщений СОВ и оценки адекватности управляемости объекта в условиях инцидента, на основе которых необходимо формировать инструкции по действиям оперативного и дежурного персонала в условиях угрозы или реализации инцидента ИБ. Для реализации функции отключения ненужных связей может предусматриваться Аварийная Панель Управления ЛВС АСУ ТП, содержащая в своем составе размыкатели Ethernet.
И последний аспект в части внедрения современных систем СОВ для АСУ ТП. Мне кажется, что по крайней мере на сегодня основной опасностью для АСУ ТП является собственный персонал объекта или командированные специалисты. Причем, я считаю их опасными даже при условии что они не имеют установки на повреждение АСУ ТП или сами не знают что на их флэш накопителе есть программа для проникновения в АСУ ТП, активирующаяся автоматически. Сегодняшние реалии таковы, что перенастройка какого-нибудь терминала защит может на 10% увеличить загрузку сети в нормальном режиме функционирования техпроцесса. Это может привести к отказу ЛВС в момент перехода технологического процесса в предаварийный и аварийный режимы и возможному отказу технологических защит, повреждению оборудования. Данное обстоятельство должно подтолкнуть разработчиков СОВ к созданию средств отображения ключевых метрик технологических сетей АСУ ТП. Таких как: загрузка различных сегментов сетей (средняя на интервале, максимальная), время отклика, отображение потоков информации между разными подсетями для диагностики недостаточного сегм��нтирования ЛВС и др. Такая информация, как мне представляется, будет востребована эксплуатационным персоналом и позволит поддерживать необходимый уровень гигиены процесса обмена технологическими данными в промышленных сетях АСУ ТП.
Вот уже более 15 лет я работаю в небольшой, но достаточно известной в узких кругах российской компании из Новосибирска «Модульные Системы Торнадо», которая занимается разработкой и внедрением программно-технических комплексов для АСУ ТП объектов энергетики. За эти годы я занимался совершенно разными направлениями: программированием специализированных программных систем верхнего уровня для МП РЗА, наладкой систем телемеханики и АСУ ТП, участием в разработке современного промышленного компьютера и продажей комплексных проектов на многие десятки миллионов рублей. Такое разнообразие производственных задач, возможно, предопределило то, что меня заинтересовало это новое направление — ИБ АСУ ТП.
Но обо всем по порядку. Сейчас может показаться, что текущий, можно сказать лавинообразный рост рынка оборудования, ПО и услуг для решения задачи ИБ АСУ ТП обусловлен появлением угроз влияния на технологические процессы извне, что приводит также к закономерному росту нормативной базы регулятора ФСТЭК и т.д. Это мнение во многом справедливо, однако, мне кажется, что фундаментом этих процессов является неконтролируемое распространение интерфейса Ethernet как стандарта де-факто для организации промышленных сетей АСУ ТП. Почему неконтролируемое? Разве можно так утверждать? На мой взгляд, для этого есть все основания. Тема ИБ АСУ ТП появилась не так давно, и до этого любой проектировщик АСУ или подсистемы легким движением руки соединял сети энергоблока, ОРУ станции, главного щита управления и еще многих мелких и не очень систем контроля и управления. Все это делалось по заданиям заказчика в целях обеспечения большей наблюдаемости объекта и повышения качества контроля и управления.
К каким результатам привели эти благие намерения? Специалисты по обслуживанию технологических систем контроля и управления во многом потеряли представление о процессах, происходящих в этих ЛВС, и об их возможном влиянии на сохранение работоспособности технологического процесса. Можно подумать, что это следствие низкой квалификации персонала. Но во многих случаях это не справедливо. Дело в том, что масштаб информации для анализа персоналом влияет на адекватность восприятия состояния объекта управления. Объем промышленных сетей и число активных устройств на сегодня таково, что даже ква��ифицированный специалист не может предвидеть возможные последствия внесения изменений в настройки контроллеров АСУ ТП, сетевого оборудования, установки новых устройств или даже вывода подсистем управления в режимы ремонта или режимной наладки. И я пока не касаюсь вопросов внешних хакеров с различными задачами и средствами проникновения и воздействия.
Таким образом появление специалистов по ИБ на проходных промышленных объектов в общем то органично совпало с этим возрастающим напором промышленных сетей, под которым уже начали сгибаться спины доблестного эксплуатационного персонала. Эти рыцари файрволлов, антивирусных защит и систем обнаружения вторжения должны были подхватить знамя безопасности промышленного объекта, и обеспечить его бесперебойную работу в современных условиях с подключениями к интернету, удаленными каналами связи, MES и ERP всасывающими гигабайтами данные с АСУ ТП.
Считаю, что во многом эта задача современными разработчиками систем ИБ для АСУ ТП решается, или будет решена в основном объеме в ближайшие годы. Конечно, есть трудности, не все АСУ стойко переносят интеграцию средств ИБ в свои чувствительные архитектуры. Но это рабочие моменты. Однако, я думаю, что существует и ряд концептуальных вопросов, которые должны быть проанализированы поставщикам и интеграторам средств ИБ АСУ ТП.
Для того, чтобы понять эффективность средств обеспечения ИБ АСУ ТП, полезно рассмотреть те средства, которые обеспечивают ее целевые задачи. Основными задачами АСУ ТП в порядке приоритета являются:
1. Поддержание технологического процесса
2. При невозможности 1го сохранение технологического оборудования и жизни персонала
В случае развития технологической аварии существуют два варианта развития ситуации. Развитие аварийной ситуации может быть остановлено автоматическим действием подсистемы защит в составе ПТК АСУ ТП, либо остановкой технологического процесса дежурным персоналом с помощью аварийной панели управления. В данном случае будет реализована штатная остановка технологического процесса. Если же по каким-то причинам данные меры не позволили штатно остановить технологический процесс, может произойти развитие аварийной ситуации с непредсказуемыми последствиями. Итак, все современные АСУ ТП включают в свой состав программно-технические и простые аппаратные средства, предназначенные для автоматической или ручной безопасной остановки технологического процесса.
Теперь рассмотрим целевые задачи ИБ АСУ ТП. Компании разработчики программных и аппаратных средств ИБ АСУ ТП исторически являются разработчиками таких же решений для рынка ИТ. Но задачи ИБ ИТ и ИБ АСУ ТП идеологически разные. В части ИБ ИТ задача заключается в сохранении работоспособности всей ИТ инфраструктуры организации, включая все связи (связь с интернет, vpn до филиалов и т.д.). Можно даже сказать, что работоспособность этих связей является одним из главных приоритетов, поскольку полезный продукт многих организаций при отключении, например, связи с сетью интернет стремится к нулю. В части же ИБ АСУ ТП сегодня основная задача формулируется как:
1. Обеспечение функционирования АСУ ТП включая все связи
Обращает на себя внимание то обстоятельство, что в случае развития инцидента ИБ его исход может быть любым, вплоть до технологической аварии, и практически никак не зависит от дежурного персонала объекта. В настоящее время SOC для объектов с АСУ ТП практически не встречаются, а их появление может сдерживаться оценкой их финансовой и особенно целевой эффективности для АСУ ТП. Это означает что существующая парадигма развития ИБ АСУ ТП отличается отсутствием средств активного влияния на развитие инцидента ИБ АСУ ТП после момента успешного проникновения в ЛВС АСУ ТП.
На самом деле, на промышленном объекте мы можем декомпозировать все промышленные сети на условно изолированные сегменты, которые сами по себе обеспечивают работу технологического процесса. Таким образом, в критических ситуациях, или ситуациях с повышенным уровнем опасности по ИБ промышленного объекта, связи таких подсетей не являются ценными с точки зрения технологического процесса. И здесь есть первый диссонанс – специалисты по ИБ привыкли видеть своей целью сохранение работоспособности всей инфраструктуры организации, в то время как в части ИБ АСУ ТП они должны начать понимать, что не все связи являются ценными. Следовательно, в определенных ситуациях их можно физически отключать для минимизации или остановки распространения деструктивных процессов в сети АСУ ТП.
Приведу один пример. Всем нам известна авария на Саяно-Шушенской ГЭС. Я не буду касаться собственно этого объекта, развитие аварии достаточно хорошо описано. Одним из факторов, приведших к ней, стал перевод Саяно-Шушенской ГЭС в режим регулирования частоты в энергосистеме. Причина этого перевода заключается в том, что в помещении связи Братской ГЭС, являющейся основным регулятором частоты в энергосистеме Сибири, произошел пожар. В результате чего основной диспетчерский центр ОДУ Сибири потерял в полном объеме связь со всеми автоматизированными системами Братской ГЭС, включая автоматическую систему регулирования частоты и мощности. Таким образом, один из ключевых объектов энергетики Сибири выпал из автоматического процесса регулирования. Связь автоматизированных систем наруши��ась. Как это повлияло на функционирование собственно Братской ГЭС? Да собственно почти никак. Конечно, станция больше не выполняла регулирование в автоматическом режиме, однако генераторы остались в работе, управление станцией велось по голосовым каналам связи из ОДУ Сибири, станционные системы автоматизации работали. Этот пример показывает, что даже потеря важных каналов контроля и управления может не приводить к остановке технологического процесса. Что же говорить про многочисленные, по сути, информационные связи АСУ ТП – передача данных в ERP и MES, общие щиты управления объектом, каналы удаленного доступа и т.д. Следовательно, в части обеспечения мер по ИБ АСУ ТП должен появиться новый принцип – не все связи ЛВС АСУ ТП являются ценными, такие связи должны выявляться при разработке проектов ИБ АСУ ТП, проектом необходимо предусматривать возможность физического отключения таких связей.
Второй диссонанс, который я чувствую, относится к реагированию на инциденты ИБ АСУ ТП. Мне, как человеку причастному к АСУ ТП, привычно, что при появлении какого-либо возмущения система управления своими алгоритмами компенсирует это возмущение. То есть имеет место активная реакция. А что же имеется в виду под термином «Реагирование на инцидент ИБ АСУ ТП»? В большинстве случаев на промышленном объекте данное действие подразумевает постанализ инцидента и принятие мер по корректировке защит и настроек в части ИБ и АСУ ТП для недопущения подобного случая в будущем. Один случай штатной остановки и последующего перезапуска крупного технологического узла может стоить десятки миллионов рублей, остановка технологического узла с повреждением технологического оборудования может стоить сотни миллионов рублей. И что, все атаки и проникновения происходят настолько быстро, что дежурный персонал (специалист по ИБ объекта по крайней мере сейчас дежурным персоналом не является) не может ничего предпринять? В большинстве случаев нет. Современные программные средства СОВ вместе с анализом ценности связей ЛВС АСУ ТП позволяют сформировать эффективные сценарии реагирования дежурного персонала объекта на инциденты в промышленных сетях АСУ ТП.
Отключение ненужных связей может остановить атаку, или предотвратить ее развитие на другие связанные ЛВС АСУ ТП. Конечно, в данном вопросе необходимо сформировать определенные сценарии анализа сообщений СОВ и оценки адекватности управляемости объекта в условиях инцидента, на основе которых необходимо формировать инструкции по действиям оперативного и дежурного персонала в условиях угрозы или реализации инцидента ИБ. Для реализации функции отключения ненужных связей может предусматриваться Аварийная Панель Управления ЛВС АСУ ТП, содержащая в своем составе размыкатели Ethernet.
И последний аспект в части внедрения современных систем СОВ для АСУ ТП. Мне кажется, что по крайней мере на сегодня основной опасностью для АСУ ТП является собственный персонал объекта или командированные специалисты. Причем, я считаю их опасными даже при условии что они не имеют установки на повреждение АСУ ТП или сами не знают что на их флэш накопителе есть программа для проникновения в АСУ ТП, активирующаяся автоматически. Сегодняшние реалии таковы, что перенастройка какого-нибудь терминала защит может на 10% увеличить загрузку сети в нормальном режиме функционирования техпроцесса. Это может привести к отказу ЛВС в момент перехода технологического процесса в предаварийный и аварийный режимы и возможному отказу технологических защит, повреждению оборудования. Данное обстоятельство должно подтолкнуть разработчиков СОВ к созданию средств отображения ключевых метрик технологических сетей АСУ ТП. Таких как: загрузка различных сегментов сетей (средняя на интервале, максимальная), время отклика, отображение потоков информации между разными подсетями для диагностики недостаточного сегм��нтирования ЛВС и др. Такая информация, как мне представляется, будет востребована эксплуатационным персоналом и позволит поддерживать необходимый уровень гигиены процесса обмена технологическими данными в промышленных сетях АСУ ТП.
