1. Предпосылки и потребность

Потребность в разработке безопасных продуктов с каждым годом только возрастает. Востребованность продуктов, для которых «из коробки» обеспечивается необходимый уровень безопасности, в первую очередь, возникает на объектах критической информационной инфраструктуры (КИИ). Но только ли для них?

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

Потребность огромна, обоснована, но что с возможностями и готовностью рынка?

2. Какие методы использовались раньше?

Для начала давайте вспомним, какие методы обнаружения уязвимостей уже существуют, легко встраиваются в жизненный цикл разработки программного обеспечения (ПО) и апробированы временем.

В первую очередь, рассмотрим различные методы тестирования разработанного ПО:

«Ручные» методы тестирования:

Ревью кода – это ручная валидация кода сотрудником-разработчиком, не являющимся автором этого кода.

Функциональное и нагрузочное тестирование механизмов безопасности ПО – вид тестирования, который проверяет соответствие функциональности и отказоустойчивости (способности функционировать под нагрузкой с заявленными характеристиками) механизма безопасности продукта тому, как он был задуман.

Тестирование на проникновение – проверка защищённости продукта, при которой моделируются реальные атаки злоумышленника (хакера).

Автоматизированные методы тестирования:

Unit-тестирование механизмов безопасности ПО – автоматизированные модульные тесты, позволяющие проверить на корректность отдельные модули (небольшие части кода). Позволяет оперативно тестировать внесенные изменения в раннее разработанный код.

Статический анализ кода (SAST) – анализ исходного кода и бинарных файлов на предмет условий кодирования и проектирования, которые указывают на уязвимости. Это один из самых распространенных методов тестирования ПО на уязвимости. Тестирование осуществляется без запуска ПО (статически), проверки проводятся по принципу «белого ящика» (метод тестирования, основанный на анализе внутренней структуры и механизмов ПО, возможен при наличии исходных кодов).

Динамический анализ (DAST) – тестирование ПО во время выполнения, осуществляется по принципу «черного ящика» (метод тестирования ПО и его поведения без знания внутренней структуры), т.е. без доступа к исходному коду, и предназначено для намеренного вызова сбоев в работе ПО.

Композиционный анализ (SCA или анализ сторонних компонентов) – анализ состава ПО и выявление в нем и в сторонних компонентах уязвимостей на основе информации открытых баз уязвимостей (например, банк данных угроз безопасности информации ФСТЭК России).

Т.е. на жизненном цикле (ЖЦ) продуктов методы обеспечения безопасности распределялись[1] следующим образом (см. рисунок 1):

Рис. 1. Практики безопасной разработки на ЖЦ. Этапы выпуска релиза и предрелизного тестирования

[1] Этапы ЖЦ ПО, на которых применяются практики безопасной разработки, выделены бирюзовым цветом.

3. С чего начать развитие?

Если оценивать визуально на схеме (рисунок 1) и применительно к основным этапам жизненного цикла продуктов, наглядно видно, что основные проверки приходятся на финальные этапы (на схеме выделены бирюзовым цветом): либо перед выпуском релиза – этап предрелизного тестирования, либо в момент его выпуска. Но рентабельность такого подхода сразу вызывает вопросы с точки зрения бизнеса.

Итог прост:

Благодаря применяемым методам тестирования на рынок мы выпускаем более безопасный продукт.
Стоимость устранения уязвимостей, выявленных в результате тестирования, максимальна. Т.к. для исправления таких уязвимостей требуется переписывать, как минимум – часть кода, как максимум – перерабатывать архитектуру, если ошибка допущена на этапе проектирования.

Рассмотрим какими методами и механизмами можно снизить стоимость обеспечения безопасности продукта при его разработке. Сначала оцениваем основные этапы ЖЦ продукта по следующим критериям:

Что можно «покрыть» наименьшими усилиями, включая временные?
Что обеспечит наибольший эффект?

И здесь напрашивается применение концепции Shift-left или «максимальный сдвиг влево». При таком подходе необходимо охватить методами обеспечения безопасности продукта этапы его ЖЦ по возможности максимально сдвигаясь влево.

Как это будет выглядеть:

Этап 1. Сдвигаем все применяемые в организации методы тестирования на этап разработки (см. рисунок 2):

Рис. 2. Практики безопасной разработки на ЖЦ. Включаем этап разработки

Результаты получаем быстро и ощутимые:

1. Не требуется выделять значительное время на одномоментное выполнение всех видов тестирования. Достаточно оперативно проводить тестирование меньших блоков разработанного кода (модулей).

2. Исправление выявленных уязвимостей так же занимает меньшее время и меньше усилий, т.к. у разработчика еще «свежа информация» и не требуется повторное погружение в контекст исправляемого функционала.

3. Разработчик, столкнувшись с выявленными уязвимостями (например, с небезопасными конструкциями в коде), далее, при разработке следующих блоков кода, перестает совершать ошибки того же типа. Т.е. прямо в процессе разработки получаем повышение безопасности кода.

4. На финальных этапах при выпуске готового релиза количество выявляемых уязвимостей снижается в разы. Соответственно, уменьшается время выпуска релиза на рынок.

Этап 2. Более трудоемкий для внедрения, но позволяющий получить качественный скачок безопасности продукта изначально – охват практиками безопасной разработки этапов ЖЦ, как можно «левее».

Такой сдвиг применения практик безопасной разработки позволяет избежать «детских» (и наиболее критичных) уязвимостей в продукте. Речь идет об ошибках, допущенных на этапе проектирования, которые невозможно закрыть минимальными доработками кода, и несущих в себе высокие риски безопасности.

Приведем наглядный и критичный вариант такой ошибки проектирования: Рассмотрим продукт с распределенной архитектурой для обеспечения его отказоустойчивости. Продукт по умолчанию разворачивается таким образом, что его отдельные функциональные блоки установлены и функционируют на различных серверах. Обмен данными при таком варианте осуществляется путем прямого доступа к единственной базе данных (БД) всех функциональных компонентов этого продукта. Т.е. БД со всей информацией этого продукта «вынесена» на поверхность атаки. Быстро исправить такую недоработку архитектуры не представляется возможным, т.к. все функциональные компоненты продукта просто «не умеют» работать иначе.

Чтобы избежать изначально подобных проблем, «сдвигаем» применение практик безопасной разработки по максимуму влево (см. рисунок 3):

Рис. 3. Практики безопасной разработки на ЖЦ. Охватываем начальные этапы (от идеи до проектирования)

Какие есть практики, позволяющие повысить безопасность разработки, для более ранних этапов ЖЦ:

Идея – с учетом видов продуктов, разрабатываемых в конкретной организации, формируется некоторый набор верхнеуровневых требований безопасности, который заведомо должен учитываться при разработке каждого продукта.
Аналитика – подход, аналогичный этапу «идеи»: так же формируется перечень общих требований безопасности, но уже более детализированных, которые должны учитываться при разработке каждого продукта, выпускаемого организацией-разработчиком.
Проектирование:
· Моделирование угроз – практика безопасной разработки, позволяющая определить потенциальные и реальные угрозы для уже разработанной архитектуры продукта. Цель выполнения практики: определить существующие угрозы безопасности, их применимость, критичность и последствия; выработать меры, позволяющие закрыть, либо снизить критичность выявленных угроз.
· Принципы и паттерны безопасной разработки – «превентивная» практика безопасного проектирования. Позволяет заранее, перед или во время проектирования ориентироваться на некоторые примеры, как «правильно» проектировать (паттерны) тот или иной механизм или взаимодействие, или как категорически нельзя реализовывать конкретный механизм/взаимодействие (анти-паттерны).
Т.е., паттерны – это именно «ориентир» в проектировании, «как именно» стоит проектировать (шаблон);
а принципы – это их верхнеуровневая агрегация, т.е. «что» необходимо выполнять при проектировании.
Дополним предыдущий пример проектирования актуальным принципом и паттерном:
принцип безопасного проектирования: «Минимизация поверхности атаки»;
паттерн: «Доступ внутренних функциональных компонентов ПО к данным этого ПО осуществляется посредством доступа к выделенному API ядрового компонента ПО».

Что получаем:

Отсутствие «детских» и наиболее критичных уязвимостей, «заложенных» в архитектуру продукта.
Минимизацию уязвимостей на уровне архитектуры, соответственно и на последующих этапах разработки продукта.
Сокращение (исключение) трудозатрат на пере- или значимую доработку архитектуры при выявлении уязвимостей проектирования на более поздних этапах разработки.

Этап 3. Shift Right

Поговорили про важность обеспечения безопасности разработки до выпуска релиза продукта. Рассмотрим, что делать с этапами после. Насколько необходимо предусматривать механизмы, позволяющие обеспечивать безопасность разработанного и готового продукта после его выпуска?

Для обеспечения комплексной безопасности разрабатываемого продукта с точки зрения эксплуатации конечным пользователем, несомненно, необходимо предусмотреть дополнительные механизмы и рекомендации. Основные из которых – это:

Автоматизированный механизм инсталляции, обеспечивающий установку продукта с рекомендуемой по умолчанию базовой безопасной конфигурацией.
Руководство пользователя и администратора. Руководства должны содержать описание механизмов безопасности, возможных параметров их конфигурирования и рекомендации по обеспечению безопасной настройки.
В процессе эксплуатации рекомендуется регулярно, с некоторой периодичностью, проводить анализ эксплуатируемого продукта и его сторонних компонентов на уязвимости, ориентируясь на информацию в открытых базах уязвимостей (например, БДУ ФСТЭК России).

Для этапа «вывода из эксплуатации», с точки зрения безопасности, необходимо зафиксировать срок технической поддержки. В течение такого установленного срока организация-разработчик обеспечивает поддержку разрабатываемого продукта, включая рекомендации по безопасному (пере)конфигурированию и закрытие уязвимостей, если такие будут выявлены.

