Особенности обеспечения информационной безопасности промышленных систем автоматизации в соответствии с приказом ФСТЭК № 31

Трудно переоценить важность вопроса обеспечения информационной безопасности (далее – ИБ) в целом для страны и в частности для объектов повышенной опасности, коими являются промышленные системы автоматизации. 
Исключений нет: инциденты ИБ происходят в различных отраслях и сферах функционирования промышленных систем автоматизации (рис. 1) и порой приводят к катастрофическим последствиям [1, 2]. 

С целью урегулирования вопросов, связанных с обеспечением ИБ промышленных систем автоматизации, в нашей стране ведётся нормотворческая деятельность. Результатом данной деятельности стал вступивший в силу в 2014 году приказ ФСТЭК России № 31 [4] (далее – приказ № 31). Однако по сей день отсутствуют методические документы к приказу № 31, которые раскроют меры по защите информации, моделированию угроз, выявлению и устранению уязвимостей, реагированию на инциденты, связанные с нарушением защиты информации в АСУ ТП.
По причине их отсутствия образовался некий переходный период: сегодня при обеспечении безопасности АСУ ТП согласно требованиям приказа № 31 возникает необходимость в принятии решений по нерегламентированным вопросам. Каким образом? Например, опираясь на практики методических документов ФСТЭК, относящихся к ключевым системам информационной инфраструктуры (КСИИ) [5, 6, 7, 8] и к другим типам систем [9, 10].
Однако приказ № 31 в силу специфичности промышленных систем автоматизации обладает рядом особенностей относительно ранее выпущенных ФСТЭК документов [9, 10]. 
В рамках данной статьи мы рассмотрим некоторые из них, опираясь на практику применения положений приказа № 31 на объекте нефтеперерабатывающей отрасли.

Обеспечение безопасной разработки ПО 

Первая особенность приказа № 31 – «уникальные» требования обеспечения безопасной разработки программного обеспечения (ОБР), которых нет в аналогичных приказах ФСТЭК. Ввиду отсутствия методических документов обратимся за ответами на вопросы о мерах защиты ОБР напрямую к разработчикам приказа № 31. Разъяснения представителей ФСТЭК представлены в таблице 1. 
Получается, что требования подсистемы ОБР предъявляются к ПО, разрабатываемому в том числе представителями оператора АСУ ТП1, таким образом, необходима реализация определённого для конкретной АСУ ТП набора мер данной подсистемы. Плюс в том, что положениями приказа № 31 разрешено применять механизмы адаптации и уточнения требований, которые позволяют обосновать, например, использование ручного анализа кода вместо статистического или динамического, то есть возможность использования компенсирующих мер даёт возможность для каждого специфичного случая обеспечить требуемый уровень защищённости АСУ ТП.

Класс защищённости АСУ ТП

Следующая особенность заключается в распределении обязанностей участников процесса защиты АСУ ТП (заказчик/оператор/разработчик) при определении класса защищённости АСУ ТП, от которого, в том числе, зависит набор мер защиты информации в АСУ ТП, а также применяемые средства защиты информации. 
При проектировании новой системы заказчик или оператор согласно приказу № 31 должен определить степень ущерба от нарушения целостности/доступности/конфиденциальности информации. Полученная степень ущерба необходима разработчику системы информационной безопасности для определения класса защищённости АСУ ТП и зависит от характера чрезвычайной ситуации. 
Однако заказчик или оператор не могут предоставить требуемые данные, ведь объект по факту ещё не существует. Выход: определить характер чрезвычайной ситуации можно, либо исходя из паспортов аналогичных, уже введённых в эксплуатацию систем, либо методом экспертной оценки. Таким образом, АСУ ТП присваивается предварительный класс защищённости.
Критерии, на основании которых определяется предварительный класс защищённости АСУ ТП, представлены в таблицах 2 и 3. 

Сертификация СрЗИ

Третья особенность – применение средств защиты информации (СрЗИ). Согласно информационному сообщению ФСТЭК России (№ 240/22/2748 от 25 июля 2014 г.) в АСУ ТП применяются СрЗИ, прошедшие оценку соответствия в форме, установленной заказчиком в техническом задании (ТЗ) в соответствии с ФЗ «О техническом регулировании». Однако на практике в ТЗ заказчик указывает всё ту же пресловутую фразу про оценку соответствия СрЗИ без уточнения формы. Остаётся проектировать систему защиты АСУ ТП с применением СрЗИ, прошедших оценку соответствия в форме обязательной и/или добровольной сертификации (если, например, требования нормативных документов конкретной отрасли по защите информации в АСУ ТП позволяют применять СрЗИ, имеющие сертификат соответствующей системы добровольной сертификации). 
Причины следующие:

