Статья Аналитик SOC: полный гайд для старта в профессии — от первого алерта до Tier 3

Первая ночная смена в SOC запоминается навсегда. Монитор залит дашбордами SIEM, в очереди мигают сотни алертов, а ты не понимаешь - это реальная атака или антивирус на бухгалтерском ПК поругался на макрос в Excel. Я через это прошёл сам, потом провёл через это два десятка стажёров. И каждый раз одна картина: человек пришёл с горящими глазами, но через час тонет в потоке событий. Никто не объяснил, как именно работает аналитик SOC в реальной инфраструктуре. Не в теории курсов, а на боевой смене с тикетной системой и SLA на два часа.

Статья написана от первого лица со слов моего коллеги.

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

Что на самом деле делает аналитик SOC каждый день​

Аналитик SOC - специалист Security Operations Center, который в реальном времени отслеживает события безопасности, классифицирует их и реагирует на инциденты кибербезопасности. Звучит просто. На практике - это работа детектива, который разгребает от нескольких сотен до десятков тысяч алертов за смену. По данным Dropzone AI, типичное расследование одного алерта занимает от 15 до 40 минут. Умножьте на очередь из пятидесяти срабатываний - и поймёте, почему мониторинг безопасности требует не только знаний, но и выстроенного рабочего процесса.

Рабочий день в центре мониторинга безопасности строится вокруг нескольких блоков:

• Приём смены. Читаете handover-отчёт предыдущей смены: какие инциденты открыты, что ждёт эскалации, где остались незакрытые тикеты. Это не формальность - я сам видел, как пропущенный handover привёл к тому, что критический инцидент «потерялся» между сменами на шесть часов.
• Мониторинг дашборда SIEM. Основная задача - смотреть на очередь алертов, сортировать по приоритету и начинать триаж. Триаж - первичная оценка: реальная угроза или false positive.
• Расследование. Для каждого подозрительного алерта, собираете контекст: откуда пришло событие, какой хост, какой пользователь, что происходило до и после. Корреляция данных из разных источников - ядро работы аналитика безопасности.
• Документирование и эскалация. Каждое действие фиксируется в тикете. Если инцидент выходит за рамки вашей компетенции - эскалация на следующий уровень с полным описанием того, что вы уже проверили.
• Передача смены. Подробный handover с перечнем открытых кейсов.

Обязанности аналитика безопасности не ограничиваются реагированием. Между инцидентами вы тюните правила корреляции, обновляете плейбуки, участвуете в тренингах. Но реальность такова: при высокой нагрузке SOC тратит только 20–30% времени на проактивную работу, остальное — на «разгребание» потока.

Tier 1, Tier 2, Tier 3 - структура карьеры в Security Operations Center​

Работа в SOC организована по уровням, и это не абстракция из учебника. Каждый тир имеет чёткие обязанности, инструменты и зону ответственности. Согласно исследованию Vielberth, Böhm, Fichtinger и Pernul (цитируется Palo Alto Networks), эти роли универсальны для большинства коммерческих SOC.

Tier 1 - триаж и мониторинг безопасности​

Tier 1 - входная точка. Здесь начинают около 80% всех сотрудников SOC. Задача - мониторинг потока алертов, первичная классификация и эскалация подтверждённых инцидентов.

Что делает Tier 1 конкретно:

• Просматривает очередь алертов в SIEM (Splunk, QRadar, MaxPatrol SIEM, ELK)
• Определяет - срабатывание false positive или требует расследования
• Обогащает алерт базовым контекстом: IP-адрес в VirusTotal, хеш файла, репутация домена
• Создаёт тикет в системе управления инцидентами (TheHive, ServiceNow, Jira)
• Эскалирует сложные кейсы на Tier 2 с описанием проделанной работы
• Работает строго по плейбукам - документированным сценариям реагирования

Типичный опыт для входа: 0–2 года, допускается переход из смежных IT-специальностей. Ключевое требование - не опыт, а внимательность, стрессоустойчивость и базовое понимание сетей (TCP/IP, DNS, HTTP).

Честное предупреждение: на Tier 1 высока монотонность. Вы будете обрабатывать десятки однотипных алертов за смену. Alert fatigue - профессиональная болезнь первой линии. Но именно здесь формируется то самое «чутьё» на аномалии, которое невозможно получить из книг. Как с вождением - сначала не замечаешь знаков, а через полгода считываешь дорогу на автомате.

Tier 2 - расследование инцидентов ИБ​

