Контакты
Подписка 2024

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

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

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

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

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

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

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

  1. Приказ № 76 "Требования по безопасности информации..."1, раздел IV, п. 17, устанавливает, что "тестирование, испытания по выявлению уязвимостей и недекларированных возможностей, а также анализ скрытых каналов проводятся изготовителем в ходе приемочных испытаний средства и испытательной лабораторией в ходе сертификационных испытаний средства".
  2. Приказ № 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 месяцев. Процесс очень непростой, и чем дальше, тем более сложным он становится, однако также интересным для инженеров и полезным для компании в целом.

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

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

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

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

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

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

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

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

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



  1. https://fstec.ru/tekhnicheskaya-zashchita-informatsii/dokumenty-po-sertifikatsii/120-normativnye-dokumenty/2126-vypiska-iz-trebovanij-po-bezopasnosti-informatsii-utverzhdennykh-prikazom-fstek-rossii-ot-2-iyunya-2020-g-n-76 
  2. https://fstec.ru/en/component/attachments/download/3096 
  3. https://docs.cntd.ru/document/1200135525 
  4. https://www.ispras.ru/news/isp-ran-predostavlyaet-bezvozmezdnyy-dostup-k-svoim-tekhnologiyam-srokom-na-polgoda/ 
  5. https://fstec.ru/en/component/attachments/download/3014 
Темы:ФСТЭКСертификацияБезопасная разработкаDevSecOpsЖурнал "Информационная безопасность" №2, 2022фаззинг

Инструменты и решения для защиты информации и предотвращения кибератак
Конференция | 2 апреля 2024

Жми для участия
Кибербезопасность в новой реальности
13 марта. Защита корпоративных данных: достаточно ли внедрить DCAP и DLP?
Участвуйте в онлайн-конференции!
Статьи по той же темеСтатьи по той же теме

  • Как организовать процесс безопасной разработки в 5 шагов
    Константин Саматов, Член Правления Ассоциации руководителей службы информационной безопасности
    Разберем значение процесса РБПО в организации, его создание, сложности и пути их преодоления.
  • Сертификация СЗИ – курс на РБПО
    Дмитрий Пономарев, технический директор ООО НТЦ “Фобос-НТ”, сотрудник ИСП РАН
    На рубеже 2023–2024 гг. положение разительно отличается от картины пятитилетней давности. Практики РБПО требуются повсеместно, их выполнение зачастую является одним из базовых пунктов контракта.
  • 50 лет ФСТЭК России
    18 декабря исполняется 50 лет со дня основания Гостехкомиссии СССР, которая в 2004 г. стала называться ФСТЭК России. Редакция журнала “Информационная безопасность” задала вопросы экспертам рынка, чтобы вместе рассмотреть важные вехи проходимого пути.
  • Обзор изменений в ИБ-законодательстве. Сентябрь, октябрь 2023 г.
    Анастасия Заведенская, старший аналитик Аналитического центра Уральского центра систем безопасности
    Перечень НПА для оценки применения по ПДн. Требования по защите информации для провайдеров хостинга. Проекты стандартов по КИИ.  Сертификация безопасной разработки ПО для изготовителей СрЗИ. Изменения в порядке ведения реестра значимых объектов КИИ. 
  • Traffic Inspector Next Generation: NGFW, сертифицированный ФСТЭК России
    Александр Вишняков, руководитель проектов ООО “СМАРТ-СОФТ”
    Cертифицированный универсальный шлюз безопасности Traffic Inspector Next Generation FSTEC от российской компании "Смарт-Софт", надежное решение с хорошим потенциалом развития
  • Обзор изменений в законодательстве в июле и августе 2023 г.
    Анастасия Заведенская, старший аналитик Аналитического центра Уральского центра систем безопасности
    Новые субъекты КИИ,  индикаторы риска нарушения требований при обработке ПДн, сертификация МЭ уровня сети и СУБД, импортозамещение в финансовой сфере, рекомендации Роскомнадзора, защита цифрового рубля, изменения в закон об ЭП

Хотите участвовать?

Выберите вариант!

КАЛЕНДАРЬ МЕРОПРИЯТИЙ 2024
ПОСЕТИТЬ МЕРОПРИЯТИЯ
ВЫСТУПИТЬ НА КОНФЕРЕНЦИЯХ
СТАТЬ АВТОРОМ
Кибербезопасность в новой реальности
14 марта. Онлайн-конференция. Реагирование на инциденты по информационной безопасности
Участвуйте!

More...
13 февраля 2024. Защита АСУ ТП. Безопасность КИИ
21 марта. Российские платформы виртуализации
Жми, чтобы участвовать