Why You Need a Multi-Layer Approach to Public Cloud Security

By Scott Montgomery, Vice President & Chief Technical Strategist, Intel Security Group

Would you hand your house keys to a total stranger and then go away on vacation for two weeks? Probably not, but that’s precisely what some businesses do when they move applications and data to the public cloud.

Security has long been the principal fear that weighs on cloud investments. While perceptions are improving, Intel Security’s recent State of Cloud Adoption study found that data breaches remain the biggest concern of companies deploying Software as a Service (SaaS), Infrastructure as a Service (IaaS), and even private cloud models. A 2015 survey by Crowd Research Partners found that nine in 10 security professionals worry about cloud security.

These concerns, however, are not stopping enterprises from investing in the cloud. The Intel Security study found that

While the survey shows that confidence in cloud security is increasing, only one-third of respondents believe their senior executives understand the security risks.

Investments in cloud security should be commensurate with the level of migration to cloud services. But budgeting for security in the public cloud is distinctly different than planning for on-premise prevention. One fundamental shift is that cloud providers use a “shared responsibility model” that spreads risks between vendor and customer. Another difference: Customers don’t buy the same mix of products and equipment to secure the cloud that they do in the data center.

Budgeting for security in the public cloud begins by considering which applications and infrastructure components will live there. Some, like website hosting and document serving, are of relatively low risk and don’t demand the most stringent safeguards. Also consider the consumption models you’ll use. SaaS providers generally assume responsibility for security and the application and system levels. However, IaaS providers tend to cede those responsibilities to the customer. What’s more, no public cloud provider is likely to assume responsibility for user access and data protection, although there are measures they can take to support your own efforts.

There are three levels of security to consider as you build out your public cloud strategy:

System-level security for IaaS

This is secured plumbing: systems-level components such as operating systems, networks, virtual machines, management utilities and containers. Here, you want to invest in cloud providers that make it easy for you to keep your systems current with the latest patches and updates. The service provider should also provide thorough visibility into your cloud instances so that you can see all instances that are running. One of the challenges of public cloud is that it’s so convenient to spin up new VMs and containers that you may forget to shut them down later. These so-called “zombies” are latent security threats because they present potential attack vectors into more business or mission critical systems.

If you plan to use containers, as a growing number of enterprises are, be diligent about the level of security protection they offer. The market for containers is still immature, and security – while improving – is considered one of the technology’s weakest areas.

Remember, you are responsible for system-level security in your Infrastructure as a Service (IaaS) and Platform as a Server (PaaS) instances. Integrating these security controls and reporting in with your on-premises systems will create efficiencies. Be sure to include the appropriate controls for the type of server employed. These may include tools such as intrusion prevention, application control, advanced antimalware solutions and threat detection. These should be all be centrally managed for visibility and compliance in addition to policy and threat intelligence sharing with your on-premises infrastructure.

Application-level security

This level is primarily about identity and access management. Your best investment here isn’t financial; it’s a policy that limits the ability of users to deploy cloud applications without IT’s knowledge.

After ensuring policies are in place that offer IT visibility, the next step is to invest in multifactor authentication and identity management. The first approach uses two or more devices or applications to permit access. For example, a verification code can be sent to a phone or email address to ensure that a stolen password isn’t a critical failure point.

Identify management locks down application access by requiring users to authenticate through a secure resource such as LDAP or Active Directory. If your organization already uses a directory, consider investing in cloud brokering software that supports single sign-on so that users can authenticate to all their cloud services through their local directory. This gives IT complete visibility and shifts access control from the cloud service to your own IT organization. Consider also investing in a secure VPN tunnel so sessions are never exposed to the public Internet.

Data-level security

This level of protection involves securing the data itself. No cloud provider will take responsibility for your data, but there are solutions you can purchase to help.

Many cloud providers, for example, offer encryption as a standard option, but you may be surprised at how many do not, or who encrypt data only part of the time. Anything less than 256-bit encryption is considered inadequate these days.

More important is that you have full control of the encryption keys. If a cloud provider insists on owning them, you have no guarantees that your data will be safe. Seek another provider.

In addition, make sure your data is unencrypted only when in use. Some providers require that data be transmitted to their facilities in plain-text format. That’s a security risk.

As noted in the Cloud Security Primer, none of these levels should be secured in isolation. Cloud security, the primer states, is “an end-to-end challenge whereby the solutions must be built into the overall IT environment and not tacked on as an afterthought.”

Whatever cloud provider you adopt, make sure their security guarantees spelled out in their contract and SLA. A good contract should spell out exactly what procedures will be employed, along with any penalties the provider will face for non-compliance, how they will report upon it, and how you can audit to ensure your contractual terms are being met. A strong SLA ensures that you don’t simply toss the keys to your cloud provider as you’re walking out the door.