CCSK Study: Domain 12 - Identity, Entitlement, & Access Management

Notes

• Concepts behind IdEA require fundamental changes when moving to cloud solutions
• Traditional deployments of servers with a standard directory service do not scale well or provide the necessary features
• Key Terms
• Identity
• The means by which an Entity can consistently and comprehensively be identified as unique
• Identifier
• the means to cryptographically assert and identity
• Entity
• user, code, org, agent, etc
• Entitlement
• the process of mapping privileges to identities and their attributes
• Reduced Sign-On
• account sync tool/process to minimize the number of credentials a user must remember
• Single Sign-On
• The ability to pass identity and attributes use secure standards such as SAML and OAuth
• Federation
• The connection of one identity repository to another
• Persona
• identity plus related environmental attributes
• IE:  Fred Smith as CEO of ACME Corp
• Attributes
• the facets of an identity
• Introduction to Identity in a Cloud Environment
• Problem similar to moving from a small town where "everyone knows your name" to a large city
• Key points to consider
• Risk calculations need to keep in mind the strength of an identity
• difference between self-assert vs CA for example
• Identity and attributes may now need to come from multiple sources
• There may be instances where a transient identity is sufficient
• There may be instances where pseudo-anonymity is desired (IE: Voting)
• Identity Architecture for the Cloud
• Cloud solutions should be able to consume assertions about identity and attributes from multiple sources
• Basic flow
• Business rules are translated into a set of entitlement rules
• An authorization engine takes assertions from multiple sources of identity and attributes and compares them to the entitlement rules
• Also factors in the "strength" of the assertion
• Authorization is granted and passed to an access management system
• Access management system governs access to key areas of the solution
• Network Layer
• One may not even be able to "see"(ping) a cloud service
• System Layer
• Entitlement rules may define the medium by which a system is accessed.  For example, RDP vs app only, etc
• Application Layer
• Functions of the application may be scaled based on the entitlement rules
• Process Layer
• Processes within the application can be scaled
• Some processes may require additional verification as specified by the entitlement rules
• Data Layer
• entitlement rules may limit access to subsets of data
• IE: Row level security
• Identity Federation
•  Defined as an interconnection of disparate Directory Services
• Technology should rest on open standards such as SAML
• Already in use as the SaaS level, but no standards exist for PaaS and IaaS
• Special considerations for the lifecycle of identities
• Think shared accounts, named accounts, priviledged accounts
• Existing systems for identity management need to be extended to support the cloud
• Provisioning and Governance of Identity and Attributes
• More than just user provisioning
• Need an appropriate set of attributes for rich risk-based decision making
• Examples
• Org Identity
• Location assertions
• Training record / compliance
• etc
• Ideally, cloud service/application should not be the master source for identity
• Some exceptions apply (Identity-as-a-Service)
• Attributes need to be linked to identity (somewhere in the chain)
• The Entitlement Process
• As per Basic Flow Above
• business requirements are used to determine the identities and attributes required to properly evaluate rules
• consider all layers in access management
• process does not stop with a launch of a cloud service.  Should consider the full identity lifecycle and periodic review
• When identities and attributes are sourced from outside the business's control, need to consider on-boarding and off-boarding of those orgs
• Considerations for enforcement points
• central/external PEP
• Embedded as part of the cloud app
• using IDaaS
• Authorization and Access Management
• Authorization layer is likely a PDP (policy decision point)
• Access management is the PEP layer
• Should use open standards such as XACML to share authorization information
• There are advantages to having the PDP implemented outside the cloud solution (and maybe within the traditional perimiter)
• logging
• central management
• access to internal resources (DS, etc)
• Architectures for Interfacing to Identity and Attribute Providers
• Hub and Spoke
• Good central control
• Can be placed on-prem
• abstracts the end-point services from the cloud provider (allowing control to dynamically add/change providers)
• Gives the org a high degree of control
• Hub can act as a cache to provide redundancy
• Free-Form
• easier to setup (from a cloud perspective)
• makes it harder to provision a user and related attributes
• makes for a more ad-hoc environment
• hard to keep multiple cloud providers in sync
• Hybrid
• Combination of the above
• Can lead to overly complex architectures
• Level of Trust with Identity and Attributes
• identities and attributes come with varied levels of trust
• traditionally, orgs have maintained their own identities and attributes 
• could potentially include many people who do not work for the org itself
• during the entitlement phase it is important to understand the attributes required but also the trust level associated with that attribute
• also a complex relationship between the strength of an attribute and the strength of the identity asserting them
• Provisioning of Accounts on Cloud Systems
• No widely used standard
• SPML - Service Provisioning Markup Language
• SCIM - Simple Cloud Identity Management
• push model may not suffice
• hard to maintain, non-standard, etc
• need to consider the whole life cycle of an identity
• disable / decommission
• Also need to consider associated data
• What about service accounts, etc, or identities for entities other than people
• Identity as a Service
• Will be covered in Domain 14
• Compliance and Audit
• PEP and PDP systems need to be configured to log according to regulatory requirements.
• Audit trails generally need to be tied to an identity
• Application Design for Identities
• bolt-on to domain-10
• Design goal should be to minimize the need for identity and attributes
• Start from the principle that identification is not required
• balance between on-the-fly account creation and a permanently identified account
• Consider attribute derivation
• Don't really need DOB, but need to know if entity is older than 18, for example
• What unique identifier will be used? (external vs internal) and management thereof
• Identity and Data Protection
• make sure all applicable laws are being adhered to if PII or SPI are stored as part of a cloud application
• Even if it is in the form of attributes on an identity
• Consumerization and the Identity Challenge
• Identity is hard with end-users and their devices
• No easy way to have a user/device enrolled in a strong authentication system
• Standards are fairly fragmented
• Identity Service Providers
• There is a fundamental level of trust issue when trusting other identity providers
• Most established identity services only deal with user verification
• Personal information is self-asserted
• Recommendations
• Read this, there is much info here
• Federation Recommendations
• Use open standards
• understand the trustworthiness of the federated party and what they verify (attributes, etc)
• Provisioning and Governance Recommendations
• all attributes should be sourced as close to the master as possible
• Cloud service/app should not be the master
• attributes should always be linked to an identity
• consider the life cycle of identities and attributes
• Entitlement Recommendations
• consider full life cycle
• All parties should be identified and rules should be clearly defined
• Entitlement rules should use the principle of least privs
• Authorization and Access Recommendations
• Use open standards (XACML, OASIS)
• Consider logging for audit/compliance
• Architecture Requirements
• Cloud providers should have PDP/PEP that is configurable
• use standard protocols
• use OATH compliance authentication
• Provisioning Recommendations
• Use open standards (SPML, SCIM)
• do not limit process to users, should include all entities
• maintenance should be done on both identity and attributes
• Identity Compliance and Audit Recommendations
• ensure that logs from PEP/PDP are available 
• log should include inputs to decision as well as the outcome
• logs containing PII or SPI will be subject to data protection legislation
• Application Design Recommendations
• minimize need for Identity and Attributes in application design
• cloud app should not be master for data
• support SSO such as SAML and OAuth
• Mutual authentication is critical
• Cloud service should authenticate user
• User should authenticate cloud service
• Data Protection Recommendations
• See domain 11 for more
• Reduce the need to store PII or SPI data
• Develop a process to deal with "Subject Access Requests"
• Identity Implementation Recommendations
• favor identity reuse rather than new enrolment
• use Risk-Based authentication techniques

