

Введение: что есть в области регулирования РБПО
Практика РБПО давно вышла за рамки традиционного DevOps с интегрированной безопасностью. Сегодня это уже полноценная идеология, в которой безопасность выступает как правило хорошего тона, часть этикета и гигиены.
В эволюционном развитии такого подхода всё происходит по классическим законам экономики: спрос рождает предложение. Если ранее большинство экспертов фокусировались на анализе кода, то сейчас мировоззрение меняется, и в поле зрения попадают и те аспекты, которые требуют проведения ИБ-проверок — от проектирования архитектуры и бизнес-логики до харденинга инфраструктуры и анализа цепочки поставок ПО. Может ли система изначально быть идеальной, или жизненные циклы создания ПО таковы, что хороший результат можно достичь только при комплексном применении всех практик безопасной разработки?
С таким широким запросом на спектр практик мы обращаемся к регуляторике и изучаем, что уже существует в этой области. Порой эксперты не замечают требования, если напрямую не указано: «Чтобы построить РБПО — делай раз, два, три». А по сути, если знать, из чего состоит РБПО и в каких документах оно описано, то можно найти множество регуляторных требований и рекомендаций о том, как правильно выстраивать процессы.
Итак, посмотрим.
Наши основные регуляторы в данном вопросе — ФСТЭК России и Банк России. Есть ещё отраслевые требования, но они, как правило, издаются как ответвление к основным, например, требования Минцифры России к госсистемам, размещаемым на ЕЦП «ГосТех», или требования Минэнерго к объектам электроэнергетики.
Помимо регуляторных, есть требования, утверждаемые президентом, — федеральные законы, указы.
Также существуют документы общего рекомендательного характера — ГОСТы (они являются рекомендательными до момента, пока о необходимости их исполнения не будет сказано в обязательных к исполнению документах).
Кроме «источника» нормативного документа, регулирование можно также классифицировать по отраслям. Обычно специалисты по ИБ именно так и формулируют свой запрос, так как решают задачу по защите объектов в конкретной сфере экономики.
Можно выделить несколько ключевых направлений регулирования: для финтеха (кредитные и некредитные организации и ряд других организационно-правовых форм в финансовой сфере), для объектов КИИ (критической информационной инфраструктуры), для ГИС (государственных информационных систем), для информационных систем обработки ПДн (персональных данных).
Важно отметить, что одна сфера регулирования не исключает другую и при выборе набора требований необходимо знать всё об объекте — его бизнес-задачи, обрабатываемые данные и их объём, нюансы взаимодействия с внешними системами и многие другие аспекты. Может получиться так, что в отношении объекта нужно принимать меры защиты и для финтеха, и для КИИ, и для ПДн, и для ГИС.
Иногда компании планируют сертифицировать свои программные продукты во ФСТЭК России, и этот процесс предполагает проверку внедрения процедур безопасной разработки ПО.
Также важна информация о том, где будут размещаться вычислительные ресурсы. Если объект будет работать на платформе ГосТех, то для ГИС необходимо будет соблюдать не только требования ФСТЭК России, но и Минцифры РФ.
Таким образом, для специалистов по безопасности нет единого универсального набора регуляторных требований — это всегда набор, формирующийся из особенностей защищаемого объекта.
Из описанного выше можно предложить некоторый алгоритм выбора требований из всего множества:
Основная часть: ретроспектива — что было и есть в НПА РБПО
Теперь рассмотрим конкретные упоминания РБПО в регуляторике.
Общие нормы, которые применимы или могут быть опционально применимы к любой отрасли:
Нормы для субъектов критической информационной инфраструктуры (КИИ):
Нормы для систем обработки персональных данных:
Нормы для финтеха:
Предметные нормы для сферы энергетики:
Требования для государственных информационных систем:
Что будет меняться?
Указом от 18.06.2024 № 529 Президент России определил приоритетные направления научно-технологического развития и перечень важнейших наукоёмких технологий. «Безопасность получения, хранения, передачи и обработки информации» определена как приоритет научно-технологического развития, а в числе важнейших наукоёмких технологий мы видим «технологии создания доверенного и защищённого системного и прикладного программного обеспечения». Таким образом речь идёт о стратегическом направлении развития нашей страны, в котором РПБО занимает важное место.
Изменения происходят во всех сферах.
Произошедшее уже изменение — это пересмотр в полном объёме базового ГОСТ Р 56939–2024. Вместо 9 мер по разработке безопасного ПО, которые были с 2016 года, вводится 25 мер, которые в сумме содержат более 100 требований к процессу РБПО.
Среди нового перечня мер выделяются те, которые, как правило, требуют экспертных компетенций в области безопасной разработки: экспертиза и статистический анализ исходного кода, динамический анализ кода программы, использование безопасной системы сборки программного обеспечения, обеспечение безопасности используемых секретов, проверка кода на предмет внедрения вредоносного ПО через цепочки поставок и ряд других.
В развитие ГОСТ 56939-2024 сейчас ФСТЭК и экспертное сообщество ведут работу над разработкой ГОСТ по методике оценке уровня реализации процессов разработки безопасного ПО. Данным ГОСТ планируется зафиксировать подходы к оценке соответствия процессов ГОСТ 56939.
Еще в скором времени ФСТЭК планирует выпустить ГОСТ по композиционному анализу ПО, в котором будут описаны и процессы, и требования к инструментам, и требования по формированию перечня программным компонентов (перечень зависимостей, библиотек и других элементов, имеющих отношение к продукту).
В новой редакции ФСТЭК России планирует выпустить приказ от 11.02.2013 № 17 (проект изменений опубликован на сайте ФСТЭК России 08.08.2024) о защите информации в госсистемах. Положения о внедрении практик безопасной разработки добавлены в явном, акцентированном виде. В частности, не допускается использование ПО без проведения работ по экспертизе, тестированию и (или) исследованиям исходного кода, в том числе без проведения статического и динамического анализа кода программ, а также композиционного анализа программного обеспечения.
Также важно, что регулятор планирует утвердить эти требования не только для систем в статусе ГИС, но и в целом для всех объектов, которые эксплуатируют госорганизации.
Также и Банк России планирует пересмотреть положения № 821-П и № 757-П. Операторы по переводу денежных средств, банковские платёжные агенты (субагенты), некредитные финансовые организации получат право не проводить контроль каждой версии ПО, если они имеют «заключение проверяющей организации о том, что реализуемые процессы разработки программного обеспечения и приложений включают меры обеспечения безопасного жизненного цикла разработки программного обеспечения и приложений». То есть безопасная разработка позволит избежать контроля ПО (в том числе, если это объект КИИ, судя по действующим проектам новых редакций положений) — это достаточно революционный подход.
Такой же концептуально новый подход ФСТЭК России уже утвердила в 2023 году приказом № 240, в котором допускается вместо сертификации новых версий СрЗИ иметь сертифицированный процесс разработки этого СрЗИ.
Также, думаю, и с принятием закона «об оборотных штрафах» за утечки ПДн всё больше внимания будет уделяться безопасности ПО, обрабатывающего ПДн.
Топ‑3 ключевых тренда
Какие тренды безопасной разработки в России можно выделить с учетом вектора развития регуляторики:
1. Импортозамещение и доверие. Open Source по-прежнему популярен, но в современных реалиях для критических сфер в российской экономике использовать его небезопасно (недавний прецедент с ядром Linux яркий тому пример), и наблюдается тренд перехода на отечественные решения и инструменты для реализации и автоматизации практик РБПО.
2. Повышение компетенций ИТ-специалистов. Относится к разработчикам, ИБ-специалистам, сетевикам и всем, кто обеспечивает эксплуатацию объекта, для которого внедряется РБПО.
Этот тренд, как результат осознанного перехода к концепции Secure by Design, свидетельствует и о максимальном «смещении влево» в обеспечении безопасности программных продуктов компаний.
3. Применение ИИ и машинного обучения. Использование технологий доверенного искусственного интеллекта для выявления уязвимостей, анализа поведения приложений и предотвращения атак. Машинное обучение помогает в прогнозировании угроз и автоматизации процессов тестирования на безопасность.
Ключевое слово тут «доверенный» — применением ИИ сейчас никого не удивишь, но можем ли мы на 100 % довериться ему в защите своих критических ресурсов? Подходы и принципы «доверия» к ИИ, а также регулирование этой технологии сейчас являются практически основной повесткой всех дискуссий профессионального сообщества.
Заключение: нормативно-правовое регулирование РБПО — необходимо для обеспечения киберустойчивости
Очень часто от регуляторики требуют меньше бюрократии, бумажной безопасности и больше практической пользы, описанной лаконично, просто и с конкретным набором действий.
Но, по сути, наши регуляторы уже давно уделяют этому много внимания, выпуская пояснения, методические материалы, да и в целом отвечая на прямые вопросы офлайн или онлайн, а также привлекая профессионалов и экспертов из коммерческих организаций для совместной работы над регуляторикой.
Безопасность всегда была и остаётся процессом, только сейчас точка старта смещается влево у всё большего числа компаний, а не только у крупнейших корпораций.
Государство в лице регуляторов задаёт и корректирует вектор развития процессов и технологий разработки безопасного ПО, помогая сохранить баланс между скоростью выпуска программных продуктов в эксплуатацию и защищённостью чувствительной информации.
Реклама. ООО «СВОРДФИШ СЕКЬЮРИТИ», ИНН: 7842496093, Erid: 2Vfnxx9sHfv
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных