Run day-to-day defense like a SOC analyst: logging and SIEM hunting, IDS alerts, incident response, triage, forensics, vulnerability management, hardening, cloud posture and MITRE ATT&CK.

Security Operations & Defense

## Why it matters

A security operations team cannot defend what it cannot see. When something goes wrong, the first questions are always the same: who logged in, from where, what ran, and what changed? Logs are the only reliable answer. Teams that collect the wrong logs (or none) discover breaches months later, usually because someone outside tells them.

Collecting **everything** is not the answer either. Storage costs money, noisy logs bury the signal, and a SIEM licence is often priced by volume. The skill this lesson teaches is choosing the logs that matter and knowing what a few key events look like.

## The core idea: log the security story

A useful security log answers five questions about an event: **who** (user or service account), **what** (the action), **where** (host, source IP), **when** (an accurate timestamp, ideally in UTC) and **outcome** (success or failure). If a log source cannot answer most of these, it is less useful for detection.

Start with the sources that cover the most common attacks:

| Priority | Source | Why it matters |
|---|---|---|
| 1 | **Authentication** (Windows Security log, Linux `auth.log`/`secure`, identity provider sign-ins) | Stolen passwords and guessing attacks show up here first |
| 2 | **Endpoint process activity** (Windows 4688 or Sysmon, Linux auditd, EDR) | Shows what actually ran on a machine |
| 3 | **Network boundary** (firewall, VPN, DNS, proxy) | Shows who talked to whom, and callbacks to attacker servers |
| 4 | **Cloud control plane** (AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs) | Records every API call that changes your cloud |
| 5 | **Application and server logs** (web server access logs, database audit) | Shows injection attempts and data access |

## Windows event IDs worth knowing

Windows writes security events to the **Security** log, viewable in Event Viewer or with PowerShell. A small set of event IDs covers a lot of ground:

| Event ID | Meaning | What a defender looks for |
|---|---|---|
| 4624 | Successful logon | Logons at odd hours, from new hosts, logon type 10 (RDP) from the internet |
| 4625 | Failed logon | Many failures for one account (guessing) or one failure for many accounts (spraying) |
| 4672 | Special privileges assigned to a new logon | An admin-level logon you did not expect |
| 4688 | New process created | Office apps starting PowerShell, unusual command lines |
| 4720 | User account created | Accounts created outside the normal process |
| 4732 | Member added to a security-enabled local group | Someone quietly added to Administrators |
| 4740 | Account locked out | Password guessing in progress |
| 1102 | The audit log was cleared | Attackers covering tracks; this should almost never happen |

The **logon type** field in 4624 and 4625 matters: type 2 is at the keyboard, type 3 is over the network (file shares), and type 10 is Remote Desktop.

Process creation (4688) is not fully useful by default: you must turn on the audit policy and the setting that includes the command line. Many teams install Microsoft's free **Sysmon** tool, which logs process creation (Event ID 1), network connections (Event ID 3) and more, with richer detail.

```powershell
# Last 20 failed logons on this machine (run as administrator)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20 |
  Select-Object TimeCreated, Message
```

## Linux authentication logs

On Debian and Ubuntu, SSH and sudo activity goes to `/var/log/auth.log`; on Red Hat-style systems it is `/var/log/secure`. On systemd systems you can also query the journal.

```bash
# Failed SSH passwords, newest last
sudo grep "Failed password" /var/log/auth.log | tail -n 5

# The same idea through the journal (the unit is "ssh" on Ubuntu, "sshd" on RHEL)
sudo journalctl -u ssh --since "1 hour ago" | grep -i "failed"
```

A typical line looks like this:

```text
Oct 23 02:14:07 web01 sshd[2210]: Failed password for invalid user admin from 203.0.113.50 port 51122 ssh2
```

It answers who (`admin`, which does not exist: "invalid user"), where (`203.0.113.50` against `web01`), when, and the outcome (failed). Thousands of these from one IP is a bot guessing passwords.

## Worked example: picking logs for a small company

A 50-person company has Windows laptops, two Linux web servers, Microsoft 365 and one AWS account. The budget allows a free or open-source SIEM and a modest amount of storage. A sensible first set:

1. Microsoft 365 / Entra ID sign-in logs (most attacks today start with a stolen cloud password).
2. Windows Security events 4624, 4625, 4672, 4720, 4732, 4740 and 1102 from every laptop, plus Sysmon process creation.
3. `auth.log` and the web server access logs from both Linux servers.
4. AWS CloudTrail for the whole account.
5. Firewall and DNS logs.

What they leave out at first: verbose debug logs, every successful file read, and performance counters. They can add sources later when a detection needs them.

