⭐ Day 16 – SOC Ticketing, Incident Documentation & Report Writing

This day is extremely important because even if a SOC analyst detects an attack correctly, it is useless if they cannot document it clearly.

Today students learn:

• How to document alerts
• How to open & update SOC tickets
• How to write incident summaries
• How to escalate to L2/L3 properly
• How to create a clean SOC report

🧠 1. Why SOC Documentation Matters (Simple Explanation)

SOC is not only detection — it is communication.

Good documentation helps:

• Other analysts understand the incident
• Managers get clarity
• IR teams take fast action
• Auditors review events
• Avoid mistakes in escalation

Even if your analysis is perfect, poor documentation makes the incident look incomplete.

📁 2. What Is a SOC Ticket? (Very Easy Explanation)

SOC tickets are created in tools like:

• ServiceNow
• Jira
• FreshService
• RSA Archer
• Splunk Phantom
• Microsoft Sentinel IR

A SOC ticket includes:

✔ Alert details
✔ What happened
✔ Investigation steps
✔ Evidence (screenshots, logs)
✔ MITRE mapping
✔ Analyst conclusion
✔ Next actions

🧩 3. Basic SOC Ticket Structure (For Beginners)

Ticket Title

Short, clear, specific
Example:
“Multiple failed login attempts from IP 185.92.xx.xx”

Alert Summary

Short explanation:

• What happened
• When
• How many events
• Which account or system

Example:
“10 failed login attempts on host WIN-SERVER01 from external IP 185.xx.xx.xx.”

Log Evidence

Paste Splunk search query + screenshot.

Example:

index=* EventCode=4625 | stats count by IpAddress

MITRE Mapping

• T1110 Brute Force
• T1021 Lateral Movement
  (whichever applies)

Investigation Notes (Detailed)

Include:

• Timeline
• IP reputation (VirusTotal/AbuseIP)
• Username used
• Successful login or not
• What else attacker tried
• Any privilege escalation

Conclusion

Clear answer:

• “True Positive” (real attack)
• “False Positive” (normal activity)
• “Benign-Positive” (admin activity)

Containment Actions

SOC recommendation:

• Block IP
• Disable user account
• Reset password
• Terminate RDP session
• Quarantine device

Closure Notes

Short summary of what was done.

🔧 4. SOC Analyst Must Write in Simple Words

Teach students that SOC writing style = short, direct, simple.

Not like:

“This event may have potentially shown possible malicious intent.”

But like:

“10 failed logins detected. Source IP appears suspicious. Attempted access blocked. No successful login.”

🧪 5. Day 16 Hands-On Activity

Give students this alert:

“Suspicious PowerShell execution detected.”

Students must document:

1️⃣ Title
2️⃣ Summary
3️⃣ Evidence (sample query)

index=* powershell "EncodedCommand"

4️⃣ MITRE mapping (T1059 Execution)
5️⃣ Investigation steps
6️⃣ Conclusion
7️⃣ Action items

This builds real SOC writing skills.

📊 6. Mini SOC Report Template (Use in Class)

Below is a simple real SOC report template for beginners:

🔹 Incident Summary

Type: Brute Force Attack
Date:
Analyst:

🔹 What Happened

Short explanation

🔹 Evidence from Splunk

Paste SPL query
Screenshots

🔹 MITRE ATT&CK Mapping

T1110 – Brute Force

🔹 Investigation Timeline

• 9:01 – First failed login
• 9:05 – 20 failed logins
• 9:10 – Attack stopped

🔹 Analyst Conclusion

True Positive / False Positive

🔹 Recommended Actions

• Block IP
• Reset password
• Additional monitoring

🎤 Trainer Script

Say this:

“Documentation is as important as detection.
A clear SOC ticket helps the entire team understand the incident.
Today you learned how to communicate like a real SOC analyst.”

📝 Homework for Day 16

Students must write a SOC ticket for:

• A brute-force attack (4625)
  or
• A successful RDP login (Type 10)
  or
• Suspicious PowerShell