Post on 05-Mar-2018
©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”