-
Security
Security a fundamental issue in the cloud and in web services.
- Two related lectures:-
- Cloud Security Alliance, OAuth, OpenID
- Security Technology, TLS, HTTPS
- Overview
- Cloud Security Alliance (CSA)
- CSA 2016 Top Threats
- CAIQ, CCM, and STAR
- OAuth 2.0 for RESTful Web Services
- Identity with OpenID Connect
- OAuth and OpenID in the cloud
- Security in SOAP using the WS-I security profiles
-
Cloud Security Alliance (CSA)
A non-profit organization that promotes research into and use of best practices for providing security assurance within cloud computing.
AWS and Microsoft etc. members
- Periodically identifies, collates and ranks the cloud computing industry’s top security concerns and threats.
- discussed over next few slides
- latest assessment was in 2016
Also provides certification, identification of best practices to address these security concerns and threats etc.
We will use their concepts to cover basic ideas of cloud security.
-
“The Treacherous 12” – Top Threats
CSA’s ranked top cloud computing threats/security concerns in 2016 (latest).
- Threat #1: 📷 Data Breaches
- Threat #2: 📷 Weak Identity, Credential and Access Management
- Threat #3: 📷 Insecure APIs
- Threat #4: 📷 System and Application Vulnerabilities
- Threat #5: 📷 Account Hijacking
- Threat #6: 📷 Malicious Insiders
- Threat #7: 📷 Advanced Persistent Threats (APTs)
- Threat #8: 📷 Data Loss
- Threat #9: 📷 Insufficient Due Diligence
- Threat #10: 📷 Abuse and Nefarious Use of Cloud Services
- Threat #11: 📷 Denial of Service
- Threat #12: 📷 Shared Technology Issues
X
X
X
X
X
X
X
X
X
X
X
X
-
CSA – What’s important?
- Security Guidance for Critical Areas of Focus in Cloud Computing
- overview document of best security practice
- as referenced in the previous threat slides
- 🔗 https://cloudsecurityalliance.org/download/security-guidance-for-critical-areas-of-focus-in-cloud-computing-v3
- Consensus Assessments Initiative Questionnaire (CAIQ)
- pronounced “cake”
- set of 140 questions auditors or potential customers should ask a cloud service provider in order to assess their security compliance before agreeing to use them
- 🔗 https://cloudsecurityalliance.org/group/consensus-assessments
- Cloud Controls Matrix (CCM)
- a detailed list of requirements and controls across 16 domains
- references many other security standards
- what has (not) been implemented by a provider helps customers assess overall security risks
- also lists fundamental best-practice security principles to guide cloud provider
- 🔗 https://cloudsecurityalliance.org/group/cloud-controls-matrix/
CSA Security, Trust & Assurance Registry (STAR)
CSA & BSI initiative ongoing since 2013.
🔗 https://cloudsecurityalliance.org/star/#_overview
Public web-based register of compliance self-assessments and audits.
🔗 https://cloudsecurityalliance.org/star/#_registry
Different levels of process available with increasing rigour from self-assessment through 3rd-party certification in different application areas to continuous certification.
self-assessment most likely
Uses the CAIQ and CCM
CSA STAR Self-Assessment
Providers either submit a completed CAIQ themselves or submit a report documenting compliance with the CCM.
CSA only undertake a basic check of factual accuracy
Most industry cloud providers have entries spanning IaaS, PaaS and SaaS offerings.
Entries deleted unless maintained after 18 months.
- A good example is MS Office 365 (SaaS) compliance documentation.
- this goes through in detail how Office 365 addresses the relevant control entries in the CCM to convince potential customers ...
- last updated April 2016
-
OAuth 2.0
Open source – rfc6749
- A federated, delegated mechanism to integrate secure RESTful services.
- intended to be lightweight
- Facebook, Twitter, Google, GitHub, DropBox, SoundCloud, MS...
- Popular also for use with cloud platforms.
- e.g. MS Azure, AWS
- because they increasingly provide RESTful APIs to access cloud resources
- OAuth is an authorization protocol that allows third-party web service creators to get access to users' data stored in a different web service.
- however it is generalised enough to be used also with browser-based apps and mobile apps in several defined scenarios (flows)
- these notes consider web services only (“web server flow”)
OAuth is about granting and gaining permission to access resources i.e. authorization.
not in itself about authentication
- With OAuth, users don’t manage access to their resources themselves nor divulge their login information to intermediaries:-
- authorization is granted from an authorization server, where access rights to owner’s resources are stored
- authorization granted as an one-time opaque authorization token/code
- an intermediary subsequently obtains a time limited access token that is used to access data from a resource server
Reliant on HTTPS to secure some functionality.
uses custom token authentication (Bearer) and Schannel
OAuth 2.0 for RESTful Web Services
Four entities:
User Agent
typically a browser (but of course could be anything...)
Client App (Web Service)
web service the user is calling which acts as a client to the resource server
- Resource Server
- 3rd party secure web service
- what we need to obtain permission to use
- Authorization Server
- deals with access requests from users
- may be combined with resource server in some implementations
Uses redirect URLs (response code 302),
Redirect URLs are protected by HTTPS which prevents tokens being intercepted in transit.
- The granting of a specific access token allows a fine grained decision about access to data to be made.
- e.g. it may only permit read-only access for this user and/or client
- client submits authorization token to obtain access token
- Users, clients and resource servers require to be registered with the authorization server.
- remember resource and authorization services may be combined
- client redirect URL registered to avoid malicious redirects
- users must be authenticated against the authorization server but OAuth does not specify how
-
OpenID Connect
- For authentication OAuth can add the use of:-
- Microsoft IDs
- SAML assertions (enterprise tokens confirming you are who you are)
- your own scheme...
- or use OpenID to extend OAuth for use as an authentication protocol
- OpenID Connect is a distributed, federated third party identity service.
- a single-sign-on (SSO) protocol
- OpenID providers
- Google, Facebook, Google, PayPal, Yahoo!
- Cloud: MS Azure Active Directory (Azure AD) and AWS Identity and Access Management
- web apps no longer manage authentication themselves
- service does not see client secret (password, biometric data...) – sees token instead
- Microsoft IDs are not unified (yet) with OpenID...
- currently you create a separate user space in Azure AD
- but MS have started to unify the API & tool support
OpenID Connect is current version.
- The key to understanding OpenID is to realise OpenID itself uses OAuth flows to obtain authentication tokens from an OpenID provider.
- human users are redirected to OpenID provider to log in
- tokens are subsequently presented to 3rd parties to prove authentication has taken place
- see: 🔗 http://cakebaker.42dh.com/2008/04/01/openid-versus-oauth-from-the-users-perspective/
- ID tokens - again uses Bearer tokens in HTTP(S) custom authentication
- as it uses OAuth...
- See also: 🔗 http://connect2id.com/learn/openid-connect
OAuth and OpenID in the Cloud
A big reliance now on RESTful web services hosted in the cloud which must be secure.
Access to cloud storage through URLs must be secure.
- Both OAuth and OpenID have a big presence in the cloud.
- Azure AD and AWS Identity and Access Management both heavily use them and both are offered as services and kept up to date by them
- AWS have internal policy that every service must be available as a RESTful service and even internal access to services uses OAuth/OpenID
AWS and Azure AD both support creation and hosting of OpenID Connect identity providers in the cloud.
-
Protecting SOAP Messages
- Security threats to a SOAP message:-
- a message could be read by an attacker
- a message could be modified by an attacker
- a message could be sent by an attacker
A set of profiles but WS-Security is the core one.
- WS-Security provides an example of message security.
- SOAP implementations use other protocols than just HTTP so we need to apply security to the message itself and not only at the transport layer.
- HTTPS/TLS can only be used for securing point-to-point services
- consider the use of message queues – now lots more point-to-point communication
See overview:- 🔗 https://msdn.microsoft.com/en-us/library/ms977327.aspx
To address the previous slide’s threats, WS-Security applies a combination of:-
Encryption
(Ensure the confidentiality of the message)Signatures
(Verify the origin and the integrity of a message)Security tokens
(Authenticate the sender on the credentials associated with the message)Messages with invalid signatures and incorrect or missing tokens are rejected.
WS-Security is the core security profile defining secure SOAP envelopes - others profiles use this