Yet another service discovered which was built/deployed with no regard for security whatsoever. I'm beginning to realize - this is the norm. Security is the least important thing for most of the IT companies.
I guess the DevOps trend (i.e. not hiring sysadmins) should take it's share of blame. Or maybe it's the other way around - you don't care for security, so there is no point in hiring security experts?
If team principals are mostly young and don't have exposure to very specific kind of experiences dealing with threat modelling, then the security work will always take a backseat to feature-building. It's how humans work - it's hard to cut time from nice visible things and dedicate it to a hypothetical (at that point) abstract goal like security. Everyone agrees that the latter is important, but it just never ends up getting any oxygen. What's worse, if the team does not know what tightening systems feels like, they don't even know where to start. No "muscle memory" for it.
Maybe at some point we'll get more baseline collective wisdom about it throughout the industry, but it will also take the people signing the cheques (CEO, investors) having a bit more (justified) paranoia and respect for these priorities, and consequently requiring them from the outset. And DevOps has little to do with it - security has to be established as a priority from the leadership levels on down anyway because it necessarily means reducing time spent on more immediately-visible things.
We are not talking about some complex interactions between multiple components which lead to a security vulnerability. This is some trivial stuff like "don't give your passwords to anybody" or "don't run everything as root".
The most complex vulnerability mentioned in the article is with proxying. If you have opened /etc/squid/squid.conf at least once you should have noticed the to_localhost ACL and the comments which explain why it is important. So is the Pocket team building a multi-million user service which has a proxying component without trying to configure squid once? Absolutely!
Also I consider too optimistic hoping for the situation to improve - it's moving in the opposite direction for now with steady speed.
It's not the DevOps philosophy that's to blame. That philosophy is primarily about the utilization of automation to drive deployments. This is a great way to get better security, but you still have to prioritize security when you're writing your automation. The problem is that investors, managers, and developers all prioritize features. People are graded and rated on bullet points not on attack surface.
> It's not the DevOps philosophy that's to blame. That philosophy is primarily about the utilization of automation to drive deployments.
In theory it is. In practise it sometimes seems to be seized on by people who are sick of listening to those fuddy-duddy infrastructure types bang on about security and firewalls and ug, so boring bro. Crush code!
I guess the DevOps trend (i.e. not hiring sysadmins) should take it's share of blame. Or maybe it's the other way around - you don't care for security, so there is no point in hiring security experts?