Security · Topic 02 of 23 · Part I — Foundations

The security testing landscape

A single mental map into which every methodology, standard, and lab in this course slots — before we study any one of them in depth.

Syllabus: Introduction (§ Overview of the theoretical part of the course) + cross-cutting framing for the entire syllabus

Topic 02 · The map first

The map into which everything else slots

By the end of this topic you can:

Define ICT security testing and distinguish it from audit, monitoring, and incident response.
Place the major testing methodologies on a single landscape map and explain how they differ in purpose, depth, and visibility to the target.
Identify who commissions security testing and why, and translate those drivers into what kind of test is appropriate.
Name the most common misconceptions about security testing and correct them.

What "security testing" means

The systematic, authorised evaluation of a system to determine the extent to which it meets its security objectives.

Systematic — guided by a method; describable in what, why, and what order.
Authorised — explicit, documented consent of the system owner. Without it, the same activity is a crime.
Evaluation — the goal is information about security posture, not damage or intrusion for its own sake.

Useful contrast A burglar breaks in to take things. A security tester is invited in to write a report explaining how a burglar could break in, what they could take, and what should be done about it. Same skill set — different contract, different output.

What security testing is not

Neighbour activity	What it does	How it differs from testing
Auditing	Checks documents and processes against a standard ("did you change passwords every 90 days?")	Testing exercises the system itself ("can I get in without the password at all?")
Monitoring	Watches a running system for signs of attack	Testing actively interrogates the system to find where it would fail under attack
Incident response	Contains and recovers after a real attack	Testing happens proactively to prevent the next incident
"Hacking"	Popular term with no agreed meaning — covers criminal, journalistic, and curious activity	Testing lives inside a contract; the discipline we study uses the term testing

All four neighbours are valuable. They answer different questions — and all four are fields a student in this room might work in.

The methodology landscape

Seven complementary lenses — not a ranked list. A mature security programme uses several over time.

Methodology	What it answers
OSINT	What can an attacker learn about the target without touching it?
Social engineering	What can an attacker extract from the people around the target?
Vulnerability scanning	What can automated tools find at scale on the target's surface?
Manual review	What can a skilled human find in code, configurations, and documents that tools miss?
Penetration testing	What could an attacker actually do by chaining discovered weaknesses together?
Red teaming	What could a sophisticated, goal-driven adversary accomplish against the organisation as a whole?
Blue teaming	Can the organisation see, contain, and recover from those attacks?

Two axes to orient the map

Passive ↔ Active

OSINT — purely passive; never touches the target.
Vulnerability scanning — touches the target but does not exploit.
Penetration testing / red teaming — highly active; exploits confirmed weaknesses.

Narrow ↔ Holistic

Manual code review — one application, deeply.
Penetration testing — depends on scope; can be narrow or broad.
Red teaming — the entire organisation, including people and processes.

Why it matters Plotting methodologies on these axes shows why a given client chooses one over another — cost, exposure to the target, and regulatory requirement all map onto these axes.

Testing in a wider security programme

Security testing is one ingredient among several. It feeds its neighbours and is constrained by them.

Neighbours

Security architecture — designs systems to be defensible.
GRC — decides required security level; satisfies auditors and regulators.
Security operations (SOC) — runs detection and response daily.
Secure development (SDLC / DevSecOps) — builds security into software creation.

Flows

Testing → Architecture: did the design hold up?
Testing → GRC: evidence for audits and regulators.
Testing → SOC: exercises detection capability.
Testing → SDLC: concrete, actionable bug reports.

Key insight A tester is embedded in a larger system of work — not an isolated lone hacker.

The attacker–tester asymmetry

A tester is not playing attacker. The constraints are fundamental and shape what testing can honestly claim to demonstrate.

Dimension	Real attacker	Security tester
Time	Unlimited — waits for the right moment	Fixed budget — engagement ends on the agreed date
Target choice	Picks the weakest target	Defined scope — tests what the client specifies
Damage	Does not care — mayhem may be the point	Must avoid damage — the test supports the system
Documentation	None — they stay invisible	Mandatory — every result must be evidenced and reportable
Success threshold	Only needs to succeed once	Judged on the quality and usefulness of the report