## Retention and integrity

- **Keep logs long enough.** Attackers often go unnoticed for weeks. Many teams keep 90 days searchable and a year or more in cheaper archive storage; regulations may require longer.
- **Synchronise clocks.** Use NTP everywhere and record times in UTC, or your timeline will not line up across systems.
- **Ship logs off the host.** An attacker with admin rights can delete local logs (that is what event 1102 records). Forwarding to a central collector protects the evidence.
- **Never log secrets.** Passwords, session tokens and full card numbers must not appear in logs.

## Common mistakes

- **Logging only successes or only failures.** A burst of 4625 followed by one 4624 is the story; you need both.
- **Leaving process auditing off.** Without 4688 or Sysmon, you cannot tell what ran.
- **Ignoring the cloud.** Many incidents never touch an on-premises server.
- **Collecting logs nobody reads.** A log source should support a question you actually ask or an alert you actually run.

## Quick recap

- Good security logs answer who, what, where, when and outcome.
- Prioritise authentication, endpoint process, network boundary and cloud audit logs.
- Know the key Windows IDs (4624, 4625, 4672, 4688, 4720, 4732, 4740, 1102) and where Linux keeps `auth.log`.
- Synchronise clocks, ship logs off the host, keep them long enough, and keep secrets out.


Pick the logs that matter: authentication, process, network and cloud audit events, and the Windows and Linux entries defenders read most.

Security logging

Log Data - CompTIA Security+ SY0-701 - 4.9

Where SOC Analysts Should Start With Windows Event Logs

## Why it matters

Logs scattered across hundreds of machines are almost useless during an incident. A **SIEM** (security information and event management) system collects them in one place, normalises them into common fields, and lets analysts search, correlate and alert. Writing good queries against that data is the core daily skill of a SOC analyst, whether the job uses Splunk, Microsoft Sentinel, Elastic, Wazuh or something else.

## What a SIEM does

1. **Collects** logs from agents, syslog, cloud APIs and appliances.
2. **Parses and normalises** them, so a failed login from Windows and one from Linux both end up with fields such as `user`, `src_ip`, `host` and `outcome`.
3. **Stores and indexes** them so searches over millions of events take seconds.
4. **Correlates** events with **detection rules** ("10 failed logins followed by a success from the same IP within 15 minutes") and raises **alerts**.
5. **Supports investigation** with dashboards, timelines and saved searches.

Each product has its own query language: **SPL** in Splunk, **KQL** in Microsoft Sentinel, **ES|QL** and KQL in Elastic. **Sigma** is an open, vendor-neutral format for writing detection rules once and converting them to many SIEMs. The thinking behind every query is the same, and SQL expresses it clearly, so this lesson uses SQL. Once you can write it in SQL, translating to SPL or KQL is mostly syntax.

Free options for a home lab include **Wazuh** (open source), **Security Onion** (open source, network-focused), the free tier of **Elastic**, and **Splunk's free licence** (check its current data limits on Splunk's site).

## Threat hunting vs alerting

- **Alerting** runs saved rules continuously and wakes someone up when they match.
- **Threat hunting** is proactive: an analyst starts with a hypothesis ("an attacker may be password spraying our VPN") and searches for evidence, even though no alert fired. A good hunt that finds something often becomes a new alert rule.

## The query patterns you will use most

Imagine a normalised table `auth_events` with columns `ts`, `host`, `user`, `src_ip` and `outcome` (`'success'` or `'failure'`).

**1. Filter**: narrow to what matters.

```sql
SELECT ts, host, user, src_ip
FROM auth_events
WHERE outcome = 'failure' AND ts >= '2026-10-23 00:00:00';
```

**2. Count and group**: turn thousands of rows into a short list of suspects.

```sql
SELECT src_ip, COUNT(*) AS failures
FROM auth_events
WHERE outcome = 'failure'
GROUP BY src_ip
ORDER BY failures DESC;
```

**3. Threshold with HAVING**: keep only groups above a limit.

```sql
SELECT src_ip, COUNT(*) AS failures
FROM auth_events
WHERE outcome = 'failure'
GROUP BY src_ip
HAVING COUNT(*) >= 5;
```

**4. Distinct counts**: separate attack shapes. Brute force is many attempts against **one** user; **password spraying** is a few attempts against **many** users, to stay under lockout limits.

```sql
SELECT src_ip,
       COUNT(*) AS failures,
       COUNT(DISTINCT user) AS users_tried
FROM auth_events
WHERE outcome = 'failure'
GROUP BY src_ip;
```

An IP with 40 failures and 1 user is guessing one password; an IP with 40 failures and 38 users is spraying.

