Hacker News Reader

Comment by rapjr9 | Hacker News Reader

It's time to admit that computers connected to the internet can not be secured. Even if the entire operating system is vetted and locked down, and only vetted and audited apps are run on the system, there will always be zero day exploits. Science has come up with no possible way to provably secure network connected computers. So do not trust them any more. Please prove me wrong, but I doubt you can. The most trusted computers in the world have repeatedly been hacked. And even if you could make a secure computer, people can not be trusted because there is always some way to compromise them. Maybe the best we'll ever be able to do is assume a system will eventually be compromised and concentrate on minimizing damage and fast recovery. Removing the incentive to compromise computers could be a solution, but that seems even less likely given our million year history.

View on HN

>It's time to admit that computers connected to the internet can not be secured.

That ship sailed a long time ago.

It was normal back in the 1990s for InfoSec folk to assume that "if it's connected to the Internet, eventually, it will be compromised."

The goal (then, as now) is to implement layered (defense-in-depth) mechanisms to deter such activities -- at perimeters, network and systems infrastructure platforms and software implementation.

This is (and has been for a long time), a well-defined, although usually poorly (if at all) implemented set of processes and procedures.

The levels of complexity for Internet resources have vastly increased over the past 25 years. Info Security techniques have advanced as well, but again are often poorly or not at all implemented.

However, far too many organizations implement a "Skittles" type defensive posture rather than defense-in-depth posture.

There are a variety of reasons for this:

1. Those responsible are ignorant of good security practice;

2. Those responsible are aware of the risks, but ignore it as it negatively impacts profit;

3. Those responsible are aware of the risks, but implement inadequate defenses because of the impact on time-to-market and/or profit.

4. But the most egregious offenders are software developers, who often just bolt on weak security measures or just ignore security altogether, rather than design with security as a primary consideration.

There are other reasons, but those are the big ones, IMHO.

True. However, now that APT tools have been leaked to the world I think I can still argue that even layered defenses are no longer sufficient. I listened to security researchers say for years that there was no point in trying to address APT's because they were just impossible to stop. Now APT methods are public knowledge and being used in common attacks. Some types of APT attacks are still too costly to be widely used, but some that used to be considered very sophisticated (like hiding an MCU in a computer cable) are not.

The reasons you list for a weak defense posture don't really apply to a government. Also the GAO has issued a constant stream of reports saying US government agencies have poor security. It was likely only a matter of time before something like this incident happened. Similarly it's probably only a matter of time until the IRS, Social Security, and other agencies are successfully attacked on a large scale.

>True. However, now that APT tools have been leaked to the world I think I can still argue that even layered defenses are no longer sufficient. I listened to security researchers say for years that there was no point in trying to address APT's because they were just impossible to stop.

Perhaps I'm a little dense, but I'm not sure what you're arguing here.

Are you asserting that since sophisticated threat actors exist, security processes and procedures are useless, and as such, shouldn't be adhered to or implemented?

No, I'm saying researchers ignored APT's for decades and now that they are available to everyone many current security processes and procedures are less effective, and yes possibly useless, _regardless_ of whether sophisticated threat actors exist (because their tools have been exposed). Current processes and procedures should still be used because they are all we have, but something new is also needed. Part of that something new should be an acknowledgement that systems are unprotectable, so instead of just security procedures we need, for example, faster recovery procedures (not just restore from backup). Another example might be dual implementations of systems, built with different technologies, so that when one is compromised the other is less likely to be susceptible to the same compromise. Expensive, but that may be what it takes to keep the world running. Splitting the internet into layers of VPN's with everything having it's own VPN might be useful too. The internet is fragmenting anyway, might as well fragment it in a useful way. Maybe everyone should have multiple physical computers as well, one for each work project, one for play, one for home finances, etc., each with tailored protections and no connections between them. I'm not sure what the answers are but it's obvious what is being done now is not good enough. I do fully expect to see the IRS hacked, chemical plants destroyed, factories stopped, etc. the way things are going now. Simple ransomware is already causing major problems and there seems to be no way to stop it and it's going to spread to all sectors and it seems likely there will be ransomware without the ransom too, just pure destruction. Already happened in Saudi Arabia.

>No, I'm saying researchers ignored APT's for decades

That isn't even close to being true. In fact, that statement is ridiculous on its face.

Research into detecting, mitigating and countering such attacks go back at least 30 years.

That APT actors have often been successful is more a function of effective execution and poor security practices than lack of knowledge/research around such attacks.

How can you blame software engineers when they are given literally 0 credit for developing software with security in mind and 100 percent credit for simply shipping as quickly as possible. Developing with security in mind will take longer and is literally the opposite of what companies ask for.

>How can you blame software engineers when they are given literally 0 credit for developing software with security in mind and 100 percent credit for simply shipping as quickly as possible. Developing with security in mind will take longer and is literally the opposite of what companies ask for.

Police are credited with making arrests, but are almost never credited with treating people with respect.

By your logic, police should be encouraged to treat those they're supposed to protect and serve with disrespect and err on the side of locking people up, rather than trying to create a safer, more prosperous community.

Doing the right thing for the right reasons is (or should be) a thing. That it isn't doesn't say much for those who ignore an important aspect of software design.

I've always striven to meet the ideal that "if it's worth doing, it's worth doing properly."

I suppose that I shouldn't hold others to the standards I set for myself, but sometimes I still do.

Feel free to be offended, but I stand by my original statement:

"4. But the most egregious offenders are software developers, who often just bolt on weak security measures or just ignore security altogether, rather than design with security as a primary consideration."

> Police are credited with making arrests, but are almost never credited with treating people with respect.

> By your logic, police should be encouraged to treat those they're supposed to protect and serve with disrespect and err on the side of locking people up, rather than trying to create a safer, more prosperous community.

No, by their argument, to the extent your first quoted sentence is true, police are (not “should be”) encouraged to treat those they're supposed to protect and serve with disrespect and err on the side of locking people up, rather than trying to create a safer, more prosperous community.

Which seems pretty accurate.

>Which seems pretty accurate.

Exactly. Which is why it was a good analogy WRT the lack of security baked into the design of most software.

> the most egregious offenders are software developers

Blame always rises. Management knows that any product without extensive review is going to be bad. They push it out the door without that review because quality costs. Stockholders know. Software is bad because you can't sue the companies that made it.

>Blame always rises. Management knows that any product without extensive review is going to be bad. They push it out the door without that review because quality costs. Stockholders know. Software is bad because you can't sue the companies that made it.

I get that a variety of pressures are put on developers to add features and ship quickly.

But whether it's corporate development done internally (e.g., LOB applications), a web app or a SaaS offering, not designing security into the software is a disaster waiting to happen.

So many times I've seen businesses have their crown jewels ripped off due to poorly implemented/weak or non-existent security practices in application design/development.

Even when the infrastructure is reasonably well secured, with defense-in-depth, including strong authn/authz, separation of duties, as well as strong security processes and policies in place, software that lacks designed-in security can render all of it useless.

Whether that's because the software doesn't/can't integrate with the security tools in use (often requiring applications to run with much higher privilege than they should) or because little or no thought was given to secure coding mechanisms or access controls.

I absolutely understand that there are always security trade-offs, regardless of where in a multi-layered infrastructure/management/application environment.

And it's always important not to expend resources beyond what's appropriate for the assets being secured.

That said, application software is the most frequent culprit in enabling compromises (followed closely by poor security implementation in the infrastructure and a lack of policy/process in securing it -- usually through ignorance/incompetence).

My argument is not that developers are stupid or ignorant, but that security isn't baked-in to their design decisions as a guiding principle.

And that often leads to insecure software and/or sloppy/insecure integration of security after the fact.

If more developers thought about security as a feature rather than an inconvenience to be given little thought or just lip service, that would make a big difference.

Edit: Clarified verbiage and fixed typos.

Show me a single project where the functional specs were complete when given to the developers and external concerns didn't dictate any implementation details. All of the projects I've been on have had changing specs, right up to and through release.

I love the architecture weenie role. It's tons of fun. But eventually you need to build something and only with experience do you discover the first set of complications, then marketing starts promising features and you've got the next, and management refuses to allocate more time.

Did you do something wrong at step 1 by building a prototype before knowing it would be perfect? And if so, how could you know that and what would you do to get there?

I write the code, and tag releases, but I don't determine what ships. I, and 95% of us, are not engineers and even those who are have abrogated their responsibility to make the bridge stand - we're all just building individual struts because someone told management that things done in a vacuum will all fit together properly in the end.

So I agree I guess, but don't at the same time.

>So I agree I guess, but don't at the same time.

I suppose I do too.

While a lack of designed-in security is often the (sometimes disastrous) result, I posit that it's more about a lack of knowledge/education around good software security design/implementation than spec changes or scope creep.

If good security design practices were stressed when teaching software development (and/or included in resources for autodidacts) and given the same value as other development concepts, developers would incorporate those concepts from the start, rather than having to bolt them on (or not) later on.

