Регуляторика РБПО. Часть 3 – Требования к КИИ (и немного ASPM)

Доброго дня, уважаемые!

Идём по плану и сегодня делаем обзор требований регуляторики к практикам разработки безопасного ПО (РБПО) для отраслей, относящихся к критической информационной инфраструктуре. Такой регуляторики немного, пройдемся быстро.

Ранее мы уже рассмотрели общие требования по РБПО и условия для финансовой отрасли. В следующих двух обзорных статьях поговорим про ИСПДн, ГИС, отраслевые требования, ответственность и тренды, а также приведем немного инфографики в виде майндкарт по всей регуляторике.

Начнем как обычно с синхронизации по терминологии

Какие отрасли относятся к КИИ?

Ст.2 ФЗ № 187-ФЗ

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

здравоохранения,

науки,

транспорта,

связи,

энергетики,

государственной регистрации прав на недвижимое имущество и сделок с ним,

банковской сфере и иных сферах финансового рынка,

топливно-энергетического комплекса,

в области атомной энергии,

оборонной,

 ракетно-космической,

горнодобывающей,

металлургической

и химической промышленности,

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

(Последние строки очень важны — в сообществе любителей КИИ постоянные холивары на тему того, кто же «обеспечивает взаимодействие», но прямого ответа на этот вопрос так и нет. Могу предположить, что при необходимости в это пространство для творческой интерпретации могут подойти все, кто нужен – от интегратора, который обеспечивает эксплуатацию и, возможно, в ходе нее интеграцию/взаимодействие КИИ с другими объектами КИИ, до разработчика, который создает/развивает объект, который станет/является КИИ и имеет связь с другим объектом КИИ).

Обратите внимание, если вы в «банковской сфере и иных сферах финансового рынка», то кроме требований Банка России вам нужно смотреть и на требования к КИИ.

Смотрим!

Общие обязательные требования

1. Указ Президента от 01.05.2022 № 250 О дополнительных мерах по обеспечению информационной безопасности Российской Федерации

Указ распространяется на органы власти, предприятия с государственным участием, субъекты критической информационной инфраструктуры (КИИ), стратегические и системообразующие организации.

Что по практикам безопасной разработки?

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

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

2. Федеральный закон от 26.07.2017 № 187-ФЗ О безопасности критической информационной инфраструктуры Российской Федерации

Закон регулирует отношения в области обеспечения безопасности КИИ.

Требования по безопасной разработке следуют из (далее выдержки):

Статьи 10 «Система безопасности значимого объекта критической информационной инфраструктуры», а именно:

п.2. Основными задачами системы безопасности значимого объекта критической информационной инфраструктуры являются:

1) предотвращение неправомерного доступа к информации, обрабатываемой значимым объектом критической информационной инфраструктуры, уничтожения такой информации, ее модифицирования, блокирования, копирования, предоставления и распространения, а также иных неправомерных действий в отношении такой информации;

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

Статьи 11 «Требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры», а именно в соответствии с требованиями должно быть предусмотрено:

1) планирование, разработка, совершенствование и осуществление внедрения мероприятий по обеспечению безопасности значимых объектов критической информационной инфраструктуры;

2) принятие организационных и технических мер для обеспечения безопасности значимых объектов критической информационной инфраструктуры;

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

Статьи 12 «Оценка безопасности критической информационной инфраструктуры», а именно:

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

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

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

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

Что по РБПО (далее выдержки):

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

а) выявление источников угроз безопасности информации и оценку возможностей (потенциала) внешних и внутренних нарушителей;

б) анализ возможных уязвимостей автоматизированной системы и входящих в ее состав программных и программно-аппаратных средств;

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

Внедрение системы защиты автоматизированной системы управления осуществляется в соответствии с проектной и эксплуатационной документацией на систему защиты информации автоматизированной системы управления и в том числе включает:

анализ уязвимостей автоматизированной системы управления и принятие мер по их устранению;

П. 15.2. Разрабатываемые организационно-распорядительные документы по защите информации должны определять правила и процедуры (политики):

анализа угроз безопасности информации в автоматизированной системе управления и рисков от их реализации;

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

П. 16.4. В ходе анализа угроз безопасности информации в автоматизированной системе управления и возможных рисков от их реализации осуществляются:

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

Дополнительно в мерах защиты информации содержатся:

III. Ограничение программной среды (ОПС)

V. Аудит безопасности (АУД)

VIII. Обеспечение целостности (ОЦЛ)

XIV. Управление обновлениями программного обеспечения (ОПО)

4. Приказ ФСТЭК России от 25.12.2017 № 239 Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации

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

Где там РБПО (далее выдержки):

П.11.2. В случае, если в ходе проектирования подсистемы безопасности значимого объекта предусмотрена разработка программного обеспечения, в том числе программного обеспечения средств защиты информации, такая разработка проводится в соответствии со стандартами безопасной разработки программного обеспечения.

П.12.6. Анализ уязвимостей значимого объекта проводится в целях выявления недостатков (слабостей) в подсистеме безопасности значимого объекта и оценки возможности их использования для реализации угроз безопасности информации. При этом анализу подлежат уязвимости кода, конфигурации и архитектуры значимого объекта.

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

При проведении анализа уязвимостей применяются следующие способы их выявления:

а) анализ проектной, рабочей (эксплуатационной) документации и организационно-распорядительных документов по безопасности значимого объекта;

б) анализ настроек программных и программно-аппаратных средств, в том числе средств защиты информации, значимого объекта;

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

г) выявление известных уязвимостей программных и программно-аппаратных средств, в том числе средств защиты информации, сетевых служб, доступных для сетевого взаимодействия, с применением средств контроля (анализа) защищенности;

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

