4 ms·
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 certification
by Veserv 3y ago
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.
- alephnerd 3y ago> We need highly secure systems at scale or we must disconnect safety-critical systems I agree, and safety-critical systems are getting disconnected now, or are in the process of being disconnected. The biggest issue is disconnected your Shadow IT environment - basically those systems and environments running without the knowledge of your security, development, or platform teams. Most attacks we've seen in Utilties and Healthcare environments have directly occured on those kinds of systems. A Formally Verified OS is helpful, but would not solve this kind of an Asset Management and Inventory problem > ROI is poor if nobody cares Even if I'm Google scale in budget, I need to prioritize vuln patching, compliance needs, misconfiguration prevention, architectural designs, etc. On the scale of things, a kernel based attack is relatively lower on the scale of actionable vulnerabilities. > 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 Let's say you are running formally verified OS that everyone is using. Maybe you've airgapped this system, yet there is a memory based attack that was recently published in the NVD. A formally verified OS would not have solved it. There is a reason those IBM Mainframes wand Green Hills RTOSes with EAL5+ certification are airgapped and access locked down. Runtime level attacks make up maybe 40% of all vectors of attack - a large but not singular cause.