3 ms·

I 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 con

by Veserv 3y ago

I 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.

alephnerd 3y ago
> 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-formal-verification/ https://blog.trailofbits.com/2024/03/22/why-fuzzing-over-for...
- Veserv 3y ago
  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.
  - alephnerd 3y ago
    Excluding formal verification, most of the stuff you mentioned has already been mandated and pushed to implement for at least 7-8 years at this point. The issue you still have straddlers who hasn't finished implementing these best practices due to organizational or financial issues. I'm just going to stop responding at this point because I don't think you've ever actually had to chat with the SecOps teams of a Healthcare Group or a Utility and I seriously have doubts you've ever actually worked in the security space And I say this as someone who has played around with INTEGRITY - most half decent EECS departments have a license for it and faculty who have worked in the space. You seem fixated by runtime and kernel attacks, which only make up a small portion of actual attacks > 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 Wow. You must be the first guy who has thought about this. Give this guy a Turing Award. I don't think organizations whose infra falls under the remit of safety-critical hasn't been in the middle of a 10 year process of trying to airgap or decouple environments. Or maybe, just maybe, there are tens of billions if not trillions of embedded computing devices and shadow IT systems that are in various differing levels of compliance, and organizations might not even realize are even running. And maybe most industries that aren't software and finance run on single digit profit margins and have very limited cash on hand to manage a migration. And maybe an EMR is different from VE 11

by Veserv 3y ago

alephnerd 3y ago

> 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-formal-verification/ https://blog.trailofbits.com/2024/03/22/why-fuzzing-over-for...

Veserv 3y ago
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.
- alephnerd 3y ago
  Excluding formal verification, most of the stuff you mentioned has already been mandated and pushed to implement for at least 7-8 years at this point. The issue you still have straddlers who hasn't finished implementing these best practices due to organizational or financial issues. I'm just going to stop responding at this point because I don't think you've ever actually had to chat with the SecOps teams of a Healthcare Group or a Utility and I seriously have doubts you've ever actually worked in the security space And I say this as someone who has played around with INTEGRITY - most half decent EECS departments have a license for it and faculty who have worked in the space. You seem fixated by runtime and kernel attacks, which only make up a small portion of actual attacks > 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 Wow. You must be the first guy who has thought about this. Give this guy a Turing Award. I don't think organizations whose infra falls under the remit of safety-critical hasn't been in the middle of a 10 year process of trying to airgap or decouple environments. Or maybe, just maybe, there are tens of billions if not trillions of embedded computing devices and shadow IT systems that are in various differing levels of compliance, and organizations might not even realize are even running. And maybe most industries that aren't software and finance run on single digit profit margins and have very limited cash on hand to manage a migration. And maybe an EMR is different from VE 11