Cloud shopping: Signing on the dotted line

Sometimes the blindingly obvious takes a long time to -- well -- become obvious. Not so long ago we were promised cloud services would be a one-click shopping experience. Simple or no contracts at all. That seemed farfetched. And it is. The...

Share

Sometimes the blindingly obvious takes a long time to -- well -- become obvious.

Not so long ago we were promised cloud services would be a one-click shopping experience. Simple or no contracts at all. That seemed farfetched. And it is.

The business and legal contract is alive and well. And by all accounts there remains a gulf in the starting point of the commercial arrangement and the time at which a customer can feel comfortable in turning on that cloud service. The legal contract is a way to secure trust between two parties and an important component of the due-diligence that makes up the commercial process.

It’s becoming evident that the acquisition of a cloud service will not differ significantly from any other IT procurement. Here are the activities that need to be knocked out:

  • Perform preliminary/legal due diligence
  • Define compliance requirements
  • Conduct risk assessments
  • Define security controls
  • Define and implement contract monitoring requirements

If you are a "medium-to-large” enterprise then the scale of your business likely means the following is mandatory:

1. Legal due diligence with the cloud provider

  • Provisions of a legal contract must be negotiated to specify the roles and responsibilities in accordance with a sub-set of regulatory sources e.g. European Union, industry, state and local data privacy laws. A customer needs to identify the regulatory requirements that apply to them and work with a cloud provider to support the customer’s efforts to be compliant with certain laws and regulations. For example there are laws that govern the collection, use, storage and sharing of personally identifiable information such as social security numbers.
  • However, the customer will ultimately be responsible for compliance. This fact should be highlighted in contract language delineating each party's rights, obligations and intentions.
  • Depending on the risks, it may be necessary to specify the assumptions which predicate the ability of all parties to deliver on their commitments.
  • A set of terms and conditions will be added by the legal review team to help get everyone on common ground regarding topics such as confidentiality, intellectual property rights, warranties, payments, service levels, termination and limitation of liability.
2. Compliance Audit of the cloud provider
  • A cloud provider's assertions may need to be demonstrated and verified. An audit would then be conducted against "standard" criteria. A customer can of course decide to believe what’s written on paper but it would be wiser to find a way to verify the cloud provider’s promises.
  • An audit can be accomplished by cross checking the facts on the ground against an industry standard (e.g. ISO 27000 series, PCI DS), government standard (e.g. NIST SP800-53) or self-asserted (e.g. SAS 70 report). It is important to clearly communicate to the cloud provider which compliance or regulatory framework(s) must be met in an audit.
  • It may also be necessary to leverage audit frameworks that combine a number of standards. For example, HITRUST (Health Industry Trust Alliance, includes elements of HIPAA, ISO, PCI, and NIST SP800-53.). The Cloud Security Alliance also has a number of helpful guidelines which lay out how companies can alleviate cloud security threats by assessing the security qualifications of their prospective cloud service providers.
  • There may be compliance regimes that mandate some element of certification (testing and evaluation) and a separate accreditation step (formal audit by an independent third-party) after the contract is signed. The contract language will need to be clear on which parties must be compliant, accredited, or audited.
  • Another practical matter may be specifying who is responsible for costs and management for each of the scenarios described above. A customer cannot expect the cloud provider to supply those capabilities without added cost.

3. Security Due Diligence and Risk Assessment

  • A customer may want to reconfirm assumptions that could have a material effect on the cost of the solution and "true-up" the cost and the target solution. The degree of security due diligence will depend on the level of trust that has been achieved or desired. Security due diligence can take place before the contract is signed, or after -- or (unlikely) never.

  • A list of questions should be asked of the cloud provider regarding security risk factors i.e. the impact and probability of something bad happening, for example "do you have controls in place to prevent data leakage or intentional/accidental compromise?" An industry-standard assessment will help in understanding any potential vulnerabilities. The SIG shared assessment framework was developed by several banks and has a public domain tool that is available on their site. HITRUST also publishes an assessment tool for their Common Security Framework.

  • Intellectual property rights and confidentially terms and conditions should be set forth in the contract. A customer will need to confirm that the right procedures are in place for encryption and restrictions on data access. Identifying the specific expectations of the customer and the cloud provider is key. There is often a wide range of possible methods to “support” or “meet” security requirements and the parties need to have a meeting of the minds.

  • A security risk assessment of the system, application or data may need to be completed after the contract is signed but prior to the commencement of services. A security subject matter advisor will be expected to dig deeper into vulnerabilities and adequate security controls will then be proposed.

  • The security due diligence of the cloud provider (the "host") should be wrapped up before the contract is signed.

4. Security Methods and Quality of the delivered solution

  • Security controls will not be implemented by magic. The necessary resources and tools will need to be put into action by one of the parties. Security controls will be required at the infrastructure tier, application tier and the platform- tier levels.
  • This step also argues for a robust system security review and acceptance process, similar to the Federal “Authority to Operate” procedure. FedRamp is an example of a repeatable, portable certification and accreditation process.

5. Security Operations and Continuous Monitoring:

  • Run-time or on-going operational processes are as important as the technical and procedural security controls. You can't just audit your systems on a snap-shot basis, security posture will drift over-time and so you need to continually validate the physical and logical environment and its health status.
  • The customer will need to ask questions like, what level of reporting or visibility will the service provider make available to the client? Will the service provider track incidents and report them (or all that exceed an agreed-to threshold) to the client? Or will the service provider maintain that they will manage the system and treat it as a “black box” from the customer’s perspective?
  • An often over-looked aspect of security operations is the opportunity to extract value from the data that is being collected and then to make productive changes in security defences.

Walid Negm, Director Cloud and Cyber Security Offerings, Accenture


Find your next job with computerworld UK jobs