Безопасная разработка: адаптивная эволюция

Постановка задачи

Для определения решения, подходящего именно вам, мы рекомендуем рассмотреть классическую триаду:

• Процессы. Как сделать интеграцию процессов ИБ, ИТ и разработки максимально простой и прозрачной? Какие ИБ-процессы задействованы при защите приложений? На что обращать внимание?
• Люди. Кто и что должен делать? Где найти необходимые компетенции? Что можно автоматизировать, а что лучше продолжать делать вручную?
• Технологии. Какие решения применять? На что обращать внимание при формировании технологического стека? Что из существующих наработок можно использовать?

Ответы на эти вопросы помогут определиться с собственной картиной мира и понять, что для вас означает безопасная разработка и DevSecOps, ведь универсального ответа попросту не существует.

Процессы

Одна из возможных проблем, с которой сталкивается ИБ при погружении в мир безопасной разработки, заключается в том, что она «слишком справа», ближе к эксплуатации. Что это значит? Представим жизненный цикл разработки ПО в виде прямой линии (процесса) — от сбора требований до эксплуатации (см. рис 1).

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

Кроме разногласий с командами разработки, это приводит к увеличению стоимости ПО. Почему? Потому что тратится время. Время безопасности и разработки.

Еще в 2002 г. исследователи Американского национального института по стандартам (NIST) в отчете «The Economic Impacts of Inadequate Infrastructure for Software Testing» показали, что стоимость устранения дефектов, найденных в коде, зависит от времени их обнаружения (см. таблицу):

• дефект, найденный и устраненный на стадии проектирования архитектуры, стоит 1*Х, где Х — человеко-часы, выраженные в денежном эквиваленте;
• аналогичный дефект, обнаруженный на этапе интеграции и тестирования, будет стоить уже 10*Х.

Чем раньше обнаружен дефект, тем меньше стоимость его устранения. То же относится к уязвимостям в исходном коде и нарушениям требований в области ИБ — их можно приравнять к дефектам кода.

Для решения этой проблемы используется подход Shift Left: безопасность начинают привлекать к разработке ПО начиная со стадии проектирования. При этом ИБ подключается не просто как «контролер», а как активный участник рабочей группы, который вносит свой вклад в проектирование приложения или сбор функциональных требований. Это позволяет, хотя и не в полной мере, реализовать концепт Security By Design.

Далее ИБ определяет Security Gates — точки контроля по информационной безопасности, которые встраиваются в pipeline. Диалог с командами разработки очень важен и на этой стадии. Ведь если добавить безопасность повсюду, можно получить огромное количество данных, которые необходимо анализировать, а по результатам делать выводы и принимать решения. Это не всегда необходимо, а кроме того, требует больших ресурсозатрат. Например, контроль над DEV-средой может быть менее серьезным, чем над PROD-средой. А вот контроль feature-ветки при разработке ПО может содержать все проверки: анализ исходного кода, сканирование контейнеров, проверку используемых библиотек. Только после их успешного прохождения код получает возможность merge’a в master-ветку репозитория. В самой же master-версии большое количество проверок может отсутствовать (предполагаем, что код из feature-ветки не поменялся и попал в master в том виде, в котором был согласован). ИБ может быть одной из сторон, которая должна согласовать код, для того чтобы master-ветка обновилась.

Более детально о проверках и их месте в pipeline расскажем чуть позже (в блоке «Технологии»).

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

Управление рисками ИБ. Решение о реализации ИБ или новой killer-feature (которая может быть уязвимой) принимает не безопасность, а бизнес-владелец приложения. Задача ИБ — показать, какие риски может принести реализация нового функционала в текущем исполнении. Дальше нужно действовать по обстоятельствам: отойти в сторону и настроить exception в системах мониторинга и сканирования, реализовать «запрет» или совместными усилиями с разработчиками и ИТ-специалистами придумать комплекс компенсирующих мер.

Управление инцидентами ИБ. Необходимо понять, что является инцидентом ИБ при разработке ПО. Например, это может быть нарушение SLA об устранении критичной уязвимости или же все, что подходит под классификацию инцидентов ИБ, принятую в компании для ПО в продуктиве.

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

Управление доступом. При разработке используется большое количество секретов (ниже, в пункте Secret Management, мы рассказываем, что это такое), которые необходимы для взаимодействия сервисов: требуется выстроить корректную ротацию, организовать процесс управления доступом к системе версионности кода и хранилищу артефактов ПО, например, с использованием групп AD.

Управление регуляторными требованиями (compliance) релевантно для компаний, которые подпадают под действие стандартов или федеральных законов, устанавливающих требования в том числе к обеспечению ИБ при разработке ПО.  Пример — требования PCI/DSS, в которых указано, что не следует использовать реальные данные для нужд тестирования/разработки.

Управление взаимодействием с подрядчиками. Необходимо убедиться в том, что код, который получает компания от третьих лиц, не содержит уязвимостей или backdoors. Это можно установить с помощью сканирования исходного кода и проведения ручного анализа. А что делать потом? Как вариант, можно разработать формы SLA, которые будут явно указывать на необходимость устранения уязвимостей внешней стороной в случае их обнаружения.

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

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

Новые процессы лучше создавать, общаясь с командами разработки. Они смогут подсказать ИБ оптимальные варианты, которые устроят обе стороны. ИБ может попутно объяснять, что такое безопасность и зачем она вообще нужна, почему грамотно выстроенная функция минимально повлияет на разработку.

Если вы думаете, что разработчики будут сопротивляться, просто посмотрите на данные отчета «DevSecOps Realities and Opportunities» (см. рис. 2).

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

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

Люди

Формирование правильной процессной карты ИБ, необходимой для обеспечения безопасности разработки, поможет ответить на вопрос «Что надо делать?». Ну а следующий вопрос, на который желательно получить ответ, — «Кто будет это делать?». Выше мы описали ряд трудностей, с которыми можно столкнуться в поисках ответа. Приведем наиболее актуальные из них.

• Адаптация существующих и создание новых процессов влекут за собой огромное количество активностей, которые повышают загрузку специалистов.
• Необходимо наладить взаимодействие с большим количеством команд разработки в условиях, когда подход «one size fits all» не работает (хотя бы из-за вероятности использования различных методологий разработки и технологического стека).
• Где взять людей, которые обладают необходимым набором компетенций? В вузах, например, будущим ИБ-специалистам дают лишь основы разработки на первых курсах, а разработчикам вряд ли читают лекции об ИБ.

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

Есть несколько возможных вариантов решения проблемы:

• Расширение штата ИБ. Потенциально возможный способ при наличии необходимых мест в организационно-штатной структуре, фонда оплаты труда и свободных специалистов необходимой квалификации на рынке (хотя найти их вряд ли удастся).
• Аутсорсинг и/или аутстаффинг. Даже при условии, что вы найдете компанию, оказывающую подобные услуги, в реалиях Российской Федерации этот способ вряд ли заработает: придется давать доступ «сторонним» людям к самому «святому» — исходному коду программного обеспечения. И не просто давать, а давать для анализа на наличие уязвимостей и несоответствий требованиям в области ИБ.
• Стажерские программы. Неплохой способ, однако у него есть недостаток: программы длятся долго, к тому же найти сильную команду менторов, способных «быстро воспитать» подрастающее поколение, сложно. Вряд ли кто-нибудь согласится выделить много времени на запуск приложения в production. Скорее всего, риски будут приняты, а проблемы станут решаться по мере появления.

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

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

• Найти человека из команды разработки, которому интересна информационная безопасность. Как это сделать? Достаточно просто: пойти и поговорить с коллегами, объяснить им, что предполагается делать, и спросить, кто хочет поучаствовать в «эксперименте». Мы рекомендуем выбирать из команд, которые наиболее лояльны по отношению к ИБ, так как последующие Security Champions смогут перенимать опыт «первопроходцев» и им будет чуть проще.
• Показать и рассказать, какие требования в области ИБ (применительно к разработке ПО) существуют в компании и как их трактовать.
• При необходимости провести общий курс по информационной безопасности: объяснить, что такое конфиденциальность, целостность, доступность информации, что такое CVE, зачем отправлять логи в SIEM (а также, что такое SIEM).
• Предоставить этому специалисту все необходимые инструменты — например, статический анализ исходного кода, инструментарий по сканированию образов контейнеров (об этом подробнее будет рассказано в следующем разделе).
• Научить пользоваться предоставленными инструментами: провести очные курсы, «показать консоль», предоставить техническую документацию (например, описание API). Разработчик поймет, как он может максимально автоматизировать собственную деятельность с точки зрения ИБ.

Основная цель — сформировать понимание важности обеспечения ИБ у разработчика и предоставить ему возможности для реализации поставленных перед ним задач. Еще одна функция Security Champion — минимизировать количество проблем ИБ путем распространения полученных знаний среди остальных членов команды. В итоге получается, что «интерфейс ИБ в команду разработки» — это мостик, который связывает два мира, ранее практически не пересекавшихся.

«Приоткрывать дверь в мир ИБ» нужно не только для Security Champions. Необходима и обратная связь — погружение ИБ-специалистов в мир разработки. В какой-то степени эту задачу возьмет на себя Security Champion, но ограничиваться этим не следует. Например, можно приглашать ИБ-специалистов на обсуждение функциональной архитектуры или планирование спринтов, что позволит устранить принцип «остаточности» при решении вопросов ИБ (может быть, не в полной степени, но начало будет положено!).

Помимо внедрения взаимного обучения, также рекомендуется изменить «каналы взаимодействия» — адаптировать ИБ для использования инструментария, привычного и понятного разработчику. Почта? Нет, зачем? Есть JIRA и Slack. Документы в формате *.docx? А может быть, лучше Confluence (у него даже мобильное приложение есть!)? Отчеты в Excel и CSV? Возможно. Но что, если подумать об использовании API и прямой интеграции, например, с git-системами?

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

Технологии

Мы определили, «что нам надо делать», подумали над тем, «кто это будет делать». Осталось найти ответ на вопрос «Какими инструментами пользоваться, для того чтобы сделать это максимально удобно и быстро?».

Это особенно актуально при постоянно увеличивающейся скорости разработки ПО и сокращении Time-to-Market.

Как можно максимально быстро решить проблему, возникающую из-за потребности в большом количестве различного рода проверок? На ум приходит только одно: автоматизировать все, что только можно! И этот концепт отлично соответствует современным реалиям, в которых используются специализированные решения, позволяющие автоматизировать весь процесс сборки и развертывания приложений (например, CI/CD tools). Важно, чтобы каждый инструмент, применяемый для защиты, был «на своем месте». Что это значит? Вспомним наш конвейер разработки (см. рис. 1) и рассмотрим, что применять на каждом этапе. Да, практически в каждый этап может быть встроено средство, позволяющее автоматизировать часть задач ИБ!

Разработка ПО

Commit Hooks. Даже не внедряя какие-либо дополнительные средства, информационная безопасность может частично автоматизировать деятельность с помощью имеющихся инструментов. Большинство git-систем позволяют добавлять «согласующих», без одобрения которых исходный код не попадет в master-версию. В качестве одного из таких согласующих можно добавить информационную безопасность.

SAST.  На этой стадии можно применять одно из самых известных решений — статический анализатор исходного кода (Static Application Security Testing, SAST). В названии анализатора не зря указано «статический»: SAST позволяет проанализировать весь код приложения (который является «статичным», «написанным на бумаге»), чтобы обнаружить уязвимости и потенциальные проблемы в информационной безопасности еще до его запуска (execution).

Вот что, например, могут содержать результаты анализа исходного кода.

• Информацию о том, что используются некриптостойкие библиотеки шифрования или возможна реализация SQL-инъекции.
• Идентификацию того, что для проверки отсутствия в пароле части логина (admin/admin123) используются регулярные выражения. Представьте, что злоумышленник создаст логин вида «(x+x+)+y», а пароль будет «xxxxxxxxxxxxxxxxxxxxxxxxxx». При использовании регулярных выражений потребуется совершить более 2 млн операций, что, скорее всего, вызовет отказ в обслуживании сервиса. От проверки применения регулярного выражения к строке лучше воздержаться, логика работы ПО детально описана по ссылке: https://www.regular-expressions.info/catastrophic.html.