Tier 2 - уровень, где начинается глубокий анализ. Вы получаете эскалированные тикеты от Tier 1 и проводите полноценное расследование инцидентов ИБ: определяете масштаб компрометации, устанавливаете вектор атаки, координируете containment.

Обязанности Tier 2:

• Глубокий анализ алертов с корреляцией данных из нескольких источников (SIEM, EDR, сетевая телеметрия, логи AD)
• Определение scope инцидента - какие хосты затронуты, какие учётные записи скомпрометированы
• Анализ вредоносных файлов и индикаторов компрометации (IoC)
• Разработка и обновление плейбуков реагирования
• Наставничество Tier 1 - объяснение, почему конкретный алерт оказался реальным инцидентом

Типичный опыт: 2–5 лет в SOC. Для перехода с Tier 1 на Tier 2 обычно нужен не просто стаж, а демонстрация аналитических способностей. В моей практике на собеседовании давали реальный кейс: вот набор логов, вот алерт - покажи, как будешь расследовать. Здесь уже нужны скрипты автоматизации (Python, Bash), уверенная работа с MITRE ATT&CK и опыт с несколькими SIEM.

Tier 3 - threat hunting и инженерия детектирования​

Tier 3 - старшие аналитики и threat hunting специалисты. Обычно это 10–15% команды SOC. Эти люди не ждут алертов - они проактивно ищут угрозы, которые не поймали автоматические правила.

Ключевые задачи:

• Проактивный threat hunting на основе гипотез и свежей threat intelligence
• Разработка новых правил детектирования (Sigma-правила, корреляционные правила SIEM, YARA-сигнатуры)
• Расследование сложных APT-инцидентов с использованием цифровой форензики
• Менторство команды - построение программы обучения для L1 и L2
• Взаимодействие с Red Team и Purple Team для улучшения покрытия детектирования

Опыт: 5+ лет. На этом уровне аналитик уже специализируется - кто-то уходит в malware analysis, кто-то в DFIR (Digital Forensics and Incident Response), кто-то становится detection engineer. По данным CyberDefenders, detection engineer фокусируется на создании и тюнинге правил обнаружения, работая на стыке threat intelligence и SOC-операций.

Параметр	Tier 1	Tier 2	Tier 3
Основная задача	Триаж алертов	Глубокое расследование	Threat hunting, инженерия
Опыт	0–2 года	2–5 лет	5+ лет
Работа по плейбукам	Строго по плейбуку	Адаптирует плейбуки	Создаёт плейбуки
MITRE ATT&CK	Знает основные тактики	Маппит инциденты на техники	Разрабатывает детектирование по матрице
Типичный инструмент	SIEM дашборд, VirusTotal	SIEM + EDR + Sandbox	SIEM + EDR + Forensic toolkit + Python
Скриптинг	Не обязателен	Базовый Python/Bash	Продвинутая автоматизация

Как выглядит расследование инцидента кибербезопасности: пошаговый разбор​

Теория - штука полезная. Но вот вы сели за монитор, и в SIEM прилетел алерт: «Multiple failed RDP logon attempts followed by successful login from external IP». Разберём, как аналитик SOC расследует этот инцидент шаг за шагом.

Шаг 1 - получение алерта и первичный триаж​

Алерт сработал по корреляционному правилу: более 15 неудачных попыток входа по RDP (Event ID 4625) с одного внешнего IP за 10 минут, после чего - успешный вход (Event ID 4624, Logon Type 10). Нюанс, который часто упускают: при включённом NLA (Network Level Authentication) неудачные попытки RDP часто логируются с Logon Type 3 (Network), а не Type 10. Рекомендую также мониторить Event ID 4776 (NTLM-аутентификация) и логи Microsoft-Windows-RemoteDesktopServices-RdpCoreTS. По классификации MITRE ATT&CK это техника T1110 Brute Force (тактика: Credential Access).

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

• Целевой хост. Что за сервер? Если это контроллер домена с торчащим в интернет RDP - критичность максимальная. Если тестовая виртуалка разработчика - приоритет ниже, но расследовать всё равно надо.
• Внешний IP. Проверяем через VirusTotal, AbuseIPDB, внутренние TI-фиды. Был ли этот IP замечен в атаках ранее?
• Учётная запись. Какой аккаунт атаковали? Если сервисная учётка с именем admin - один сценарий. Если конкретный пользователь ivanov.a - другой (возможна целевая атака с утёкшими credentials).

Для быстрой проверки в Splunk запрос выглядит так:

index=wineventlog EventCode=4625 src=<suspicious_ip>
| stats count by user, src, dest
| sort -count

Этот запрос покажет, какие учётные записи перебирались и на каких хостах. Если атакующий долбил один аккаунт - вероятен credential stuffing. Если десятки аккаунтов - классический brute force.

Шаг 2 - сбор контекста и обогащение​

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

Проверяем в SIEM:

• Активность после входа. Ищем события создания процессов (Event ID 4688 или логи Sysmon Event ID 1) с того же хоста и от той же учётной записи. Запуск powershell.exe - тревожный сигнал, это техника T1059.001 PowerShell (Execution). cmd.exe - T1059.003 Windows Command Shell (Execution). mshta.exe может указывать на System Binary Proxy Execution: Mshta (T1218.005, Defense Evasion). certutil.exe - на Deobfuscate/Decode Files or Information (T1140) или Ingress Tool Transfer (T1105, Command and Control).
• Lateral movement. Были ли попытки подключения к другим хостам с этой машины? Ищем Event ID 4648 (Explicit credentials), события входа на соседних серверах.
• Persistence. Создание новых учётных записей (Event ID 4720) - техника T1136 Create Account (тактика: Persistence). Изменение scheduled tasks, модификация автозагрузки.
• Отключение защиты. Остановка антивируса, удаление логов - техника Impair Defenses (T1562, Defense Evasion) и Indicator Removal (T1070, Defense Evasion).

Проверяем EDR-агент на этом хосте: CrowdStrike, Microsoft Defender for Endpoint, Kaspersky EDR - зависит от того, что развёрнуто в организации. EDR покажет дерево процессов, сетевые соединения, модификации файловой системы.

Шаг 3 - принятие решения и эскалация​

На этом этапе у вас один из трёх сценариев:

Сценарий А - false positive. Успешный вход оказался легитимным: сотрудник подключался из дома, ошибся с паролем несколько раз, потом вспомнил. IP совпадает с домашним провайдером сотрудника. Закрываем тикет как false positive, но добавляем рекомендацию: включить MFA на RDP.

Сценарий Б - подтверждённый инцидент, Tier 1 справляется. Brute force был, но вход не произошёл (все попытки неуспешные). Блокируем IP на firewall, создаём IoC, закрываем тикет с описанием.

Сценарий В - эскалация на Tier 2. Успешный вход подтверждён, после него обнаружена подозрительная активность. Tier 1 фиксирует всё найденное в тикете и передаёт на второй уровень. Tier 2 проведёт containment: изолирует хост, заблокирует скомпрометированную учётную запись, начнёт полноценное расследование.

Этот пошаговый процесс - ваш ежедневный хлеб на позиции Tier 1. Первые разы будет медленно. Через месяц такой алерт разберёте за 15 минут.

SIEM система мониторинга: какие инструменты освоить первому​

SIEM - центральная нервная система любого SOC. Без неё мониторинг безопасности невозможен. Вот конкретика по платформам, которые встретите на рынке:

Splunk - наиболее распространённая платформа в международных SOC. Язык запросов SPL мощный, но требует привыкания. Если учите один SIEM - начинайте с него, навык переносится на другие платформы.

MaxPatrol SIEM (Positive Technologies) - де-факто стандарт в российских SOC, особенно в госсекторе и критической инфраструктуре. На российском рынке знание MaxPatrol открывает больше дверей, чем Splunk.

IBM QRadar - встречается в крупных корпоративных SOC. Сильная сторона - встроенная корреляция и интеграция с Watson.

ELK Stack (Elasticsearch + Kibana + Logstash) - open-source альтернатива, популярная в MSSP и стартапах. Язык запросов Lucene/KQL. Часто используется как дополнение к коммерческому SIEM. Для домашней лабы - идеальный вариант, потому что бесплатный и документация отличная.

Microsoft Sentinel - облачный SIEM, растёт в популярности среди компаний на Azure. Язык запросов KQL.

Помимо SIEM, понадобятся EDR-решения (CrowdStrike, Microsoft Defender for Endpoint, Kaspersky EDR), сетевые инструменты (wireshark, tcpdump для анализа PCAP-файлов), тикетные системы (TheHive, ServiceNow) и платформы threat intelligence (MISP, AlienVault OTX, VirusTotal).

Мой совет новичкам: не пытайтесь освоить всё сразу. Выберите один SIEM. Научитесь писать базовые запросы, создавать алерты, строить timeline инцидента. Остальное придёт в процессе - каждое новое расследование подскажет, чего не хватает.

