The Technical Side of the Capital One AWS Security Breach

The Technical Side of the Capital One AWS Security Breach

  • August 3, 2019
Table of Contents

The Technical Side of the Capital One AWS Security Breach

On July 19th, 2019 Capital One got the red flag that every modern company hopes to avoid – their data had been breached. Over 106 million people affected.

140,000 Social Security numbers. 80,000 bank account numbers. 1,000,000 Social Insurance Numbers.

Pretty messy right? Unfortunately, the 19th wasn’t when the breach occurred.

It turns out that Paige Thompson, aka Erratic, had done the deed between March 22nd and March 23rd 2019.

So almost 4 months earlier. In fact, it took an external tip for Capital One to realize something had happened.

So almost 4 months earlier. Though the former Amazon employee has been arrested and is facing $250k in fines and 5 years in prison…it’s left a lot of residual negativity. Why?

Because of many of the companies who’ve suffered data breaches try to brush off the responsibility of hardening their infrastructures and applications to the increased cyber crime.

Source: jcolemorrison.com

Share :
comments powered by Disqus

Related Posts

Architecting for PCI DSS Segmentation and Scoping on AWS

Architecting for PCI DSS Segmentation and Scoping on AWS

AWS has published a whitepaper, Architecting for PCI DSS Scoping and Segmentation on AWS, to provide guidance on how to properly define the scope of your Payment Card Industry (PCI) Data Security Standard (DSS) workloads running on the AWS Cloud. The whitepaper looks at how to define segmentation boundaries between your in-scope and out-of-scope resources using cloud native AWS services. The whitepaper is intended for engineers and solution builders, but it also serves as a guide for Qualified Security Assessors (QSAs) and internal security assessors (ISAs) to better understand the different segmentation controls available within AWS products and services, along with associated scoping considerations.

Read More