Многие SAST-решения, представленные на рынке, позволяют интегрироваться в CI/CD-pipeline, что помогает автоматически запускать тестирование, как только разработчик совершит обновление кода в системе контроля версий. От ИБ-специалистов не требуется ничего! Разве что внедрить и настроить решение надлежащим образом. Некоторые производители SAST предоставляют надстройки, которые интегрируются в Interactive Development Environment (IDE) — программы, используемые разработчиками для написания кода (например, Intellij IDEA, Visual Studio). Таким образом, разработчик может получать уведомления о потенциальных ошибках прямо во время работы, что способствует максимально раннему обнаружению и устранению погрешностей.

У решений этого класса есть недостатки, которые обусловливаются срабатываниями false positive или negative: возможен сценарий ошибочной идентификации уязвимости и, наоборот, пропуска присутствующей. Решению этой проблемы в том числе были посвящены первые два раздела статьи. При обнаружении false positive разработчик может обратиться к Security Champion для разбора ситуации с последующим информированием ИБ-специалиста. Иногда бывают случаи, когда разработчик не может устранить уязвимость из-за сложности реализации задачи. Тогда он просит ИБ-специалиста внести исключение (exception) в логику работы SAST — применение раздела «Люди». Последний, в свою очередь, знает, что делать дальше, — ведь процесс управления рисками теперь учитывает потребности команд разработки! После получения ответа от владельца продукта происходит оценка ситуации: можно ли делать exception или разработчику придется искать альтернативные способы решения проблемы (применение раздела «Процессы»)?

Сборка приложения

SCA. Исходный код проверен на наличие уязвимостей, началось время сборки. На этом этапе могут помочь решения класса Software Composition Analysis (SCA). SCA позволяют определить полный перечень компонент open source, используемых при разработке приложения (например, frameworks, plugin, библиотеки).

Также решения помогают идентифицировать потенциальные проблемы в найденных артефактах. Указанные проблемы не всегда заключаются в том, что библиотеки содержат уязвимости или их «срок действия истек». Бывают случаи, когда подключаются библиотеки open source, обладающие лицензионными соглашениями.

Вот один из потенциальных сценариев использования SCA. Допустим, стало известно об уязвимости нулевого дня в какой-либо библиотеке. Как конкретной команде разработки понять (и быстро), используется ли уязвимая библиотека в ее ПО, а ИБ-специалистам оценить глобальный масштаб проблемы в рамках компании? Как раз в этой ситуации SCA сможет помочь как ничто другое. Уязвимая библиотека будет идентифицирована, варианты «альтернативных библиотек» предложены самим решением, и останется только установить обновление или перейти к аналогичной проблеме, что займет время и ресурсы, но спасет от уязвимостей нулевого дня.

SCA-решения могут быть интегрированы в CI/CD-pipeline для автоматического запуска проверки ПО на наличие проблем, обусловленных использованием решений open source. Некоторые производители предоставляют специализированные надстройки для наиболее популярных инструментов CI/CD, что упрощает интеграцию.

Тестирование и развертывание ПО

DAST. На стадии разработки программного обеспечения мы рассматривали статический анализ кода: приложение только создавалось и не было готово к запуску. На стадии тестирования и развертывания ситуация изменилась: приложение работает, осуществляются тестирования различного вида (функциональные, нагрузочные). А безопасность начинает использовать динамические анализаторы (Dynamic Application Security Testing, DAST).

Ключевым отличием DAST от SAST является период тестирования. SAST анализирует приложение до запуска, DAST — после. Можно сказать, что SAST использует подход whitebox, а DAST — blackbox. С одной стороны, это плюс (можно проанализировать приложение, полученное от контрагента), с другой — минус (для проведения качественного DAST-тестирования требуется полная сборка приложения).

Зачастую тестирование с помощью DAST применяется для анализа веб-приложений. Решения этого класса позволяют выявлять уязвимости, обусловленные различного рода инъекциями кода в запрос (например, к веб-странице) или связанные с некорректной конфигурацией (самый простой пример — возможность аутентификации по пустому паролю). Ввиду ограниченного функционала, DAST не может быть сам по себе эталоном для оценки защищенности приложения, однако преимущества делают его хорошим дополнением к общей картине, включающей SAST и SCA. Так, DAST не привязан к языкам программирования, для анализа не требуется исходный код, а также происходит незначительное количество ложноположительных срабатываний или они отсутствуют вовсе.