Summary

This was a pretty interesting domain, one that I think generally gets glossed over.  Identity and attributes surrounding identity is the premier "user input" of our day and age.  Maybe it always was, but until you start thinking about the controls in place around this sort of stuff you don't really understand the level of "faith" than can be placed in it.

Take, for example, employee on boarding.  Potential employees send out resumes.  If you think about it, they can (and often do) write whatever they want on it.  All the information on a resume should be treated as "self-asserted" because there is no confirmation.  This even comes down to name, address, etc and scales up to things like past experience.  Now, you could take a step to verify the name and address by asking for a valid government-issued photo id.  This step allows you to not only validate identity (via the photo) but also some of the attributes (ie: name, age, address).  Validating identity becomes interesting in this case because all we have to rely on is a photo and we assume that a photo is "generally unique".  I guess you could take this one further and look at the person who is validating the photo.  Is that person trained in this sort of thing?  Is the photo in color?  Is the photo recent enough?  I might put more trust (increase the strength of the identity) if a boarder security guard validated the photo from a color passport than I would an office worker validating from a black and white photo on a plastic card.  There are obviously other measures that can be taken here, but how many offices take then?

This goes even further, to other important areas such as work history.  Unless you called to confirm employment, you only have the self-asserted data to go off of.  I know of some companies that do do checks, but most don't.  This gets even more bizarre when we get to identities on the internet.  Take, for example, linked-in.  Anyone can add experience to their profile.  In fact, they can even select the company that they worked for from a list and have their image displayed.  Does the company get a chance to review the people who have claimed that they work for them?  I wonder....

After the employee is hired, does anyone check the attributes then?  I bet not.  They probably expect honesty and rely on the policy that action will be taken against people who do not tell the truth.  Now imagine being a 3rd party that is trying to allow trust to employees of this company?  Wow, mind = blown.

Back to the course content, it will be interesting to watch the developments in this area, especially around management of cloud identities, etc.  This seems to be a place where traditional IT is falling down rapidly.  Further to this, there is a lot of "rogue business departments" provisioning their own cloud resources, independent of IT.  The lack of standards in this area is unfortunate, but hopefully we can move in the right direction.