SOC Tier 1 Analyst ทำงานตลอดทั้งวันหรือแบบไหน

การประกาศรับสมัครตำแหน่ง SOC Tier 1 analyst มักจะคลุมเครือโดยเจตนา เพราะหน้าที่นั้นส่วนใหญ่เป็นการ triage ซ้ำ ๆ และบริษัทรู้ว่า "monitor alerts and investigate incidents" ฟังดูดีกว่าความเป็นจริง นี่คือสิ่งที่หน้าที่นั้นมีลักษณะจากข้างใน ticket ต่อ ticket

คิวไม่เคยว่างจริง ๆ

คุณเริ่มกะและมี queue ของ ticket อยู่ โดยปกติจะสร้างมาจาก SIEM เช่น Splunk, Microsoft Sentinel หรือ QRadar แต่ละ ticket คือ alert หนึ่ง: login จากประเทศที่ผิดปกติ spike ของ outbound traffic file ที่ตรงกับ YARA rule user account ถูกล็อก 5 ครั้งในสิบนาที SOC ที่ยุ่งจะสร้างอันนี้หลายร้อยตัวต่อวัน และส่วนใหญ่คือปัญหาของ Tier 1 ก่อน

คุณเปิด ticket มันให้ timestamp, source IP, บางทีชื่อผู้ใช้ และ rule ที่ทำให้เกิด หน้าที่ของคุณคือตอบคำถามหนึ่งข้อ: สิ่งนี้สำคัญหรือไม่สำคัญ นั่นคือทั้งหมด คุณไม่ได้แก้อะไรเลย — คุณกำลังตัดสินใจว่าสิ่งนี้สมควรได้ความสนใจมากขึ้นหรือไม่

Triage คือ 90% การรวบรวมบริบท

พูดว่า alert คือ "impossible travel": ผู้ใช้ login จาก Chicago และจากนั้น 20 นาทีต่อมา จาก Frankfurt ก่อนที่คุณจะตัดสินใจอะไร คุณจะดึง context:

• ตรวจสอบรูปแบบ login ปกติของผู้ใช้ใน SIEM — พวกเขาเดินทางเพื่อท่องเที่ยวหรือไม่ใช้ VPN มี laptop ที่รายงาน geolocation ผิดหรือไม่
• ตรวจสอบว่า MFA ได้รับการตอบสนองบน login ทั้งสองหรือถ้า login ที่สองใช้ cached token
• ค้นหา source IP ในสิ่งเช่น VirusTotal หรือ AbuseIPDB — มันเป็น Tor exit node ที่รู้จัก VPN provider หรือ residential ISP หรือไม่
• ตรวจสอบกับผู้ใช้โดยตรงหากกระบวนการของ SOC ของคุณอนุญาต — ข้อความ Slack เช่น "hey, were you logging in from Germany around 2pm?" แก้ไข ticket ครึ่งหนึ่งเหล่านี้ในการตอบสนองหนึ่ง

ส่วนใหญ่ครั้ง VPN client สลับเซิร์ฟเวอร์หรือโทรศัพท์ที่ซิงค์ผ่าน LTE ในตำแหน่งแปลก ๆ คุณจดบันทึกสิ่งที่คุณพบ ทำเครื่องหมายว่า false positive และปิด ticket นั่นคือหน้าที่ ซ้ำ 30-60 ครั้งต่อกะขึ้นอยู่กับปริมาณของ SOC ของคุณและความเร็วของคุณ

รู้เมื่อไหร่ที่ต้อง escalate — และเขียนมันขึ้นเพื่อให้ Tier 2 ไม่ต้องทำซ้ำหน้าที่ของคุณ

ทักษะจริงไม่ใช่การจดจำ malware มันคือการรู้ว่าเมื่อไหร่บางอย่างไม่เพิ่มเติม escalate พอ และเขียน escalation เพื่อให้ Tier 2 สามารถรับได้โดยไม่ต้องทำ triage ของคุณใหม่อีกครั้ง escalation ที่แย่จะบอกว่า "suspicious login, please investigate" escalation ที่ดีจะบอก:

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 ยี่สิบ ticket เช่นนี้ — ที่ผู้ใช้ปฏิเสธกิจกรรมและ IP ได้รับการทำเครื่องหมาย — คือสิ่งที่สำคัญจริง ๆ และพวกเขาอาจจะ 5% ของคิวของคุณ

เครื่องมือที่คุณจะสัมผัสทุกกะเลย

นอกเหนือจาก SIEM คาดหวังที่จะใช้ชีวิตในมือมูลหลายชุดทุกวัน: EDR console (CrowdStrike Falcon, SentinelOne, Defender for Endpoint) เพื่อตรวจสอบ process tree และแยก host หากบอกให้ ticketing system (ServiceNow, Jira) เพื่อติดตามงานของคุณ threat intel lookups (VirusTotal, AbuseIPDB, urlscan.io) สำหรับการตรวจสอบ IOC อย่างรวดเร็ว และมักจะ runbook หรือ playbook document ที่บอกคุณว่าต้องทำตามขั้นตอนใดแน่นอนสำหรับแต่ละประเภท alert Tier 1 work จะ playbook-driven บนวัตถุประสงค์ — ความสอดคล้องสำคัญมากกว่า improvisation ที่ระดับนี้

ทำไมการทำซ้ำจึงเป็นการฝึกอบรมจริง ๆ

เหตุผลที่ Tier 1 มีอยู่เป็นบทบาทที่แตกต่าง แทนที่จะโยน alert ทั้งหมดไปยัง senior analyst คือการรู้จำรูปแบบผ่านปริมาณ หลังจากนี้ impossible-travel tickets หลายร้อยคุณจะเริ่มรู้จำรูปของจริงเมื่อเทียบกับ VPN switch ปกติก่อนที่คุณจะทำการดึง context เสร็จ สัญชาตญาณนั้นไม่มาจากคอร์ส — มันมาจากการทำ version ที่น่าเบื่อของหน้าที่นานพอที่ incident จริงที่เกิดขึ้นน้อยนิดจริงยิ่งขึ้น

ถ้าคุณกำลังทำแผนที่เส้นทางเข้าสู่งาน blue team Korra Studio มี segment ใน SIEM query basics phishing triage workflows และสิ่งที่แยกความแตกต่าง Tier 1 จาก Tier 2 responsibilities ในทางปฏิบัติ