1 / 14

QU antifiable E nd-to-end S ecuri T y for Cloud Trustworthiness

QU antifiable E nd-to-end S ecuri T y for Cloud Trustworthiness. TU Darmstadt, Germany DEEDS Group Dr. Jesus Luna G. Outline. Why we need to quantify security? Quantifying security on the IT-chain Cloud Security Ratings-as-a-Service Conclusions.

talisa
Télécharger la présentation

QU antifiable E nd-to-end S ecuri T y for Cloud Trustworthiness

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  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. 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. 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 13th, 2011] • New business models for ISP/SP/CSP based on security levels. • Transparency towards end-users of ICT services.

  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. Introducing: Security Ratings-as-a-Service (SeRaaS) • We’ve started building a prototype to quantitatively evaluate Cloud SecLAs in order to rate CSPs

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

  9. Assessment Metrics

  10. Assessment Metrics

  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. Thanks! For updated information: http://www.deeds.informatik.tu-darmstadt.de/QUANTS/ jluna@deeds.informatik.tu-darmtstadt.de Twitter: @jlunagar

  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. 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: • For each CID creates a set of security ranges (SecLA Template): IS-01.Q1={Not Specified, Customer, NDA, NDA+Justification} • Each CID in the Template is represented by a vector with eg. 4 possible values: IS-01.Q1={0,0,0,0} • So, if a specific CSP has IS-01.Q1={Customer} then will be represented by: IS-01.Q1={1,1,0,0} • 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 0 0 1 1 1 1 1 0 0 0 • 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:

More Related