Live data from Hacker News

Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]

cisa.gov

11–20 of 33 posts

Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]

#11
post #2

[flagged]

As a security advocate, I hope for a future where we can move away from systems that have been vulnerable by design such as Windows, Linux, iOS, and AWS. These systems were not initially designed with security in mind and have remained structurally vulnerable over time, despite attempts to bolt on security measures. To adequately address future security concerns, we need to design and verify a new computing stack that incorporates security principles specifically aimed at thwarting nation-state attackers like the NSA.

Although some commercial systems are still being regularly targeted by nation-state or state-sponsored attackers, historical systems and certification processes such as the Orange Book Level A1, SCOMP, GEMSOS, and the Common Criteria SKPP have provided adequate validation against such attacks. Successful evaluations have included practical testing, formal specifications, and formal proofs of correctness as part of the validation process.

Meaningful security against proven threats is only possible through the application of security principles that have demonstrated success against nation-state attackers, leading to a greenfield redesign of the entire computing stack. Attempting to bolt on security measures to existing systems is unlikely to provide meaningful security against current threats, given decades of failed attempts by large software companies via certification processes.

It's important to note that while some systems, like Windows NT, were initially designed with security in mind, they still suffer from vulnerabilities. A potential solution to this issue may be to create specialized, limited-performance systems that complement lower-security systems instead of replacing them. Additionally, disconnecting servers from the internet remains a viable security measure as it is unlikely for hackers to physically infiltrate a network.

Overall, our goal should be to develop a new computing stack with security designed, verified, and demonstrated to thwart nation-state attackers, rather than attempting to retrofit security measures onto existing vulnerable systems.

Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]

#12
post #9

Earlier quoted context omitted.

Security was absolutely considered during the design process of Windows and iOS. I'm less familiar with AWS and Linux history but it's hard for me to imagine AWS wasn't designed with security in mind given a lack of security would mean people freeloading off of Amazon's servers and security was hardly an unknown subject at the time of AWS's design. One of the main selling points of Windows NT when it was released was…

Microsoft has continuously attempted and failed over multiple decades to get Windows NT of any flavor or configuration certified against anything more stringent than EAL4+ which is not even certified to protect against attackers with a "Moderate" attack potential. A older version of the standard prefaced EAL4 as being limited to protecting against "casual and inadvertent threats". That does not, by any measure, quali…

You sure put a lot of stock in these bureaucratic certifications. I agree modern OS’s are woefully insecure, but focusing on the certifications the way you do is putting the cart before the horse. Certifications are just some other org’s opinion. Hard to take them seriously when they haven’t built anything so great themselves. Following their list of rules isn’t going to change anything.

Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]

#13
post #10
post #7

Earlier quoted context omitted.

I think it's unfair to say those didn't consider security. Security was one of the big features of the Windows NT familiy in its early days, and Linux also obviously has a lot of security in its design. Their problem is that the threat model completely changed since their design. Windows and Linux were written with the assumption that a computer has multiple users, most of them without admin privileges. The threat mo…

It is absolutely fair to say they did not consider security (at least to a level that can be considered real security). They targeted a Orange Book Level C2/Common Criteria EAL4 level of security (at best) which is a level that was not even really intended to indicate there exists any security at all, and, as a result, were permanently unable to retrofit beyond that. They attempted to many times and failed every sing…

You seem to be from a bizarro world where these certifications are the be-all/end-all. No major advance in security was ever achieved by trying to follow some standard written by a bunch of people who haven’t themselves solved any of the engineering challenges.

Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]

#14
post #7
post #5

Hopefully one day we can get away from systems that are vulnerable by design such as Windows, Linux, iOS, AWS, etc. where security was not considered during their design process and are thus structurally doomed to perpetual vulnerability as decades of history have shown that security can not be bolted on. Only a greenfield redesign incorporating security designed, verified, and demonstrated to thwart the best efforts…

I think it's unfair to say those didn't consider security. Security was one of the big features of the Windows NT familiy in its early days, and Linux also obviously has a lot of security in its design. Their problem is that the threat model completely changed since their design. Windows and Linux were written with the assumption that a computer has multiple users, most of them without admin privileges. The threat mo…

