Guest Column | August 17, 2012

Securing The Cloud With A VAR, MSP, ISV Audience In Mind

Andrew Hay, CloudPassage

By Andrew Hay, chief evangelist, CloudPassage

Customers have always looked to their vendors, be they VARs, MSPs or ISVs, to distill the challenges of migrating to a computing architecture. This continues to be true with regards to cloud – perhaps one of the most misunderstood and confusing architectures to arrive since the introduction of the personal computer to replace aging mainframe technology. Extending security beyond traditional on-premises perimeter controls, adhering to regulatory compliance mandates and revising policies and procedures to encompass a platform owned by a third-party (not to mention shared with other customers) are but a few of the concerns customers wrestle with when thinking about making the jump to cloud.

Security in the cloud, as with past evolutions in computer architectures, remains an unfortunate afterthought of the server and application deployment process. Organizations want to get their servers online as fast as possible to complete projects and free up implementation staff. As such, the procedures that align with the defined security policy is often viewed as a task to be performed after the server or application is deployed – and often by a completely different team of individuals. This may have been possible with on-premises servers carefully hidden behind network-based security controls, such as firewalls, intrusion systems and router access control lists (ACLs), but such controls are far less prevalent and configurable in cloud environments. The risk of compromise is also higher in public cloud environments with many service providers allowing the provisioning of exposed servers without any perimeter security in place.

Compliance, often perceived as one of the primary roadblocks to cloud adoption, presents an additional challenge. Organizations required to adhere to international, state or industry-specific regulatory compliance mandates find themselves scratching their heads when it comes to moving ‘in-scope’ servers and applications to cloud environments. If a cloud provider is compliant with a particular mandate, does that mean that the customer’s cloud instances are automatically compliant? Will an auditor or assessor look upon the cloud server instances and deployed host-based controls as sufficient to satisfy the requirement? Will the previous ‘certification’ be nullified if some in-scope servers are moved to a cloud environment? Unfortunately, the answers to the aforementioned questions are ‘probably not’, ‘maybe’ and ‘it depends’ – answers that no company ever wants to provide to its customers.

At an established company it’s highly unlikely that policies and procedures were written with cloud architectures in mind. Organizations are often guilty of ‘updating’ existing policies by appending words like ‘cloud’ to a list of technologies or simply adding another bullet to ensure the term cloud is somewhere in the document. Similarly, it’s not uncommon for organizations to do a global search for a term like ‘server’ and replace it with ‘cloud server’ just to have a procedure on hand. Unfortunately, the nuances of installing, configuring and operationalizing cloud instances require far more work than a simple search and replace.
VARs, MSPs and ISVs would do well to familiarize themselves with the architecture requirements of their customers – i.e. how they see the business leveraging cloud for various projects. Does the customer plan on embracing cloud bursting between private, public and hybrid cloud environments to handle heavy server and application utilization periods? Will the tools currently deployed handle such dynamic environments? Will the purchased licenses allow for the rapid deployment and retirement of servers or will customers find themselves constantly on the phone with support explaining their strange licensing usage?

Vendors must also work to security and compliance capabilities of the various cloud providers to help address implementation and operational questions from customers. The customer may require certain architectural requirements that a particular cloud provider may not be able to facilitate – such as the ability to burst cloud servers to a competing cloud provider’s platform. If a customer requires that the cloud service provider’s infrastructure be PCI or HIPAA compliant, the vendor must be able to help its customer understand exactly what that entails – including the demarcation points of security responsibility.

Finally, customers need to know that cloud architectures are different than on-premises physical and virtualized servers. Depending on which cloud architectures are employed, be they SaaS, PaaS, IaaS or some combination of the three, customers must be education on the required changes to existing policies and procedures – or in some cases, educated on how to create new policies and procedures to specifically address cloud architecture adoption. To help VARs, MSPs, ISVs and customers, a number of free resources exist to facilitate cloud security education. Perhaps some of the most useful resources available are those provided by the Cloud Security Alliance ( and promotes the use of best practices for providing security assurance within cloud environments. Another resource is The SANS Institute’s topical and very technical cloud security blog ( The National Institute of Science and Technology (NIST - also provides fairly detailed guidance on cloud computing security including Guidelines on Security and Privacy in Public Cloud Computing (SP800-144) and Cloud Computing Synopsis and Recommendations (SP800-146). For European vendors, the European Network and Information Security Agency (ENISA - provides cloud security risk assessment guidance, in addition to an assurance framework, aimed at a European audience.

Using the aforementioned resources should help expedite VAR, MSP and ISV cloud knowledge and allow better handling of customer questions with regards to their inevitable adoption of cloud computing architectures.