• отсутствие чёткого толкования условий и результата проведения оценки соответствия в других формах;
• устоявшаяся практика применения сертифицированных СрЗИ;
• отсутствие практики применения СрЗИ, прошедших оценку соответствия в других формах (следствие из предыдущего пункта). 

Ответственный за ИБ АСУ ТП

Четвёртая особенность, вызывающая горячие споры в профессиональном сообществе специалистов по ИБ промышленных систем автоматизации, – структурное подразделение или должностное лицо (работник), ответственное за защиту информации в АСУ ТП. Уйти от этого вопроса не удастся – ответственный должен быть назначен согласно приказу № 31, а вот кто им должен быть, остаётся за кадром. Давайте разбираться. 
При рассмотрении предприятия через призму ИБ–АСУ ТП–ИТ обособление данных направлений в отдельные подразделения, находящиеся на одном уровне организационной иерархии, на практике расценивается как самый эффективный вариант, обеспечивающий равенство интересов трёх направлений или их обоснованную приоритезацию с учётом стратегии развития. Ответственный за ИБ промышленных систем автоматизации должен относиться к подразделению ИБ и обладать компетенциями в сфере автоматизации. Стоит учитывать также зарубежный опыт в данном вопросе: самым подходящим решением является создание по примеру NIST SP 800-82 [12] межфункциональной команды кибербезопасности, обеспечивающей плотное взаимодействие этих направлений. 
Таким образом, на примере рассмотренных особенностей обеспечения ИБ промышленных систем автоматизации в соответствии с приказом ФСТЭК № 31 становится очевидным, что с одной стороны, есть сложность и неоднозначность применения в переходный период положений приказа ФСТЭК России № 31, предъявляющего специфичные требования к защите информации в АСУ ТП, а с другой стороны, предоставляется возможность адаптации, уточнения, дополнения защитных мер, позволяющая применять компенсирующие защитные меры и обеспечивать гибкий подход к построению системы защиты информации в АСУ ТП. ● 

Литература

1. Stuxnet [Электронный ресурс] // Википедия. – Режим доступа : https://ru.wikipedia.org/wiki/Stuxnet.
2. Хакеры случайно получили доступ к SCADA-системе водоочистной станции и ради интереса изменили её настройки [Электронный ресурс] // SecurityLab.ru. – Режим доступа : http://www.securitylab.ru/news/480334.php.
3. ICS-CERT Fiscal Year 2015: Mid-Year Statistics [Электронный ресурс] // ICS-CERT MONITOR. – Режим доступа : https://ics-cert.us-cert.gov/sites/default/files/Monitors/ICS-CERT_Monitor_May-Jun2015.pdf.
4. Об утверждении требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды : приказ ФСТЭК России от 14 марта 2014 г. № 31.
5. Базовая модель угроз безопасности информации в ключевых системах информационной инфраструктуры : утв. ФСТЭК России 18.05.2007.
6. Методика определения актуальных угроз безопасности информации в ключевых системах информационной инфраструктуры : утв. ФСТЭК России 18.05.2007.
7. Общие требования по обеспечению безопасности информации в ключевых системах информационной инфраструктуры : утв. ФСТЭК России 18.05.2007.
8. Рекомендации по обеспечению безопасности информации в ключевых системах информационной инфраструктуры : утв. ФСТЭК России 19.11.2007.
9. Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах : приказ ФСТЭК России от 11 фев. 2013 г. № 17.
10. Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных : приказ ФСТЭК России от 18 фев. 2013 г. № 21. 
11. О классификации чрезвычайных ситуаций природного и техногенного характера : постановление Правительства Российской Федерации от 21 мая 2007 г. № 304.
12. K. Stouffer, V. Pillitteri, M. Abrams, A. Hahn. Guide to ICS Security : NIST SP 800-82 Revision 2 [Электронный ресурс] // NIST. – Режим доступа: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf/

E-mail: chernushchenko@gmail.com