Разработка программного обеспечения для объектов КИИ: что надо знать

Разработка программного обеспечения для объектов КИИ: что надо знать

Процесс разработки ПО для объектов КИИ должен соответствовать Приказу ФСТЭК РФ № 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 - внедрить автоматизированные проверки безопасности в процесс разработки ПО. Так можно обеспечить не только быстрое создание и доставку на рынок безопасных приложений, но также соблюсти требования регламентирующих документов.
ЗО КИИ КИИ программное обеспечение защита критической инфраструктуры энергетический комплекс защита данных безопасная разработка
Alt text
Обращаем внимание, что все материалы в этом блоге представляют личное мнение их авторов. Редакция SecurityLab.ru не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.

Наш контент расширяется быстрее Вселенной!

Большой взрыв знаний каждый день в вашем телефоне

Подпишитесь, пока мы не вышли за горизонт событий

rcngroup

Компания «Рубикон» — IT-предприятие, основное направление деятельности которого – информационная безопасность. Мы занимаемся решением задач по аудиту, созданию и оптимизации IT-инфраструктур.