The fourth prediction in the report predicts that we will see one major data breach incident each month in 2014. That’s big enough that it bears repeating.
We will see one major data breach incident a month.
Big Data, Big Breach
2013 altered our sense of scale when it came to the amount of data exposed with each breach. We were shocked when, in previous years, breaches of several million records came to light. In 2013, there were at least three separate breaches that exposed 50 million records.
In 2014, we could easily see 500 billion data records exposed. The stakes have never been higher.
Working With Your Cloud Provider
Of course breaches of this size are only possible because services are scaling up to the point where it’s not uncommon for a small service to host a massive amount of data. To scale these sizes economically, most services are leveraging the cloud and that brings new challenges when it comes to responding to security incidents.
While you’ve no doubt designed your service to reduce the possibility of any data breaches, it’s absolutely crucial that you have a strong incident response plan in place, in order to quickly and effective investigate any possibility of a breach.
If your service is in the cloud this means that your incident response plan is going to include your cloud service provider. This collaboration will impact each stage of your response plan–from prepare, to detect, contain, eradicate, recover, and finally learn.
By the very nature of the offering, security in the cloud is shared between the client (that’s you) and the service provider. The type of service (SaaS, PaaS, or IaaS) will dictate the amount of responsibilities that you take on versus your provider.
In an IaaS deployment, the line is usually drawn at the operating system. Everything up to the operating system (physical infrastructure, networking, virtualization layer) is the service provider’s responsibility to secure. The operating system and application you deploy on that stack are your responsibility to secure.
AWS does an especially good job of laying out the division of responsibilities. Their Shared Responsibility Model is simple and straight forward.
AWS is responsible for the:
- physical security
- physical infrastructure
- network infrastructure
- virtualization infrastructure
You are responsible for:
- operating system
- account management
- security groups
- network configuration
Of course you can’t share effectively if you don’t have agreement on the division of responsibilities and excellent communications…which brings us to the second point.
A lot of your interaction with your cloud provider is probably through their API or website. During a security incident that just won’t cut it.
You’re going to have to know not only who but how you contact the security team for your provider. Just as important, you’re going to have to have a process in place for how you respond when your provider contacts you with an issue.
More than just establishing a method of communication for security incidents; take the time to develop a relationship with your provider’s security team. When there are defined responsibilities, it’s easy to start the blame game…especially when your back is against the wall.
Having a strong relationship between the security teams on both sides can go a long way to prevent that from happening.
Predicting more breaches in 2014 isn’t exactly a risky call. The important take away here is that the stakes have increased. Breaches are getting bigger and bigger, which means the potential damage to your reputation, liabilities, and financial loses are getting bigger too.
Working with a cloud service provider on an incident is not something you want to figure out in the heat of the moment. Take a little time and lay the groundwork now. With a little preparation you can put yourself in the best possible position so you don’t end up a statistic in next year’s predictions.