- PATCHING OF KNOWN CRITICAL SECURITY VULNERABILITIES IMMEDIATELY.
Immediately? No real company can do this. 1-2 weeks after the announcement is the best you'll see, even with something of the magnitude and publicity of Heartbleed. I'm not saying that's how it should be but that's how it is. Most organisation's it's quarterly!
All of these can be designed into a system and still maintain 100% uptime
Sure. If you were designing from a clean slate right now. The vast majority of organisations in the world aren't.
And believe me: in 10 or 20 years your new design would have revealed flaws too, and look laughably primitive to the practitioners of the day.
What's the solution then? An architecture in which no single compromise can compromise the entire system. That's getting harder and harder to do as the landscape homogenises around Lintel.
Impressive. Let me amend my original statement from "no" to "a tiny minority" then but I believe my point stands - frantic patching to keep up is no substitute for an architecture with no single point of vulnerability.
If you're on an computer there is always going to be a single point of failure with a window of venerability. Any piece of software or combination thereof will possibly leave a RCOE veunerability, which means you always have a single point of veunerability. I think what you mean is, is the unauthorized access isolated enough such that by the time an attacker finds the next thing to attack you've noticed the odd network behavior, eg defense in depth? If so, yes. But theres a difference between frantic patches and a well controlled, tested and easy to deploy set of software which makes pushing updates much less "frantic" and much more controlled. No matter what your defense in depth is you're always going to get an "oh fuck we are totally uncovered" moment, this is where the agility helps out. Your other option in this case is "the emergency shut-down for the oasis", well or the equifax option of sticking your head in the sand and running the servers open for months. I assume we're all responsible adults here though so that last one is off the table, it all comes down to risk assesment. ef seems to have miscalculated on that one.
We need to differentiate then between "patch for this one specific thing" and "upgrade to the next version" which are often conflated. The former could literally be a one-line change to correct an off-by-one error say. The latter will have to go through the full regression and release process. Often it's a grey area.
Companies like Red Hat, Suse and Ubuntu provide security backporting for exactly this reason. It's one of the major reasons that folk subscribe to them.
Unless you are part of that "tiny minority", you have no business handling information that can substantially negatively impact people's lives.
Isn't it interesting that one needs a license to drive an automobile and yet companies that handle this type of information get to do so without demonstrating the required level of competence.
Isn't it interesting that one needs a license to drive an automobile and yet companies that handle this type of information get to do so without demonstrating the required level of competence
Oh, it's the whole industry tho'. VMS running on DEC hardware was at a level of security and reliability that we can only dream of today, but it was abandoned on the scrapheap and replaced by glorified PCs running a hobbyist OS. If you wanted to build an infrastructure on old-skool principles now you couldn't, you can't get the components anymore. The truth is we're fighting a losing battle and the real enemy is ourselves.
They can, but it requires automation. I've worked on and used tooling for just such things. We can see an upstream CVE and have it patched in production inside 48hrs. Usually the same day.
Disclosure: I work for Pivotal. All this stuff (Cloud Foundry, BOSH etc) is opensource, but we sell commercial versions too.
> No real company can do this. 1-2 weeks after the announcement is the best you'll see
You don't need to patch your software right away, but you should have other strategies for mitigation such as a WAP in front of your services that you can configure to block malicious traffic when you identify a remote code execution vulnerability.
Immediately? No real company can do this. 1-2 weeks after the announcement is the best you'll see, even with something of the magnitude and publicity of Heartbleed. I'm not saying that's how it should be but that's how it is. Most organisation's it's quarterly!
All of these can be designed into a system and still maintain 100% uptime
Sure. If you were designing from a clean slate right now. The vast majority of organisations in the world aren't.
And believe me: in 10 or 20 years your new design would have revealed flaws too, and look laughably primitive to the practitioners of the day.
What's the solution then? An architecture in which no single compromise can compromise the entire system. That's getting harder and harder to do as the landscape homogenises around Lintel.