Безопасная разработка и сертификация: две стороны одной медали

Дмитрий Пономарев, 17/06/22

Все мы видим, что происходит в мире в последние месяцы. Неправомерное давление на нашу страну усиливается на всех уровнях – экономическом, технологическом – и проявляется в форме разнопланового силового воздействия, в том числе кибератаках, проводимых различными акторами, вплоть до APT-группировок. О некоторых атаках – успешных и неуспешных – мы знаем, а о некоторых не узнаем никогда. Поскольку угроза безопасности информационной инфраструктуры носит комплексный характер, то и бороться с ней можно только комплексными методами.

Автор: Дмитрий Пономарев, технический директор ООО НТЦ “Фобос-НТ”, сотрудник ИСП РАН

На стратегическом уровне процессы технологического развития можно выстраивать, опираясь на концепцию "физтеховского треугольника" "образование – разработка – инновации". При создании информационных систем, в частности на уровне непосредственной разработки СЗИ, требуется следовать принципу эшелонированной обороны. И в самом ее фундаменте, когда атакующим пройдены все остальные уровни защиты – организационные, административные, наложенные – находится безопасность разработки. Надежность последнего рубежа, а значит, и всей киберобороны в целом определяется тем, насколько хорошо спроектирована и реализована ваша система.

Роль и место безопасной разработки в современном процессе сертификации

Необходимость развивать процессы безопасной разработки в отечественных компаниях очевидна, и эта позиция всецело поддерживается государством в лице ФСТЭК России. Обратим внимание на два очень важных документа:

Приказ № 76 "Требования по безопасности информации..."1, раздел IV, п. 17, устанавливает, что "тестирование, испытания по выявлению уязвимостей и недекларированных возможностей, а также анализ скрытых каналов проводятся изготовителем в ходе приемочных испытаний средства и испытательной лабораторией в ходе сертификационных испытаний средства".
Приказ № 121 "О внесении изменений в положение о системе сертификации..."2, п. 12, усиливает и конкретизирует требование формулировкой "...при проверке организации производства программных и программно-технических средств защиты информации проверяется внедрение заявителем процедур безопасной разработки программного обеспечения в соответствии с требованиями по безопасности информации, на соответствие которым проводятся сертификационные испытания".

Эти формулировки принципиально важны! В соответствии с ними заявитель обязан тестировать разрабатываемые СЗИ, подлежащие серийному производству, теми же методиками, практиками и инструментами и в том же объеме, которыми лаборатория будет его проверять.

Что это значит? Это значит, что парадигма "отдадим собранный полгода назад комплект бинарных файлов в лабораторию, они там что-то пофаззят, и испытания пройдены", системно больше не работает. Конечно, мир не меняется моментально, некоторые из разработчиков-лицензиатов, пока еще пытающиеся идти упомянутым путем, вполне возможно, сертификаты получат, но точно не все и, возможно, не с первой попытки: глубина экспертизы и количество замечаний и отрицательных заключений со стороны участников процесса сертификации, выполняющих контролирующие функции (органы по сертификации, федеральный регулятор) стремительно нарастает. Можно сделать вывод: если у разработчика не реализован процесс безопасной разработки, отдавать код в испытательную лабораторию бесполезно.

Парадигма "отдадим собранный полгода назад комплект бинарных файлов в лабораторию, они там что-то пофаззят, и испытания пройдены", системно больше не работает

В то же время актуальная нормативно-правовая база содержит и позитивные стимулы для развития процессов безопасной разработки. Артефакты, подтверждающие корректное выполнение требуемых практик, полученные разработчиком в ходе процессов создания СЗИ в парадигме безопасной разработки, допускается переиспользовать в сертификационных испытаниях, что, как правило, приводит к существенному сокращению их сроков.

Практики и методики безопасной разработки должны реализовываться в соответствии с регламентирующими документами. В настоящий момент требования к количественным и качественным характеристикам SDLи сертификационных процессов задаются положением о системе сертификации, требованиями доверия и методикой ВУ и НДВ. Стоит упомянуть и ГОСТ Р 56939–2016 "Защита информации. Разработка безопасного программного обеспечения"3, но важно понимать, что, будучи концептуально правильным, он тем не менее носит рекомендательный характер. Ориентироваться на этот ГОСТ при подготовке продукта к сертификационным испытаниям не совсем верно, поскольку в ряде вопросов (например, аспекты статического и динамического анализа) он гораздо более узок, чем требования и методики регулятора, а в каких-то иных он, наоборот, описывает практики, не подлежащие проверке в ходе сертификационных испытаний (например, обучение персонала методикам и практикам безопасной разработки).

Как сформировать команду SDL

