3 ms·

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 mor

by 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
- Veserv 3y ago
  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.

by Veserv 3y ago

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

Veserv 3y ago
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.