Вендоры ИБ-решений любят одну и ту же картинку: нажали кнопку — и инфраструктура «под защитой». На практике всё сложнее. Лицензия куплена, агент раскатан, галочка в отчёте для регулятора стоит, а при первом реальном инциденте выясняется, что логи писались в никуда, алерты падали в общий ящик поддержки, а последний бэкап успешно восстанавливали года три назад.
Проблема не в том, что средств защиты нет. Проблема в том, что их работу никто не проверял. Рабочий тезис простой: контроль, который ни разу не проходил проверку, считается неработающим. Ниже — чек-лист аудита, который можно прогнать по своей системе за несколько дней и получить не бумажный отчёт, а список конкретных дыр.
Чем аудит отличается от проверки ради галочки
Большинство «аудитов ИБ», которые я видел, отвечают на вопрос «настроено ли?». Нам нужен другой вопрос: «сработает ли?». Разница принципиальная. Антивирус настроен — но обнаружит ли он подозрительную активность сегодня? Бэкап настроен — но сколько займёт восстановление одного сервера?
Хорошая проверка всегда даёт бинарный или измеримый ответ: работает / не работает, 4 минуты / 8 часов, 95% хостов / 60%. Всё, что нельзя так измерить, — это самоуспокоение.
Что подготовить до старта
Аудит защиты без подготовки легко превращается в инцидент, который вы же сами и устроили. Поэтому сначала — бумаги и границы:
- Письменное разрешение. Согласованные границы (какие подсети, хосты, сервисы), окно работ и ответственный, который может остановить проверку в любой момент.
- Контакты дежурных. Если проверка что-то заденет, поддержка и владельцы сервисов должны знать о ней заранее.
- План отката. Что и как вы вернёте, если тест уронит сервис или заполнит диск логами.
- Изолированный стенд. Всё, что может навредить, проверяем на копии контура, а не на продакшене.
- Фиксация baseline. Зафиксируйте состояние «до»: счётчики, метрики, логи — иначе не докажете, что что-то изменилось.
Чек-лист: десять контуров, которые нужно проверить
1. Инвентаризация и владельцы
Нельзя защитить то, о чём не знаешь. Возьмите данные сканера и сравните с трекером активов: обычно находится с десяток «забытых» серверов, тестовых баз с реальными данными и виртуалок, которые кто-то поднял и не выключил. У каждой критичной системы должен быть владелец — человек, а не отдел.
2. Доступы и привилегии
Проверьте принцип наименьших привилегий на практике: сколько учёток с правами администратора, есть ли generic-аккаунты, живы ли учётки уволенных сотрудников. Отдельно поищите доступы, которые «временно» выдали год назад и забыли закрыть.
3. Аутентификация и MFA
MFA, включённая «в целом», и MFA, которая реально защищает, — разные вещи. Проверьте, что второй фактор обязателен для всех внешних точек входа: VPN, почта, админ-панели, удалённый доступ к серверам. Классическая дыра — старые протоколы аутентификации, которые остались включены на одном сервере и тихо обходят второй фактор.
4. Патчи и управление уязвимостями
Свежесть патчей — это метрика, а не состояние. Считайте долю устранённых критичных уязвимостей и медианное время до закрытия. Отдельно проверьте, доезжают ли обновления до сегментов без интернета: изолированные сети часто остаются с дырами многолетней давности.
5. Защита конечных точек
Здесь проверка простая и честная: агент живой, обновляется, не отключён локальным админом. Проверьте охват — сколько хостов в отчёте и сколько всего в инвентаре. Сходите на пару машин и убедитесь, что модуль действительно запущен, а не просто «висит» иконкой в трее.
6. Резервное копирование и восстановление
Самый недооценённый пункт. Бэкап считается существующим только после успешного восстановления. Поднимите копию на изолированном хосте, замерьте время и запишите его. Отдельно спросите: есть ли неизменяемая (immutable) или офлайн-копия — иначе шифровальщик доберётся и до бэкапов.
7. Логирование, мониторинг, алертинг
Логи должны не просто собираться — кто-то должен их смотреть и реагировать. Проверьте цепочку целиком: событие → нормализация → правило → алерт → дежурный. Самая частая поломка происходит на последнем шаге: алерт падает в канал, за которым никто не следит.
8. Сетевая сегментация
Нарисуйте схему, как она есть, а не как задумана. Проверьте, реально ли рабочая станция из офисного сегмента достаёт до админ-интерфейса базы данных. Сегментация, которую не проверяли, обычно держится только на честном слове одного маршрутизатора.
9. Секреты и цепочка поставок
Поищите пароли и токены там, где им быть не положено: в git-репозиториях, конфигах, переменных CI в открытом виде. Проверьте, сканируются ли зависимости на известные уязвимости и обновляются ли они. Supply chain сегодня — один из самых практичных векторов, и он про ваш код, а не про абстрактного противника.
10. Люди и процессы
Технические контроли без процессов не живут. Проведите легальную фишинг-симуляцию, заранее согласованную с руководством, прогоните учения по сценарию «утечка данных» и посмотрите, кто что делает в первые 30 минут. Обычно выясняется, что у людей нет понятного порядка действий — только общая идея «звонить в ИБ».
Как тестировать, не устраивая катастрофу
Все проверки делятся на безопасные и требующие осторожности. Безопасные можно делать хоть каждый месяц:
- Проверка антивируса и EDR штатным тестовым файлом EICAR — он не является вредоносным и существует ровно для этой задачи.
- Контрольные сценарии по MITRE ATT&CK. Фреймворк ATT&CK описывает техники, а легитимные наборы проверок позволяют понять, видит ли ваш SIEM конкретное событие. Это проверка детекта, а не атака.
- Восстановление из бэкапа на отдельный хост с замером времени.
- Ревью правил доступа и выгрузка отчётов из сканера уязвимостей.
Всё, что может повлиять на прод, — только на копии контура и в согласованное окно. И да: не храните результаты проверок с реальными данными вне защищённого контура, это тоже часть гигиены.
Метрики: по ним видно, что защита живая
- MTTD — сколько времени проходит от события до обнаружения.
- MTTR — сколько времени уходит на реакцию и локализацию.
- Охват агентов — процент хостов с работающим средством защиты от общего числа в инвентаре.
- Доля закрытых критичных уязвимостей и медианное время до патча.
- RTO восстановления — проверенный на практике, а не взятый из документа.
- Доля ложных срабатываний — если алертов 3000 в день, их перестают читать, и это тоже уязвимость.
Типичные грабли
- Проверка без письменного разрешения — потом сложно объяснять дежурному, почему его подняли среди ночи.
- Тесты на продакшене «быстренько». Быстренько не бывает.
- Формальная проверка: посмотрели, что консоль открывается, и поставили галочку.
- Бэкапы, которые ни разу не восстанавливали.
- Отчёты, которые легли в стол: без плана устранения аудит бесполезен.
Итоговый чек-лист
- Есть письменный scope, окно работ и ответственный.
- Инвентарь сверен со сканером, у критичных активов есть владельцы.
- Лишних админских и «спящих» учёток нет, least privilege проверен.
- MFA обязательна на всех внешних точках входа.
- Критичные патчи закрываются в срок, включая изолированные сегменты.
- Агенты защиты живут на всех хостах и обновляются.
- Бэкап восстановлен, время замерено, immutable-копия есть.
- Логи доходят до дежурного, и по ним есть реакция.
- Сегментация проверена с рабочей станции, а не на бумаге.
- Секреты не лежат в репозиториях, зависимости сканируются.
- Команда знает порядок действий при инциденте.
- По результатам есть план работ с ответственными и датами.
Аудит не делает систему неуязвимой — он делает её честно измеряемой. Это скучнее, чем очередная «волшебная кнопка» от вендора, но именно из таких проверок складывается защита, которая срабатывает не в презентации, а в четыре утра, когда дежурному действительно нужно понять, что происходит.
