Разработка безопасного программного обеспечения по ГОСТ Р 56939-2016
5 сентября, 2016
Пришлось столкнуться с новым стандартом по разработке безопасного — ГОСТ Р 56939-2016.
Документ получился интересный, поэтому полезно провести его небольшой анализ.
Стандарт был принят прошедшим летом, но вступит в силу только через год – с 1 июля 2017 года. Разработчиком стандарта является ЗАО «НПО «ЭШЕЛОН». Целевой аудиторией стандарта являются разработчики ПО, а также организации, выполняющие оценку соответствия.
В стандарте можно выделить следующие ключевые моменты:
- Стандарт устанавливает общие требования к содержанию и порядку выполнения работ, связанных с созданием безопасного ПО. Детали соответствующих процессов в стандартом не регламентируются.
- Меры по разработке безопасного ПО применяются в течение всего жизненного цикла ПО. Есть связь с процессами, описанными в ИСО/МЭК 12207-2010.
- Стандартом вводится базовый набор мер по разработке безопасного ПО. При невозможности реализации в среде разработки ПО отдельных мер из базового набора, разработчик имеет право реализовать компенсирующие меры.
- В стандарте предусмотрено целых 6 видов испытаний ПО: статический анализ и экспертиза кода, функциональное тестирование программы, тестирование на проникновение, динамический анализ кода и фаззинг-тестирование.
- Учитывается необходимость защиты инфраструктуры среды разработки ПО.
- Учитывается необходимость обеспечения конфиденциальности информации, получаемой в ходе анализа кода и тестирования ПО
Всего в стандарте описано 23 меры. По каждой мере четко описаны цели, результат реализации, а также требования к реализации меры (т.е. что именно нужно сделать). Радует, что все меры описаны достаточно однозначно.
«Базовый набор мер» по ГОСТ Р 56939-2016 выглядит следующим образом:
1. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении анализа требований к программному обеспечению:
1.1. При выполнении анализа требований к ПО разработчик ПО должен определить требования по безопасности, предъявляемые к разрабатываемому ПО.
2. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении проектирования архитектуры программы:
2.1. Моделирование угроз безопасности информации.
2.2. Уточнение проекта архитектуры программы с учетом результатов моделирования угроз безопасности информации.
3. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении конструирования и комплексирования программного обеспечения:
3.1. Использование при разработке ПО идентифицированных инструментальных средств.
3.2. Создание программы на основе уточненного проекта архитектуры программы.
3.3. Создание (выбор) и использование при создании программы порядка оформления исходного кода программы.
3.4. Статический анализисходного кода программы.
3.5. Экспертизаисходного кода программы.
4. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении квалификационного тестирования программного обеспечения:
4.1. Функциональное тестирование программы.
4.2. Тестирование на проникновение.
4.3. Динамический анализ кода программы.
4.4. Фаззинг-тестирование программы.
5. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении инсталляции программы и поддержки приемки программного обеспечения:
5.1. Обеспечение защиты ПО от угроз безопасности информации, связанных с нарушением целостности в процессе его передачи пользователю.
5.2. Поставка пользователю эксплуатационных документов.
6. Меры по разработке безопасного программного обеспечения, реализуемые при решении проблем в программном обеспечении в процессе эксплуатации:
6.1. Реализация и использование процедуры отслеживания и исправления обнаруженных ошибок ПО и уязвимостей программы.
6.2. Систематический поиск уязвимости программы.
7. Меры по разработке безопасного программного обеспечения, реализуемые в процессе менеджмента документацией и конфигурацией программы:
7.1. Реализация и использование процедуры уникальной маркировки каждой версии ПО.
7.2. Использование системы управления конфигурацией ПО.
8. Меры по разработке безопасного программного обеспечения, реализуемые в процессе менеджмента инфраструктурой среды разработки программного обеспечения:
8.1. Защита от несанкционированного доступа к элементам конфигурации.
8.2. Резервное копирование элементов конфигурации.
8.3. Регистрация событий, связанных с фактами изменения элементов конфигурации.
9. Меры по разработке безопасного программного обеспечения, реализуемые в процессе менеджмента людскими ресурсами
9.1. Периодическое обучение сотрудников.
9.2. Периодический анализ программы обучения сотрудников.
Далее рассмотрим примерный набор документов, которые должны быть в наличии в соответствии со стандартом.
- Политика информационной безопасности в соответствии с ИСО/МЭК 27001.
- Руководство по разработке безопасного ПО.
- Перечень требований по безопасности (могут быть включены в ТЗ).
- Модель угроз безопасности.
- Проект архитектуры программы (логическая структура программы).
- Перечень инструментальных средств разработки ПО.
- Описание проектных решений, обеспечивающих выполнение требований по безопасности;
- Порядок оформления исходного кода программы.
- Регламент и протоколы статического тестирования программы.
- Регламент и протоколы экспертизы исходного кода программы.
- Регламент и протоколы функционального тестирования программы.
- Регламент и протоколы тестирования на проникновение.
- Регламент и протоколы динамического анализа кода программы.
- Регламент и протоколы фаззинг-тестирования программы.
- Эксплуатационная документация.
- Регламент передачи ПО пользователю.
- Регламент отслеживания и исправления обнаруженных ошибок ПО и уязвимостей программы.
- Регламент приема и обработки сообщений от пользователей об ошибках ПО и уязвимостях программы.
- Регламент доведения до пользователей информации об уязвимости программы и рекомендаций по их устранению.
- Журнал ошибок и уязвимостей программы.
- Регламент экстренного выпуска обновлений ПО.
- Регламент, протоколы и журналы поиска уязвимостей программы.
- Регламент доведения до пользователей сведений об уязвимостях программы.
- Регламент маркировки версий ПО.
- Регламент управления конфигурацией ПО.
- Регламент защиты инфраструктуры среды разработки ПО.
- Регламент резервного копирования конфигурации ПО.
- Регламент регистрации событий изменений конфигурации ПО.
- Журнал регистрации изменений конфигурации ПО.
- Программа обучения сотрудников в области разработки безопасного ПО.
- Журнал обучения сотрудников в области разработки безопасного ПО.
Перечень примерный. В самом стандарте допускается компоновка документов по усмотрению разработчика.
Подводя итог, хочется отметить достоинства документа:
- продуманный набор мер, хорошее объяснение по сути каждой меры;
- разрешается использовать компенсирующие меры;
- предусмотрен широкий перечень проверок кода и тестирования ПО;
- связь с ГОСТ Р ИСО/МЭК 15408, ИСО/МЭК 12207-2010.
P.S. Для тех, кто хочет глубже понять стандарт, советую отличную научную статью, практически из первоисточника: ссылка.
В статье очень подробно объясняется методика разработки стандарта и состав защитных мер.
Цифровой мир полон опасностей — подписывайтесь на наш канал и научитесь как их преодолеть!
Библиография
| Обозначение ГОСТ | ГОСТ Р 56939-2016 |
| Наименование на русском языке | Защита информации. Разработка безопасного программного обеспечения. Общие требования |
| Наименование на английском языке | Information protection. Secure Software Development. General requirements |
| Дата введения в действие | 01.06.2017 |
| Код ОКС | 35.020 |
| Количество страниц | 24 |
| Статус | Действует |
 |
