Регуляторика РБПО. Часть 5 – Ответственность, взгляд в будущее, инфографика всего обзора

Приветы после долгого перерыва!

С вами Альбина Аскерова, руководитель направления по взаимодействию с регуляторами в Swordfish Security. Сегодня в завершающей статье по Регуляторике РБПО:

— напомним о применимой законодательной ответственности,

— расскажем, что сейчас в проектах у регуляторов на 2025 год, а что уже есть нового утвержденного,

— покажем майндкарты регуляторики.

В конце будет розыгрыш мерча, который обещали в 1 части 😊

Ранее были:

Часть 1 – Введение. Общие требования

Часть 2 – Требования в финансовой отрасли

Часть 3 – Требования к КИИ (и немного ASPM)

Часть 4 – Требования к ГИС, ИСПДн, отраслевые требования

Теперь к сути.

Законодательная ответственность (за невыполнение требований регуляторов)

Общее:

ст. 13.12 (ч.6) КоАП РФ (выдержка):

Нарушение требований (законодательных) о защите информации… влечет наложение административного штрафа на:

·         должностных лиц – от 1 000 до 2 000 рублей,

·         юридических лиц – от 10 000 до 15 000 рублей.

Внимание: ФСТЭК инициировал увеличение штрафов в несколько раз. Планируется, что должностное лицо за нарушение требований заплатит от 10 тыс. до 50 тыс. руб, а юридическое — от 50 тыс. до 100 тыс. руб.

Для КИИ:

ст. 13.12.1 (ч.1) КоАП РФ (выдержка):

Нарушение требований к созданию систем безопасности значимых объектов КИИ либо требований по обеспечению безопасности значимых объектов КИИ… влечет наложение административного штрафа на:

·         должностных лиц – от 10 000 до 50 000 рублей,

·         юридических лиц – от 50 000 до 100 000 рублей.

ст. 274.1 УК РФ (ч.3) (выдержка):

Нарушение правил эксплуатации… либо правил доступа, если оно повлекло причинение вреда критической информационной инфраструктуре Российской Федерации, наказывается принудительными работами на срок до 5 лет с лишением права занимать определенные должности или заниматься определенной деятельностью на срок до 3 лет или без такового, либо лишением свободы на срок до 6 лет с лишением права занимать определенные должности или заниматься определенной деятельностью на срок до 3 лет или без такового.

---

Взгляд в будущее

Какие есть публичные планы по изменению/разработке в регуляторике? И что уже есть новенького? Смотрим и читаем:

(В хорошем качестве скачать и посмотреть можно тут)

Планы по ГОСТ:

По публичным планам ФСТЭК России, только на 2025 год запланированы к выпуску следующие ГОСТы:

1. ГОСТ Защита информации. Разработка безопасного программного обеспечения. Композиционный анализ ПО

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

   Публично проект пока не размещен.

2. ГОСТ Защита информации. Системы с конструктивной информационной безопасностью. Методология разработки

   ГОСТ устанавливает требования к мерам безопасности программного обеспечения с начала его разработки. В обосновании разработки ГОСТ указано «Процесс создания систем, в ходе которого обеспечивается учет опыта блокирования и исправления известных (типовых) уязвимостей и ошибок, а также минимизация числа потенциальных (новых, неизвестных) уязвимостей и ошибок, упрощается за счет формирования и использования шаблонов проектирования и разработки».

   Проект размещен публично еще в прошлом году. Недавно мы в составе ТК 362 голосовали за направление проекта на утверждение. Возможно, в ближайшие пару месяцев ГОСТ выйдет в свет.

3. ГОСТ Защита информации. Доверенная среда исполнения. Общие требования

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

   Публично проект пока не размещен.

4. ГОСТ Защита информации. Разработка безопасного программного обеспечения. Динамический анализ программного обеспечения

   В ГОСТ будут установлены требования к средствам и методам динамического анализа ПО, а также исходным данным, необходимым для проведения динамического анализа программного обеспечения.

   Публично проект пока не размещен.

5. ГОСТ Защита информации. Разработка безопасного программного обеспечения. Методика оценки уровня реализации процессов разработки безопасного ПО

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

   Публично проект пока не размещен.

6. ГОСТ Защита информации. Разработка безопасного программного обеспечения. Руководство по внедрению процессов разработки безопасного ПО

   Планируется, что ГОСТ предложит детальное руководство по внедрению требований ГОСТ Р 56939-2024.

   Публично проект пока не размещен.

