top of page

   Cyber_(Cloud-Services)

 

  • The basic document for the paid provision of access by a buyer/customer through the internet or world-wide web, to a hardware source (server or servers), controlled or owned by a seller/provider – generally referenced as a cloud service provider (CSP) – and generally paid by the buyer/customer to the CSP on an hourly, daily, monthly, yearly or multi-year subscription schedule, is currently referenced as a cloud services agreement (CSA) – which new term evolved from a former term, the service-level agreement (SLA), which term is now used more-narrowly to define the metrics and specifics, in granular detail, to be required on a moment-to-moment basis, for whatever type of product or service is to be provided to the buyer/customer through the CSA in any particular context, so it is not unusual now, for example, for there to be a CSA that references a voluminous companion and parallel SLA between the buyer/customer and CSP entities, specifying all the minute details of the metrics for the particular products and services noted in the CSA  – through which CSA the CSP may just be providing virtual space in a server farm – generally, either a configuration of a vast number of servers collected together in one location, or multiple configurations of few or many servers grouped together in many locations, either domestic or international, and all connected together through the seller/provider’s own private  network, called alternately an intranet, or a virtual private network (VPN), depending on the components and configuration thereof, such configurations are referenced collectively as the “cloud” – to the buyer/customer, which may be accessed by the buyer/customer from anywhere in the world through the internet or world-wide web, through the use of either a simple authentication mechanism (such as a single password) or in more-secure situations, multiple access authentication mechanisms (such as a password, plus some other authentication mechanism, such as an immediate call to the smartphone of the person attempting to access the CSP’s cloud, or even the combination of several authentication mechanisms in immediate sequence, such as a password, plus a call to a smartphone, plus some form of biometric authentication – such as a thumbprint scan or retina scan, depending on the available hardware), or the CSP may be granting the buyer/customer limited or unlimited access to either one particular application that may just be controlled by the CSP (generally referenced as a “hosting” license arrangement between the CSP and the actual developer/owner of that application, in which the developer/owner grants a license to the CSP allowing the CSP to allow third-parties to access that application either on some limited basis, or on an unlimited basis, with the CSP then paying royalties to the developer/owner every time such application is accessed by some third party through the CSP’s cloud) or owned by the CSP, or perhaps a “suite” (collection) of such applications (whether just controlled by the CSP or actually owned by the CSP, or some combination thereof), or the CSA may grant the buyer/customer a combination of virtual space and limited or unlimited access to an application or suite of applications through the CSP’s cloud.

 

  • Besides the CSP, there may be other entities the buyer/customer may have to engage to gain access to a particular cloud, such as for example, a cloud auditor (CA), cloud broker (CB), cloud carrier (CC), or the like.

 

  • There may also be different hardware, legal and software requirements imposed by the CSA for the different types of cloud services to be provided, such as in agreements for anything-as-a-service (any type of service to be provided on a subscription basis) (XaaS), infrastructure as a service (IaaS), platform as a service (PaaS), software as a service (SaaS), or the like.

 

  • Generally, a CSA arrangement may have three (3) basic components – a customer agreement (describing the basic conditions, relationship and terms between the buyer/customer and the CSP), an acceptable use policy (AUP) (which specifies in detail how and when the buyer/customer may have access to and resulting use of whatever services the CSP is providing to the buyer/customer on the subscription basis) and an SLA (which, as indicated above, specifies the details and metrics of whatever services the CSP is providing to the buyer/customer on the subscription basis) – all of which may be either contained within one CSA as exhibits to or sections of the CSA, or may be individual agreements besides the CSA, but all with interconnected references to the others and to the CSA.

 

  • In order for a buyer/customer to negotiate the most cost-efficient CSA, the buyer/customer must first perform extensive internal due diligence to determine whether the buyer/customer’s objectives for entering into the CSA with a particular CSP, will be fulfilled, such as for example:

    • creating a list of critical metrics – a/k/a key performance indicators (KPIs), such as for example, incident response time, that the CSP must meet hourly, daily, weekly, monthly and yearly, in order to provide the buyer/customer with an efficient level of performance that is aligned with the buyer/customer’s own infrastructure and personnel capabilities;

    • creating or updating a disaster recovery plan, including but not limited to verification that the appropriate insurance (such as for example: business interruption; data breach; data loss; data recovery; directors’ and officers’ – D&O – errors and omissions – E&O – liability; and the like) is in place, with realistic limits scaled proportionally to the volume of the buyer/customer’s operations;

    • evaluating whether the deployment model for the services to be provided by the CSP meets the buyer/seller’s existing access and information distribution requirements;

    • evaluating whether the service model to be provided by the CSP meets the buyer/seller’s information distribution requirements; identifying the critical data availability, data preservation, data privacy, data redundancy, data security and data seizure controls that may be required from the CSP, due to the sensitive nature of the information to be managed under the CSA;

    • providing alternate protocols to address data breaches to and outages of the CSP’s network;

    • providing for change management notification protocols for key personnel to be employed by the CSP for the work of the CSA;

    • revisiting every existing corporate policy of the buyer/customer that may be in any way applicable to the CSA, and then either authoring new corporate policies for any situation not already specifically addressed in the CSA, or updating any existing corporate policies as may be required;

    • specifying the locations of all servers to be assigned to the CSA, as well as the type of data to be provided to each server in each location (to avoid any violations of laws that may relate to different types of data, such as for example personally-identifiable information – PII – which must be treated with special security protocols when residing in servers located within the European Union – EU – under the General Data Protection Regulation – GDPR and its successor regulations);

    • understanding the buyer/customer’s own internal requirements that must be fulfilled through the CSA;

    • understanding the relationship between the buyer/customer and CSP that is likely to result from the CSA;

    • verifying the expiration and termination provisions of the CSA to assure that the buyer/customer will be able to exit the CSA if necessary upon conditions as favorable to the buyer/customer as favorable as possible, under the circumstances.

