От слепого мониторинга к проверке цифровой согласованности

«Всё больше российских компаний, особенно работающих с критичной информацией и под надзором ФСТЭК и 152-ФЗ, осознают, что классический подход к мониторингу уязвимостей, это лишь половина дела. Поиск известных угроз оставляет за кадром целевые атаки, которые годами живут в сетях, используя только легитимные инструменты и мимикрируя под рутинную активность. Гарантий безопасности не существует, есть только разная степень осознанности собственных слепых зон. Основной сдвиг — не в том, чтобы установить ещё одну SIEM-систему, а в изменении мышления: от слепой веры в прозрачность данных к парадигме постоянной проверки их внутренней согласованности.»

От иллюзии прозрачности к модели цифровой согласованности

Классический подход в регуляторных практиках (таких как требования ФСТЭК по ИБ) сосредоточен на обнаружении аномалий: неавторизованный доступ, всплески трафика, запуск известного вредоносного ПО. Это эффективно против массовых автоматизированных атак. Целевое же проникновение стремится к невидимости, его задача — стать частью ежедневного фонового шума инфраструктуры.

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

Согласованность журналов событий. В журнале VPN зафиксирован успешный вход пользователя в 14:00 с определённого IP-адреса. Однако в логах корпоративного прокси-сервера в последующие 15 минут нет ни одного запроса с этого IP к внутренним бизнес-системам. Либо сессия была украдена, и трафик идёт в обход прокси, либо активность маскируется под другой узел.
Согласованность метрик производительности. Мониторинг показывает резкий рост дисковых операций ввода-вывода на сервере с базой данных, но мониторинг прикладного уровня не фиксирует сопоставимого роста числа транзакций или запросов от санкционированных микросервисов. Возможный сценарий — неучтённая выгрузка информации.
Согласованность сетевых потоков. Система учёта трафика (NetFlow/IPFIX) фиксирует регулярные ночные сессии с контроллера домена на внешний ресурс по HTTPS. Никакие сигнатуры IPS не срабатывают, так как трафик легитимен. Но сам факт такого «графика работы» у критичного инфраструктурного компонента вступает в противоречие с его предназначением.

Фундаментальные ограничения любых систем мониторинга

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

Компромисс между детальностью и производительностью

Включение полного аудита всех событий (например, через подсистему Windows Audit) генерирует терабайты данных, парализует как сами контролируемые системы, так и каналы сбора. На практике всегда применяется агрегация и фильтрация. Злоумышленник, изучивший политики аудита в конкретной организации, может строить свою активность так, чтобы она попадала в эти «слепые зоны» — действия, которые по умолчанию не логируются или отбрасываются на этапе агрегации.

Ненадёжность источника данных под контролем противника

Получив привилегии администратора на хосте, злоумышленник получает контроль и над инструментами мониторинга. Он может остановить агенты EDR/XDR, удалить или модифицировать локальные журналы событий до их отправки в SIEM, внедрить руткит, перехватывающий системные вызовы, на которых построен сбор телеметрии.
. Достоверность данных обратно пропорциональна уровню привилегий, которые мог получить потенциальный нарушитель.

Запаздывание сигнатурных методов

Антивирусы, системы обнаружения вторжений (IDS), работающие по известным шаблонам, бессильны против атак, использующих только легитимные административные инструменты (Living-off-the-Land, или LOLbins), или специально разработанного, нигде ранее не встречавшегося вредоносного ПО. Период между использованием новой техники в целевой атаке и обновлением сигнатур в коммерческих продуктах может длиться месяцами.

От реактивного наблюдения к проактивному поиску

Поскольку полагаться на автоматическое оповещение нельзя, активный поиск скрытых компромиссов должен стать рутинной операционной практикой, особенно в организациях, подпадающих под требования 152-ФЗ о постоянном контроле защищённости.

Проактивный поиск угроз (Threat Hunting)

Это не расследование уже известного инцидента, а целенаправленная, основанная на гипотезах проверка данных на наличие следов скрытой активности. Гипотеза может быть такой: «Нарушитель, получивший начальный доступ, будет проводить разведку сети». Это запускает поиск в сырых данных (например, в полных журналах сетевых устройств или дампах трафика) аномальных сканирований портов или запросов SMB, исходящих с пользовательских рабочих станций. Другая гипотеза: «Для сохранения устойчивости атакующий создаст механизм автозапуска» — что ведёт к массовой проверке реестра, планировщика задач и служб Windows на всех хостах на предмет нестандартных записей.

