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

Безопасность с оговорками

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

Отсутствие ответственных

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

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

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

Удивительное рядом

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

В дело как раз вступает культура ИБ: специалисты фактически по личной инициативе реализуют (или требуют их реализации от подрядчиков) меры безопасности в соответствии со своим пониманием возможных рисков и технических особенностей эксплуатации системы. Это, разумеется, лучше, чем ничего. Но комплексным или глубоким такой подход не назовешь. Квалификация у всех разная, понимание проблем и угроз ИБ — тоже, равно как и наличие времени и возможностей для «факультативного» изучения смежных областей знаний (как правило, речь идет о специалистах по системам автоматизации или сетевым технологиям, для которых ИБ — далеко не основной профиль).

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

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

О проектах

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

Связь с бизнесом

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

Отсутствие методологии

На текущий момент основные руководящие (и по совместительству методические) документы, на которые опираются специалисты при обеспечении ИБ в АСУ ТП, — это Приказ ФСТЭК № 31 и документы по защите ключевых сегментов информационной инфраструктуры (КСИИ). Причем последние, на мой взгляд, существенно устарели. Есть еще частично переведенное МЭКом семейство стандартов IEC 62443. К сожалению, этих документов недостаточно для создания методической базы по обеспечению информационной безопасности в системах управления технологическими процессами.

Зарубежная методическая база не только описывает требования по реализации конкретных технических или организационных мер защиты, но и создает целую парадигму кибербезопасности промышленных объектов. В стандарте NIST SP800-82 помимо рекомендуемых средств, мер, способов и процессов обеспечения ИБ содержится информация об автоматизированных системах вообще, о принципах построения, о классификации, о различиях и сходстве, например, между распределенной системой управления (DCS) и системами диспетчерского управления и сбора данных (SCADA), и так далее. У нас подобных документов, к сожалению, нет.

В заключение

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

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

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

Автор статьи — CISA, CISM, руководитель отдела кибербезопасности АСУ ТП АО «ДиалогНаука».

СПЕЦПРОЕКТ КОМПАНИИ «ДИАЛОГНАУКА»

Другие спецпроекты

Версия для печати (без изображений)