Требования к безопасной разработке ПО согласно приказу ФСТЭК №31

В приказе ФСТЭК №31 (далее — приказ №31) есть «особенная» подсистема мер, которой нет в аналогичных приказах ФСТЭК для ГИС и ИСПДн, а именно «обеспечение безопасной разработки ПО» (далее — ОБР).

Что мы знаем об ОБР? Например, что в этом направлении ведется нормотворческая работа, примером тому служит проект ГОСТ Р «Обеспечение безопасной разработки ПО» (далее – проект ГОСТ). Посвящен он созданию системы управления безопасной разработкой ПО (далее — СУБР ПО) организацией-разработчиком ПО и учитывает, например, такие практики как Microsoft SDL, Cisco CDL, OWASP CLASP и положения ГОСТ Р ИСО/МЭК 15408-3, ГОСТ Р ИСО/МЭК 27001. Одной из причин создания данного ГОСТ является тот факт, что «виновниками»инцидентов ИБ чаще всего становятся дефекты безопасности и уязвимости программ. Актуальность защиты самого ПО (в том числе применяемого в промышленных системах автоматизации) от угроз, связанных с наличием в нем уязвимостей, не вызывает сомнения (Рисунок 1).

 image001

Рисунок 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? С полной версией ответа ФСТЭК России можно ознакомиться здесь.

Назад

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *