Журнал "Information Security/ Информационная безопасность" #2, 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- тестирование, а сертификация – white- box. Однако далеко не все серьезные разработчики готовы делиться своими исходными кодами с внешними экспер- тами. Являясь сотрудником испытатель- ной лаборатории, имеющим доступ к исходникам непосредственно по сер- тификационному "законодательству", я периодически сталкиваюсь с нежела- нием команд допускать кого-либо со стороны к важным частям кода. Разу- меется, в конечном итоге вопрос всегда решается положительно, но только по причине того, что наличие сертификата соответствия – это прямая необходи- мость для продаж сертифицируемого ПО. Bug Bounty же – это в конечном итоге "про тестирование" и денег само по себе не приносит, поэтому такими компаниями риски возможной утечки исходников расцениваются как непри- емлемые. Однако без наличия исходни- ков и доступа к сборочной среде воз- можности исследователя по выявлению дефектов кода кратно сокращаются. принципиальная разница № 2. Bug Bounty – это в первую очередь про нарушителя, а сертификация, и тем более внедрение процессов РБПО, – это в первую очередь про трансформа- цию культуры разработки в сторону Test, Security First. Чем качественнее и безошибочнее пишется код, чем более РБПО-ориентированы сотрудники ком- пании, тем меньше шансов в конечном итоге у любого исследователя Bug Bounty. l • 59 Безопасная разраБотка www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru 4 https://portal.linuxtesting.ru/news.html#main 5 https://t.me/sdl_community/4859 6 https://www.tbforum.ru/2024/program/rbpo