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

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

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

В конечном итоге, если кто-то хочет войти, он войдёт. Примите это. Во-первых, вы вовлечены в борьбу, верите вы в это или нет. Во-вторых, вас почти наверняка взломали", — Майкл Хейден, бывший директор АНБ и ЦРУ.

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

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

Ожидайте, что скептики принесут некоторые распространенные аргументы, такие как:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Векторы атак

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

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

• Хранение секретов в защищенных хранилищах
• Удаление учетных записей локального администратора
• Ограничить 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)

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

Guidelines

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

Кодекс поведения

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

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

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

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

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

Результаты

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

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

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

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

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

Дальнейшие шаги

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