Securing Your Cloud – Part 2

In my previous blog post, I discussed the importance of using the shared responsibilities model and mapping out, between you and the cloud vendor, who owns which parts of the security of your data. This post will continue that conversation and provide guidance on standardizing your cloud security tools.

Necessary Security Resources

There are three security areas an organization needs to standardize on. I’m talking about tools you would use across all the cloud platforms the business units are currently using and could potentially bring into the fold. These include an identity management platform, a cloud access security broker and an encryption platform. Of course, there are other areas of cloud security, but they start to get more specific to each platform.

For example, if you are going to be doing an Infrastructure as a Service (IaaS) platform, such as Azure, Amazon Web Services (AWS), Oracle Cloud or Google Cloud, you are going to also want to look at firewalls, an intrusion prevention system (IPS), system anti-malware, a vulnerability management solution and so on. But the initial three items I mentioned above will be used for those environments as well as for Software as a Service (SaaS) platforms — including Salesforce, Box, Office 365 and G Suite — where you wouldn’t place a firewall.

When you choose a vendor for one of those initial three areas you need to standardize on, you need to look at platforms that are flexible in their use. Too many times, customers will go the inexpensive route to meet their needs now; later, they find themselves stuck with a solution that doesn’t work or that takes a lot of customization to support a new cloud platform that a business unit wants to bring in after the fact. I have seen integrations take as long as nine months to get the arrangement working securely; I have heard of it taking two years.

Choosing the Right Vendor

Another common mistake is when organizations use something they are unfamiliar with that is not in their current data center to cut down on costs. For example, if you are using vendor XYZ as your corporate and branch firewall, chances are good that they have a version of the firewall that can be used in an IaaS environment.

In the same vein, don’t assume a particular vendor is the best choice because some vendors have limitations in an IaaS environment, such as how many ports/segments they support and what services they can provide. Using the cloud-provided firewall (as in this example) is usually a mistake that will bite you later. That’s because you won’t have the same fully featured firewall as you are using in your corporate HQ and you will have inconsistent policies and reporting between environments, which weakens your overall security posture. Your security is only as strong as your weakest point.

In conclusion, for all aspects of your security (cloud too), you need to think in these terms: If I just discovered I have been breached, how quickly and easily can I gather actionable information to know who, when, where, what and how, not just from an IT technical standpoint but also from a business and breach notification/compliance standpoint.

This goes back to how I started this blog post, in that you need to, as an IT security entity, accept the cloud so you can manage your risk and have visibility into your risks and simplify risk mitigation. There can be nothing worse than finding out some critical data was lost in a platform that you didn’t know existed or was being utilized by your organization. Imagine starting with that kind of alert call and trying to figure out who, when, where, what and how? Not a fun day.

You may even want to think in terms of your own personally identifiable information (PII) being in that cloud platform — make it personal for your organization too, and you will get a better understanding of what is at stake.

Learn more about CDW’s cloud solutions and services.

This blog post brought to you by: