Как правильно организовать процесс безопасной разработки ПО (SDL): 6 шагов

Дмитрий Пономарев, 30/12/22
В наши дни все больше элементов общественной инфраструктуры используют современные решения, основанные на компьютеризированных информационных системах. В то же время львиная доля программных компонентов, из которых они состоят, происходит из проектов с открытым кодом, зачастую не имеющих должной организации процесса разработки и тестирования. Отсутствие ответственности за надежность (защищенность) компонента приводит к нарушению цепочки доверия ко всем составляющим и продукту в целом. Внедрение в компании процессов безопасной разработки SDL (Secure Development Lifecycle) поможет избежать подобной проблемы. Давайте разберемся, какие тренды и организационные моменты необходимо учесть, какие инструменты использовать, чтобы добиться цели.
Авторы:
Дмитрий Пономарев, технический директор испытательной лаборатории ООО НТЦ “Фобос-НТ”
Роман Карпов, директор по технологиям и развитию технологий Axiom JDK компании “БЕЛЛСОФТ”, руководитель комитета по ИБ АРПП “Отечественный софт”

Предпосылки

Основной предпосылкой внедрения практик разработки безопасного ПО традиционно являются требования регуляторов – ситуация в России не отличается от мира в целом. ФСТЭК России фокусируется на технологической безопасности, на применении лучших мировых практик и их совершенствовании в соответствии с актуальными угрозами и вызовами времени.
В качестве частного примера с далеко идущими последствиями можно привести проработку федеральной службой в сотрудничестве с сообществом экспертов в области ИБ-технологий подхода к декларированию программных компонентов, аналогичного изданному в 2021 г. указу [1] президента США, в числе прочего обязывающему разработчиков декларировать компонентный состав продукта – формировать SBoM (Software Bill of Materials, или реестр компонентных связей).
Внедрение технологий анализа влечет за собой как дополнительные накладные расходы на бизнес "здесь и сейчас", так и более масштабные – в будущем. Реестр компонентных связей продукта, представленный в стандартной форме, описывающий состав программного обеспечения, поверхность атаки на программное обеспечение и т.п., позволит регулирующим органам собирать широкий спектр аналитической информации обо всех эксплуатируемых программных продуктах практически в режиме реального времени, что, в свою очередь, потребует оперативного реагирования на отсутствие должной поддержки разработчиками ПО, вплоть до отзыва сертификатов и лицензий на разработку.
Руководство и маркетологи компаний обычно стараются подчеркнуть уникальность продукта. Однако на поверку оказывается, что многие программные решения, продаваемые в том числе как отечественные, не уникальны. Они не только на 100% состоят из стороннего кода (еще и без учета лицензионных аспектов использования этого кода), но и при этом из его устаревших, никем не поддерживаемых версий, к тому же с размещением данных компонентов на поверхности атаки. А это наиболее критические интерфейсы программного обеспечения, в первую очередь подверженные угрозам атаки потенциального нарушителя.
Введение автоматизированного механизма в определенном смысле поместит разрабатываемые программные решения "под рентген", снизив возможность сокрытия компонентов из-за недобросовестной работы эксперта.
Не менее важной предпосылкой к внедрению процедур безопасной разработки (SDL, Secure Development Lifecycle) является осознание того, что SDL – не только "про безопасность", это один из доменов практик качественной разработки!
Информация считается защищенной только в случае, если она обладает тремя свойствами одновременно: целостностью, доступностью и конфиденциальностью. Таким образом, любое падение или замедление работы системы, вызванное программной ошибкой, нарушает свойство доступности, а также зачастую ведет к перерасходу ресурсов. Перефразируя известную фразу Стива Балмера, СЕО Microsoft, "Developers! Developers! Developers!", можно сказать: "Тестирование, тестирование, тестирование!"
Много тестов не бывает, поскольку любое современное ПО, даже без учета нюансов аппаратной составляющей, ОС, компонентов среды разработки и исполнения, имеет объем кодовой базы и ее сложность, не подлежащие формальному доказательству безошибочности в условиях ограничения реальных технологий и ресурсов. С другой стороны, чем шире тест-сьют, чем более он автоматизирован, тем больше вероятность своевременного нахождения проблем, что, в свою очередь, приводит к сокращению Time-to-Market, снижению числа потенциальных рекламаций и нагрузки на группы техподдержки.
Разработчики, не обладающие возможностями для организации качественного производства, хватающие любые контракты с целью заработать денег в парадигме "после нас хоть потоп" и не планирующие оказывать реальную техническую поддержку (что прямо требуется основными нормативными документами ФСТЭК России и не только), окажутся в заведомо невыгодных условиях и уступят место на рынке ответственным производителям.

