Александр Моисеев: «Для внедрения процесса безопасной разработки ПО ориентируйтесь на ГОСТ Р 56939»
 
                 
Поиск по сайту
 bit.samag.ru     Web
Рассылка Subscribe.ru
подписаться письмом
Вход в систему
 Запомнить меня
Регистрация
Забыли пароль?

Календарь мероприятий
февраль    2023
Пн
Вт
Ср
Чт
Пт
Сб
Вс
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

показать все 

Новости партнеров

26.01.2023

ФОРМИРУЕТСЯ ДЕЛОВАЯ ПРОГРАММА 25-Й КОНФЕРЕНЦИИ «РУСКРИПТО»

Читать далее 

16.01.2023

«Свободное ПО в высшей школе» – единственная в России научно-практическая конференция «Базальт СПО»

Читать далее 

20.12.2022

На московской выставке беспилотной авиации обсудили вопросы продовольственной безопасности

Читать далее 

20.12.2022

Как утолить кадровый и технологический голод в сфере БПЛА: панельная дискуссия на московской выставке

Читать далее 

показать все 

Статьи

31.12.2022

Возможности реализации 2ФА в ОС Linux

Читать далее 

31.12.2022

Есть только миг между прошлым и будущим

Читать далее 

15.12.2022

Александр Моисеев: «Для внедрения процесса безопасной разработки ПО ориентируйтесь на ГОСТ Р 56939»

Читать далее 

15.12.2022

Быть мировым ИТ-лидером – утопия или сверхзадача?

Читать далее 

17.11.2022

8 шагов к росту продаж программных продуктов

Читать далее 

13.02.2020

Чат-бот CallShark не требует зарплаты, а работает круглосуточно

Читать далее 

24.12.2019

До встречи в «Пьяном Сомелье»!

Читать далее 

21.12.2019

Искусство как награда Как изготавливали статуэтки для премии IT Stars им. Георгия Генса в сфере инноваций

Читать далее 

04.12.2019

ЛАНИТ учредил премию IT Stars памяти основателя компании Георгия Генса

Читать далее 

04.06.2019

Маркетолог: привлекать, продавать, продвигать?

Читать далее 

показать все 

Александр Моисеев: «Для внедрения процесса безопасной разработки ПО ориентируйтесь на ГОСТ Р 56939»

Главная / Статьи / Общие тенденции и тренды / Александр Моисеев: «Для внедрения процесса безопасной разработки ПО ориентируйтесь на ГОСТ Р 56939»


Александр Моисеев: «Для внедрения процесса безопасной разработки ПО ориентируйтесь на ГОСТ Р 56939»

В Москве состоялась Первая межотраслевая конференция по регуляторике в сфере информационной безопасности финансовой отрасли.
По просьбе журнала «БИТ», спикер конференции Александр Моисеев, ведущий консультант по ИБ бизнес-направления AKTIV.CONSULTING Компании «Актив», рассказал о подходах к формированию процессов управления киберисками и киберустойчивостью в рамках системы управления операционными рисками организации.






– Александр, почему так актуально сегодня обеспечение безопасности значимых объектов критической информационной инфраструктуры?

– Потому что с 1 января 2023 года вступает в силу новая редакция Приказа ФСТЭК России № 239 от 25.12.2017 г., согласно которой при создании либо модернизации значимых объектов критической информационной инфраструктуры (ЗО КИИ) прикладное программное обеспечение должно соответствовать следующим условиям:

  • должны быть реализованы требования по безопасной разработке,
  • проведены испытания по выявлению уязвимостей,
  • обеспечена поддержка безопасности в ходе жизненного цикла.

Кроме того, до 1 января 2025 года в рамках 166-го Указа президента все прикладное ПО на значимых объектах КИИ должно быть импортозамещено. Два этих условия создают ситуацию, когда практически все субъекты КИИ и разработчики прикладного ПО, которые хотят поставлять его для значимых объектов критической информационной инфраструктуры, столкнутся с необходимостью внедрения процессов безопасной разработки программного обеспечения.

Рассматривая существующие подходы к внедрению процессов безопасной разработки ПО, можно выделить три основных направления. Это – отечественная регуляторика, гармонизированные международные стандарты, международные стандарты и практики. К последним двум можно отнести стандарты серии ГОСТ/ИСО МЭК 27034 «Безопасности приложений», систему стандартов ГОСТ Р ИСО/МЭК 15408 «Общие критерии», а также стандарты, разработанные на основе накопленного опыта крупных международных вендоров и некоммерческих организаций, таких как Microsoft, Cisco, OWASP и других.

Если говорить про отечественную регуляторику, то это уже упомянутый выше Приказ № 239 ФСТЭК России, а также система национальных стандартов ГОСТ Р 56939, к которой относится один утвержденный стандарт и пять опубликованных проектов стандартов.

Изложенные в них подходы хорошо знакомы разработчикам средств защиты информации, которые в ходе сертификационных испытаний проводят проверки безопасности своих программных продуктов по «Методике выявления уязвимостей и недекларированных возможностей» (документ утвержден в 2020 году и имеет ограниченное распространение), а также в соответствии с требованиям Приказа № 76 ФСТЭК России.

– Какие процессы необходимо внедрить для обеспечения безопасной разработки программного обеспечения?

– Давайте рассмотрим систему стандартов ГОСТ Р 56939 . В ней устанавливаются требования к 22 основным мерам безопасности, которые распределены по 9 основным этапам жизненного цикла ПО. Кроме того, содержатся рекомендации по реализации каждой меры безопасности. Приводятся типовые действия в ходе подготовки и реализации меры, а также возможное распределение ролей и обязанностей участников.

Помимо этого, устанавливаются требования по оценке соответствия: критерии, подходы и методы проведения оценки, а также перечень оцениваемых показателей. Иными словами мероприятия, которые должен формально провести оценщик для того, чтобы удостовериться, что требования стандарта 56939 выполняются.

Также в стандарте 56939 содержатся требования к методикам и инструментам, реализующим конкретные меры, в том числе требования к процессу проведения статического и динамического анализов кода.

Каковы основные требования Приказа № 239 ФСТЭК РФ?  Опишу их.

Первое требование. Разработка документа «Руководства по безопасной разработке ПО».

Данное руководство, помимо общих организационных моментов, касающихся области действия, определения целей, распределения ролей, должно включать указания на все процедуры безопасной разработки. Для оперативного внесения всех изменений, связанных с разработкой ПО и проведением проверок безопасности, рекомендуем данное руководство разрабатывать в виде электронного документа (с учетом Федерального закона № 63 «Об электронной подписи»).

Второе требование. Анализ и моделирование угроз информационной безопасности.

На данном этапе происходит моделирование тех угроз, которые рабочая группа специалистов выявляет в предположении на каждом этапе жизненного цикла и разрабатывает компенсирующие мероприятия, которые затем отражаются на архитектуре разрабатываемого проекта ПО. Для моделирования угроз можно использовать такие опорные материалы, как ГОСТ Р 58412, Методику моделирования угроз ФСТЭК от 2021, БДУ ФСТЭК.

Третье требование. Обеспечение прослеживаемости.

Суть процесса в том, чтобы функциональную спецификацию ПО можно было проследить до конкретных блоков функций, которые их реализуют. Это упрощает контроль недекларированных возможностей в ходе реализации проекта ПО и внесения в него изменений.

Четвертое требование. Статический анализ кода (без его исполнения).

Это техническая мера, и она требует внедрения специального инструмента – статического анализатора кода.

По результатам анализа нескольких проверок безопасности статическим анализатором проекта ПО необходимо провести так называемую «разметку»: сопоставить выявленные ошибки и предупреждения с тем, являются ли они на самом деле недостатками ПО.

Также в правила статического анализатора можно добавить необходимую стилистику оформления исходного кода, которая принята в проекте. При каком-либо отступлении от нее разработчику необходимо будет в комментариях указывать причину.

Пятое требование. Динамический анализ кода (с его исполнением).

В простейшем случае динамический анализ кода проводится в виде ряда тестов: модульного, регрессионного и системного.

Модульные тесты разрабатываются на  функции, которые принимают входные значения из внешних данных (т.е. составляют поверхность атаки). В ходе инструментирования кода счетчиками ошибок (санитайзерами и отладочными аллокаторами) необходимо провести автоматизированный запуск этих тестов, собрать тестовое покрытие и проанализировать результаты.

На основании результатов можно, в том числе, увидеть участки кода, которые в ходе выполнения не были задействованы, а значит, требуют дополнительного внимания. К примеру, они могут быть проверены на отсутствие недекларированных возможностей в ручном режиме.

Шестое требование. Фаззинг-тестирование (с его исполнением).

Для данного процесса необходимо разработать специальные функции либо наборы входных данных (методами «мутационного» или «генерационного» фаззинга), которые подаются на вход тех же самых функций, составляющих поверхность атаки. И точно так же, как в динамическом анализе, для фаззинга собирается покрытие и анализируются результаты, а выявленные ошибки включаются в план устранения недостатков.

Седьмое требование.  Отслеживание исправления ошибок, уязвимостей в ходе жизненного цикла.

На данном этапе проводится автоматизация процедур реагирования на выявленные уязвимости, которые возникли в ходе разработки либо по сообщениям от пользователей.

Как правило, в информационных системах разработки заводятся тикеты. По данным тикетам разработчикам ставится в план задача по устранению критических уязвимостей и уязвимостей, имеющих высокий приоритет. Устранив уязвимость, разработчик в комментариях может сделать пометку с идентификатором тикета. Тем самым будет обеспечена прослеживаемость закрытия выявленных уязвимостей.

Восьмое требование. Информирование о выявленных уязвимостях и компенсирующих мероприятиях конечных пользователей.

В качестве примера можно привести сообщения на сайтах крупных разработчиков средств защиты информации. Там публикуются сообщения, в которых дается ссылка на источник скачивания обновлений, указываются идентификаторы уязвимостей, а также даются ссылки на инструкции по устранению уязвимостей и проведению дополнительных мероприятий.

Девятое требование. Оповещение конечного пользователя об окончании жизненного цикла ПО.

Например, в специальном разделе сайта разработчика могут быть организованы специальные «фильтры» по продуктам, которые ведут на страницы с планами по поддержке ПО в ходе жизненного цикла.

– Как осуществить проект  по внедрению безопасной разработки программного обеспечения в  соответствии с требованиями регулятора?

– Масштабы проекта для субъекта критической информационной инфраструктуры зависят от типа разработки: собственная, заказная или вендорская.

Когда прикладное ПО разрабатывается силами собственных разработчиков, необходимо внедрить наиболее полный состав процессов безопасности.

В случае заказной разработки или использования вендорского ПО необходимо обеспечить наличие всех необходимых свидетельств по процессам безопасности, выстроенным на стороне вендора – производителя ПО, и приобщить их в проектную документацию на ЗО КИИ.

Как правило, типовой проект внедрения процессов безопасной разработки ПО разделяется на пять основных этапов.

На первом этапе готовится технико-экономическое обоснование для руководства с верхнеуровневыми финансовыми параметрами проекта, основными этапами работ, основными результатами, которые достигаются в ходе проекта, а также персоналом, который требуется привлечь.

На втором этапе проводится аудит текущих бизнес-процессов разработки, формируется целевое состояние процессов разработки, исходя из требований регулятора либо бизнес-потребностей. Далее выявляются несоответствия и формируются рекомендации по внедрению организационных и технических мероприятий.

На третьем этапе рекомендации ранжируются по степени их реализуемости и сводятся в дорожную карту. Настоятельно рекомендуем разрабатывать детальный план перехода и пояснительную записку с обоснованием принятых решений, чтобы всегда можно было поднять историю и причины принятых решений.

Четвертый этап – это уже непосредственно работа проектной команды, которая движется по дорожной карте. Исходя из практики, оптимальным вариантом является тот, в котором техническое лидерство в проекте остается за разработчиками, а организационное лидерство, то есть руководство проектом, возложено на специалиста по информационной безопасности. В этом случае происходит тесная интеграция компетенций безопасников и разработчиков.

И наконец, на последнем этапе происходит контроль функционирования внедренных процессов. Через несколько месяцев после завершения внедрения производится сбор и анализ всех свидетельств и записей процессов безопасной разработки ПО на предмет их полноты и достаточности.

Мы обсудили только минимально необходимый набор процессов, которые должны быть внедрены по Приказу № 239 ФСТЭК России. Разумеется, подобных процессов безопасности и проверок может быть гораздо больше: сканирование на уязвимости, сканирование зависимостей, антивирусная проверка, анализ дампа сетевого трафика при динамическом анализе ПО или анализ логов при сборке проекта, любые другие виды проверок ПО на стендах или проведение пентестов.

Хочется отметить, что для внедрения процесса безопасной разработки программного обеспечения можно ориентироваться на ГОСТ Р 56939. Это позволит не только выполнить требования приказа ФСТЭК, но и охватить все необходимые этапы жизненного цикла разработки ПО.

При реализации проекта по внедрению безопасной разработки программного обеспечения необходимо учитывать существующие процессы разработки, специфику организации и ее значимых объектов КИИ. Старт проекту должно дать руководство при полном понимании выгод от  реализации проекта и затрат на него.

Eщё по теме


В Москве состоялась 8 ноября 2022 г. Первая межотраслевая конференция по регуляторике в сфере информационной безопасности финансовой отрасли. Организаторами мероприятия выступили Ассоциация АБИСС и Академия информационных систем (АИС) при поддержке Банка России.
В рамках конференции обсуждались следующие вопросы: выполнение ИБ-требований в условиях импортозамещения; формирование требований для сервисной модели и аутсорса ИБ; гармонизация межведомственных требований и их адаптация под реалии времени; проведение контрольно-надзорных мероприятий в существующих условиях; управление операционной надежностью и киберрисками; обеспечение безопасности прикладного ПО финансовых организаций; практика реализации существующих требований.

 

Ключевые слова: прикладное ПО, субъекты КИИ, ГОСТ Р 56939, Приказ № 239 ФСТЭК России

https://aktiv.consulting/

 


Подпишитесь на журнал
Купите в Интернет-магазине

 

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи

Выпуск №10 (123) 2022г.
Выпуск №10 (123) 2022г. Выпуск №09 (122) 2022г. Выпуск №08 (121) 2022г. Выпуск №07 (120) 2022г. Выпуск №06 (119) 2022г. Выпуск №05 (118) 2022г. Выпуск №04 (117) 2022г. Выпуск №03 (116) 2022г. Выпуск №01 (114) 2022г. Выпуск №02 (115) 2022г.
Вакансии на сайте Jooble

           

Tel.: (499) 277-12-41  Fax: (499) 277-12-45  E-mail: sa@samag.ru

 

Copyright © Системный администратор

  Яндекс.Метрика