4 ms·
You presented arguments, but did not present any substantive, quantitative effects attributed to those changes. You have presented no quantitative means of eval
by Veserv 2y ago
You presented arguments, but did not present any substantive, quantitative effects attributed to those changes. You have presented no quantitative means of evaluating security.
Furthermore, you have presented no empirical evidence that those changes actually result in meaningful security. No, I do not mean “better”, I mean meaningful, as in can protect against commercially-motivated hackers.
None of the systems actually certified to protect against state-actors used such a nonsensical process as imagining improvements and then just assuming things are better. Show a proof of correctness and a NSA pentest that fails to find any vulnerabilities, then we can start talking. Barring that, the explicit, above-board bug bounty provides a okay lower bound on security. You really need a more stable process, but it is at least a starting point.
And besides that, a 7-figure number is paltry. Google Cloud brings in, what, 11 figures? The operations of a billion dollar company should not be secured to a level of only a few million dollars.
So again, proofs of correctness and demonstrated protection against teams with tens to hundreds of millions in budget (i.e team of 5 competent offensive security specialists for 2 years, NSO group for a year, etc.). Anything less is insufficient to bet trillions of dollars of commerce and countless lives on.
- tptacek 2y agoSo that's a no, then. Actual LOL at "an NSA pentest". Slightly later A friend points out I'm being too harsh here, and that lots of products do in fact get NSA pentests. They just never get the pentest report. We regret the error.
- Veserv 2y agoI see, you are unfamiliar with actual high security development and certification. Common Criteria SKPP [1]. “AVA_VLA EXP.4.3E The NSA evaluator shall perform independent penetration testing. AVA_VLA _EXP.4.4E The NSA evaluator shall determine that the TOE is resistant to penetration attacks performed by an attacker possessing a high attack potential.” Which has been successfully certified against [2] for use in the F-22 and F-35. Sneering dismissal of the existence of high security systems with actual empirical evidence while demanding recognition for unproven systems is ridiculous. Oh, and by the way, the SKPP, like Level A1, required formal specifications and proofs. So, no, a demand to prove such systems are secure is not a winning move. [1] https://www.commoncriteriaportal.org/nfs/ccpfiles/files/ppfiles/pp_skpp_hr_v1.03.pdf#page117 https://www.commoncriteriaportal.org/nfs/ccpfiles/files/ppfi... [2] https://www.commoncriteriaportal.org/nfs/ccpfiles/files/epfiles/st_vid10362-vr.pdf https://www.commoncriteriaportal.org/nfs/ccpfiles/files/epfi...
- kasey_junk 2y agoI’m sort of curious what your actual hypothesis is now. Are you suggesting that kvm a) has the same security surface as a general purpose os b) that its not a high enough value target to surface commercial vulnerabilities or c) that more modern development techniques, such as using Rust, don’t limit that surface beyond traditional OS’s. Not for nothing but it’s hard to follow what you are even arguing.
- Veserv 2y ago1. Commercially motivated attacks against mere mid-sized entities (100 M$-1 G$ in revenue) can empirically derive 10s of M$ from successful attacks. Adequate security must make such attacks unprofitable. This constitutes a absolute, rock-bottom, minimum standard for effective enterprise security. 2. We have always known that such attacks would eventually become feasible to execute once the hackers matured. This was so obvious that government security standards/certifications such as the Rainbow Series codified in the 80s already considered such threats and placed thwarting them as the middle-levels of security. So, we have always known that "adequate" security against commercially motivated attackers has always demanded protection against skilled teams. 3. The commercial IT systems in regular use have never once, over 40 years, demonstrated the levels of security needed to protect against such commercially motivated attacks. These techniques and processes have failed continuously to achieve adequate security despite claiming to solve it every year for 40 years. At some point you need to stop listening. 4. There are systems that did achieve adequate security against commercially motivated attackers and even security against state actors in those 40 years. These standards were not pie-in-the-sky unreachable goals. They were "practical" if you actually cared about security. 5. KVM is in the commercial IT system category, being derived and developed by people who have never once deployed, developed, designed, or likely even seen a system known to have adequate security. Such systems DO NOT get the benefit of the doubt. There is no metric of evaluation, no means of evaluating if the theorized improvements achieve adequacy. In fact, you would be hard-pressed to find literally anybody who would stand up and say: "KVM is unhackable by any team with a budget of 10 M$" (budget including the average salary for the team members so you do not get a talented team doing it just to prove it can be done). Nobody will vouch for the system claiming it achieves even the bare-minimum requirements for adequate security I stated above. That it might be "better" than the Linux kernel is irrelevant; bad is also better than terrible, but it is still bad. At the end of the day they are not meaningfully different; they are all inadequate and unfit for purpose. So, you can disagree on two primary positions: 1. 10 M$ is too high of a standard for mid-size enterprise security. 2. Commercial IT systems, such as KVM, achieve the 10 M$ level. You could also argue that I am being reductive by defining security as the cost for a successful attack. But that is silly because it is the one metric that exactly aligns with the operational goals. Every other metric is a means of helping quantify the cost of a successful attack. To put it another way, if you had a magic genie that told you that number, you would not even bother with any other metrics; you have a direct line to what matters. In summary, it is none of the above. The betterness of KVM is irrelevant except if it achieves adequacy. There is no evidence of that and until there is, KVM is not categorically distinct from any other inadequate system. So, the original point still holds, the reason these "secure VM" techniques are not applied to make a "secure OS" is that there are no "secure VM" techniques to be found in that corner of the world.