Год назад облачная среда Datadog выросла и стала поддерживать десятки тысяч пользователей по всему миру. По мере расширения парка наших хостов вслед за ростом числа пользователей мы заметили, что наша первоначальная система сканирования уязвимостей становится менее эффективной в охвате и оценке каждого хоста.
За последний год мы перенесли сканирование уязвимостей хостов на Datadog Agent, чтобы решить эту проблему. В результате миграции Datadog Cloud Security стала системой учета результатов поиска уязвимостей хостов. Наш рабочий процесс на базе Agent теперь поддерживает актуальность сканирования на уровне выше 99%, измеряемую как процент охваченных хостов, последнее сканирование уязвимостей которых было завершено в течение предыдущих 24 часов. Это сканирование является частью нашей более широкой программы управления уязвимостями, которая поддерживает нашу работу в рамках стандартов SOC 2 Type II, ISO 27001, PCI DSS и FedRAMP® High.
Перед переходом мы должны были убедиться, что подход на базе Agent сможет удовлетворить наши требования к обнаружению, отчетности и аудиту в масштабе. В этой статье мы расскажем, почему мы пересмотрели предыдущую архитектуру, как мы сравнили два подхода в ходе шестимесячного параллельного запуска и как эта оценка повлияла на наше решение о переходе.
Почему мы пересмотрели удаленное сканирование уязвимостей хостов
Мы хотели, чтобы наши новые инструменты управления уязвимостями позволяли командам сканировать хосты в рамках тех же рабочих процессов, которые они уже использовали для подготовки, наблюдения и замены этих хостов. Консолидируя эти рабочие процессы, мы могли бы проще выяснить, указывают ли повторяющиеся результаты на общий источник, например на общий образ, содержащий уязвимый пакет. Затем наши команды могли бы обновить образ и заменить затронутые хосты в ходе обычного процесса выпуска релизов.
Но управление уязвимостями вместе с инфраструктурой таким образом требовало от нас последовательного сканирования каждого входящего в область видимости хоста, что становилось все сложнее делать при удаленном сканировании по мере роста нашего парка. Оценка каждого хоста занимала более 18 часов, в то время как SSH-учетные данные сканера истекали через 12 часов. После истечения срока действия этих учетных данных сканер не мог пройти аутентификацию на оставшихся хостах. А без аутентификации он не мог проверить локальное программное обеспечение и версии пакетов, необходимые для обнаружения уязвимостей.
Мы могли бы продлить срок службы учетных данных или продолжить расширение парка сканеров. Однако любой из этих вариантов все равно потребовал бы от нашей команды безопасности поддерживать выделенные сканеры и управлять учетными данными и сетевым доступом, необходимым этим сканерам для доступа к хостам. Поскольку Datadog Agent уже был развернут на всем парке для обеспечения наблюдаемости, он предоставил нам другой способ сбора данных о хостах, необходимых для обнаружения уязвимостей. При настройке Agent мог собирать инвентарный список установленных пакетов и их версий и отправлять его в Datadog по существующему каналу передачи данных. Затем Cloud Security могла бы использовать эту инвентаризацию для выявления известных уязвимостей.
Существующее развертывание Agent предоставило нам практическую альтернативу расширению предыдущей архитектуры, поэтому мы сравнили два подхода по стоимости и покрытию.
Как мы оценивали сканирование уязвимостей хостов на базе Agent
В качестве Customer Zero наша команда безопасности работала напрямую с продуктовой командой Cloud Security, чтобы оценить сканирование уязвимостей хостов в Datadog Cloud Security на соответствие нашим операционным требованиям и требованиям аудита. Мы сосредоточились на том, может ли замена поддерживать актуальность покрытия хостов, поддерживать отчетность и предоставлять доказательства для аудитов соответствия. Мы также оценили, могут ли команды использовать производственный контекст для приоритизации результатов и устранения уязвимостей с помощью существующих инфраструктурных рабочих процессов.
В течение шести месяцев мы запускали наш предыдущий сканер и Cloud Security параллельно, чтобы определить, когда мы сможем переключиться на Cloud Security без потери покрытия хостов или обнаружения уязвимостей. Мы сравнили, какие хосты охватывала каждая система, как она определяла пакеты, сколько результатов уязвимостей она выдавала и как она сообщала о результатах. Затем мы оценили замену на базе Agent по четырем требованиям.
Поддерживать актуальность покрытия аутентифицированных хостов
Наша замена должна была поддерживать актуальность покрытия по мере появления и ухода хостов из парка. Сканер может точно оценить каждый хост, до которого он дотягивается, и все же оставить значительный пробел, если новые или недолговечные хосты никогда не попадают в его график сканирования.
Конструкция на базе Agent соответствовала этому требованию, потому что инфраструктурные команды уже управляли конфигурацией Datadog Agent через свои рабочие процессы для подготовки и поддержки хостов. Включение сканирования уязвимостей хостов с помощью этих существующих процессов означало, что покрытие может следовать за жизненным циклом хоста без необходимости отдельного сканера для аутентификации на каждом хосте по SSH.
Приоритизация результатов с учетом производственного контекста
В рамках наших критериев перехода мы оценили, можем ли мы объединить результаты Cloud Security с производственным контекстом, уже доступным в Datadog. Этот контекст включал в себя то, был ли затронутый хост общедоступным или поддерживал критически важную службу.
Мы по-прежнему сохраняли полный набор результатов доступным для отчетности о соответствии и последующего анализа.
Интеграция данных об уязвимостях в выпуски инфраструктуры
В нашем масштабе команды обычно устраняют общие уязвимости хостов через существующий процесс выпуска инфраструктуры. Например, предположим, что одна и та же уязвимая версия OpenSSL появилась на сотнях хостов API, созданных из одного образа Amazon Machine Image (AMI). Ответственная команда может обновить OpenSSL в образе, опубликовать новый AMI и заменить затронутые хосты в ходе типичного процесса развертывания. Новый рабочий процесс сканирования должен был поддерживать этот процесс, не требуя от наших команд исправления каждого хоста или открытия отдельного тикета для каждого CVE.
Сохранение отчетности и доказательств аудита
Замена также должна была поддерживать внутренние проверки рисков и предоставлять доказательства для аудитов соответствия, включая SOC 2 Type II, ISO 27001, PCI DSS и FedRAMP® High.
В новом рабочем процессе мы использовали одни и те же результаты уязвимостей для обоих вариантов, фильтруя их по ответственной команде и по любым применимым требованиям соответствия. Использование актуальных результатов для проверок и аудитов позволяло привязать отчетность к данным, которые команды использовали для исправления. Мы также избежали ведения отдельных статических отчетов аудита, которые устаревали по мере изменения результатов.
Почему сканеры давали разные результаты
Во время миграции мы не могли рассматривать различия между существующим сканером и рабочим процессом на базе Agent как доказательство того, что один из них пропустил уязвимость. Сначала мы должны были определить, связано ли каждое различие с тем, как инструменты определяли установленные пакеты, группировали уязвимости в результаты или вычисляли покрытие. Перед переходом среды мы исследовали эти различия, чтобы определить, представляют ли они реальный пробел в обнаружении или разницу в том, как две системы сообщали об одном и том же базовом состоянии.
Когда наше исследование выявило пробел в продукте, наша команда безопасности напрямую поработала с продуктовой командой Cloud Security, чтобы устранить его до перехода. Это сотрудничество является частью того, как наша команда безопасности работает в роли Клиента Нуль (Customer Zero), используя Datadog в рабочей среде и возвращая болевые точки командам, создающим продукт.
Сканеры по-разному идентифицировали установленное ПО
Идентификация пакетов иногда приводила к тому, что сканеры сообщали о разных уязвимостях для одного и того же установленного программного обеспечения. Например, во время параллельного запуска мы обнаружили, что наш существующий сканер и его предполагаемая замена, Cloud Security, по-разному идентифицируют ответвление (форк) containerd. Поскольку сканеры классифицировали это ПО по-разному, сравнение их необработанных количеств обнаружений не позволило бы нам понять, пропустил ли какой-либо из них уязвимость. Поэтому мы сравнили уникальные CVE, о которых сообщил каждый сканер для одного и того же ресурса.
Хосты с несколькими установленными ядрами выявили еще одно различие. Cloud Security изначально сообщала об уязвимостях для каждой установленной версии, включая ядра, которые были установлены, но не загружены, в то время как предыдущий сканер исключал эти версии. Параллельный запуск выявил такое поведение как пробел в продукте, и до перехода продуктовая команда Cloud Security обновила то, как Datadog сообщает об уязвимостях для установленных версий ядер, которые не были загружены.
Сканеры по-разному подсчитывали результаты обнаружения уязвимостей
Общее количество обнаруженных уязвимостей иногда отличалось, даже когда оба сканера выявляли одни и те же уязвимости на одних и тех же ресурсах. Например, наш предыдущий сканер группировал несколько CVE под одним плагином, в то время как Cloud Security сообщала о каждой CVE отдельно. Мы решили сопоставлять уникальные CVE по ресурсам и исследовали значимые различия, включая возможные ложноположительные срабатывания. Сравнение на уровне ресурсов предоставило нашей команде безопасности и продуктовой команде Cloud Security повторяемый способ сравнения результатов обнаружения без опоры исключительно на общее количество найденных уязвимостей.
Методы сканирования различались по скорости оценки хостов
Предыдущий сканер сообщал, какие хосты он оценивал, но нам также нужно было убедиться, что охват остается актуальным. Для хостов, зарегистрированных в рабочем процессе на базе агента, мы измеряли свежесть сканирования как процент хостов из целевой группы, последнее сканирование уязвимостей которых было завершено в течение предыдущих 24 часов. Этот процент оставался выше 99%, что дало нам надежный способ определять, когда хосты начинают отставать, вместо того чтобы полагаться на разовый подсчет охвата на определенный момент времени.
Мы отдельно использовали API анализа покрытия Cloud Security, чтобы выявить хосты, которые не попали в рабочий процесс из-за отсутствия агента или неправильной настройки сканирования уязвимостей.
Что мы узнали из миграции
После перехода наша команда безопасности вывела из эксплуатации учетные данные для удаленного доступа и выделенную инфраструктуру сканирования, которые требовались при предыдущем подходе. Благодаря интеграции управления уязвимостями хостов в рабочие процессы Datadog, которые мы уже использовали для работы нашей инфраструктуры, команды смогли легко использовать результаты сканирования уязвимостей для выявления и устранения общих проблем инфраструктуры.
Если вы планируете аналогичную миграцию, вы можете использовать те же шаги для определения и тестирования требований к заменяемому решению:
- Задокументируйте, что обеспечивает ваш текущий инструмент сканирования в отношении охвата, обнаружения, отчетности и свидетельств для аудита.
Задокументируйте, что обеспечивает ваш текущий инструмент сканирования в отношении охвата, обнаружения, отчетности и свидетельств для аудита.
- Определите, какие возможности заменяемое решение должно сохранить или улучшить, а также любые новые функции, которые оно должно предоставлять.
Определите, какие возможности заменяемое решение должно сохранить или улучшить, а также любые новые функции, которые оно должно предоставлять.
- Запустите оба подхода параллельно, пока не поймете каждое значимое различие и не убедитесь, что заменяемое решение соответствует этим требованиям.
Запустите оба подхода параллельно, пока не поймете каждое значимое различие и не убедитесь, что заменяемое решение соответствует этим требованиям.
Прочтите нашу документацию, чтобы узнать больше о Datadog Cloud Security и о том, как включить ее на хостах, или вы можете
