Configuration-as-Code
За последнее десятилетие мы убедились, что выполнение вручную процессов расследования и реагирования ограничивает нас по скорости, что сильно сказывается на возможности обрабатывать прирастающий с каждым днем поток инцидентов и угроз. Для того, чтобы помочь в решении складывающейся ситуации специалисты ИБ начинают применять в своей практике новые подходы, такие как Everything as Code (EaC), который зародился на базе практик разработки ПО.
Одна из основных проблематик обнаружения инцидентов, процедур Threat hunting и обнаружения угроз (TI) — высокая гранулярность скриптов и функций, необходимость контроля версий и учета изменений. Поэтому инженеры по информационной безопасности, стремясь повысить эффективность детекта и улучшить качество работы переняли лучшие практики из IT-разработки и назвали этот метод Configuration-as-Code. Давайте разберемся, что он из себя представляет.
Что такое обнаружение как код?
Configuration-as-Code (или CI/CD в информационной безопасности) — это разбиение процессов и процедур на максимально атомарные функции, работа с которыми ведется по образу и подобию кода: они отдельно хранятся, редактируются, версионируются, тестируются, анализируются на качество и в последующем используются при необходимости в совершенно разных процессах.
Например, процедура аудита учетной записи:
во-первых, разбивается на множество реализаций и версий в зависимости от используемых инструментов;
во-вторых, используется одна и та же процедура в разных процессах: в инцидент-менеджменте, в ассет-менеджементе и в любых других по необходимости.
Если разным специалистам надо ее скорректировать, редактироваться будет один и тот же код и все будут видеть правки друг друга.
Аналогично концепции Everything as Code (IaC) в Configuration-as-Code (CaC) применяется машиночитаемый формат файлов и описываются масштабируемые модели данных, которые позволяют построить любые инфраструктуры, не ограниченные по объемам, типам и структурам данных.
Здесь можно провести аналогию с DevOps направлением, которое использует практики, помогающие из кирпичиков выстраивать большие сложные pipeline. Так вот, процессы security management также можно декомпозировать, разделить на атомарные функции, многократно переиспользуя четко работающие винтики в большом слаженном механизме.
Подобно рабочему процессу CI/CD, процесс разработки и внедрения функций ИБ должен включать следующие обязательные этапы:
1. Идентификация логики подозрительного или вредоносного поведения;
2. Воспроизведение (моделирование) этого поведения в коде. Например, если процесс запущен из нестандартного родителя — сработка;
3. Написание различных тест кейсов для проверки работоспособности функции;
4. Включение функции в систему контроля версий;
5. Сборка, раскатка в прод, сборка билда;
6. Постоянная поддержка, обновление (процесс поддержки функции ИБ работает в PDCA цикле постоянного обновления и поддержки, для совершенно разных случаев отклонений, нарушений корректности работы).
Эти шаги показывают, что рабочий процесс Configuration-as-Code должен учитывать процедуру улучшения существующего репозитория функций ИБ. При необходимости по каждой функции можно вернуться на первый шаг и обкатать сложные операции вновь через процедуру тестирования и раскатки.
Концепция Detection-as-Code возникла из потребности в автоматизированных, систематически повторяемых и фиксируемых подходах к безопасности, что и является ее ценностью. Ранее обнаружение угроз не было полностью развито как систематическая регулярная дисциплина с эффективной автоматизацией и фиксацией результатов.
Метод обнаружения угроз, адаптированный к конкретным средам и системам, оказывает более мощный эффект. Использование хорошо написанного кода для обнаружения, который можно протестировать и проверить в системе контроля версий, позволяет инженерам создавать более качественные алерты и уменьшать количество ложных срабатываний, снижая выгорание и устраняя лишнюю активность.
Каковы преимущества Configuration-as-Code?
Преимущества Configuration-as-Code включают:
1. Создание собственных гибких средств обнаружения с помощью языка программирования;
2 Применение подхода разработки через тестирование (TDD);
3. Интеграция с системами контроля версий;
4. Автоматизация рабочих процессов;
5. Повторное использование кода.
Написание обнаружений на распространённом, гибком и удобном языке, таком как Python, имеет множество преимуществ.
Удобство и простота
Вместо использования предметно-ориентированных языков с некоторым набором ограничений, вы можете создавать более индивидуализированные и сложные методы обнаружения, соответствующие конкретным потребностям вашей инфраструктуры. Эти языковые правила также часто более читабельны и просты для понимания, что может иметь решающее значение по мере увеличения сложности.
За вас уже многое разработано
Дополнительное преимущество использования распространённого языка заключается в доступе к богатому набору встроенных или сторонних библиотек, разработанных другими специалистами по безопасности. Например, библиотеки для взаимодействия с API значительно повышают эффективность обнаружения и автоматизации.
TDD
Обеспечение качества кода обнаружения помогает выявить «слепые зоны», проверить ложные срабатывания и повысить эффективность обнаружения. Подход TDD позволяет командам безопасности предугадывать действия злоумышленников, документировать полученные знания и создавать библиотеку аналитических данных о стратегии злоумышленников и их маршрутах.
Кроме того, подход TDD улучшает качество кода обнаружения, делая его более модульным, расширяемым и гибким. Инженеры могут легко вносить изменения в свой код, не опасаясь нарушить работу алертов или ослабить безопасность инфраструктуры.
Написание обнаружений на распространённом, гибком и удобном языке, таком как Python, имеет множество преимуществ.
Системы контроля версий
При написании или изменении обнаружений в виде кода, контроль версий позволяет специалистам быстро вернуться к предыдущим состояниям в случае ошибок. Также контроль версий может предоставить необходимую информацию для конкретных обнаружений, которые вызывают алерты, или помогает идентифицировать изменения в обнаружениях.
Методы обнаружения должны эволюционировать по мере поступления новых данных. Контроль изменений — это важный процесс, помогающий командам корректировать обнаружения по мере необходимости. Эффективный процесс контроля изменений улучшает качество документирования и проверку всех изменений.
Автоматизация процессов безопасности
Инженеры по информационной безопасности, ожидавшие сдвиг в автоматизации, получат преимущества от интеграции конвейера CI/CD. Внедрение этого метода на ранних этапах процесса доставки помогает достичь двух целей:
Устранение разрозненности между командами, которые работают на общей платформе и проверяют код друг друга;
Обеспечение автоматизированных систем тестирования и доставки для обнаружения нарушений безопасности. Команды безопасности сохраняют гибкость, уделяя особое внимание созданию точных систем обнаружения.
Переиспользование своей работы
Наконец, Detection-as-Code способствует повторному использованию кода для широкого спектра обнаружений. По мере того, как инженеры по информационной безопасности пишут код для обнаружения, они начинают выявлять неочевидные закономерности и неоднократные повторения процедур. Эта декомпозиция дает возможность оптимизировать процесс и повторно переиспользовать код в аналогичных кейсах в других детектах.
Заключение
Каждая инфраструктура уникальна и требует индивидуального подхода к методам обнаружения. Концепция Detection-as-Code (DaC) позволяет инженерам ИБ создавать индивидуальные правила, регулярно проводя улучшения за счет тестирования кода, управляя версиями с помощью различных программных средств. Гибкость и надежность языков программирования позволяет выявлять как простые, так и сложные действия злоумышленников, обеспечивая при этом необходимое обогащение контекста. В рамках этого подхода специалисты даже структурируют и нормализовывают журналы в строгую схему для выполнения SQL-запросов, что помогает в исследовании отказоустойчивости при обработке больших объемов данных о событиях безопасности.
Обнаружение как код (DaC) занимает свое заслуженное место рядом с инфраструктурой как код (IaC) в рамках быстро развивающейся концепции «Everything as Code» (EaC), где каждый уровень стека выражается посредством кода.
