Topics in this domain
- Security Governance and Roles
- Data Classification and Ownership
- Security Policies
- Privacy Principles and GDPR
- Identity Management
- Authentication Factors
- Biometrics
- Access Models: DAC, MAC, RBAC
- Logical and Privileged Access
- Cryptography Basics
- Symmetric Encryption
- Asymmetric Encryption
- Hashing and Integrity
- Digital Signatures
- PKI and Certificates
- Firewalls
- IDS/IPS
- VPN, SSL/TLS, IPsec
- Wireless Security
- Endpoint and Mobile (BYOD)
- Cloud and Virtualization Security
- Physical Access Controls
- Environmental Controls: Fire, Power, HVAC
- Social Engineering
- Malware
- Network Attacks: DoS, Spoofing, Sniffing
- Application Attacks: SQLi, XSS
- Vulnerability Management and Pen Testing
- Incident Response
- Digital Forensics and Chain of Custody
- Security Awareness Training
- Logging, SIEM, and Auditing Security
Vulnerability Management and Pen Testing
Finding the holes first
A home inspection before you buy a house finds the damp and the dodgy wiring before they cost you money. A security expert who actually tries to break in tells you which weakness really matters.
Vulnerability scanning is the inspection. Penetration testing is the friendly burglar.
A clean scan only means no known issues were found. It doesn’t mean the system is secure.
The vulnerability management cycle
Vulnerability management finds and fixes weaknesses before attackers exploit them. It’s a continuous cycle, not a one-off scan.
- Asset inventory: you can’t scan what you don’t know about.
- Scanning: regular automated scans of internal, external and cloud assets. Authenticated (credentialed) scans see far more than unauthenticated ones.
- Prioritisation: severity scores (such as CVSS), whether an exploit exists or is being used right now, how exposed the asset is (internet-facing or internal), and how critical it is.
- Remediation: patching, configuration changes or compensating controls, within deadlines set by severity.
- Verification: rescanning to confirm the fix.
- Reporting: metrics such as time to fix and overdue critical issues, plus documented exceptions.
Example. Monthly scans always show about 40 critical vulnerabilities, so management believes things are stable. The auditor finds they’re different vulnerabilities each month on the same servers: the patching team fixes only the last report’s list and never addresses the underlying patch process. Time-to-fix metrics, not just counts, reveal this.
Kinds of penetration test
A penetration test simulates a real attack, chaining weaknesses together to show what an attacker could actually achieve.
By position: external (from the internet) or internal (from inside the network).
By what the testers know:
- Black box: nothing in advance. Realistic for an outsider, but slower.
- Grey box: some information, such as a user account.
- White box: everything, including architecture and source code. Thorough and efficient.
By what the defenders know:
- Blind: testers get little information; the security team knows a test is happening.
- Double-blind: the security team isn’t told, so their detection and response are tested too.
- Targeted: testers and IT work together openly.
Permission first
The most important thing before any penetration test is written authorisation from management with the authority to approve it, plus agreed rules of engagement:
- scope: which systems, applications and IP ranges are in and out
- timing and testing windows
- allowed techniques, including whether social engineering or denial of service is permitted
- how sensitive data found during the test is handled
- contacts, escalation and when to stop
- confidentiality of the results
Without authorisation, testing may be illegal and could disrupt operations. Third-party systems (cloud or hosted services) need the provider’s permission, or must follow its testing policy.
How a test runs
Planning, reconnaissance, scanning and enumeration, exploitation, post-exploitation (privilege escalation, moving sideways through the network), then a report with prioritised recommendations. Testers report; fixing is management’s job, followed by a retest.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Most important requirement before a penetration test | Written authorisation from management with agreed scope |
| Test where defenders aren’t informed | Double-blind |
| Tester with full knowledge of the system | White box |
| Difference between scanning and pen testing | Scanning identifies; pen testing exploits to show impact |
| Scan type that finds the most | Authenticated / credentialed scanning |
| Prioritising vulnerabilities | Severity plus exploitability, exposure and asset criticality |
In short
- Vulnerability management is a continuous cycle: discover assets, scan, prioritise, remediate, verify and report.
- Prioritisation considers severity (such as CVSS), exploitability, exposure and asset criticality.
- A vulnerability scan identifies known weaknesses automatically; a penetration test actively exploits them to show real impact.
- Penetration test knowledge levels: black box (no prior knowledge), grey box (some), white box (full knowledge).
- Before any penetration test, written authorisation from management with agreed scope and rules of engagement is essential.
- Blind and double-blind tests evaluate detection and response; in double-blind, the defenders aren't told.
- Findings must be tracked to remediation and retested.
Exam traps
- Penetration testing without written authorisation may be illegal and can disrupt systems.
- A scan reporting no vulnerabilities doesn't mean the system is secure; scans only find known issues.
- Authenticated (credentialed) scans find more than unauthenticated ones.
- Testers shouldn't fix findings themselves during the test; they report.
- Pen test scope must avoid unapproved third-party systems.
Slides
Click the slide and use the arrow keys. F toggles full screen.