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

Defenders need a shared language for what attackers actually do. "We got hacked" is not useful. "Initial access by spearphishing attachment, execution through PowerShell, persistence with a scheduled task, then credential dumping" tells everyone which controls failed and which detections to build. **MITRE ATT&CK** is that language. It is used in SOC reports, threat intelligence, detection engineering, red team plans and vendor products, and you will be expected to use it.

## What ATT&CK is

ATT&CK (Adversarial Tactics, Techniques and Common Knowledge) is a free, publicly available knowledge base maintained by MITRE, a US non-profit. It is built from real, publicly reported intrusions. Browse it at [attack.mitre.org](https://attack.mitre.org/). Checked on 2026-10-23.

There are matrices for **Enterprise** (Windows, macOS, Linux, cloud, network, containers), **Mobile** and **ICS** (industrial control systems). Its building blocks:

- **Tactics**: the attacker's goal at a stage, the "why". Enterprise has 14.
- **Techniques**: how they achieve the goal, with IDs like `T1566`. Many have **sub-techniques**, such as `T1566.001` (Spearphishing Attachment).
- **Procedures**: specific ways a real group or malware used a technique.
- **Groups and software**: profiles of known threat actors and tools, with the techniques they use.
- **Mitigations** and **detection** guidance for each technique.

## The 14 Enterprise tactics

| Tactic | Attacker's goal | Example technique |
|---|---|---|
| Reconnaissance | Gather information for planning | Gather victim identity information |
| Resource Development | Set up infrastructure and tools | Acquire infrastructure (domains, servers) |
| Initial Access | Get in | T1566 Phishing; T1190 Exploit Public-Facing Application |
| Execution | Run code | T1059 Command and Scripting Interpreter |
| Persistence | Stay in across reboots and resets | T1053 Scheduled Task/Job |
| Privilege Escalation | Get higher permissions | Exploitation for privilege escalation |
| Defense Evasion | Avoid being detected | T1070 Indicator Removal (for example clearing logs) |
| Credential Access | Steal passwords and tokens | T1003 OS Credential Dumping; T1110 Brute Force |
| Discovery | Learn the environment | Account and network discovery |
| Lateral Movement | Move to other systems | T1021 Remote Services (RDP, SSH, SMB) |
| Collection | Gather the data they want | Data from local system |
| Command and Control | Communicate with compromised systems | T1071 Application Layer Protocol (for example HTTPS) |
| Exfiltration | Steal the data | T1567 Exfiltration Over Web Service |
| Impact | Disrupt or destroy | T1486 Data Encrypted for Impact (ransomware) |

Attacks do not have to use every tactic or go in this order, but the columns roughly follow an intrusion from start to finish.

**T1078 Valid Accounts** is worth remembering separately: using stolen but real credentials appears under several tactics (initial access, persistence, privilege escalation, defense evasion), and it is one of the hardest things to detect because the logins look legitimate.

## Worked example: mapping an incident

An incident report summary:

1. An accountant opened an emailed Word document and enabled macros.
2. The macro launched PowerShell, which downloaded a tool.
3. The tool created a scheduled task to run at every logon.
4. The attacker dumped credentials from memory and found a domain admin's password.
5. They used Remote Desktop to reach the file server.
6. They compressed the finance share and uploaded it to a cloud storage service.
7. They encrypted the file server and left a ransom note.

Mapped to ATT&CK:

| Step | Tactic | Technique |
|---|---|---|
| 1 | Initial Access | T1566.001 Phishing: Spearphishing Attachment |
| 1 | Execution | T1204.002 User Execution: Malicious File |
| 2 | Execution | T1059.001 Command and Scripting Interpreter: PowerShell |
| 3 | Persistence | T1053.005 Scheduled Task/Job: Scheduled Task |
| 4 | Credential Access | T1003 OS Credential Dumping |
| 5 | Lateral Movement | T1021.001 Remote Services: Remote Desktop Protocol |
| 5 | Defense Evasion / Persistence | T1078 Valid Accounts |
| 6 | Collection / Exfiltration | T1560 Archive Collected Data; T1567 Exfiltration Over Web Service |
| 7 | Impact | T1486 Data Encrypted for Impact |

Note that one step can map to more than one technique, and that is normal. Mapping with the exact sub-technique where you can makes the result more useful.

## Using the map

Once mapped, ATT&CK becomes a planning tool:

- **Detection gaps.** For each technique, ask: did we have a log source and an alert? Here, Office spawning PowerShell (step 2) and new scheduled tasks (step 3) are both detectable with Sysmon or EDR; if nothing fired, those are the first detections to build.
- **Mitigations.** Blocking macros from internet files, restricting PowerShell, protecting credential memory (for example Credential Guard on Windows) and limiting RDP would each break the chain.
- **Coverage heat maps.** The free **ATT&CK Navigator** lets you colour techniques by coverage, compare to the techniques a threat group uses, and share layers with your team.
- **Testing.** Red teams and open-source tools such as Atomic Red Team run small, safe tests per technique so you can check that detections fire (in a lab or with permission).

Related models you will see: the **Cyber Kill Chain** (Lockheed Martin, seven high-level stages) and the **Pyramid of Pain** (detecting attacker behaviour hurts them more than blocking an IP or hash). ATT&CK is the most detailed and the most used day to day.

## Common mistakes

- **Treating ATT&CK as a checklist to "complete".** Covering every technique is impossible; prioritise the ones relevant to your environment and threats.
- **Mapping guesses as facts.** Map what evidence shows; mark assumptions.
- **Stopping at the tactic.** "Persistence" is too vague to build a detection; the technique is the useful level.

## Quick recap

- MITRE ATT&CK is a free knowledge base of real attacker behaviour: tactics (why), techniques and sub-techniques (how), procedures (real examples).
- Enterprise has 14 tactics from Reconnaissance to Impact.
- Map each step of an incident to techniques, then use the map to find detection gaps, choose mitigations and plan tests.


Use MITRE ATT&CK tactics and techniques to describe an intrusion step by step and find detection gaps.

MITRE ATT&CK

MITRE ATT&CK® Framework

How to Actually Use MITRE ATT&CK as a Beginner (Not Just Memorize It)

Write a test plan like the one in the reading: authoriser (you), time window, in-scope IPs, out-of-scope items (your host, home network, internet), forbidden techniques, goals and stop conditions.

Set up the lab: a host-only network with a deliberately vulnerable VM (such as Metasploitable 2 or OWASP Juice Shop) and an attacker VM. Confirm the vulnerable VM cannot reach your home network. Snapshot every VM.

Start your defender view: run Suricata (lesson 1.3) or another log collector where it can see lab traffic, and note the start time in UTC.

Reconnaissance on in-scope IPs only: run `nmap -sV <target>` and record open ports and service versions.

Vulnerability analysis: pick one service and look up whether its version has a known vulnerability (search the CVE or a lab walkthrough for that target). Note its CVSS score.

Exploitation (in scope only): attempt that one known vulnerability, or for Juice Shop find one OWASP Top 10 issue, and capture evidence.

Check the defender side: which of your steps produced IDS alerts or log entries, and which left no trace?

Write a one-page report: summary, the finding with evidence and severity, the ATT&CK technique, a fix, and the detection gaps you found.

Clean up: restore every VM's snapshot and shut the lab down.

## Why it matters

A penetration test (pentest) is an authorised, simulated attack that shows how far a real attacker could get. Defenders who understand pentest methodology write better detections, read pentest reports critically and plan useful tests for their own organisation. And the single most important part of the methodology is not a tool: it is **authorisation and scope**.

## Legal first, always

Testing a system without the owner's explicit, written permission is illegal in most countries, under laws such as the US Computer Fraud and Abuse Act and the UK Computer Misuse Act, even if you mean well and even if you find nothing. Permission from someone who does not own the system (a friend who works there, a user of the service) does not count.

For practice, you have three safe options:

1. **Your own lab**: virtual machines you own on an isolated network (deliberately vulnerable targets such as Metasploitable, DVWA or OWASP Juice Shop).
2. **Platforms that authorise you**: TryHackMe, Hack The Box, PortSwigger Web Security Academy and similar, within their rules.
3. **Bug bounty programmes**: only the assets listed in the programme's published scope, following its rules exactly.

## The phases

Several published methodologies describe a pentest, including the Penetration Testing Execution Standard (PTES), NIST SP 800-115 and the OWASP Web Security Testing Guide. They share the same core phases:

| Phase | What happens | Output |
|---|---|---|
| **1. Pre-engagement** | Agree scope, goals, rules of engagement, timing, contacts and written authorisation | Signed authorisation and scope document |
| **2. Reconnaissance** | Gather information: public sources (passive), then scanning in scope (active) | List of hosts, services, users, technologies |
| **3. Threat modelling and vulnerability analysis** | Decide which weaknesses are realistic and valuable to test | Prioritised list of candidate vulnerabilities |
| **4. Exploitation** | Safely attempt to use the vulnerabilities to gain access | Proof of access, with evidence |
| **5. Post-exploitation** | Within scope, see what access allows: privilege escalation, lateral movement, reaching sensitive data | Impact demonstrated |
| **6. Reporting** | Explain findings, risk, evidence and fixes for both executives and engineers | Report and debrief |
| **7. Cleanup and retest** | Remove test accounts, tools and files; retest fixes later | Clean environment, verified fixes |

## Rules of engagement

The rules of engagement (RoE) turn "test our stuff" into something safe and legal. A useful RoE answers:

- **In scope:** exact IP ranges, domains, applications and accounts. Anything not listed is out of scope.
- **Out of scope:** for example production databases, third-party services you do not own (the cloud provider's own infrastructure, a payment processor), and physical or social engineering tests unless explicitly included.
- **Allowed and forbidden techniques:** no denial of service, no destructive actions, no accessing real customer data beyond proof.
- **Timing:** testing windows and blackout periods.
- **Contacts and stop conditions:** who to call if something breaks or you find evidence of a real attacker, and a phrase that stops testing immediately.
- **Data handling:** how evidence and any captured credentials are stored and destroyed.

Cloud providers publish their own pentest policies for customers; read them before testing anything you host there.

## Worked example: a scoped home-lab test plan

```text
Engagement: Home lab practice test
Owner/authoriser: Me (I own the host machine and all VMs)
Date/time window: 2026-10-24, 10:00-14:00 local

In scope:
  - 192.168.56.101 (Metasploitable 2 VM, host-only network)
  - 192.168.56.102 (Ubuntu VM running OWASP Juice Shop on port 3000)
Out of scope:
  - 192.168.56.1 (my host machine)
  - my home network, router, other devices, and the internet
Rules:
  - Host-only network; no bridged adapters during testing
  - No denial-of-service tests
  - Snapshot both VMs before starting; restore afterwards
Goals:
  1. Enumerate services on both VMs
  2. Gain a shell on .101 via one known vulnerability and document it
  3. Find one OWASP Top 10 issue in Juice Shop
Defender view: run the Suricata sensor from lesson 1.3 and note which steps alerted
Report: findings, evidence, ATT&CK technique, fix, and which steps were NOT detected
```

The last two lines are what makes this a defender's exercise. For each step you take as the attacker, check what the logs and IDS saw. Steps that left no trace are detection gaps, the same lesson as the previous ATT&CK mapping.

## Common reconnaissance tools (in scope only)

- `nmap` for host and service discovery: `nmap -sV 192.168.56.101` lists open ports and service versions.
- Web proxies such as OWASP ZAP or Burp Suite Community for web testing.
- Metasploit Framework for exploiting known vulnerabilities in lab targets.

Learning these tools on TryHackMe's free beginner rooms is a good path, because the targets are provided and authorised.

## A good report

- **Executive summary** in plain language: what was tested, what an attacker could achieve, the top risks.
- **Findings**, each with severity (often CVSS), affected asset, evidence (screenshots, requests), business impact, and a specific fix.
- **Attack narrative**: how findings chained together.
- **What went well**: controls that stopped or detected the tester.

## Common mistakes

- **Starting without written authorisation.** No document, no test.
- **Drifting out of scope.** Finding a new IP during recon does not make it in scope; ask the owner.
- **Running exploits you do not understand** against anything that matters. Some crash services or corrupt data.
- **A report full of scanner output.** Value comes from validated, prioritised findings and clear fixes.

## Quick recap

- Pentests need explicit written authorisation and a defined scope; practise only in your own lab or on platforms that authorise you.
- Phases: pre-engagement, reconnaissance, vulnerability analysis, exploitation, post-exploitation, reporting, cleanup and retest.
- Rules of engagement define scope, techniques, timing, contacts and stop conditions.
- For defenders, the key output is which attack steps were not detected.

## Try it

Open the **Do** tab to write and run a scoped test plan in your own lab.


Plan a scoped, authorised penetration test in your own lab, from rules of engagement to a defender-focused report.

Pentest methodology

Penetration Testing - CompTIA Security+ SY0-701 - 4.3

Collect 15 real job postings for SOC analyst tier 2, security engineer or incident responder roles in your area or remote market. Count which certifications, tools and experience levels they mention.

Open the official CompTIA CySA+ page, download the current exam objectives, and note the exam code and domains. If your postings favour a different certification, open its official page instead.

Read the official ISC2 CISSP experience requirement and write down how many years of qualifying experience you have today and when you could reach five.

Rate yourself 1 to 5 on each objective domain of your chosen certification, using this course's lessons as a guide.

Choose two free practice sources (for example TryHackMe free SOC rooms, Blue Team Labs Online free investigations or CyberDefenders) and one home-lab project (such as Wazuh or Security Onion collecting logs from your VMs).

Write a month-by-month plan for 6 months with weekly hours, mapping each month to weak domains and one write-up to publish.

Draft one CV bullet for a lab project you have already done in this course, written in terms of what you detected, investigated or fixed.

Put your target exam month and your first job application date in your calendar.

## Why it matters

You now have the skills of a working security operations analyst: logging and SIEM queries, network detection, incident response, triage, forensics basics, vulnerability management, hardening, cloud posture and ATT&CK. The next step toward a mid-level cybersecurity engineer role is proving those skills to employers and deepening them with real experience. This lesson helps you plan that honestly.

## What mid-level roles ask for

Job postings for SOC analyst tier 2, security engineer, incident responder or vulnerability management roles usually ask for some mix of:

- **Experience**: often 2 to 5 years in IT or security. Help desk, system administration, network administration and SOC tier 1 are common routes in.
- **A certification** at the analyst or practitioner level, on top of Security+.
- **Hands-on skills**: a SIEM, an EDR tool, scripting (Python or PowerShell), Linux, one cloud platform.
- **Sometimes a degree or a security clearance**, especially for government and defence work. A clearance cannot be obtained on your own; an employer sponsors it.

## Certification options

Details such as exam codes, objectives, prices and experience rules change. Always check the official pages.

**CompTIA CySA+ (Cybersecurity Analyst).** The natural next step after Security+ for security operations. It covers security operations, vulnerability management, incident response and reporting, which matches this course closely. CompTIA recommends prior Security+ (or equivalent knowledge) and a few years of hands-on experience, but there is no formal requirement. Official page: [comptia.org/certifications/cybersecurity-analyst](https://www.comptia.org/en-us/certifications/cybersecurity-analyst/). Checked on 2026-10-23.

**ISC2 CISSP.** A senior, management-leaning certification covering eight domains of security. To be certified you need at least **five years** of cumulative paid work experience in two or more of the domains (a relevant degree or approved credential can count for one year). If you pass the exam without the experience, you become an **Associate of ISC2** while you earn it. It is a goal for a few years from now, not the next step. Official page: [isc2.org/certifications/cissp](https://www.isc2.org/certifications/cissp). Checked on 2026-10-23.

**Other options people combine with or choose instead of CySA+:**

- **Vendor SIEM and security certifications**, such as Microsoft's Security Operations Analyst (SC-200) or Splunk's certifications, if employers near you use those tools.
- **Practical blue-team certifications** with hands-on exams (for example from Security Blue Team or TryHackMe).
- **GIAC** certifications (for example GCIH for incident handling): highly regarded, usually expensive, often employer-funded.
- **Offensive certifications** (CompTIA PenTest+, OSCP) if you want to move toward penetration testing.
- **Cloud security** certifications from AWS, Microsoft or Google if you are heading toward cloud security engineering.

Pick based on the jobs you want: read 15 to 20 real postings in your area and count which certifications and tools they mention.

## Building experience without a security job

Certifications get interviews; experience gets offers. Ways to build it legally:

- **A home SOC lab.** Wazuh or Security Onion collecting logs from two or three VMs you own; run safe attack simulations (for example Atomic Red Team tests in the lab) and write detections for what you see.
- **Free training platforms.** TryHackMe's free SOC and blue-team rooms, Blue Team Labs Online free investigations, LetsDefend and CyberDefenders challenges.
- **Write-ups.** Short, defender-focused notes in a public repository or blog: the scenario, your queries, your timeline, your detection. Follow each platform's rules on what you may publish.
- **Open source and community.** Contribute Sigma rules or detection content, join local security meetups or BSides conferences, and volunteer for non-profits that need IT help (with written scope).
- **Your current job.** If you are in IT, ask to help with patching, log reviews or incident tickets. That counts as security experience.

## A 6-month plan, as an example

| Month | Focus |
|---|---|
| 1 | Download the CySA+ objectives; rate yourself per objective; build the Wazuh or Security Onion lab |
| 2 | Logging and SIEM queries: write five detections in your lab, one write-up |
| 3 | Incident response and forensics: complete two free investigation challenges, two write-ups |
| 4 | Vulnerability management and hardening: scan your lab with OpenVAS, harden one VM against a CIS Benchmark, document before and after |
| 5 | Practice exams; review weak objectives; update your CV with lab projects |
| 6 | Take the exam; apply for SOC tier 1 or 2 and security engineer roles with your write-ups linked |

Adjust the pace to your life: 5 to 8 hours a week is realistic for most people with a job.

## Common mistakes

- **Collecting certifications instead of skills.** Interviewers will ask you to walk through an investigation; your lab work is what lets you answer.
- **Paying for expensive courses before using free ones.** Free platforms and official objectives take you a long way.
- **Brain dumps.** Using leaked exam questions violates certification agreements and can get you banned.
- **Waiting until you feel ready.** Apply while you study; many people get the job first and the certification paid for afterwards.

## Quick recap

- Mid-level security roles want experience, a practitioner certification and hands-on tool skills.
- CySA+ fits security operations well; CISSP needs five years' experience; vendor, practical, GIAC, offensive and cloud certifications are alternatives. Check official pages.
- Build experience with a home SOC lab, free platforms and defender-focused write-ups.
- Make a written plan with dates, and apply while you study.

## Try it

Open the **Do** tab to write your own certification and experience plan.


Plan your route to a mid-level security role: CySA+ or an alternative, CISSP's experience rule, and building real experience.

Mid-level certifications

Cybersecurity Certifications Roadmap

Map intrusions to MITRE ATT&CK, plan authorised tests in a legal lab, and plan your next certification.