Реализация

Неслучайно мировые ИТ-гиганты неукоснительно следуют практикам безопасной разработки. Они занимаются промышленным производством ПО, и SDL-подход, можно сказать, стал частью ДНК их инженерных команд. Каким образом лучшие практики распространить в России?
Рассмотрим опыт разработчиков российской среды исполнения Java на базе проекта с открытым исходным кодом OpenJDK. Отечественные инженеры внедрили концепцию жизненного цикла безопасной разработки с момента создания программного продукта Axiom JDK. Команда уже четверть века работает над улучшением Java-технологий, в том числе в центрах разработки Oracle и Sun, и сегодня входит в число лидеров SDL-разработки в России.

На технологиях Java работает подавляющее большинство критически важных государственных, банковских и промышленных систем. Одна из идей, лежащих у истоков российского дистрибутива среды исполнения Java в концепции SDL by Design, – создать надежный продукт, обеспеченный высоким уровнем доверия потребителя, вниманием к процессам тестирования и качеству при каждом обновлении. SDL позволяет воплотить эту идею и сократить расходы на процессы, необходимые для поддержания качества.
Итак, какие этапы необходимо пройти инженерной команде, чтобы внедрить в разработку принципы SDL?

1. Убедить руководство: заручиться поддержкой и бюджетом

Первый (или нулевой) этап предполагает определение бюджета и убеждение руководства в необходимости проведения данных мероприятий. Хорошо, когда инициатива изначально исходит от руководителей компании, но это бывает нечасто. Хорошим аргументом может стать ощутимый размер убытков в случае обнаружения уязвимостей после выпуска изделия в промышленную эксплуатацию. Эксперты из LLVM Project приводят [2] следующую оценку: если стоимость исправления бага на этапе разработки около $25, то после релиза она может быть порядка $16 000, то есть в 640 раз выше.
При проработке плана действий необходимо учесть особенности SDL-процесса в парадигме ФСТЭК России:
выявление уязвимостей и недекларированных возможностей, статический и динамический анализ в первую очередь в отношении тех компонентов решения, которые находятся на поверхности атаки;
опора на технологическую и методологическую поддержку ИСП РАН, разработки которого востребованы в России и в мире. В числе его сотрудников – все пять российских ревьюверов gcc-компилятора. Помимо компетенций в технологиях классической продуктовой безопасности ИСП РАН входит в шестерку исследовательских центров в сфере искусственного интеллекта, отобранных в 2021 г. в рамках проекта "Искусственный интеллект" национального проекта "Цифровая экономика". Он сконцентрирован на анализе безопасности технологий искусственного интеллекта;
активное взаимодействие с сообществом – привлечение участников сообщества к развитию методик и требований разработки и анализа СЗИ, создание информационных ресурсов для обучения компаний.

2. Получить и проработать требования к продукту для сертификации по SDL

На этом этапе проводятся переговоры с представителями лаборатории. Их результатом является получение и проработка требований, создание формализованного списка действий по доработке изделия с целью удовлетворения требований по безопасному функционированию, проведению испытаний, подтверждающих состоятельность доработанного функционала, и выполнению регулярных испытаний, обеспечивающих поддержание высокого стандарта качества и защищенности для каждой новой версии изделия. Список требований согласуется с регулятором.
Например, при подготовке к внедрению SDL и сертификации для Axiom JDK обсуждались и прорабатывались требования и тесты для проверки следующих механизмов:
обеспечения независимости экземпляров виртуальных машин;
обеспечения верификации байт-кода на соответствие спецификации языка Java;
обеспечения проверок безопасности операций во время выполнения кода;
обеспечения разграничения и контроля доступа приложений Java к внешним по отношению к виртуальной машине Java-ресурсам;
обеспечения контроля целостности исполняемого кода;
предоставления администратору ВМ возможности определения событий, подлежащих записи в журнал аудита;
выделения/удаления памяти, корректность его работы при разных сценариях.

3. Сформировать команду для поддержания SDL-процесса

