11 марта 2008 г. в Государственной Думе РФ был снят с дальнейшего рассмотрения проект федерального закона "Об особенностях обеспечения информационной безопасности критически важных объектов информационной и телекоммуникационной инфраструктуры". В перечень таких объектов, перечисленных в этом, уже бывшем, законопроекте наряду с традиционными "почтами, телеграфами и телефонами", входили крупные промышленные предприятия, компании водо- и энергоснабжения, бизнес по добыче и транспортировке нефти и газа и т.п.

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

Что может привести к авариям?

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

Механизм работы простейшей АСУ ТП

Источник: Cisco, 2008

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

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

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

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

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

Кто использует уязвимость АСУ ТП?

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

Имеет большое значение адаптация стандартных технологий, которые обладают хорошо известными уязвимостями. Среди них надо назвать такие протоколы и стандарты, как IP, Etnernet, HTTP, XML, DCOM, .NET и т.д. Увеличивает область возможных атак и широкое распространение таких операционных систем, как Linux, Windows, а также коммуникационного оборудования: мультиплексоров, маршрутизаторов, коммутаторов и т.д.

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

Отсутствие данных об успешных атаках на системы АСУ ТП в РФ часто приводится в подтверждение идеи о том, что имеющие место риски завышаются и затраты на ИБ в АСУ ТП не обоснованы.

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

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

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

Уроки из событий в Америке 11 сентября 2001 г.

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

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

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

На взгляд автора, основная причина, которая не позволяет перейти к практическим шагам по защите АСУ ТП, заключается в непонимании проблематики департаментами автоматизации, ИТ и безопасности, а также рядом законодателей.

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

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

Безопасность АСУ ТП не по зубам ИБэшникам?

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

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

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

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

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

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

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