Алерт указывает на подозрительное событие, но сам по себе не показывает ни масштаб инцидента, ни последующие действия атакующего. Доступ в сеть ещё не означает, что злоумышленник похитил данные или нарушил работу целевых систем. Ему могут потребоваться дополнительные права, переход на другой компьютер либо изучение инфраструктуры. Возможность увидеть и интерпретировать такую активность даёт команде шанс вмешаться до развития атаки.
Профилактика не бывает абсолютной. Это не означает, что команда или её инструменты работают плохо: для выявления уже проникшей активности и существуют средства обнаружения. Признание пределов предотвращения переводит фокус на пресечение — обнаружение и нейтрализацию того, что уже оказалось внутри сети.
Обнаружение не заменяет расследование
При оценке защитных продуктов в первую очередь обычно смотрят на детекты. Их сравнительно просто сопоставлять и измерять, а основной вопрос выглядит очевидным: сможет ли средство обнаружить атаку. Из-за этого нередко предполагается, что качественные срабатывания автоматически обеспечат и качественное расследование.
На практике возможность проследить действия атакующего, установить масштаб инцидента и вовремя отреагировать во многом зависит от данных, лежащих в основе алерта. Продукт сетевой безопасности может корректно выявить событие, но аналитик всё равно столкнётся с ограничениями при разборе.
Например, аналитик видит соединение, вызвавшее срабатывание, но не может установить, что происходило после него. Если поиск не даёт результатов, остаётся принципиальная неопределённость: подозрительная активность действительно прекратилась или система не собрала доказательства, необходимые для её выявления. Поэтому качеству исходных данных уделяют всё больше внимания, в том числе на фоне развития защитных инструментов с ИИ.
Поверхностная телеметрия и данные с контекстом
Успех расследования зависит и от знания поведения злоумышленников, и от понимания собственной среды. Аналитику недостаточно знать, что искать: необходимо понимать, на какие вопросы способны ответить доступные данные.
Различие между типами сетевой телеметрии особенно заметно при разборе алерта. И поверхностные, и подробные данные могут стать отправной точкой, однако первые нередко быстро приводят расследование в тупик.
Поверхностные данные часто ограничиваются временными метками, IP-адресами и базовыми сведениями о соединениях. Более подробная телеметрия включает сведения о транзакциях и дополнительный контекст. Она позволяет коррелировать события, рассматривать активность с разных сторон и реконструировать произошедшее. Тогда можно не только установить причину конкретного алерта, но и выяснить, что происходило до него, после него и в других частях сети.
Для SOC это означает, что оценивать нужно не только число срабатываний, но и возможность подтвердить либо опровергнуть гипотезу по исходным данным. Этот принцип перекликается с материалом TTL о том, почему структурированный ответ не заменяет расследование: формализованный порядок действий не устраняет пробелы в доказательствах.
Если команде требуется сопоставить требования к инфраструктуре, хранению и анализу событий с возможностями SIEM, для такой проверки можно использовать официальную страницу Security Capsule SIEM для оценки применимости к требованиям инфраструктуры. Важен не сам факт наличия данных в системе, а возможность быстро связать их с сетевой активностью, хостом и временным интервалом конкретного инцидента.
Новости информационной безопасности, технологий и государственного регулирования, а также анонсы новых исследований Tech Threat Lab.
При оценке качества данных в средстве сетевой безопасности стоит проверить:
- предоставляет ли оно полные сведения о транзакциях или только сводку;
- доступны ли содержимое пакетов либо извлечение файлов;
- насколько глубоко в прошлое можно выполнять поиск и как быстро он работает;
- можно ли проследить соединение между хостами и во времени.
ИИ зависит от исходных доказательств
Инструменты SOC на базе ИИ способны обрабатывать объёмы данных, недостижимые для ручной работы команд. Чем больше релевантных данных получает ИИ, тем больше у него возможностей выявлять события. Поверхностная телеметрия ограничивает корреляцию, тогда как более насыщенные данные позволяют находить малозаметные закономерности между хостами и типами поведения.
Это потенциально помогает выявлять ранее незамеченные индикаторы компрометации либо вмешиваться до того, как активность перерастёт в более серьёзную угрозу. Речь не о гарантированном результате: полезность выводов зависит от того, содержатся ли в собранной телеметрии признаки, которые можно связать между собой.
ИИ также может помочь при работе с незнакомой активностью. Невозможно заранее знать все сервисы, процессы и форматы журналов. Помощник способен объяснить наблюдаемое, предложить вопросы для дальнейшего изучения или подготовить скрипт, упрощающий анализ большого массива данных. Это может сократить время исследования и помочь аналитику выйти из тупика.
При этом утверждениям ИИ нельзя доверять без проверки. Если помощник предлагает объяснение, необходимо убедиться, что его подтверждают факты. Если он генерирует запрос или скрипт, следует проверить принцип работы. Перед запуском предложенной команды нужно оценить, на что ещё она может повлиять: модель может сосредоточиться на непосредственной задаче и упустить остальную часть системы.
По мере того как ИИ берёт на себя больше работы в расследованиях, возможность проверить исходные доказательства становится самостоятельным критерием качества данных. Ответ модели без доступной первичной телеметрии остаётся гипотезой, даже если выглядит правдоподобно.
Как проверять NDR вне демонстрационного сценария
При оценке данных из продуктов сетевой безопасности, особенно NDR, недостаточно пройти подготовленный демонстрационный маршрут. Полезнее взять показанный алерт и изучить его детально, намеренно выйдя за рамки сценария. Такой подход лучше показывает, насколько средство помогает аналитикам при работе с событием, которого они раньше не встречали.
Для этого стоит:
- изучить транзакции, лежащие в основе алерта;
- выяснить, доступны ли содержимое пакетов или извлечённые файлы;
- проследить активность ретроспективно и после срабатывания;
- задать вопрос, который не предусмотрен демонстрационным сценарием.
Такие задачи, вероятно, не входят в типовую демонстрацию. Но именно они позволяют понять, обеспечивают ли данные достаточные точность, охват и контекст для реального расследования либо остаются лишь отправной точкой, за которой следует тупик.
Детекты привлекают внимание, однако исход расследования определяют данные. Ключевой вопрос при оценке NDR и смежных инструментов — может ли команда с их помощью достаточно полно понять инцидент и принять решение о дальнейших действиях.