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.

Cloud

8/2/2019
11:30 AM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
100%
0%

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
Comments
Newest First  |  Oldest First  |  Threaded View
tdsan
100%
0%
tdsan,
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.


Todd

REISEN1955
50%
50%
REISEN1955,
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???
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
Unreasonable Security Best Practices vs. Good Risk Management
Jack Freund, Director, Risk Science at RiskLens,  11/13/2019
6 Small-Business Password Managers
Curtis Franklin Jr., Senior Editor at Dark Reading,  11/8/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-11931
PUBLISHED: 2019-11-14
A stack-based buffer overflow could be triggered in WhatsApp by sending a specially crafted MP4 file to a WhatsApp user. The issue was present in parsing the elementary stream metadata of an MP4 file and could result in a DoS or RCE. This affects Android versions prior to 2.19.274, iOS versions prio...
CVE-2019-18980
PUBLISHED: 2019-11-14
On Signify Philips Taolight Smart Wi-Fi Wiz Connected LED Bulb 9290022656 devices, an unprotected API lets remote users control the bulb's operation. Anyone can turn the bulb on or off, or change its color or brightness remotely. There is no authentication or encryption to use the control API. The o...
CVE-2019-17391
PUBLISHED: 2019-11-14
An issue was discovered in the Espressif ESP32 mask ROM code 2016-06-08 0 through 2. Lack of anti-glitch mitigations in the first stage bootloader of the ESP32 chip allows an attacker (with physical access to the device) to read the contents of read-protected eFuses, such as flash encryption and sec...
CVE-2019-18651
PUBLISHED: 2019-11-14
A cross-site request forgery (CSRF) vulnerability in 3xLogic Infinias Access Control through 6.6.9586.0 allows remote attackers to execute malicious and unauthorized actions (e.g., delete application users) by sending a crafted HTML document to a user that the website trusts. The user needs to have ...
CVE-2019-18978
PUBLISHED: 2019-11-14
An issue was discovered in the rack-cors (aka Rack CORS Middleware) gem before 1.0.4 for Ruby. It allows ../ directory traversal to access private resources because resource matching does not ensure that pathnames are in a canonical format.