The Codex of Business Writing Software for Real-World Solutions 2.pptx
Cloud computing & service level agreements
1. Computing in the clouds while
wearing a good service level
agreement
By
Cade Zvavanjanja
CISO
Gainful Information Security
2. THE
CLOUD
“Cloud Computing” can
mean different things
SaaS, PaaS, IaaS
Public Definitions:
NIST
Berkeley
ABA Legal Tech
Resource Center
Service & Deployment
Models:
Private, Public, Hybrid
6. CLOUD:
WHEN BAD THINGS HAPPEN TO GOOD
EVIDENCE
General Considerations
Potential Liability for
Spoliation
Minimize Risk by
Addressing Up Front
the Need to Preserve
and Produce ESI
Remedies for Spoliation
7. HOW DO YOU CONDUCT A
FORENSIC EXAMINATION IN
THE CLOUD?
8. CLOUD COMPUTING
SERVICE LEVEL AGREEMENT
CONSIDERATIONS
Use of data/Security
Location of data
No change of terms
Destruction
Ownership
(assignment)
Subpoena response
Regulatory
requirements
Insurance/Indemnity
Audits
9. SERVICE LEVEL AGREEMENT
(SLA)
SLA should contain:
The list of services the provider will deliver and a complete definition
of each service.
Metrics to determine whether the provider is delivering the service
as promised
Auditing mechanism to monitor the service.
Responsibilities of the provider and the consumer
Remedies available to both provider and client if the terms of the
SLA are not met.
A description of how the SLA will change over time.
10. SERVICE LEVEL AGREEMENT
(SLA)
Security: Client and CSP must understand security requirements.
Data encryption: Data must be encrypted while it is in motion and while it is at
rest. The details of the encryption algorithms and access control policies should
be specified.
Privacy: Basic privacy concerns are addressed by requirements such as data
encryption, retention, and deletion. An SLA should make it clear how the cloud
provider isolates data and applications in a multi-tenant environment.
Data retention/deletion: How does CSP prove they comply with retention laws
and deletion policies?
Hardware erasure/ destruction: Same as #4.
Regulatory compliance: If regulations must be enforced because of the type of
data, CSP must be able to prove compliance.
Transparency: For critical data and applications CSP must be proactive in
notifying client when the terms of the SLA are breached including infrastructure
issues like outages and performance problems as well as security incidents.
11. (SLA)
Certification: CSP should be responsible for proving required certification
and keeping it current.
Performance definitions: Defining terminology such as uptime and other
contractual metric terms (i.e. – uptime could mean all servers on continent
are available or only one designated server is available.)
Monitoring: Responsible party for monitoring including identification of any
third-party organization designated to monitor performance of the provider.
Audit Rights: To monitor for any data breaches including loss of data and
availability issues. SLA should clarify when and how the audits will take
place.
Metrics: to be monitored in real-time and audited after occurence. Metrics of
an SLA must be objectively and unambiguously defined.
Human interaction: On-demand self-service is one of the basic
characteristics of cloud computing, but SLA should provide customer
service when needed.
Review and summary of cloud service level agreements, From "Cloud Computing Use Cases
Whitepaper" Version 4.0,
12. REALITY – CONTRACT ISSUE
Currently, the standard contracts offered by cloud
computing providers are one-sided and service
provider-friendly, with little opportunity to change
terms.
Few offer meaningful service levels or assume any
responsibility for legal compliance, security or data
protection. Many permit suspension of service or
unilateral termination, and disclaim all or most of the
provider's potential liability.
In addition, some cloud computing providers
emphasize low cost offerings, which leave little room
for robust contractual commitments or customer
requirements.
13. BEFORE YOU GO “TO THE
CLOUD!”
Security & Control
No uniform standard for security and compliance
among cloud providers. This may be bad - if you
have evolved mature security and control discipline;
or it may be a good thing, if you are looking for an
external provider to help you with best practices.
Cloud is not, per se, either secure or insecure. You
simply need to set your own standards, be aware of
what your cloud provider can and cannot deliver,
and choose according to your desired level of risk.
14. BEFORE YOU GO “TO THE
CLOUD!”
Por tability & Compatibility
Not all cloud providers are able to provide the same
level of portability and compatibility.
Extractingand restoring data may be a slow manual
process due to API limitations and other restrictions.
May be impossible to accomplish in a timely manner
due to common limitations such as bandwidth.
Applications may require significant changes to be
compatible with storage in a non-specific location that
changes in case of emergency.
Be aware of your use cases, and make sure your
recovery plan allows for the mobility of data the cloud
will enable.
15. BEFORE YOU GO “TO THE
CLOUD!”
Longevity & Accessibility
Consider and verify the longevity of CSP
to ensure data will be accessible when and
how, needed before committing to CSP as
sole source for data recovery.
During an analyst keynote speech at the
2010 CA InfoXchange event in Malaysia,
the speaker estimated that a substantial
number of current cloud providers will be
out of business within 2 years.
CSPs talked about 99.999 per cent
uptime, or the equivalent of five minutes'
downtime per year. This is the Holy Grail of
cloud computing but achieving it requires
multi million-dollar investments in redundant
infrastructure.
16. BEFORE YOU GO “TO THE
CLOUD!”
Where does your data reside?
EU Data Privacy Concerns
Which laws apply, country of origin or country
where data resides?
17. ESSENTIAL POWER CONTRACTS TO RETAIN
Realtime feed from data intrusion detection systems to permit
monitoring of the security systems performance.
Performance standards mandating maximum downtime and
platform stability.
Auditing rights – access to monitoring dashboard to see metrics
on function of the system. Also onsite visits to provider.
Remediation power – including monetary penalties for downtime,
termination in the event of security violations and notice of any
breach.
18. ESSENTIAL CONTRACT POWERS TO
RETAIN
Freedom to Move – contract must make it clear that the data
owner retains all ownership of the data as well as access to
the data. There should be a defined time frame for giving
back all the data once request has been made as well as
definition of the format for the data if it is to be moved or
returned to the client to avoid any additional cost to reformat
data to be moved to a new provider.
Preservation of metadata – what metadata will be maintained
and any impact of the system upon that metadata.
Access to information for e-discovery – how accessible the
data will be including time to extract.