Cloud Security Strategy

Cloud Security

As discussed in the previous article around cloud strategy, some areas might require there own succinct strategies.  This article will attempt to outline some of the cloud security challenges for cloud adoption and promote discussion.

There is an element of stepping into the unknown with cloud and cloud security, to a degree that is caused by the way cloud is represented and sold.  As an industry there needs to be an increased understanding about what cloud is, and more specifically about the model that cloud represents.  It isn’t as simple as saying the cloud is somebody else’s compute power, with SaaS and PaaS services it goes beyond that.  However, similarly the view that the cloud represents an impossible security challenge is false, in many cases you should continue doing that which you have always done.  Analyse, identify, mitigate and minimise risk and impact to the business.

The security and privacy concerns that need to be addressed with cloud computing are similar to the security and privacy concerns that need to be addressed with traditional non cloud computing.  These concerns are however brought into a sharper focus as it is now not an option to not engage in these activities and as cloud assets are subject to external control and management.

Central to many cloud computing concerns is this transference of responsibilities and control from internal IT teams to external suppliers.

Despite not having control and responsibility for certain elements of the cloud stack, depending on the cloud service being consumed, a consumer still needs to take responsibility for its use of cloud services.  In terms of maintaining situational awareness, setting priority, continued analysis of alternatives and effecting change to security and privacy standards that are in the best interest of the organisation.

There are a number of security risks associated with cloud computing that should be adequately addressed.

• Legal protections.
• Governance loss.
• Responsibility ambiguity.
• Authentication.
• Authorisation.
• Resource isolation and segregation.
• Compliance requirements.
• Legal obligations.
• Incident management.
• Interface vulnerabilities.
• Data protection.
• Internal malicious behaviour.
• Business robustness.
• Service availability.
• Vendor lock in.
• Data deletion.
• Visibility.
• Auditability.

Cloud computing does not only introduce risks, it also introduces an opportunity to improve upon current practice. As many industries seek to leverage the value inherent in cloud computing, standards and certifications are being introduced and modified to ensure the security, policies, governance and compliance of cloud vendors.

This presents an opportunity for many organisations to provision improvements to current security services, through embracing the advanced cloud native security and privacy tools and by fully leveraging the tools, scale and automation of management tasks. As the transition to cloud computing gathers pace, it is vital that an organisation provides comprehensive framework for the secure adoption of these services; that an evaluation and security perspective is provided to business functions that want to consume cloud services.

This framework can contextualise the security responsibilities for the business functions that consume these resources.

Cloud Security Framework

As an organisation transfers data and processes into a cloud platform it is important that the current level of security is maintained and potentially surpassed.

The section below identifies key framework elements that will help an organisation to evaluate and manage the security of cloud services.  The goal of using these framework elements is to mitigate risk and ensure services are supportable when operating in a live environment.

Effective governance, risk, compliance processes

Transfer the established security and compliance policies that govern current IT services. These are in place to ensure protection of intellectual property (IP), assets, personal identifiable information (PII), adherence to compliance requirements and the continued operation of the organisation. These policies and procedures should have been developed using results from continuous analysis of the impact of having any aspect of an organisations  systems compromised.

Security controls for cloud services should be similar to those in existing environments.  However, the risks are different due in part to;

• The division of responsibilities between cloud vendors and consumers.
• Technical design of the underpinning infrastructure is the responsibility of the cloud vendor.
• The multiple interfaces between vendors and consumers.

Understanding the associated risks of cloud computing, documenting an organisations level of risk tolerance and focusing on the mitigation of red line risks and requirements are key tasks to the transition of services to cloud computing.

As an organisation moves to adopt cloud services, focus needs to shift to the identification, documentation and mitigation of these risks and requirements.

The primary method an organisation has available to ensuring that cloud computing is secured in line with security and compliance policies, is within the agreements maintained with the cloud vendors. The master service, service level and operational level agreements need to collectively meet all of the identified security and compliance requirements.

Given that Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS) provide different separations of responsibilities between the cloud vendor and consumer, this needs to be appropriately reflected in the master service, service level and operation level agreements.

Whilst it might seem obvious, if these vendor agreements are not in place or don’t meet security and compliance requirements, then it is inadvisable for to proceed and use those cloud services.  Adoption of services that don’t meet the identified requirements should be flagged on risk registers.

From a general governance perspective, cloud vendors should be contractually bound to inform of any breach into systems, regardless of your specific organisation being directly impacted.  The cloud vendor should provide specific pertinent information in the notification, stop the breach as quickly as possible, restore secure access to services, apply forensic analysis to determine the circumstances and cause of the breach, advise of long term changes to correct the root causes to ensure no re-occurrence.

If you are working in an industry with the potential for high financial and reputation costs resultant from a breach, you could seek the cloud vendor to provide indemnity, against breaches proven to be the cloud vendor’s responsibility.  It is unlikely at this stage of cloud adoption you’ll succeeded in that endeavour, but if you don’t ask you will never get!

One of the fundamental design concepts behind cloud computing is that, data may be stored in, processed on and transmitted to any servers or devices the cloud vendor operates.  It is possible therefore for data to be located across multiple jurisdictions, either through multi-jurisdiction cloud service design or because a cloud vendor might have subcontracted services.  This adds complexity, as it might be difficult to ascertain with complete confidence which jurisdiction data actually resides, which regulators have jurisdiction and what regulations apply.

This jurisdictional issue directly impacts the placements and protection of PII data for example.  The divergence between the regulations within each jurisdiction could potentially create issues.  In addition some regulations might restrict the allowed locations of data. Before the migration of any data into a cloud service it should be a requirement to capture the regulatory and compliance requirements and obligations of the cloud vendor and the organisation.  Specifically the requirements for;

• Data Retention.
• Data Protection.
• Interoperability.
• File Management.
• Disclosure.

This requirement is so an organisation can identify any legal requirements and related risks, helping to understand the business impact level of the data, and ultimately provide a recommendation of a data sets suitability for cloud computing.

Challenge the cloud vendor to provide evidence that they are compliant with a set of established security controls. The most widely recognised international standard for security compliance is ISO/IEC 27001.  In addition the following cloud specific certifications exist;

• ISO/IEC 27017 “Code of practice for information security controls based on ISO/IEC 27002 for cloud services”.
• ISO/IEC 27018 “Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors”.

This provides a degree of confidence in the cloud vendor, and shows in some part due diligence in vendor selection.  The suitability of the certification held needs to be established on a service by service basis. For example a service handling payment card information, would require a cloud vendor to be certified for Payment Card Industry (PCI) Data Security Standard (DSS).

Audit operational and business processes

As a baseline, an organisation should expect to have access to a report of the cloud vendors operations conducted by independent auditors.  The level of access granted to effectively audit information is a consideration for contracts and service level terms agreed with cloud vendors.  As part of the terms in the contract, the cloud vendor should provide timely access to audit, log and report information – that are relevant to the services being held with the cloud vendor.

Through independent audit reports or self conducted audits, an organisation should seek to gain insight into the following;

• The internal control environment of the cloud vendor, including risks, controls and other governance issues.
• The corporate audit trail, including workflow and authorisation.
• Facilities for management and control of cloud services and how these facilities are secured.

Any cloud services being used creates a need for appropriate auditing of activities of persons employed by the cloud vendor, the organisation or the organisations partners, to ensure that security controls meet requirements.  the consuming organisation should expect to see audit information relating to any cloud service that is being purchased.

Key audit controls for cloud services that a consuming organisation utilises include;

• Ensuring the logical or physical isolation of applications and data located within shared, multi-tenant environments.
• Provision of protection for assets from unauthorised access from vendor staff.

Any auditing that the cloud vendor is subject to should be independent.  To effectively audit the cloud vendor the auditor must be granted access to the policies and procedures of the vendor related to security controls.  Auditors require access to logs and records to determine if these procedures and policies are being correctly followed; in some cases the auditors may require specific testing to be conducted to demonstrate compliance.

The consuming organisation should have appropriate access to cloud vendor events, logs and audit trails to prove enforcement of cloud vendor security controls.  As part of an independent audit the vendor should be able to assure that all necessary information is being logged and stored appropriately. Including;

• Authentication.
• Authorisation.
• Management information.

For related consumed cloud services and data, for all security and compliance policies established by the consuming organisation and the cloud vendor.

