Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


11:30 AM
Connect Directly

Capital One: What We Should Learn This Time

Where Capital One went wrong, what the bank did right, and more key takeaways from the latest mega-breach.

When a major data breach occurs, security and business leaders running companies large and small are quick to ask the same familiar question: "How can we prevent this from happening to us?"

Their question remains the same as organizations continue to shore up their defenses and cybercriminals continue to find their way in. Top of mind now is the Capital One breach, disclosed this week, which compromised personal data belonging to 100 million Americans and 6 million Canadians.

Most affected data came from credit card applications: names, addresses, ZIP and postal codes, phone numbers, email addresses, birth dates, self-reported income. Still, 140,000 Social Security numbers and 80,000 linked bank accounts of secured credit card customers were accessed by the attacker, as were about 1 million Social Insurance numbers of Canadian users.

New details about the breach have emerged since it was first reported. We now know Paige Thompson, the suspect in FBI custody, accessed this information through a misconfiguration error in a web application firewall (WAF), which let privileged commands be executed using Capital One credentials that had sufficient privileges to access the bank's data. Thompson is a former employee of Amazon Web Services (AWS), where Capital One stored its information.

Capital One may not have been the only company Thompson breached. The attacker, known under the alias "erratic," maintained a Slack channel where she shared details of her personal life and online activity. In late June, she posted a comment listing several corporate databases she located by breaking into poorly secured Amazon cloud servers. So far, no other businesses have confirmed they were breached.

As the investigations continue and more updates surface, businesses can (and should) consider what Capital One got wrong, what it got right, and how they can learn from this incident:

This Should Have Been Spotted
A number of red flags could have alerted Capital One to this activity long before the company was informed of it in July, says Avivah Litan, distinguished research vice president at Gartner.

"It's the same old story," she explains. "All this activity is being logged but no one is paying attention to logs or alerts indicating the attack is in progress." A misconfigured WAF is an application error, not a cloud error, Litan adds. It could have happened anywhere. But Capital One, which has marketed itself as a tech-savvy business, should have noticed. The financial giant was among the first to embrace the cloud and move its data over to AWS five years ago.

"There are few companies that have spent as much time and money as they have," she says.

Part of the problem is there's simply too much data. Litan advises adopting user and entity behavioral analytics to scan data for anomalies. Many companies use this to determine a baseline for normal activity and seek anomalies that go beyond it. "These systems are way too complicated for humans to decipher," she notes. "There's just too much going on." Capital One uses behavioral analytics on certain systems, she says, but it wasn't used on these logs.

It's also worth noting that cloud security experts have long known about the type of vulnerability exploited in the Capital One breach, says Chris Wysopal, CTO of Veracode. Server-side request forgery is when an attacker can control the requests that a server makes; these requests often have higher privileges and provide greater access to sensitive data, he explains.

"In the Capital One case, it seems a vendor-provided WAF, which was acting as a server, allowed an attacker to manipulate server-side requests and leverage its privileges to get at sensitive data," Wysopal says, who adds that other firms may have had data accessed through the same vulnerability. He anticipates we'll see similar attacks continue in the future.

Responsible Disclosure Cut Response Time
In a nod to Capital One, it only took two days to investigate and confirm a breach after it was alerted to the attack. Thompson was not shy about sharing details of the breach on GitHub and social media platforms. A white-hat hacker noticed her posts and informed Capital One of a potential intrusion via its Responsible Disclosure Program on July 17, 2019. Officials launched an investigation, which led to discovery of the breach on July 19 and announcement on July 29. Thompson had breached the company few months earlier, between March 22 and 23 of this year.

"It usually takes companies far longer to identify that a breach has occurred, and white-hat hackers played a kay role in reducing the window of exposure," says Casey Ellis, CTO of Bugcrowd. When a white-hat hacker discovers a bug, he continues, it's important for organizations to clarify a process that lets the researcher safely report a problem.

Because it had a working responsible disclosure process, Capital One was able to investigate and fix the vulnerability before more damage was done. The bank says it's unlikely any of the compromised data was used for fraud or disseminated by Thompson.

