Do you have knowledge of physical security? Contributions to the registry are welcome!
The Virtual World Has a Physical Address
The virtual world rests on foundations that are physical, and too often overlooked. Every cloud service runs on machines that sit in a building, behind a door, watched or not by someone. When data is lost, the cause is sometimes a flaw in the code. Sometimes it is a door that did not hold, a badge that should have been cancelled, or an alarm that rang in an empty room.
Software security learned long ago to name its failures. A category of flaw has an entry in CWE. A known flaw in a given product has a CVE identifier. An attacker's technique is described in CAPEC, and a score such as CVSS helps teams decide what to fix first. Two engineers on opposite sides of the world can say the same few letters and mean the same thing.
Physical security has no counterpart. There are good standards on how to design and run a secure facility, but when an audit finds a weakness, the finding is written in the auditor's own words. What one report calls weak physical access control, another calls inadequate entry protection. The two cannot be compared, counted or searched, and what one team learns rarely reaches the next.
A shared vocabulary does not repair a door. It does something that comes earlier, which is to let people agree on what they are looking at. For physical security, that agreement needs a name and a stable identifier for each weakness, a common structure to describe it, and a method to rate how serious it is on a given site.
The Physical Weakness Registry Explained
The Physical Weakness Registry provides the first two. It follows the model of CWE. Each weakness has an identifier that never changes, such as PWR-7, and an entry written the same way every time: what the weakness is, where it applies, how it can be exploited, what it can lead to, how to reduce it, and which standards address it. Entries are organized from general to specific, so that a broad family like access control contains more precise weaknesses, and some of those have variants. There are 26 entries today, in four families: entry control, credential management, monitoring and logging.
Two rules shape the writing. A weakness is a condition of a site, not an attack, so an entry never describes how to break in step by step. And standards are cited by their identifier and never copied, which keeps the registry free to reuse and keeps the original texts where they belong.
A Physical Vulnerability Scoring System
The third part, rating severity, is handled by a companion method called PVSS, the Physical Vulnerability Scoring System. It follows the spirit of CVSS, with a form of ten questions that produces a vector, a score and a severity level. The questions cover who can attempt the exploitation, with what means, whether it would be detected in time, how critical the protected asset is, what is harmed, whether people are endangered and how far the consequences spread. One choice sets it apart. The criticality of the asset is mandatory and limits the result, so an easy weakness on an ordinary asset does not come out as critical just because it is easy. Its tables, code and test cases are public, so anyone can check the method, challenge it and test it against their own audits.
A registry grows with the experience behind it. Anyone who has audited, designed or defended a site has met weaknesses that deserve an entry, and has views on the ones already there. Entries are plain files in an open repository, changes go through public review, and contributors are credited in the entries they help write.
The virtual world has a physical address. Describing what can go wrong there, in words everyone reads the same way, is a job for many hands.
Explore the Registry: https://pwr-security.org/explorer
Would you also like to contribute to tomorrow's standard? Contributions to the registry are welcome!
Top comments (0)