Для внедрения SDL-практик в команду разработки из 5–15 сотрудников необходимы 1–2 выделенных специалиста по информационной безопасности и процессам SDL. Обычно они ведут проект самостоятельно и взаимодействуют с 5–7 техническими экспертами, сосредоточенными на разработке и сопровождении программного изделия.
Эксперты привлекаются для разрешения вопросов, требующих опыта и глубокой экспертизы по конкретному направлению. Специалисту по защите информации и SDL, пришедшему извне, чаще всего сложно быстро разобраться в структуре большого проекта, понять архитектурные и функциональные решения, взаимодействие компонентов внутри программного продукта, тонкости процесса сборки, разные режимы функционирования и т.д.
Например, при разборе логов статического анализатора необходимы постоянные консультации с разработчиком, хорошо разбирающимся в коде подлежащего анализу программного компонента. На этапе внедрения тестов с санитайзерами будет полезна помощь тестировщика. С фаззингом – понадобится участие ведущих разработчиков для выбора поверхности атаки и DevOps-инженеров – при подготовке и сборке фаззинг-цели.
Приглашая в команду специалиста, отвечающего за инженерный центр безопасности и внедрение SDL, стоит обратить внимание на следующие компетенции кандидата:
минимально Junior по SDL/DevSecOps должен обладать следующим набором знаний на базовом уровне: С/C++, работа с Linux, информационная безопасность, а также опционально – базовые знания языка/стека технологий для конкретного изделия/проекта, на котором нужно внедрять SDL;
специалист уровня Security Champion имеет хорошее понимание C/C++, работы сетевых протоколов, механизмов работы Linux и C runtime, понимание принципов ИБ и их прикладного значения, обладает опытом работы с инструментами тестирования (статические анализаторы, фаззеры, отладчики) и инструментами анализа (статические анализаторы, средства реверс-инжиниринга – дизассемблеры, декомпиляторы, сетевые сканеры, средства пентеста).

4. Выбрать актуальные инструменты

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

Статический анализатор Svace (ИСП РАН)

Это постоянно развивающийся инновационный продукт для статического анализа, основанный на многолетних исследованиях. Он объединяет ключевые качества иностранных аналогов (Synopsis Coverity Static Analysis, Perforce Klocwork Static Code Analysis, Fortify Static Code Analyzer) с уникальным использованием открытых промышленных компиляторов в целях максимальной поддержки новых стандартов языков программирования. Svace, например, является основным статическим анализатором в компании Samsung, в которой заменил мирового лидера – Coverity.
Инструмент Svace применяется в Axiom JDK для анализа кода C/C++, а также Java-кода с учетом ранних ограничений на анализ исходных кодов, написанных на Java 17. Благодаря передовому движку межмодульного анализа, чувствительному к контексту и путям выполнения, широкому спектру доступных в Svace детекторов и удобству интерфейса разметки срабатываний Svace, команде удалось обнаружить и исправить ряд дефектов в релизах JDK 8, 11 и 17. Работа с этим инструментом подразумевает разметку и разбор предупреждений, выявленных в ходе сертификационных испытаний, и затем написание патчей к выявленным проблемам исходного кода.

Система определения поверхности атаки Natch (ИСП РАН)

Инженеры отечественной среды разработки Java используют как статическое, так и динамическое тестирование, стремятся повышать эффективность анализа безопасности и участвуют в развитии инструментов. Среди перспективных планов команды – встраивание в рабочий процесс системы Natch.
Это инструмент для определения поверхности атаки, основанный на полносистемном эмуляторе Qemu. Он использует технологии анализа помеченных данных, интроспекции виртуальных машин и детерминированного воспроизведения. Основная функция Natch – получение поверхности атаки, то есть поиск исполняемых файлов, динамических библиотек, функций, отвечающих за обработку входных данных (файлов, сетевых пакетов) во время выполнения задачи.
Задачей Natch является выявление структурных элементов кода (функций), значимо взаимодействующих с потоками данных, формируемых потенциальным нарушителем с целью изменения штатной логики работы программы (может быть связано с кодовыми или алгоритмическими ошибками), а также различных неучтенных потоков данных (в самом деле, типовое СЗИ типа межсетевой экран может состоять из ядра Linux и 300–500 пакетов, скомпонованных в единое целое меняющейся командой разработчиков различной квалификации; наличие неучтенных "хвостов" и "точек входа" – это типичное событие при сертификации более-менее крупных программных решений) [3].
Помимо технологий анализа ИСП РАН, в России развиваются и другие команды. В частности, стоит иметь ввиду такие решения, как система SCA-анализа.