Планы ФСТЭК России:

1. Планируется полный пересмотр приказа № 17 по защите информации в ГИС

   В одной из версий проекта приказа добавлены в явном виде положения о внедрении практик безопасной разработки, например:

45. Мероприятия по разработке безопасного программного обеспечения должны быть направлены на предотвращение появления, выявление и устранение уязвимостей в разрабатываемом оператором программном обеспечении.

В случае самостоятельной разработки оператором программного обеспечения, предназначенного для использования в информационных системах, должны быть реализованы меры, предусмотренные разделом 5 ГОСТ Р 56939 -2024.

В случае разработки программного обеспечения подрядной организацией на основании заключенного с оператором договора по решению руководителя, ответственного лица допускается включение в техническое задание на разработку программного обеспечения требований по разработке безопасного программного обеспечения, предусмотренных разделом 5 ГОСТ Р 56939 -2024. Подтверждением выполнения подрядной организацией мер по разработке безопасного программного обеспечения является наличие у нее сертификата соответствия, выданного ФСТЭК России в соответствии с Порядком проведения сертификации процессов безопасной разработки программного обеспечения средств защиты информации, утвержденным приказом ФСТЭК России от 1 декабря 2023 г. № 240.

Кстати, интересно, что ФСТЭК последним предложением позволяет «заказчикам» требовать от подрядчиков сертификацию конвейера разработки, хотя в текущей редакции приказа № 240 он ориентирован только на разработку средств защиты информации. Видимо, будут внесены изменения в этот приказ.

p.s. Пока готовили статью к публикации появилась информация, что новый приказ уже утвержден во ФСТЭК от 11 апреля 2025 г. № 117 и сейчас находится на регистрации в Минюсте России. Ждем официального опубликования.

2. На ТБ-Форуме 2025 Елена Торбенко, начальник восьмого управления ФСТЭК России, говорила, что одни из типовых нарушений по защите объектов КИИ — это непроведение мероприятий по выявлению и анализу уязвимостей на значимых объектах КИИ и наличие уязвимого ПО на значимых объектах КИИ. Можно предположить, что в приказ № 239 тоже внесут больше требований по практикам безопасного ПО.

Планы Банка России (и утвержденные документы в 2025 году):

Тут будущее уже наступило. Банк России в январе 2025 года утвердил три новых документа, в которых есть требования по нашей теме.

1. Методические рекомендации от 22.01.2025 № 2-МР по проведению тестирования на проникновение и анализа уязвимостей информационной безопасности объектов информационной инфраструктуры организаций финансового рынка

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

Требования по проведению тестирования на проникновение и анализа уязвимостей детально расписаны по всему документу : в отношении каких объектов, с какой целью, какими методами.

Например, тестирование на проникновение и анализ уязвимостей, согласно методике, распространяется на следующие объекты:

веб-приложения дистанционного банковского обслуживания (далее — ДБО) физических лиц (далее — ФЛ);

веб-приложения ДБО юридических лиц (далее — ЮЛ);

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

мобильные приложения ДБО ФЛ для различных мобильных операционных систем;

мобильные приложения ДБО ЮЛ для различных мобильных операционных систем;

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

специализированные клиентские приложения ДБО ФЛ для различных операционных систем;

специализированные клиентские приложения ДБО ЮЛ для различных операционных систем;

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

автоматизированные системы, участвующие во взаимодействии с ДБО ФЛ или ЮЛ, в том числе интеграционные системы и API;

серверы приложений;

серверы систем управления базами данных.

2. Положение Банка России от 13.01.2025 N 850-П Об обязательных для кредитных организаций, иностранных банков, осуществляющих деятельность на территории Российской Федерации через свои филиалы, требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг

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

Положение выпущено взамен Положения Банка России № 787-П от 12.01.2022, которое мы рассматривали в прошлом году во 2-й части.

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

Документ применяется кредитными организациями.

Требования по безопасной разработке:

П.7.1. Кредитные организации в отношении элементов, являющихся значимыми объектами критической информационной инфраструктуры, должны выполнять требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры, установленные в соответствии с пунктом 4 части 3 статьи 6 Федерального закона от 26 июля 2017 года N 187-ФЗ.

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

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

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

