Big deal. So, we had another massive data breach involving potentially millions of exposed records, and what do we do? There are many news stories (most of the non-technical) about the breach, discussing how devastating it is. Someone got arrested. But, nothing happens in the grand scheme of things.

I would argue that a lot could happen from this breach, depending on whether MSPs use the opportunity wisely. Here are a few of the key conclusions I took from this hack.

How Not To Handle Data Breach Notifications

It was awkward to see Capital One’s response to the breach. Everyone knew it happened. And yet, the company insisted on fancy word crafting designed to fool the ignorant and infuriate those with even modest intelligence. The following is from the company’s press statement:

“No bank account numbers or Social Security numbers were compromised, other than:

About 140,000 Social Security numbers of our credit card customers

• About 80,000 linked bank account numbers of our secured credit card customers
• For our Canadian credit card customers, approximately 1 million Social Insurance Numbers were compromised in this incident.”

I had to read this statement several times before I could rule out that I was living in some alternate reality. “No social security numbers were compromised….other than about 140,000 social security numbers…” This is probably not the way you want to issue a data breach notification.

The statement does provide some more specific (although still vague) details about how the incident occurred. Capital One said, “a highly sophisticated individual was able to exploit a specific configuration vulnerability in our (emphasis added by me) infrastructure.”

It is not clear whether Paige Thompson, the former Amazon Web Services employee, actually leveraged her experience with AWS to exploit Capital One. Capital One uses AWS for its infrastructure.

Public Cloud Takes Another Hit

Although AWS denies responsibility for the Capital One breach, the incident draws unnecessary attention to the public cloud. Public cloud has, for the past several years, been receiving many attacks and critiques, some frivolous, but many which are warranted.

In a statement, Amazon said the following: “AWS was not compromised in any way and functioned as designed. The perpetrator gained access through a misconfiguration of the web application and not the underlying cloud-based infrastructure. As Capital One explained clearly in its disclosure, this type of vulnerability is not specific to the cloud.”

This incident is still a great example of how leveraging external service providers (like AWS) does not absolve you of the responsibility of locking down your customer data.

Threats Come From Everywhere

In this particular case, it wasn’t an insider job, but it was a former employee who had access (or knowledge) of sensitive data. There will be plenty of time to discuss blame later. One business conclusion to take from this breach is the importance of knowing who has access to your data and how those people could cause damage to it.

If the only conclusion is to fix a configuration setting, I believe this would be a wasted opportunity. There will always be vulnerabilities in any system. Security is not about making a network or system impenetrable; this will never happen.

MSPs should use this breach to talk to their customers about the importance of knowing their data, assessing what is most important, and developing plans to secure it.

Until then, we’ll wait for the next significant data breach, which will inevitably happen.