It is recommended that mechanisms be put in place to ensure the routine flow of audit information from the cloud vendor.  This flow might include secure logs and reports sent on an agreed timetable that might for example take place alongside service reviews.  Any notifications for exceptional security alerts, events, incidents or breaches should be timelier.

Any provided audit data, secure logs and reporting should have the requisite information contained within to enable forensic analysis, independently from the cloud vendor, to determine incident root cause, what assets were compromised and what security controls, policies, procedures, design or technologies need to be changed to prevent re-occurrence.

Ideally this audit information should be delivered via an API or web service, to ensure timely delivery and reduce the human resource cost from processing this information.

Auditing of the cloud vendor must extend to any cloud self service portals, as this service itself is more sensitive to abuse then the services running within.

A consuming organisation should be able to demonstrate that both the cloud vendor has been independently audited and they have access to the audit report.  Or in a case of internal audits, the consuming organisation should be able to provide the auditors with the required level of access to audit, through contractual agreements with the cloud vendor.

Audit of cloud vendors is essential for providing a degree of confidence in adopting cloud services.

• Audits conducted by appropriately skilled staff, independent from the cloud vendor.
• Audits must be conducted against an agreed established security standard (ISO27001, PCI DSS).
• The security standards being audited against, must meet requirements for security controls.
• Audit reports are recommended to be delivered as part of the service review process.
• Audit information should be available via an API or web service.

Supply Chain Security

In addition to the security controls, policies and procedures that the cloud vendor adheres to, of equal importance are the controls, policies and procedures that the cloud vendors supply chain adheres to.  Any solution is only as strong as its weakest link; it would be naive to think that the supply chain security isn’t a routine target for malicious attempts for access.

The cloud vendor must ensure that its supply chain satisfactorily supports all of the security controls and principals that the vendor claims to implement.  If the cloud vendor doesn’t implement this principle it is possible for a supply chain compromise to undermine the security and compliance of a service, negatively impacting the implementation of other security controls and principals.

Manage identities, roles and people

The use of the cloud means that to some extent cloud vendor staff will have the ability to access consuming organisation data and applications, in addition to the end users that require access for administration or job roles.

It should be ensured that the cloud vendor has processes and functionality that governs their own staff access into customer data and applications. There should also be the capability to and tools provided to implement role based access control (RBAC) to data and applications for accessing staff. This RBAC could be set/applied per resource, resource type, service, service type, application and application type.

The cloud vendor should provide a secure system for the provisioning and management of unique identities for accessing staff.  This identity and access management (IdAM/CIAM) functionality should support simple resource access, customer applications and cloud service workflows.  Any access to the cloud management platform should be monitored and logged to provide auditing of access to all customer data and applications.

Points to consider;

Federated Identity Management (FIM), External Identity Providers (EIP): Integration to existing Active Directory (AD), to maintain efficiency in management and to avoid ID split brain or multiple identity management.

Identity Provisioning and Delegation: Be able to administer and control user access. This access should be delegated away from the cloud vendor.

Single-Sign-On (SSO), Single Sign-Off: Use FIM to provide SSO for authentication to SaaS platforms and for solutions deployed across the cloud infrastructure. SSO made available using standards such as SAML 2.0, WS-Federation and OAuth.

Identity and Access Audit: Access to audit and logging reports relating to service usage, for internal assurance and for compliance with regulations.

Robust Authentication: The option to utilise strong, multi-factor, mutual and/or bio-metric authentication for those services that are deemed to contain high value or high risk data assets.

Role, Entitlement and Policy Management: Be able to follow any existing RBAC models utilised within the current infrastructure.

The cloud vendor should have a formalised process for managing their own employee access to any hardware or software used to store transmit or execute customer data and applications.  These processes should be disclosed and adherence to them should be auditable.

Personnel Security

Cloud vendor staff should be subject to personnel security screening and security education appropriate for the role held and level of access to systems. This principle should be followed to mitigate the likelihood of accidental or malicious compromise of customer data by cloud vendor personnel.

Up to date security education should be a pre-requisite for cloud vendor staff gaining access to cloud vendor systems.  Tracking of this education should form part of the cloud vendor formalised process for managing staff access.

Protection of data and information

