«Горести и радости» практического РБПО. Взгляд РБПО-сообщества ФСТЭК России и ИСП РАН
Дмитрий Пономарёв. Работа: НТЦ «Фобос-НТ» / ИСП РАН / МГТУ им. Баумана; интересы: аудит и консалтинг построения процессов безопасной и качественной разработки ПО, анализ поверхности атаки
В этой подборке опытом «удивительных открытий» и решений практических задач в области безопасной и качественной разработки поделятся коллеги — известные в сообществе инженеры — рангом от руководителя направления до владельца компании. Мы подобрали палитру рассказчиков так, чтобы охватить максимум различных технологических профилей — чтобы и сами истории, и стилистика их рассказа оказались интересны и полезны широкому кругу специалистов.
К числу моих любимых историй относится опыт разбора поверхности атаки с одним из заявителей на сертификацию. В ходе первичного анализа программно-аппаратного решения мы обнаружили там полноценный Jabber-сервер, написанный на C++. На вопрос «Зачем вам это в сертифицируемом продукте в 2022 году?» последовал ответ: «Да просто N лет назад какой-то один клиент попросил включить "за копеечку", ну, мы и включили, а в чём дело?» Далее последовала моя мини-лекция о стоимости и целесообразности фаззинг-тестирования сетевого Stateful-протокола в рамках итак горящей сертификации, в ходе которой верное решение — «Доктор сказал: резать» — было принято через 15 минут. Мораль истории проста: убирайте из состава вашего продукта весь непрофильный «для бизнеса» код, особенно код сетевых сервисов, формирующих поверхность атаки. Особенно в случае получения вашего первого сертификата соответствия. Пара недель на рефакторинг смогут сэкономить вам месяцы работы и миллионы рублей трудозатрат, не говоря уже о повышении защищённости продукта.
Ещё одна забавная (и типичная для отрасли) история, непосредственным участником которой являлись я сам и наши друзья из «Айдеко», опубликована ранее и доступна по ссылке (см. врезку в разделе «Выводы»).
Желаю всем приятного и интересного «РБПО-шного чтива»!
Николай Костригин. Работа: руководитель отдела БРПО, компания «Базальт СПО»; интересы: развитие свободного ПО в целом и повышение доверия к нему в частности
Согласно укоренившемуся в сообществе РБПО тезису «Заимствованный код — твой код!», команда «Базальт СПО» постоянно проводит исследования программных пакетов, входящих в репозиторий свободного ПО «Сизиф» и его стабильные бранчи. Работа ведётся как самостоятельно, так и в кооперации с другими компаниями-разработчиками. Используется широкий арсенал свободных и проприетарных инструментов.
Не так давно сотрудничество в рамках Центра исследований безопасности системного программного обеспечения привело к интересному случаю, существование которого предполагалось, но на практике мало кто встречал. При исследованиях кода Qemuфаззингом было выявлено падение, получившее оценку серьёзности 6.6 по CVSS 3.1. Разработанный патч готовился к отправке в апстрим Qemu, когда выяснилось, что такое же исправление уже подготовлено другой компанией — участником консорциума, но как результат анализа срабатывания статического анализатора. Получился своего рода «выстрел Робин Гуда».
Интересные случаи, связанные с безопасностью свободного ПО, встречались в проекте «Сизиф» и раньше. К примеру, в отношении CVE-2017-1000408 и CVE-2017-1000409. При анализе кода библиотеки GNU libc, используемой в операционных системах «Альт», на подверженность этим уязвимостям выяснилось, что они были устранены в ней превентивно ещё в 2001 году.
Вообще говоря, принимая участие в разработке и доработке проектов СПО, мы относимся к РБПО-исследованиям не как к неизбежной, навязанной кем-то обузе, но как к возможности погрузиться в исходный код проекта, узнать его глубже изнутри.
Андрей Кузнецов. Работа: руководитель Центра внедрения и развития практик РБПО НТЦ «Фобос-НТ»; интересы: построение комплексных РБПО-процессов и последующая сертификация СЗИ
Современная испытательная лаборатория, стремящаяся соответствовать актуальным отраслевым стандартам, вырастает в «настоящую ИТ-компанию». Эксперты лаборатории всё больше становятся похожи на настоящих инженеров-исследователей и сталкиваются с суровой реальностью: если процесс не автоматизирован, значит, его системно не существует. Автоматизация процессов имеет первостепенное значение, поскольку обеспечивает воспроизводимость и доступность информации о результатах тестирования для всех заинтересованных сторон, не говоря уже о кратном ускорении процесса испытаний.
Комплексный подход к тестированию разрабатываемого программного обеспечения — это то, чего требует регулятор. Различные виды статического и динамического анализа (в том числе фаззинг-тестирования) позволяют обнаруживать ошибки и уязвимости, в том числе неочевидные проблемы безопасности и качества реализации, на ранних стадиях разработки, что способствует повышению надёжности и стабильности работы ПО, многократному снижению затрат на экстренные исправления проблем, «ушедших в прод».
Когда-нибудь эксперта лаборатории заменит бездушный и беспристрастный робот, но пока этого не случилось, экспертам необходимо самостоятельно вживлять себе, а иногда и придумывать «кибернетические руки».
Одним из процессов, который нам приходится автоматизировать регулярно, является фаззинг-тестирование — полезная, но нетривиальная практика. Когда же его выполняют разрозненные группы инженеров на своих ноутбуках, то даже простой сбор артефактов превращается в настоящее испытание, а уж их анализ — и подавно в непроходимый квест. Несколько раз обжёгшись, мы решили организовать в лаборатории собственный конвейер фаззинг-тестирования, автоматизирующий этапы:
- определения поверхности атаки программного обеспечения (данная практика является наиболее творческой, её автоматизация находится в стадии проработки);
- подготовки набора входных данных;
- запуска реализованных фазз-тестов;
- триажа и заведения задач по исправлению багов, обнаруженных в ходе фаззинга.
Заручившись поддержкой и вычислительными мощностями коллег из ОрлГУ, мы построили «кибернетическую руку», использующую более 400 процессорных ядер и 500 Гб оперативной памяти для решения наших фаззинг-задач. Как результат, уже за первый месяц пилотной работы конвейера число поданных в апстрим найденных багов (и даже уязвимостей) исчисляется десятками.
Дмитрий Сорокин. Работа: технический директор компании «Базис»
На этапе внедрения безопасной разработки в наши продукты и проведения первичного аудита безопасности и качества кода наша команда инженеров столкнулась с неожиданной находкой: анализ выявил критические уязвимости в 150 библиотеках одного продукта. А до окончания спринта и выхода в релиз оставалось всего две недели. После проведённого анализа потребовалось выяснить, откуда взялось такое количество уязвимостей и как их исправить в такой короткий срок. На проведённом митинге с командой разработки после долгого разговора выяснилось, что все библиотеки относились к части неиспользуемого, устаревшего кода, о котором все, естественно, благополучно позабыли, пользуясь правилом «работает — не трогай».
Таким образом, просто избавившись от ненужного придатка в продукте, команда доблестно выявила критические уязвимости и также не менее доблестно их закрыла одним движением руки. С того момента команда разработки не оставляет устаревший код, но команда инженеров по безопасной разработке пристально за этим следит. А с появлением в нашем арсенале инструментов, созданных инженерами ИСП РАН и CodeScoring, мы повысили контроль за качеством и безопасностью нашего кода и выпускаемых нами продуктов. Это, в свою очередь, гарантирует надёжность и безопасность продуктов компании «БАЗИС».
Антон Гаврилов. Работа: владелец продукта Axel PRO; интересы: безопасная разработка / разработка безопасного ПО и всё, что с ней связано
Многие в разговорах про безопасность видят только «лишения» и «ограничения». Однако зачастую практики РБПО могут помочь и разработчикам.
Знание объекта защиты — одна из самых базовых и важных вещей в информационной безопасности. Также и с разработкой безопасного ПО. Важно понимать, из чего оно состоит, и по возможности минимизировать количество «лишних» компонентов. При этом важно не забывать, что «чужого кода» не существует: всё, что есть в ПО, оно «ваше».
Мне довелось участвовать в процессе сертификации достаточно «массивного» ПО, в котором присутствует очень много различных сервисов, работающих вместе, как единый организм.
В процессе изучения пакетов и образов контейнеров мы с разработчиками выяснили, что:
- для сборки многих образов используются похожие базовые образы; именно что похожие: golang:1.20.7, golang:1.20, golang:1.20.6, golang:1.20.14 и т. д.;
- в дистрибутиве содержатся образы, которые более не используются для корректной работы ПО;
- в дистрибутиве содержатся пакеты и образы разных версий, некоторые из которых не используются вовсе.
Почему это так? Ответ, как и всегда: «Исторически так сложилось». Да, где-то «недосмотрели», где-то «забыли», где-то «не знали».
В той выборке, о которой я говорил, суммарно получилось около 3000 разных пакетов в базовых образах контейнеров. Да, уникальных было в разы меньше, но как всё это поддерживать и анализировать, непонятно.
Было принято решение «всё почистить» — по возможности привести все базовые образы к единому «знаменателю», удалить ненужное и оставить только то, что реально используется.
В итоге осталось несколько базовых образов (ввиду специфики их «содержания»), а количество пакетов в них — не более 250 штук. Аналогичная ситуация (пусть и с меньшим «разбросом») получилась и с пакетами дистрибутива.
Да, классическая «инвентаризация», с которой начинается (практически) любая книга по информационной безопасности. Такой подход позволяет не только повысить уровень ИБ за счёт «отсечения лишнего», но и помогает разработке: вместо того чтобы поддерживать n базовых образов, можно поддерживать один и быть уверенным в том, что именно передаётся конечному пользователю и с какой версией.
Анатолий Карпенко. Работа: инженер по автоматизации, Luntry; интересы: программная инженерия, безопасность ПО во всех её аспектах, надёжность ПО
В любой момент, всегда есть уязвимости, вероятность наличия НДВ, нежелательной функциональности. Этого не нужно бояться, нужно принять как факт и уметь работать в такой ситуации. Один из примеров — случай с CNI Calico. Проблема заключалась в том, что по умолчанию он отправлял телеметрию из инфраструктуры клиента своим разработчикам. Это было обнаружено совершенно случайно.
В этом и подобных случаях достаточно поправить флаги конфигурации запуска, но есть ещё куча других менее известных и документированных проектов, которые затаскивают разработчики к себе. Как они ведут себя, не очень очевидно, и это всё может привести к компрометации данных клиента. Поэтому к любому коду, как своему, так и стороннему, надо относиться с недоверием и выстраивать ZeroTrust-инфраструктуру.
Одним из подходов является уменьшение поверхности атаки и следование принципу наименьших привилегий, например, с помощью контейнеров. Оркестратор контейнеризированных приложений (например, Kubernetes) позволяет не только применить харденинг для самого контейнера (запретить запуск недоверенных файлов, сделать файловую систему доступной только на чтение и ограничить права пользователя), но и сделать ограничения на уровне самого оркестратора (настроить сетевые политики, мандатный доступ и т. д.). Экосистема вокруг контейнеризации позволяет организовать детектирование подозрительной активности, реакцию на неё, а в некоторых случаях вообще предотвратить её появление.
А как насчёт парадокса: безопасного ПО нет, а безопасная разработка есть? Тут все процессы надо внедрять, так как синергия безопасной разработки с безопасной эксплуатацией даёт максимальный успех, ведь всё это делается не ради процесса, а ради конечного результата.
Всем РБПО!
Алексей Смирнов. Работа: основатель и генеральный директор Profiscope / CodeScoring; интересы: полезные инструменты анализа программного обеспечения
Мы у себя в CodeScoring постоянно собираем и проверяем информацию про мировой Open Source. Эти данные нужны для защиты цепочки поставки и повышения точности композиционного анализа ПО. Собираем данные про сами компоненты (библиотеки) и их свойства, например: информация про уязвимости, патчи, эксплойты, а также данные о версиях, авторах компонентов, датах релизов и пр. Эти данные мы обрабатываем и зачастую узнаём много интересного, чем было бы полезно поделиться с сообществом.
В частности, мы постоянно строим и анализируем SBoM от множества открытых проектов. SBoM — перечень компонентов ПО, в котором указываются их версии и дополнительная информация об уязвимостях и условиях использования (лицензиях). В России он называется ППК — перечень программных компонентов.
Однажды сформировав для своего ПО такой перечень, возможно проводить его актуализацию и следить за тем, какие уязвимости были обнаружены уже после того, как вы включили сторонний компонент к себе «под капот».
С одной стороны, формирование такого списка помогает более удобным образом следить за тем, сколько всего стороннего и с какими проблемами мы поставляем нашим заказчикам. С другой стороны, после выпуска даже самого «чистого» и безопасного продукта нет гарантии, что в сторонних компонентах со временем не обнаружатся новые проблемы. Поэтому ППК следует перестраивать (обогащать) и следить за новостями.
Наши последние расчёты показали, что в среднем ПО без обновлений за один год накапливает 100 (сто!) новых уязвимостей, из которых 10–15 являются эксплуатируемыми.
Отсюда следует логичный вывод, что, оценивая безопасность ПО, которое вы хотите использовать у себя, достаточно познакомиться с его динамикой релизного цикла. Если релизы раз в полгода, то есть над чем задуматься.
Следить за подобными проблемами помогает понятие композиционного анализа, которое было поставлено в один ряд со статикой и динамикой в обновлённом стандарте по безопасной разработке (ГОСТ 56939-2024). Верим, что осознанность использования сторонних компонентов и практики безопасной работы с ними будут только усиливаться.
Марк Коренберг. Работа: технический директор ООО «Айдеко»; интересы: сноуборд, путешествия, инвестирование
В «Айдеко» мы ответственно подходим к кодовой базе, её минимизация и анализ занимают важную роль в процессах разработки безопасного ПО, и эта работа проводится нами самостоятельно, без давления со стороны регуляторов.
Так, во время сертификационных испытаний межсетевого экрана Ideco UTM специалисты «на спор» решили поискать интерпретируемый код и, что удивительно, нашли два избыточных интерпретатора, хотя главный архитектор был уверен, что ничего, кроме Python-кода, в составе дистрибутива нет. Ими оказались не используемый нигде Perl, который подтягивался из-за зависимостей, а ещё движок Mozjs из состава Firefox, который использовался для системы конфигурации очень популярного демона Policykit. В этом демоне конфигурация пишется на JS, а сам демон отвечает за систему раздачи прав пользователям и работает с root-привилегиями! В итоге Perl удалили из системы с помощью патчей компонентов, убирающих ненужную функциональность, и добавили проверку, чтобы он гарантированно не мог быть установлен. А PolicyKit переписали на Python, тем самым сократив кодовую базу. Такой подход позволил существенно упростить прохождение сертификационных испытаний.
Во время аудита и предварительной подготовки к сертификации процессов безопасной разработки мы нашли то, чего не должно быть в продукте (речь идёт о программе-агенте для рабочих станций), а именно библиотеки libGLX и libOpenGL. Это было похоже на настоящие археологические раскопки, и оказалось, что корень проблем — неверно собираемый фреймворк Qt, который по зависимостям притягивал много библиотек, без которых вполне можно обойтись.
Без использования OpenSource ПО написать современное решение невозможно. Но и с ними — опасно, поэтому регулярное устранение ненужной кодовой базы, обновление, различные виды анализа системы и кода, тщательный выбор компонентов и поставщиков ПО — это необходимость для безопасной разработки программного обеспечения в условиях увеличения функциональности продукта и роста команды разработки.
.png)
