SOC Tier 1 分析師實際上整天在做什麼？

SOC Tier 1 分析師的職缺貼文故意含糊其辭，因為這個角色大多是重複性的分類工作，公司知道「監控警報和調查事件」聽起來比現實好聽。以下是從內部看這份工作的樣子，逐票說明。

隊列永遠不會真正清空

你開始值班，隊列中有許多票券，通常由 SIEM（如 Splunk、Microsoft Sentinel 或 QRadar）產生。每張票券代表一個警報：來自異常國家的登入、出站流量激增、符合 YARA 規則的檔案、帳戶在十分鐘內被鎖定五次。繁忙的 SOC 每天產生數百個這樣的警報，其中大多數首先是 Tier 1 的問題。

你打開一張票券。它會給你一個時間戳記、來源 IP、可能還有使用者名稱，以及觸發的規則。你的工作是回答一個問題：這是什麼東西，還是沒什麼？就這樣。你還不是在修復任何東西——你在決定這是否值得更多關注。

分類 90% 是蒐集背景資訊

假設警報是「不可能的旅行」：一個使用者從芝加哥登入，然後在 20 分鐘後從法蘭克福登入。在你決定任何事之前，你先蒐集背景資訊：

• 在 SIEM 中檢查使用者的常規登入模式——他們是否因工作而旅行、使用 VPN、有一台誤報地理位置的筆記型電腦？
• 檢查兩次登入是否都滿足 MFA，或第二次是否使用了快取令牌。
• 在 VirusTotal 或 AbuseIPDB 等工具中查找來源 IP——它是已知的 Tor 出口節點、VPN 提供者，還是住宅 ISP？
• 如果你的 SOC 流程允許，直接與使用者聯絡——一條像「嘿，你大約下午 2 點從德國登入嗎？」的 Slack 訊息可以一次回覆解決半數票券。

大多數情況下是 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 查詢基礎、網路釣魚分類工作流，以及實踐中 Tier 1 與 Tier 2 責任差異的內容。