Кроме того, стоит добавить, что DAST может быть интегрирован в CI/CD-pipeline для автоматического запуска сканирования.

Эксплуатация приложения

WAF. Web Application Firewall — межсетевой экран прикладного уровня, основной задачей которого является защита приложений, доступных online. Сперва может показаться, что это очень «ограниченное» решение, направленное на защиту одного класса приложений. Однако практически каждый слышал о переходе в digital, одним из аспектов которого является предоставление сервисов клиентам по всем возможным каналам в любое время, в том числе через веб.

Задача WAF — контроль http/https-трафика между пользователем и веб-приложением. Он позволяет идентифицировать и защищать приложения от наиболее известных атак, информация о которых регулярно публикуется OWASP (Open Web Application Security Project), например:

• инъекции, они же «внедрение кода»;
• некорректная аутентификация;
• ошибки в настройке;
• межсайтовый скриптинг (XSS);
• подделка межсайтовых запросов (CSRF);
• использование компонентов с известными уязвимостями;
• недостаточные логирование и мониторинг.

WAF выступает в роли щита между веб-приложением и пользователем, что позволяет перехватывать http/https-трафик и реализовывать действия согласно настроенным политикам — например, блокировать трафик, если была идентифицирована попытка SQL-инъекции.  В таком случае трафик не дойдет до конечного потребителя (веб-приложения) и работоспособность сервиса не нарушится или не будет совершена кража конфиденциальных данных компании. В другом сценарии WAF разрешает только «доверенный» трафик, который был заранее определен (whitelisting-подход).

Возможен альтернативный вариант использования WAF — виртуальный патчинг (грубо говоря, использование настроек WAF для создания видимости установки несуществующего обновления, которое выполняет необходимый функционал). Допустим, существует скрипт, который некорректно проверяет входные данные, что создает возможность внедрения произвольного SQL-кода. Есть несколько вариантов решения проблемы:

• «Классический» патчинг. Скорректировать скрипт, переписав логику его работы, и добавить фильтрацию данных, получаемых извне.
• «Виртуальный» патчинг. Настроить WAF таким образом, чтобы он проверял передаваемую в скрипт нагрузку (payload) на наличие запрещенных элементов.

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

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

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

• Безопасность кластера. Эта часть мало чем отличается от «классической» информационной безопасности. Задача — защитить ноды (серверы, хосты) кластера, используемые для функционирования среды контейнеризации. Для этого стоит обращать внимание на:
  
  • использование встроенных механизмов хостов для повышения уровня ИБ (hardening);
  • управление сетевыми потоками между нодами кластера;
  • сканирование хостов на уязвимости.

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

• Безопасность оркестратора. Среды оркестрации (например, на базе Kubernetes) обладают встроенным функционалом, который можно использовать в интересах информационной безопасности:
  • управление namespaces, включая распределение контейнеров по нодам в зависимости от их значимости для компании (например, все контейнеры, которые входят в скоуп PCI DSS, должны «подниматься» только на специально отведенном сервере);
  • управление pod security policy (политиками безопасности, которые определяют возможности и ограничения контейнеров);
  • управление ограничениями запускаемых контейнеров (управление квотами на использование ресурсов, применение функционала AppArmor, SELinux, cgroups);
  • обеспечение сетевой безопасности при взаимодействии контейнеров (как между собой, так и с внешними ресурсами).

• Безопасность образов. Контейнеры создаются из образов (аналог template виртуальных машин), которые могут быть получены из внешних или внутренних реестров либо создаваться разработчиками в рамках CI/CD-pipeline. Обеспечить безопасность образов рекомендуется на всех этапах.
  • удаление «лишнего» (например, в образе контейнера в момент разработки требовался уязвимый curl, а впоследствии потребность в нем пропала, поэтому проще удалить ненужный уязвимый компонент, чем пытаться его обновить);
  • «подпись» образов, гарантирующая, что контейнер запускается только из образов, целостность которых контролируется;
  • встраивание проверок образов в CI/CD-pipeline для автоматизации сканирования на наличие уязвимостей и compliance-несоответствий (например, запуск контейнера из-под привилегированной учетной записи, незащищенные системные файловые каталоги, завышенные права системных пользователей, включенные ненужные системные службы и т.д.);
  • сканирование образов в частных и публичных реестрах, используемых компанией;
  • управление контролем доступа к реестрам.

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

