РБПО-2024. Итоги и перспективы

РБПО-2024. Итоги и перспективы

                                            «РБПО — не для ФСТЭКа.

РБПО — для безопасности и качества вашего ПО».

            Представитель ФСТЭК России

Если задаться целью проанализировать, какие именно слова были наиболее популярными в 2024 году в области, связанной с разработкой и поддержкой программ и систем, акроним РБПО с высокой вероятностью займёт лидирующую позицию [1]. Бесспорно, никуда не делся, хотя и несколько снизил темпы маркетинговой экспансии «искусственный интеллект». Резкий всплеск внимания к термину NGFW — ​все стремятся «застолбить поляну», правила работы на которой ещё толком не определены. Всё больше внимания обращается на микросервисные программные решения: «облака», сервисы банков и маркетплейсов и даже средства защиты информации — ​в контейнерном исполнении, в том числе функционирующие в кластерах под управлением kubernetes.

Но все эти понятия и слова в итоге подразумевают под собой определённые типы и особенности эксплуатации ПО. А где ПО — ​там и необходимость его создания и поддержки. Качественно, безопасно, управляемо и, что немаловажно, в соответствии с парадигмой действующей и перспективной регуляторики. «Комплаенс» — ​мощнейший стимул становиться лучше, особенно в современных условиях стратегической турбулентности и уже никому не требующих доказательства фактов непрестанных атак на отечественную IT-инфраструктуру. При этом необходимо отметить: несмотря на все сложности последних лет, мы не находимся в уникальной ситуации. Рост рынка киберпреступности в мире оценивается в «триллионы рублей в год» [2], степень информатизации становится всё выше, а атаки — ​всё изощрённее.

Реакцией на давление киберпреступности — ​как «частной», так и инициируемой на уровне недружественных государств (не все APT-группировки только лишь «про деньги») — ​является рост системности и проработанности различных требований в области информационной безопасности и, как следствие, рост технологий, инструментов и методик РБПО, а также вовлечённого в эти процессы сообщества инженеров, экспертов, чиновников и руководителей. Все эти факторы приводят к трансформации отечественных рынков ИБ и ИТ в целом. Парадигма «Внедрённые процессы РБПО — ​показатель зрелости компании и бизнес-преимущество XXI века» становится всё более распространённой, а в ряде сегментов — ​безальтернативной. Развиваются имеющиеся и возникают новые классы инструментов анализа. Пресса и профильные конференции пестрят анонсами о важности РБПО и предложениями продуктов и услуг. Безотносительно к тому, написаны они заинтересованными специалистами-инженерами или «ванильными маркетологами» с целью набить цену собственной компании, информационный поток становится всё более значимым, и из «темы для избранных» вопросы РПБО за единицы лет стали настоящим мейнстримом.

Эта статья пополнит копилку материалов «по теме» и, надеемся, окажется полезной читателям. В ней я постарался осветить некоторые типовые вопросы, возникающие у разработчиков — ​лицензиатов ФСТЭК России — при внедрении инструментов и развитии практик РБПО и последующем выводе собственных решений на сертификацию. Материал можно рассматривать в качестве логического продолжения опубликованной в 2024 году статьи «6 мифов о безопасной разработке и сертификации ПО» [3].

Типовые «проблемы» заявителя

Примерно с 2020 года развитие отрасли создания средств защиты информации можно охарактеризовать в том числе следующими тезисами:

• растёт число лицензиатов ФСТЭК, равно как и число заявителей на сертификацию СЗИ;
• растёт число малых команд, приходящих на сертификацию с одним небольшим продуктом и имеющих околонулевой опыт в сертификации; при этом многие команды ничего не слышали о требованиях РБПО и считают, что сертификация — ​это «что-то записанное в контракт по остаточному принципу, сделаем за 3–6 месяцев, не напрягаясь»;
• всё больший процент кодовой базы СЗИ составляют компоненты с открытым исходным кодом; у некоторых решений он достигает 100 %, а на долю разработчика остаются компоновка, конфигурирование, маркетинг и поддержка;
• всё большую долю кодовой базы составляют интерпретируемые языки программирования/языки с «управляемой памятью» (Python, JS, C#, Java и так далее);
• более половины приходящих на сертификацию продуктов составляют «СЗИ в контейнерном исполнении [4]», выполняющиеся в контексте средств контейнеризации (в том числе оркестратора kubernetes).

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

• разработчик не умеет собирать своё решение из исходников, использует бинарные пресобранные компоненты из произвольных источников; нарушение базового принципа «весь код СЗИ === ваш код»;
• не ведётся контроль наличия уязвимых версий компонентов либо ведётся по остаточному принципу, поскольку: «их так много, мы же всё не поправим», «да оно не эксплуатируемо», «да наше ПО будет применяться только в доверенном контуре, никаких внутренних врагов нет»;
• у разработчика СЗИ в контейнерном исполнении, а значит: «у нас всё в контейнерах, значит, всё безопасно и вообще, упадёт — ​переподнимем», «что это вы такое придумали — ​контейнеры самому собирать и анализировать код компонентов… Это же Alpine с DockerHub, там всё отлично и безопасно»;
• разработчики СЗИ относятся к пакетной базе репозиториев отечественных сертифицированных ОС (~50 000 пакетов) так же, как к самому сертифицированному дистрибутиву (~300 пакетов): «разработчик ОС сказал, что в репе тоже всё доверенное, берите, чего в дистрибутиве не хватает».

Ещё одной типовой проблемой организации и контроля процессов РБПО является «разнобой» в используемых инструментах анализа, в том числе между разработчиками СЗИ и испытательными лабораториями. Часть разработчиков клюёт на активность маркетологов и приобретает за большие деньги «самый раскрученный», но не самый качественный инструмент, часть — ​принципиально экономит на платных инструментах, используя открытые, безотносительно к качеству их работы, зачастую только ради формального выполнения требования о проведении соответствующего вида анализа. Наиболее жаркие «дискуссии» в отрасли традиционно идут вокруг средств поиска известных уязвимостей и ошибок конфигурирования компонентов системы. Второе же место, бесспорно, принадлежит проблематике выбора инструментов статического анализа исходного кода. Данная практика анализа является широко распространённой и одной из базовых при построении процессов РБПО. Неслучайно требования ФСТЭК России к процессу статического анализа в части методики проведения сертификационных испытаний, равно как и в части комплектования испытательных лабораторий инструментами анализа, являются одними из наиболее проработанных.

Вышеуказанные факторы в совокупности с существенной разницей в компетенциях испытательных лабораторий, а также отсутствием прямых и конкретных разъяснений в нормативно-правовой базе по каждому возможному подвопросу (парадигма «писать рамочные требования — ​рассчитывать на сознательность и заинтересованность разработчика в безопасности и качестве», к сожалению, работает далеко не всегда) приводят к частому непониманию разработчиками СЗИ, «что именно, как и на какую глубину» требуется выполнить. Что, в свою очередь, порождает риски неопределённости для бизнеса, зависящие во многом от позиции конкретных экспертов, их персональных трактовок требований регулятора.

Актуализация регуляторики и сообщество РБПО

Ответом на вызовы времени явилось активное развитие в 2024 году нормативно-правовой базы ФСТЭК России. Ниже кратко описаны наиболее значимые изменения и сопровождавшие их события.

Информационным письмом «О порядке испытаний и поддержки безопасности средств защиты информации» изменён порядок исследования критичных компонентов с открытым исходным кодом при подготовке и проведении испытаний. При подаче заявки на сертификационные испытания заявители должны предоставить Перечень Программных Компонентов (ППК aka SBoM) в составе СЗИ и далее осуществлять их поддержку безопасности. Глубина и качество анализа компонентов, равно как и распределение нагрузки по анализу компонентов между разработчиками, определяются в рамках консорциума Центра исследований безопасности системного ПО ФСТЭК России и ИСП РАН [5].

Информационным письмом (от 25.10.2024) [6] уточнён порядок анализа компонентов, реализующих функции серверов приложений, веб-серверов и интерпретаторов. Функции безопасности данных компонентов должны быть корректно заявлены в формулярах СЗИ и проверены в ходе испытаний, при этом разработчик СЗИ должен сформулировать рекомендации по безопасной настройке указанных компонентов, а также минимизировать поверхность атаки на компонент посредством удаления из комплекта поставки функциональных возможностей, не предполагаемых к использованию. В первую очередь данные требования затрагивают разработчиков ОС, традиционно включающих в составы своих дистрибутивов значительное число таких компонентов [7].

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

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

Принятый в 2024 году ГОСТ Р 71207–2024 (статический анализ программного обеспечения) [8] фактически явился первым из целого семейства ГОСТ в области РБПО, запланированных к принятию в 2024–2026 годах. Одной из задач данного ГОСТа является регламентация процесса оценки качества инструмента статического анализа. Анонс испытаний отечественных статических анализаторов был сделан заместителем начальника 2 управления ФСТЭК России И.С.Гефнер [9] в ходе Открытой конференции ИСП РАН 11 декабря [10]. В настоящий момент осуществляется формирование жюри испытаний, комплекта тестов. К участию в испытаниях приглашаются все отечественные компании — ​разработчики статических анализаторов, а также заинтересованные участники сообщества. В качестве инфраструктурной основы организации тестирования предполагается использование наработок, полученных в рамках создания Унифицированной среды безопасной разработки ПО [11].

Сообщество РБПО центра компетенций ФСТЭК России и ИСП РАН [12] активно развивается и прирастает новыми участниками. Целями сообщества являются:

• популяризация системного, фундаментально-инженерного подхода к организации безопасной и качественной разработки и подготовке кадров;
• популяризация отечественных технологий и школ, в том числе в части лучших практик и регуляторики; поддержка и продвижение отечественной «культуры»;
• формирование «грибницы» доверенных, кросс-верифицированных горизонтальных связей. Ядро сообщества составляют «технари» (бизнесмены, инженеры, чиновники). В сообществе не приветствуется «маркетологическая маркетология».

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

Основные информационные ресурсы сообщества в «Телеграме», посвящённые вопросам инструментального анализа, объединения усилий по анализу разделяемой компонентной базы, организации просветительских мероприятий, превысили число в 1500 участников. Узнать подробности про семейство чатов сообщества вы можете, перейдя по ссылке [13].

Подводя итог

2024-й выдался чрезвычайно насыщенным на различные события в области ИТ, ИБ и регуляторики. «За скобками» статьи остались такие важнейшие для отрасли вопросы, как, например, сертификация процессов РБПО на соответствие обновлённому ГОСТ Р 56939–2024 или публикация проекта обновлений 17-го приказа и многие другие. Реальное влияние анонсированных и принятых решений в полной мере отрасль ощутит в 2025–2026 годах. Со своей стороны традиционно могу пожелать читателям всех рангов как можно скорее осознать безальтернативность парадигмы безопасной и качественной разработки ПО в современных реалиях, трансформации отечественной регуляторики в технологичный и полезный инженеру свод рекомендаций и требований, а также тезис о том, что «внедрённые процессы безопасной и качественной разработки — ​гарантия эффективного прохождения сертификационных испытаний и конкурентное преимущество XXI века»!

[1] Во время написания статьи вышел материал, не подтверждающий данную гипотезу для сферы ИT в целом. Тем не менее автор оставляет за собой право считать утверждение верным в отношении компаний-лицензиатов отечественных регуляторов.

[2] https://www.statista.com/hart/28878/expected-cost-of-cybercrime-until-2027/

[3] https://cs.groteck.com/IB_2_2024/60/    

[4] https://clck.ru/3GAsaP

[5] https://portal.linuxtesting.ru/index.html#regulations

[6] https://clck.ru/3GAsim

[7] https://clck.ru/3GAsaP

[8] https://protect.gost.ru/document1.aspx?control=31&baseC=6&page=3&month=2&year=2024&search=&id=257752

[9] https://t.me/sdl_community/7343

[10] https://www.isprasopen.ru/

[11] https://www.tbforum.ru/hubfs/Digital/SS/SS_ADAPT/TBF24_14-02-24_Падарян.pdf

[12] https://cs.groteck.com/IB_3_2023/40/

[13] https://t.me/sdl_community