Hacker News Reader

Comment by chasb | Hacker News Reader

For teams that use a DevOps model, fast, predictable deploys that can be safely rolled back are important for security, for this reason.

If deploys are like playing Jenga on a sailboat, you're not going to be able to patch fast or safely.

That said, even becoming aware a CVE exists in the first place is still a problem for many teams. There are plenty of good options, it's just underinvested in early on.

View on HN

It isn't necessary DevOps or system admin not capable. You've vendor software not up-to-date that is beyond your control, and often users do not know until vendor sends a notification or a hack headline comes online then "oh fuck" moment.

Just to be fair too: I have seen a number of enterprises run their "legacy" infrastructure (mostly refereing to on-premise servers and old applications) doing a good job keeping up with updates such as Microsoft and whatever Linux flavor they use. But the new system/DevOps havr trouble getting through the gate, mostly IMO because we adding too many layers to the stack.

Your first paragraph, do you find any of that a valid excuse for a company like Equifax, who handle so much sensitive data? _I_ consider them responsible for the entire chain. I understand it's hard, makes no difference with those stakes.

No, not at all. My point was DevOps is not a magical group of wizards, and often DevOps team can be unproductive compared to whatever enterprise IT operation team/client service team. If DevOps is unable to carry out its core values, yes, entite chain is to be critized.

Companies like Equifax are fundamentally timebombs. The problem there isn't an IT problem.

Even if they learn of a CVE there's no guarantee a patch exists for it. You might even be stuck with no alternative but to disable whatever the attack vector is... which could be key to your business.

Back in the 90s people used to have their pager connected to CERT to make sure they knew if anything happened. Of course no one uses pagers anymore, but there are places you should definitely pay attention to if you're looking at the software.

I get SMS for CERT.

Exactly. I'd say the check of how fast can a security patch be deployed from the moment upstream OS or library releases is a good benchmark for a team/system and should be evaluated at the same level as log audits, what ports are open and what openssl versions are running.

> it's just underinvested in early on.

And for cases where there is no personal or financial data involved it is shameful and just a bad practice to not have the system which allow fast security patch deployed. For a system that holds sensitive personal information for hundreds of millions of people it should a very serious issue not to patch the system for months after vulnerability was known.

Deploying patches is easy, validating that they aren't going to break anything (sometimes in hard to detect ways) is hard.

Reply on news.ycombinator.com