6 ms·
And still, despite the weakening, hardly anybody passed even the watered down requirements. Large vendors like Microsoft complained that the bidding process was
by Veserv 3y ago
And still, despite the weakening, hardly anybody passed even the watered down requirements. Large vendors like Microsoft complained that the bidding process was unfair because they were not even allowed to compete just because they could not meet the minimum security requirements. So, the requirements were reduced until the requirements could meet the the abilities of the vendors.
For operating systems in the early 2000s, this constituted a Common Criteria EAL4 certification according to the Controlled Access Protection Profile (CAPP) [1] which is only appropriate for: "an assumed non-hostile and well-managed user community requiring protection against threats of inadvertent or casual attempts to breach the system security". EAL4 certifications have since been viewed as too onerous for vendors so they progressively dropped it to 2 stacked EAL2, since clearly 2 * EAL2 = EAL4 (I am only half-joking). To where we are now where the requirement is only the lowest level of certification, EAL1, which does not even demand a security analysis. The vendor is only required to Google: Name + Vulnerability (I am not joking this time [2][3]) and show that any vulnerabilities that showed up were patched.
And people wonder why everything is easily hacked. Should be pretty obvious once you see the standards we hold them to.
[1] https://www.commoncriteriaportal.org/files/ppfiles/pp_os_ca_v1.d.pdf https://www.commoncriteriaportal.org/files/ppfiles/pp_os_ca_... Page 9
[2] https://www.niap-ccevs.org/MMO/Product/st_vid11349-vr.pdf https://www.niap-ccevs.org/MMO/Product/st_vid11349-vr.pdf Page 20 to see the searches used to validate iOS
[3] https://download.microsoft.com/download/6/9/1/69101f35-1373-4262-8c5b-75e08bc2e365/Microsoft%20Windows,%20Windows%20Server,%20Azure%20Stack%20Validation%20Report%20(22H2).pdf https://download.microsoft.com/download/6/9/1/69101f35-1373-... Page 14 to see the searches used to validate Windows
- alephnerd 3y agoTbh, Common Critera is basically security theatre. I've went thru the process and it's very checkbox driven and not truly design driven. There is a mutual issue of both Procurement being an onerous shitshow and vendors being lazy about validating and ensuring security. I have some thoughts about this but that would basically be a book (or an angry presentation at RSAC, Black Hat, DefCon, and Gartner Federal) Some of the federal PoCs I've been a part of recentlyish (past decade) have returned to the red-teaming methodology that OP mentioned, but it's very Agency dependent.
- Veserv 3y agoWere you involved in a Common Criteria certification at EAL5 or higher? Anything below EAL5 is just paperwork. As stated above, EAL4 is explicitly only intended to certify a system protects against casual and inadvertent attacks. Checkbox security is largely sufficient to meet that standard. In contrast, it takes actual effort to certify at EAL5 or higher which is why Microsoft and Apple have consistently failed every time they have attempted to do so. Even EAL5 is just the baby steps and at best only comparable to mid-level security like what Multics achieved in the 80s. You need to target something like the Separation Kernel Protection Profile (SKPP) if you want serious security. That demanded formal specifications, formal proofs of security, and a multi-month NSA penetration test that must fail to find any vulnerabilities. That was the certification process used for the operating system used in the F-22 and F-35, Integrity-178B.
- emmelaich 3y agoAnd yet afaik no Linux is certified higher than eal4+ and no-one buys them anyway. Efforts are better placed at isolation and hardening of a standard distro.
- Veserv 3y agoI have no idea what you are even trying to say. In this thread we are talking about how cybersecurity is broken and how certification requirements have been continuously degraded to allow insecure systems to be deployed in inappropriate contexts. This has removed one of the vital incentives for secure systems, having requirements that actually demand and verify security instead of just caving into vendor incompetence. Saying that people use systems known to have poor security because they are not required to use systems with high security supports my point. It is not even like they were asking for the impossible. High security systems designed and verified to protect against state actors were developed and deployed. Just everybody demanded they be allowed to use cheap garbage because they value their budgets over your security. Incidentally, we also learned from this process that it is basically impossible to retrofit security onto a insecure design. Any system with a insecure design must be thrown out and redesigned from scratch. Numerous attempts over multiple decades and billions of dollars were spent trying to retrofit security onto existing designs and literally every single one of them failed to this day. Attempting to "harden" existing systems to achieve meaningful security is just a fools errand when there are plenty of examples showing you can develop a secure, general purpose base from scratch, and no examples of anybody ever successfully hardening a existing system.