Внедрение мер по разработке безопасного программного обеспечения (ПО) на всех этапах жизненного цикла (SDLC ─ Secure Software Development Lifecycle) является обязательным условием конкурентоспособности на рынке для компаний, занимающихся разработкой ПО. Наша компания внедрила в свой процесс разработки лучшие практики по организации процесса разработки безопасного ПО с целью предоставления более надежной и безопасной продукции нашим заказчикам. В частности, Infotecs SDLC (ISDL) учитывает требования регламентов ФСТЭК России, национального стандарта ГОСТ Р 56939-2016, международных стандартов серии ISO/IEC 27000, материалы OWASP, а также рекомендации NIST (например, NIST SP 800-64, SP 800-100).
ISDL ─ это комплексный процесс, затрагивающий всю организацию и включающий следующее:
Программа обучения
Без эффективной программы обучения внедрить ISDL было бы невозможно. Мы разработали ряд корпоративных обучающих курсов, призванных восполнить недостающие знания в области защиты информации, обеспечить необходимую поддержку и повышение профессиональной квалификации сотрудников с учетом их обязанностей и зон ответственности в рамках ISDL. Помимо теоретических знаний по безопасности, наши обучающие курсы включают набор практических упражнений, которые так необходимы для технических специалистов.
Сбор требований
Определение требований к продукту сводится к поиску компромисса между бизнес-потребностями заказчика и уровнем безопасности, необходимым для защиты его активов. Такого компромисса можно достичь только путем сбора и тщательного анализа требований рынка, соответствующих нормативно-правовых актов, а также стандартов и лучших практик.
Требования рынка
Сбор требований рынка включает выявление проблемы заказчика, которая может быть решена с помощью продукта или сервиса. На данном этапе важно прояснить множество деталей, например, тип защищаемых данных, необходимую функциональность продукта, возможные ограничения, связанные со средой функционирования продукта и так далее.
Нормативно-правовые акты
Учет всех действующих нормативно-правовых актов на раннем этапе способствует снижению расходов, рисков несоответствия, а также времени выпуска продукта на рынок в целом.
Стандарты и лучшие практики
Несмотря на то, что законодательство зачастую не требует явного соблюдения каких-либо стандартов и лучших практик, их применение остается важным условием обеспечения конкурентоспособности продуктов и компании в целом.
Проектирование
На данном этапе мы тщательно анализируем собранные требования с тем, чтобы определить, каким образом реализовать эти требования в продукте, а также определяем наиболее надежный и безопасный способ их реализации. Если мы планируем использовать программное обеспечение сторонних производителей, мы тщательно его проверяем, а также проводим анализ поверхности атак (в том числе, разрабатываем модель нарушителя) и разрабатываем модель угроз.
Анализ сторонних компонентов
При коммерческом использовании стороннего программного обеспечения мы обязуем партнеров в кратчайшие сроки уведомлять нас о выявленных уязвимостях для принятия необходимых мер по предотвращению их эксплуатации. Кроме того, мы автоматически отслеживаем информацию об уязвимостях, обнаруженных в программном обеспечении с открытым исходным кодом (если такое ПО используется в наших продуктах или мы планируем использовать его в будущем), чтобы своевременно вносить необходимые изменения.
Анализ поверхности атак
Цель такого анализа ─ выявить, к каким компонентам или функциям злоумышленник имеет доступ и, соответственно, может их использовать, и свести количество таких компонентов и функций к минимуму.
Разработка модели угроз
Разработка модели угроз ─ один из наиболее важных этапов разработки продукта с учетом безопасности. Мы разрабатываем модель угроз с учетом результатов, полученных на предыдущем шаге. Затем мы используем ее для определения необходимого уровня безопасности и последующего выбора соответствующих мер защиты, которые должны быть реализованы в продукте.
Разработка
Безопасное программирование прежде всего направлено на предотвращение появления ошибок в коде на этапе разработки, что может быть достигнуто посредством:
- Внедрения строгого стандарта безопасного программирования и контролем его соблюдения посредством анализа кода;
- Внедрением современных инструментов автоматизации (статических анализаторов, компиляторов, систем контроля версий и т.д.) в среду разработки ПО.
Стандарт безопасного программирования
Мы разработали корпоративный стандарт безопасного программирования, внедрили его в наш процесс разработки ПО. Данный стандарт учитывается в программе обучения сотрудников и является обязательным для технических специалистов, участвующих в процессе разработки безопасного ПО.
Анализ кода
Анализ безопасности кода, выполненный экспертами по безопасности, и ревью кода позволяют устранять ошибки на самых ранних этапах разработки ПО. Эти методы достаточно эффективны для обнаружения как случайных, так и преднамеренных логических ошибок в коде.
Средства автоматизации
Процесс разработки ПО предполагает использование автоматизированных средств (компиляторов, систем контроля версий, анализаторов кода и т.д.), которые должны быть настроены надлежащим образом. Чтобы оставаться эффективными, эти инструменты должны своевременно обновляться, поэтому мы стараемся поддерживать актуальность версий средств автоматизации, используемых в нашей среде разработки.
Проверка
Целью данного этапа является проверка того, что продукт отвечает требованиям спецификации и обеспечивает необходимый уровень безопасности. Для функциональной оценки продукта целесообразно проводить интеграционное, регрессионное и модульное тестирование. Одновременно, тестирование мер защиты, сканирование на наличие уязвимостей и тестирование на проникновение, представляют собой важную часть тестирования безопасности, выполняемого на этапе проверки.
Тестирование мер защиты
На данном этапе выполняется тестирование мер защиты, в рамках которого проверяется, что они разработаны надлежащим образом и действительно обеспечивают необходимый уровень безопасности.
Сканирование на наличие уязвимостей
Регулярное автоматизированное сканирование на уязвимости позволяет выявить и устранить уязвимости до выпуска продукта. На данном этапе также рекомендуется выполнить фаззинг тестирование, чтобы проверить, что программа корректно отвечает, как на ожидаемые, так и на случайные входные значения, — это позволяет идентифицировать ошибки переполнения буфера, проверки входных параметров и проблемы безопасности.
Тестирование на проникновение
Тестирование на проникновение, выполняемое экспертами по безопасности, позволяет эффективно выявлять сложные уязвимости и, следовательно, хорошо дополняет сканирование с помощью автоматизированных средств.
Выпуск и поддержка продукта
Выпуск продукта на рынок осуществляется только после успешного проведения финальной проверки безопасности (FSR – Final Security Review), выполненной командой разработки и экспертами по безопасности. Кроме того, мы разработали план реагирования на инциденты для устранения возможных проблем безопасности в наших продуктах. Мы также оказываем услуги технической поддержки (ссылка) и своевременно предоставляем заказчикам всю необходимую информацию о планируемых изменениях в продукте.
Финальная проверка безопасности / Сертификация
Основная цель финальной проверки безопасности – оценка готовности продукта и принятие решения о том, будет ли он выпущен на рынок. Такая проверка включает оценку безопасности продукта, а также, когда это необходимо, его сертификацию.
План реагирования на инциденты
Ни одна компания не хочет разрабатывать уязвимое программное обеспечение. Тем не менее, в процессе разработки невозможно полностью избавиться от ошибок, как и невозможно предотвратить появление новых уязвимостей. Поэтому наличие заблаговременно подготовленного плана реагирования на инциденты может существенно сэкономить время и деньги.
Управление конфигурацией и изменениями
Практически любой готовый продукт требует настройки для последующей работы в производственной среде. При этом, чтобы он продолжал обеспечивать необходимый уровень безопасности в процессе эксплуатации, состояние продукта нужно отслеживать, а также его необходимо своевременно обновлять (например, в связи с выпуском новой версии, необходимостью исправления ошибок и / или устранения обнаруженных уязвимостей).
Вывод из эксплуатации
Когда наступает время вывода продукта из эксплуатации (например, в виду его устаревания, необходимости обновления или по любым другим причинам), нельзя забывать о том, что защищаемая информация все еще должна оставаться защищенной. Для этого нужно заранее спланировать и разработать процесс вывода продукта из эксплуатации, принимая во внимание меры защиты, которые должны применяться для обеспечения безопасности при организации последующего хранения информации, удалении данных и аппаратного и программного обеспечения в целом.
Сохранение информации
Сохранение ценной информации подразумевает не только обеспечение доступности такой информации (например, когда это требуется по закону), но и обеспечение ее защиты в процессе и, если необходимо, после вывода продукта из эксплуатации.
Удаление данных
Для предотвращения разглашения защищаемой информации, необходимо уделять особое внимание методам и оборудованию, которые используются при удалении данных с носителя. Выбор соответствующих методов удаления защищаемой информации (путем перезаписи, размагничивания или уничтожения) должен осуществляться с учетом необходимого уровня безопасности.
Удаление аппаратного и программного обеспечения
Физическое уничтожение аппаратного обеспечения может потребоваться только в том случае, если защищаемую информацию невозможно удалить с помощью других средств.
В то же время настоятельно рекомендуется удалять устаревшее программное обеспечение, поскольку в противном случае его последующее использование может привести к возникновению новых рисков.
СОИБ. Анализ. Разработка безопасного ПО
В сегодняшней заметке хотелось бы
поговорить про свежий ГОСТ Р 56939-2016 ЗАЩИТА ИНФОРМАЦИИ. РАЗРАБОТКА
БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. ОБЩИЕ ТРЕБОВАНИЯ. Разработан ЗАО НПО
Эшелон, недавно отличившимся в пропущенных уязвимостях SN и DL. Введен в действие с 1
июня 2016 г.
Стандарт современный, учитывающий
актуальные практики, но высокоуровневый. Всё-таки это общие требования, которые
потом хорошо бы детализировать. Предназначен для разработчиков ПО и организаций,
проводящих оценку соответствия процесса разработки ПО (аудиторов). В соответствии с лучшими практиками (как в
австралийском ISM)
требуемые меры вводятся тремя формами: должен (must), следует(should) и может(may). Предусмотрены компенсирующие меры
для неприменимых.
Несмотря на то, что стандарт
утвержден в июне этого года, уже есть российские производители, заявившие о
соответствии требованиям стандарта. Видимо внедрение мер безопасной разработки
ПО была проведена до выхода стандарта?
Пожалуй, для полноты картины в
стандарте не хватает приложения с таблицей для оценки соответствия. Решил
сделать такую таблицу, для быстрой самооценки, в случае если вы только планируете
внедрять этот стандарт – может быть полезным.
Пример возможного перечня
документальных свидетельств, полученного в результате выполнения требований:
·
Руководство по разработке безопасного
программного обеспечения (РБПО)
o
Описание средств разработки ПО
o
Описание средств управления конфигурацией
o
Порядок оформления исходного кода
o
Порядок маркировки версий ПО
o
Порядок отслеживания уязвимостей
o
Порядок систематического поиска уязвимостей
·
Отчеты (о разовых мероприятиях)
o
Статистического анализа кода
o
Экспертиза исходного кода
o
Функционального тестирования
o
Тестирования на проникновение
o
Динамического анализа кода
·
Свидетельства об обучении сотрудников
Популярные сообщения из этого блога
Модель угроз безопасности клиента финансовой организации
Уже более 2 месяцев как вступил в силу методический документ ФСТЭК по моделированию угроз, а ни одного публичного примера модели угроз информационной безопасности сообществом не было опубликовано. Как мы обсуждали на межблогерском вебинаре по моделированию угроз ИБ , такой пример мог бы сильно помочь ответственным лицам, обязанным руководствоваться данной методикой. Пример модели угроз обещал сделать Алексей Лукацкий, но пока у него получилась серия публикаций про проблемы моделирования и примера ещё нет. В УЦСБ в рамках услуг по моделированию угроз, коллеги уже провели необходимую аналитику и подготовили внутренние средства автоматизации для разработки МУ, что уже говорит о возможности моделирования угроз по новой Методике. К последнему межблогерскому вебинару по безопасности клиентов финансовых организаций я решил проверить насколько адекватной получится модель угроз для типового сегмента клиента ФО (а для данной статьи ещё и обновил графическое оформление). Давайте посмот
Сравнение техник и тактик нарушителей из методики ФСТЭК и матриц MITRE ATT&CK
Как вы, наверное, знаете, новая методика моделирования угроз ФСТЭК России сделала революцию в российских подходах к моделированию угроз – теперь нужно рассматривать угрозы – как комбинацию сценариев действий нарушителей, составленных из элементарных частиц – техник и тактик. Но техники и тактики из методики ФСТЭК немного, они недостаточно сбалансированы и пока не обновляются. Параллельно с этим существуют мировые лучшие практики по структурированию действий нарушителей кибербезопасности и самая популярная из них – матрица MITRE ATT & CK и сопутствующие ей матрицы хакерских группировок, способов обнаружения и возможных мер защиты. Как применить MITRE ATT & CK на практике хорошо рассказал Алексей Лукацкий на недавнем вебинаре Но что, если мы хотим взаимоувязать моделирование угроз по методике ФСТЭК России и анализ по матрицам MITRE ? Я вижу следующие возможные варианты интеграции этих двух каталогов: · Провести анализ актуальных техник и тактик и контрмер п
Mind map по моделированию угроз ИБ
11 марта 2021 вместе с Ксенией Лебедевой (Шудровой) и Алексеем Лукацким провели вебинар по моделированию угроз информационной безопасности. Уже прошел почти месяц с момента публикации новой методики ФСТЭК России , а никаких обзоров, анализа и обсуждений ещё не было. Нужно было кому то начинать и мы взяли на себя это. Лично я начинал анализ новой методики с того, что сделал для себя mind карту документа – отметил там основные тезисы, проблемы, направления будущей аналитики. Её же использовал при подготовке вебинара и пару раз она промелькнула на самом вебинаре. В связи с большим количеством запросов на её в комментариях – выкладываю эту карту в картинке тут. А исходники будут в группах в VK и FB Основные мои мысли по поводу новой методики: · В методике достаточно много остается на экспертную оценку, экспертное определение и нужно много придумывать. Соответственно нужно закладывать большое количество трудозатрат по сравнению с предыдущими вариантами методик. · Хот