VMblog’s Expert Interviews: CloudPassage Talks about Security and Compliance in the Cloud

March 29, 2016 Off By David
Grazed from VMblog.com

Whether new infrastructure is spun up in the cloud or whether new applications are launched in a rapid development environment, companies should be implementing security best practices and compliance checks as early and often as possible.  But, is that happening?  To find out more about compliance in the cloud and beyond, I recently spoke with Bart Westerink, senior director of security and compliance at CloudPassage, to dig in deeper and find out what we need to know.

VMblog:  To kick things off, give us some background on CloudPassage and tell us what type of problems you’re solving?

Bart Westerink:  The migration from traditional servers to agile, elastic infrastructure is putting a huge strain on enterprise compliance efforts. Servers and workloads that spin up automatically and on-demand make it difficult to manage and verify access controls, user privileges and security configurations. Implementing continuous monitoring and logging, while maintaining an accurate inventory of systems are also huge challenges. Compliance teams are being forced to expend lots of manual effort to keep up, which threatens to erase the business benefits of moving to agile infrastructure in the first place.

 

CloudPassage provides an on-demand solution that delivers complete visibility to every workload, no matter where it lives. Deployment is fast and automated, system integrity is verified, access controls are enforced and all relevant system and audit logs are tracked and archived – even for the shortest-lived systems or containers. The CloudPassage platform helps organizations track and report on all systems that fall under compliance regulations – SOX, SOC 2, PCI DSS, HIPAA and others. Policies can be automatically assigned based on the workload type, regulation category or sensitivity of the data.

VMblog:  If you would, please talk about the challenges to achieving compliance in the cloud, and to attestation efforts.

Westerink:  The public cloud is fundamentally different from a traditional physical data center environment where you rent a cage or a rack of servers. The cloud is much more abstracted and software-defined and workloads tend to be more distributed and elastic. In the public cloud, your IaaS provider gives you a virtual machine and it is mostly up to the subscriber to secure that system. You no longer have control over network devices – like routers and switches. You’re not going to find hardware based perimeter firewalls and you will likely be using a host based firewall to secure your workloads. Security appliances like network based intrusion systems and data leakage detection/prevention systems won’t work in the public cloud environment. You have no access to the network – it’s shared with other customers. So the tools that you rely on to get you through compliance in your physical datacenter may not work in the public cloud. You have to rethink about how you protect these workloads without network based tools.

One of the main reasons companies are moving to the cloud is its agility and elasticity. It’s easy to spin up hundreds of workloads as demand increases. Unfortunately, many of the traditional host based security solutions don’t work well in these dynamic environments.

VMblog:  What are the major compliance standards that enterprises adopting cloud models are focused on?

Westerink:  The more common assurance programs for enterprises moving to the cloud are SOC 2, PCI DSS and HIPAA. A SOC 2 attestation is used by many Software as a Service companies to provide increased trust and transparency with customers. The SOC 2 report allows customers to review the effectiveness of the service organization’s controls. The benefit to the service organization is that it’s a one time annual audit and the report can be shared with many customers so they don’t need to perform their own audit. Trust in the cloud is key and a SOC 2 attestation can offer a competitive advantage. Any cloud service provider that stores, processes or transfers credit card cards must be compliant with the PCI DSS standards. Healthcare companies are also moving to the cloud. Providers that process, maintain and store protected health information (PHI) are subject to HIPAA.

VMblog:  If an organization is compliant with a standard (e.g. PCI), does that mean that organization is secure?

Westerink:  No. When you look at PCI for example, we have seen quite a number of credit card breaches at large retailers over the past few years and all of these organizations were PCI compliant at the time.  There are a number of reasons for this. First, PCI is a point-in-time-audit so you may be compliant one day but not the next. Some service providers will just focus on passing the audit and not much more. PCI requires quarterly vulnerability scans, but this not enough. You’re constantly dealing with new threats and many weaknesses in your network won’t show up in a vulnerability scan. Heartbleed and Shellshock were serious vulnerabilities that required immediate attention. What’s needed is continuous monitoring where you are notified the moment a new vulnerability shows up or when one of your systems no longer meets its baseline policy. 

You also need visibility. Today’s networks can be enormously complex, connected to third parties, and auditors may not fully understand all of the intricacies during their assessment. How secure is the corporate network?  How tightly is access really controlled between the corporate network and the PCI environment? Sure there is a two factor authentication solution in place, but are there other ways in? Without performing an exhaustive penetration test, the auditor may never know.

Finally, you need automation. Given the shortage of security pros, you need to look for ways to do more with less. In the cloud, automation is no longer optional. Imagine managing firewall rules for hundreds of systems that you need to spin up in an instant?  So, organizations would be better of if they focused on thoroughly securing the business first and then compliance second.

The Federal Trade Commission also wants to understand why compliance does not equal security. In March, the FTC ordered nine QSA companies to respond to detailed questions about how they measure compliance with the PCI DSS.

VMblog:  How do public cloud software or infrastructure providers figure into the compliance question?  Do service providers make compliance easier or more difficult?

Westerink:  Security in the cloud is a shared responsibility and the IaaS provider should be going through its own compliance programs as well. This is where they get audited on the physical security of the data center, employee background checks, access controls, cameras, generators, etc. In a cloud environment, the auditor will want to understand how they manage the security of the hypervisor, storage and network, install patches and monitor logs and intrusion detection systems. The auditor for the Cloud Service Provider will include a copy of the IaaS provider’s report in its assessment to show that all of the controls below the VM were covered.

VMblog:  What should our readers think about in terms of successfully executing on compliance in the future?

Westerink:  First, build a strong security program with the right preventative, detective and responsive controls.  On the compliance side, you need to understand what you’re being audited on and develop sound processes around these controls.  Most compliance programs cover core security functions such as configuration management, vulnerability management and file integrity monitoring. For dynamic cloud environments, you want to look for a lightweight solution that offers a wide range of these core security functions. Use APIs and automate as much as you can.  On a daily basis, generate compliance reports based on events coming out of your security platform. Then, use your ticketing systems’ API and automatically upload the reports on a daily basis. A security engineer reviews the reports in the morning and either closes out the ticket or continues to investigate anomalies. Do the same for keeping track of access management reviews, vulnerability assessments, policy reviews, etc.  When the auditor shows up and starts asking for pieces of evidence, you should be able to quickly pull that information out of your ticketing system.

##