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
Article source: https://www.darkreading.com/cloud/capital-one-what-we-should-learn-this-time/d/d-id/1335426?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple
