Cloud Security: Yesterday, Today, and Tomorrowarctecgroup.net/pdf/YesterdayTodayTomorrow.pdf · ©2005-9 Arctec Group Cloud Security: Yesterday, Today, and Tomorrow Presentation by

©2005-9 Arctec Group

Cloud Security: Yesterday, Today, and Tomorrow

Presentation by Gunnar Peterson www.arctecgroup.net

©2005-9 Arctec Group

“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

©2005-9 Arctec Group

www.rationalsurvivability.com

©2005-9 Arctec Group

©2005-9 Arctec Group

©2005-9 Arctec Group

©2005-9 Arctec Group

©2005-9 Arctec Group

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

©2005-9 Arctec Group

Threat   Security  Service   Data   Method   Channel  

Spoofing   Authen;ca;on  

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  

Spoofing   Authen;ca;on  

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

©2005-9 Arctec Group

…but what kind of security services should we build?

©2005-9 Arctec Group

What we have is a design problem

©2005-9 Arctec Group

..its not just that we need stronger mechanisms

©2005-9 Arctec Group

©2005-9 Arctec Group

…they must be USEFUL by people

©2005-9 Arctec Group

©2005-9 Arctec Group

©2005-9 Arctec Group

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

Gateway: defensive structure to limit attack surface & enforce policy

©2005-9 Arctec Group

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

Monitor: records and publishes auditable events

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

©2005-9 Arctec Group

STS: Issue, validate, & exchange security tokens

©2005-9 Arctec Group

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

©2005-9 Arctec Group

•  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

©2005-9 Arctec Group

•  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

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

Cloud Security is not about trust. Its about

Verification Visibility

Thingfrastructure

©2005-9 Arctec Group

Thingfrastructure

©2005-9 Arctec Group

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

©2005-9 Arctec Group

©2005-9 Arctec Group

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

•  Blog: http://1raindrop.typepad.com •  Web: http://www.arctecgroup.net •  Email: gunnar@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”