В сегодняшней заметке хотелось бы поговорить про свежий ГОСТ Р 56939-2016 ЗАЩИТА ИНФОРМАЦИИ. РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. ОБЩИЕ ТРЕБОВАНИЯ. Разработан ЗАО НПО Эшелон, недавно отличившимся в пропущенных уязвимостях SN и DL. Введен в действие с 1 июня 2016 г.
Стандарт современный, учитывающий актуальные практики, но высокоуровневый. Всё-таки это общие требования, которые потом хорошо бы детализировать. Предназначен для разработчиков ПО и организаций, проводящих оценку соответствия процесса разработки ПО (аудиторов). В соответствии с лучшими практиками (как в австралийском ISM) требуемые меры вводятся тремя формами: должен (must), следует(should) и может(may). Предусмотрены компенсирующие меры для неприменимых.
Несмотря на то, что стандарт утвержден в июне этого года, уже есть российские производители , заявившие о соответствии требованиям стандарта. Видимо внедрение мер безопасной разработки ПО была проведена до выхода стандарта?
Пожалуй, для полноты картины в стандарте не хватает приложения с таблицей для оценки соответствия. Решил сделать такую таблицу, для быстрой самооценки, в случае если вы только планируете внедрять этот стандарт – может быть полезным.
Пример возможного перечня документальных свидетельств, полученного в результате выполнения требований:
· Руководство по разработке безопасного программного обеспечения (РБПО)
· МУ
· ТЗ
· Проектная документация
o Архитектура ПО
o Описание средств разработки ПО
o Описание средств управления конфигурацией
o Порядок оформления исходного кода
o Порядок маркировки версий ПО
o Порядок передачи ПО
o Порядок отслеживания уязвимостей
o Порядок систематического поиска уязвимостей
· План тестирования
· Отчеты (о разовых мероприятиях)
o Статистического анализа кода
o Экспертиза исходного кода
o Функционального тестирования
o Тестирования на проникновение
o Динамического анализа кода
o Фазинг тестирования
· Свидетельства об обучения сотрудников
Стандарт современный, учитывающий актуальные практики, но высокоуровневый. Всё-таки это общие требования, которые потом хорошо бы детализировать. Предназначен для разработчиков ПО и организаций, проводящих оценку соответствия процесса разработки ПО (аудиторов). В соответствии с лучшими практиками (как в австралийском ISM) требуемые меры вводятся тремя формами: должен (must), следует(should) и может(may). Предусмотрены компенсирующие меры для неприменимых.
Несмотря на то, что стандарт утвержден в июне этого года, уже есть российские производители , заявившие о соответствии требованиям стандарта. Видимо внедрение мер безопасной разработки ПО была проведена до выхода стандарта?
Пожалуй, для полноты картины в стандарте не хватает приложения с таблицей для оценки соответствия. Решил сделать такую таблицу, для быстрой самооценки, в случае если вы только планируете внедрять этот стандарт – может быть полезным.
Пример возможного перечня документальных свидетельств, полученного в результате выполнения требований:
· Руководство по разработке безопасного программного обеспечения (РБПО)
· МУ
· ТЗ
· Проектная документация
o Архитектура ПО
o Описание средств разработки ПО
o Описание средств управления конфигурацией
o Порядок оформления исходного кода
o Порядок маркировки версий ПО
o Порядок передачи ПО
o Порядок отслеживания уязвимостей
o Порядок систематического поиска уязвимостей
· План тестирования
· Отчеты (о разовых мероприятиях)
o Статистического анализа кода
o Экспертиза исходного кода
o Функционального тестирования
o Тестирования на проникновение
o Динамического анализа кода
o Фазинг тестирования
· Свидетельства об обучения сотрудников
Ваш провайдер знает о вас больше, чем ваша девушка?