Tips for Staying Proactive
Given Thompson's openness on GitHub, Slack, and other platforms, it's worth asking why Capital One didn't notice its data shared before a security researcher did. "One of the issues with security is it's really reactive, and not preemptive," says Litan. If Capital One had noticed this earlier, it could have reduced the time between the breach and its discovery.

"The information universe is incredibly fast and broad," says Jim Zuffoletti, CEO of SafeGuard Cyber. "One of the things that keeps showing up again and again is where are people doing things — GitHub, Slack, etc." Being proactive on social media can help financial services firms, and other potential victims, find emerging threats to act on. Zuffoletti advises companies to think about social media both as a vector for threat hunting and part of their attack surface.

In terms of protecting information before someone gets to it, Elissa Shevinsky, CEO of Faster Than Light, encourages the "defense in depth" approach in which organizations place several layers between sensitive data and the surface where an attacker could break in. Businesses should also conduct penetration tests at least once a year, she adds.

Also important here is companies' responsibility for their own configurations and working with cloud providers, adds Litan, citing the shared responsibility model. "Capital One knows its role, it knows AWS's role, but it's important for people to know this is a shared responsibility," she says. One thing company can do is put a "default deny" posture in all applications. This denies all access unless it's explicitly granted, which prevents data access in all but legitimate cases.

"There is another important lesson here, which is that a data breach can happen to anyone," says Shevinsky. "We don't want to think about it, but it's worthwhile to have an emergency response plan ready just in case."

Related Content:


Black Hat USA returns to Las Vegas with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Ninja
8/6/2019 | 11:30:34 AM
Re: A key concept: THIS TIME

At the end of the day it comes down to the following:

  • Setup a risk management framework that just makes sense
  • Provide continuous monitoring and training
  • Put personnel in situations where they are working with senior cybersecurity analysts (mentor)
  • Schedule weekend simulation attacks where the groups are teamed together to address these problems, make different people leads (you really learn when the analyst is put in the line of fire)
  • Put on a large monitor the areas they need to improve (accountability)
  • Document those shortcomings and successes so the team can see where individually and as a group where they need to improve (access)

There is not enough focus on the impending situation, it is going to take a major financial hit for staff and executive members to see the importance of their shortcomings.


User Rank: Ninja
8/2/2019 | 2:53:06 PM
A key concept: THIS TIME
When will WE learn?  If not Equifax, then Atlanta - or cities in Florida - or Hydro-Norsk - or Capital One.  WHEN will the basic lessons of disaster recovery and continuity planning BE learned?  How many lessons does it take for the C-Suite and IT staff to LEARN how to monitor and do things right?   Without this basic function, all other tasks will fail.  Hey - all IT staffers should have GitHub accounts - riught???
For Cybersecurity to Be Proactive, Terrains Must Be Mapped
Craig Harber, Chief Technology Officer at Fidelis Cybersecurity,  10/8/2019
A Realistic Threat Model for the Masses
Lysa Myers, Security Researcher, ESET,  10/9/2019
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
2019 Online Malware and Threats
2019 Online Malware and Threats
As cyberattacks become more frequent and more sophisticated, enterprise security teams are under unprecedented pressure to respond. Is your organization ready?
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-10-15
safer-eval before 1.3.4 are vulnerable to Arbitrary Code Execution. A payload using constructor properties can escape the sandbox and execute arbitrary code.
PUBLISHED: 2019-10-15
safer-eval before 1.3.2 are vulnerable to Arbitrary Code Execution. A payload using constructor properties can escape the sandbox and execute arbitrary code.
PUBLISHED: 2019-10-15
In the DoorDash application through 11.5.2 for Android, the username and password are stored in the log during authentication, and may be available to attackers via logcat.
PUBLISHED: 2019-10-15
Glue Smart Lock 2.7.8 devices do not properly block guest access in certain situations where the network connection is unavailable.
PUBLISHED: 2019-10-15
Connect2id Nimbus JOSE+JWT before v7.9 can throw various uncaught exceptions while parsing a JWT, which could result in an application crash (potential information disclosure) or a potential authentication bypass.