1. SECURECLOUD2012 MAY-2012 1 QUantifiable End-to-end SecuriTy for Cloud Trustworthiness TU Darmstadt, Germany DEEDS Group Dr. Jesus Luna G.

2. SECURECLOUD2012 MAY-2012 2 Outline  Why we need to quantify security?  Quantifying security on the IT-chain  Cloud Security Ratings-as-a-Service  Conclusions

3. SECURECLOUD2012 MAY-2012 3 Why we need to quantify security? From Metrics to Ratings "If you can not measure it, you can not improve it.“ Lord Kelvin (1824 – 1907)  Metrics (and ratings) are everywhere:  BUT...it is still quite uncommon for ICT providers to specify the “security level” associated with their products and services.  This forbids informed user or customer decisions on the matter.  It is hard to measure security, but it is even harder to quantify security by aggregating the security measurement at all design and usage levels of the system.

4. SECURECLOUD2012 MAY-2012 4 Quantifying security on the IT-chain  But let’s make this a little more complex by introducing the whole IT chain:  There is a conspicuous gap concerning addressing security quantification across an entire IT-chain.  This prevents:  Involved stakeholders from dealing with the security properties of services in a transparent manner.  Competition between Service Providers based on security properties.  And the creation of trustworthy IT ecosystems!

5. SECURECLOUD2012 MAY-2012 5 Potential benefits of end-2-end security metrics  Ease the implementation of regulations such as Art13a (from EU Directive 2009/140/EC) beyond the telecom sector, as advocated by ENISA’s Executive Director Prof. Udo Helbrecht. [Press Release, December 13 th, 2011]  New business models for ISP/SP/CSP based on security levels.  Transparency towards end-users of ICT services.

6. SECURECLOUD2012 MAY-2012 6 What we need to do? (Wish list)  The notion of Security in SLAs (or SecLAs) is essential to enable the quantification of the overall security level of an IT-chain.  Security metrics for every stakeholder on the IT-chain.  Interoperable specifications of SecLAs  Techniques to aggregate, negotiate, predict and compare SecLAs.  Non-intrusive architectures for gathering, storing and analyzing security- related data.  Dashboards to visualize and manage security metrics.  And of course...the empirical validation of the security metrics.

7. SECURECLOUD2012 MAY-2012 7 Introducing: Security Ratings-as-a-Service (SeRaaS)  We’ve started building a prototype to quantitatively evaluate Cloud SecLAs in order to rate CSPs

8. SECURECLOUD2012 MAY-2012 8 Cloud Security Level Agreements Ordered set of security ranges per-CID

9. SECURECLOUD2012 MAY-2012 9 Assessment Metrics

10. SECURECLOUD2012 MAY-2012 10 Assessment Metrics

11. SECURECLOUD2012 MAY-2012 11 Conclusions  Academia and Industry need to work together on creating the appropriate ICT security metrics, rating systems and associated frameworks.  Measuring security in Cloud computing has several challenges e.g., associated with their elasticity and multi-tenancy features.  Therefore, initiatives like the CAMM, CSA’s STAR and its Security Metrics WG are excellent starting points.  Motivate the use of Security Level Agreements!  Open Issues:  Do we need Rating Agencies for IT Security?  Economic-driven security metrics – no enough information out there.  Interested on collaborating?

12. SECURECLOUD2012 MAY-2012 12 Thanks! For updated information: http://www.deeds.informatik.tu- darmstadt.de/QUANTS/ jluna@deeds.informatik.tu-darmtstadt.de Twitter: @jlunagar

13. SECURECLOUD2012 MAY-2012 13 Our contribution  We’ve started working on mechanisms to quantitatively assess the security of a CSP’s SecLA (paper submitted to scientific conference).  An initial case study has been created, using SecLAs derived from the “Consensus Assessments Initiative Questionnaire (CAIQ)” stored in the STAR repository of the CSA.

14. SECURECLOUD2012 MAY-2012 14 Evaluation Methodology  We’re using a technique from previous works (used to quantify a PKI’s Certification Policy). The input is the SecLA, and the output is a number representing its security level.  This technique (called Reference Evaluation Methodology –REM-) does in a glimpse: 1.For each CID creates a set of security ranges (SecLA Template): IS-01.Q1={Not Specified, Customer, NDA, NDA+Justification} 2.Each CID in the Template is represented by a vector with eg. 4 possible values: IS-01.Q1={0,0,0,0} 3.So, if a specific CSP has IS-01.Q1={Customer} then will be represented by: IS-01.Q1={1,1,0,0} 4.Therefore the set of CIDs representing the CSP’s SecLA will become a (N x 4) matrix like the following: 1 1 0 0 0 0 1 1 1 0 0 0 5.Finally, the “Global Security Level –GSL-” associated with a SecLA is obtained by computing the Euclidean Distance to an “origin matrix” (all rows set to (0 0 0 0)). Graphically: