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

объеме ее проводить и какой ожидается конечный результат. С этого момента начинается непрерывный процесс внед- рения, улучшения, автоматизации и поддержания 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 раз. l • 41 БезОПАСнАя РАзРАБОТкА www.itsec.ru 4 https://portal.linuxtesting.ru/ Примеры минимизации необязательной кодовой базы Важнейшим аспектом испытаний, связанных с практической безопасностью, является определение кодовой базы (модулей и функции), составляющей поверхность атаки на анализируемую систему. Важнейший аспект разработки безопасного ПО – минимизация необязательной кодовой базы, в первую очередь и составляющей поверхность атаки. Год назад в ходе сертификационных испытаний межсетевого экрана Ideco UTM произошел достаточно поучительный случай. Он особенно важен, поскольку разработчики Ideco весьма ответственно относятся к собственной кодовой базе и занимаются ее минимизацией и анализом самостоятельно, без давления регуляторов. Специалисты Ideco решили "на спор" поискать в кодовой базе развернутого межсетевого экрана интерпретируемый код. Архитектор утверждал, что ничего, кроме python-кода, в составе дистрибутива нет и быть не может, однако первый же запуск grep/-name "*.pl" нашел некоторое количество perl-кода. После чего выяснилось, что он есть, и даже есть сам интерпретатор perl, хотя при этом он нигде не используется. "Раз пошла такая пьянка, режь последний огурец!" – решили поискать заодно и js, что удивительно – нашли! Откуда он там?! Оказалось, что на js (то есть прямо в формате скрипта) присутствует файл конфигурации демона policykit, реализующего систему раздачи прав пользователям и работающего с root-привилегиями. Для чтения файла конфигурации используется mozjs – js-движок из состава firefox, разумеется написанный на C. Таким образом, за 20 минут работы были найдены два избыточных интерпретатора, один из которых выполняется с root-привилегиями. Сразу были созданы тикеты. Perl удалили из системы с помощью патчей компонентов, убирающих ненужную функциональность, добавили проверку, чтобы он гарантированно не мог быть установлен. В части policy-kit самостоятельно переписали соответствующий функционал на python. Итого: сократили несколько десятков Мбайт бинарного кода и два интерпретатора, что особенно важно при прохождении сертификационных испытаний, упростили сборочный процесс. Ваше мнение и вопросы присылайте по адресу is@groteck.ru