Чтобы внедрить безопасную разработку, недостаточно пройти код парой-тройкой анализаторов и прикрепить к материалам отчеты на 200 тыс. строк с формулировками "уязвимости не эксплуатируемы, потому что не эксплуатируемы". Безопасная разработка – это непрерывный процесс, включающий выделенных сотрудников, технику, платные и бесплатные программные средства. Важно также понимание необходимости этого процесса сотрудниками компании, начиная с собственника и заканчивая джунами-стажерами. Правильным подходом является переход компании в целом к работе в парадигме Secure by Design. Необходимо донести до руководства важность процесса безопасной разработки. Скажу честно, работать с крупными компаниями сложнее, чем с небольшими или средними организациями, где уровень принятия решений – это человек, с которым ты можешь общаться напрямую, которому можно за чашкой кофе объяснить, зачем все это нужно и какую реальную пользу от внедрения получит бизнес. В крупных же компаниях собственник обычно где-то очень далеко, и пытаться до него донести важность безопасной разработки весьма сложно. Но если руководство организации все же проявит нужную политическую волю, вплоть до приостановки процессов разработки на несколько месяцев и концентрации на внедрении практик и инструментов, ориентированных на безопасность, желаемый и ощутимый положительный эффект может быть достигнут очень быстро. И такие прецеденты в российских условиях есть.

Важно понять и принять как аксиому, что правильно поставленный процесс безопасной разработки становится залогом своевременного получения сертификата соответствия, а также настоящим конкурентным преимуществом XXI века.

Для внедрения SDL-практик в команду разработки в количестве 5–15 сотрудников необходимы 1–2 выделенных SDL-специалиста. Важно понимать, что свободных Security Champion на рынке нет. На текущий момент отечественная система образования только приходит к необходимости подготовки специалистов профиля Application Security, одной из первых ласточек является создание учебной программы "Кибербезопасность", благодаря стараниям ФСТЭК России и ИСП РАН, однако реальные плоды этих преобразований мы увидим только через несколько лет. Тем не менее такого специалиста вполне реально вырастить за год-полтора при наличии хороших исходных данных: Junior- или Middle-разработчик по каждому языку программирования, используемому в продукте, с навыками пентеста, общим представлением об анализе уязвимостей, навыками DevOps, горящими глазами и прямыми руками. Важно не брать в SDL чистых билдеров, даже если он Senior Developer на ассемблере, ведь люди, которые любят писать код, делать интересные фичи в приложениях, на позициях SDL не задерживаются. Четверть наших клиентов изначально допустила такую ошибку, и это привело их к затягиванию процесса. Человек, занимающийся SDL, должен любить расследовать, рыться, ковыряться в деталях, у него должен быть подходящий для этого характер и склад ума.

Немаловажным и полезным является подключение кандидатов в SDL-специльность к деятельности профессионального сообщества, формируемого под эгидой центров компетенций ФСТЭК России и ИСП РАН: возможность задать вопросы и получить ответы от более опытных единомышленников именно в отечественном информационном сегменте сложно переоценить.

Сколько стоит безопасная разработка?

Безопасная разработка – это не бесплатное и не дешевое удовольствие. Но нужно воспринимать связанные с ней затраты исключительно как инвестиции, которые уже в среднесрочной перспективе начнут приносить качественные результаты.

Приведем один из множества частных примеров: глубокая автоматизация всех основных видов динамического тестирования в "Лаборатории Касперского" позволила сократить релизный цикл стратегически значимых продуктов компании с одного года до одного квартала и при этом повысить качество тестирования, то есть снизить число ошибок, выявляемых на этапе эксплуатации продукта.

Первый пункт затрат, естественно, – инфраструктура, аппаратная платформа, вычислитель. Стоимость его для компании среднего размера можно оценить от 1 млн до 3 млн руб. Впрочем, вполне возможен более оптимизированный по стоимости вариант развертывания инфраструктуры в облаке. Важно понимать, что некоторые практики анализа, в первую очередь фаззинг-тестирование, "съедят" столько процессорных ядер, сколько вы сможете им выделить. В этом смысле фаззинг сравним с майнингом криптовалют: увеличение вкладываемых в анализ ресурсов повышает шанс нахождения уязвимостей раньше потенциального нарушителя, но, разумеется, не гарантирует отсутствие в коде потенциальных уязвимостей.