Data is central to IT security concerns.  The same rigour that is required in managing data in current IT infrastructure and platforms is required in the cloud infrastructure.  The task is made more difficult due in part to the distributed nature of the cloud and the shared responsibilities involved in cloud computing.

Security considerations should apply to data at rest and data in transit in both current IT infrastructure and for cloud infrastructure.

The question of data suitability for cloud computing comes down to risk analysis;

• Risk of theft.
• Risk of unauthorised disclosure.
• Risk of tampering.
• Risk of unauthorised data modifications.
• Risk of data loss.
• Risk of data unavailability.

Due to the encapsulation of IT infrastructure within the cloud, when we discuss risks to data above these should extend that risk to include ‘encapsulated data assets’, this might include applications, firewalls, servers, desktops, switches and databases.

The security controls for handling data security are well defined in ISO 27002 and are augmented by specific cloud considerations defined in ISO 27017

The cloud service that has been adopted (IaaS, PaaS or SaaS) is going to define where control and responsibilities sit for ensuring security controls are implemented correctly.

• Create a data asset catalogue:
  • Identify all data assets, classifying the data in terms of business impact.
  • Specifying ownership and responsibility and describing the locations and acceptable use.  Map the relationship and interoperability of the data assets.
• Consider all forms of data:
  • Include a provision within the above control for unstructured data (images, scans, pictures and multimedia).
  • Identify any specific treatment required for unstructured data, such as redaction of signatures, addresses, payment card information or PII data.
  • Structured data sets within a database need to have appropriate segmentation requirements agreed;
    • In a shared data schema, data is intermixed on a shared platform.  Row 1 might contain company data and row 2 might contain another cloud customer’s data.
    • With an isolated database, company data would be stored within a database platform dedicated.
    •  Within both shared schema and isolated scenarios data should be encrypted at rest.
• Consider privacy requirements:
  • Does the data contain PII? What privacy regulations and law governs the data? Do these regulations govern the placement of this data set?
  • Tag the data appropriately and ensure that the storage meets regulatory requirements, permit access only by appropriately authorised users.
  • Security controls and audit points created to ensure compliance with appropriate regulations.
  • Audits conducted against standards (ISO/IEC 27018 covers PII for example).
