Cybersecurity Is Broken

Back in my aerospace days I worked on an obscure secure operating system, which, unfortunately, was built for the PDP-11 just as the PDP-11 neared end of life. This was when NSA was getting interested in computer security. NSA tried applying the same criteria to computer security they applied to safes and filing cabinets for classified documents. A red team tried to break in. If they succeeded, the vendor got a list of the problems found, and one more chance for an evaluation. On the second time around, if a break in succeeded, the product was rejected.

Vendors screamed. Loudly. Loudly enough that the evaluation process was moved out of NSA and weakened. It was outsourced to approved commercial labs, and the vendor could keep trying over and over until they passed the test, or wore down the red team. Standards were weakened. There were vendor demand that the highest security levels (including verification down to the hardware level) not even be listed, because they made vendors look bad.

A few systems did pass the NSA tests, but they were obscure and mostly from minor vendors. Honeywell and Prime managed to get systems approved. (It was, for a long time, a joke that the Pentagon's MULTICS system had the budgets of all three services, isolated well enough that they couldn't see each other's budget, but the office of the Secretary of Defense could see all of them.)

What really killed this was that in 1980, DoD was the dominant buyer of computers, and by 1990, the industry was way beyond that.

While it feels dirty, I blame companies more than PCI.

Just like the failures of traditional Enterprise Architecture, the Prescriptivist, universal top down method eats lots of resources without delivering much value to the company.

While governance and policy are important, most are written to CYA more than to solve the initial problems.

As an example, as a consultant I once found a serious vulnerability with a serialization library on a very large companies stack.

Because it wasn't web facing, it couldn't be prioritized as policy didn't allow increasing its weight.

They were compromised a few quarters later... but it was their policy that they wrote that caused that.

Almost universally, restrictions and barriers have almost nothing to do with PCI requirements, but due to how the company implemented it.

A lot of that is due to the consulting and certification industrial complex and the focus on productized offerings. Just as chatGPT is intentionally verbose because it appears more authoritative, companies adopt governance that is way more detailed than appropriate.

Obviously any compliance will have some detailed and firm requirements, but the core concepts are replaced with blindly implemented checklists when values and principles are what should drive most decisions in specific systems.

The requirements to be PCI compliant often follow that concept far more closely than what companies actually adopt.

PCI DSS isn't that far off from generic best practices, optimization for superficial Self-assessment questionnaires and audits that we know don't catch much over those best practices is the problem.

[dead]

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_... Page 9

[2] 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-... Page 14 to see the searches used to validate Windows

Any C compiler can generate better assembly for a function. But there's often some whole program optimizations that you can make, which the C compiler isn't allowed to do (because of the ABI/linker).

For example, a Forth interpreter can thread its way through "words" (its subroutines) with the top-of-stack element in a dedicated register. This simplifies many of the core words; for example, "DUP" becomes a single x86 push instruction, instead of having to load the value from the stack first. And the "NEXT" snippet which drives the threaded execution can be inlined in every core word. And so on.

You can write a Forth interpreter loop in C (I have), and it can be clever. But a C compiler can't optimize it to the hilt. Of course it may not be necessary, and the actual solution is to design your interpreted language such that it benefits from decades of C compiler optimizations, but nevertheless, there are many things that can be radically streamlined if you sympathize with the hardware platform.