Що насправді робить аналітик 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, постачальник VPN, жилий ISP?
• За можливості, напряму звертаєтесь до користувача, якщо процес вашого SOC це дозволяє — повідомлення в Slack на кшталт «привіт, ти входив з Німеччини близько 14:00?» закриває половину цих тикетів однією відповіддю.

Зазвичай це клієнт VPN, який переключився на сервери, або телефон, який синхронізується через LTE в дивній локації. Ви записуєте те, що знайшли, позначаєте це як помилкову спрацьовку, і закриваєте тикет. От така робота, повторена 30-60 разів за зміну залежно від обсягу вашого SOC та вашої швидкості.

Знання коли ескалювати — та написання ескалації так, щоб Tier 2 не мусив переробляти вашу роботу

Настоящий навик — це не виявлення зловмисного ПО. Це знання, коли щось не сходиться достатньо, щоб ескалювати, та написання ескалації так, щоб Tier 2 міг взяти її в роботу без переробки вашого тріажу з нуля. Погана ескалація говорить «підозрілий вхід, будь ласка, розслідуй.» Гарна говорить:

User: jsmith@company.com
Alert: Impossible travel (Chicago -> Frankfurt, 22 min apart)
MFA: Satisfied on both logins via push notification
Source IP (Frankfurt): 185.220.101.x — matches known Tor exit node list (AbuseIPDB score 94)
User response: Denies traveling or using VPN; reports no MFA prompt received for second login (possible push fatigue?)
Recommendation: Escalate — possible account compromise via MFA push spam. Recommend forced password reset and session revocation.

Цей запис зайняв близько восьми хвилин, але заощадить Tier 2 двадцять. Тикети на кшталт цього — де користувач заперечує діяльність і IP позначена — це ті, які насправді мають значення, і їх приблизно 5% вашої черги.

Інструменти, яких ви торкатиметесь кожної зміни

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

Чому повторення насправді є навчанням

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

Якщо ви прокладаєте шлях у роботу синьої команди, Korra Studio має сегменти про основи SIEM запитів, workflow тріажу фішингу та те, що розділяє відповідальність Tier 1 від Tier 2 на практиці.