Применение способов и средств выявления уязвимостей осуществляется субъектом критической информационной инфраструктуры с учетом особенностей функционирования значимого объекта.

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

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

П.16. Задачами обеспечения безопасности значимого объекта являются:

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

б) недопущение информационного воздействия на программные и программно-аппаратные средства, в результате которого может быть нарушено и (или) прекращено функционирование значимого объекта;

в) обеспечение функционирования значимого объекта в проектных режимах его работы в условиях воздействия угроз безопасности информации;

г) обеспечение возможности восстановления функционирования значимого объекта критической информационной инфраструктуры.

П.22. В значимых объектах в зависимости от их категории значимости и угроз безопасности информации должны быть реализованы следующие организационные и технические меры (далее выдержка):

— ограничение программной среды (мера «ОПС»; Управление запуском (обращениями) компонентов программного обеспечения; Управление установкой (инсталляцией) компонентов программного обеспечения; Управление временными файлами);

— аудит безопасности (мера «АУД»; Анализ уязвимостей и их устранение);

— обеспечение целостности (мера «ОЦЛ»; Контроль целостности программного обеспечения);

— защита информационной (автоматизированной) системы и ее компонентов (мера «ЗИС»);

— управление обновлениями программного обеспечения (мера «ОПО»; Поиск, получение обновлений программного обеспечения от доверенного источника; Контроль целостности обновлений программного обеспечения; Тестирование обновлений программного обеспечения; Установка обновлений программного обеспечения).

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

29.3.1. Требования по безопасной разработке программного обеспечения:

— наличие руководства по безопасной разработке программного обеспечения;

— проведение анализа угроз безопасности информации программного обеспечения;

— наличие описания структуры программного обеспечения на уровне подсистем и результатов сопоставления функций программного обеспечения и интерфейсов, описанных в функциональной спецификации, с его подсистемами (для программного обеспечения, планируемого к применению в значимых объектах 1 категории значимости).

29.3.2. Требования к испытаниям по выявлению уязвимостей в программном обеспечении:

— проведение статического анализа исходного кода программы;

— проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей;

— проведение динамического анализа кода программы (для программного обеспечения, планируемого к применению в значимых объектах 1 категории значимости).

29.3.3. Требования к поддержке безопасности программного обеспечения:

— наличие процедур отслеживания и исправления обнаруженных ошибок и уязвимостей программного обеспечения;

— определение способов и сроков доведения разработчиком (производителем) программного обеспечения до его пользователей информации об уязвимостях программного обеспечения, о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения, способов получения пользователями программного обеспечения его обновлений, проверки их целостности и подлинности;

— наличие процедур информирования субъекта критической информационной инфраструктуры об окончании производства и (или) поддержки программного обеспечения (для программного обеспечения, планируемого к применению в значимых объектах 1 категории значимости).

29.4. Выполнение требований по безопасности, указанных в подпунктах 29.3.1 — 29.3.3 пункта 29.3 настоящих Требований, оценивается лицом, выполняющим работы по созданию (модернизации, реконструкции или ремонту) значимого объекта и (или) обеспечению его безопасности, на этапе проектирования значимого объекта на основе результатов анализа материалов и документов, представляемых разработчиком (производителем) программного обеспечения в соответствии с техническим заданием (частным техническим заданием), разрабатываемым в соответствии с пунктом 10 настоящих Требований.

Результаты оценки включаются в проектную документацию на значимый объект (подсистему безопасности значимого объекта) и представляются субъекту критической информационной инфраструктуры.

Опциональные обязательные требования

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

1. Приказ Минэнерго России от 26.12.2023 № 1215 Об утверждении дополнительных требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры, функционирующих в сфере электроэнергетики, при организации и осуществлении дистанционного управления технологическими режимами работы и эксплуатационным состоянием объектов электроэнергетики из диспетчерских центров субъекта оперативно-диспетчерского управления в электроэнергетике.

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

Приказ вступил в силу с 1 сентября 2024 года.

По РБПО (далее выдержки):

П.12. В отношении программного обеспечения, используемого для реализации дистанционного управления из диспетчерских центров, должны быть выполнены следующие требования поддержки безопасности программного обеспечения:

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

б) определение способов и сроков доведения организациями – разработчиками и (или) производителями программного обеспечения до его пользователей следующей информации:

об уязвимостях программного обеспечения;

о компенсирующих мерах по защите информации или ограничениях по применению программного обеспечения;

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

Завершение

Спасибо за внимание — мы перешли за экватор! Впереди еще 2 статьи, а дальше придумаем что-нибудь интересное для будущих обзоров, например, подробно рассмотрим порядок сертификации процессов РБПО, ведь уже утверждена новая редакция ГОСТ Р 56939-2024 (текст самого ГОСТ претерпел не принципиальные изменения относительно опубликованной ФСТЭК в июне версии (скоро опубликуют утвержденную версию).

Не забывайте, что в конце можно будет выиграть мерч, для этого нужно быть внимательными ко всем статьям этой серии (впереди еще две) 😊

Немного полезной визуализации

Чтобы разбавить сухой текст полезной графикой, покажу вам, как мы в Свордфиш в Альбоме РБПО 2025 наглядно визуализировали наложение практик оркестрации и корреляции (ASPM) на конвейер РБПО. Также наглядно видно, как в прогрессии может оказаться полезной автоматизация процессов управления и разбора результатов работы инструментов ИБ. Скоро коллеги опубликуют аналитические исследования на эту тему.

К чему это в статье о регуляторике — требований много, трактовки их еще больше, а по сути все сводится к «безопасно делай‑безопасно будет», и бонусом уже есть множество инструментов и практик ИБ, которые помогают реализовать эти самые требования, получается — не так страшно, как может показаться при первом касании.