Lessons learned from Capital One data breach

Cyber Security Expert, CISSP

July 30th, 2019

As the result of this breach, over 100 million credit card applicants at risk in Capital One breach.

Let’s review three facts we are aware of:

Fact#1: The attacker, Thompson, a 33-year-old software engineer’s last listed role was with Amazon’s Simple Storage Services (S3) as a Level 4 systems engineer, a role that ended in September 2016. This could have been enabled her of becoming aware of an existing vulnerability to allegedly access information from Capital One bank through a “miss-configured” security feature on a server rented by Capital One hosted by Amazon!

More specifically, a “firewall misconfiguration permitted commands to reach and be executed” by Capital One’s cloud-based storage servers. This means that the intruder was able to breach the security measures put in place by Capital One and request the data stored on the servers without needing the proper “authorization”.

What can we learn from above fact?

Regular Firewall Rules review is one of the fundamental security requirements that is articulated in security standards and best practices and is required by different compliance requirements. Sounds like this fundamental security practice was not followed properly otherwise this gap could have been identified log back.
Authorization is as important as identification and authentication. In this case the authorization was not configured properly.
Either there was not a configuration checklist in place or otherwise the checklist did not include proper firewall configuration or perhaps the firewall setting was changed at a point in time without being properly reviewed through a change management system.
When it come to using cloud infrastructure, a comprehensive checklist must be followed that covers all applicable preventive and monitoring controls.
There must be a configuration standard in place. Any further changes that does not align with configuration standard must be thoroughly reviewed based on a change management process.
Fact#2: Capital One only became aware of the breach on July 19, when someone emailed the company to say Thompson had posted information about the hacked data on GitHub, which software developers use to share code. Meaning neither Capital One nor Amazon spotted the breach but someone outside the company.

What can we learn from above fact?

Not knowing what is happening underneath the application and network layers means low visibility. There are number of detective controls that can monitor data flow and determine who accessed what and when. I gather their visibility on their cloud base services was low. The outgoing traffic was not being monitored properly otherwise this anomaly could have been identified at the first place.

Fact#3: She used several methods to mask her identity and location, including a virtual private network service and the anonymous TOR browser.

What can we learn from above fact?

Systems hosting sensitive information must be very strict in their access controls. The fact that she was able to circumvent access control mechanisms based on anonymity means the access controls were weak and the fact that she was able to establish a VPN tunnel means perhaps she had elevated privilege.

Also, it means that existing monitoring and detective controls were blind to spot and report her access and her abnormal behaviour. There are variety of detective solutions that can monitor the traffic and identify anomalies. Such solutions must be configured properly to perform effectively. When it comes to utilizing cloud infrastructure (PaaS, IaaS, AaaS, etc.) strong access control mechanism, traffic monitoring controls and anomaly detection controls must be deployed to maximize the visibility as to what happens underneath the application and network layers.

While that service is used by Capital One, there is no evidence that Amazon’s cloud system was involved in the breach.

“AWS was not compromised in any way and functioned as designed,” a company spokesperson said Tuesday. “The perpetrator gained access through a misconfiguration of the web application and not the underlying cloud-based infrastructure. As Capital One explained clearly in its disclosure, this type of vulnerability is not specific to the cloud.”

About 140,000 Social Security numbers and 80,000 bank account numbers were potentially put at risk, according to a statement from the bank.

Contact me if you have any questions or need assistance to increase the security resilience of your IT and Cloud infrastructure.

Lessons learned from Capital One data breach

You May Also Like

Leave a Reply