2014 is so far looking as though it might turn out to be the year of authentication. It seems that every story I read or watch on the television news that relates to computer security has something to do with authentication. Many – or maybe most – feature some form of authentication error or issue as the center of the story.
Those of you that have followed this blog for any length of time know that I often discuss authentication issues. That’s not just because it interests me, but it is because it is such a fundamental part of cybersecurity. If an attacker can fool a system to believe that he or she is someone authorized to something, then the attacker can do that thing even if he or she shouldn’t.
Take the Target breach we’ve heard so much about recently. It seems the attacker(s) somehow managed to get credentials for the company’s system from a contractor. There are at least two major issues here, one relating to authentication and one other one. Before I make any specific comments, though, I want to make it clear that I’m not investigating this, I don’t have any inside knowledge and I’m not trying to assign any type of blame or make any accusations. Instead, I want to look at what’s been reported and point out some issues from which we all can learn.
First, it seems the contractor needed the target credentials to perform some necessary work. I get that. But there are at least three issues at work here: 1) the credentials were possibly good past the time the work was being done. What should have been done instead (if it was possible, and frankly I don’t have enough concrete details to know, so, in fairness, it might have been done) was to limit the duration of the logins and passwords to the times the contractor actually needed them. 2) it appears the credentials allowed access beyond what the contractors actually needed. To be fair, this is a common issue: someone needs to perform task X and is given wider credentials to make their life, and the life of the admin, easier. I get it. I’ve done it. Maybe there were no accounts with just the permissions the contractor needed. Maybe it was difficult to set up such an account. At any rate, doing so might have helped prevent the attack. And 3) somehow the attackers got the creds from the contractor.
The second issue was data partitioning. The Wall Street Journal is reporting that an HVAC contractor had access to computers at the company and needed the credentials. Fine. There are lots of potential reasons for that. But I can’t figure out why the contractor also needed access to the system that controls the point-of-sale terminals. In other words the creds the contractor apparently had were far too broad for the task as I noted above. But there is more. There does not appear to be sufficient partitioning between the payment system and the environmental control system. Maybe there was and maybe it hasn’t been reported. The issue, though, is an important one: different systems need different sets of credentials or different permissions or maybe need to be separated completely. Why should the web surfing Wi-Fi access on an airplane be connected to the computers that fly the plane? They’re not, of course, and they shouldn’t be.
We discuss these kinds of issues (and, in fact, all of the issues here) in Learning Tree Course 468. This breach should be a learning moment for all of us. The fundamentals still hold. We need to do extra work sometimes to help ensure security. I feel sorry for the victims here: Target, the contractor, and the cardholders. We can all learn from this. Let us know in the comments below what you’ve learned from this.