Согласно приказу ФСТЭК от 1 декабря 2023 №240 можно не только сертифицировать программное обеспечение (ПО) средств защиты информации (СЗИ), но и пройти сертификацию процессов безопасной разработке и получить сертификат соответствия (документ, подтверждающий требования безопасности информации), что конечно же, облегчит жизнь компании. В Российской Федерации темой разработки безопасного программного обеспечения занимаются с подачей регуляторов, а также на научной основе.
Актуальность создания безопасного программного обеспечения
Разработка безопасного программного обеспечения (РБПО) - ПО, разработанное с использованием совокупности мер, направленных на предотвращение появления и устранение уязвимостей программы. Требования к РБПО изложены в приказе ФСТЭК от 13 февраля 2013 №17, в том числе экспертиза исходного кода, статического и динамического анализа.
Помимо определения рассматриваемого процесса, стоит разобраться и с методологией безопасного жизненного цикла (ЖЦ).
Методология безопасного ЖЦ объекта оценки (ОО) - соблюдение совокупности принципов, правил, мер, требований, а также последовательность мероприятий ЖЦ для целей предотвращения появлений и устранения уязвимостей в ОО, поддержание доверия к ОО на всём протяжении ЖЦ ОО и обеспечения необходимого и достаточного уровня безопасности ОО.
Цель РБПО - обеспечение высокой конкурентоспособной скорости разработки и внедрения безопасных программных продуктов (более подробно - ГОСТ Р 56939 - 2016, пункт 7.4.1 Общие положения). Кажется теперь стало немного понятнее.
Говоря об РБПО, стоит задуматься, что является критериями и показателями безопасности ПО:
- Отсутствие уязвимостей;
- Отсутствие недостатков.
Что такое недостатки, а также достаточно ли отсутствия уязвимостей для того, чтобы считать ПО безопасным выясняют специалисты данной области.
Кому нужно РБПО?
- собственные нужды;
- заказчики;
- пользователи;
- финансовые сферы;
- промышленные сектора;
- сферы IT и телекомпании;
- организации, имеющие или получающие лицензию на создание средств защиты информации (СЗИ).
Согласно приказу ФСТЭК России от 25 декабря 2017 №239, среди требований к программным и программно-аппаратным средствам, применяемым для обеспечения безопасности значимых объектов, можно обнаружить требования к испытаниям по выявлению уязвимостей ПО - сформулировано, что результаты оценки должны быть включены в проектную документацию на значимых объектах и предоставлены субъекту критической информационной инфраструктуры (КИИ).
ГОСТ 56939 также направлен на предотвращение и устранение уязвимостей программы.
ГОСТ Р 71207 - 2024
Наконец, в свежем и недавно вышедшем (01.04.2024) ГОСТе сформулировано понятие критической ошибки, что является большим плюсом для РБПО.
Критическая ошибка - ошибка, которая может привести к нарушению безопасности обрабатываемой информации. Подобные ошибки необходимо найти и исправить, а не думать над тем, как их можно эксплуатировать. Так код можно будет назвать безопасным. Примеры подобных ошибок:
Интерпретируемые языки:
- ошибки непроверенного использования чувствительных данных;
- ошибки некорректного использования системных процедур и интерфейсов, связанных с обеспечением информационной безопасности;
- ошибки при работе с многопоточными примитивами.
Компилируемые языки (добавляется к ошибкам, изложенных выше):
- ошибки целочисленного переполнения и некорректного совместного использования знаковых и беззнаковых чисел;
- ошибки переполнения буфера.
С и С++:
- ошибки разыменования нулевого указателя;
- ошибки деления на ноль;
- ошибки управления динамической памятью;
- ошибки использования форматной строки;
- ошибки использования неинициализированных переменных;
- ошибки утечек памяти, незакрытых файловых дескрипторов и дескрипторов сетевых соединений.
Практический пример ошибки управления динамической памятью:
void ...
{
...
} else {
delete ops;
legatos [ops -> track() ] = 0;
}
Стоит заметить, что всё условно и относительно, а потому некритическая ошибка на первый взгляд может быть критической. ГОСТ также подразумевает использование набора статических анализаторов, так как выбор одного варианта бывает сложен. Кроме того, в документе изложены требования к инструментам статического анализа. (Анализатор запускается != анализатор внедрён). Интересным фактом является и то, что сторонний код библиотек - теперь тоже ваш код и его также необходимо проверять.
По итогам стандарта ясно, что стоит руководствоваться фразой "Хорошо делай - хорошо будет", но всё таки вопрос разработчиков "Чем руководствоваться и в какую сторону развивать статический анализатор?" остаётся открытым.
Управление процессом безопасной разработки
Решения в данной области могут применяться на основе:
- разной целевой аудитории;
- разной детализации;
- разного угла зрения.
Единой основой является объективные данные телеметрии.
Источниками данных могут являться системы управления задачами, исходным кодом, артефактами, инцидентами. Системы отслеживания дефектов, инструменты безопасности ПО, а также сервисы CI/CD.
Помимо прочего, необходимо производить мониторинг и анализ показателей в режиме реального времени, предварительную настройку критериев качества, визуализация данных и сквозной контроль безопасности.
Результатами будут являться:
- Становление полноценной частью инженерного процесса разработки защищённого ПО;
- Реализация прозрачного процесса, управляемого на основе метрик;
- Уменьшение количества уязвимостей ПО и стоимости их устранения;
- Наращивание внутренней экспертизы в части безопасной разработки.
Полезные статьи для более подробного ознакомления с темой:
