QUantifiable End-to-end SecuriTy
for Cloud Trustworthiness
TU Darmstadt, Germany
DEEDS Group
Dr. Jesus Luna G.
SECURECLOUD2012
MAY-2012
1
Outline
 Why we need to quantify security?
 Quantifying security on the IT-chain
 Cloud Security Ratings-as-a-Service
 Conclusions
SECURECLOUD2012
MAY-2012
2
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.
SECURECLOUD2012
MAY-2012
3
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!
SECURECLOUD2012
MAY-2012
4
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.
SECURECLOUD2012
MAY-2012
5
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 securityrelated data.
 Dashboards to visualize and manage security metrics.
 And of course...the empirical validation of the security metrics.




SECURECLOUD2012
MAY-2012
6
Introducing: Security Ratings-as-a-Service (SeRaaS)
 We’ve started building a prototype to quantitatively evaluate Cloud
SecLAs in order to rate CSPs
SECURECLOUD2012
MAY-2012
7
Cloud Security Level Agreements
Ordered set of
security ranges
per-CID
SECURECLOUD2012
MAY-2012
8
Assessment Metrics
SECURECLOUD2012
MAY-2012
9
Assessment Metrics
SECURECLOUD2012
MAY-2012
10
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?
SECURECLOUD2012
MAY-2012
11
Thanks!
For updated information:
http://www.deeds.informatik.tudarmstadt.de/QUANTS/
jluna@deeds.informatik.tu-darmtstadt.de
Twitter: @jlunagar
SECURECLOUD2012
MAY-2012
12
 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.
SECURECLOUD2012
MAY-2012
13
IaaS
PaaS
SaaS
Service levelSecurity Requirements,
Threat Modeling
Compliance, Data Governance,
Facility, Human Resources,
Information, Legal, Operational,...
Cloud SecLA
Assessing a Cloud SecLA
 We’ve started working on
mechanisms to quantitatively
assess the security of a CSP’s
SecLA (paper submitted to scientific
conference).
Creating a Cloud SecLA
Our contribution
Evaluation methodology (e.g.,
REM)
Quantitative Security
Levels
Assessment metrics: comparison,
benchmarking and compliance.
Quantitative Security
Assessment
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.
2.
3.
4.
5.
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:
1100
0000
1111
1000
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:
GSL(max,f)
GSL(CSP,f)
SecLA(f)
SECURECLOUD2012
MAY-2012
GSL(max,CSP)
SecLA(CSP)
14
SecLA(max)