Security Inspection Fundamentals and Methodology
This domain tests how you plan and govern an inspection: scoping, legal authority, methodology selection, and operational safety.
Authority and scope
Every inspection needs written authorization that names the legal entity, the in-scope assets, the testing window, and prohibited actions. Scope is usually an allowlist (CIDR ranges, FQDNs, cloud accounts) plus a denylist of fragile or third-party hosts. Confirm that DNS resolves only to authorized addresses; a hostname can point to a CDN or SaaS provider you do not have permission to test. Record start and stop times in UTC.
Methodology
The exam expects familiarity with structured approaches: NIST SP 800-115 phases (planning, discovery, attack, reporting), PTES, and OSSTMM. Choose intrusive versus non-intrusive testing based on production sensitivity and the rules of engagement. Deconfliction contact and rollback plans belong in the plan, not in an emergency chat.
Worked example
A client authorizes 10.0.0.0/24 but says 10.0.0.5 is a fragile medical device. The reasoning: the /24 is not automatically in scope as a blanket target; the exclusion must be explicit, documented, and enforced in the scanner configuration. Verify that no hostname resolves to 10.0.0.5, run a small discovery probe first, and log the exclusion.
Traps
Verbal approval is not authorization. Do not assume a cloud-hosted asset is owned by the client because it resolves to their domain. Do not treat a vulnerability assessment as an audit or a penetration test; the evidence and rules differ. Missing scope boundaries, stale asset lists, and unlogged testing times are common mark-losers.