As such, it's more about lack of knowledge/focus/value placed on security in software design/development.

Given the value of data that being secured with software, good security practices should be, if not just as integral, to software development as performance or UX design, it should at least be a consideration before prototyping.

> I posit that it's more about a lack of knowledge/education around good software security design/implementation than spec changes or scope creep.

It probably depends on what your team is good at. I tend to work in fairly security conscious teams. They check the length of buffers, don't rely on anything from the user, etc. So most of our issues tend to be from our architecture being drastically changed to integrate our solution into something else, or vice versa. Stuff is dropped on us, opaque libraries and internal code, and entirely new goals created around the big stuff, data persistence, key management, and so on.

But when I had an actual stable product that could not get spec changes (it was custom hardware) we knew from the beginning how the project would go and how all of the pieces would fit and it went together cleanly. But, it turns out many embedded engineers don't (didn't maybe, it was a while ago) program as defensively because they're used to owning the entire scope. If they put a value somewhere they expect it to be there, unmolested, when they want it. That project was full of buffer overflows and bad crypto.

> If good security design practices were stressed when teaching software development (and/or included in resources for autodidacts)

Yeah. I'm not sure how but it does tend to be lacking. Everyone probably needs a different hook. For me it was quality. How could I say my software does X if you have a way to break it?

This is equivalent to me saying I blame security researchers because they don't develop software which forces all software paradigms to follow rules that implement perfectly secure software

> It's time to admit that computers connected to the internet can not be secured.

Iranian centrifuges were air-gapped (ie no internet connection) and they still got hacked by Stuxnet via USB. https://en.m.wikipedia.org/wiki/Stuxnet

We are well past the point where even stuff that's not connected to the internet can not be secured.

I am bit skeptical of the accidental USB insertion story.

A secure air gapped network won't have open USB ports . Only privileged users who know what they are doing should even have access to a port.

You bring up a very good point and it's worth reiterating that the Kremlin reverted to use paper instead of computers to discuss sensitive topics. [1]

I wouldn't be surprised if any network connected device is vulnerable to being exploited, even if not directly connected to the internet, by association of other devices on the network.

[1] https://www.usatoday.com/story/news/world/2013/07/11/russia-...

I think it is just a problem between theory and practice. In theory it is possible, but in practice it has proven to be so hard, that I am not sure if there ever was or will be a secure computer that is connected to the internet.

Another problem is that the complexity in modern systems is increasing and designing secure systems on top of complexity is next to impossible. I think Unikernels have a good chance of delivering secure systems from a software perspective, but it seems even modern hardware has enough vulnerabilities to thwart those plans.

To be fair you have the burden of proof by asserting "computers connected to the internet can not be secured."

It's an open problem in science to prove security of a network connected computer. It's well known.

Really? What's that problem called? As you stated it, it seems too vague to be considered "open" or "closed".

Provable Security:

https://en.wikipedia.org/wiki/Provable_security

If you read that article you'll see that current approaches don't even attempt some kinds of proofs such as proof of security against side channel attacks. It goes by other names as well such as proof of code correctness:

https://www.schneier.com/blog/archives/2009/10/proving_a_com...

A major problem with current attempts at proofs is you can at best create a proof based on a system specification and what you want it to be secure against, which basically means you have to already know all possible attacks including zero day attacks. So far the field has resulted in nothing practically useful as far as I know. Homomorphic encryption might be close to being practical for a limited set of problems and could be provably secure for a limited set of attacks, though I don't know if anyone has attempted such a proof yet.

Thanks. That sounds about as fruitful as I would have guessed.

>To be fair you have the burden of proof by asserting "computers connected to the internet can not be secured."

How so?

In fact, competent InfoSec folks will tell you that you should assume that "if you connect a device to the Internet, eventually it will be compromised."

That's not to say a device will be compromised, but making such an assumption, given the history of Internet connected devices is an eminently reasonable one.

I've yet to see any formal proof that computers connected to the Internet can be secured.

If you have, please link a reference. I'd love to see it.

Extraordinary claims require extraordinary evidence.

But even ordinary claims require ordinary evidence.

The burden of proof is on the claimant, not the defendant. I believe that's the point parent was addressing.

>The burden of proof is on the claimant, not the defendant. I believe that's the point parent was addressing.

Absolutely. I was pointing out that in this specific case (whether or not devices connected to the internet can be secured), the converse is also true.

there is a saying in infosec, "not if, but when". no one is under the dissolution that we can keep a network perfectly safe, we just implement layers to mitigate damage

Reply on news.ycombinator.com