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 vulnerability scanner pointed at a medium-sized network can report thousands of findings. No team can fix them all at once, and attackers do not care which ones you meant to get to. **Vulnerability management** is the continuous process of finding weaknesses, deciding which ones matter most, fixing them and checking the fix. The hard part is prioritisation.

## The lifecycle

1. **Asset inventory**: you cannot scan what you do not know exists.
2. **Discover**: authenticated scans (with OpenVAS/Greenbone, Nessus, Qualys and similar), agent reports, cloud posture tools, software composition analysis for code dependencies.
3. **Prioritise**: rank findings by risk, not just by score.
4. **Remediate**: patch, change configuration, or apply a compensating control (for example, block the port) if a fix is not possible yet.
5. **Verify**: rescan to confirm the fix worked.
6. **Report**: track trends and deadlines (often called SLAs, such as "critical internet-facing findings fixed within 7 days").

## CVE, CWE and CVSS

- A **CVE** (Common Vulnerabilities and Exposures) ID names one specific vulnerability in one product, such as `CVE-2021-44228` (Log4Shell). Browse them at [cve.org](https://www.cve.org/).
- A **CWE** (Common Weakness Enumeration) names the type of mistake, such as CWE-79 (cross-site scripting) or CWE-89 (SQL injection).
- **CVSS** (Common Vulnerability Scoring System), maintained by FIRST, scores how severe a vulnerability is from 0.0 to 10.0. The current version is **CVSS v4.0** (released in 2023); you will still see many v3.1 scores. Official specification: [first.org/cvss](https://www.first.org/cvss/). Checked on 2026-10-23.

CVSS severity ratings:

| Score | Rating |
|---|---|
| 0.0 | None |
| 0.1 to 3.9 | Low |
| 4.0 to 6.9 | Medium |
| 7.0 to 8.9 | High |
| 9.0 to 10.0 | Critical |

The **base score** comes from a vector string describing the vulnerability itself. A v3.1 example:

```text
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H   -> 9.8 Critical
```

Read it as: Attack Vector Network, Attack Complexity Low, Privileges Required None, User Interaction None, Scope Unchanged, and High impact on Confidentiality, Integrity and Availability. In plain English: anyone on the network can fully take over the system with no login and no help from a user.

## Why the score alone is not enough

CVSS base scores describe the vulnerability in general, not **your** risk. Two more questions change the priority a lot:

1. **Is it being exploited?** The US CISA **Known Exploited Vulnerabilities (KEV)** catalogue lists vulnerabilities with evidence of real-world exploitation: [cisa.gov/known-exploited-vulnerabilities-catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). FIRST's **EPSS** estimates the probability that a vulnerability will be exploited in the next 30 days. Checked on 2026-10-23.
2. **How exposed is the asset, and how important?** An internet-facing VPN gateway is far more exposed than a printer on an isolated network. A server holding customer data matters more than a test VM.

A practical rule many teams use: **known exploited and exposed first**, then critical and high on important assets, then the rest by score and age.

## Worked example: ranking five findings

| # | Finding | CVSS | In KEV? | Asset |
|---|---|---|---|---|
| 1 | VPN appliance remote code execution | 9.8 | Yes | Internet-facing, all remote staff use it |
| 2 | Database server privilege escalation | 7.8 | No | Internal, holds customer data, needs a local login |
| 3 | Web framework remote code execution | 9.8 | No | Internal test VM, no real data, isolated |
| 4 | Outdated TLS settings on intranet site | 5.3 | No | Internal |
| 5 | Mail server authentication bypass | 8.1 | Yes | Internet-facing |

A sensible order: **1, 5, 2, 3, 4**. Findings 1 and 5 are exploited in the wild and reachable from the internet. Finding 2 is lower scored but protects sensitive data. Finding 3 has the highest score but almost no exposure, so it can follow. Sorting by CVSS alone would have put the test VM ahead of an actively exploited mail server.

If finding 1 cannot be patched today (say the vendor patch needs a maintenance window), a **compensating control** buys time: restrict the VPN management interface to the admin network, turn on the vendor's mitigation, and watch its logs closely. Record the exception with an owner and an expiry date.

## Common mistakes

- **Sorting by CVSS only.** Exposure and active exploitation matter at least as much.
- **Unauthenticated scans only.** Scans that cannot log in miss most missing patches.
- **Closing tickets without rescanning.** A patch that failed to install looks the same as one that worked until you verify.
- **Permanent exceptions.** Every accepted risk needs an owner and a review date.

## Quick recap

- Vulnerability management is a loop: inventory, discover, prioritise, remediate, verify, report.
- CVE names a vulnerability, CWE names the kind of mistake, CVSS scores severity (v4.0 current, v3.1 common).
- Prioritise with exploitation evidence (CISA KEV, EPSS), exposure and asset value, not the base score alone.
- Use compensating controls with owners and deadlines when you cannot patch yet.


Read CVE, CWE and CVSS, then prioritise findings by exploitation evidence, exposure and asset value rather than score alone.

Vulnerability management

CVE and CVSS explained | Security Detail

Analyzing Vulnerabilities - CompTIA Security+ SY0-701 - 4.3

Take a snapshot of your Ubuntu lab VM named "before-hardening".

Download the free CIS Benchmark for your Ubuntu release from cisecurity.org (free registration) and find the recommendation "Ensure sshd PermitRootLogin is disabled" (the exact title varies by version). Note its profile level, audit and remediation.

Install Lynis (`sudo apt install lynis`), run `sudo lynis audit system`, and record the hardening index and three warnings or suggestions.

Audit the current SSH setting: `sudo sshd -T | grep -i permitrootlogin`, and write down the value.

Remediate with a drop-in file: `echo "PermitRootLogin no" | sudo tee /etc/ssh/sshd_config.d/60-hardening.conf`, then test the configuration with `sudo sshd -t`.

Keeping your current session open, reload SSH (`sudo systemctl reload ssh`) and confirm you can still open a new SSH session as your normal user.

Verify the change: `sudo sshd -T | grep -i permitrootlogin` now shows `no`. If not, find which file sets it earlier.

Run Lynis again and compare the hardening index and findings.

Write a short change record: benchmark item, before value, after value, how you tested, and how to roll back.

## Why it matters

Fresh installs are built to be easy to use, not to be safe. Default settings often leave unneeded services running, allow weak authentication and keep logging minimal. **Hardening** is the work of reducing that attack surface with a repeatable, documented configuration. It prevents a huge share of real attacks, and it makes the vulnerability scans from the previous lesson much quieter.

## Benchmarks: someone has already written the checklist

You do not have to invent a hardening standard. The **Center for Internet Security (CIS)** publishes free **CIS Benchmarks**: consensus configuration guides for operating systems (Ubuntu, Red Hat, Windows, macOS), cloud platforms, databases, browsers and network devices. Download them (free registration) from [cisecurity.org/cis-benchmarks](https://www.cisecurity.org/cis-benchmarks). Checked on 2026-10-23.

Other sources: the US DoD **STIGs** (Security Technical Implementation Guides), and vendor guides such as Microsoft's security baselines.

Each benchmark item (a "recommendation") has the same structure:

- **Title**, for example "Ensure SSH root login is disabled".
- **Profile**: **Level 1** items are practical and low-impact for most systems; **Level 2** items add defence in depth for high-security environments and may break some functionality.
- **Rationale**: why it matters.
- **Audit**: the exact command to check the current state.
- **Remediation**: how to fix it.
- **Default value** and references.

## Worked example: disabling SSH root login

**Rationale.** If `root` can log in over SSH, attackers only need to guess one password for an account they know exists, and logs show "root" instead of the real person. Admins should log in as themselves and use `sudo`.

**Audit.** Ask the SSH server for its effective configuration (this includes settings from included files):

```bash
sudo sshd -T | grep -i permitrootlogin
# permitrootlogin without-password   <- default on many distributions: keys allowed, passwords not
# permitrootlogin no                 <- what the benchmark wants
```

**Remediation.** On recent Ubuntu, add a drop-in file rather than editing the main file:

```bash
echo "PermitRootLogin no" | sudo tee /etc/ssh/sshd_config.d/60-hardening.conf
sudo sshd -t            # test the configuration; no output means OK
sudo systemctl reload ssh   # the service is "sshd" on Red Hat-style systems
sudo sshd -T | grep -i permitrootlogin
```

Two safety habits matter here. First, test with `sshd -t` before reloading, because a broken configuration can lock you out. Second, keep your current session open and test a **new** login in another terminal before you disconnect. In a lab VM, take a snapshot first.

Note that OpenSSH uses the **first** value it reads for most settings, so the drop-in's file name matters: files in `sshd_config.d` are read in name order, and if another file sets the same option earlier, that one wins. That is exactly why you audit with `sshd -T` instead of trusting what you typed.

## Other common Level 1 items on Linux

| Area | Example recommendation | Quick audit |
|---|---|---|
| Updates | Ensure updates and security patches are installed | `apt list --upgradable` |
| Services | Ensure unneeded services are not running | `systemctl list-units --type=service --state=running` |
| Network | Ensure a host firewall is active with default deny inbound | `sudo ufw status verbose` |
| SSH | Ensure SSH `MaxAuthTries` is 4 or less | the `maxauthtries` line of `sudo sshd -T` |
| Accounts | Ensure no accounts have empty passwords | `sudo awk -F: '($2 == "") {print $1}' /etc/shadow` |
| Logging | Ensure auditd is installed and enabled | `systemctl is-enabled auditd` |
| Files | Ensure permissions on `/etc/shadow` are restrictive | `stat -c '%a %U %G' /etc/shadow` |

Exact wording and numbering change between benchmark versions, so always work from the version that matches your OS release.

## Tooling: measure, then enforce

- **Lynis** is a free, open-source auditing tool for Linux and macOS. `sudo lynis audit system` prints warnings, suggestions and a hardening index.
- **CIS-CAT Lite** (free) scores a system against selected CIS Benchmarks.
- **OpenSCAP** can scan and remediate against published profiles on many distributions.
- At scale, teams enforce settings with configuration management (Ansible, Puppet, Group Policy, Intune) or build hardened **golden images**, so every new server starts compliant. Manual changes on one server drift; code does not.

## Exceptions are normal

Some benchmark items will conflict with what a system must do. A file server may need a service a benchmark says to disable. That is fine if it is **documented**: the item, the reason, the compensating control and an owner who reviews it. Applying every Level 2 item blindly to production is a common way to cause outages.

## Common mistakes

- **Hardening on production first.** Test in a lab or staging system and roll out gradually.
- **Locking yourself out.** Keep a session open, test new logins, and know how to reach the console.
- **One-off manual changes.** Put settings in configuration management so they survive rebuilds.
- **Treating a score as the goal.** A higher Lynis index is nice; closing the paths attackers actually use is the point.

## Quick recap

- Hardening reduces the attack surface with a documented, repeatable configuration.
- CIS Benchmarks give per-platform recommendations with rationale, audit and remediation; Level 1 is the practical baseline.
- Audit, change, test and verify: for SSH, `sshd -T`, a drop-in file, `sshd -t`, reload, and a fresh login test.
- Measure with Lynis or CIS-CAT Lite, enforce with configuration management, and document exceptions.

## Try it

Open the **Do** tab to audit your lab VM and apply one benchmark item.


Use CIS Benchmarks to audit and apply hardening safely, starting with disabling SSH root login on a Linux VM.

System hardening

Effectively Harden Your Systems with CIS Benchmarks

10 Tips for Hardening your Linux Servers

Sign in to your own AWS account (not your root user for daily work; use an IAM user or Identity Center user with MFA) and create a budget alert of a few dollars under Billing and Cost Management.

Create an S3 bucket with a unique name and upload a text file containing only the words "test file".

On that bucket only, turn off Block Public Access and add a bucket policy allowing `s3:GetObject` to `"Principal": "*"` (as in the reading).

From your own computer, confirm the exposure with `curl -I https://<bucket>.s3.amazonaws.com/<file>` and note the HTTP status.

Fix it: delete the bucket policy and turn Block Public Access back on. Repeat the curl and confirm you now get 403.

In the EC2 console, create a security group with an inbound rule TCP 22 from `0.0.0.0/0` (do not launch an instance).

Fix it: change the source to your own public IP as a `/32`, or delete the rule and note that a session manager needs no inbound port.

Optional: run the free, open-source Prowler tool against your account (follow its official docs) or review AWS Security Hub findings, and note one more finding.

Clean up: delete the test file, the bucket and the security group, and confirm in the console that they are gone. Keep the budget alert.

## Why it matters

In the cloud, a single setting can expose a whole data set to the internet. Many of the best-known cloud breaches were not clever exploits: they were storage buckets left public, databases with no password, or management ports open to everyone. **Cloud security posture management (CSPM)** is the practice, and the tooling, of continuously checking cloud configuration for exactly these mistakes and fixing them.

## The shared responsibility model

Cloud providers secure the cloud itself: data centres, hardware, the hypervisor and their managed services. **You** secure what you put in it and how you configure it: identities and permissions, network rules, storage access, encryption settings, and your operating systems and applications. The line moves depending on the service (you manage more on a virtual machine than on a managed database), but configuration is always your job.

## The usual suspects

| Misconfiguration | Why it is dangerous | Typical fix |
|---|---|---|
| Public storage bucket | Anyone with the URL can list or download files | Block public access; share with signed URLs or specific identities |
| Security group allowing `0.0.0.0/0` on port 22 or 3389 | Every bot on the internet can try to log in | Restrict to known IPs, or use a bastion, VPN or the provider's session manager |
| Overly broad IAM permissions (`"Action": "*"`) | One leaked key can do anything | Least privilege; role-based access; short-lived credentials |
| Root or owner account without MFA | Account takeover is total | MFA on the root account, then stop using it day to day |
| Audit logging off | No record of who changed what | Turn on CloudTrail / Activity Log / Cloud Audit Logs for all regions |
| Unencrypted storage or databases | Data readable if copied | Turn on default encryption |

## Worked example: a public bucket

A storage bucket with this AWS bucket policy is readable by the whole internet:

```json
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::acme-reports-2026/*"
  }]
}
```

`"Principal": "*"` means everyone, including people who are not logged in. Anyone can fetch an object with a plain request:

```bash
curl -I https://acme-reports-2026.s3.amazonaws.com/q3-customers.csv
# HTTP/1.1 200 OK   <- exposed
```

**Fix:** remove the statement and turn on **S3 Block Public Access**, ideally at the account level so a single bucket policy cannot undo it. New buckets have it on by default, so a public bucket today usually means someone turned it off. After the fix, the same request returns `403 Forbidden`. Then answer the incident question too: was the file downloaded while it was public? Check server access logs or CloudTrail data events if they were enabled, and involve your IR process if sensitive data was exposed.

## Worked example: an open management port

A security group rule lets SSH in from anywhere:

```text
Inbound: TCP 22  source 0.0.0.0/0
```

**Fix:** change the source to the admin's public IP as a `/32` (for example `198.51.100.24/32`), or remove the rule entirely and connect through the provider's session manager, which needs no open inbound port. Azure network security groups and Google Cloud firewall rules work the same way.

## How CSPM tools work

CSPM tools read your cloud configuration through the provider's APIs and compare it with rules, often mapped to CIS Benchmarks for AWS, Azure and Google Cloud. Examples:

- Built in: **AWS Security Hub** and **AWS Config**, **Microsoft Defender for Cloud**, **Google Security Command Center**.
- Open source: **Prowler** (AWS, Azure, Google Cloud, Kubernetes) and **ScoutSuite**.
- Commercial platforms that add attack-path analysis and workload protection (often sold as CNAPP).

The output is a list of findings with severity, the affected resource and a fix. As with vulnerability management, prioritise by exposure and data sensitivity: a public bucket of website images is a different problem from a public bucket of customer records.

The best place to catch misconfiguration is **before** deployment. If infrastructure is defined as code (Terraform, CloudFormation, Bicep), scanners such as Checkov or tfsec flag a public bucket in a pull request, before it ever exists.

## Cost and safety in your own account

Practising in a real cloud account is valuable, but treat it carefully:

- Use the provider's free tier, set a **budget alert first**, and delete everything when you finish.
- Never put real or personal data in a practice resource, especially one you are about to make public.
- Only scan and change accounts you own. Probing other people's buckets or ports is unauthorised access, even if they are misconfigured.

## Common mistakes

- **Fixing the console and not the code.** If the bucket came from Terraform, the next deploy reverts your manual fix.
- **Opening a port "just for a minute".** Bots scan the whole IPv4 internet constantly; exposure is found in minutes.
- **Ignoring identities.** Broad IAM permissions and long-lived access keys cause as many incidents as network rules.

## Quick recap

- Under shared responsibility, the provider secures the cloud and you secure your configuration.
- Public buckets, open management ports, broad IAM, missing MFA and disabled audit logs are the usual problems.
- Fix a public bucket with Block Public Access and specific grants; fix an open port by restricting the source or using a session manager.
- CSPM tools (Security Hub, Defender for Cloud, Prowler) find misconfigurations continuously; IaC scanners catch them before deployment.

## Try it

Open the **Do** tab to create, find and fix both misconfigurations in your own free-tier account.


Understand shared responsibility and fix the classic cloud misconfigurations: a public storage bucket and an open management port.

Cloud security posture

What is CSPM (Cloud Security Posture Management)?

Prioritise vulnerabilities by real risk, harden systems with CIS Benchmarks, and fix common cloud misconfigurations.