Система SCA-анализа и проверки компонент на лицензионную чистоту CodeScoring (Profiscope)

Это уникальное отечественное решение композиционного анализа программных продуктов, решающее задачи инвентаризации компонентной базы продуктов (Bill of Materials), поиска уязвимостей в компонентах Open Source, анализа лицензионного ландшафта и лицензионной чистоты (ближайший аналог – система OWASP Dependency Track). Это пример отечественной команды и разработки со всеми правами на разрабатываемую кодовую базу.

Система комплексного статического и динамического анализа кода AppScreener (Ростелеком-Солар)

Удобное и понятное решение для анализа кода, которое позволяет контролировать безопасность используемых в компании систем и предотвращать утечки данных, выявлять и исправлять недостатки кода на ранних этапах разработки.
Инженеры Axiom JDK считают, что для библиотек доверенного репозитория следует иметь в арсенале два анализатора, и в дополнение к Svace рассматривают использование AppScreener для эшелонированного статического анализа.
Система поддерживает анализ исходных текстов, написанных на 37+ языках программирования, что может быть особенно актуальным при анализе веб-приложений, зачастую представляющих из себя зоопарк технологий. Она также позволяет декомпилировать и впоследствии анализировать бинарный код при отсутствии исходного кода.

5. Выстроить процесс реализации требований

Подготовительные этапы завершены, инструменты выбраны, и команда профессионалов готова к постоянной работе по внедрению SDL: знает, в каком объеме ее проводить и какой ожидается конечный результат. С этого момента начинается непрерывный процесс внедрения, улучшения, автоматизации и поддержания SDL. Это в первую очередь подразумевает регулярное проведение испытаний, удостоверяющих соответствие требованиям и качество изделия.
В примере с продуктом Axiom JDK требовалось вовлечение специалистов по Java, С/С++, безопасности и тысячи часов рабочего времени. В результате испытаний были обработаны и разобраны тысячи событий срабатываний санитайзеров, полученные при тестировании, исправлены дефекты и повышено качество продукта. Затем была сформирована дорожная карта по организации, улучшению и расширению процессов SDL.
Эти усилия дали значимые результаты. В частности, для реализации требований ФСТЭК России (фиксировать результаты испытаний) SDL-команда провела серьезную работу по выстраиванию автоматизированной системы порождения различной отчетности, раскатыванию тестовых комплектов на разные процессорные архитектуры и затем – на различные сборки операционных систем. Увеличилось число тестирований в соответствии с рекомендацией ФСТЭК России выполнять их везде, а отчетные материалы стали создаваться автоматически: они верифицированы и принимаются регулятором, можно даже добавить электронную подпись. В результате удалось снизить нагрузку на разработчиков при подготовке отчетности.
Эксперты считают, что исследование безопасности и функционала платформы Java сравнимо по ресурсам с исследованием безопасности операционной системы. Объем исходного кода российского дистрибутива среды исполнения Java составляет 12 млн строк. Это сложный продукт, который содержит огромное количество модулей, выполняющих самые различные задачи, от обработки изображений до работы с памятью в C runtime. А специфика функционирования осложнена их постоянным взаимодействием друг с другом в рамках единого продукта.
В работы по SDL-проекту команда Axiom JDK инвестировала 10 человеко-лет, причем самостоятельно, а не под давлением ФСТЭК России. Инженеры верифицировали 3 Гбайт программного кода. Благодаря этому сертифицированный продукт готов к использованию в качестве платформы в критических информационных инфраструктурах и промышленному тиражированию как платформа для Java-приложений и облачных провайдеров, которым требуется сертификация ФСТЭК России.

6. Обмениваться опытом в сообществе SDL

