Наша работа - Ваша уверенность
Особенности безопасной разработки ПО для объектов КИИ

Процесс разработки ПО для объектов КИИ должен соответствовать Приказу ФСТЭК РФ № 239 от 25.12.2017 г, который вступил в силу 01.01.2023 г в новой редакции. Документ устанавливает ряд требований к прикладному ПО, которое внедряется при модернизации или создании значимых объектов КИИ с 2023 года.

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

В соответствии с п. 29.3 Приказа установлены требования касательно:

    • безопасной разработки ПО
    • испытаний по выявлению уязвимостей в ПО
    • поддержки безопасности ПО

 
Если проанализировать их подробнее, можно выделить ряд действий, которые потребуется выполнять компаниями-разработчикам ПО для значимых объектов КИИ:

    1. Разработать и содержать актуальным специальное руководство, которое описывает организационные вопросы в части обеспечения безопасности разрабатываемого ПО. Кроме того, рекомендуется в документе предусмотреть ссылки на существующие процессы в части ИБ.

    2. Анализировать и моделировать угрозы ИБ. На рабочую группу компании возлагается обязанность определить предположительные угрозы для каждой из стадий жизненного цикла ПО, смоделировать их и разработать компенсирующие меры.
     
    3. Обеспечить прослеживаемость функциональной специфики ПО. Так намного проще контролировать недекларированные возможности, т.е. неописанные или несоответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации, и вносить в ПО изменения.

    4. Проводить статистический анализ кода. Мероприятие технического характера. Для его реализации потребуется применение специального инструмента –  статистического анализатора. Исполнение кода для этого типа анализа не требуется.

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

    6. Проведение фаззинг-тестов. Используя методы генерационного либо мутационного фаззинга разрабатываются комплексы данных для отработки «входного» функционала или специальных функций для подачи на вход «поверхности атаки». Результаты анализа итогов тестирования, проведенного на данном этапе, учитывают при планировании задач по устранению недостатков.

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

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

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

Документационное обеспечение разработки ПО

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

Разработка типового проекта документации состоит из 5 основных этапов:

    1. Подготовка обобщенного технико-экономического обоснования.

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

    3. Создание «дорожной карты» с учетом степени реализуемости каждого мероприятия и их приоритетности.

    4. Основной этап – разработка. Работа группы / команды проекта. Рекомендуется организовать ее, обеспечив постоянное и плотное взаимодействие знаний и навыков разработчиков и специалистов по безопасности.

    5. Внедрение и контроль функционирования ПО.

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

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

Связанные материалы

(Словарь терминов ИБ) DevSecOps
(Словарь терминов ИБ) Аллокатор
(Словарь терминов ИБ) Отладочный аллокатор
(Словарь терминов ИБ) Поверхность атаки
(Словарь терминов ИБ) Санитайзер
(Словарь терминов ИБ) Фаззинг
(Словарь терминов ИБ) КИИ
(Словарь терминов ИБ) Объекты КИИ
(Словарь терминов ИБ) ФСТЭК
Поиск
Мы в соцсетях
Рассказываем об информационной безопасности и актуальных ИТ-решениях, делимся своими кейсами и новостями ИТ: Telegram-канал компании «Рубикон»
Дзен-канал компании «Рубикон»
Услуги

Подпишитесь на получение новостей

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

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

Принять