• Apply confidentiality, integrity and availability procedures:
  • Data sets classified as sensitive must be encrypted at rest and encrypted in transit.  This means data should be encrypted upon the storage and processing
    • Keys and certificates for access must be controlled and only be accessible to company staff
  • Data integrity must be guaranteed and validated either via message digests or secure hash algorithms.  This integrity must extend to data deduplication, redundancy, replication and backups.
  • Data sets must be highly available either through application based replication and redundancy or infrastructure based replication and redundancy.
  • Data handling systems must be resilient to ensure high availability during planned load or denial of service attacks (DDoS
  • Existing business continuity (BC) and disaster recovery (DR) plans must be adhered to, or improved.
• Apply identity and access management:
  • Appropriate authorisation must be granted before any user is granted access to sensitive data; audit trails for data access must be available.
  • Logging and event management must be provided by the cloud vendor, relating to any systems hosted within cloud vendor platforms
  • Clear procedures for the handling of data forensics, logs and events must also be treated securely to prevent ‘covering of tracks’.

None of the security techniques outlined are new.  Cloud computing does require new considerations for these principles.  The way in which security must be applied will vary depending on the cloud services being consumed.  For IaaS, much of the ability to control the security of a service remains resident with the consuming organisation.  For SaaS, much more emphasis is placed on the cloud vendor to ensure adherence to requirements.  In SaaS the role becomes much more about auditing this adherence.

Enforce privacy policies

There is a concern for privacy inherent with the adoption of a multi tenanted cloud service; this concern is heightened by newsworthy cases in which major financial institutions have reported theft of PII data, such as credit card numbers.

Data protection and privacy is of prime consideration.  Many types of data sets that are stored and processed are regulated and governed by law, continued adherence to these regulations and laws are a requirement for data to be stored and processed within cloud solutions.

Whilst security and privacy are related, they are not the same.  Security is primarily concerned with defending against threats.  Privacy is specifically related to personal data, which can be endangered not only by external malicious threats, but by internal negligence, bugs or governance gaps.

Data protection requires imposing limitations on the use and accessibility of PII, consistent with applicable regulations and law, approved at the highest levels within an organisation.  The ability to effectively enforce the data protection and privacy policies requires the identification and tagging of the data in scope.  Only after identification can the data be appropriately stored, processed and access controls placed around it.  This applies to the cloud just as it applies to current IT infrastructure and systems.

Responsibility for data, regardless of what cloud service is consumed (IaaS, PaaS or SaaS) remains with consuming organisation.  Even though the ability to police polices and procedures for data sets stored in the cloud might be limited.  The consuming organisation will remain liable for any loss, damage, misuse of the data sets.

Entering into legally bounding agreements that correctly identify the roles and expectations of the consuming organisation and its cloud vendors, that allocate the responsibilities for the data being stored in the cloud is one tool.  This legal agreement or contract should also deal with the terms by which the cloud vendor will indemnify consuming organisation against damages and losses sustained.

It is critical that the privacy requirements are addressed in the cloud service agreement.  If they are not adequately addressed the perhaps alternate methods for achieving organisational goals should be sought, either through a different provider or the removal of PII data to hybrid hosted systems.

The consuming organisation retains a responsibility for maintaining policies that address privacy concerns and are responsible for ensuring that cloud vendors adhere to the defined privacy policies.  There is an ongoing obligation to monitor the cloud vendors’ compliance with policy.

Assess the security provisions and placement for cloud applications

There is a need to proactively protect business critical applications from external and internal threats throughout the applications life-cycle, from design to implementation and production.  An organisation should have clearly defined security policies and processes to ensure applications are not introducing risk.

A consuming organisation should place the same rigour to applications security in the cloud as is applied to infrastructure or physical security.  If an application is compromised it can create financial liability and reputation damage, not just to consuming organisation but to the cloud vendor.

In order to effectively make decisions around cloud application security, it is important to understand the impact different cloud deployment models have to application security.

• Infrastructure as a Service (IaaS):
  • Responsibility for deployment of the complete software stack – operating system, middleware and application – and for all aspects of security that relate to this stack, including the installation of all required security patches.
  • Security of network, physical environment, auditing, authorisation and authentication.
  • Mimic the current application policy.
  • Apply appropriate data encryption standards to the storage, processing and interaction with data sets.
  • System assurance principals, development and testing methods applied with rigour.  As application is resident outside of the security perimeter, escalations and impact for errors and faults can snowball.
• Platform as a Service (PaaS):
  • Responsibility for application deployment and securing access to the application.
  • Cloud vendor has responsibility for securing the infrastructure, operating systems and middleware.
  • focus on audit, authorisation and authentication.
  • Ensure the application of appropriate data encryption and key management standards.
  • Defines how sensitive data is handled, in general and through PaaS configuration options.
  • Ensure that knowledge is maintained for the format and location of the data.
• Software as a Service (SaaS):
  • Cloud vendor has responsibility for securing the infrastructure, operating systems, middleware, applications and data.
  • Ensure knowledge is maintained for vendor patching schedules, malware controls and release cycle.
  • Define scaling policies to ensure high availability.
  • Ensure knowledge is maintained for vendor handling of data locations and format.
  • Define how sensitive data is handled, in general and through SaaS configuration options.
  • Ensure knowledge is maintained for vendor encryption at rest and in transit.

There is a cost in ensuring all of the above, built into technology, resourcing, interventions and audits. However, these costs are not likely to be as high as the potential liability and reputation loss from an application security breach.

Developing and deploying applications in the cloud environment forfeits some control and the ability to police all levels of an environment. Application development needs to keep this consideration in mind and where possible engineer security into cloud applications from the ground up.

Ensure cloud networks and connections are secure

The cloud vendor must allow legitimate traffic and block malicious network traffic.  This can be problematic for a cloud vendor as they don’t and cannot know the network traffic that their customers plan to send and receive. Nevertheless, it is required that the cloud vendor provide a level of perimeter safety measures.

• Traffic Screening:
  • Certain traffic is never legitimate, for example traffic to and from known malware ports.  If the cloud vendor doesn’t automatically screen traffic, the customer must.
  • Screening is generally performed by firewalls of software.
    • Does the provider publish a standard perimeter block list that matches with the offering terms of service? Request and maintain a copy of this block list; this offers assurances that a network protection plan is in place and some functional guidelines.
    • Does the cloud vendors firewall control IPv6 access, or protect against both IPv4 and IPv6 attacks?  This is important as IPv6 can provide circumvention of an IPv4 only firewall, if IPv6 is not limited.
• Denial of Service protection:
  • Is the cloud vendor able to withstand and adapt to high-traffic attacks, such as Distributed Denial of Service attacks (DDoS)?
  • A DDoS attack might result in being unable to access cloud services, and ultimately a loss in business and reputation.
• Intrusion detection and prevention:
  • Some traffic may initially look legitimate, but deeper inspection might indicate a malicious payload such as spam, viruses, or known attacks.  Understand if the cloud vendor will block or notify about this traffic.
  • Intrusion detection and/or prevention systems (IDS/IPS) may be virtual or physical devices.  Understand if the cloud vendor is providing IDS/IPS services and if not implement solutions where appropriate.
  • IDS will typically only flag for human intervention, IPS will take action to block offending traffic.
    • IDS/IPS content matching can detect or block known malware attacks, virus signatures and spam signatures, but are also subject to false positives.  If the cloud vendor is providing IDS/IPS are there documented exception processes?
    • Similarly, IDS/IPS traffic pattern analysis can often detect or block attacks such as DDoS or network scans.  In some cases this could be legitimate traffic, in the case of load or security testing. Does the cloud vendor have documented exception process for traffic identified as an attack pattern?
• Logging and notification:
  • For assurance and troubleshooting the customer should have access into network health.
  • The cloud vendor must have defined incident reporting and handling procedures that are clear with visibility.
  • Any logging that takes place for systems hosting PII data, must adhere to the rules and regulation governing the capture, transfer and processing of those logs.
  • Where networking logs contain information about other clients, it isn’t unreasonable for a cloud vendor to deny direct access to unformatted logging information.
  • Understand the logging and retention policies;
    • What is the cloud vendors’ network logging and retention policy?  Are these logs made available for forensic analysis?
    • What are the cloud vendors’ notification policies?
    • Are historical statistics available for the number of attacks detected and blocked?

It is not sufficient for a cloud vendors’ architecture to only deal with external traffic, it must have security controls that govern the movement of traffic within the cloud platform.  This is to protect and maintain customer isolation within the cloud vendors’ internal network.

Assess the suitability of a cloud vendor based not only upon the external network controls but also these internal network controls.

• Provide tools to protect clients from one another:
  • Cloud vendors are responsible for providing the means to separate themselves from other customers and from the internet.
  • Most cloud vendors provide private Virtual Local Area Networks (VLANs) for customers that no other customer can access.  These VLANs may be implemented on physical switches, hypervisors or a combination of both.  Verify the cloud vendors VLAN controls meet regulatory requirements.
  • Virtual Private Networks (VPNs) used to connect VLANs and to sites must be configurable in such a way to meet regulator requirements.
  • Firewalls must be resident between VLANs, either in the form of physical infrastructure firewalls or virtual host based firewalls.
• Protect the cloud vendors network:
  • The cloud vendors control network must be properly protected and hold certification to the required level to support the servers that it is managing.  For example if an implemented solution accredited to PCI DSS the cloud vendors management network must also be certified for PCI DSS.
• Monitor for intrusion attempts:
  • Audit information and logs must be subject to appropriate security controls to prevent unauthorised access, destruction or tampering.
  • Request details of what type of internal network security incidents are reported and what the metrics are.
  • Hold details for the cloud vendors processes for alerting in the event of both successful and unsuccessful internal network attacks.

Data in transit protection

Data transiting networks must be adequately protected against tampering and eavesdropping via a combination of network protections and encryption. If there is a failure to implement data in transit protection, then the integrity and confidentiality of the data may be compromised in transit between storage, processing, organisational use and customer use.

External Interface protection

All external or less trusted interfaces utilised must be identified and have appropriate protections to defend attacks against them. By not implementing this principal, interfaces could be subverted by attackers in order to gain access to a service or the data within it.

Physical security controls for cloud infrastructure and facilities

The security of any IT system also depends upon the physical security of the infrastructure and facilities that are used to host it.  In the case of cloud computing this extends to the cloud vendors infrastructure and facilities.  Gain assurances that appropriate security controls are in place from the cloud vendor.

This assurance can be gained from a cloud vendor demonstrating auditable compliance to ISO 27002.  Controls contained within include;

• Physical infrastructure and facilities should be held in secure areas.  A physical security perimeter must be in place to prevent unauthorised access, combined with physical entry controls.  All endpoints that are used to manage the cloud vendors’ infrastructure need to have an appropriate level of physical security.
• Protection against external and environmental threats. The cloud vendor must provide protection against fire, flood, earthquakes, civil unrest or other potential threats that might disrupt vendor services.
• Control of personnel working in secure areas.  Controls must be applied to prevent malicious actions by any personnel who have access to secure locations and areas.
• Equipment security controls. Controls must be in place to prevent loss, theft, damage or compromise of assets.
• Supporting utilities such as electricity, gas, telecommunications and water must have controls in place.  Controls must be in place to prevent the disruption of vendor services either by failure or malfunction of a utility supply.  This should include the use of multiple routes and multiple providers.
• Control security of cabling. Controls must be in place to protect power cabling and telecommunications cabling, to prevent accidental or malicious damage.
• Equipment maintenance. Controls must be in place to perform the necessary preventive maintenance of all equipment to ensure services are not disrupted due to foreseeable equipment failure.
• Removal of assets. Controls must be in place to control the removal of assets, to prevent theft of valuable or sensitive assets.
• Secure disposal or re-use of equipment.  Controls must be in place to facilitate the secure disposal or re-use of equipment, in particular any devices that might contain data.
• Human resources security. Appropriate controls must exist to govern the staff working at the facilities of the cloud vendor, including any temporary or contract staff.  For example staff must be DBS vetted.
• Backup, DR and BC plans. The cloud vendor must have appropriate backup of data, retention if data and test DR and BC plans for handling the failure of equipment.

Asset protection and resilience

Data, assets should be protected against physical tampering, loss, damage or seizure. Failure to implement this principal will lead to inappropriately protected  data that could be compromised and may result in legal and regulatory sanctions and reputation damage.

Agreement on security terms and service agreements

Cloud computing is a purchased service and as such must be implemented with an SLA.  Included within this SLA must be an agreement for the security responsibilities of each party.  The service agreement should specify security responsibilities, requirements and include the mechanism by which breaches will be reported.  In addition the security agreements contained within any SLA agreement between consuming organisations and a cloud vendor must pass on to any services that the cloud vendor utilises to deliver services.

It should be explicitly documented in the SLA that cloud vendors must notify in a timely manner of any breaches to the cloud vendors systems, regardless of being impacted or not.  The cloud vendor should;

• Include specific pertinent information in the notification.
• Stop the data breach as quickly as possible.
• Restore secure access to the service as soon as possible.
• Apply best practice forensics in investigating the cause of the breach.
• Make any long term infrastructure changes required to correct the root causes of the breach and ensure no re-occurrence.

Agree and document what standards cloud vendors will be held to.  In addition document the current standards that the infrastructure is held to and the differences when moving to a cloud service.

The exit process

Have a well defined exit process for cloud services.  This must cover not just how, where and why services will be moved but define the cloud vendors requirements and obligations.

The exit process should include a provision to ensure smooth transition of service, without the loss or breach of data.  It must therefore enable the retrieval of data in a suitably secure form.  Backups, logs and events should be maintained until the exit process is complete.

Upon exit completion the cloud vendor should ensure that any and all copies of customer data are permanently and irreversibly erased from its environment.  Including but not limited to backup locations, replication targets and online locations for data.  This must also extend to the deletion of logs or events that might be held for customer services and systems.

Summary

There is no one size fits all for any aspect of cloud strategy, certainly not cloud security and effective strategies are tied into business requirements.  TOGAF doesn’t include an isolated domain for security, perhaps this is to ensure that any security requirements can be linked back to business requirements and architectural principles.

The points in this article are for discussion and consideration when thinking about cloud security strategy. Using the ADM cycle to work through the business, data, application and technology requirements specifically with a security focus will stand you in good stead.

Simon