Введение и резюме

DevOps работает над созданием больших бизнес-ценностей для компаний. Это также создает новые требования, проблемы и возможности для практики кибербезопасности, которая развивается в сторону того, что часто называют DevSecOps. Хотя точное определение DevSecOps варьируется, ядро ​​остается прежним; DevSecOps - это встраивание безопасности в методы работы DevOps.

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

В наборе инструментов отсутствует ключевая возможность. Возможность, которая постоянно расширяет возможности как DevOps Teams, так и CISO:

  • Контекстуализация рисков

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

  • Действия с указанием точки

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

  • Проведение автоматизированного моделирования атак

Да, мы должны проводить этот анализ постоянно, но это просто невозможно сделать вручную. Было бы здорово интегрировать автоматизированный целостный анализ в наш CI / CD.

Эта статья включает:

  1. Проблемы DevSecOps на практике
  2. Текущее состояние рабочих процессов и инструментов DevSecOps
  3. Необходим недостающий элемент
  4. Как ведущие директора по информационным технологиям и команды DevOps используют новые возможности

1. Проблемы DevSecOps на практике

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

Давайте рассмотрим типичный иллюстративный пример: Организация - DevOpsCo - использует метод работы DevOps. В нем может быть две, десять, пятьдесят или даже сотни команд DevOps. Каждая команда разрабатывает и эксплуатирует свою часть общей системной среды компании. Нередко одна команда выпускает несколько релизов в день. И каждый выпуск, естественно, влияет на состояние безопасности среды. И не только в среде команды, но и в среде других команд и всей инфраструктуре. Эта небольшая иллюстрация сама по себе иллюстрирует как важность включения безопасности в рабочие процессы DevOps, чтобы сделать DevSecOps практически жизнеспособным, так и масштабность проблемы. Но эта динамика - лишь часть проблемы. Более длинный список ключевых проблем включает следующее:

  • Все группы DevOps выпускают частые выпуски, и каждый выпуск влияет на степень риска кибербезопасности как своей команды, так и других команд, а также всей организации.
  • Очень легко могут случиться, что команды допускают ошибки безопасности. Это лишь один из примеров того, насколько легко сделать ошибку при настройке политик IAM. Как в облачных средах, так и в локальных средах очень легко может случиться, что IAM настроен таким образом, что предоставляет слишком много / неправильный доступ, что создает слабые позиции безопасности и высокие бизнес-риски.
  • Кроме того, существует задача быть в курсе новых уязвимостей, обновлений безопасности и т. д. и помещать их в контекст того, что необходимо решать для постоянного управления рисками с течением времени.
  • Команды DevOps не являются экспертами по безопасности. Даже если мы думаем, что было бы здорово, если бы они были такими, этого никогда не будет. На самом деле это даже нежелательно, поскольку для этого потребуется слишком много ресурсов безопасности.
  • Для функции CISO крайне необходимы механизмы, которые одновременно расширяют возможности команд DevOps для автоматизированных аналитических данных и предоставляют функции CISO непрерывный обзор, отслеживание и управление состоянием рисков кибербезопасности.
  • Мы все живем в мире ограниченных ресурсов. Определение длинных списков рисков и передовых методов - хорошая отправная точка. Но нам действительно необходимо определить, какие риски являются ключевыми, какие действия дают наилучший эффект и когда наша безопасность достаточно хороша. Приоритизация должна осуществляться с комплексной точки зрения. А делать это вручную практически нецелесообразно, это слишком сложно и требует много времени.

2. Текущее состояние рабочих процессов и инструментов DevSecOps

«Sec» в DevSecOps - это не отдельный шаг или фаза, а интегрированная часть действий, необходимых для безопасной доставки программного обеспечения или услуг, как показано в типичном цикле DevSecOps.

Сегодня различные действия и инструменты программы AppSec обычно связаны с разными фазами цикла DevOps. Обучение разработчиков безопасности, анализ проекта на основе моделирования угроз, анализ дизайна и кода, а также инструменты SAST, такие как SonarQube, для проверки исходного кода - все это часть этапов планирования и кода. На этапах сборки и упаковки вы обычно обнаруживаете сканирование безопасности уязвимостей в зависимостях цепочки поставок с помощью решений от таких компаний, как debricked или Snyk.

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

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

Кроме того, непрерывное развертывание в общедоступных облачных средах, таких как Amazon Web Services, Microsoft Azure и Google Cloud Platform, создает еще более сложную ситуацию, поскольку доступны как плоскость управления (операции управления активами), так и плоскость данных (приложения и связанные с ними сервисные активы). через Интернет и часто делегируются напрямую команде DevOps.

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

3. Требуется недостающий элемент

Как описано в предыдущих разделах; DevSecOps - это естественный путь вперед для организаций DevOps. Но это также создает несколько весьма серьезных проблем. Чтобы сделать DevSecOps практически жизнеспособным, ключевую роль играет автоматизированный инструментарий. Сегодня компании обычно используют ряд автоматизированных инструментов для DevSecOps. Однако в значительной степени они представляют собой отдельные разрозненные хранилища, которые определяют отдельные списки, чаще всего длинные списки, рисков и уязвимостей.

В наборе инструментов отсутствует ключевая возможность. Инструмент, который постоянно:

  • Контекстуализирует риски

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

  • Действия с точками

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

  • Проводит автоматизированное моделирование атак

Да, мы должны проводить этот анализ постоянно, но это просто невозможно сделать вручную. Было бы здорово интегрировать автоматизированный целостный анализ в наш CI / CD.

Эти возможности позволяют командам DevOps получать непрерывную аналитическую информацию по таким ключевым вопросам, как «Достаточно ли мы защищены?», «Каковы самые слабые звенья?» и «Что из всего возможного мы должны сделать, чтобы улучшить нашу позицию в области безопасности?». И это позволяет функции CISO получать обзор и отслеживать состояние рисков безопасности и получать точную информацию, когда и где это необходимо.

4. Как ведущие директора по информационным технологиям и команды DevOps используют новые возможности

Итак, как мы можем решить проблемы и получить необходимые возможности?

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

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

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

Используя автоматизированное моделирование атак:

  • Команды DevOps автоматически и непрерывно получают информацию о степени риска кибербезопасности в своей среде. Когда подверженность риску слишком высока / позиция слишком слабая, они автоматически получают представление о слабых местах в архитектуре и предлагают действия по их снижению. Анализ может быть полностью интегрирован в конвейеры CI / CD.
  • Функция CISO автоматически и непрерывно анализирует состояние всей среды. Как со временем улучшается мое общее отношение к риску? Как выступают разные команды? Как взаимодействуют среды различных команд, когда / как одна команда создает риск для другой команды и автоматически предоставляет эту информацию командам?
  • Автоматически и непрерывно на протяжении всего цикла DevOps. securiCAD обеспечивает полностью автоматизированный углубленный анализ. Его можно легко интегрировать в конвейеры CI / CD. И это не мешает вашей живой среде, поскольку все симуляции проводятся на цифровых двойниках вашей среды.

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

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

👋 Присоединяйтесь к FAUN сегодня и получайте похожие истории каждую неделю на свой почтовый ящик! ️ Получите еженедельную дозу обязательных к прочтению технических статей, новостей и руководств.

Подписывайтесь на нас в Twitter 🐦 и Facebook 👥 и Instagram 📷 и присоединяйтесь к нашим Facebook и Linkedin Группы 💬

Если этот пост был полезен, пожалуйста, нажмите несколько раз кнопку хлопка 👏 ниже, чтобы выразить поддержку автору! ⬇