**5. Correlate**: did the noisy IP ever get in? A subquery or join links failures to a later success.

```sql
SELECT DISTINCT s.src_ip, s.user, s.ts
FROM auth_events AS s
WHERE s.outcome = 'success'
  AND s.src_ip IN (
    SELECT src_ip FROM auth_events
    WHERE outcome = 'failure'
    GROUP BY src_ip HAVING COUNT(*) >= 5
  );
```

That last query is the one that turns a noisy event into an incident: a success after many failures from the same source.

## Worked example: a hypothesis-driven hunt

**Hypothesis:** someone is spraying passwords at our SSH servers.

1. Count failures by source IP for the last 24 hours. Two IPs stand out with 30+ failures each.
2. Add `COUNT(DISTINCT user)`. One IP tried 1 user (a misconfigured backup script with an old password); the other tried 26 users.
3. Check the spraying IP for any success. One success for `deploy` on `web02`.
4. Pivot: search every event for `user = 'deploy'` and `host = 'web02'` after that time to see what happened next.
5. Result: escalate as an incident, and save the query as a rule so it alerts next time.

The same hunt in Splunk SPL looks like this, to show how close the ideas are:

```text
index=auth outcome=failure
| stats count AS failures dc(user) AS users_tried BY src_ip
| where failures >= 5
```

## Common mistakes

- **Searching all time.** Always set a time window; it is faster and keeps you focused.
- **Forgetting normalisation.** `Admin`, `admin` and `CORP\admin` may be the same account. Check how your SIEM normalises fields.
- **Alerting on single events.** One failed login is normal; thresholds and correlation turn noise into signal.
- **Not writing down the hypothesis.** A hunt without a question becomes aimless scrolling.

## Quick recap

- A SIEM collects, normalises, stores, correlates and alerts on logs.
- Hunting starts with a hypothesis; alerting runs saved rules.
- Filter, group and count, threshold with HAVING, count distinct values, and correlate failures with successes.
- The logic carries over to SPL, KQL and Sigma.

## Try it

Open the **Do** tab and hunt through a small authentication log with SQL.


See what a SIEM does and hunt through authentication logs with filter, group, threshold and correlation queries.

SIEM and queries

What Is SIEM?

Security Monitoring - CompTIA Security+ SY0-701 - 4.4

Start your Ubuntu lab VM (from Linux Administration), make sure it is updated, and take a snapshot named "before-suricata".

Install Suricata from your distribution or the official Suricata PPA, following the official Suricata quickstart guide for your release.

Find your VM's network interface with `ip -br addr`, set it as the capture interface in `/etc/suricata/suricata.yaml` (the `af-packet` section), and set `HOME_NET` to your VM's subnet.

Download the free Emerging Threats Open rules with `sudo suricata-update`, then restart the service and check it is running with `sudo systemctl status suricata`.

From the VM itself, request the IDS test page: `curl http://testmynids.org/uid/index.html`. This page exists only to trigger a test signature.

Read the alert in `/var/log/suricata/fast.log`, then find the full JSON event in `/var/log/suricata/eve.json` (for example with `sudo grep '"event_type":"alert"' /var/log/suricata/eve.json | tail -n 1`).

Write down the signature name and ID, source and destination IPs, direction, action and severity. Look up the rule text with `sudo grep -r "sid:2100498" /var/lib/suricata/rules/` (use the ID you saw) and explain in one sentence what it matches.

Classify the alert (true positive, false positive or benign true positive) and write a two-line analyst note explaining why.

When you are done, stop Suricata (`sudo systemctl disable --now suricata`) or restore your snapshot.

## Why it matters

Host logs show what happened on a machine. A **network intrusion detection system (IDS)** shows what crossed the wire: scans, exploit attempts, malware calling home, data leaving. It also covers devices that cannot run agents, such as printers, cameras and network appliances. SOC analysts read IDS alerts every shift, and the skill is not memorising signatures but deciding quickly what an alert means and whether it matters.

## IDS, IPS and how they detect

- An **IDS** watches a copy of traffic (from a span port or network tap) and raises alerts. It does not block anything.
- An **IPS** (intrusion prevention system) sits inline and can drop matching traffic. That is more protective but riskier: a bad rule can block legitimate users.

Detection works in two main ways:

| Method | How it works | Strength | Weakness |
|---|---|---|---|
| **Signature-based** | Matches known patterns (bytes, URLs, protocol fields) | Precise, explainable alerts | Misses new or disguised attacks |
| **Anomaly-based** | Flags behaviour that differs from a baseline | Can catch new attacks | More false positives; needs tuning |