3.Положение Банка России от 30.01.2025 N 851-П «Об установлении обязательных для кредитных организаций, иностранных банков, осуществляющих деятельность на территории Российской Федерации через свои филиалы, требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента»

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

Положение выпущено взамен Положения Банка России № 683-П от 17.04.2019, которое мы рассматривали в прошлом году во 2-й части.

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

Документ применяется кредитными организациями.

Требования по безопасной разработке:

П.3.1. Положения указывает на обязательное выполнение ГОСТ Р 57580.1-2017, в котором есть такие меры защиты как «контроль отсутствия известных (описанных) уязвимостей защиты информации объектов информатизации», «контроль размещения, хранения и обновления ПО информационной инфраструктуры», «контроль состава и целостности ПО информационной инфраструктуры» (Код мер – ЦЗИ.Х).

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

П.4.1. Положения: кредитные организации должны обеспечить использование для осуществления банковских операций прикладного программного обеспечения автоматизированных систем и приложений, распространяемых кредитной организацией клиентам для совершения действий в целях осуществления банковских операций, а также программного обеспечения, обрабатывающего защищаемую информацию на участках, используемых для приема электронных сообщений к исполнению в автоматизированных системах и приложениях с использованием информационно-телекоммуникационной сети «Интернет» (далее – сеть «Интернет»), прошедших сертификацию в системе сертификации Федеральной службы по техническому и экспортному контролю или оценку соответствия по требованиям к оценочному уровню доверия (далее – ОУД) не ниже чем ОУД 4.

При этом ОУД4 содержит обязательное требование по проведению анализа уязвимостей.

Из планов Банка России:

В прошлом году Банк России публиковал проекты изменений в 757-П (требования ИБ для некредитных организаций) и в 821-П (требования ИБ к кредитным организациям). Они были опубликованы одновременно, но позднее с сайта Банка России удалены. Сейчас в публичном пространстве их судьба не обсуждается.

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

Кажется, финтех очень давно ждет таких изменений и с радостью бы реализовал все процессы безопасной разработки у себя, что позволило бы избежать ОУД4, увеличенного Time-to-Market и прочих не очень приятных бизнесу историй.

Из планов Правительства:

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

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

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

---

Майндкарты регуляторики

Теперь перейдем к красивому и ужасному.

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

Для начала хочется показать всю действующую регуляторику, в которой хоть как-то упоминается РБПО, в формате временной ленты. Такой файл помог мне разложить для себя хронологию регулирования и определить последовательность, что и за чем шло в истории нашей регуляторики. Файл, что называется, «рабочий», практически раз в месяц вношу в него какие-то изменения. Помогает держать одной линией всё в фокусе внимания.

(В хорошем качестве скачать и посмотреть можно тут)

__

И еще полезная визуализация того же самого набора, но уже объединенного в блоки источников регулирования: ФЗ, ФСТЭК, ЦБ, ГОСТ, отраслевые регуляторы (Минэнерго). Нам такое нужно, потому что заказчики часто смешанные, когда ПО – это и финансы, и госсектор, и КИИ. Для вас это может быть полезно, если специальность сохраняете, но меняете прикладную часть, и переходите из, например, промышленности в банк:

(В хорошем качестве скачать и посмотреть можно тут)

__

А следующая с таким же наполнением, но в разрезе направлений/отраслей регулирования:

(В хорошем качестве скачать и посмотреть можно тут)

__

Тут не забываем, что всё может перемешаться, поэтому в завершении хочется напомнить то, что мы проходили в первой части — алгоритм подбора нужной регуляторики:

1. Отталкиваемся от объекта защиты:

   — оцениваем тип объекта (например, ДБО, ГИС, веб-приложение, мобильное приложение и т.д. или вообще всё вместе),

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

   — оцениваем тип обрабатываемых данных (например, есть/нет ПДн, попадает объект под ЗО КИИ).

2. Не забываем про общие обязательные требования, которые не зависят ни от чего вышеуказанного.

3. Не забываем про общие рекомендательные требования, которые не зависят ни от чего вышеуказанного.

4. Из всего этого готовим борщ РБПО под конкретную вашу задачу.

---

Ура, всё!

Теперь о приятном, о мерче!

В цикле статей есть пасхалочка – в большей части статей есть что-то, что объединяет их одной темой (и это не регуляторика, и не РБПО)))

Ваши варианты пишите мне в личку @AlbinaAskerova, за правильный ответ вас ждет подарок 😊

---

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