Secure Scroll

In Part 1, we learned the language of the SOC. Now, we must give our Watchtower the ability to see. Without data, an analyst is blind. Today, we learn the art of Visibility.

Welcome back to The Watchtower Chronicles.

In our last article(https://securescroll.wordpress.com/?p=160), we defined the vocabulary of the SOC. We talked about “Alerts,” “Incidents,” and “SIEMs.” But there is a fundamental truth in cybersecurity that overrides everything else:

“You cannot detect what you cannot see.”

If a hacker breaks into a server, but that server isn’t generating logs, the attack didn’t “happen”—at least, not to the SOC. To the Blue Team, it is invisible.

In this chapter, we are going to explore Visibility. We will look at the “Golden Sources” of data you need to collect, why “more data” isn’t always better, and how to turn on the single most important log in Windows.

The “Golden Triangle” of Data

You can’t log everything. It costs too much money and slows down the network. A smart SOC prioritizes the Golden Triangle of visibility.

1. Identity Logs (The “Who”)

Attacks almost always involve stealing credentials. If you know who is logging in, you can spot anomalies.

• What to watch: Failed logins, Logins at weird times (3 AM), or Logins from weird places (VPN from North Korea).
• Key Windows Events: 4624 (Success), 4625 (Failure).

2. Endpoint Logs (The “What”)

The endpoint (laptop/server) is the battlefield. This is where the malware runs. You need to know what programs are executing.

• What to watch: Process Creation (e.g., powershell.exe launching unknown_file.exe).
• Key Windows Event: 4688 (Process Creation).

3. Network Logs (The “Where”)

malware needs to “phone home” to the hacker to get instructions (C2 – Command and Control). Network logs show this conversation.

• What to watch: Connections to bad IP addresses, or huge data transfers (Data Exfiltration) leaving the network.
• Source: Firewalls (Palo Alto, Fortinet) or DNS Server logs

Here is the complete draft for Part 2 of your series.

This article shifts from “Definitions” to “Action.” It explains what data a SOC Analyst actually looks at and teaches the reader how to turn on the most important logging setting in Windows.

---

Quality vs. Quantity (Garbage In, Garbage Out)

A common mistake beginners make is thinking, “I’ll just log everything!”

This leads to Alert Fatigue. If you log every time a user opens a Word document, your analysts will drown in millions of useless events. The goal of a SOC Engineer is Tuning—filtering out the noise so the Analyst only sees the signal.

• Bad Log: “User Bob opened Chrome.” (Who cares?)
• Good Log: “User Bob opened Chrome and it immediately downloaded an .exe file.” (Suspicious.)

Tutorial: Turning on the Lights (Windows Command Line Logging)

Let’s make this practical. By default, Windows is actually very quiet. It will tell you “PowerShell started,” but it won’t tell you what PowerShell did.

• Default Log: PowerShell.exe started. (Useless).
• What we need: PowerShell.exe started -Command "Download-Malware.ps1"

To see the hacker’s commands, you must enable “Include Command Line in Process Creation Events.”

How to do it (On your own lab machine):

1. Open Group Policy Editor (gpedit.msc).
2. Navigate to: Computer Configuration -> Administrative Templates -> System -> Audit Process Creation.
3. Double click “Include command line in process creation events”.
4. Set it to Enabled.

Now, when you look at Event ID 4688 in your Event Viewer, you will see exactly what the hacker typed. This single setting has caught more bad guys than almost any other.

The Central Brain: The SIEM

So we have Identity logs, Endpoint logs, and Network logs. But we can’t log into 500 different servers to read them.

We need to send them all to one place. This is the SIEM (Security Information and Event Management).

• Collection: Agents (like Splunk Forwarder or Wazuh Agent) sit on the laptops and ship the logs to the SIEM.
• Correlation: The SIEM links them together.
  • Log 1 (Firewall): “Connection from Russia.”
  • Log 2 (Server): “Failed Login.”
  • SIEM Alert: “Brute Force Attack from Russia detected!”

Coming Up Next…

Now that we have the Vocabulary (Part 1) and the Data (Part 2), we are ready to teach the machine how to spot evil.

In Part 3: Signal in the Noise, we are going to write our very first Detection Rule. We will take that log we just enabled (Event 4688) and write logic to catch a real-world attack.

Get your logic gates ready

Disclaimer

This article is for educational purposes. Modifying Group Policy (GPO) and Audit settings can increase log volume significantly. Always test in a lab environment before applying changes to a production network.