Автор: Дмитрий Пономарев, заместитель генерального директора – директор департамента внедрения и развития РБПО НТЦ “Фобос-НТ”, сотрудник ИСП РАН, преподаватель МГТУ им. Н.Э. Баумана
Крайними в этом случае зачастую оказываются эксперты испытательных лабораторий (ИЛ) – в такой ситуации оказался и я сам пять лет назад.
В этой статье совместно с редакцией журнала "Информационная безопасность" мы постараемся ответить на типовые вопросы к эксперту ИЛ и развеять несколько наиболее популярных мифов.
За последние пять лет система сертификации СЗИ претерпела колоссальные изменения, практически сменив свой вектор, и продолжает активно развиваться. Если вы проходили испытания до 2019 г., или даже до 2023 г., скорее всего вы будете сильно удивлены числу произошедших перемен и их объему.
Выход новой нормативки, в частности приказа № 76 "Требования по безопасности информации..." и Методики ВУ и НДВ (издание второе, доработанное), сместил основной фокус с проверки "бумаг" и функционала на анализ процессов безопасной разработки (Application Security) и их результатов в отношении сертифицируемого СЗИ. Это не означает, что наличие полных и корректных документальных свидетельств или подтверждение выполнения функций безопасности перестало быть важным. Это означает, что в общем объеме задач сертификации задачи и проверки из области безопасной разработки играют не меньшую роль, а "бумажные" артефакты в первую очередь должны подчеркивать глубину и качество выполнения требований к безопасной разработке и не изготавливаться ради себя самих, как отписки в рамках "бумажной" безопасности.
Подтверждение этих тезисов можно найти в публичных выступлениях руководителей ФСТЭК России и представителей Института системного программирования РАН им. В.П. Иванникова на открытых конференциях, в первую очередь на ТБ Форуме 2024 [1].
Методика ВУ и НДВ – это постоянно развивающийся документ (в настоящий момент он имеет пометку "ДСП"), определяющий инструменты и методики анализа, применяемые в ходе испытаний, а также качество артефактов, подтверждающих выполнение проверок.
Некоторое представление об этом документе вы можете получить, посмотрев выступления на ТБ Форуме 2023 [2] и OFFZONE 2023 [3] или поинтересовавшись у вашей ИЛ, если вы работаете в компании – лицензиате ФСТЭК России.
Типовые DevSecOps-процессы, как правило, сконцентрированы вокруг таких практик, как:
Требования Методики значительно более глубокие. Значимый акцент делается на различные виды инструментирующего фаззинга, применение датчиков срабатывания ошибок (аллокаторов, санитайзеров) в динамике, углубленный статический анализ, анализ утечек помеченных данных, харденинг параметров компиляции и иные техники, нечасто применяемые в базовом DevSecOps-процессе малой и даже средней компании.
Особое внимание уделяется определению поверхности атаки. Методика ее определения является значительно более глубокой, нежели простое сканирование портов или анализ логов strace, и требует определения конкретных функций, обрабатывающих данные, поступающие от потенциального нарушителя.
Работы в соответствии с Методикой ориентированы на обеспечение уровня анализа, позволяющего искать дефекты, потенциально способные стать уязвимостями нулевого дня, а не только на устранение уже известных уязвимостей и слабостей конфигураций.
Одно из типовых заблуждений заключается в том, что для выстраивания процессов безопасной разработки, соответствующих требованиям Методики ФСТЭК России, все инструменты должны быть сертифицированы.
В настоящее время такие требования точно не применяются к статическим анализаторам и большинству инструментов динамического анализа. В то же время, с учетом недавно введенных в действие ГОСТ Р 71207–2024 "Статический анализ программного обеспечения. Общие требования" и ГОСТ Р 71206–2024 "Безопасный компилятор языков С/С++", а также разрабатываемых стандартов динамического и композиционного анализа, лично я предполагаю, что уже в среднесрочной перспективе мы увидим требования необходимости соответствия инструментов данным стандартам.
Наличие требования к сертифицированности средства поиска уязвимостей не мешает применять и иные инструменты. Основная цель этого требования – обеспечение поддержки связи с БДУ ФСТЭК, которая сейчас активно развивается и пополняется. В любом случае данные средства, если не покупать наиболее дорогие их варианты, составляют меньшую долю от общей стоимости требуемых инструментов обеспечения процессов РБПО. К тому же нормативка на то и нормативка, чтобы меняться с некоторым временным отставанием от лучших практик, в том числе в такой сфере, как сертификация, требующей определенной стабильности "интерфейсов" и правил. Плановое изменение регулятором перечня средств анализа для ИЛ и разработчиков-лицензиатов ожидается в начале июня.
Кстати, расчет контрольных сумм можно осуществлять средствами из состава сертифицированной ОС, которые являются средой функционирования для вашего сертифицированного СЗИ.
Полностью согласен с тем, что попытка проанализировать весь объем компонентов, с учетом сторонних компонентов с открытым исходным кодом, в рамках одной конкретной сертификации – это мартышкин труд, и ничего, кроме негатива со стороны разработчиков в отношении регулятора, он не приносит.
Именно для этой цели ФСТЭК России, совместно с ИСП РАН, и создала в 2021 г. Центр исследования безопасности системного ПО [4].
За три года работы Центра более 315 патчей отдано в апстрим ядра Linux. Сопоставимое число также отдано по интерпретаторам и иным пакетам, таким как OpenSSL, nginx и др.
В деятельности Центра участвует более 30 крупнейших отечественных разработчиков: операционщики ("Альт", "Группа Астра", "Открытая мобильная платформа"), "Лаборатория Касперского", "Базис", "Сбертех" и многие другие. Новые участники регулярно вступают в консорциум Центра. Это уникальный пример совместной работы бизнес-конкурентов в зоне неконкурентности – для повышения безопасности и качества открытого кода, который в чистом виде никто не продает. Продаются лишь конечные бизнес-решения, созданные на базе открытого кода.
Однако даже Центр не сможет помочь наноразработчику, который решит произвести и продать очередного монстра из Linux-ядра и 500 пакетов с GitHub. Важнейший принцип регулятора – "весь код – это ваш код", если только вы не переиспользуете код из состава сертифицированных СЗИ, например ОС. Необходимо соизмерять собственные возможности по обеспечению процессов безопасной разработки, прежде, чем замахиваться на очередной контракт.
Под эгидой ФСТЭК России и ИСП РАН создано и развивается сообщество безопасной разработки. В него входят представители различных компаний, от мелких до по-настоящему крупных.
У сообщества есть активные telegram-ресурсы [5]. Важным является то, что это не просто однонаправленные каналы, а именно чаты, где мы обсуждаем инструменты и методики, где опытные участники делятся своими знаниями с новичками. Интересный факт: данные ресурсы были созданы под эгидой партнерства ФСТЭК России и ИСП РАН и с прямой поддержкой службы еще во времена блокировок Telegram в России.
Мы регулярно проводим встречи [6] в составе от 10 до 300 человек в Москве, Санкт-Петербурге и других городах, участвуем в вебинарах. Даже эта статья является активностью в рамках нашего сообщества.
Основной фокус сообщества – это не Vulnerabilty Management, не общий отечественный Compliance, не различные варианты пентеста и даже не "бумажное" выстраивание процессов РБПО, а именно формирование/возрождение инженерной культуры безопасной и качественной разработки, основанной на понимании "истоков": как изначально писать качественный код; какой код порождается компилятором; как сделать код безопасным, в том числе в конкретных средах выполнения; как инструментировать код для различных динамических исследований и многое другое.
Основным достоянием сообщества являются люди: конкретные эксперты, владельцы компаний, руководители направлений, опытные спикеры и просто хорошие ребята, которые делают ставку на то, что безопасная и качественная "от истоков" разработка – это конкурентное преимущество XXI века, это интересная и важнейшая часть отечественных систем сертификации и их будущее.
Bug Bounty, бесспорно, интересная практика, и лично я делаю ставку на то, что в среднесрочной перспективе она пополнит набор практик, требуемых либо рекомендуемых регулятором.
Тем не менее не все типы продуктов подходят для Bug Bounty, в том числе по причине сложности развертывания стендов, а также воспроизведения разработчиком найденных частным исследователем проблем: сложность протокола взаимодействия ограничивает область применения.
Принципиальная разница № 1.
Bug Bounty – это в первую очередь blackbox-тестирование, а сертификация – whitebox. Однако далеко не все серьезные разработчики готовы делиться своими исходными кодами с внешними экспертами. Являясь сотрудником испытательной лаборатории, имеющим доступ к исходникам непосредственно по сертификационному "законодательству", я периодически сталкиваюсь с нежеланием команд допускать кого-либо со стороны к важным частям кода. Разумеется, в конечном итоге вопрос всегда решается положительно, но только по причине того, что наличие сертификата соответствия – это прямая необходимость для продаж сертифицируемого ПО. Bug Bounty же – это в конечном итоге "про тестирование" и денег само по себе не приносит, поэтому такими компаниями риски возможной утечки исходников расцениваются как неприемлемые. Однако без наличия исходников и доступа к сборочной среде возможности исследователя по выявлению дефектов кода кратно сокращаются.
Принципиальная разница № 2.
Bug Bounty – это в первую очередь про нарушителя, а сертификация, и тем более внедрение процессов РБПО, – это в первую очередь про трансформацию культуры разработки в сторону Test, Security First. Чем качественнее и безошибочнее пишется код, чем более РБПО-ориентированы сотрудники компании, тем меньше шансов в конечном итоге у любого исследователя Bug Bounty.