• Управление доступом и секретами. На каждом из «уровней» — от ноды до контейнера — присутствует множество разных сущностей, взаимодействующих между собой. Для них необходимо выполнить следующее:
  • разработать ролевую модель, описывающую, кто и с какими правами имеет доступ, например, к оркестратору, реестру с образами контейнеров, к конкретному namespace и т.д.;
  • управлять секретами — паролями пользователей, сервисными учетными записями, токенами для аутентификации в сторонних сервисах, выстроить корректное управление инфраструктурой открытых ключей.

• Мониторинг и аудит ИБ. Для того чтобы было проще идентифицировать инциденты ИБ и анализировать, насколько требования в области ИБ исполняются в реальной жизни, а не просто «на бумаге», рекомендуется:
  • реализовать управление событиями для передачи данных, например, в SIEM-системы для идентификации инцидентов ИБ;
  • особое внимание уделять анализу действий администраторов;
  • периодически проверять выполнение требований в области ИБ (например, требований к hardening кластера, который описывался в пункте «Безопасность кластера»).

Для того чтобы реализовать перечисленные меры, применяется «смешанный» подход: часть выполняется при помощи встроенных механизмов (то, что относится к hardening-активностям), часть — при помощи навесных средств. Например, организовать защиту контейнеров в режиме run-time без них не представляется возможным. На рынке представлены специализированные решения, которые обладают обширным функционалом и позволяют охватить сразу несколько областей: безопасность образов, безопасность контейнеров, мониторинг и аудит ИБ, частичные активности других разделов (например, проверка того, что hardening нод кластера реализован). Кроме «корпоративных» решений, можно использовать open source (который представлен в достаточной степени) для сборки собственного «комбайна» для защиты среды контейнеризации. Большинство решений интегрируются в CI/CD-pipeline, для некоторых разработаны специализированные надстройки, что упрощает процесс внедрения и настройки.

Secret Management. При разработке ПО, особенно если задействовано множество различных сервисов (git‑системы, контейнерные среды, облачные ресурсы, реестры артефактов и т.д.), можно столкнуться с тем, что потребуется выстроить управление такими сущностями, как:

• API-токены;
• SSH-ключи;
• технологические учетные записи;
• данные аутентификации облачных сервисов;
• 509-сертификаты и другие чувствительные данные (например, пароли).

Все вместе это можно назвать одним словом — секрет. Если их немного, управление можно осуществлять вручную. Ситуация меняется, когда число таких сервисов превышает десяток. При этом в отношении секретов требования в области ИБ могут быть различными. Самый просто пример: пароли пользователей и пароли технологических учетных записей. Именно для этих целей применяются решения класса Secret Management — централизованные хранилища, предназначенные для безопасного создания, управления (доступ и распределение) и хранения различных секретов.

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

Для взаимодействия приложений между собой или приложений и БД требуются учетные данные, иногда привилегированные. Один из самых простых способов, который иногда применяют на практике, заключается в том, что учетные данные вписывают (hardcode) в исходный код, который может быть доступен лицам, не обладающим соответствующими правами. Это повышает вероятность компрометации данных или может привести к недоступности сервиса (если кто-нибудь, даже по ошибке, сможет изменить данные аутентификации). Такие недостатки можно устранить при помощи решения Secret Management: код вызывает функцию, предоставляющую ему секрет, необходимый для установки соединения. Схожий функционал есть, например, у git-систем. Важно не забывать, что мы рассматриваем ситуацию, в которой необходимо централизованно управлять большим количеством секретов разного типа.

Некоторые решения, представленные на рынке, обладают дополнительным функционалом: создание удостоверяющего центра, шифрование данных. Как и большинство приведенных в статье классов решений, системы Secret Management могут быть интегрированы (использоваться) в CI/CD-pipeline, где их помощь просто неоценима — ИБ-специалисты вряд ли смогут вручную менять большое количество секретов, используемых при автоматизированных сборках приложений.