Формализация базового состояния

Чем чётче описана «норма», тем проще обнаружить отклонение от неё. В контексте регуляторики это выходит за рамки базовых KPI производительности. Это детальное описание легитимных поведенческих моделей:

Какие конкретно серверы и с каких подсетей имеют право запрашивать тикеты Kerberos у контроллера домена?
Какие учётные записи (и только они) могут подключаться по RDP или WinRM к промышленным серверам верхнего уровня?
Какой типичный профиль исходящего трафика (объём, протоколы, целевые AS) для сегмента, где размещены рабочие места финансового департамента?

Создание и актуализация таких профилей — сложная, но необходимая работа. Без них любое мало-мальски грамотное отклонение растворится в фоновом шуме.

Имитационное тестирование обороны (Red Teaming)

Если проверка на проникновение (пентест) ищет уязвимости, то работа «красной команды», это полноценная симуляция действий целевого противника с задачами закрепиться, перемещаться по сети и эксфильтрировать данные, минимизируя обнаружимость. Успех «красных», это не провал защиты, а прямой ответ на вопрос, какие этапы реальной атаки остались незамеченными вашими системами мониторинга и «синей командой». Это практическая проверка границ слепых зон.

Организационная трансформация: от культуры «всё чисто» к культуре управляемого риска

Главным барьером для адекватной оценки ситуации часто становится организационная инерция, основанная на убеждении, что защищённость, это конечное состояние, которое можно достичь. Статус «инцидентов не зафиксировано» воспринимается как успех, а не как вероятное следствие ограниченной видимости.

Отчётность, основанная на проверке гипотез. Вместо шаблонной фразы «нарушений не выявлено» стандартным выводом может быть: «За квартал проверено 15 гипотез о скрытых компромиссах. По 12 из них получены данные, которые удалось отнести к легитимной активности. По 2 гипотезам данных для выводов недостаточно. Одна гипотеза о несанкционированном доступе к служебной учётной записи требует дополнительного расследования. Области промышленных сетей и сегмент DevOps остаются зонами пониженной телеметрии согласно актуальной карте рисков».
Управление критическими допущениями. Необходимо явно документировать допущения, на которых строится текущая уверенность: «Мы допускаем, что агенты мониторинга на всех серверах не могут быть бесшумно отключены», «Мы допускаем, что сегментация между сетями А и Б физически непреодолима». Затем регулярно, в том числе в ходе учений «красной команды», подвергать эти допущения проверке.
Принцип минимальных привилегий и реальная сегментация. Единственный способ ограничить ущерб от неизбежной компрометации — сделать перемещение атакующего максимально сложным. Учётная запись, скомпрометированная через фишинг, не должна иметь доступа к сетевым устройствам или системам управления. Взломанный внешний портал не должен иметь сетевого пути к АСУ ТП. Грамотная сегментация не предотвращает взлом, но делает скрытую горизонтальную подвижку и сбор данных настолько сложными, что они с высокой вероятностью породят те самые «несогласованности», которые можно будет обнаружить.

Практические шаги для экспресс-оценки

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

Аудит свежесозданных привилегированных объектов. Проверьте журналы безопасности домена на события создания учётных записей и, особенно, добавления в высокопривилегированные группы (Domain Admins, Enterprise Admins, Schema Admins). Сравните результат с официальным реестром.
Поиск скрытых объектов в службе каталогов. Используйте инструменты, способные читать сырые данные Active Directory (например, AD Explorer), для обнаружения объектов, у которых установлен атрибут showInAdvancedViewOnly, скрывающий их от стандартных оснасток.
Анализ установленных сетевых соединений на критичных серверах. На контроллерах домена, SQL-серверах, файловых хранилищах выполните анализ исходящих подключений. Обратите внимание на долгоживущие сессии на стандартные веб-порты (443, 80) или DNS (53) с внешними адресами, геолокация которых не связана с бизнес-активностью компании.
Проверка политик брандмауэра на наличие скрытых правил. Помимо групповых политик, проверьте локальные правила Windows Firewall, которые могли быть добавлены через netsh advfirewall в обход централизованного управления.
Корреляция событий аутентификации. Соберите с контроллеров домена события 4624 (успешный вход) и 4625 (неудачный вход). Ищите паттерны, где множественные неудачи с одного IP-адреса сменяются успехом, особенно в нерабочие часы — классический признак успешной атаки перебором.

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