Cloud Shopping. Signing on the dotted line and then some.

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 far fetched. And it is. 

The business and legal contract is alive and well. And by all account there remains a gulf in cogent understanding about all of the compulsory commercial steps (legal/contract, risk management, solution scope) before you (as a customer) can claim victory and turn that sometimes intangible "cloud service" on. The contract is just one component of the due-diligence and commercial process.

  

A cloud computing “purchasing” guide will not differ from the run of the mill due-diligence in many IT procurement guides. The detail is a re-frame of what we know to be true, but for some reason have not been applied. Maybe humans abandon what is blindingly obvious, until we make a mistake or when we realize the short-cuts lead us astray.

Whatever the physiology, here are the activities that we've come up with: 

• Perform preliminary/legal due diligence
• Define compliance requirements
• Conduct risk assessments
• Define security controls, including security architecture components provided as standard service elements and controls that may need to be negotiated to meet your requirements. 
• Define and implement contract monitoring requirements to measure and correct deviations from the service agreement

Nothing here is rocket-science. If you are part of an "enterprise" (enter company size here) then the scale of your business means the following is mandatory:

1.    Legal due diligence with the cloud provider

• A legal contract (document) must be in place to clarify the roles and responsibilities in accordance to a sub-set of regulatory sources e.g. European Union, Spain, Healthcare. As an initial step the customer of the cloud provider would need to identify the regulatory requirements/frameworks to which they are subject. At the end of the day you will be responsible for meeting those requirements..even those you have not initially identified as relevant in the contract. 
• It's obvious that the regulated entity will be ultimately responsible for compliance. This fact will likely be high-lighted in clear contract language to reinforce each party's rights, obligations and intentions. The use of a cloud solution will not in and itself make a client organization compliant with *all* laws and regulations. 
• Depending on the risks (and complexity of the relationship) it will be necessary to enumerate all the assumptions which are related to the ability of all parties involved to deliver on their commitments be they the data owner, processor and custodian. Here a common interpretation of the law is necessary. 
• A minimum set of terms and conditions are included to raise trust and to help get both the customer and cloud vendor on common ground e.g. confidentiality, intellectual property, warranty, payments, termination, limitation of liability. The list of clauses will grow and shrink depending on whether we are dealing with a regulated entity, private company or mom-and-pop shop
• A cloud vendor will be expected to state in the contract their ability to "support" data protection acts or law. 
• Let’s get an analogy to bring all the points above together. The contracts builds trust between two parties. Trust is like a bank account. You add and remove to it. It will be clear and unambiguous clauses that add to the trust balance. If you start with a “click-through” agreement – you may-be looking at the other end of the gun barrel. The short end of the stick etc.

2.    Compliance Audit of the cloud provider 

• There will be a point where a vendor's assertions (I do this or that) simply have to be demonstrated and proven. An audit will have to be conducted against some "standard" criteria. You can decide to believe what they say – at your own risk.
• An audit can be a cross check against an industry (e.g. PCI DS) or government standard (e.g. NIST SP800-53) or against self-asserted statements (e.g. SAS 70 report).  It is important to specify which compliance or regulatory framework(s) must be met. Other common frameworks: FIPS, ISO27000 series, CoBIT, COSO, and HITRUST (Health Industry Trust Alliance, which includes elements of HIPAA, ISO, PCI, and NIST SP800-53.). The Cloud Security Alliance  has a number of fantastic check-lists and guidelines. 
• There will be compliance regimes that mandate some sort of certification (testing and evaluation) and a separate accreditation step (formal audit by an independent third-party) after the contract is signed and for specific scenario's. Regardless, the contract language will need to be very clear on which parties must be compliant, accredited, or audited, if that is a requirement. The customer or the service provider may need to be compliant/audited/accredited, or that a total solution, spanning across services and components of both the customer and service provider. All depends.
• Another practical matter: who is responsible for costs and for management of any audit or accreditation review and certification for each of the scenarios described above? A customer may want a comprehensive, automated capability for system monitoring, but are not willing to pay for it and seem to expect that the service provider will supply those capabilities without added cost.

3.    Security Due Diligence and Risk Assessment

• A customer may want to (re)confirm assumptions that could have a material effect on the cost of the solution and "true-up" the cost and the solution against a use-case or expectation. The degree of security due diligence depending on the level of trust that has been achieved and that is desired. Security due diligence can take place before the contract is signed, or after -- or (unlikely) never. 
• A list of questions maybe asked of the cloud provider, above and beyond compliance. 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 bank and publish a public domain tool that is available on their site at www.sharedassessments.org. They also have a white paper on applying the SIG assessment methodology to cloud computing (available from the Resources page at www.sharedassessment.org/value/resources.html).  HITRUST also publishes an assessment tool for their Common Security Framework.
• Intellectual property and confidentially will be mentioned in the contract. However, that’s not the end of the road. A customer will still need to “design in” the right procedures for things like encryption, restrictions on data access. Key point: it is critical to identify the specific expectations of customer and service provider. As described elsewhere in this list, a customer may ask or be told that a solution will support a particular compliance regime; however, there is often a wide range of possible methods to “support” or “meet” compliance requirements. As an example, consider the HIPAA requirement to monitor system activity; that could be met several ways, each of which would differ in deployment and operational costs: logging system/application activity and manually reviewing logs; IDS; SIEM; GRC, etc. There is as yet no widely agreed “standard of practice” for minimal levels of protection, so a service provider should specify what capabilities will be provided. 
• A security subject matter expert will be expected to dig deeper into vulnerabilities depending on the scope of the solution. Adequate security controls will then be proposed.
• Security due-diligence of the cloud provider (the "host") ideally should be wrapped up before the contract is signed. 
• A security risk assessment of the custom system, application or data elements may need to be completed after the contract is signed and ahead the lights being turned on. 

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 someone Indeed, for both the initial implementation and the ongoing management/maintenance; see my previous comment.
• Someone has to accept the risk decision before the lights are turned on and the “go" or "no go" decision should be based on the circumstances of that moment. In other words risk tolerance may have changed since the contract was signed. 
• This procedural step argues for a robust system security review and acceptance process, similar to the Federal “Authority to Operate” procedure (although, hopefully, not as time consuming or costly). FedRamp is another example of a repeatable, portable and certification and accreditation process.  

5.    Security Operations and Continuous Monitoring: 

• Need to consider "run-time" and operational processes in addition to the technical and procedural security controls. The goal: continual validation of the physical and logical environment and it's status. What level or 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 customers perspective? (This argues that reporting requirements, reporting processes and frequency, and operational responsibilities should be explicitly specified in the contract)
• You can't just audit your systems on an snap-shot basis, things may drift over-time and its best to be "on top of things". 
• Adherence to regulatory compliance is increasingly about a more near-real-time reporting of changes, the status of the operating environment and any priority milestones