Quiz Entry - updated: 2026.10.13
What separates a good security requirement from a bad or an ugly one?
A good one is specific and verifiable: it names the component, the control and the exact expected state. Bad ones point in a direction but cannot be tested. Ugly ones are slogans.
| Product requirement | Technical requirement | |
|---|---|---|
| Good | "The system shall be certified to Common Criteria protection profile PP0084, to fulfil MNO certification requirements" | "The Control Unit Windows Firewall shall block all inbound and outbound connections on all Ethernet and Wi-Fi interfaces, except TCP 443 inbound from 10.123.12.3" |
| Bad | "Relevant components shall be FIPS certification ready" | "All network interfaces shall be protected by firewalls" |
| Ugly | "The product shall provide state-of-the-art security" | "The system shall be hardened" |
The good examples are S.M.A.R.T. (specific, measurable, achievable, relevant, time-bound). They also carry their rationale: PP0084 is required because the mobile network operator demands it. A tester can write a pass or fail test straight from them. "Relevant components" and "FIPS ready" leave open which components and what "ready" means. "State of the art" and "hardened" cannot fail any test, so they guarantee nothing.
Go deeper:
SMART criteria (Wikipedia) — origin and variants of the S.M.A.R.T. checklist