**Snort** and **Suricata** are the best-known open-source signature engines. **Zeek** takes a different approach: it writes detailed logs of every connection, DNS query, HTTP request and TLS handshake, which analysts use for hunting. **Security Onion** bundles Suricata, Zeek and a search interface into one free distribution for labs and real networks.

## Anatomy of a rule

Snort and Suricata share a rule format. Here is a simple local rule:

```text
alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"LOCAL SSH connection attempt from outside"; flow:to_server,established; sid:1000001; rev:1;)
```

- `alert`: the action (an IPS could use `drop`).
- `tcp $EXTERNAL_NET any -> $HOME_NET 22`: protocol, source, direction and destination. The variables are defined in the engine's configuration.
- `msg`: the text analysts see.
- `flow`: match only traffic going to the server on an established connection.
- `sid` and `rev`: the unique signature ID and its revision. Local rules use IDs of 1,000,000 and above.

Most teams do not write most rules themselves. They use curated rulesets such as the free **Emerging Threats Open** set and add a few local rules.

## Reading an alert

Suricata writes alerts in JSON to `eve.json` (and a one-line summary to `fast.log`). A trimmed alert:

```json
{
  "timestamp": "2026-10-23T09:41:12.512+0000",
  "event_type": "alert",
  "src_ip": "10.0.5.23",
  "src_port": 51544,
  "dest_ip": "198.51.100.77",
  "dest_port": 80,
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "signature_id": 2100498,
    "signature": "GPL ATTACK_RESPONSE id check returned root",
    "category": "Potentially Bad Traffic",
    "severity": 2
  },
  "http": { "hostname": "198.51.100.77", "url": "/uid/index.html" }
}
```

Read it in this order:

1. **What fired?** The signature name and ID. Look up the rule text to see exactly what it matches. This one matches the text `uid=0(root)` in a response, which is what the Linux `id` command prints for the root user.
2. **Which direction?** Internal `10.0.5.23` fetched a page from external `198.51.100.77`. The suspicious content came back in the response.
3. **Was it allowed or blocked?** `allowed`: this is an IDS, so the traffic went through.
4. **How severe?** Suricata severity 1 is the highest; 2 is medium.
5. **What is the context?** Which host is `10.0.5.23`, who uses it, and is this a known test? Pivot to Zeek, proxy or DNS logs for the same IP and time.

Here the honest answer is often "it depends". This exact signature is used by the test page `testmynids.org` to confirm an IDS works, so an alert during an admin's setup test is benign. The same alert from a production web server's **outbound** traffic would be alarming: it could mean an attacker ran `id` through a web shell.

## True and false positives

- **True positive:** the alert fired and the bad thing really happened.
- **False positive:** the alert fired but nothing bad happened (for example, a rule matching a harmless file).
- **Benign true positive:** the rule matched correctly, but the activity is authorised, such as a scheduled vulnerability scan.
- **False negative:** something bad happened and nothing fired. These are the dangerous ones, and you only find them by hunting or after an incident.

**Tuning** means reducing false positives without creating false negatives: suppressing a rule for one known scanner IP, adjusting thresholds, or disabling rules for software you do not run. Record every tuning change and why.

## Encrypted traffic

Most web traffic is TLS, so signatures cannot see inside it. Network detection still sees metadata: destination IPs and ports, DNS names, TLS server names (SNI), certificate details, connection timing and size. Beaconing (a host connecting to the same rare domain every 60 seconds) stands out even when the content is encrypted.

## Common mistakes

- **Escalating on the signature name alone.** Always check direction, context and the rule text.
- **Placing the sensor where it cannot see.** A sensor outside the firewall sees internet noise; one inside sees what actually got through and internal movement.
- **Never tuning.** Thousands of ignored alerts train analysts to miss the real one.
- **Running a sensor on networks you do not own.** Capturing other people's traffic without authorisation can be illegal.

## Quick recap

- An IDS alerts; an IPS can block. Signatures are precise; anomaly detection is broader but noisier.
- Snort and Suricata use rules with an action, header and options including `msg` and `sid`.
- Read an alert by signature, direction, action, severity and context, then pivot to other logs.
- Classify as true positive, false positive or benign true positive, and tune carefully.

## Try it

Open the **Do** tab to run Suricata on your own virtual machine and read a test alert.


Learn how Snort and Suricata detect attacks, read a rule, and work through an IDS alert step by step.

Network detection

Intrusion Prevention - CompTIA Security+ SY0-701 - 3.2

IDS vs IPS: Which to Use and When

Choose the logs that matter, hunt through them with SIEM queries, and read network IDS alerts.