It's curious looking at the fall out over the Equifax hack. I've been biting my tongue, not wanting to add to the hyperbole, but the temptation has become too great. I'm going to have to throw in my 2 cents.
There is some disagreement to whether it was a simple as an admin/admin login and password or if their servers where not patched, but what's really interesting in looking at the demands for more explanations and various CISOs giving their opinions on linkedin and blog posts about the hack, everyone is talking about patch management and password management. There are various discussions and excuses given to why this is hard and how people sign off knowingly on not upgrading.
Now, I have strong opinions around these areas too and if you're running a server which is holding the crown jewels and something which will have a direct and significant impact on your customers' lives, each of the decisions on which exceptions will get signed off on have to be made at the upmost echelons of the company.
This isn't the internal knowledge base you're talking about, this is the information which your very company is built upon.
If your company deals in analytics and information, which Equifax does, then one of your absolute highest concerns is security. It simply has to be. People are trusting you and the things which are coming out of Equifax show that in no way did that company deserve that trust.
But I feel like focusing on patching and password management also misses a far deeper and more troubling issue, an issue which often gets overlooked for these more superficial problems.
That issue really is design. The state of security today means that any CISO must understand that their network will be compromised. I'm sorry guys to have to tell you that even as you read this, most likely, there is a compromised server, desktop, laptop, phone sitting within your infrastructure or with access to some server within your infrastructure. So, given that premise, how on earth did any server, desktop or laptop have access to over 100 Million records?
Any system which is designed to allow for access to that many records from a single source (or cluster of same type of sources) should never have been allowed out of the design stage. Security doesn't stop or start at patch management and pen testing.
Systems have to be designed with the idea that at some point they can be compromised. This means limiting trust, making sure there are barriers at different stages, that when looking at data segmentation you're looking at it from a security model view.
As more people are moving to a micro service architecture and going to a containerized deployment processes, there has to be a concerted effort to make sure a security model is set out with clear definitions of perimeters and trust. With each step of the design there should be an idea of where this service sits within the security model and what the consequences of that service being compromised will have.
Thinking in terms of services and compromise arms you with an understanding of what level of security you should have around those services. With services running on docker and immutable instances within cloud means that there is very little excuse not to start looking long and hard about how you're segregating your data and limiting the scope of what can be accessed from a particular instance.
You're probably thinking that's all well and good when you're talking about a new architecture but obviously Equifax are running a stack which predates this type of flexibility. But really that isn't a good enough excuse. Hackers being able to access that many records in one go shows that there is a fundamental problem at Equifax and that problem extends to the bowels of the deployment and software architecture.
All the best password and patch management in the world will be a band-aide over the fundamental problems which need to be addressed. I am sure that Equifax will take a long hard look at this in the future, and it's probably a good time for all of us to do the same.
No comments:
Post a Comment