Чем на самом деле занимается аналитик SOC Tier 1 весь день?

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

Очередь никогда не пустеет

Вы начинаете смену, и в очереди уже тикеты, обычно сгенерированные SIEM вроде Splunk, Microsoft Sentinel или QRadar. Каждый тикет — это один алерт: вход с необычной страны, скачок исходящего трафика, файл, совпадающий с YARA-правилом, учетная запись пользователя заблокирована пять раз за десять минут. Активный SOC генерирует сотни таких алертов в день, и большинство из них сначала — проблема Tier 1.

Вы открываете тикет. Там временная метка, исходящий IP, может быть имя пользователя и правило, которое сработало. Ваша задача — ответить на один вопрос: это что-то важное или ничего? Вот и все. Вы еще ничего не чините — вы решаете, стоит ли это внимание дальше.

Сортировка — это 90% сбора контекста

Допустим, алерт: "невозможное путешествие" — пользователь зашел из Чикаго, а через 20 минут из Франкфурта. Перед тем как принять решение, вы собираете контекст:

• Проверьте обычный паттерн входов пользователя в SIEM — ездит ли он в командировки, использует ли VPN, есть ли у него ноутбук, который неправильно определяет геолокацию?
• Проверьте, было ли MFA подтверждено на обоих входах или второй вход использовал закэшированный токен.
• Посмотрите исходящий IP в VirusTotal или AbuseIPDB — это известный Tor exit node, VPN-провайдер, жилой ISP?
• Если процесс SOC это позволяет, напрямую свяжитесь с пользователем — Slack-сообщение вроде "привет, ты заходил из Германии около 14:00?" решает половину таких тикетов одним ответом.

В большинстве случаев это VPN-клиент, переключившийся между серверами, или телефон, синхронизирующийся по LTE в странном месте. Вы записываете то, что нашли, отмечаете это как false positive и закрываете тикет. Вот работа, повторенная 30-60 раз за смену в зависимости от объема алертов в вашем SOC и вашей скорости.

Знание, когда эскалировать — и документирование так, чтобы Tier 2 не переделывал вашу работу

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

Пользователь: jsmith@company.com
Алерт: Невозможное путешествие (Чикаго -> Франкфурт, 22 минуты)
MFA: Подтверждено на обоих входах через push-уведомление
Исходящий IP (Франкфурт): 185.220.101.x — совпадает со списком известных Tor exit nodes (AbuseIPDB score 94)
Ответ пользователя: Отрицает путешествие или использование VPN; сообщает, что не получал MFA-запрос на второй вход (возможна усталость от push-уведомлений?)
Рекомендация: Эскалировать — возможна компрометация учетной записи через MFA push spam. Рекомендуется принудительный сброс пароля и отзыв сессий.

Это документирование заняло минут восемь, но сэкономило Tier 2 двадцать. Тикеты вроде этого — где пользователь отрицает активность и IP помечен как опасный — это те, что действительно важны, и их примерно 5% от всей очереди.

Инструменты, с которыми вы работаете каждую смену

Кроме SIEM, будьте готовы жить в нескольких инструментах ежедневно: консоль EDR (CrowdStrike Falcon, SentinelOne, Defender for Endpoint) для проверки дерева процессов и изоляции хостов при необходимости, система тикетов (ServiceNow, Jira) для отслеживания работы, запросы threat intel (VirusTotal, AbuseIPDB, urlscan.io) для быстрых IOC-проверок и часто документ с runbook или playbook, которые указывают точные шаги для каждого типа алерта. Работа Tier 1 намеренно построена на playbook — согласованность здесь важнее импровизации.

Почему повторение — это на самом деле обучение

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

Если вы планируете путь в blue team, Korra Studio имеет сегменты по основам SIEM-запросов, workflow по сортировке фишинга и тому, что на практике отделяет Tier 1 от Tier 2 ответственности.