Cybersecurity Is Broken

> I have no idea what you are even trying to say

The person is (correctly) pointing out that Engineering/Technology is only 50% of the cause of a breach.

Security breaches are equal part technical issues (eg. Bugs, misconfigurations) and process failures (eg. requiring multiple VPs giving the go-ahead on upgrading your Artifcatory server).

Purely technical solutions will not stop breaches.

The belief that bug free formally verified code for something as complex as a fully functional OS (not an embedded or RTOS) can be developed and scaled out is unrealistic and wouldn't solve plenty of much easier vectors of attack.

I'll let Trail of Bits explain for me (thank goodness they recently published a blogpost about this very topic) [0]

[0] - https://blog.trailofbits.com/2024/03/22/why-fuzzing-over-for...

I have no idea why you think that explains anything. It is just saying that fuzzing is a inferior substitute for formal methods, but much cheaper and thus a more cost-effective option. That is totally divorced from literally any point I have ever made anywhere.

Formal verification is a known mechanism for establishing highly secure systems. It is not the only way. But it is a way that is known to work. A certification process that demands formal verification and practical penetration testing by the NSA is, as far as we know, a highly effective means of identifying a high security system designed to protect against state actors. It may generate false negatives, but it is highly unlikely to generate false positives.

In contrast, extrapolation from processes used by systems that are known to be insecure and security procedures that have never once produced systems that can do things like withstand a practical penetration test by the NSA are highly speculative at best. You must not only do them, you must then generate empirical evidence of security against highly sophisticated and well-funded adversaries, such as practical penetration tests by highly competent red teams, before you can determine if your theories are correct. Anybody who has never achieved success against such adversaries has no business dictating forward looking strategy.

As to your assertion that a highly secure fully functional OS can not be developed and scaled out. Then you must either believe that it is okay to connect nuclear power plants and medical devices to the internet with insecure systems or that we must not connect and disconnect all safety-critical systems from the internet. We can not have it both ways. We must either solve the problem technologically or socially, the alternative is catastrophe. You can advocate unproven techniques that have failed for everybody who has ever tried them, but I prefer to advocate using techniques that are empirically known to work and building from there up to more security and down to easier implementation.

Okay, so you were not involved in a EAL5 or higher software certification. You did a checkbox-level certification and think that proves the harder certifications are all useless. Sure, if the harder certification was useless then you would have a point. If the Navy SEAL test is easy, bootcamp is easy. That logic does not go the other way. Just because you can pass bootcamp does not mean you can be a Navy SEAL.

As to your point about ROI, well duh, we are literally in a post about how cybersecurity is broken because nobody cares about cybersecurity. Of course the ROI is poor if nobody cares. I also never even said that formal verification is a goal. I said that the SKPP is a means of demonstrating a product has serious security as it demands a very stringent process that, as far as we know, is theoretically and empirically verified to protect against highly capable state actors. You could theorize some other means of doing so and then verify those means are effective by empirically testing it against highly capable red teams, but you can not claim those techniques are effective prior to the tests, and the SKPP is a known effective certification mechanism for the level of security needed against state actors.

As to the fact that there is more work to be done than just a secure foundation. Again, another duh. But again, should we rely on processes that have failed to produce secure systems for decades, or should be rely on processes that have demonstrably achieved a level of security that most people believe to be impossible. All the high security processes have ever done is succeed at a small scale. That is clearly inferior to the regular processes that continuously fail at immense scale. I mean, everybody knows how to scale and hardly anybody knows how to make things secure, but clearly scaling is the hard part in this equation.

And frankly, this is all besides the point. We need highly secure systems at scale or we must disconnect safety-critical systems. Saying that we do not know how to be secure at scale does not mean it is magically okay to be insecure at scale. Engineering is about minimum requirements, you do not get to just muddle through and harm people because you want to do things beyond your capacity.

Oh please. This entire comment chain is about how they do not demand highly certified systems. Literally the only substantial thing I mentioned is the thing they have not mandated or pushed to implement. The only secondary thing I mentioned is that they should use systems that are empirically determined to protect against well-funded attackers as that is the actual goal. I did not supply a number to that, but I usually use 10 M$ as a bare minimum since we have seen numerous financially motivated attacks coming in around that number already. So, a 20 person red-team with 1 year full-time must not be able to find any vulnerabilities in your system, then you meet that bar. Again, nobody does that either. So, the only two things that I said are not being done.

Then you keep coming back to how their security teams need to focus on easier wins. Yes, they do, but even if they do them all they have still failed to reach the minimum bar. The goal is not "better" it is "adequate". Following all modern best practices and doing everything correctly still leaves you vulnerable to the now commonplace attacks by financially motivated professional criminals. Being unable to protect against the adversaries who are literally attacking you is the definition of inadequate.

Technology is the limiting factor for adequate security deployments. No matter how good your processes are you are still screwed against competent adversaries. That is not to say that technology is the limiting factor for most companies. Most companies also have bad processes. No matter what technology they are given they will screw it up. But even if you do everything (within reason) right and achieve the maximum potential of what is achievable you still have a inadequate system. That is a untenable state of affairs.

As to your random personal attacks. I design and develop actual high security systems in defense applications. People do frequently accuse me of not knowing what I am talking about because what I view as standard processes are what they view as impossible dreams. I do try to tamp it down to be generally applicable even to low security systems.

I mostly agree with this sentiment, but please let's not pretend like we're doing it because we care about "security", and not just because we don't like some of C's 1970's legacy crap.