Cloud Security: una "real world due diligence" Case study 19 Marzo 2015
Disclaimer The present original document was produced by CEFRIEL for the benefit and internal use of this course, and nobody else may claim any right or paternity on it. No right to use the document for any purpose other than the intended purpose and no right to distribute, disclose, release, furnish or disseminate it or a part of it in any way or form to anyone without the prior express written consent of CEFRIEL. Copyright CEFRIEL 2015. All rights reserved in accordance with rule of law and international agreements. 2
WHO AM I? Raoul Brenna Head of Information Security Practice @ CEFRIEL raoul.brenna @ cefriel.com http://www.cefriel.com
Agenda Cloud e sicurezza: un po' di contesto Ma sono cose note! Però nella pratica Case study: una "real word due diligence" Conclusioni 4
Quali problemi nell'uso del Cloud? I temi di sicurezza sono quelli maggiormente rilevati (percezione) Viene identificata anche una potenziale perdita di controllo 5
Una riflessione: è ragionevole chiedere? Ma quanto si vuole pagare per il cloud? E per ottenere cosa? Se si applica il "solito" razionale (security spending = 5% IT spending) 5% del 5%? 7
D'altra parte Il rischio esiste davvero E' implicitamente legato al modello http://rischioblog.blogspot.it/2010/09/usa-dipendente-digoogle-licenziato-per.html http://www.computerweekly.com/news/2240219265/cyberattacks-move-to-cloud-with-adoption-report-shows 8
E anche i CP sentono "pressione" Un problema concreto! http://www.gizmodo.it/2013/11/30/google-ha-minacciato-di-lasciare-gliusa-a-causa-dellnsa.html Ma se il cliente non è "US"? 9
Rischi ben noti European Network and Information Security Agency (ENISA) ha realizzato una possibile Risk Analisys per i servizi di Cloud Computing Conformità (R.3) Mancato rispetto di normative Impossibile rispettare regolamenti di settore (es. PCI) Mancato isolamento (R.9) Perdita di dati di valore o sensibili Cambio di giurisdizione (R.22) Mancato rispetto di normative Divulgazione forzata o sequestro di dati Gestione della rete (R.26) Intercettazione dati Sottrazione credenziali 10
Ma come controllare? 1 2 3 4 5 6 7 Data breaches Data loss Account or service traffic hijacking Insecure interfaces and APIs Denial of Service Malicious insiders Abuse of cloud services 78 Insufficient due diligence 9 Shared technology vulnerabilities 11
Insufficient due diligence Le organizzazioni che si spostano verso soluzioni cloud devono disporre di risorse capaci ed eseguire una approfondita ed ampia «due diligence» per comprendere i rischi Entrare nel cloud può generare problemi contrattuali con i fornitori su aspetti di responsabilità e trasparenza 12
Una nota curiosa Governo CC Standard e metodologie Controlli sicurezza SLA Availability (99.xxx?) Performance (max resp time?) Security / privacy of the data (encryption rest/motion?) Disaster Recovery expectations (worst case?) Location of the data (compliance?) Access to the data Portability of the data Process to identify problems and resolution expectations Change Management process Dispute mediation process Exit Strategy 13
CASE STUDY
Il framework Elementi "cross-cutting" basati su ISO 17788/89 Processi e capability che devono essere messi in campo in modo dimostrabile da un CP Ogni contratto di servizi cloud dovrebbe considerarli (NON sono tutti legati a InfoSec) 15
L'analisi Un'analisi complessa Anche su aspetti "operational", out of scope rispetto a questa presentazione 16
Il posizionamento globale Risultati di una valutazione semi-quantitativa CROSS CUTTING ASPECTS Service Level Agreement Security Reversibility Auditability 5 4 3 2 1 0 Availability Governance Interoperability Index scale: 5 Aspect treated at a complete and comprehensive level 4 Aspect fully treated, with some minor clarifications to be asked 3 Aspect treated, but misses some information Resiliency Maintenance 2 Aspect partially treated, misses relevant information 1 Aspect not treated Protection of PII Performance Portability 17
Security Gli aspetti generali di InfoSecurity non vengono citati nella service description Sono in realtà ben descritti in whitepaper a corredo dell'offerta, ma No service description = (potenzialmente) no obbligo di erogare "security"!!! Sto estremizzando fino a un certo punto! Element Contract reference Coverage Comments Proposed Requests for the CSP Security Web site PARTIAL The CSP does mention their security practices in a white paper available in their website. No mention of it is in the SD. Provide a detailed description of the security measures and control put in field to ensure protection of the cloud services in perimeter, with particular attention to: Physical and logical security of the datacenter and infrastructure Security responsibilities External audits and security checks Richiesto al CP l'invio di informazioni puntuali su aspetti interni e di relazione/governance. Specificando bene come il WP si applica a quanto effettivamente in perimetro 18
Auditability Apparentemente, presenza di certificazioni che attestano la bontà dei sistemi, dei servizi e dei processi ISO27001 and SSAE16 Element Contract reference Coverage Comments Proposed Requests for the CSP Auditability N/A (no mention in the contract) http://www.***.com/cl oudiaas/compl iancecertificatio ns PARTIAL There is no indication in the contractual documents about the availability of the CSP to either provide independent audit information covering their infrastructures or support audit activities conducted by the client s trusted auditors. However, the Provider web site declares the presence of ISO27001 and SSAE16 certifications for some of the datacenters and services. The provider should clearly indicate in the service description which security certifications apply to the service perimeter within the contract. Certificazioni certamente interessanti. Ma se il cliente volesse condurre un'ispezione? Non è un caso "ammesso" (o è omesso) Inoltre, ricordiamoci: "certifications for some of the datacenters and services" 19
SLA /1 Approccio "lasco" Copertura del SOLO servizio core No VM = Ti risarcisco con altro tempo VM SLA Area Referen ces Coverage Notes Rquests for the CSP SLA overall structure Penalties and liquidated damages Whole SD PARTIAL SLAs are covered in different parts of the document. We suggest asking for a more organized and self-contained section listing out all the SLAs and thresholds and the related penalty/service credit. Some SLAs in the SD B1.2 table are not clear. The SD is missing a clear indication on how the various SLA KPIS are actually measured (e.g. what is the source of information) SLA measurement will start 30 days from the service start date No SLA in service desk availability (e.g. call answer time or missed calls) SD 3.2 PARTIAL Only VM availability SLA is covered with a service credit mechanism The rest of the SLAs are shown (SD B1.2), but no penalties whatsoever are specified. Summarize ALL service levels mentioned in the document and any other required by [Client] in a single section, along with their associated service credit or penalty In generale, poca chiarezza sugli SLA, e disomogeneità sulle diverse aree Altri SLA specificati, ma senza penali! Quanto si impegneranno per rispettarli? 20
SLA /2 Anche nello specifico SLA Area Incident management Problem management Referen ces Coverage Notes Rquests for the CSP SD 8 SD 8 PARTIAL PARTIAL As for other indicators, KPIs and thresholds are specified, but no penalties are associated with them (and hence no commitment is actually taken). Some SLAs for change management or scheduled maintenances are mentioned in the «definitions» section (not the appropriate position) Summarize ALL service levels mentioned in the document in a single table, along with their associated service credit Please, verify that ANY indication about service levels, notification times, service thresholds, commitments, etc are all contained in a single chapter with a clear indication of their KPI, threshold, measurement tools and service credit in case of breach Soffermandoci su aspetti maggiormente legati alla InfoSecurity Si conferma l'impostazione generale ("no penalties, hence no commitment") Tralasciando poi aspetti formali (ma sostanziali, quando poi ci si scontra con il caso concreto di breach) 21
Rispetto della PI/Protezione Dato /1 Dall'analisi degli aspetti contrattuali, oltre che della SD: Emergono punti di attenzione sui temi della protezione e del "trattamento" del dato MSA Article Element key aspects for [Client] 5 Customer Obligations [Client] contents license (5.3) Ma più in generale, da valutare il tema della protezione dell'accesso all'informazione del Cliente. Processi e tecnologie It must be explicited that the Supplier may not access the contents in any way. It should be verified whether the data is encrypted 6 Data Protection We need to make explicit that the italian law and the provisions of the «Garante per la protezione dei dati personali italiano» applies to the services in perimeter of the contract 6 Data Protection (6.1) We need to ask for the appointment of «data processor» 6 Data Protection (6.1.b - 6.2) It is impossible to accept a clause that implicitly allows the provider to transfer data outside the EU. This is against the Italian law. 6 Data Protection (6.1.d) We need to have a document explaining all the deployed security measures. Molti temi legati alla "Data Privacy" (atteso è un provider US-based) 22
Rispetto della PI/Protezione Dato /2 Il tema della compliance rispetto alla Data Privacy ha richiesto molti approfondimenti 23
In conclusione L'esperienza pratica mette in luce carenze Una due diligence "ben fatta" può prevenire problemi peggiori Ed in particolare aspetti "securityrelated" Out of scope Peccato.. ;-) 24
Altrimenti ;-) Libero adattamento da http://xkcd.com/908/ 25
THANK YOU! Raoul Brenna Head of Information Security Practice @ CEFRIEL raoul.brenna @ cefriel.com http://www.cefriel.com