BAS. Breach and Attack Simulation — термин, впервые введенный компанией Gartner в 2017 г. BAS — класс решений, которые используются для имитации действий реального злоумышленника при атаках на компанию. Можно сказать, что решения частично позволяют автоматизировать функционал тестирования на проникновение для идентификации потенциальных уязвимостей и для анализа корректности работы средств защиты информации. Решения BAS не способны полноценно заменить специалиста по тестированию на проникновение, но могут наглядно показать проблемы компании в области ИБ на всех этапах kill-chain (универсального сценария, описывающего действия злоумышленника). Для этого специалисты компаний-производителей формируют playbooks (сценарии действий), основанные на активностях реальных хакерских групп, таких как Fancy Bear, Lazarus Group, Dragon Fly 2, или разрабатываемые с учетом готовых фреймворков — MITRE ATT&CK.

• Разведка и вооружение (Reconnaissance and Weaponization). Задача BAS — идентифицировать возможные пути проникновения внутрь периметра компании. В качестве его анализа может быть реализована проверка корректности настройки WAF — сделаны попытки реализации SQL-инъекций, XSS, выполнения удаленных файлов на стороне сервера и т.д.
• Доставка (Delivery). Многие BAS-решения позволяют имитировать атаки типа «социальная инженерия» путем рассылки email, содержащих вредоносные файлы или ссылки на веб-ресурсы, переходы по которым могут привести к компрометации пользовательских учетных данных. Альтернативный подход — попытки эксплуатации уязвимостей веб-ресурса компании (данные о которых были получены на предыдущем этапе) для продвижения атаки «вглубь».
• Заражение (Exploitation). Проверка корректности настроек средств защиты конечных точек. Для этого BAS позволяет эмулировать различные атаки: вирусное заражение, установка троянов и червей, запуск вирусов-шифровальщиков и т.д. Вредоносный код может находиться в содержащем макросы файле MS Word, который был передан в рамках phishing-рассылки на предыдущем этапе. Помимо попыток заражения, на данном этапе BAS-решения могут попытаться собрать дополнительную информацию, пригодную для расширения поверхности атаки (attack surface): о запущенных процессах, доступных портах, сетевых папках (network share) и т.д. При каждой попытке атаки решение анализирует, смогли ли системы защиты конечных точек — антивирусы, EDR-системы, системы контроля целостности и т.д. — идентифицировать или заблокировать действия потенциального злоумышленника.

• Инсталляция (Installation). После заражения предпринимаются попытки расширения зоны присутствия за счет анализа сети и оценки возможностей латерального движения (lateral movement), что позволяет оценить, насколько злоумышленник сможет продвинуться и до каких данных добраться. BAS-решение собирает необходимую информацию: данные об операционных системах, используемых службах и портах (RDP: 3389, SMB: 445 и т.д.). Следующий шаг — попытка получить учетные данные (пароли, токены, kerberos-тикеты) из оперативной памяти. Для этого может быть использована специальная утилита mimikatz. Получив сведения об окружении и восстановив пароли, BAS пытается получить максимально возможный доступ при помощи техник, которые детально описаны в MITRE ATT&CK framework: pass the password, pass the ticket, pass the hash, kerberoasting и т.д. На протяжении атак BAS анализирует срабатывания межсетевых экранов, IPS- и SIEM-систем. По результатам сканирования формируется отчет о реализованных атаках и о реакции систем безопасности.

• Управление и действия (Command&Control and Actions). Решение имитирует попытки передачи конфиденциальной информации (например, данных платежных карт) за пределы компании, одновременно фиксируя ответную реакцию DLP-систем: была ли предпринята попытка блокировки передачи данных на личный email или нет? Эмуляция передачи может осуществляться по разным векторам: email, облачные сервисы, съемные носители и т.д.

Как организовать имитацию, максимально приближенную к реальным сценариям, без причинения ущерба вычислительным мощностям компании? Можно разместить виртуальные машины в необходимых сетевых сегментах, например, для проверки сетевой доступности. Еще один вариант — установить на вычислительные мощности компании агенты, необходимые для синхронизации с облаком производителя (многие BAS-решения представляют собой SaaS-платформы).

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

