|
Александр Моисеев: «Для внедрения процесса безопасной разработки ПО ориентируйтесь на ГОСТ Р 56939»
Главная / Статьи / Общие тенденции и тренды / Александр Моисеев: «Для внедрения процесса безопасной разработки ПО ориентируйтесь на ГОСТ Р 56939»
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Александр Моисеев: «Для внедрения процесса безопасной разработки ПО ориентируйтесь на ГОСТ Р 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 ФСТЭК России
Подпишитесь на журнал
Купите в Интернет-магазине
В начало⇑
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Комментарии отсутствуют
Комментарии могут отставлять только зарегистрированные пользователи
|
RAMAX Group расскажет об инструментах повышения операционной эффективности на «RPA Connect: Магия притяжения» 
_cover.jpg)
_cover.jpg)
_cover.jpg)
