'Disconnect from the internet' is a kind of 'Security through obscurity'; which isn't very good security.
It's basically an admission that the software may be full of vulnerabilities and the only way to protect it is to limit its exposure to the outside world.
The root of the problem is that almost all software is poorly designed and full of unnecessary complexity which leaves room for exploitation. Companies don't have a good model for quality software and don't aim for it as a goal. They just pile on layer upon layer of complexity.
Quality software tends to be minimalistic. The code should be so easy to read that an average hacker could hack it in under an hour if there was an issue with it... But if the code is both simple and there is no vulnerability within it, then you can rest assured that there exist no hackers on the face of the earth who can exploit it in unexpected ways.
The attack surface should be crystal clear.
You don't want to play a game of cat and mouse with hackers because it's only a matter of time before you come across a hacker who can surpass your expectations. Also, it's orders of magnitude more work to create complex secure software than it is to create simple secure software.
The mindset to adopt is that bad code deserves to be hacked. Difficulty involved in pulling off the hack is not a factor. It's a matter of time before hackers can disentangle the complexity.
I don't agree that airgapping is security through obscurity; it's defense in depth, just like putting up a fence around your datacenter. It doesn't solve your insider risk (or 12 foot ladder risk), but it is an additional measure.
> 'Security through obscurity'; which isn't very good security.
I never understood this. You never have absolute security, that’s why you must apply the Swiss cheese model. Obscurity is definitely a worthy slice to have. Few people can attack you if you can only be attacked in person.
The "Swiss cheese model" worked against amateur attackers. It doesn't hold up against well-funded or patient ones who can work through the holes in each layer. The extreme demo of this was Stuxnet.
All security is really just the swiss-cheese model. Some entities just invest in more slices than others to keep more sophisticated/determined attackers out (such as nation states).
What other practical model is there for security then defense in depth? "Just make 100% bulletproof computers with no faults?"
- Systems that store the code in read-only memory. Example: slot machines.
- Systems with backup systems completely different from the main system, implemented by a different group, and thoroughly tested. Example: Airbus aircraft.
- Systems continuously sanity-checked by hard-wired checkers. Example: Traffic lights.
- Systems where the important computational functions are totally stateless and hardware reset to a ground state for each transaction. Example: #5 Crossbar.
Systems security is an economics game. It is valuable to be protected against amateur attackers even if the most extreme state actors can still breach you.
The criticism of "security through obscurity" is specifically Kerchoff's Principle, which applies to cryptographic systems. It is not an absolute rule outside of that domain.
No but it makes it a hell of a lot harder for them to do it undetected.
There's a reason Stuxnet was an exception. These things are not very common and the only reason we even know about it is because it managed to spread further than its intended target.
What is better than the Swiss cheese model or its derivatives? Planes still crash from time to time, but nobody is saying that the model is wrong as the reliability is insane.
> 'Disconnect from the internet' is a kind of 'Security through obscurity'
I disagree with this, no internet is not an obscurity this is more like incapsulation for the sake of having controllable interface via setters and getters only.
If some computer rules something (something big as an airport or something tiny like a washing machine) how often it really needs an update of something system-related like the kernel? How many MB of code with potential 0-days are you going to expose to the wild for the sake of that autoupdate?
Cybersecurity is mainly a technical application of risk management.
An untrusted network (the internet) is a risk. Removing access from that network is one way to mitigate that risk.
Obscurity doesn’t remove a risk, it just reduces its likelihood. An obscurity approach here would be more akin to changing your SSH port from 22 to some random number rather than blocking SSH entirely.
I have no experience in cybersecurity, but if the software is possibly full of vulnerabilities and the company is not willing to fix it, why not support disconnecting it if it functions anyway? Analogously, someone who lives in a dangerous neighborhood locks their doors because they can't move somewhere safer, and that's viewed as normal.
Give an example of software that exists for decades and never had an exploit. You might say basic OS tools. The OS might not be secure then; giving internet terminals to everyone in the world is just a stupid oversight; the best is probably a combination of both having internet when needed but most access to it to be through an extremely thick layer of firewalls (e.g. only system administrators updating stuff should be exposed to the internet for software involving airport security).
I actually agree with this. Of course it's easy to dismiss as "just don't make mistakes" but there is a profound lack of simplicity. For example, a security boundary like ssh or vpn should not have a billion configuration options (or any options for that matter), some less secure than others. It also shouldn't have any complex negotiating before auth. Receive a fixed size magic + auth key, validate with small formally verified crypto, if doesn't match then drop connection without any IO or other side effect.
But instead we have protocols where the security boundary represents thousands of pages of specifications, parsing of complex structures in elevated context, network requests on behalf of untrusted users, logging without input escaping, and a dozen "unused" extensions added by some company in 1990s to be backwards compatible with their 5 bit EBDIC machines.
> But if the code is both simple and there is no issue with it, then you can rest assured that there exist no hackers on the face of the earth who can exploit it
It's difficult to get there but it's often achievable and worthwhile. When a company is worth billions, what's the cost of aiming to reach perfection? What's the cost of not trying?
The cost is you lose to your competitor who offers features (complexity) instead of security and now all your effort is for naught.
People talk a lot about security but nobody actually values it. You just send out some Uber Eats coupons or free Credit Protection vouchers and keep on doing what you were doing and in a month everyone has forgotten.
I'd argue more aptly: what's the cost when this "perfect" solution inevitably fails? If it was easy (or even _possible_) to make perfect computers, I assure you we already would.
Nevermind a large org, I'd be surprised if you can achieve that perfection in tiny software written in the safest languages reviewed by experienced engineers.
Yeah, even if you review your own code and it happens to be perfect, you probably have quite a bit of dependencies that you definitely don't have time to review.
It's basically an admission that the software may be full of vulnerabilities and the only way to protect it is to limit its exposure to the outside world.
The root of the problem is that almost all software is poorly designed and full of unnecessary complexity which leaves room for exploitation. Companies don't have a good model for quality software and don't aim for it as a goal. They just pile on layer upon layer of complexity.
Quality software tends to be minimalistic. The code should be so easy to read that an average hacker could hack it in under an hour if there was an issue with it... But if the code is both simple and there is no vulnerability within it, then you can rest assured that there exist no hackers on the face of the earth who can exploit it in unexpected ways.
The attack surface should be crystal clear.
You don't want to play a game of cat and mouse with hackers because it's only a matter of time before you come across a hacker who can surpass your expectations. Also, it's orders of magnitude more work to create complex secure software than it is to create simple secure software.
The mindset to adopt is that bad code deserves to be hacked. Difficulty involved in pulling off the hack is not a factor. It's a matter of time before hackers can disentangle the complexity.