Завершающий этап организации процессов безопасной разработки – это взаимодействие в сообществе. Обратная связь позволяет повышать эффективность SDL-процессов и экономить ресурсы: обмениваться опытом, формировать четкое представление о рабочих процессах и их целях не повторять работу, уже проделанную кем-то на рынке.
Например, сотрудничество ИСП РАН и команды Axiom JDK позволило улучшить как программный продукт, так и инструмент Svace. Специалисты института получили набор рекомендаций по улучшению его работы, связанных как созданием новых типов детекторов, так и с модификацией уровня значимости некоторых типов детекторов, с учетом особенностей, присущих именно Java-коду.
Сила сообщества в единстве непохожих участников и зачастую прямых конкурентов или оппонирующих сторон в процессе сертификационных испытаний (регулятор – лаборатория – разработчик). Они объединяются в вопросах, которые касаются развития безопасной и качественной кодовой базы и нормативно-правовых документов. Технологический центр исследования безопасности ядра Linux [4], работающий под эгидой партнерства ФСТЭК России и ИСП РАН, включает уже более 26 отечественных организаций. Это яркий пример сотрудничества, которое приносит значимые результаты для мирового Open Source-сообщества независимо от международной ситуации. Так, например, за период с февраля по декабрь 2022 г. были обнаружены и поданы в апстрим 64 значимые уязвимости кода и патчи к ним. Координация участников сообщества и обмен опытом осуществляются в телеграм-чате @sdl_community и нескольких других.

Выводы

Внедрение SDL дает разработчикам возможность сократить расходы на сопровождение программного продукта, ускоряет тестирование и выпуск новых релизов, позволяет запустить разработку в промышленное производство. В то же время SDL является базовым требованием при сертификации ПО в дополнение к необходимым функциям безопасности, определяемым документами ФСТЭК России. Разрабатываемые программные средства предназначаются для повышения уровня защищенности объектов критической инфраструктуры, АСУ ТП и информационных систем, обрабатывающих персональные данные. При этом высокое качество, актуальность и востребованность создаваемых продуктов позволяет реализовывать их и для других информационных систем с повышенными требованиями по безопасности, что исключительно важно сегодня, когда число кибератак выросло в 1,5 раза по сравнению с 2021 г., а на КИИ – нефтяную, энергетическую и финансовую отрасли – в 1,7 раз.

Примеры минимизации необязательной кодовой базы

Важнейшим аспектом испытаний, связанных с практической безопасностью, является определение кодовой базы (модулей и функции), составляющей поверхность атаки на анализируемую систему. Важнейший аспект разработки безопасного пО – минимизация необязательной кодовой базы, в первую очередь и составляющей поверхность атаки.
Год назад в ходе сертификационных испытаний межсетевого экрана Ideco UTM произошел достаточно поучительный случай. Он особенно важен, поскольку разработчики Ideco весьма ответственно относятся к собственной кодовой базе и занимаются ее минимизацией и анализом самостоятельно, без давления регуляторов. специалисты Ideco решили "на спор" поискать в кодовой базе развернутого межсетевого экрана интерпретируемый код. архитектор утверждал, что ничего, кроме python-кода, в составе дистрибутива нет и быть не может, однако первый же запуск grep/-name "*.pl" нашел некоторое количество perl-кода. после чего выяснилось, что он есть, и даже есть сам интерпретатор perl, хотя при этом он нигде не используется. "раз пошла такая пьянка, режь последний огурец!" – решили поискать заодно и js, что удивительно – нашли! Откуда он там?! Оказалось, что на js (то есть прямо в формате скрипта) присутствует файл конфигурации демона policykit, реализующего систему раздачи прав пользователям и работающего с root-привилегиями. Для чтения файла конфигурации используется mozjs – js-движок из состава firefox, разумеется написанный на C.
Таким образом, за 20 минут работы были найдены два избыточных интерпретатора, один из которых выполняется с root-привилегиями. сразу были созданы тикеты. Perl удалили из системы с помощью патчей компонентов, убирающих ненужную функциональность, добавили проверку, чтобы он гарантированно не мог быть установлен.
В части policy-kit самостоятельно переписали соответствующий функционал на python. Итого: сократили несколько десятков Мбайт бинарного кода и два интерпретатора, что особенно важно при прохождении сертификационных испытаний, упростили сборочный процесс.
https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
https://llvm.org/devmtg/2020-09/slides/Using_the_clang_static_ananalyzer_to_find_bugs.pdf
Полный список инструментов и технологий, разрабатываемых ИСП РАН, доступен по ссылке https://www.ispras.ru/downloads/ISP_RAS_Catalogue_of_technologies_2022_ru.pdf
https://portal.linuxtesting.ru/

www.itsec.ru