Windows NT was designed as a multi-user system in which everything [0] lived in one of a small handful of global namespaces. They built an unbelievably complex ACL and “privilege” system for it. And they allowed remote systems to connect over various Ethernet protocols and interact directly with those global namespaces. And they did the latter with cryptosystems that were obviously terrible even at the time. Of course it didn’t work.

Linux is modeled after Unix, and I don’t think security was a serious initial goal. Heck, Unix has setuid, of which nothing good can be said. Most of Linux’s security advantages were due to:

1. The lack of the aforementioned global namespaces in such an egregious way. The main global namespaces is the filesystem, and that one stares you in the face. The object manager hierarchy in Windows was basically invisible until Sysinternals figured out how to enumerate it and stuck a UI on it.

2. A lack of all the Microsoft RPC crap. Your files and processes on Linux were not all visible from outside. You only had an SMB server if you chose to run one.

3. A much less complex syscall interface. Seccomp on Linux is fairly straightforward. Windows had to come up with a complex “integrity level” scheme. (Windows is full of nasty complex things like restricted jobs that seem unlikely to be used correctly by anyone.)

But at least Windows has a sensible process model and does not have privilege increases when CreateProcess is called.

Security systems that actually work are simple.

At least they had a SAK, which everyone seems to have given up on these days.

Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]

#15
post #9

Earlier quoted context omitted.

Microsoft has continuously attempted and failed over multiple decades to get Windows NT of any flavor or configuration certified against anything more stringent than EAL4+ which is not even certified to protect against attackers with a "Moderate" attack potential. A older version of the standard prefaced EAL4 as being limited to protecting against "casual and inadvertent threats". That does not, by any measure, quali…

You sure put a lot of stock in these bureaucratic certifications. I agree modern OS’s are woefully insecure, but focusing on the certifications the way you do is putting the cart before the horse. Certifications are just some other org’s opinion. Hard to take them seriously when they haven’t built anything so great themselves. Following their list of rules isn’t going to change anything.

I do, in fact, put stock in quality certifications. Most certifications are not worth the toilet paper they are written on; anything that gives a system as insecure as Windows top scores is obviously useless. In contrast, the best that Windows can certify against with respect to the Common Criteria is that it can verify that it is easily hacked by minimally skilled attackers which has been proven out in practice as true. That is a good sign of a security certification with standards, though by no means exhaustive.

You will find that all the certifications you are aware of, which has led you to the idea that all certifications are worthless, fall into this bad category since the commercial IT world is hopelessly incompetent with respect to security and their certifications are the corrupt supporting the corrupt. The standards and prescriptions they suggest are worthless as you state because they have not built anything great, have never seen a great system, and have no intention of creating acceptance criteria that their own incompetently designed systems would fail. Frankly, the number of security standards of any value is basically 0.

This does not mean that certifications created by entities that have never built the system they are trying to certify are useless. It is actually quite easy to create excellent acceptance criteria as long as you stray far enough away from prescriptive standards and accept based on the outcomes instead of mechanism. For instance, I am not a mechanical engineer, but I can design the acceptance criteria for a bridge as requiring 3x the maximum weight of fully loaded vehicles laid across the length of the bridge. I do not need to know how that is achieved, just that you must do so before I accept the bridge. Assuming such a standard is desirable (I am not a mechanical engineer so I do not know how bridge load specifications are actually done or what they must achieve), I created a fairly good standard with a acceptance test despite having no knowledge of how the bridge must be built. In fact, I can do this even if such a bridge can not be built with existing technology. In that case we have deemed that a adequate bridge with the desired safety properties is just plain impossible and should not be built.

