Correct me if I'm wrong, but If there's no holes in the application/web stack to be exploited, then there's no getting in. Right? It's not about hacker/pirate skill. It's about whether or not the target has plugged all their holes or not.
Correct me if I'm wrong, but If there's no holes in the application/web stack to be exploited, then there's no getting in. Right? It's not about hacker/pirate skill. It's about whether or not the target has plugged all their holes or not.
All your software vendors?
How likely are you to get malware on an employee laptop?
Phish employee credentials?
Have somebody sneak into your office late at night and install keyloggers on everyone's keyboards?
Kidnap an employee's family and blackmail them into giving you access?
Go through your recruiting pipeline and join as an employee with the motive to steal your data?
Get two people to do the same and bypass peer review controls?
Of course those are getting outlandish and unlikely, but that depends how "motivated and skilled" your attacker is.
Not sure where OP was coming from. It’s virtually impossible to protect yourself against a dedicated advanced persistent threat group.
If we want to be pragmatic about the discussion, then it’s all about your threat model. In that sense, OP is right. If you’re a mom and pop shop selling a catalog of hardware, your LAMP stack isn’t going to face the same scrutiny as a “GooFacePayZon”. According to how he defines his threat model, he can call himself ‘secure’.
Are you secure if your admin's child is kidnapped and the ransom demand is for network access? Are you secure from the Secret Police wanting to hijack your service for their purposes?
Once you accept you CAN'T stop truly all attacks you can be comfortable with acceptable risk and work to mitigate realistic risks.
So unless you advocate for no secured data, you are vulnerable to a sufficiently sophisticated attack (I.e. hypnodrones hijack your mind)
Can’t remember how I did it but my former coworkers still tell stories about it. Lol.
https://gallery.technet.microsoft.com/Cloud-Red-Teaming-b837...
Similarly if a ship is unsinkable the passengers will never drown. Easier said than done.
It may be possible to write a software component that is not vulnerable to exploits, but any non-trivial system built of many components will almost certainly be exploitable.
As much as people say they value security, they also value delivery of working software.
Additionally, as others have said, no system is invulnerable from the CIA, NSA, KGB, etc. Someone knows the passwords (or where the passwords are stored) for your system. They may be vulnerable to bribery, blackmail, torture, etc.
Then there are the security holes that exist and are known about by select groups which they sit on and use for big plays...
Right. But there's a saying. "Nothing in unhackable". There in lies the problem. If you can build an unhackable system you literally can get whatever salary you want. If you can convince someone that such a thing is possible. But I'm pretty sure that'd count as fraud.
They both will never exist with the proper 'adversary'.
Does it have to be useful?
On a more serious note, similarly to being able to break RSA in ‘little’ time, having that kind of skill would not result in financial wealth but a huge risk to your physical and mental/emotional well-being. Imagine who would come knocking on your door (assuming they won’t straight out abduct you), and trying to tell them no.
You're not exactly wrong, but you're assuming something that's impossible. How do you know where all the holes are? You (I'm using the generic you here, as though speaking to a CIO) cannot even inventory all the net-connected software and hardware you own, and even if you could the list would be out of date in 24 hours. But let's say you had that fictional inventory. How do you find its vulnerabilities? You might be able to design an automated process to look at your source code and match against the CVE database. Whoops! You don't have source code for most of your resources because they're proprietary and came from outside vendors. So maybe you look at object code. There are tools that do that. Whoops! A lot of the code is in ROM and you cannot extract it. Even if you could extract all your object code and analyze it against CVEs (which you can't), that's only going to catch known vulnerabilities. What about the unknown ones?
Oh and now we have to talk about all the stuff that's not net-connected which is vulnerable to employees plugging in USB drives...
So no, you can't know where all the holes are so there's no way to patch them all. This doesn't mean security is impossible. It just means there's no such thing as perfect security and there are no magic bullets. Security is a necessary, expensive, and mostly boring part of any company's day-to-day business operations, like, say, accounting and the legal department. But that's not quite right, because most of your employees probably don't need to know much about accounting or the law. But they do need to understand the basics of safe computer use, so ongoing training should be a fat budget line item.
Anyway security is a process, not a thing you can just buy a little of from a vendor. You ignore the security process at your peril.
This is rice's theorem.
More practically, you can simply assume that for an arbitrary program of 'reasonable size' with a moving codebase there are effectively infinite exploitable vulnerabilities.
Or if they're not SuperMicro, then you'll buy hardware with a https://en.wikipedia.org/wiki/The_Thing_(listening_device) in it
The bar can be raised quite high.