Журнал "Information Security/ Информационная безопасность" #2, 2024

Есть несколько типовых вопросов, регулярно поступающих со стороны орга- низаций и частных лиц, столкнувшихся с современной сертификацией на соот- ветствие требованиям ФСТЭК России. Не всегда специалисты получают на них простые ответы, и не всегда эти ответы даются на языке, понятном инженеру- разработчику. Зачастую именно это ста- новится причиной нагнетания атмосфе- ры секретности, непонимания систем- ности подхода и стратегического курса регулятора, недоверия к тому, что оте- чественный регулятор может активно и деятельно способствовать развитию и внедрению лучших практик безопасной и качественной разработки ПО. Крайними в этом случае зачастую оказываются эксперты испытательных лабораторий (ИЛ) – в такой ситуации оказался и я сам пять лет назад. В этой статье совместно с редакцией журнала "Информационная безопас- ность" мы постараемся ответить на типо- вые вопросы к эксперту ИЛ и развеять несколько наиболее популярных мифов. Сертификация – это длитель- ный и неинтересный процесс, направленный на прохождение множества бюрократических эта- пов и не связанный с реальной безопасностью. За последние пять лет система серти- фикации СЗИ претерпела колоссальные изменения, практически сменив свой вектор, и продолжает активно разви- ваться. Если вы проходили испытания до 2019 г., или даже до 2023 г., скорее всего вы будете сильно удивлены числу произошедших перемен и их объему. Выход новой нормативки, в частности приказа № 76 "Требования по безопасно- сти информации…" и Методики ВУ и НДВ (издание второе, доработанное), сместил основной фокус с проверки "бумаг" и функ- ционала на анализ процессов безопасной разработки (Application Security) и их результатов в отношении сертифицируе- мого СЗИ. Это не означает, что наличие полных и корректных документальных сви- детельств или подтверждение выполнения функций безопасности перестало быть важным. Это означает, что в общем объе- ме задач сертификации задачи и проверки из области безопасной разработки играют не меньшую роль, а "бумажные" артефакты в первую очередь должны подчеркивать глубину и качество выполнения требований к безопасной разработке и не изготавли- ваться ради себя самих, как отписки в рамках "бумажной" безопасности. Подтверждение этих тезисов можно найти в публичных выступлениях руко- водителей ФСТЭК России и представи- телей Института системного програм- мирования РАН им. В.П. Иванникова на открытых конференциях, в первую оче- редь на ТБ Форуме 2024 1 . Что, кроме дополнительной нагрузки, может привнести Мето- дика ВУ и НДВ ФСТЭК России в компании с уже сформирован- ными командами DevSecOps? Методика ВУ и НДВ – это постоянно развивающийся документ (в настоящий момент он имеет пометку "ДСП"), опре- деляющий инструменты и методики ана- лиза, применяемые в ходе испытаний, а также качество артефактов, подтвер- ждающих выполнение проверок. Некоторое представление об этом документе вы можете получить, посмот- рев выступления на ТБ Форуме 2023 2 и OFFZONE 2023 3 или поинтересовавшись у вашей ИЛ, если вы работаете в компа- нии – лицензиате ФСТЭК России. Типовые DevSecOps-процессы, как правило, сконцентрированы вокруг таких практик, как: l композиционный анализ, переисполь- зование бинарных компонентов и обра- зов контейнеров; l веб-тестирование на проникновение; l базовый статический анализ собст- венных компонентов; l а также вопросов безопасной настрой- ки kubernetes-кластеров для программ- ных решений в k8s-исполнении. Требования Методики значительно более глубокие. Значимый акцент дела- ется на различные виды инструменти- рующего фаззинга, применение датчиков срабатывания ошибок (аллокаторов, санитайзеров) в динамике, углубленный статический анализ, анализ утечек поме- ченных данных, харденинг параметров компиляции и иные техники, нечасто применяемые в базовом DevSecOps-про- цессе малой и даже средней компании. Особое внимание уделяется опреде- лению поверхности атаки. Методика ее определения является значительно более глубокой, нежели простое сканирование портов или анализ логов strace, и требует определения конкретных функций, обра- батывающих данные, поступающие от потенциального нарушителя. Работы в соответствии с Методикой ориентированы на обеспечение уровня анализа, позволяющего искать дефекты, потенциально способные стать уязви- мостями нулевого дня, а не только на устранение уже известных уязвимостей и слабостей конфигураций. В чем смысл применения дове- ренных инструментов анализа (статических анализаторов, средств поиска уязвимостей или подсчета контрольных сумм), если эффективность их работы не превышает аналогичные пока- затели бесплатных аналогов? Одно из типовых заблуждений заклю- чается в том, что для выстраивания про- цессов безопасной разработки, соот- ветствующих требованиям Методики ФСТЭК России, все инструменты долж- ны быть сертифицированы. В настоящее время такие требования точно не применяются к статическим ана- лизаторам и большинству инструментов динамического анализа. В то же время, с учетом недавно введенных в действие ГОСТ Р 71207–2024 "Статический анализ программного обеспечения. Общие тре- бования" и ГОСТ Р 71206–2024 "Без- 58 • ТЕХНОЛОГИИ 6 мифов о безопасной разработке и сертификации ПО Дмитрий Пономарев, заместитель генерального директора – директор департамента внедрения и развития РБПО НТЦ “Фобос-НТ”, сотрудник ИСП РАН, преподаватель МГТУ им. Н.Э. Баумана Фото: Фобос-НТ 1 https://www.tbforum.ru/2024/program/information-security 2 https://www.tbforum.ru/2023/program/information-security 3 https://www.youtube.com/watch?v=Kt9t_poXttI