In the case of the Common Criteria SKPP standard, one of the acceptance tests was that the NSA red-team must fail to find any deficiencies. Yes, the literal standard requires that the NSA be unable to hack it and it is verified by the NSA having a team attempt to hack it with full access to the source code, specifications, and proofs of correctness. Now for anybody whose gut instinct is that they will just pretend to fail (which is totally the right gut instinct to have), the NSA did the verification work for the only certified system, INTEGRITY-178B, at the behest of the DoD to verify that the core OS of the F-22 and the F-35, the top-line fighter jets of the US military, can not be hacked and either disabled or turned against the US by enemy countries. This is also the same system used in the flight and weapons control of the B-1 and B-2 intercontinental nuclear bombers and in various other NSA and DoD systems. So, pretending to fail is just shooting themselves, the US Air Force, and part of the US nuclear arsenal in the foot.

So yeah, go find me one of these uncertified systems that has achieved a "major advance in security" that the NSA can not hack and then we can start talking about whether there might be some good lessons to be learned. Until then we should probably look to the systems that can actually stop the prevailing threats in practice which the commercial IT sector thinks is literally impossible (that being protecting against nation-state attackers such as the NSA).

Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]

#16
I've commonly seen companies create secure by default programs around there deploying there Infrastructure (terraform/cloudformation templating). Maybe some companies do this with packages and vulnerability management. While its commendable to try this, until an organization is pretty large very little effort will be put into making secure by default design.

Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]

#18
"migrating to programming languages that eliminate widespread vulnerabilities."

"Some examples of modern memory safe languages include C#, Rust, Ruby, Java, Go, and Swift."

"Too often, backwards- compatible legacy features are included, and often enabled, in products despite causing risks to product security. Prioritize security over backwards compatibility, empowering security teams to remove insecure features even if it means causing breaking changes."

"While customer input is important, the authoring agencies have observed important cases where customers have been unwilling or unable to adopt improved standards, often network protocols. It is important for the manufacturers to create meaningful incentives for customers to stay current and not allow them to remain vulnerable indefinitely."

---

The fundamental challenge is that by the time a "secure default" has been universally agreed on, and implemented widely in a space, the target moves again. Meanwhile each vendor decides what is "most secure" based on what they have been able to implement. Businesses are left with the integration challenge, and maintenance burden, of operating equipment that changes underneath their feet with each upgrade/update in the name of "being more secure."

Government agencies could reduce the integration and adoption window by providing implementations of the "secure defaults" that were ready-to-use in the recommended programming languages. To do this they would need to be able to incentivize and recruit personnel that were capable of doing this, and adopt methods and practices that could produce such modules in a timely manner. Do governments want to distribute implementations that are usuable by any actor? Can they produce it in a timely manner? Would industry trust the implementation if it was produced by governments?

When "legacy features" are being asked for it is most likely because they have been shown to work, and integrate, well across the business. A new product may be perfectly secure, but is it usable? The last quote alludes to this, customers need to run the business to generate the revenue to afford the security.

Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]

#19
post #5

Hopefully one day we can get away from systems that are vulnerable by design such as Windows, Linux, iOS, AWS, etc. where security was not considered during their design process and are thus structurally doomed to perpetual vulnerability as decades of history have shown that security can not be bolted on. Only a greenfield redesign incorporating security designed, verified, and demonstrated to thwart the best efforts…

Security was absolutely considered during the design process of Windows and iOS. I'm less familiar with AWS and Linux history but it's hard for me to imagine AWS wasn't designed with security in mind given a lack of security would mean people freeloading off of Amazon's servers and security was hardly an unknown subject at the time of AWS's design. One of the main selling points of Windows NT when it was released was…

All of those OSes are written in C, C++ and sputterings of asm.

Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]

#20
post #19

Earlier quoted context omitted.

Security was absolutely considered during the design process of Windows and iOS. I'm less familiar with AWS and Linux history but it's hard for me to imagine AWS wasn't designed with security in mind given a lack of security would mean people freeloading off of Amazon's servers and security was hardly an unknown subject at the time of AWS's design. One of the main selling points of Windows NT when it was released was…

All of those OSes are written in C, C++ and sputterings of asm.

The entire point of an OS is to handle low level unsafe stuff so the user doesn't have to. Writing in a lower level language doesn't just make sense, it's straight up necessary. Rust is the only "modern" language that's anywhere near the stability and maturity required, but it's still quite young and rough.
Post reply on HN