Passing a test does not prove the system is invulnerable — it proves this scope, at this time, by this tester, with this depth, found what it found.

Who buys security testing — and why

Motivation shapes scope, depth, and what the client will actually do with the findings.

1Compliance — a regulation, certification, or contract requires a periodic test (PCI-DSS, ISO 27001, regulator demands). Often the floor, not the ceiling.

2Risk reduction — the organisation wants to know how exposed it is. The healthiest driver; produces the most useful tests.

3Specific trigger — new application going live, breach elsewhere in the industry, acquisition due diligence.

4Public assurance — a vendor tells customers "we are tested". Less rigorous when the report is never published.

5Internal politics — a test commissioned to give a team ammunition or embarrass a rival. Worth being aware of.

One-shot vs. recurring assessments

One-shot

Single bounded engagement at a particular moment.
Triggers: new application, acquisition due diligence, initial baseline.
Result: snapshot — "here is what we found in this scope at this time."
Results go stale as systems change.

Recurring

Repeats on schedule — annually, bi-annually, or more.
Triggers: compliance mandates (PCI-DSS, ISO 27001 surveillance).
Result: trend data — progress or regression since last cycle?
Creates institutional memory; catches configuration drift.

Mature programme One comprehensive initial assessment establishes the baseline; regular retesting monitors and validates remediation. Both models serve different needs.

Five misconceptions to dismantle today

Misconception	Reality
"A scan is a pentest."	A scan finds what is known and exposed. A pentest demonstrates what an attacker can actually do. Different legal scope, different client expectation.
"A clean report means we are secure."	It means this scope, at this time, by this tester, with this depth found no findings. Tomorrow's deploy can change everything.
"The best tester finds the most findings."	The best tester finds the most consequential findings and explains them in a way the client can act on. Count is a weak metric.
"The test is the deliverable."	The report is the deliverable. Everything before the report is the means to produce it.
"Offence is more impressive than defence."	Culturally common, professionally false. The defender's job is harder; testing exists to serve it.

How the course maps to the landscape

The four-part structure of Security is a deliberate walk through this landscape — from map to methods to mastery to output.

Part	Topics	What it builds
I — Foundations	01–06	The map and the rules: landscape, standards, scope, legal, ethics
II — Methodologies	07–13	Each methodology as a concept — OSINT through blue teaming
III — Pentest in depth	14–18	One methodology taken to hands-on depth: recon, exploit, privesc, web, kill chain
IV — From findings to value	19–23	Evidence, scoring, remediation, reporting — turning test work into client value

Why depth in pentesting? Depth in one methodology is the only honest way to teach the others as concepts. Red teaming takes years; pentesting is the right pedagogical entry point.

Check — scoping a test

Reflection

A client says: "We want a pentest." What three follow-up questions would you ask before agreeing to a scope — and what would each answer tell you?

Reveal answer

(1) Why this, why now? — reveals motivation (compliance, risk, trigger event). (2) What system, with what data? — reveals scope and risk profile. (3) Who reads the report? — reveals audience and how findings must be framed. Principle: "pentest" is not a scope.

What you take home

Security testing is systematic, authorised evaluation — not hacking, not auditing, not monitoring.
Seven methodologies (OSINT through blue teaming) are complementary lenses, not a ranked list.
Two axes — passive ↔ active and narrow ↔ holistic — explain why clients choose one methodology over another.
The attacker–tester asymmetry means a test result is always scoped, time-boxed, and documented — a clean report is not a guarantee of security.
Motivation (compliance, risk, trigger) shapes every downstream decision: scope, depth, audience, and what the client will do with findings.
Recurring assessments catch drift; one-shot assessments establish baselines — mature programmes use both.
The report is the deliverable; the test is the means to produce it.

Next: Topic 03 — Standards and frameworks. We look at how the industry has formalised this landscape into OSSTMM, PTES, NIST 800-115, and OWASP.

END · TOPIC 02

Map before methods

Revisit the two-axis diagram before Topic 03 — it is the frame every later methodology slides into.