cloud security: yesterday, today, and tomorrowarctecgroup.net/pdf/yesterdaytodaytomorrow.pdf ·...

©2005-9 Arctec Group

Cloud Security: Yesterday, Today, and Tomorrow

Presentation by Gunnar Peterson www.arctecgroup.net


“Everything we think of as a computer today is really just a device that connects to the big computer that we are all collec;vely building”

Cloudanatomy


www.rationalsurvivability.com

STRIDE Threat Model Examples Threat Descrip-on Example

Spoofing Assume iden;ty of client, server or request/response

Phishing aDack to fool user into sending creden;als to fake site

Tampering Alter contents of request of response

Message or data integrity compromised to change parameters or values

Repudia;on Dispute legi;mate transac;on Illegi;mately claiming a transac;on was not completed

Informa;on Disclosure Unauthorized release of data Unencrypted message sniffed off the network

Denial of Service Service not available to authorized users

System flooded by requests un;l web server fails

Eleva;on of privilege Bypass authoriza;on system ADacker changes group membership

Threat Security Service

Spoofing Authen;ca;on

Tampering Digital Signature, Hash

Repudia;on Audit Logging

Informa;on Disclosure Encryp;on

Denial of Service Availability

Eleva;on of privilege Authoriza;on

Threat Model + Countermeasure Examples

Attack Surface

•  Describes the locations an attacker can launch, propagate and detonate an attack – Attack Surface = Data + Method + Channel – Example Web Service Attack Surface

•  Data: XML •  Method: SOAP, URI •  Channel: HTTP


Threat Security Service Data Method Channel


Tampering Digital Signature

Repudiation Audit Logging

Informa;on Disclosure

Encryp;on

Denial of Service

Availability

Eleva;on of privilege

Authoriza;on, Input valida;on

Threat Model + Attack Surface

Threat Security Service Data Method Channel


Tampering Digital Signature

Repudiation Audit Logging

Informa;on Disclosure

Encryp;on SSL

Denial of Service

Availability

Eleva;on of privilege

Authoriza;on, Input valida;on

Threat Model + Attack Surface


…but what kind of security services should we build?


What we have is a design problem


..its not just that we need stronger mechanisms


…they must be USEFUL by people

Gateway: defensive structure to limit attack surface & enforce policy

Monitor: records and publishes auditable events

STS: Issue, validate, & exchange security tokens

PEP/PDP: create, manage, & enforce policy


Partial overview of J2EE support in WAS – great functionality also mucho attack surface

J2EE 1.4 specifications Java Servlet Specification 2.4 JavaServer Pages Specification 2.0 Enterprise JavaBeans Specification 2.1 Enterprise JavaBeans to CORBA Mapping 1.1 RMI over IIOPJava IDL APIWeb Services for J2EE, Version 1.1SOAP with Attachments API for Java Specification 1.2 Java API for XML Processing Specification 1.2 Java API for XML Registries Specification 1.0 Java API for XML-based RPC Specification 1.1JDBC Specifications, 3.0, 2.1, and Optional Package API (2.0) Java Connector Architecture (JCA) 1.5 Java Message Service Specification 1.1 JavaMail API Specification 1.3 Java Authorization Contract for Containers 1.0 Java Naming and Directory Interface Specification 1.2.1 Java Transaction API Specification 1.0.1B Java Transaction Service Specification 1.0 JavaBeans Activation Framework Specification 1.0.2

Basic Audit Log Event Model

•  Who? Who was involved? –  Example: Username , identity provider

•  What? What happened? –  Example: Event status, object, transactions

•  Where? Where did it take place? –  Example: System, application or component

•  When? When did it take place? –  Example: Timestamp + time zone

•  Why? Why did it happen? –  Example: Reason event happened

•  How? How did it happen? –  Example: Action taken

(see IEEE Security & Privacy Journal – “How to Application Logging Right”, Anton Chuvakin & Gunnar Peterson



•  User STS –  Responsibilities:

–  Map user to set of verifiable claims –  Select identity to authenticate –  Select identity and/or attribute claims to release –  Enable usability of security protocols –  Optionally enable multi-factor authN –  Optionally, provider anonymizers and pseudonymizers

–  Collaborations: The user STS collaborates with –  Identity Provider for authentication –  Attribute stores –  Required security protocols – 2 factor, etc. –  Work in user environment with usability-centric tooling – e.g. Mobile

device, Azigo, Cardspace, browser plugins, et. Al.


•  IdP STS –  Responsibilities:

•  Subject > claim mapping •  Map requests and responses to token(s) based on policy •  Route and transform requests and responses based on policy •  Policy based payload access

–  Collaborations: •  User stores •  Directories •  Multi-factor


•  SP STS –  Responsibilities:

•  Object/resource > claim mapping •  Mapping requests and responses to token(s) based on policy •  Route and transform requests and responses based on policy •  Policy based payload access

–  Collaborations: •  Objects under management, e.g. JNDI trees, JDBC connections,

databases, Web Service methods, et. Al.

PEP/PDP: Push and pull authorizations on cloud-separated subjects and objects

Dynamically bind to make context-aware authorization decisions, embed access control rules in an object that is occassionally connected such as mobile




PEP/PDP: create, manage, & enforce policy

Cloud Security is not about trust. Its about

Verification Visibility

Thingfrastructure


Thingfrastructure


Timo Arnall Wireless in the world http://vimeo.com/12187317

Thingfrastructure

•  Trends – Scale – Getting smaller all the time – Geolocation drives privacy issues – Used to worry about monoculture and cascade

fail, now we have complexity due vendor-specific heterogeneity.

– Thingfrastructure will drive changes down through the Infostructure, Metastructure and Infrastructure



•  …”let’s collectively build security in” – Gunnar Peterson

•  Blog: http://1raindrop.typepad.com •  Web: http://www.arctecgroup.net •  Email: [email protected]

“Everything we think of as a computer today is really just a device that connects to the big computer that we are all collec;vely building”

cloud security: yesterday, today, and tomorrowarctecgroup.net/pdf/yesterdaytodaytomorrow.pdf ·...

Documents