Let’s be honest. When most financial executives read the headline “Capital One Data Breach,” they had two thoughts:
It’s not that executives are unsympathetic. They know the aftermath of a data breach is like experiencing every circle of Dante’s hell. But, bank and credit union executives can’t assume it will never happen to their institution. They have to learn from other’s mistakes.
Paige Thompson, the woman who is alleged to have performed the hack, used a web vulnerability known as Server-Side Request Forgery. SSRF means the hacker was able to forge credentials to gain access to restricted parts of a network. In this case, information about Capital One’s customers.
Remember access control systems? The company issued employees an access card that determined where they could go within company buildings. If employees tried to access a restricted area, they were denied access. The same concept applies to SSRF. When the authentication process works correctly, a request for information from an unauthorized source will be blocked. But, just as people can forge an access card, hackers can fake credentials to access restricted data.
Capital One uses Amazon Web Services to house data and applications rather than purchase and maintain its own cluster of servers. Thompson used the known SSRF vulnerability to trick AWS into giving her access to restricted data, but it was Capital One’s misconfigured firewall that let her request through. So who is responsible for the breach? Aren’t both AWS and Capital One both responsible? Technically, that is true, but legally, only Capital One is responsible.
Although SSRF is a known vulnerability that AWS could address, Amazon relies on properly configured networks to block an attack. AWS publishes extensive documentation and guidelines outlining how its cloud customers must secure their data. As a result, AWS shifts the responsibility to the customer. In the case of Capital One, it mismanaged its firewall, comprising its bank security.
For financial institutions, it calls into question the security of cloud computing. Capital One is the first large institution to embrace cloud computing; others have been more reluctant. This breach does nothing to build confidence in cloud computing within the financial sector despite AWS’s claim that its infrastructure was not at fault.
What the breach does point out is the risk financial institutions take when storing data and applications at third-party locations. Now is an excellent time to review the institution’s security by:
No one can guarantee a financial institution is 100% safe, but being proactive is one way to continue to say, “Thank goodness it wasn’t my institution!”
One thought on “Lessons from the Capital One Data Breach”
The thing about this that amazed me is that I received a credit card solicitation in the mail from them about two weeks after it hit the news. Did they really think I would sign up for that?