Безопасность в DevOps (DevSecOps)

Безопасность является ключевым аспектом DevOps. Но как команда знает, безопасна ли система? Действительно ли можно доставить полностью безопасную службу?

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

"В принципе, если кто-то хочет войти, они получают в... примите это. То, что мы говорим клиентам: номер один, вы находитесь в борьбе, будь то вы думали, что вы были или нет. Номер два, вы почти наверняка проникли" - Майкл Хейден, бывший директор НСА и ЦРУ.

Беседа по безопасности

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

Скептики обычно приводят следующие аргументы:

• Насколько реальна угроза? Команды часто не понимают потенциальную ценность служб и данных, которые они должны защищать.
• Наша команда хорошо справляется, верно? Обсуждение безопасности может рассматриваться как сомнение в способности команды создать безопасную систему.
• Я не думаю, что это возможно. Это распространенный аргумент младших инженеров. Более опытные коллеги придерживаются другого мнения.
• У нас никогда не было взломов. Откуда вы знаете? Как это узнать?
• Бесконечные дебаты о ценности. DevSecOps — это серьезное обязательство, и может показаться, что оно только отвлекает от основной работы. Следует найти баланс между безопасностью и другими задачами, но безопасность нельзя игнорировать.

Смена менталитета

Язык и региональные параметры DevSecOps требуют важного изменения в мышлении. Не только вам нужно предотвратить нарушения, но и предположитьих.

Компоненты стратегии безопасности

Существует множество методов, которые можно применить в поиске более безопасных систем.

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

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

Распространенные вопросы, которые следует думать, включают:

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

Основные методики DevSecOps

Существует несколько распространенных методик DevSecOps, применяемых практически к любой команде.

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

Глубинная защита практики. Когда происходит нарушение, злоумышленники могут получить доступ к внутренним сетям и всем внутри них. Хотя это было бы идеально, чтобы остановить злоумышленников, прежде чем он получит это далеко, политика, предполагающая нарушения драки команд, чтобы свести к минимуму воздействие от злоумышленника, который уже получил.

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

Стратегии устранения угроз

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

"Attack vectors" (Направления атаки).

Рассмотрим сценарий, когда злоумышленник получил доступ к учетным данным разработчика. Что они могут сделать?

Как ваша команда может защититься от этих векторов?

• Хранение секретов в защищенных хранилищах
• Удаление учетных записей локального администратора
• Ограничение SAMR
• Credential Guard
• Удаление двухдоменных серверов
• Отдельные подписки
• Многофакторная проверка подлинности
• Привилегированные рабочие станции доступа
• Обнаружение с помощью ATP и Microsoft Defender для облака

Управление секретами

Все секреты должны храниться в защищенном хранилище. Секреты включают в себя:

• Пароли, ключи и маркеры
• Ключи учетной записи хранения
• Сертификаты
• Учетные данные, используемые в общих непроизводственных средах, тоже

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

Платформы имеют функции безопасного хранения для управления секретами в конвейерах CI/CD и облачных средах, таких как Azure Key Vault и GitHub Actions.

Полезные инструменты

• Microsoft Defender для облака отлично подходит для универсальных оповещений инфраструктуры, таких как вредоносные программы, подозрительные процессы и т. д.
• Средства анализа исходного кода для статического тестирования безопасности приложений (SAST).
• Расширенная безопасность GitHub для анализа и мониторинга репозиториев.
• Mimikatz извлекает пароли, ключи, коды пин-кода, билеты и многое другое из памяти , служба подсистемы локального lsass.exeцентра безопасности в Windows. Для этого требуется только административный доступ к компьютеру или учетная запись с включенной привилегией отладки.
• BloodHound создает граф связей в среде Active Directory. Ее можно использовать красной командой, чтобы легко определить векторы атак, которые трудно определить.

Упражнения в военной стратегии

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

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

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

Развитие стратегии военных игр

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

Подготовка к военным играм

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

Упорядочение команд

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

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

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

Запуск ранних военных игр

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

Текущие военные игры

После нескольких раундов красной команде потребуется полагаться на более сложные методы, такие как межсайтовые скрипты (XSS), эксплойты десериализации и уязвимости системы инженерии. Привлечение внешних экспертов по безопасности в таких областях, как Active Directory, может оказаться полезным, чтобы атаковать более неясные эксплойты. К этому времени синяя команда должна иметь не только заклиненную платформу для защиты, но и будет использовать комплексное централизованное ведение журнала для судебной экспертизы после нарушений.

"Защитники думают в списках. Злоумышленники думают в графах. До тех пор, пока это верно, злоумышленники выигрывают" - Джон Ламберт (MSTIC)

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

Рекомендации

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

Правила поведения

Ниже приведен пример кода поведения, используемого корпорацией Майкрософт:

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

Правила участия

Ниже приведены примеры правил взаимодействия, используемых корпорацией Майкрософт:

1. Не влияйте на доступность любой системы.
2. Не обращаться к внешним данным клиента.
3. Не значительно ослабляйте защиту безопасности на месте в любой службе.
4. Не выполняйте намеренно разрушительные действия в отношении каких-либо ресурсов.
5. Сейф охраняемых учетных данных, уязвимостей и других критически важных сведений.

Конечные результаты

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

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

Уроки, полученные в Корпорации Майкрософт

Корпорация Майкрософт регулярно практикует военные игры и научилась много уроков на пути.

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

Следующие шаги

Дополнительные сведения о жизненном цикле разработки безопасности и DevSecOps в Azure.