Оглавление
Есть несколько типовых вопросов, регулярно поступающих со стороны организаций и частных лиц, столкнувшихся с современной сертификацией на соответствие требованиям ФСТЭК России. Не всегда специалисты получают на них простые ответы, и не всегда эти ответы даются на языке, понятном инженеру-разработчику. Зачастую именно это становится причиной нагнетания атмосферы секретности, непонимания системности подхода и стратегического курса регулятора, недоверия к тому, что отечественный регулятор может активно и деятельно способствовать развитию и внедрению лучших практик безопасной и качественной разработки ПО.
Автор: Дмитрий Пономарев, заместитель генерального директора – директор департамента внедрения и развития РБПО НТЦ “Фобос-НТ”, сотрудник ИСП РАН, преподаватель МГТУ им. Н.Э. Баумана
Крайними в этом случае зачастую оказываются эксперты испытательных лабораторий (ИЛ) – в такой ситуации оказался и я сам пять лет назад.
В этой статье совместно с редакцией журнала “Информационная безопасность” мы постараемся ответить на типовые вопросы к эксперту ИЛ и развеять несколько наиболее популярных мифов.
Сертификация – это длительный и неинтересный процесс, направленный на прохождение множества бюрократических этапов и не связанный с реальной безопасностью.
За последние пять лет система сертификации СЗИ претерпела колоссальные изменения, практически сменив свой вектор, и продолжает активно развиваться. Если вы проходили испытания до 2019 г., или даже до 2023 г., скорее всего вы будете сильно удивлены числу произошедших перемен и их объему.
Выход новой нормативки, в частности приказа № 76 “Требования по безопасности информации…” и Методики ВУ и НДВ (издание второе, доработанное), сместил основной фокус с проверки “бумаг” и функционала на анализ процессов безопасной разработки (Application Security) и их результатов в отношении сертифицируемого СЗИ. Это не означает, что наличие полных и корректных документальных свидетельств или подтверждение выполнения функций безопасности перестало быть важным. Это означает, что в общем объеме задач сертификации задачи и проверки из области безопасной разработки играют не меньшую роль, а “бумажные” артефакты в первую очередь должны подчеркивать глубину и качество выполнения требований к безопасной разработке и не изготавливаться ради себя самих, как отписки в рамках “бумажной” безопасности.
Подтверждение этих тезисов можно найти в публичных выступлениях руководителей ФСТЭК России и представителей Института системного программирования РАН им. В.П. Иванникова на открытых конференциях, в первую очередь на ТБ Форуме 2024 [1].
Что, кроме дополнительной нагрузки, может привнести Методика ВУ и НДВ ФСТЭК России в компании с уже сформированными командами DevSecOps?
Методика ВУ и НДВ – это постоянно развивающийся документ (в настоящий момент он имеет пометку “ДСП”), определяющий инструменты и методики анализа, применяемые в ходе испытаний, а также качество артефактов, подтверждающих выполнение проверок.
Некоторое представление об этом документе вы можете получить, посмотрев выступления на ТБ Форуме 2023 [2] и OFFZONE 2023 [3] или поинтересовавшись у вашей ИЛ, если вы работаете в компании – лицензиате ФСТЭК России.
Типовые DevSecOps-процессы, как правило, сконцентрированы вокруг таких практик, как:
композиционный анализ, переиспользование бинарных компонентов и образов контейнеров;
веб-тестирование на проникновение;
базовый статический анализ собственных компонентов;
а также вопросов безопасной настройки kubernetes-кластеров для программных решений в k8s-исполнении.
Требования Методики значительно более глубокие. Значимый акцент делается на различные виды инструментирующего фаззинга, применение датчиков срабатывания ошибок (аллокаторов, санитайзеров) в динамике, углубленный статический анализ, анализ утечек помеченных данных, харденинг параметров компиляции и иные техники, нечасто применяемые в базовом 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 – это самая эффективная проверка на безопасность и что стоит заменить ей систему сертификации.
Bug Bounty, бесспорно, интересная практика, и лично я делаю ставку на то, что в среднесрочной перспективе она пополнит набор практик, требуемых либо рекомендуемых регулятором.
Тем не менее не все типы продуктов подходят для Bug Bounty, в том числе по причине сложности развертывания стендов, а также воспроизведения разработчиком найденных частным исследователем проблем: сложность протокола взаимодействия ограничивает область применения.
Принципиальная разница № 1.
Bug Bounty – это в первую очередь blackbox-тестирование, а сертификация – whitebox. Однако далеко не все серьезные разработчики готовы делиться своими исходными кодами с внешними экспертами. Являясь сотрудником испытательной лаборатории, имеющим доступ к исходникам непосредственно по сертификационному “законодательству”, я периодически сталкиваюсь с нежеланием команд допускать кого-либо со стороны к важным частям кода. Разумеется, в конечном итоге вопрос всегда решается положительно, но только по причине того, что наличие сертификата соответствия – это прямая необходимость для продаж сертифицируемого ПО. Bug Bounty же – это в конечном итоге “про тестирование” и денег само по себе не приносит, поэтому такими компаниями риски возможной утечки исходников расцениваются как неприемлемые. Однако без наличия исходников и доступа к сборочной среде возможности исследователя по выявлению дефектов кода кратно сокращаются.
Принципиальная разница № 2.
Bug Bounty – это в первую очередь про нарушителя, а сертификация, и тем более внедрение процессов РБПО, – это в первую очередь про трансформацию культуры разработки в сторону Test, Security First. Чем качественнее и безошибочнее пишется код, чем более РБПО-ориентированы сотрудники компании, тем меньше шансов в конечном итоге у любого исследователя Bug Bounty.
https://www.tbforum.ru/2024/program/information-security
https://www.tbforum.ru/2023/program/information-security
https://www.youtube.com/watch?v=Kt9t_poXttI
https://portal.linuxtesting.ru/news.html#main
https://t.me/sdl_community/4859
https://www.tbforum.ru/2024/program/rbpo
ITSec_articles