​

  • The general standard relating to cloud computing is the International Standardization Organization (ISO)/International  Electrotechnical Commission (IEC) 17789:2014, which specifies the cloud computing reference architecture (CCRA) standards for the basic cloud computing activities, functional components, relationships and roles, as related to the most-common entities in a CSA – the buyer/customer and the CSP – as well as any other entity (sometimes referenced as a “partner”, but in a general sense, and not in the strict legal sense of a partner in a partnership, such as for example: cloud service auditor, which monitors the performance of the CSP in real time, to compare against the relevant metrics in the SLA; cloud service broker; cloud service developer) in any particular CSA arrangement.

 

  • The CSA must clearly specify the details of relevant business-level operating policies, such as for example: activation protocols for granting access to the cloud and access limits for the buyer/customer’s personnel users (perhaps covering such issues as number of simultaneous users, usage durations per discrete session, usage times, and the like); assignability; bonuses in favor of the CSP for achieving better-than-specified metrics; escalation of incidents; guarantees; hardware and software maintenance schedules; licensing (the entire license terms and conditions should be quoted in the CSA itself, rather than by including a URL to the license at some external website, since the content of an external website can be changed surreptitiously at will by the website owner, without prior notice to anyone (such as to the buyer/customer); mandatory modifications; payment terms and conditions; penalties against the CSP for achieving for less-than-specified metrics; protocols that must be followed by the buyer/customer (a/k/a the acceptable use policy – AUP); representations; services not covered under to CSA – which is perhaps the most-difficult to articulate, since it is similar to attempting to prove a negative; voluntary modifications; warranties; what services may be subcontracted by the CSP..

 

  • From the perspective of the buyer/customer, perhaps the most-important business-level operating policy that must be specified in detail somewhere in either the CSA itself or in the associated SLA is the support the CSP will provide to the buyer/customer’s user personnel, either directly (with the CSP’s own personnel) or indirectly, through outsourced support providers subcontracted by the CSP, for which the buyer/customer should insist that the CSP must have direct liability and responsibility, if the CSA gives the CSP the option to use outsourced support service providers; the specifications for such support should be meticulous in detail regarding such factors as for example the level of training and familiarity such support personnel must have in relation to the services the CSP has contracted to provide to the buyer/customer, the maximum time allowed to respond to any support request at any time of the day or night, the technical background and acumen of each such support person, their ability to communicate clearly and succinctly both in writing and verbally, and their proven ability to troubleshoot hardware and software issues; there should be a clearly-delineated chart or table providing in plain English an escalation matrix specifying the allowable response times and factors governing the escalation of various hardware, maintenance and software issues in various priority levels up the support chain of command established by the CSP (whether applicable to the CSP’s own personnel or to the CSP’s outsourced support provider.

 

  • If a CSA is intended to be operational only within a specific country or state, then that must be specified, and every guideline, law, regulation, rule, statute or treaty that may apply to such CSA must be specified by name to the fullest extent possible, so both the buyer/customer and the CSP both have a context in which to audit for compliance; this is critical since different jurisdictions may have vastly different requirements applicable to different types of data, so a mere statement to the effect the all “applicable laws” apply to the CSA would have no objective meaning and consequently, no legal effect; conversely, if the CSA is intended to operate in many domestic and international jurisdictions, or globally, a concerted due diligence effort must be undertaken through the cooperation of both the buyer/customer and the CSP to identify in the CSA every applicable guideline, law, regulation, rule, statute or treaty that may apply to such CSA for compliance purposes, and then perhaps to end with the catch-all phrase at the end of such itemization might be appropriate, since the good-faith effort to identify all applicable guideline, law, regulation, rule, statute or treaty that may apply to such CSA would have been demonstrated.

 

  • Key security considerations for CSA arrangements may include, for example:

    • assessing the sensitivity and security requirements for the applications used to provide the cloud services;

    • auditing (for example, of application performance, cloud performance, inter-cloud performance, peak load performance, problem notification);

    • carefully monitor all security protocols specified in the CSA;

    • establishing restrictions (such as encryption, firewalls and multi-partitioned drives) against unauthorized data migration and accidental disclosure;

    • intellectual property (IP) ownership; requiring the CSP to sign a Health Insurance Portability and Accountability Act (HIPAA) business associate agreement, if any personally-identifiable information (PII) is included in the data to be transmitted pursuant to the CSA;

    • requiring transparency and strict regulatory compliance from the CSP in the CSA, relating to data breaches, suspicious activity and the like;

    • stress testing at the rollout of the cloud services;

    • the amount of training to be provided by the CSP to a specified number of the buyer/customer’s key personnel; understanding the applicable legal and regulatory data residency requirements of the jurisdictions in which the CSA is intended to operate.

 

  • The CSA must also require the CSP to meet regularly with the buyer/customer for a QA/QC review of the CSA efficacy, to discuss issues such as, for example: achieved service levels and any shortcomings thereof; change requests and notifications, from either party; incident reports; KPI analytics and statistics; legal and regulatory compliance; problem reports; service failure reports; user satisfaction feedback.

​

  • CSAs are commonly-used for various service models, such as for example: Infrastructure as a Service (IaaS); Platform as a Service (PaaS); and currently, the most ubiquitous, Software as a Service (SaaS).

 

  • Infrastructure as a Service (IaaS) may seem similar to service level agreements (SLAs) in format; it is often-used for data center outsourcing, hosting, and network services; the metrics (KPIs) for which, pursuant to the CSA, may only be applicable to the CSP’s own intranet or network itself, and may involve high-level performance requirements applied against basic infrastructure service limitations of the CSPs equipment itself; examples of such metrics (KPIs) may be, for example, grouped into the general categories of: computational (including: acceptable length of outages; availability of service; server reboot time); networking (including: availability of service; bandwidth – the maximum amount of data transmitted over an internet connection in a given amount of time; latency – the time it takes for data to be transferred between its original source and its destination, measured in milliseconds – ms;  maximum-mean jitter – meaning the maximum or the average variation in delay for packet transfers between selected routers, measured in nanoseconds – ns; packet loss – which tracks the number of data packets that do not reach their intended destinations within a particular time period); and, storage (including: availability of service; input/output per second; latency; maximum time to restore data; processing speed).

​

  • Several industry groups have attempted to formulate standards to govern the language and meanings of common IaaS CSA terms, such as for example, the: Distributed Management Task Force (DMTF) CIMI (Cloud Infrastructure Management Interface); DMTF OVF (Open Virtualization Format); International Standardization Organization (ISO)/International  Electrotechnical Commission (IEC) JTC 1/SC 38 Working Group 3 on Cloud Computing; Open Grid Forum (OGF) OCCI (Open Cloud Computing Interface); Open Group (OG) SOCCI (Service-Oriented Cloud-Computing Infrastructure); and, Storage Networking Industry Association (SNIA) CDMI (Cloud Data Management Interface).

 

  • Platform as a Service (PaaS) CSAs are generally intended for either of two (2) situations, referenced in the industry as  integrated solutions (web-accessible development environments which enable platform developers to build an application using only the infrastructure and middleware services provided by the CSP, which then manages the resulting application) and deploy-based solutions (which enable the deployment of middleware on top of resources acquired from an IaaS cloud provider, and offer deployment services which automate the process of installation and configuration of such middleware, and is generally a much more flexible environment in which the platform developer can operate).

 

  • The Organization for the Advancement of Structured Information Standards (OASIS) Topology and Orchestration Specification for Cloud Applications (TOSCA) is an example of an attempt to standardize common PaaS CSA terms.

 

  • Software as a Service (SaaS) CSAs are currently-utilized for software distribution in all industries, and may be measured with metrics (KPIs) including for example, application response time, automatic scalability, customer information persistence and monthly cumulative application downtime; SaaS CSAs may be categorized generally in various deployment models: community (shares CSP resources as a closed environment, generally only between organizations with similar purposes, such as with government institutions); hybrid (shares CSP services between public and private clouds depending on their purpose; generally common in high-access enterprise situations; a specific standard should be specified to describe the interface and security requirements); private on-site (similar considerations to the traditional SLA, not shared with the public or any other entity, and offers services over a private internal network typically hosted on-premises, applied to an enterprise); private outsourced (similar to the private on-site, except that the CSP has outsourced the actual cloud services to an offsite external CSP, but such services may still be offered to only one buyer/customer, thus perhaps mitigating some of the security risks; added expense due to the outsourcing of the cloud services by the CSP); or, public (CSP resources are shared with multiple buyer/customers, and offered to the general public, thus requiring increased availability, metrics accuracy, reliability, response time, scalability, security and speed).

​

  • Drafting, negotiation or review of various types of agreements, contracts, documents, forms, guidelines, policies and templates, such as for example: anything-as-a-service (XaaS); cloud services agreement (CSA); infrastructure-as-a-service (IaaS); platform-as-a-service (PaaS); software-as a service (SaaS).

​

    Progress_Page_Last_Updated_220121_2201

bottom of page