MITRE ATT&CK в ежедневной работе аналитика безопасности​

MITRE ATT&CK - не красивая матрица для презентаций. Для аналитика SOC это рабочий инструмент, который используется ежедневно. Вот как конкретно.

При триаже алерта. Когда видите срабатывание, первый вопрос: «Какой технике это соответствует?». Brute force по RDP - T1110 (Brute Force). Фишинговое письмо с вложением - T1566 Phishing (тактика: Initial Access). Подозрительный PowerShell-скрипт - T1059.001 (тактика: Execution). Маппинг алерта на технику ATT&CK сразу даёт контекст: какая тактика используется, что атакующий, скорее всего, будет делать дальше.

При построении timeline инцидента. Если определили начальный вектор - например, T1190 Exploit Public-Facing Application через уязвимость в веб-приложении - вы понимаете типичную цепочку: после initial access атакующий обычно переходит к execution, persistence, credential access, lateral movement. Это подсказывает, где искать следы.

При написании отчёта. Каждый инцидент маппится на тактики и техники ATT&CK. Это стандарт индустрии, и этого ожидают от вас с первого дня. В тикете вы пишете не «пользователь запустил подозрительный скрипт», а «обнаружено применение T1059.001 (PowerShell) на хосте WS-FIN-042 в контексте инцидента INC-2025-1847». Разница - как между «что-то болит» и «острая боль в правом подреберье при пальпации». Второе можно лечить.

При оценке покрытия детектирования. Tier 3 аналитики используют MITRE Navigator, чтобы визуализировать, какие техники покрыты правилами корреляции, а какие нет. Если ваш SOC хорошо ловит T1110 (Brute Force), но не имеет правил на T1486 (Data Encrypted for Impact) - это слепая зона, которую нужно закрывать.

Как стать аналитиком SOC: дорожная карта для начинающих​

Начало карьеры в ИБ через SOC - один из самых реалистичных путей. Компании готовы нанимать людей с мотивацией и базовыми IT-знаниями, даже без профильного опыта. Но «базовые» не значит «нулевые». Вот конкретный план.

Фундамент - сети и операционные системы​

Без понимания TCP/IP, DNS, HTTP вы не отличите нормальный трафик от аномального. Это не опционально - это фундамент, без которого в SOC делать нечего.

Что нужно знать на уровне Tier 1:

• Как работает TCP-handshake и что значат RST, SYN, FIN-пакеты
• Что такое DNS-резолвинг и как атакующие используют DNS-туннелирование
• Разница между HTTP и HTTPS, что видно в логах прокси, а что нет
• Основные сетевые порты: 22 (SSH), 80 (HTTP), 443 (HTTPS), 3389 (RDP), 445 (SMB)
• Базовые команды Linux: grep, find, ps, netstat, cat, less - вы будете использовать их каждый день для просмотра логов
• Windows Event Log: где находятся логи Security, System, Application и что означают ключевые Event ID (4624, 4625, 4688, 4720, 7045)

Первые шаги - лаборатории и сертификации​

Теория без практики не работает. Поднимите домашнюю лабораторию:

Требования к окружению: хост с 16+ ГБ RAM (лучше 32), VirtualBox 7.x или VMware Workstation 17, образ Windows Server 2019/2022 (evaluation), 1-2 образа Windows 10/11, стабильный интернет для скачивания пакетов ELK. Всё крутится локально.

1. Установите VirtualBox или VMware
2. Разверните Windows Server с Active Directory и пару клиентских машин
3. Поставьте ELK Stack (бесплатный) и настройте сбор Windows Event Logs через Winlogbeat
4. Сгенерируйте «атаку» - запустите брутфорс по RDP с одной VM на другую и найдите её в Kibana

Этот опыт стоит дороже любого сертификата, потому что вы своими руками пройдёте путь от события безопасности до алерта в SIEM. Когда видишь в Kibana свой же брутфорс - всё встаёт на свои места.

По сертификациям: CompTIA Security+ - хороший старт, признаётся международно. На российском рынке ценят практический опыт с MaxPatrol SIEM и знание нормативной базы (ФЗ-187 о КИИ). Для продвижения на Tier 2 и выше - GCIH (GIAC Certified Incident Handler), SC-200 (Microsoft Security Operations Analyst).

Мягкие навыки, которые важнее технических​

Я видел технически сильных кандидатов, которые проваливались в SOC, и видел людей из техподдержки, которые становились отличными аналитиками. Разница - в soft skills.

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

Письменная коммуникация. Тикет, который вы заполнили, будут читать Tier 2, менеджер SOC, возможно - заказчик. «Что-то подозрительное на сервере» - плохо. «4625 EventCode, 47 failed logon attempts от src_ip 185.x.x.x на хост DC01, учётная запись svc_backup, за период 03:14–03:22 UTC» - хорошо. Разница между этими двумя записями - это разница между «вроде видел» и «вот доказательство».

Стрессоустойчивость. Ночная смена, три инцидента одновременно, SLA горит. Это реальность, а не исключение. SOC работает 24/7, и сменный график - часть профессии.

Любопытство. Лучшие аналитики, которых я встречал, не закрывают тикет при первом объяснении. Они копают глубже: «Окей, это false positive. Но почему правило сработало? Можно ли его затюнить, чтобы таких FP стало меньше?». Именно такие люди вырастают в Tier 2 за год, а не за три.

Типичные ошибки начинающих и как их избежать​

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

Ошибка 1: закрывать алерт без документирования. «Посмотрел - вроде ничего страшного, закрыл.» Через неделю открывается инцидент, оказывается - это был первый сигнал, и к нему нет записей. Правило простое: если открыли алерт, оставляете запись о том, что проверили и почему решили, что это false positive. Без исключений.

Ошибка 2: не смотреть, что было ДО и ПОСЛЕ алерта. Сработал алерт на подозрительный PowerShell. Новичок проверяет только этот процесс. Опытный аналитик смотрит: кто и как залогинился на хост за 30 минут до этого? Были ли аномалии в сетевом трафике после? Контекст - это всё. Алерт без контекста - как страница из середины детектива: слова видишь, а кто убийца - непонятно.

Ошибка 3: бояться эскалировать. Новички часто думают: «Если я эскалирую, а это окажется false positive - меня осудят». Нет. Не эскалировать реальный инцидент - в десять раз хуже, чем эскалировать ложный. В нормальном SOC за разумную эскалацию никто не ругает.

Ошибка 4: игнорировать плейбуки. Плейбук - не бюрократия. Это концентрированный опыт команды, записанный в виде пошаговой инструкции. На первой линии вы работаете строго по плейбуку. Импровизация - привилегия Tier 2 и выше.

Ошибка 5: пытаться выучить всё сразу. Splunk, QRadar, ELK, CrowdStrike, Volatility, YARA, Python, Wireshark, форензика, malware analysis... Стоп. На Tier 1 вам нужны: один SIEM, базовые сети, базовый Linux, умение читать логи. Остальное придёт с опытом и потребностями конкретных расследований. Для тех кто в танке - не надо покупать десять книг одновременно, лучше одну прочитать и руками попробовать.

Куда расти после SOC: карьерные треки​

SOC - не конечная точка, а трамплин. По данным CyberDefenders, из SOC аналитики уходят в несколько направлений:

• Вертикальный рост: Tier 1 → Tier 2 → Tier 3 → SOC Lead → SOC Manager. Менеджер SOC определяет SLA, KPI (MTTD, MTTR), управляет командой и бюджетом.
• Detection Engineer: разработка и тюнинг правил обнаружения - Sigma-правила, YARA-сигнатуры, корреляционные правила SIEM. Роль на стыке threat intelligence и SOC-операций. Мне этот трек кажется самым недооценённым - хороший detection engineer экономит сотни часов аналитикам на первой линии.
• Incident Responder / DFIR-специалист: containment, eradication, recovery при инцидентах. Форензика, анализ дампов памяти, восстановление timeline атаки.
• Threat Intelligence аналитик: стратегический анализ угроз, работа с IoC, профилирование APT-групп.
• Security Engineer: проектирование систем защиты, внедрение SOAR-платформ для автоматизации реагирования, разработка архитектуры сбора логов.

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

Вопрос к читателям​

Для домашней лаборатории SOC-аналитика один из ключевых шагов - настройка сбора Windows Security Events в ELK через Winlogbeat. По умолчанию Winlogbeat отправляет все события из канала Security, но на реальном хосте это генерирует огромный объём шума. Какой набор Event ID вы оставляете в winlogbeat.yml для секции event_logs - полный Security канал или фильтруете конкретные ID (4624, 4625, 4688, 4720, 7045)? Поделитесь вашим конфигом фильтрации - интересно сравнить подходы тех, кто уже строил лабу или продуктивный сбор.