Не покупайте инструменты комплаенса, пока не написаны политики

Знакомая последовательность: компании нужны SOC 2 или ISO 27001, кто-то изучает вопрос, и первой покупкой становится инструмент: платформа комплаенса, набор для защиты конечных точек, SIEM, генератор политик. Через несколько месяцев инструмент настроен наполовину, его оповещения игнорируются, а аудитор задаёт вопросы, на которые он не отвечает. Проблема была не в инструменте. Проблемой был порядок действий.

Инструменты реализуют решения

Каждому контролю нужно несколько решений до того, как инструмент сможет помочь: что входит в область применения, кто за него отвечает, как часто он выполняется, что считается «хорошо» и что происходит при сбое. Эти решения и есть ваши политика и процедуры. Купите сканер уязвимостей без них — и получите тысячи находок, за которые никто не отвечает; купите SIEM без них — и получите логи, которые никто не читает.

Стандарты сходятся во мнении

Ни один основной стандарт не требует конкретного продукта. ISO 27001 требует политик, обработки рисков и работающих контролей. SOC 2 проверяет, спроектированы ли контроли и эффективно ли они работают. PCI DSS начинает каждое из своих двенадцати требований с документированных политик, процедур и назначенных ролей. Все они предполагают, что сначала идёт продумывание.

Лучший порядок

1. Область применения и риски: что мы защищаем, от чего и какие стандарты применяются? Анализ разрывов показывает, что добавит следующий стандарт к уже имеющемуся.
2. Решите по каждому контролю: владелец, периодичность, стандарт и доказательства. Запишите кратко — это и есть ваш набор политик (см. один набор политик для многих стандартов).
3. Сначала выполняйте вручную, где это возможно. Квартальная проверка доступа в таблице покажет, что именно должен делать инструмент.
4. Затем покупайте инструменты, которые автоматизируют уже принятые решения, и оценивайте их по этим решениям.

Когда инструменты идут первыми — и это работает

Есть исключения. Защита конечных точек, MFA и резервное копирование стоит внедрять сразу, поскольку их ценность не зависит от тонкой настройки. А платформы комплаенса, которые помогают писать политики и отслеживать контроли, могут ускорить второй шаг — при условии, что их шаблоны и соответствия рассматриваются как черновики, а не готовые ответы (мы писали о соответствиях, которые нельзя проверить).

Как выглядит решение сначала

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

• Область: какие активы сканируются (внутренние, внешние, облачные, контейнеры) и как вы поймёте, что список активов полный.
• Периодичность: PCI DSS требует внутреннего сканирования каждые три месяца и после значимых изменений; CIS Controls требуют автоматизированного сканирования внутренних и внешних активов; ваш собственный риск может требовать большего.
• Серьёзность и сроки: как оцениваются находки и how быстро каждая категория серьёзности должна быть устранена.
• Ответственность: кто сортирует находки, кто их устраняет и кто принимает риск, если что-то невозможно исправить.
• Доказательства: какой отчёт подтверждает, что контроль работал и находки обрабатывались.

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

Ключевые выводы

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

Проверка

Прежде чем покупать, спросите: какой контроль это реализует, кто за него отвечает и какие доказательства он создаст? Если никто не может ответить, покупка преждевременна.

Вопросы

Что должно идти первым: политики или инструменты?

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

Требуют ли аудиторы конкретные инструменты?

Ни один основной стандарт не требует конкретного продукта. Аудиторы проверяют, работают ли контроли и создают ли они доказательства, независимо от того, как они реализованы.

Стоит ли платформа автоматизации комплаенса своих денег?

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