Secure Scroll

You built the Watchtower. You collected the logs. You wrote the detection rule. Now, the screen is flashing red. A suspected attack is happening right now. In this guide, we learn how to survive the adrenaline and triage the threat.

Welcome back to The Watchtower Chronicles.

If you have followed this series from the beginning, your Security Operations Center (SOC) is now fully operational. You understand the vocabulary, you have visibility into your network, and you have written logic to filter out the noise.

Suddenly, it happens. Your SIEM dashboard lights up. An alert titled “Multiple Failed Logins Followed by Success” just dropped into your queue.

In the movies, this is the moment alarms blare, metal doors slam shut, and people start typing at lightspeed. In reality, it’s just you, sitting in a quiet room with a cup of coffee, staring at a screen.

Your heart might beat a little faster, but this is exactly what you trained for. Today, we are going to learn how to Triage an alert like a professional.

The Golden Rule: Don’t Panic

When you look at your very first high-severity alert, your instinct might be to pull the physical internet cable out of the wall.

Resist that urge.

In a SOC, Triage is the medical concept of sorting patients by the urgency of their need. You aren’t doing the surgery yet; you are just figuring out if the patient has a scraped knee (False Positive) or a gunshot wound (True Incident).

To do this without panicking, cybersecurity professionals borrow a concept from fighter pilots: The OODA Loop.

The OODA Loop for SOC Analysts

Developed by U.S. Air Force Colonel John Boyd, the OODA loop is a four-step decision-making process for high-stakes, rapidly changing environments. If you can cycle through these four steps faster than the hacker, you win.

Here is how it applies to your alert queue:

1. Observe (What am I looking at?)

Stop and read the data. Don’t assume anything.

• What rule triggered? (e.g., Suspicious Powershell Download).
• What is the timestamp?
• What is the hostname and IP address involved?

2. Orient (What is the context?)

Data without context is useless. You must orient yourself to the environment.

• Who owns this computer? Is it the CEO, or a generic kiosk in the lobby?
• What is the normal baseline? Is it normal for this specific developer to run weird scripts at 2 AM?
• Have we seen this IP address before?

3. Decide (What is the verdict?)

Based on your observation and orientation, you must make a call.

• False Positive: This is normal business activity that just looked weird.
• True Positive (Malicious): This is a real attack.
• True Positive (Benign): The rule worked perfectly, but the “hacker” was just our own internal IT team running a vulnerability scan.

4. Act (What do I do about it?)

You made a decision; now execute it.

• If it’s a False Positive, close the ticket and write a note on why.
• If it’s a True Positive, escalate the ticket to Tier 2 (Incident Response) or trigger a containment protocol.

Case Study: Triaging a Phishing Alert

Let’s walk through a real-world scenario using the OODA Loop.

The Alert: Your SIEM flags that a user, “Alice,” clicked a link in an email that is categorized as malicious by your threat intelligence feed.

1. Observe: You open the alert. You see Alice’s email address, the URL she clicked (http://evil-fake-login.com), and the time it happened (10 minutes ago).

2. Orient: You dig deeper. You check Alice’s endpoint logs (from Part 2 of this series). Did her computer download an .exe file after she clicked the link? No. You check your firewall logs. Did her computer send a massive amount of data to that website? No. You check her Identity logs. Did anyone successfully log into Alice’s account from a foreign country right after she clicked the link? Yes. A login from an unknown IP address occurred 2 minutes later.

3. Decide: You piece the puzzle together. Alice clicked a fake Microsoft login page and typed in her password. The hacker immediately used that password to log into her account. Verdict: True Positive – Credential Compromise.

4. Act: You don’t need to format Alice’s computer (because no malware was downloaded). You need to kill the hacker’s access. You immediately execute the playbook for compromised accounts:

1. Revoke Alice’s active login sessions.
2. Reset her password.
3. Notify the Incident Response team to check if the hacker accessed sensitive emails during those 10 minutes.

You just stopped a data breach.

The Importance of Documentation

The final, unwritten step of the OODA loop is writing down what you did.

A SOC is a team sport running 24/7. When your shift ends, the next analyst needs to know what happened. If you close an alert as a “False Positive,” you must write a comment explaining why.

• Bad Comment: “Checked it. It’s fine.”
• Good Comment: “Observed unusual PowerShell execution. Correlated with IT change ticket #4451. Confirmed this was the sysadmin deploying a new software patch. Closing as False Positive.”

Coming Up Next…

Triaging one alert is thrilling. Triaging 500 alerts a day is exhausting.

When you stare at a screen making split-second decisions for 8 hours a day, you experience Alert Fatigue. You start making mistakes. You start ignoring the red lights.

In the final chapter of our series, Part 5: Beyond the Screen, we are going to look at how modern SOCs use Automation (SOAR) to let robots handle the boring stuff, so the humans can focus on hunting the real threats.

Stay calm, and trust your loop.

Disclaimer

This article is for educational purposes. Incident response protocols vary drastically by organization. Always follow your company’s specific runbooks and escalation procedures when handling a live security incident.