Однако и это еще не всё! Рассмотренные примеры решений по автоматизации безопасности касались в большей степени разработки и защиты кода. Но не стоит забывать, что классическая безопасность с межсетевыми экранами, антивирусами, системами мониторинга и корреляции событий ИБ остается. Она необходима в том числе для защиты рабочих станций и серверов, которыми пользуются разработчики для грамотного распределения сетевого доступа между DEV-, TEST- и PROD-сегментами, и для многого другого. Здесь мы не будем подробно останавливаться на этом аспекте, ведь рассмотреть вопросы построения контура безопасной разработки в ограниченном объеме статьи можно лишь поверхностно, а если захватывать еще и «классический» уровень, то уложиться точно не получится. В результате наш первоначальный вариант pipeline может приобрести, например, такой вид (см. рис. 4).

Так на что же следует обращать внимание при выборе инструментария для автоматизации процесса безопасной разработки? Согласно лучшим практикам:

• решения должны обладать возможностью доступа по API, Command Line и/или использовать специализированную надстройку (для встраивания в CI/CD-pipeline);
• решение в виде контейнеров в значительной степени упрощает возможность его применения;
• у решения должны быть минимальные лицензионные ограничения (например, на параллельное выполнение задач);
• итогом работы решения должен быть легко «разбираемый» результат (parsing), например xml и/или json;
• необходимо реализовать возможность подсчета false positive / false negative.

Большое количество инструментов может напугать или привести в некоторое замешательство: «Неужели всё это нужно?». Да, всё. Но не сразу. И не всем. Компании бывают разные: разные уровни зрелости, бизнес-модели. Кто-то разрабатывает ПО для внутренних нужд, кто-то — на продажу клиентам. Соответственно, возникает потребность в различных уровнях защиты ПО. Одной компании хватит SAST, а другой потребуется «полный набор» и еще несколько технологий, которые не были указаны в нашей статье. Главное — выбрать то, что требуется, и приступить к реализации намеченного плана. Необходимо внедрить SAST не просто как технологию. Нужен инструмент для решения поставленных задач с учетом потребностей разработчиков, ИТ- и ИБ-специалистов, и при этом с грамотным выстраиванием процессов. Такое внедрение требует немало времени.

При автоматизации проверок ИБ:

Заключение

Возможно, после прочтения статьи у вас возникнут вопросы. Какие процессы мне необходимо реализовать в первую очередь? У меня столько команд разработки! Мне идти ко всем и сразу с целью найти Security Champion? Столько решений для автоматизации! Что внедрить?

Мы рекомендуем погружаться в мир безопасной разработки постепенно, создавая «контур» — своеобразную «виртуальную платформу», которая должна включать в себя:

• перечень технологий (сервисов), предоставляемых информационной безопасностью командам;
• описанные процессы и инструкции, отвечающие на вопрос «Что и как делать?», доступные всем участникам процесса;
• ответственных ИБ-специалистов, к которым можно обратиться за советом.

Что это значит? Допустим, наш контур состоит из статического анализатора исходного кода (Static Application Security Testing), задокументированного процесса управления уязвимостями (отвечает на вопросы, кто запускает сканирование, у кого есть доступ к результатам, кто должен устранить уязвимости, что делать, если уязвимость не может быть устранена, и т.д.) и перечня ИБ-сотрудников, которые отвечают за администрирование SAST и процесс управления уязвимостями.

Отлично! Нашлась команда, которую необходимо подключить к нашему воображаемому контуру. Для этого мы интегрируем ее git-репозиторий исходного кода для анализа при помощи SAST, явно определяем ответственных за реализацию этапов процесса управления уязвимостями, проводим вводные семинары. У команды должны быть контакты специалистов по информационной безопасности, чтобы в случае необходимости было к кому обратиться с вопросами. И продолжаем процесс с командами, которые остались «вне контура». На деле все это обстоит несколько иначе (сложнее и длительнее), но концепт остается таким же.

Что включать в этот контур на первых этапах? Увы, универсального ответа не существует. В каждой ситуации нужен индивидуальный подход. Решение зависит от множества аспектов — начиная от организационной структуры компании, применяемых методов разработки ПО, используемых технологий и заканчивая ограничениями, к которым можно отнести и конкретную цифру выделенного бюджета, и требования регуляторных органов, и наличие/отсутствие поставщиков решений на российском рынке ИБ.

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