Cloud Computing Security Pattern

Cloud Computing Security Pattern

Legend:

Services provided by the Cloud Computing environment are not under direct control and therefore a few control families become more significant. Controls in the CA series increase in importance to ensure oversight and assurance given that the operations are being "outsourced" to another provider. SA-1/4/5 are crucial to ensure that acquisition of services are managed correctly. CP-1 helps ensure a clear understanding of how to respond in the event of interruptions to service delivery. The RA controls are very important to understand the risks associated with the service in a business context, but may be challenging to implement, depending on the supplier and the degree of visibility into their operations.

Description:

Cloud computing can be defined as the provision of computing services via the Internet such as

• Applications (Software as a Service or SaaS),
• Platforms,
• Infrastructure (IaaS),
• Process Orchestration and Integration.

The cloud model is of great interest to service providers because it likely represents the next great wave of innovation sweeping across the the Internet and presents tremendous business opportunities for those who can successfully define and implement the new paradigm. End users are interested because services are reasonably priced and can be accessed from any browser giving access to the computing environment from any location and making collaboration much easier. Corporate IT departments are interested because the model reduces capital investments, removes constraints on power and space, may deliver much faster development and implementation times, and promises to simplify the management of complex environments.

So it should be a simple decision to scrap the legacy environments and move to the cloud? Well, for many use cases especially private end users and Small to Medium Enterprises (SME's)  the risk versus reward is strongly in favor of adopting relevant new Cloud services as they become available. However for large organizations, especially those in regulated sectors the decision is not so simple.

Key control areas:

There are a number of control areas that must be consider carefully before you move computing operations to Cloud Services:

• Contractual agreements- who owns the data, what rights or recourse do you have for security breaches or incidents, what happens when you want to move to another provider?
• Certification and 3rd party audits- is the provider certified e.g. SAS-70 (remember the scope of a SAS-70 will determine how much trust you can place in it), can you request independent audits of the facilities and operations?
• Compliance requirements- do they meet your organisations compliance needs, e.g. Data Privacy, Safe Harbor. Where are the operations located and where would your data reside? Be aware that providers will need to obey law enforcement regulations in their operating locations, and may be obliged to disclose data without your consent to government and law enforcement agencies if requested.
• Availability, reliability and resilience- what happens when the service is not available? What are the points where you need additional resilience for access?
• Backup and recovery- in the event of a physical or logical disaster what are the Recovery Point and Recovery Time Objectives (RPO/RTO) that you will need and they will provide?
• Service levels and Performance- what do they offer and what do you need? What happens if the service is below expectations? Remember a service may be available but have an unacceptable performance level or response times.
• Decommissioning- will data be securely deleted once it is no longer needed? What about the virtual machines or processes you are using? Will fragments reside client side in your browser that you need to be aware of?

A key activity that is shared by the architect, the security manager and the business manager is to jointly agree the controls required. They should:

• Agree on the control baseline applicable to this cloud sourcing activity/service
• Confirm how this translates into the control framework of the cloud provider, because unlike regular supplier contracting it is very improbable that the cloud provider will directly implement the controls specified by the customer. It is more likely that the cloud service provider will refer to his standard (PCI DSS adherent, NIST adherent or ISO adherent) control framework.
• Decide on additional risk mitigating controls.

You will likely need supporting services if your process is comprised of a number of cloud services. Some of the important ones to consider are:

• Security (OpenID, .Net Access Control, PKI), Billing (DevPay),
• Load Monitoring and Testing (Soasta, Hyperic)
• Provisioning and Configuration Mgmt (Rightscale)

This is an evolving area and standards for integration are still emerging. Maintaining a security context across a number of seperate cloud providers can be a real challenge! Especially when you consider that you likely want to use roles to manage authorisation to different functions. There is a good case for maintaining your own directory and federation services that you will use to provide authentication across in-house and cloud services. Where possible it is recommended to abstract the authentication and authorisation services behind industry standard interfaces such as SAML


Cloud services will likely be complex webs and in fact the service you recieve may in fact be provided by another cloud provider (e.g. Box.net use Amazon S3). This became apparent when an Amazon S3 outage affected a number of services that had been built using Amazon for storage. The chain of dependencies may not be obvious, make checks according to the criticality of your requirements. If creating custom code elements the developer constantly needs to consider code refactoring to keep the code base as simple as possible and hence mitigate what is frequently the biggest overall IT Risk, complexity. 

Examples:

Applications/SaaS include

• SaaS: Salesforce, Google Docs, Facebook, LinkedIn, Doodle.

Platform service providers include

• Content: SpringCM, Xythos OnDemand, GoogleBase
• Platform as a Service: Force.com, Google App Engine, Bungee Labs Connect, Etelos, Intiuit Quickbase, LongJump, Apprenda SaasGrid, Oracle Saas Platform, MS Azure
• Data: Amazon S3, Box.net, Google Base, Amazon SimpleDB, Trackvia, Microsoft SSDS.

Infrastructure as a service include

• Cloud Providers : IBM Blue Cloud, Joyent, GoGrid, SunGrid, Amazon EC2,

Examples of Integration and Orchestration include

• Integration: Boomi, Mule OnDemand, OpSource Connect (OSB), Amazon SQS, Microsoft BizTalk Services
• Orchestration: ProcessMaker, Appian Anywhere, Skemma, Intensil
• Billing, Contract Management: OpSource/LeCayla, Aria, eVapt, Amazon DevPay, Zuora
• Security: OpenID, OAuth, Ping Identity
• Cloud Deployment: rPath, CohesiveFT, VMWare, Xen, Parallels, Bea Weblogic Server VE, 3Tera AppLogic, Elastra Cloud Server

Assumptions: Cloud computing is an evolving area and it is expected that this pattern will be revised within a year to reflect developments. It is likely that for large corporates a prudent and realistic strategy will be to deploy for test and development environments, which give some benefits without the downside of exposing production data sets.

Typical challenges: Trustworthiness of partner-how to establish and track? Lack of certainty on many aspects of controls required. Compliance. Ability to move to other providers. Authentication and authorization across multiple providers and systems.

Indications: Organization who will provide some or all of their computing environment via cloud services. Organization has constraints on existing power or space, desire to reduce capital expenditure, need to provision services rapidly, big variations in computing demand, collaboration with wide range of B2B partners.

Contra-indications: Lack of understanding of your compliance needs or inability to confirm how the supplier will meet your requirements.

Resistance against threats: Untrustworthy supplier, eavesdropping, impersonation, data theft, lack of performance and logical and physical disasters are addressed by this pattern. Consider checking supplier applications for Cross-site scripting (XSS) attacks which can be used to log keystrokes and capture data, and propagate web application worms such as Samy. Feed injection for RSS and Atom can allow an attacker to compromise applications, if feeds are not properly secured.

All other major vendors have their own literature and approaches, just search on Google!