Таким образом, выполняя практики безопасной разработки на каждом этапе ЖЦ продукта, мы добиваемся его максимально возможного уровня безопасности на каждом из этапов (см. рисунок 4):

Рис. 4. Практики безопасной разработки на ЖЦ. Этап эксплуатации и ее завершение

4. Иные направления. Что важнее? И как развивать?

Цикличность ЖЦ продуктов.

Обсудили практики и методы безопасной разработки. Но необходимо рассмотреть процесс разработки в целом и оценить, какие еще существуют направления, обеспечивающие повышение безопасности разработки. Оценим процессы и методологию управления.

Процесс разработки продукта не линеен, это итерационно повторяющийся цикл основных этапов (см. рисунок 5):

Рис. 5. Практики безопасной разработки на ЖЦ. Цикличность разработки

Комплексная безопасность продуктов. Подход.

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

Рассмотрим безопасность самих процессов. Ключевые направления, необходимые для обеспечения безопасности процессов следующие:

Регламентация безопасной разработки (политика, регламенты, положение о безопасной разработке) – верхнеуровневые регламентирующие документы, определяющие направления обеспечения безопасности в организации, обязательные к использованию правила и механизмы.
Процессы и люди – регламентация каждого процесса, правила его функционирования, задействованные роли сотрудников и их зоны ответственности на каждом этапе.
Методология – детальные инструкции с рекомендациями по выполнению практики, процесса, использования конкретного механизма или сервиса.
Автоматизация – реализованная совокупность сервисов, механизмов и средств, используя которые возможно конфигурирование того или иного действия или процесса частично или полностью без участия человека.

Приоритет. Очередность.

С направлениями, востребованными к доработке в части обеспечения (повышения) безопасности разрабатываемых продуктов, определились. Но как определить, что приоритетнее? В какой последовательности дорабатывать то или иное направление? До какого уровня необходимо продолжать доработку и что считать критерием достижения цели?

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

Пример подобной связности процессов и их взаимного дополнения приведен на рисунке 6 и включает:

Рис. 6. Связность процессов безопасной разработки на примере статического анализа

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

Процессы и люди:

- разработан регламент проведения статического анализа, в котором определены этапы процесса ЖЦ, на которых должна применяться практика, прописаны условия и критерии ее применения;

- в регламенте проведения статического анализа зафиксированы роли и зоны ответственности сотрудников, задействованных при выполнении данной практики.

Методология: разработана инструкция по правилам и рекомендациям разбора выявленных уязвимостей.

Автоматизация:

- в инфраструктуре сборочного конвейера установлен и сконфигурирован статический анализатор, позволяющий проводить статический анализ кода разрабатываемого продукта (например, Svace);

- подготовлены шаблоны для конфигурирования интеграции со статическим анализатором в процессе сборки конкретного продукта;

- разработана пошаговая инструкция для конфигурирования интеграции.

Итеративность и актуализация.

Один из важнейших критериев внедрения любых изменений в процессы организации: никогда не стоит забывать про итеративный подход. Хотелось бы, конечно, с первой итерации получить идеальный программный продукт с максимально возможным уровнем безопасности. Однако подобное возможно только в теории, чаще всего при попытке достичь «идеала» получим «перекос» в одном или нескольких направлениях (регламентация, методология, автоматизация). Развивать одновременно все и с максимальным уровнем детализации долго и дорого, оперативно внедрить необходимые изменения не удастся. Чтобы подобного избежать, стоит использовать итерационный подход. Разбить модернизацию каждого направления на сопоставимое количество итераций, приоритизировать необходимые изменения, разработать план внедрения и, в соответствии с планом, последовательно вносить требуемые улучшения.

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

5. Информирование и обучение

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

И здесь нам поможет:

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

6. Результат

Теперь сведем все воедино, в единый чек-лист, что необходимо выполнить в организации для обеспечения разработки безопасных продуктов:

Безопасность процесса разработки:

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

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

Внедрены практики безопасной разработки на всех этапах ЖЦ ПО
Обеспечивается безопасность инфраструктуры, используемой в процессе разработки

Выполняются обязательные критерии:

Все модификации процессов проводятся итерационно
Все процессы и методологии регулярно актуализируются
Обеспечивается оперативное и своевременное информирование участников о планируемых изменениях
Обеспечивается обучение участников процессов практикам безопасной разработки

Результат. Что получаем.

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

И одновременно обеспечиваем минимизацию трудозатрат на выполнение практик безопасной разработки.

Практики безопасной разработки успешно применяются ведущими вендорами страны, например, компанией «ИнфоТеКС», которая входит в число лидеров российских разработчиков и производителей высокотехнологичных программных и программно-аппаратных средств защиты информации. Использование описанных подходов на практике позволяет ИнфоТеКС обеспечивать безопасность разрабатываемых продуктов экосистемы ViPNet и качественно и оперативно оказывать поддержку их потребителям.

Безопасная разработка: как обеспечить безопасность разрабатываемых продуктов