Второй момент: инструментальные средства потребуют до 5 млн руб. в год в зависимости от конкретных условий. При этом в настоящее время действует льготная программ ИСП РАН, позволяющая получить широкий комплект средств анализа на безвозвмездной основе сроком на полгода [4[.

Третий момент – фонд оплаты труда. Назвать конкретные цифры здесь сложно, поскольку зарплатные политики компаний могут значительно различаться, в том числе в зависимости от региона.

После запуска процесса внедрения SDL-практик значимые результаты появятся, как правило, через 6–12 месяцев. Процесс очень непростой, и чем дальше, тем более сложным он становится, однако также интересным для инженеров и полезным для компании в целом.

Практики безопасной разработки

Привожу неполный, основной список того, что как компании, так и лаборатории должны уметь делать уже сейчас:

моделирование и проектирование безопасной архитектуры;
анализ безызбыточности внешних интерфейсов и прав доступа к ресурсам;
статический анализ исходного кода;
статический анализ конфигураций модулей и контейнеров;
использование безопасных тулчейнов: компиляторы, линковщики и их параметры;
использование безопасных сторонних и заимствованных компонентов, в том числе рантайм-компонент и интерпретаторов/ВМ;
динамический анализ в форме модульного и функционального тестирования с целью "подтверждения известного";
динамический анализ в форме фаззинг-тестирования для "поиска неизвестного";
динамический анализ для выявления побочных взаимодействий со средой функционирования;
динамический анализ с целью анализа утечек чувствительных (помеченных) данных;
тестирование на проникновение.

С течением времени этот список будет расти как с точки зрения номенклатуры требуемых практик, так и в плане глубины и качества их применения.

Помимо внедрения самих практик, нельзя забывать о двух важных аспектах:

Подготовка кадров: необходимо менять парадигму обучения специалистов, особенно студентов, включая безопасную разработку в их картину мира на как можно более ранней стадии.
Автоматизация: чем меньше новой рутины привносит процесс SDL в разработку, тем лучше он приживается в командах, поскольку рутинизация довольно быстро убивает всякий энтузиазм.

Что нас ждет дальше?

Если заглянуть в недалекое будущее, то можно увидеть ряд грядущих важных событий и изменений.

Разработка и обновление ГОСТов по безопасной разработке, статическому и динамическому анализу, безопасной компиляции и др. Во-первых, ГОСТы станут более разнообразными. Во-вторых, нужно обратить особое внимание на ГОСТ по безопасному компилятору [5]. Весьма вероятно, что через некоторое время весь код на языках С/С++, предполагаемый для использования в сертифицируемых СЗИ, нужно будет собирать именно им.
Разработка и обновление требований безопасности и профилей защиты. Уже разработаны требования к системам защиты от DDoS. Разрабатываются требования к средствам контейнеризации, на очереди явно требования к средствам виртуализации, СУБД и DLP, а также уточнение существующих профилей. Назревает вопрос о создании требований к средам выполнения кодов, написанных на интерпретируемых (управляемых) языках программирования. ФСТЭК очень активно ведет эти работы, опираясь на технологическую экспертизу ИСП РАН и привлекая экспертные сообщества. Всем понятно, что требования должны быть живыми, впрочем это не означает, что они должны быть мягкими.
Средства автоматизации и стандартизации определения ширины и глубины поверхности атаки в процессе безопасной разработки продуктов и их сертификации. Это очень ожидаемая вещь: вы приносите двухгигабайтный комплекс исполняемых файлов, называемый СЗИ, заводится "волшебный ящик", прогоняются основные сценарии и автоматически вырисовываются карты того, какие модули в действительности составляют СЗИ, что с чем взаимодействует, какие участки кода покрыты, куда утекали помеченные данные, эвристики их изменений, цикломатическая сложность кода. И по этой красивой схеме нужно работать, а потом и идти на сертификацию. Лучше развивать все эти процессы уже сейчас, поскольку автоматизированная система гарантированно отрисует (и подпишет цифровой подписью) большую поверхность атаки, чем любой эксперт, особенно если он лично заинтересован в скорейшем завершении процесса сертификации в ущерб качеству.
Стандартизация использования системных компонент (ядра, системное ПО, компоненты виртуализации и контейнеризации, компоненты сборочной системы). Тут, в общем, все понятно, за это кто-то должен отвечать, то есть либо вы, либо разработчик операционной системы, в которой вы работаете. Если вы хотите взять, например, оттуда Lua, а в сертифицированном дистрибутиве операционной системы его нет, значит, вы должны фаззить Lua сами, ведь за каждый компонент должен кто-то отвечать. Поэтому чем компонентов будет меньше, чем они будут более стандартизованы, тем будет проще. Особое внимание следует уже сейчас обратить на функционирование Центра анализа ядра Линукс, в работе которого уже принимают участие все основные отечественные разработчики СЗИ. Уже в среднесрочной перспективе успешное прохождение сертификационных испытаний СЗИ, имеющего в своем составе ядро, не покрытое объемом практик анализа, сопоставимым с результатами работы Центра, представляется маловыполнимым.
Обеспечение целостности результатов работы анализаторов с помощью цифровых подписей. Это тоже очень важный момент, чтобы отчеты не просто выпадали из анализатора, а подписывались: чтобы, к примеру, нельзя было вручную убрать 100 тыс. срабатываний, оставив только тысячу. И это вопрос самого ближайшего будущего.
Стандартизация материалов сертификационных испытаний, уход от "бумажной" безопасности в сторону реальной. Сейчас явно наблюдается движение в этом направлении и есть успехи. Что немаловажно – этот вектор горячо поддерживается в первую очередь самими регуляторами, ведь главное – это суть, а не кипа написанных бумаг.