Section 11
Intermediate
Standards & Case Studies
Physical findings land harder when they map to current standards and real failures. This chapter gives you a translation layer from offensive observations to governance language, while keeping a few case studies that show how access, process, and authorization failures become very expensive quickly.
Information
Not every standard applies to every client. Identify which frameworks the organization already follows before mapping findings — aligning with their existing language dramatically increases remediation adoption.
Standards Mapping
| Reference | Why It Matters | Use In Reporting |
|---|---|---|
| NIST CSF 2.0 | Lets you anchor physical findings in Govern, Protect, Detect, and Respond language | Useful for executive summaries and cross-program remediation |
| ISO 27001 / 27002 | Provides physical perimeter, monitoring, and media-handling control references | Strong for audit-driven clients and policy alignment |
| UL 294 | Helps frame access-control hardware quality and tamper resistance expectations | Useful when badge readers and door hardware are part of the finding |
| OSDP Secure Channel | Modernizes reader-controller communication versus insecure Wiegand deployments | Use when exposed reader wiring and cloning risk appear together |
| ONVIF / CCTV guidance | Frames camera management and interoperability expectations | Use when surveillance coverage or camera network exposure is weak |
Make Physical Findings Easy To Fund
Facilities, security operations, and IT often own different parts of the same weakness. Standards language helps you describe the issue in a way each team recognizes, instead of making the report sound like an isolated red-team anecdote.
Case Study Patterns
Coalfire Iowa Courthouse
Physical testers with authorization were arrested after local law enforcement and local stakeholders were not aligned on the engagement.
- • Lesson: authorization must be socially and operationally distributed, not just signed
- • Lesson: after-hours physical work needs explicit local coordination
Target HVAC Vendor Path
A trusted third party became the route into a much larger environment, showing how contractor trust and operational access can bypass stronger central assumptions.
- • Lesson: vendor workflows are part of physical and identity security
- • Lesson: "authorized presence" should not imply broad network trust
MGM Help Desk Social Engineering
Not a classic physical breach, but an instructive reminder that identity confidence and human verification still fail when urgency and familiarity win.
- • Lesson: challenge culture and trusted callback processes matter across channels
- • Lesson: physical and digital identity workflows should not be separated in analysis
Failure Modes To Call Out Explicitly
- • Authorization exists on paper but not in the awareness of local guards, reception, or law enforcement
- • Badge systems are treated as strong despite insecure reader wiring, weak credential tech, or no anti-tailgating culture
- • Cameras provide presence theater without useful identification or meaningful response
- • Visitor and contractor processes create trusted humans who then move unchallenged into technical attack paths
False Positives
- A framework the client does not use: Mapping a finding to a standard the organisation never reports against reads as an outsider lecture. Ask which frameworks they already answer to before you map anything.
- Control claimed but not verified: A policy document is not evidence that the control operates. Name the artefact you saw, and say plainly when the claim is unverified.
- Case study transplanted: The courthouse arrest and the vendor path explain patterns of failure. Neither is evidence about this client, and neither belongs in a findings table.
- Framework language inflating severity: A NIST CSF category describes function, not impact. Keep severity in your own terms and use the framework for ownership and funding, not scoring.
- Authorisation that never reached the site: A signed scope that local guards and reception never saw is a real problem, but it belongs in the engagement narrative, not the technical findings.
Mapping Checklist
Before mapping
- ☐ List the frameworks the client already reports against, and who signs those reports.
- ☐ Identify the owners: facilities, security operations, and IT usually split one weakness three ways.
- ☐ Decide the primary reference per finding before writing, so a finding is not mapped to four frameworks at once.
Mapping
- ☐ Name the control the client claims, and the artefact that shows the gap.
- ☐ Keep one primary reference and at most one supporting reference per finding.
- ☐ Write the recommendation in language the funding owner uses, not in framework shorthand.
After delivery
- ☐ Give every recommendation a named owner and a review date.
- ☐ Offer the standards summary as a separate one-page view for leadership.
- ☐ Re-check the mapping when the client changes framework or audit cycle.