17 апреля
Материал директора департамента внедрения и развития РБПО НТЦ «Фобос-НТ» Дмитрия Пономарева для отраслевого портала InformationSecurity
Есть несколько типовых вопросов, регулярно поступающих со стороны организаций и частных лиц, столкнувшихся с современной сертификацией на соответствие требованиям ФСТЭК России. Не всегда специалисты получают на них простые ответы, и не всегда эти ответы даются на языке, понятном инженеру-разработчику. Зачастую именно это становится причиной нагнетания атмосферы секретности, непонимания системности подхода и стратегического курса регулятора, недоверия к тому, что отечественный регулятор может активно и деятельно способствовать развитию и внедрению лучших практик безопасной и качественной разработки ПО.
Крайними в этом случае зачастую оказываются эксперты испытательных лабораторий (ИЛ) – в такой ситуации оказался и я сам пять лет назад.
В этой статье совместно с редакцией журнала «Информационная безопасность» мы постараемся ответить на типовые вопросы к эксперту ИЛ и развеять несколько наиболее популярных мифов.
— Сертификация – это длительный и неинтересный процесс, направленный на прохождение множества бюрократических этапов и не связанный с реальной безопасностью.
За последние пять лет система сертификации СЗИ претерпела колоссальные изменения, практически сменив свой вектор, и продолжает активно развиваться. Если вы проходили испытания до 2019 г., или даже до 2023 г., скорее всего вы будете сильно удивлены числу произошедших перемен и их объему.
Выход новой нормативки, в частности приказа № 76 «Требования по безопасности информации…» и Методики ВУ и НДВ (издание второе, доработанное), сместил основной фокус с проверки «бумаг» и функционала на анализ процессов безопасной разработки (Application Security) и их результатов в отношении сертифицируемого СЗИ. Это не означает, что наличие полных и корректных документальных свидетельств или подтверждение выполнения функций безопасности перестало быть важным. Это означает, что в общем объеме задач сертификации задачи и проверки из области безопасной разработки играют не меньшую роль, а «бумажные» артефакты в первую очередь должны подчеркивать глубину и качество выполнения требований к безопасной разработке и не изготавливаться ради себя самих, как отписки в рамках «бумажной» безопасности.
Подтверждение этих тезисов можно найти в публичных выступлениях руководителей ФСТЭК России и представителей Института системного программирования РАН им. В.П. Иванникова на открытых конференциях, в первую очередь на ТБ Форуме 2024.
— Что, кроме дополнительной нагрузки, может привнести Методика ВУ и НДВ ФСТЭК России в компании с уже сформированными командами DevSecOps?
— Методика ВУ и НДВ – это постоянно развивающийся документ (в настоящий момент он имеет пометку «ДСП»), определяющий инструменты и методики анализа, применяемые в ходе испытаний, а также качество артефактов, подтверждающих выполнение проверок.
Некоторое представление об этом документе вы можете получить, посмотрев выступления на ТБ Форуме 2023 и OFFZONE 2023 или поинтересовавшись у вашей ИЛ, если вы работаете в компании – лицензиате ФСТЭК России.
Типовые DevSecOps-процессы, как правило, сконцентрированы вокруг таких практик, как:
— композиционный анализ, переиспользование бинарных компонентов и образов контейнеров;
— веб-тестирование на проникновение;
— базовый статический анализ собственных компонентов;
— а также вопросов безопасной настройки kubernetes-кластеров для программных решений в k8s-исполнении.
Требования Методики значительно более глубокие. Значимый акцент делается на различные виды инструментирующего фаззинга, применение датчиков срабатывания ошибок (аллокаторов, санитайзеров) в динамике, углубленный статический анализ, анализ утечек помеченных данных, харденинг параметров компиляции и иные техники, нечасто применяемые в базовом DevSecOps-процессе малой и даже средней компании.
Особое внимание уделяется определению поверхности атаки. Методика ее определения является значительно более глубокой, нежели простое сканирование портов или анализ логов strace, и требует определения конкретных функций, обрабатывающих данные, поступающие от потенциального нарушителя.
Работы в соответствии с Методикой ориентированы на обеспечение уровня анализа, позволяющего искать дефекты, потенциально способные стать уязвимостями нулевого дня, а не только на устранение уже известных уязвимостей и слабостей конфигураций.
— В чем смысл применения доверенных инструментов анализа (статических анализаторов, средств поиска уязвимостей или подсчета контрольных сумм), если эффективность их работы не превышает аналогичные показатели бесплатных аналогов?
— Одно из типовых заблуждений заключается в том, что для выстраивания процессов безопасной разработки, соответствующих требованиям Методики ФСТЭК России, все инструменты должны быть сертифицированы.
В настоящее время такие требования точно не применяются к статическим анализаторам и большинству инструментов динамического анализа. В то же время, с учетом недавно введенных в действие ГОСТ Р 71207–2024 «Статический анализ программного обеспечения. Общие требования» и ГОСТ Р 71206–2024 «Безопасный компилятор языков С/С++», а также разрабатываемых стандартов динамического и композиционного анализа, лично я предполагаю, что уже в среднесрочной перспективе мы увидим требования необходимости соответствия инструментов данным стандартам.
Наличие требования к сертифицированности средства поиска уязвимостей не мешает применять и иные инструменты. Основная цель этого требования – обеспечение поддержки связи с БДУ ФСТЭК, которая сейчас активно развивается и пополняется. В любом случае данные средства, если не покупать наиболее дорогие их варианты, составляют меньшую долю от общей стоимости требуемых инструментов обеспечения процессов РБПО. К тому же нормативка на то и нормативка, чтобы меняться с некоторым временным отставанием от лучших практик, в том числе в такой сфере, как сертификация, требующей определенной стабильности «интерфейсов» и правил. Плановое изменение регулятором перечня средств анализа для ИЛ и разработчиков-лицензиатов ожидается в начале июня.
Кстати, расчет контрольных сумм можно осуществлять средствами из состава сертифицированной ОС, которые являются средой функционирования для вашего сертифицированного СЗИ.
Объем проверок, который ФСТЭК России хочет увидеть в рамках одной сертификации, крайне затруднительно выполнить каждой конкретной компании в одиночку.
Полностью согласен с тем, что попытка проанализировать весь объем компонентов, с учетом сторонних компонентов с открытым исходным кодом, в рамках одной конкретной сертификации – это мартышкин труд, и ничего, кроме негатива со стороны разработчиков в отношении регулятора, он не приносит.
Именно для этой цели ФСТЭК России, совместно с ИСП РАН, и создала в 2021 г. Центр исследования безопасности системного ПО.
За три года работы Центра более 315 патчей отдано в апстрим ядра Linux. Сопоставимое число также отдано по интерпретаторам и иным пакетам, таким как OpenSSL, nginx и др.
В деятельности Центра участвует более 30 крупнейших отечественных разработчиков: операционщики («Альт», «Группа Астра», «Открытая мобильная платформа»), «Лаборатория Касперского», «Базис», «Сбертех» и многие другие. Новые участники регулярно вступают в консорциум Центра. Это уникальный пример совместной работы бизнес-конкурентов в зоне неконкурентности – для повышения безопасности и качества открытого кода, который в чистом виде никто не продает. Продаются лишь конечные бизнес-решения, созданные на базе открытого кода.
Однако даже Центр не сможет помочь наноразработчику, который решит произвести и продать очередного монстра из Linux-ядра и 500 пакетов с GitHub. Важнейший принцип регулятора – «весь код – это ваш код», если только вы не переиспользуете код из состава сертифицированных СЗИ, например ОС. Необходимо соизмерять собственные возможности по обеспечению процессов безопасной разработки, прежде, чем замахиваться на очередной контракт.
— Вы пытаетесь убедить, что сертификация – это интересно и полезно. Но почему никто, кроме вас, об этом не говорит? Мои друзья работают в финтех-стартапе, ни о чем подобном они не слышали – вероятно, вы один такой и просто вешаете нам лапшу на уши?
— Под эгидой ФСТЭК России и ИСП РАН создано и развивается сообщество безопасной разработки. В него входят представители различных компаний, от мелких до по-настоящему крупных.
У сообщества есть активные telegram-ресурсы. Важным является то, что это не просто однонаправленные каналы, а именно чаты, где мы обсуждаем инструменты и методики, где опытные участники делятся своими знаниями с новичками. Интересный факт: данные ресурсы были созданы под эгидой партнерства ФСТЭК России и ИСП РАН и с прямой поддержкой службы еще во времена блокировок Telegram в России.
Мы регулярно проводим встречи в составе от 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.