Blog / Capital One Data Breach: A Look at the Information thus far.
A little while ago I started seeing articles about a large breach of Capital One‘s network. Just in case you aren’t aware of them, they are a major Credit Card provider, right up there with Visa and MasterCard.
The breach is being hailed as one of the third largest in the financial sector (so far.) An estimated 100 million Americans and 6 million Canadians have been impacted.
When I first started seeing articles about this breach, I decided not to send out a newsletter, but to keep an eye on the situation instead. This is because I don’t want to become a Breach Watchdog (hey, did you hear about the breach at XYZ?) At the end of the day, I do talk about breaches often, but the reason is to investigate the situation and learn from it (EQUIFAX being a rare exception.)
Before I go any further, I recommend that anyone with a Capital One card go to the ‘Capital One Canada’ website and look up the information they’ve published:
It’s worth mentioning that they learned from the EQUIFAX situation and DID NOT set-up a totally separate being taken to communicate breach details.
Under the European Union’s General Data Protection Regulation (GDPR), companies must inform victims of severe data breaches “without undue delay.” They must then describe in “clear and plain language” the nature of the breach, the likely consequences and what measures are being taken to deal with it. While GDPR doesn’t impact companies outside the EU, similar regulations are starting to show-up in other countries. This means the standard for Public Breach notifications is becoming that of supplying details about how it happened and what is being done to fix it.
I’m starting to see articles that contain analysis information. This means they’re releasing details about how the breach occurred. Now then, I can turn this into a teachable moment by finding out what went wrong and providing advice on how to avoid getting caught in the same boat. I would also like to apologize, since this newsletter is going to be a bit longer than normal, thereby violating my personal rule of trying to keep things short.
How was the breach detected?
It wasn’t!
The breach began a few months ago; March 19th to be exact. The only reason it was detected is because the hacker admitted to it in an online chat group and someone from that group turned them in to Capitol One (in July.) Capital One then contacted the FBI, in order to investigate the situation and take the hacker into custody.
How did the breach happen?
The hacker managed to compromise an Administrator Account in one of the company’s Cloud Amazon storage containers. They then used that account to get a list of other containers that Capital One controlled, and then downloaded a large amount of data from another container used to store files.
It was that simple. So now I’m going to break this down and analyze things a little:
Step 1) An Administrator level account was compromised – They didn’t say how this occurred, but I’ll simplify this into 2 scenarios:
I) The hacker knew the admin password ahead of time. If this is true, then there are some serious issues. The hacker was not an employee of Capital One and never was, so if they somehow managed to obtain the password, that would mean there are some massive shortcomings with Policies & Procedures.
II) The admin password was ‘hacked’. Regardless of the method, this would almost certainly have involved many failed login attempts. Overall it seems the more likely option.
Step 2) Listing all Amazon containers that Capital One controlled – Doesn’t cause permission issues, but unusual command to execute.
Step 3) Downloading a large amount of information – Like Step 2, this wouldn’t cause any permission issue. However, just like Step 2, it would be highly unusual activity.
Now based on all of this, is it possible to come up with something that Capital One was doing wrong? Yes, they were not monitoring their Administrative level account activity enough.
So, looking at the situation, there are a couple of things that could potentially have prevented this from happening:
First: Closely monitor the logins for all your Administrator level users
This doesn’t mean just failed logins, but successful ones as well. Administrative users are not something that get used on a regular basis. The only time an admin level user should login, is to perform an activity that makes that level of permission necessary.
Having Policies & Procedures in place that support and enforce this means it will be much easier to track logins of admin level users, as well as their justification. Alerts should be generated and monitored for all failed and successful administrative user logins. This should be sent to a system that is monitored by your IT Team. Realistically, alerts of this nature should not occur often, but should be monitored in Real-Time. Logins should also be periodically reviewed, to make sure that an alert wasn’t missed.
Second: Monitor all Administrative User Activity
After you deal with the logins, you should also have a system in place that keeps track of the activity an administrative user undertook. It’s not as important to keep as close an eye on this sort of action, since (in theory) you are keeping a close eye on the login activity, but it’s still important to monitor and store this sort of movement.
Keeping a watchful eye on the login activity should (in theory) keep you protected from external threats, but that doesn’t mean a legitimate login can’t be hijacked by an attacker or misused by an employee. This means that Admin user activity should be periodically reviewed, to see if there is any sort of unusual action.
Third: Make sure that all Administrative Level users are associated with a single person
The reason for this is simple. Administrative users are powerful and should not be used very often. If the password for an account is only known by a single person or entity, it makes it a lot easier to find out if any given login event was likely the actual person in charge of the account or not.
If an account is used by multiple people trying to positively say that an action was undertaken by a single person, that becomes difficult. When it comes to external companies or contractors, then it’s reasonable for a single user to be associated with that entity. This is because once you can reasonably link an action to an external entity, the burden of proof shifts. Essentially, you’ve proved them to be guilty, so now they must take up the task of investigating further and assist with any investigations.
Fourth: Monitoring should not be limited to Active Directory users
An Administrative Level user in any system has a large amount of potential permissions that can be misused or abused. For any important system or system containing sensitive information, it’s crucial to keep tabs on Admin user activity.
However, I’m not saying that Capital One didn’t do any of these. Not being involved in the investigation, I don’t have any visibility into how their network is set-up or what policies they have. I’m just saying that considering what has been told about the situation, these are the things I can take-away from this situation, as useful advice that would have had a good chance of preventing this breach from happening in the first place.
All I can say for sure is what we already know, which is that Capital One did not detect this breach. The hacker was turned in by someone they knew. That is not how these situations normally play-out. Usually, a breach is either detected by some equipment in the network (like EQUIFAX) or the information is found on the Dark Web and the company is informed about it. It’s also possible that the attacker can try to hold the information for Ransom. This is honestly the first time I’ve heard of a hacker being apprehended in this fashion.
If you have any questions about Data Breaches, you can always reach out to your TRINUS Account Manager for some stress-free IT.
By Kind Courtesy of Your Friendly Neighbourhood Cyberman.
