Например, что в этом направлении ведется нормотворческая работа, примером тому служит проект ГОСТ Р «Обеспечение безопасной разработки ПО» (далее – проект ГОСТ). Посвящен он созданию системы управления безопасной разработкой ПО (далее – СУБР ПО) организацией-разработчиком ПО и учитывает, например, такие практики как Microsoft SDL, Cisco CDL, OWASP CLASP и положения ГОСТ Р ИСО/МЭК 15408-3, ГОСТ Р ИСО/МЭК 27001. Одной из причин создания данного ГОСТ является тот факт, что «виновниками»инцидентов ИБ чаще всего становятся дефекты безопасности и уязвимости программ. Актуальность защиты самого ПО (в том числе применяемого в промышленных системах автоматизации) от угроз, связанных с наличием в нем уязвимостей, не вызывает сомнения (Рисунок 1).
Рисунок 1 – Распределение уязвимостей кода программных средств АСУ ТП и ПО программно-аппаратных средств АСУ ТП согласно сведениям банка данных угроз безопасности информации ФСТЭК
Проект ГОСТ устанавливает требования к процессу разработки программного обеспечения и определяет следующие группы мер, направленные на обеспечение безопасной разработки ПО:
- управление конфигурациями;
- безопасная поставка ПО;
- защита инфраструктуры разработки ПО;
- защищенное программирование.
Сравним положения проекта ГОСТ с мерами защиты информации подсистемы ОБР Приказа №31 (Таблица 1).
Таблица 1 – Соответствие положений проекта ГОСТ и требований подсистемы ОБР Приказа №31.
|
Меры защиты информации подсистемы ОБР Приказа №31 |
Положения проекта ГОСТ (требования к организации-разработчику ПО) |
|
ОБР.0:Разработка правил и процедур (политик) обеспечения безопасной разработки программного обеспечения |
Определить и задокументировать политику обеспечения безопасности разработки ПО |
|
ОБР.1:Анализ уязвимостей и угроз безопасности информации в ходе разработки программного обеспечения |
Выполнять моделирование угроз с целью выявления потенциальных дефектов безопасности и уязвимостей разрабатываемой программы |
|
ОБР.2:Статический анализ кода программного обеспечения в ходе разработки программного обеспечения |
Проводить статический анализ программы с целью выявления дефектов безопасности и уязвимостей программы |
|
ОБР.3:Ручной анализ кода программного обеспечения в ходе разработки программного обеспечения |
Проводить периодическую инспекцию исходных модулей с целью выявления дефектов безопасности и уязвимостей программы |
|
ОБР.4:Тестирование на проникновение в ходе разработки программного обеспечения |
Проводить тестирование программы на проникновение с целью выявления дефектов безопасности и уязвимостей программы |
|
ОБР.5:Динамический анализ кода программного обеспечения в ходе разработки программного обеспечения |
Проводить динамический анализ программы с целью выявления дефектов безопасности и уязвимостей программы |
|
ОБР.6:Документирование процедур обеспечения безопасной разработки программного обеспечения разработчиком и представление их заказчику (оператору) |
Документация системы управления безопасной разработкой ПО должна включать в себя: -политику обеспечения безопасности разработки ПО; -описание области функционирования (логические и физические границы) системы управления безопасной разработкой ПО; -подход к оценке рисков, связанных с обеспечением безопасной разработки ПО; -документированные свидетельства реализации мер по обеспечению безопасности разработки ПО |
Отдельный пункт в проекте ГОСТ посвящен описанию необходимого комплекта документации и требований к управлению документацией СУБР ПО.
Что касается моделирования угроз и выявления уязвимостей в проекте ГОСТ выделена необходимость:
- собственно, моделирования угроз c целью выявления потенциальных дефектов безопасности и уязвимостей;
- рассмотрения при идентификации рисков перечня актуальных угроз (приведен в проекте ГОСТ с указанием источника угроз, возможных последствий реализации угрозы, мер, направленных на парирование угроз);
- анализа изменений перечня угроз безопасности, имеющих отношение к СУБР ПО, и установки требований к предупреждающим действиям;
- проектирования архитектуры программы с учетом устранения потенциальных дефектов безопасности и уязвимостей разрабатываемой программы;
- проведения динамического, статического анализа программы, инспекции исходных модулей программы, тестирования на проникновениес целью выявления дефектов безопасности и уязвимостей программы;
- реализации процедуры, позволяющей выполнять отслеживание и исправление всех обнаруженных дефектов безопасности и уязвимостей программы.
Все бы ничего, но, в силу особенностей процесса разработки прикладного ПО АСУ ТП и его специфичности, возникают вопросы к реализации некоторых требований, которые в условиях отсутствия соответствующих методических документов к Приказу №31, воспринимаются через призму субъективного мнения.
Чтобы не заблудиться в своих рассуждениях, мы решили обратиться непосредственно к разработчику Приказа №31, и делимся с вами результатами (Таблица 2). К слову, спасибо представителям ФСТЭК, которые очень подробно ответили на все вопросы в течение месяца, и даже позвонили, чтобы пояснить ответы)).
Таблица 2 – Комментарии ФСТЭК к подсистеме ОБР Приказа №31
|
Вопрос, касающийся подсистемы ОБР Приказа №31 |
Выдержка из ответа представителей ФСТЭК |
|
Являются ли инженеры-программисты (представители оператора АСУ), разрабатывающие/дорабатывающие прикладное программное обеспечение для функционирования АСУ ТП (мнемосхемы, алгоритмы ПЛК и т.д.) разработчиками согласно терминологии приказа №31 |
К разработчикам системы защиты информации АСУ относятся в том числе инженеры-программисты, привлекаемые к разработке/доработке прикладного ПО для обеспечения безопасности информации в АСУ |
|
В случае самостоятельной разработки прикладного программного обеспечения операторами АСУ и необходимости выполнения ими требований к ОБР, какие из анализаторов кода можно использовать? Ведь на данный момент известные анализаторы кода (Safe ERP, Infowatch APPERCUT, SolarinCode, PVS-Studio и т.п.) не ориентированы на SCADA-пакеты и АСУ в целом (не поддерживают языки программирования ПЛК, к примеру) |
Выбор автоматизированных средств, применяемых для реализации мер защиты информации по обеспечению безопасной разработки ПО, осуществляется оператором самостоятельно. В случае отсутствия автоматизированных средств анализа кода, он может быть проведен методом ручного анализа |
|
Может ли оператор АСУ использовать ПО стороннего разработчика, который не выполняет требования ОБР.0-ОБР.6 при разработке ПО? Если да, то при каких условиях? |
В соответствии с пунктом 13.4 Требований требования к мерам и средствам защиты информации, применяемым в АСУ, устанавливаются заказчиком на этапе формирования требований к защите информации в автоматизированной системе управления. В процессе проектирования АСУ разработчиком должно быть выбрано ПО, соответствующее требованиям в части разработки ПО. В случае отсутствия возможности использования указанного ПО разработчиком системы защиты АСУ должны быть реализованы компенсирующие меры, связанные с применением недоверенного ПО, в соответствии с пунктом 22 Требований |
|
Согласно п.18.14 Приказа №31 контроль принимаемых мер по выявлению, анализу и устранению уязвимостей программного обеспечения осуществляется Заказчиком и (или) Оператором АСУ. Каким образом, выполняется данное требование, в случае, когда Заказчиком или Оператором АСУ не осуществляется разработка прикладного ПО, а используется прикладное ПО (SCADA-пакеты, СУБД, исполнительные системы ПЛК и т.д.) сторонних разработчиков? |
Контроль принимаемых мер защиты информации по выявлению, анализу и устранению уязвимостей, в том числе прикладного ПО сторонних разработчиков, может проводиться на этапе внедрения системы защиты АСУ при анализе уязвимостей АСУ в соответствии с пунктом 15.7 Требований. Кроме того, при приобретении стороннего ПО необходимо предусмотреть процедуру запроса документов, подтверждающих тестирование ПО на уязвимости при разработке |
Что мы получаем в итоге?
Требования подсистемы ОБР предъявляются к ПО, разрабатываемому в том числе представителями оператора АСУ ТП, таким образом необходима реализация определенного для конкретной АСУ ТП набора мер данной подсистемы. Плюс в том, что механизм адаптации и уточнения Приказа №31 позволяет обосновать, например, использование ручного анализа кода вместо статистического или динамического. Т.е. возможность использования компенсирующих мер позволяет для каждого специфичного случая обеспечить требуемый уровень защищенности АСУ ТП.
Белых пятен в Приказе №31 становится все меньше. А какие белые пятна для вас были/есть в Приказе №31? С полной версией ответа ФСТЭК России можно ознакомиться здесь.
