SECURECLOUD2012MAY-2012

1

QUantifiable End-to-end SecuriTy for Cloud Trustworthiness

TU Darmstadt, Germany

DEEDS Group

Dr. Jesus Luna G.

SECURECLOUD2012MAY-2012

2

Outline

Why we need to quantify security?

Quantifying security on the IT-chain

Cloud Security Ratings-as-a-Service

Conclusions

SECURECLOUD2012MAY-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.

SECURECLOUD2012MAY-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!

SECURECLOUD2012MAY-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 13th, 2011]

New business models for ISP/SP/CSP based on security levels.

Transparency towards end-users of ICT services.

SECURECLOUD2012MAY-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.

SECURECLOUD2012MAY-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

SECURECLOUD2012MAY-2012

8

Cloud Security Level Agreements

Ordered set of security

ranges per-CID

SECURECLOUD2012MAY-2012

9

Assessment Metrics

SECURECLOUD2012MAY-2012

10

Assessment Metrics

SECURECLOUD2012MAY-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?

SECURECLOUD2012MAY-2012

12

Thanks!

For updated information:

http://www.deeds.informatik.tu-darmstadt.de/QUANTS

/

jluna@deeds.informatik.tu-darmtstadt.de

Twitter: @jlunagar

SECURECLOUD2012MAY-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.

IaaSPaaSSaaS

Service level-Security Requirements,Threat Modeling

Compliance, Data Governance, Facility, Human Resources,

Information, Legal, Operational,...

Cloud SecLA

Cre

atin

g a

Clo

ud S

ecLA

Ass

essi

ng a

Clo

ud S

ecLA Evaluation methodology (e.g.,

REM)

Quantitative Security Levels

Assessment metrics: comparison, benchmarking and compliance.

Quantitative Security Assessment

SECURECLOUD2012MAY-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 00 0 0 01 1 1 11 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:

SecLA(f) SecLA(max)SecLA(CSP)

GSL(CSP,f) GSL(max,CSP)

GSL(max,f)