Identity Management & Access Control in Cloud Computing Identity Management fo… · and best practices for identity management and access control for cloud computing, identifying

3040 Williams Drive, Suite 610, Fairfax, VA 22031 www.actgov.org ● (p) (703) 208.4800 (f) ● (703) 208.4805

Advancing Government through Collaboration, Education and Action

Identity Management & Access Control in Cloud Computing

Recommendations and Best Practices for using Cloud Services while Maintaining Compliance and Access

Controls

Cloud Computing Cross-SIG Task Group Date Released: November 2012

SYNOPSIS The following white paper addresses the challenges of supporting the integration of cloud services into agencies and departments while maintaining compliance with federal Identity, credentialing and access management standards. The paper highlights the broad level of support in current policy and makes recommendations for further improvement. Review of this document for publication followed significant vetting by key government organizations. The contents of this document were completed in 2011 and vetted in 2012.



Advancing Government Through Collaboration, Education and Action Page 2

American Council for Technology-Industry Advisory Council The American Council for Technology (ACT) is a non-profit educational organization established in 1979 to assist the Government in acquiring and using IT resources effectively. In 1989 ACT established the Industry Advisory Council (IAC) to bring industry and government executives together to collaborate on IT issues of interest to the Government. The American Council for Technology-Industry Advisory Council is a unique, public-private partnership dedicated to helping Government use technology to serve the public. The purposes of the organization are to communicate, educate, inform, and collaborate. ACT-IAC also works to promote the profession of public IT management. ACT-IAC offers a wide range of programs to accomplish these purposes. ACT-IAC welcomes the participation of all public and private organizations committed to improving the delivery of public services through the effective and efficient use of IT. For membership and other information, visit the ACT-IAC website at www.actgov.org.

Cloud Computing Cross-SIG Task Group The Cloud Computing Cross-SIG Task Group was created to coordinate and facilitate cloud computing related activities across the SIGs. The agenda for the Cloud Computing Cross-SIG Task Group is to coordinate cross-SIG related activities on cloud computing; reduce redundancy of cloud computing activities across ACT-IAC and to promote cross pollination of ideas and activities; align the efforts of the SIGs on cloud computing with the needs and requirements of the Federal Government; and to provide a mechanism and platform for SIGs to collaborate and communicate effectively on the topic of cloud computing.

Disclaimer This document has been prepared to provide information regarding a specific issue. This document does not – nor is it intended to – take a position on any specific course of action or proposal. This document does not – nor is it intended to – endorse or recommend any specific technology, product or vendor. The views expressed in this document do not necessarily represent the official views of the individuals and organizations who participated in its development. Every effort has been made to present accurate and reliable information in this report. However, ACT-IAC assumes no responsibility for consequences resulting from the use of the information herein.

Copyright ©American Council for Technology, 2012. This document may be quoted, reproduced and/or distributed without permission provided that credit is given to the American Council for Technology-Industry Advisory Council.

Further Information For further information, contact the American Council for Technology-Industry Advisory Council at (703) 208-4800 or www.actgov.org.

http://www.actgov.org/

http://www.actgov.org/




Contents

Introduction .......................................................................................................................................... 5

Cloud Provider / Consumer Adoption Scenarios in Scope ................................................................ 5

Executive Overview ............................................................................................................................. 7

Identity Management and Access Management in Cloud Computing ........................................... 8

The Federal IAM Landscape ............................................................................................................ 11

Federal IAM Initiatives .................................................................................................................. 11

Enter FICAM ................................................................................................................................. 12

NIST Cloud Computing Reference Architecture .......................................................................... 13

National Strategy for Trusted Identities in Cyberspace (NSTIC) ................................................. 14

Federal IAM Regulatory Compliance and Cloud Computing ........................................................... 16

Regulatory pressure for CAC / PIV compliance is (perceived) to be incompatible with the use of

external cloud services ................................................................................................................. 17

Protection of information and the ability to maintain stewardship responsibilities, confidentiality,

and integrity of restricted access information hosted in external cloud services......................... 19

The NIST Services Models (IaaS, PaaS and SaaS) are addressing different levels of the

technology stack. Are there compliant solutions for IAM that address each of these models? .. 21

There is a lot of discussion in industry around the types of public credentials available to users

(e.g., Facebook, Google) in addition to the FIPS-201 CAC/PIV. How are the various credential

types relevant to use by government agencies? ......................................................................... 23

Governance, monitoring, audit, and compliance of external cloud services ............................... 24

Case Study .......................................................................................................................................... 26

GSA Case Study .............................................................................................................................. 26

Recommendations ............................................................................................................................. 28

Agencies should implement identity federation brokers for access to external cloud services ...... 28

Agencies should support external credentials and trust frameworks .............................................. 30

Merge FedRAMP and FICAM Assessment and Authorization ........................................................ 30

Provide Change Management Guidance to Agencies ..................................................................... 31




Figures

Figure 1: IAM Models: Authorization vs. Authentication based approaches ....................................... 10

Figure 2 – FICAM Reference Architecture .......................................................................................... 12

Figure 3 - NIST Conceptual Reference Model .................................................................................... 14

Figure 4 – NSTIC Identity Ecosystem.................................................................................................. 16

Figure 5 - Decoupling Authentication and Authorization Using Federation ........................................ 19

Figure 6 – Service Model Roles and Responsibilities ......................................................................... 21

Figure 7 – NIST Usage Scenario for Cloud Brokers ........................................................................... 28

Figure 8 - Identity Federation Broker Model ........................................................................................ 29




Introduction

Purpose In response to a request from the General Services Administration (GSA) Federal Cloud Computing Initiative (FCCI), the American Council for Technology-Industry Advisory Council (ACT-IAC) assembled an Identity Management and Access Control working group comprised of experienced cybersecurity, cloud computing and identity management professionals from ACT-IAC membership. Formed within the Cloud Computing Cross-SIG Task Group, the charter of this working group was to provide the GSA FCCI program industry perspective on challenges and best practices for identity management and access control for cloud computing, identifying solutions and best practices which organizations may consider to overcome these potential barriers to adoption. As there are numerous business cases, cloud computing deployment models and associated solutions available today and continuing to emerge, the working group, through collaboration with the GSA FCCI program office, focused on whether identity management and access control policy and regulatory compliance was a barrier to cloud computing adoption by the Federal Government.

The key objectives of the paper are to:

- Describe the identity and access management environment as it relates to cloud

computing;

- Identify compliance challenges for agencies migration to cloud computing;

- Identify best practices for adoption of cloud computing while maintaining compliance;

- Provide recommendations for accelerating the adoption of identity and access

management best practices by the Federal Government.

Cloud Provider / Consumer Adoption Scenarios in Scope

Aside from the existing definitions for cloud computing already defined by NIST, the working group determined the need to expand on these definitions to support the objective of this paper. The following terms are used within the context of this paper to aid in the interpretation of requirements and to assist in conveying differences in how responsibilities and controls apply and must be implemented depending on who accesses the information, the locations where the information is stored, and the level of security certification of business partners. Please refer to NIST guidance for definitions of Cloud Computing Models and associated characteristics.

Term Definition

Government access access using a government controlled device from an authenticated user

Controlled access access from a device which may not be government controlled from an approved authenticated user

Public access access from a device which may not be government controlled by an




Term Definition

unauthenticated user

Dedicated government facility

single-tenant dedicated data and processing environment hosted on government controlled premises

Shared government facility

multi-tenant, government community, shared data and processing environment on government controlled premises

Certified provider government

multi-tenant, government community, shared data and processing environment on commercial premises, certified via FedRAMP

Certified provider hybrid

multi-tenant, government and non-government customers, shared data and processing environment on commercial premises, certified via FedRAMP

Public Multi-tenant, government and non-government customers, shared data and processing environment on commercial premises, industry best practices and associated audit (e.g., SAS 70)

The table below depicts a representation of the different combinations of access/facility pairs which government customers may encounter in obtaining internally provided and externally provided cloud computing solutions. Through collaboration with the GSA FCCI program office, the working group determined that of the pairs identified in this table those shaded in red presented the situations that were the most relevant for identity and access management (IAM) compliance and thus became the focus of the working group’s analysis. The Government to Public Provider relationship is also applicable, but may not be fully addressed within the scope of this paper.

Access Type

Facility / Compute System Control

Dedicated Government

Shared Government

Certified Provider, Govt.

Certified Provider, Hybrid

Public Provider

Government G2DG G2SG G2CP G2CM G2PP

Controlled C2DG C2SG C2CP C2CM C2PP

Public P2DG P2SG P2CP P2CM P2PP

Table 1: Access/Facility Pairs Describe Deployment Situations Anticipated by Federal Agencies

There are a number of provider and consumer relationships that are likely to be used in combination and each may generate a slightly different set of requirements and obligations for the parties. Proper understanding of the relationships, level of trust and responsibilities of each of the parties in a cloud based system can be supported in a secure way through intelligent use of identities, persona, access control policies and credentials.




Executive Overview Today, federal agencies find themselves in an era of restricted or reduced budgetary allocations while being challenged to provide an enhanced level of services to both internal and citizen stakeholders. Internally, the challenge is to do more with less; less money, fewer people and more need for automation. Externally, citizens are wondering why Government can’t provide the same level of online services that the commercial entities they do business with routinely adopt to reduce cost and empower their customers. It is in this environment that former Federal CIO Vivek Kundra began a series of radical changes to the way the Government procures and operates IT systems. The current Federal CIO Steven VanRoekel continues to build upon those changes and ideas to further reform how government IT operates. This drive towards transparency and consolidation of IT has led to the recognition of several important drivers that are currently impacting Federal Agency Chief Information Officers: 1) The drive for workplace mobility and collaboration through improved implementation of IAM and utilization of smartcard credentials for access to federal and commercial computer systems. 2) The drive for federal agencies to decrease the infrastructure footprint (both data center and workplace) from an economic and environmental standpoint through utilization of ―cloud computing‖ for cost effective delivery and consumption of IT services to their internal and external constituents. 3) The drive for increased security and defense against an increasing cybersecurity threat. 4) The cultural change of moving from dedicated government owned IT systems to a hybrid ecosystem consisting of a mix of government owned, shared, and public cloud systems. Some have expressed concerns that these drivers are inherently in conflict with each other. While the initiatives have great value, there are concerns that agencies will resolve the apparent conflict by slowing their adoption of cloud computing. The result of this approach will be a significant limitation in the ability of federal agencies to realize the benefits associated with the cloud computing model. The ability to effectively manage identity, credentials, and access controls to protect and govern this expanded ecosystem, while presenting some challenges, is an important capability to enable the rapid adoption of cloud computing. The goal of this paper is to analyze the relationships among these drivers and to provide recommendations on how to effectively address them in a manner that allows agencies to comply with IAM mandates and enable effective adoption of cloud computing. Access Control Models There are two basic models for access control – authentication and authorization. Authentication based access control starts with a user credential and then expects the service provider to honor that credential. Authentication based access control accepts that services are written to accept a specified set of credentials and then expects the user credential to map to one of these. Authentication based models work well if the credential owning organization owns or controls the service a user wishes to access, such as government users accessing government systems. Authorization based models work best when the credential owning organization does not own or control the service to be accessed, but wants to facilitate access by their users in a controlled way. For this paper, which focuses on government use of




externally hosted services, authorization based access control models represents a best practice. Challenges and Best Practices Specific challenges exist around compliance with federal IAM regulation and policy, protection of information in the cloud, IAM differences between the NIST service models (infrastructure, platform and software as a service), the ability to use and trust external credentials, and the management and governance of IAM in a cloud context. Each of these is discussed and can be addressed within the context of existing Federal Identity, Credential and Access Management (FICAM) related programs and best practices. FICAM, NIST, and NSTIC Enable Cloud Adoption The FICAM establishes an architecture, roadmap, and implementation guidance for federal agencies. This is structured around five areas; identity, credentials, access control, federation, and auditing/reporting needs. The OMB M-11-11 mandate and FICAM do not represent barriers to the use of cloud computing. In fact, the implementation of FICAM by agencies will improve their ability to leverage cloud-based services from multiple providers. The National Strategy for Trusted Identities in Cyberspace (NSTIC) is a White House initiative that encourages commercial adoption of trusted identity, credentials, and access management best practices. NIST has been tasked by the President to lead the implementation of NSTIC through a new national program office (NPO), and is currently working with private sector stakeholders on this mission. Increasing adoption of trusted credentials by commercial providers supports secure, risk managed access to commercial cloud services. The NIST has been tasked by the Federal CIO to accelerate the adoption of secure and effective cloud computing by federal agencies. The NIST cloud computing program has developed special publications, including SP 800-144, 800-145, and 800-146, that define and support the adoption of cloud computing standards and best practices. Case Study and Recommendations A case study is presented that demonstrates how an agency has addressed IAM in their cloud programs. Specific recommendations are presented for improving the federal IAM programs to facilitate and clarify issues around cloud adoption by Government. The Bottom Line is that, while there are challenges to IAM in the cloud, existing federal programs do provide the tools to enable a risk managed approach to achieve the Government’s goals around cloud computing adoption.

Identity Management and Access Management in Cloud Computing IAM is the management of credentials, identities, and their associated privileges that are used to control and grant access to information resources such as files, documents, applications, and data. While IAM is not unique to cloud computing, the complex relationships between providers and consumers increase the need to plan and manage access controls and identity credentials. There are a number of concepts and processes in the IAM space that are worth a short discussion before moving on to the cloud specific considerations:

Identity describes a unique entity, being a person or device, who may participate in a

system interaction. Generally, each individual or device has a single identity.




A persona represents an aspect, character, or role that an identity principal assumes for

the purposes of an interaction. For example, an individual may have many personas

representing different aspects of their work or personal life, each of which has its own

unique set of rights, powers, duties, and attributes. A device may have the persona of a

server, a mail server, or other roles they expose within a certain type of relationship.

A credential is an artifact that asserts some attributes about an identity’s persona for

use in confirming or describing the attributes or role of the entity in an interaction.

An access policy is used to evaluate the right of an authorized user of a credential to

perform some action against a protected resource.

A protected resource is the target of an access request. It has a resource owner who

establishes the access policy used to grant access to validated holders of trusted

credentials.

Credentials are the key to interoperability in a multi-provider cloud ecosystem. Credentials support the ability to share information about parties in a transaction in order to establish access rights (authentication and authorization). Sharing information in a trusted context without requiring each party to have a separate credential for each provider allows composite systems to function without alienating the user community. Imagine an application that is composed of a portal, payment service, shipping service, and search engine that creates a mash-up of services offered by 10 other commercial sites, brokering payment, and shipping. Each of these component providers is designed to use a specific credential. Unmanaged IAM would present a user with up to 15 credential challenges, rather than a single logon that handled access to the other services. From a process perspective, IAM encompasses five major functional components:

1. Identity management: the management of entities (individuals or systems) whose

access rights are to be managed.

2. Credential management: the management of credentials (e.g., digital certificates,

username/passwords, etc.) that are used to establish the identity of the entities whose

access rights are to be managed.

3. Access management: the establishment of privileges required to access protected

resources and the procedures for validating the rights of a given entity to access

protected resources.

4. Federation: the management of relationships with external partners in order to honor

credentials managed and validated by those external partners.

5. Auditing and reporting: the ability to monitor and report on the activities of the other

IAM components.

These concepts have been addressed in computer systems for many years but typically they have been implemented in a tightly coupled fashion on an application or system-specific basis.




However, the 21st century federal IT environment is built on highly distributed and interconnected systems that span federal agencies, their public and private sector partners, and their constituencies. In this environment, the tightly coupled and system-specific approach does not scale or provide a level of information security that is commensurate with the federal information assets that must be protected. As shown in Figure 1 below, there are two basic approaches to thinking about IAM. The fundamental difference between them is an expectation of who is responsible for access control within an organization. An authentication based model places the responsibility for assigning a user’s persona to a credential with the owner of the credential. Trust flows from the credential to the resource. The resource owner must trust the holder of a credential not to abuse the access granted (particularly when a user holds multiple roles within a system) and the credential owner trusts the resource not to misuse the information provided about the user.

Figure 1: IAM Models: Authorization vs. Authentication based approaches

An authorization based model places the responsibility with the resource owner. The resource owner assigns permissions though access control policies to a credential. Access to the credential is granted to the identity/persona. The trust flows from the resource owner through the credential to the holder of the credential. The decision on which model to use is based on where stewardship or ownership responsibilities lie and the ability manage risk. Where the service provider owns or controls both the credential and the service, the use of an authentication based model where the system uses the provider’s credentials makes good sense. An example of this is a government user accessing a government system and requiring the use of an HSPD-12 credential. Another instance where an authentication based model makes sense is when the risk of unauthorized




access is low. In this case, the provider’s credential may be used and if compromised, the information can be deleted or corrected. Most often, the risk of compromise is medium or high, and the objective is to provide a high degree of assurance that only authorized users access the resource and establish a chain of trust back to the actual holder of a credential, so it is recommended to default to the authorization based model. In the cloud, where shared resources from a number of providers are the norm, the owner of the cloud service may be unwilling to cede authority to a credential owner, especially in the case of multi-tenant services, so the providers credential is used and a chain of trust to the authorized user of a credential. For example, it is desirable to prevent an unauthorized user from sending email on behalf of a government employee. A cloud email system is designed to assign permissions to its internal account as a credential. To prevent unauthorized use, a policy might be established that requires a user to present an authenticated government credential in order to access the account, thereby establishing a link from the email resource back to the holder of an HSPD-12 credential.

The Federal IAM Landscape

Federal IAM Initiatives

Improvements in federal agency implementation of IAM have been recognized as a priority. In fact, the Cyberspace Policy Review1 highlighted the importance of IAM in protecting the nation’s infrastructure. One of the most significant initiatives in this area is the HSPD-12 directive. This program requires agencies to implement common procedures for conducting background checks on potential federal employees and contractors, and to issue identity credentials in the form of a Personal Identity Verification (PIV) smartcard. Prior to the issuance of HSPD-12, the Department of Defense established the smart card based Common Access Card (CAC) and Public Key Infrastructure (PKI) program, which paved the way for use of PKI-enabled smart cards in the Government. CAC and PIV are now harmonized to both support the NIST FIPS 201 standard for Personal Identity Verification (PIV). Several million PIV and CAC cards have been issued to federal employees and contractors. In February 2011, the Office of Management and Budget (OMB) issued Memorandum M-11-112 which reiterates the priority of the HSPD-12 initiative and also requires agencies to establish firm plans for enforcing the use of smartcard credentials as the primary mechanism for accessing federal facilities and computer systems.

1 http://www.whitehouse.gov/assets/documents/Cyberspace_Policy_Review_final.pdf

2 http://www.whitehouse.gov/sites/default/files/omb/memoranda/2011/m11-11.pdf

http://www.whitehouse.gov/assets/documents/Cyberspace_Policy_Review_final.pdf

http://www.whitehouse.gov/sites/default/files/omb/memoranda/2011/m11-11.pdf




Enter FICAM

Recognizing the shortcomings of the legacy, system-specific approach to IAM, the Federal CIO Council chartered the Identity, Credential and Access Management Subcommittee (ICAMSC) to develop recommendations and standards for federal agencies to follow in the implementation of modern IAM ecosystems. The result of this effort is the FICAM roadmap, reference architecture, and implementation guidance3. Figure 2 shows the high-level FICAM reference architecture that addresses the five major functional components of IAM. The OMB M-11-11 directive requires federal agencies to follow this reference architecture when implementing IAM systems.

Figure 2 – FICAM Reference Architecture

Fundamental to the FICAM architectural model is the decoupling of the major functional components using a modular approach. In particular, this allows the credential management functions associated with smartcards (PIV or CAC) to support multiple uses of these credentials such as facilities access or computer system access. Thus the access management functions leverage the credentials but are in a separate component of the architecture. The process of assessing compliance of credentials is through the Trust Framework Provider Adoption Process (TFPAP)4. Identity providers certified under this process can be adopted easily. They are assessed as compliant at various levels of trust (1 through 4). This ecosystem of trusted identity providers supports the use of external credentials by agencies both for access

3 http://www.idmanagement.gov

4 http://www.idmanagement.gov/pages.cfm/page/IDManagement-open-identity-solutions-for-open-government

http://www.idmanagement.gov/

http://www.idmanagement.gov/pages.cfm/page/IDManagement-open-identity-solutions-for-open-government




to citizen services and government access to commercial services. Refer to OMB M-04-04 and NIST SP 800-43 for more on TFPAP documents. Another significant benefit of the FICAM architecture is the ability to decouple authentication from authorization. While these two words are very similar, they mean very different things in the context of IAM. In the context of IAM, authentication is the process of validating the identity of an individual or a system. Common authentication techniques include username/password combinations, biometrics, or, of particular importance to federal agencies, smartcards. Successful authentication confirms the identity of the entity but does not actually grant access. The process of determining appropriate levels of access is the function of authorization. Based on the identity credentials that are presented and previously defined access control policies, a decision can be made as to whether to grant the requesting entity access to the desired resource. The true power of this model comes with the introduction of federation. Federation is the ability to have the authentication process vouch for the identity of the requester to the authorization process. Further, the authentication process and authorization process can be owned and operated by distinct organizations, as long as they have previously established a ―trust model‖ that governs how identities will be federated and a chain of trust established and maintained.

NIST Cloud Computing Reference Architecture

Figure 3 depicts the NIST cloud computing reference architecture. This reference architecture is intended to facilitate the requirements and characteristics of cloud computing by federal agencies. This architecture is described more fully in NIST SP 500-2925.

5 http://collaborate.nist.gov/twiki-cloud-

computing/pub/CloudComputing/ReferenceArchitectureTaxonomy/NIST_SP_500-292_-_090611.pdf

http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/ReferenceArchitectureTaxonomy/NIST_SP_500-292_-_090611.pdf





Figure 3 - NIST Conceptual Reference Model

National Strategy for Trusted Identities in Cyberspace (NSTIC)

As more and more commerce and interaction occurs online rather than face-to-face, there is a need to have an ecosystem of trusted credentials that can be used to verify the identity of those we interact with in cyberspace. Organizations acknowledge the need to trust the practices and credentials issued by other organizations. This ecosystem of interoperable trust frameworks founded in a set of standards and best practices is described in the NSTIC67. In April 2011, President Obama signed the NSTIC, which charts a course for the public and private sectors to collaborate to raise the level of trust associated with the identities of individuals, organizations, networks, services, and devices involved in online transactions. The NSTIC can be found at: http://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf. The NSTIC’s vision is that individuals and organizations utilize secure, efficient, easy-to-use, and interoperable identity solutions to access online services in a manner that promotes confidence, privacy, choice, and innovation. The NSTIC acknowledges and addresses three major challenges in cyberspace:

6 http://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf

7 http://www.nist.gov/nstic/

http://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf

http://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf

http://www.nist.gov/nstic/




1. A lack of confidence and assurance that people, organizations, and businesses are who they say they are online. Both businesses and governments are unable to offer many services online because they cannot effectively identify the individuals with whom they interact. 2. A de-facto requirement in the current online environment for individuals to maintain dozens of different usernames and passwords, typically one for each website with which they interact. The complexity of this approach is a burden to individuals, and it encourages behavior – like the reuse of passwords – that makes online fraud and identity theft easier. This requirement has created a number of problems for online businesses who face ever-increasing costs for managing customer accounts and the loss of business that results from individuals’ unwillingness to create yet another account and the consequences of online fraud. Spoofed websites, stolen passwords, and compromised accounts are all symptoms of inadequate authentication mechanisms. 3. A growing list of online privacy challenges, ranging from minor nuisances and unfair surprises to disclosure of sensitive information in violation of individual rights, injury, or discrimination based on sensitive personal attributes that are improperly disclosed, actions and decisions in response to misleading or inaccurate information, and costly and potentially life-disrupting identity theft. In the aggregate, even the minor nuisances and unfair surprises have significant adverse effects, because they undermine consumer trust in the internet environment. Diminished trust, in turn, may cause consumers to hesitate before adopting new services and may impede innovative and productive uses of new technologies. The NSTIC envisions addressing these challenges through a user-centric identity ecosystem, defined as ―an online environment where individuals and organizations will be able to trust each other because they follow agreed upon standards to obtain and authenticate their digital identities—and the digital identities of devices.‖ The NSTIC specifies four guiding principles to which the identity ecosystem must adhere: 1. Identity solutions will be privacy-enhancing and voluntary. 2. Identity solutions will be secure and resilient. 3. Identity solutions will be interoperable. 4. Identity solutions will be cost-effective and easy to use. The NSTIC will only be a success – and the ideal of the identity ecosystem will only be achieved – if identity solutions fulfill all of these guiding principles. Achieving them separately will not only lead to an inadequate solution but could serve as a hindrance to the broader evolution of cyberspace. The NSTIC emphasizes that some parts of the identity ecosystem exist today but recognizes that there is still much work to be done. NIST has established a NPO to lead the implementation of NSTIC, with a focus on promoting private-sector involvement and engagement, supporting interagency collaboration and coordinating interagency efforts associated with achieving programmatic goals, building consensus on policy frameworks necessary to achieve the vision, identifying areas for the Government to lead by example in developing and supporting the identity ecosystem (particularly in the Executive Branch’s role as a provider and validator of key credentials), actively participating within and across relevant public- and private-sector fora, and assessing progress against the goals, objectives, and milestones of the NSTIC.




In implementing the strategy, the NSTIC NPO is seeking to promote the existing marketplace, encourage new solutions where none exist, and establish a baseline of privacy, security, interoperability, and ease of use that will enable the market to flourish, while retaining current levels of security for government systems.

Figure 4 – NSTIC Identity Ecosystem

Federal IAM Regulatory Compliance and Cloud Computing

Cloud computing describes a broad movement to treat IT services as a commodity with the ability to dynamically increase or decrease capacity to match usage needs. According to the Federal Cloud Computing Strategy8, ―by leveraging shared infrastructure and economies of scale, cloud computing present’s federal leadership with a compelling business model.‖ The strategy also estimates that $20B in current IT spending could be moved to cloud-based service providers in order to realize benefits in the areas of efficiency, agility, and innovation. In order to encourage agencies to take advantage of these opportunities, the strategy establishes a ―cloud first‖ policy. This policy requires federal agencies to consider cloud-based solutions as the first choice when developing IT solutions for their constituents. Agencies may perceive that the provider of a cloud-based application cannot comply with the mandate to use PIV cards for authentication and that support for user ID/password is a less expensive form of authentication. A fundamental goal of the federal IAM initiatives is to standardize on IAM approaches that are utilized by federal agencies and to leverage millions of smartcard credentials that have already been issued. However, the cloud computing

8 http://www.cio.gov/documents/Federal-Cloud-Computing-Strategy.pdf

http://www.cio.gov/documents/Federal-Cloud-Computing-Strategy.pdf




marketplace is still emerging and as such is marked by a diversity of platforms, approaches, and technologies, including those that support IAM functions. Additionally, few, if any, cloud service providers currently support smartcard credentials as a means to grant access to their systems. Therefore, embracing cloud technologies is often perceived seen by some to require federal agencies to take a step back from the advantages to be gained by standardizing on IAM approaches, or to take a step back from fully leveraging the benefits associated with cloud computing. In reality, it is possible and quite practical to adopt cloud computing solutions while remaining compliant with federal regulation. A number of the perceived issues associated with cloud computing have been identified for discussion:

Regulatory pressure for CAC / PIV compliance is (perceived) to be incompatible with the use of external cloud services

The solution to this perception of compliance incompatibility is for agencies to work with cloud service providers to establish an authorization or authentication based model as appropriate. Firms providing outsourced IT services today must address requirements where two-factor authentication is already being supported. The resources required to verify the validity of a PKI certificate have already been stood up as part of the Government-wide PKI ecosystem. So the issue for cloud providers becomes one of connectivity to access and process certificate revocation lists (CRLs) or the use of Online Certificate Status Protocol (OCSP). Most recently OMB in their policy memo M-11-11 dated February 3, 2011 provided additional direction to agencies regarding the use of PIV cards as it relates to their use as an authentication token for agency networks and applications. This policy directs agencies to enable all new applications to accept the PKI certificates on the PIV card and for end users to employ these credentials when authenticating to these applications. The use of PIV-based credentials for authentication may require an agency to procure approved technology in accordance with OMB Memorandum 06-18, ―Acquisition of Products and Services for Implementation of HSPD-12‖, requiring agencies to procure products and services that are approved as compliant with federal policy, standards, and supporting technical specifications. The ability to extend FICAM to externally provided cloud services using only approved products may impact agency budgets which are already under pressure from multiple directions or they may find the reduction in complexity for internal systems offsets this potential added expenditure. The requirement to use only ―approved‖ technologies, e.g., smart card readers, should not be a major obstacle in terms of agencies employing PIV-based access to authenticate to cloud-based applications. Most workstations purchased by the Government since 2009 likely already have suitable card readers already installed. And PCs running Windows 7 already have suitable middleware installed eliminating the need to purchase that software. Some agencies may choose to use additional software that has features not offered in the default implementation. The requirement (OMB M-11-11) to authenticate using PIV credentials has an impact on the manner in which end users now interact with such applications. The shift is from the typical user ID/password combination to inserting the PIV card into a reader, and then entering a PIN to unlock the card. Change from the application specific user ID/password approach used for many years is simply a difficult adjustment and requires agencies to manage the cultural changes in much the same way they manage the technological changes.




Not all systems will support the use of a PIV card for access, nor does the use of a single credential easily support the need for multiple roles, or personas, for an individual. In particular, external cloud based systems may continue to require their own unique credentials based on user ID and password. Since users should already be employing the PIV card for workstation and network logon, the more frequent usage should result in an easily recalled PIN. The rules for password composition and management can be complex and too often cause users to record their passwords in a manner where there is increased risk of exposure. For external sites, the use of a passphrase should be considered as this is usually more easily remembered by a user than a complex password. In an authorization based model, there is often a need to federate, or map, the original credential to one that is recognized by the service provider or system. The federation component that accomplishes this is referred to as a trust or credential broker. The broker accepts the consumers credential and maps it to one the provider can accept. This can be done in several ways; a broker may assert attributes of the consumer credential to a service provider, allowing the provider to determine the appropriate user credential or account. A broker may issue a credential that the provider will accept that is internally mapped to the consumers credential. This can also serve to protect the privacy of the consumer. The key aspect of this is that the broker maintains the chain of trust and enables non-repudiation through the trust chain. Figure 5 depicts the recommended approach for federal agencies to use that will allow them to meet the requirements of M-11-11 and the Federal Cloud Computing Strategy. Using this approach:

1. The holder of a PIV or CAC smartcard uses their credential to authenticate their

identity to a Federal Agency’s IT infrastructure, as required by M-11-11.

2. Using the architectural concepts described by FICAM, the Agency uses identity

federation to share the authenticated credential with an external cloud provider. In an

authorization based model, the credential is shared directly or assertions passed

based on the HSPD-12 compliant PIV or CAC card. In an authorization based model,

the federation process may use a credential broker to map the HSPD-12 compliant

credential to a credential issued by the service provider where PIV is not supported.

External cloud providers are selected in a manner consistent with the Federal Cloud

Computing Strategy.

3. The external provider uses the credential to make a policy-based authorization

decision as to whether or not to grant access to the requested resource. Best

practice dictates a separation of duties in this process, with the service consumer

setting policy for access control decisions to its data and the service provider

enforcing this policy decision.




Figure 5 - Decoupling Authentication and Authorization Using Federation

This model has been adopted by GSA in their implementation of cloud-based email and collaboration services, as described in section 3.4 of this document. Therefore, agencies should embrace the FICAM architectural model as the approach to resolve the apparent conflicts between M-11-11 and the Federal Cloud Computing Strategy.

Protection of information and the ability to maintain stewardship responsibilities,

confidentiality, and integrity of restricted access information hosted in external cloud

services.

Agency and organizational concerns continue to exist with respect to the protection of data and the information that can be gleaned from that data. Additionally, questions continue to arise with respect to ownership of the data when it is thought to be under the control of the cloud provider. Finally, once that data is stored in the cloud, additional controls are required to ensure the integrity of the data that is hosted and stored in cloud service. Protection of Data Agencies and organizations are reluctant to move services to the cloud due to concerns about data protection. Agencies are under great pressure and continued scrutiny to protect their application data but more pressure exists to protect privacy or personal identifiable information (PII). This becomes more important as identity services migrate to the cloud. Costs to the agencies with respect to reputation are intangible; however, the costs to react to a breach of the private information that has been entrusted to the agency can cost tens of thousands of dollars per record per year. These are costs that agencies cannot afford to expend from budgets required to ensure the operations of their core mission. As a result, agencies may continue to control their data rather than to entrust their data to a cloud provider. It is important to note that security of the perimeter is not enough to prevent catastrophe in a multi-tenant environment that is the cloud, but there are other common security means such as data encryption Data Ownership When an agency utilizes a cloud service, the question inevitably asked, ―Whose data is it anyway?‖ The applications are operated and licensed by the cloud provider, who in turn leases the use of the application which processes the data utilized for service delivery. If the agency needs to transition to another application or even to a different cloud provider, the agency needs to ensure that the data transfers intact as desired. That data ownership remains with the agency




needs to be very clear in the procurement of the cloud service, the application used, and the transition costs of that data when applications change or if the cloud provider changes. When it comes to identity management, the questions then arise as follows:

• For the identity provider who operates in the cloud, who owns the PII used to

create the identity credential?

• For the identity broker, who owns the data that traverses through it and the audit

trail that is created?

• For the authentication of the identity, who owns the results of the validation

authority?

• For the authorization of the identity for access rules, who owns the assignment of

the authorization rules and the access to the application and its data?

• For the end-entity to whom an identity is provided, is the PII owned by the end-

entity or is the PII owned by the agency that sponsors the end-entity to receive

the identity credential?

Data Confidentiality Utilizing the NIST controls found in SP800-53, agencies must make a determination as to the security controls for the application and the ensuing data. Agencies are required to ensure that these security controls are properly executed, monitored, and reported. Infractions of these security controls can affect the reputation and place an additional financial burden on already strained budgets. This is especially important for identity management in the cloud. Some data does not require confidentiality, e.g., the contents of a digital certificate issued under the Federal Common Policy 9 that is required for the PIV credential. Agencies need to ensure that data is secure in transmission as well as secured at rest. Agencies need to ensure that cloud providers are properly keeping data confidential in transit and at rest. Data confidentiality also needs to ensure that data, including identity data, is not inadvertently nor inappropriately ―shared‖ with other organizations and applications in the cloud infrastructure. This requires appropriate data separation as well as access controls, encryption technologies, and authorization schemes as a part of policy determination and auditing to ensure compliance. Mitigations and best practices include the following:

1) Agencies need to ensure as part of procuring cloud services that the cloud

provider can meet the necessary controls to ensure data confidentiality and

data protection.

2) Agencies need to ensure as part of procuring cloud services that the data

ownership used in the applications is truly delineated. This also includes

9 Certificate Policy for the U.S. Federal Common Policy, Section 9.4.3, “Information Not Deemed Private”




transition costs and responsibilities if a new cloud provider is utilized, or the

data is transitioned to a government data center.

3) Agencies need to ensure that privacy, onboarding, offboarding, migration,

auditing, and eDiscovery issues are covered in agreements with the provider.

NIST SP 800-53 (rev 4) has added appendix J to specifically address privacy

issues and practices.

The NIST Services Models (IaaS, PaaS and SaaS) are addressing different levels of the

technology stack. Are there compliant solutions for IAM that address each of these

models?

When looking at the different cloud service models as defined by NIST in the draft of SP 800-14510, the implications for IAM fall into a number of categories. Each of the models has a different split in responsibility for the IAM functionality as shown in Figure 6. Following the authorization based model most appropriate for cloud services, the provider of the resource is primarily responsible for the binding of permissions to a credential. This is done at the time that a service is developed, and can be very difficult to change to suit the needs of multiple consumers. Credential brokers or federated identity can be used to bind the consumer credential to that expected by the provider to enforce access policy. The provider needs to delegate the access control policy and decisions to the cloud service consumer. As the consumer of a cloud service is often entrusting information with the cloud provider, the consumer needs to establish who has the right to access the information and under what conditions. The provider then enforces that policy.

Figure 6 – Service Model Roles and Responsibilities

10

http://csrc.nist.gov/publications/drafts/800-145/Draft-SP-800-145_cloud-definition.pdf

http://csrc.nist.gov/publications/drafts/800-145/Draft-SP-800-145_cloud-definition.pdf




For Infrastructure as a Service (IaaS), the cloud provider is provisioning the equivalent of hardware resources to a consumer. The consumer is responsible for loading whatever software is necessary onto the provisioned infrastructure. The IaaS provider will need to enforce access to the hardware and its control panels, but has no inherent ability to enforce access control to the software an IaaS consumer may load on to the infrastructure. In addition to access control, it may also be desirable to establish a unique identity and credential for the infrastructure asset. A consumer could use this to perform remote attestation of an asset to continuously monitor the integrity of the cloud infrastructure services. This is useful to ensure that virtual assets are not migrated to locations or devices that would change the compliance of the overall system. For Platform as a Service (PaaS), the cloud provider is still not providing an entire application, but has added software assets from which applications can be constructed. This may include runtime libraries, databases or other tools that support the execution of applications loaded by the PaaS consumer. The issues are very similar to IaaS, where the cloud provider can enforce access controls to the tools in the platform layer, but has limited ability to enforce access to the applications built on top of the PaaS assets. This enforcement is the responsibility of the PaaS consumer. For Software as a Service (SaaS), the entire stack is under the enforcement control of the cloud provider. Access decisions are delegated to the SaaS consumer, with enforcement performed by the SaaS provider. The provider also has a limited role in setting access policy to enforce proper and authorized usage of the SaaS assets (i.e., has the bill been paid?). The software application has likely been written to associate permissions to a particular credential or user account and so there is most likely a need to translate the users credential to one the software understands. As previously mentioned, federated identity or credential brokers are useful for maintaining the chain of trust. Flexibility in the implementation of IAM for SaaS services raises concerns associated with the costs associated with migrating legacy applications to a cloud model. Current best practice is to build separation of policy decisions from policy enforcement into the application, where the application takes on an enforcement role and delegates policy decisions to an external policy decision provider. This IAM enablement is likely not part of the original budget; this concern arises as both a budget and schedule impact factor. Many applications that are being re-hosted in a cloud environment have undergone some degree of transformation and modernization. What had once been a large monolithic application has been redesigned to be more modular to take advantage of technical capabilities of a cloud environment and to make maintenance easier and less costly. The process of transformation may be the optimum time to accommodate the IAM enablement work and result in only a modest expense and minimal schedule impact. Contemporary technologies also make it far easier to accommodate delegated policy enforcement than was common five years ago. Delegating Access Control Security is consistently cited as a primary concern of the cloud computing model. One aspect of the security concern is that one of the major components of IAM, access management, is essentially delegated to an external provider. Using FICAM and a federated identity approach, federal agencies can instead establish a shared approach to access control that can actually improve the security posture for the agency by forcing the agency and the cloud provider to explicitly identify access control policies and an overall trust framework that will guide subsequent authorization decisions.




The establishment of an appropriate trust framework and policy-based authorization model will be driven by the sensitivity of the information that is being accessed, processed or stored in the cloud environment. This will be of particular importance for information and systems that have been classified as ―high‖ using the FIPS 199 standards are considered for cloud deployment. This is especially true for SaaS-based applications that are ―multi-tenant‖ and support users from not only multiple agencies but perhaps even users from the private sector. The SaaS model poses some unique challenges since in this use case the provider typically issues user IDs and passwords based on input from the agency such as an identifier (email address) and user’s role (to determine privileges within the application). Where external credential trust frameworks are not supported, agencies require mechanisms to securely convey information about a user’s role to the service provider in order to properly ―provision‖ the user with appropriate access. Sharing access privileges in a directory (such as active directory) is one approach but may lead to the agency incurring risks associated with sharing. Technologies such as SPML (Secure Provisioning Markup Language) and XACML (eXtensible Access Control Markup Language) may provide the basis for an agency to automatically convey role and/or privilege information to the service provider. The automated approaches are preferred as they help ensure a stronger trust relationship between the agency and the cloud provider since the agency is able to maintain more control, if not complete control over authorization. Some cloud service providers are beginning to support credentials already in use by their clients.

There is a lot of discussion in industry around the types of public credentials available to

users (e.g., Facebook, Google) in addition to the FIPS-201 CAC/PIV. How are the various

credential types relevant to use by government agencies?

The NSTIC11 describes a vision for a future state where individuals and organizations utilize secure and interoperable identity management capabilities to access and deliver online services. The NSTIC uses the term ―identity ecosystem‖ to describe the environment that delivers on these capabilities. While the NSTIC presents a future state vision, several key components of the identity ecosystem are already in place. For example, the NSTIC describes multiple ―identity providers‖ who will be responsible for establishing, maintaining, and validating the identities of the participants in the identity ecosystem. These identity providers could be commercial or government organizations. Given their role in issuing CAC and PIV cards, FICAM compliant federal agencies are clearly identity providers in the NSTIC model. Also, the Federal Government has already established policies for federal agencies to utilize credentials issued by non-government entities through the Open Identity Solutions for Open Government12 initiative. This initiative establishes the framework and standards for agencies to use externally issued credentials, as long as they meet policy requirements. For example, citizen access to government websites could utilize externally issued credentials as long as they meet level of authorization requirements as defined by NIST 800-6313 and have been certified

11

http://www.nist.gov/nstic/ 12

http://www.idmanagement.gov/pages.cfm/page/IDManagement-open-identity-solutions-for-open-government 13

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf

http://www.nist.gov/nstic/

http://www.idmanagement.gov/pages.cfm/page/IDManagement-open-identity-solutions-for-open-government

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf




through the TFPAP program14. Per the Digital Government Strategy, ―The list of externally-issued credential providers that have been certified as being in accordance with government-wide requirements is at http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework-IDP (for non-PKI solutions) and at http://www.idmanagement.gov/pages.cfm/page/Federal-PKI-Management-Authority-entities-crosscertified-with-the-FBCA (for PKI solutions).These are the only externally-issued credentials which may be accepted.‖ Implementing the recommended federation model for compliance with M-11-11 and the Federal Cloud Computing Strategy will also position federal agencies to fully participate in the broader identity ecosystem described by the NSTIC. Some security experts today are promoting the use of a single credential to be presented to all external services, but that approach carries fairly high risks. If a single credential is assigned to an identity, then the compromise of that credential is bound to access permissions for resources across all of the personas associated with an identity. If however, the hierarchical relationship of one identity to multiple personas to multiple credentials is maintained, then the damage caused by compromise of an individual credential is limited. Restricted use or one-time credentials can allow a user access to a system and the assertions and other attributes released to a provider system targeted to what is necessary for the transaction. This approach does lead to a need for multiple credentials for a user. Rather than requiring a user to retain knowledge of many credentials and passwords, a credential broker can issue tokens to a user for use in specific scenarios, minimizing the complexity from a user perspective. The broker maintains the chain of trust from the user’s primary credential to secondary credentials necessary for access to provider services. The addition of trusted credentials that align with the NSTIC guiding principles enhances the end-to-end security of cloud-based deployments.

Governance, monitoring, audit, and compliance of external cloud services

Agencies must be able to audit and monitor access to remain compliant with federal regulations, including but not limited to A-123 and FISMA. In addition, auditing and monitoring access helps prevent non-repudiation of potential fraudulent transactions. Agencies thinking about adopting cloud should consider establishing IAM audit processes to help certify user access and reduce segregation of duties (SoD) violations. Agencies should empower their application portfolio information system security managers (ISSMs) and information system security officers (ISSOs) with the right training to evaluate IAM compliance in the cloud. Agencies thinking about adopting cloud should consider conducting a role management assessment to better understand the roles required in the cloud to help manage discrete access. Conducting an assessment of your existing application roles will help the agency define and engineer new roles that can be mapped or implemented in the cloud. In addition, understanding the role-based access control (RBAC) model prior to moving to the cloud will help the agency establish an access audit requirements baseline. Agencies thinking about adopting cloud should establish metrics to audit, measure, test, and monitor the performance of the security controls implemented in the cloud. For example,

14

http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework

http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework-IDP

http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework-IDP

http://www.idmanagement.gov/pages.cfm/page/Federal-PKI-Management-Authority-entities-crosscertified-with-the-FBCA

http://www.idmanagement.gov/pages.cfm/page/Federal-PKI-Management-Authority-entities-crosscertified-with-the-FBCA

http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework




agencies can monitor risk of unauthorized access by auditing the provisioning and de-provisioning of users and entitlements in the cloud. Prior to entering any agreements with a mission critical back-office system, like payroll, agencies should discuss how security and access controls can be tested in a multi-tenant cloud environment. Agencies thinking about adopting cloud should consider adding your IAM audit policies and metrics to the audit frameworks (e.g., SAS 70) executed by the agency’s external auditor. The Federal Risk and Authorization Management Program (FedRAMP15) is a program that has been established by the Federal Government to provide a standard approach to assessing and authorizing cloud-based computing services used by federal agencies. FedRAMP allows joint authorizations and continuous security monitoring services for government and commercial cloud computing systems intended for multi-agency use. Thus FedRAMP provides the auditing and reporting component of the FICAM reference architecture for access control functions that are delegated to cloud service providers. FedRAMP security controls have been defined to address information and systems that have been classified as ―low to moderate‖ using the FIPS 199 standards. The movement towards continuous monitoring envisioned under FedRAMP extends the use of occasional audits towards a real time tracking and event response capability. From the use of remote attestation of hardware to ensure compliance and ongoing integrity of cloud assets to interfaces into systems management and security monitoring and event managers, cloud consumers can begin to monitor, audit, and respond to policy exceptions in near real time. Agency CFOs and CIOs are under immense pressure to find creative and innovative ways to reduce costs, improve security, and increase availability of their existing IT systems. With the recent successes, stories of cloud agency leaders are considering moving other back-office IT applications, like enterprise resource planning (ERP), to the cloud to discover new cost reduction opportunities, increase availability, and improve scalability. Before moving financial or HR systems in the cloud, agencies must address a number a number of security considerations to ensure safe and secure access. One of the many security considerations that must be addressed is the ability to audit and monitor access. An agency’s transformation plan should include risk analysis. A risk-based approach should be considered for each user of enterprise or cloud-based applications. Essentially, a score associated with each user that changes dynamically based upon application access, access privileges, database access, last access re-certification, etc. Risk can also be associated with each platform (OS, application, directory, database, cloud, etc.). Risk analysis would then allow access control resources to be prioritized on to those users and platforms that pose the most risk as a function of time. In other words, it's not practical to treat all users and all platforms as equal. Risk analysis should be one of the underpinnings of governance. Governance should be implemented for continuously staying in access control compliance through controls that detect & remediate policy violations in production and controls that prevent policy violations from going into production. Such governance will insure continuous compliance versus a once-per-year compliance report. Governance should be an underpinning of all

15

http://www.cio.gov/pages.cfm/page/Federal-Risk-and-Authorization-Management-Program-FedRAMP





changes associated with access re-certification, self-service access request, and user lifecycle events (joining-moving-leaving). Governance of cloud based user accounts and applications should be a transparent extension of enterprise based user accounts and applications. Governance should extend over users and applications regardless of where the application runs.

Case Study

GSA Case Study

In December 2010 GSA awarded a contract to move its email service to the cloud, and seven months later the new cloud-based system was in production. Currently, GSA has about 20,000 email accounts for its employees and contractors located worldwide. When announcing the award, GSA CIO Casey Coleman stated ―… GSA employees will have a modern, robust email and collaboration platform that better supports our mission and our mobile work force, and costs half as much."16 With respect to GSA’s identity management requirements, the vendor had to provide solutions to the following issues: Can the solution support PIV cards and multi-factor logins? How can GSA provision and de-provision end users? How to control access roles and ensure segregation of duties, especially for system administrators? How can GSA’s current identity management services be used to support a cloud-based implementation? Can features such as single sign-on, digital signatures, and encryption be provided? What sort of additional services for collaboration can be provided from the same vendor? The overall implementation strategy adopted was to interface the selected vendor’s authentication and provisioning services with GSA’s identity management infrastructure, and to utilize the selected vendor’s implementation for role management and run-time authorization services. GSA is required to use PIV card based authentication from facilities on the GSA network and wanted a single sign-on approach leveraging the user’s login to the GSA network. But, it was strongly felt that GSA staff members also need to access their email remotely, sometimes from computers and devices that have no PIV card reader available. A second problem was that the new agency-wide authentication service was not yet available. As a result, GSA implemented a multi-factor authentication solution that leverages GSA’s Microsoft integrated Windows authentication capabilities. In addition, the selected vendor provided GSA an active directory server connector to allow the email service to read user account information to support end-user provisioning and de-provisioning services. Authorization services for end users and administrative users are native to the vendor’s application. GSA required documentation of the security roles defined, and tested each user’s available functions to ensure appropriate segregation of duties by role. In addition, all contractor and vendor staff who are able to access the email system, are required to have federal

16

GSA Becomes First Federal Agency to Move Email to the Cloud Agencywide, December 1, 2010; see http://www.gsa.gov/portal/content/208417

http://www.gsa.gov/portal/content/208417




background investigations and suitability checks equivalent to what would be required for a non-cloud based solution. GSA system administrators and security staff have 24/7 access to all the system’s audit logs and records. Not all services requested by GSA were provided in the first phase of the implementation. Digital signing of email and encryption will not be supported directly in the environment until a browser plug-in is available. A desktop email client is used as a work around for the 100+ GSA staff members who need these functions for their current work. On the other hand, the implementation includes a mature internet based, shared document repository that has built-in access controls that are integrated with the Agency email contacts database. This provides more secure document sharing environment than using a shared network drive because it allows end users to set fine-grained access rules for all documents and folders. It also better supports GSA staff members who are teleworking by providing the same secure access to shared documents over the Internet as their colleagues have from within the GSA network. The GSA email implementation clearly shows that Federal IT services can be run safely and deliver authentication and authorization services for cloud-based applications. In certain cases, Federal Government requirements may be in advance of features provided by cloud based service providers, but these may not be show-stoppers when adequate compensating controls can be used. GSA has shown it is possible to leverage an Agency’s own identity management services and combine them with a vendor’s existing authentication, provisioning and authorization services to provide secure access using standard Federal identity credentials.




Recommendations

Agencies should implement identity federation brokers for access to external

cloud services

The FICAM-based federation model shown in Figure 5 represents an agency connecting to a single cloud provider. However, as agencies implement the Cloud First policy, it is probable that they will need to establish connections with multiple cloud providers. This probability introduces the risk that agencies may develop ―cloud stovepipes‖ or many-to-many connections between individual program or mission areas and cloud providers. The NIST cloud computing reference architecture identifies the use of ―cloud brokers‖ to mitigate this risk. As described in NIST SP 500-29217, one of the categories of service that may be provided by cloud brokers is service intermediation, whereby a cloud broker enhances the services of cloud providers through the provision of value-added services, such as identity management. NIST’s generic usage scenario for cloud brokers is represented in Figure 7.

Figure 7 – NIST Usage Scenario for Cloud Brokers

In the context of IAM, the generic cloud broker would become an ―identity federation broker.‖ As depicted in Figure 8, this broker would serve as a central point for federating identity between multiple agencies and multiple cloud service providers. This approach is recommended for federal agencies in order to minimize the technical integration requirements that will be associated with establishing connections to multiple cloud service providers. Note - for simplicity, Figure 8 depicts a single broker. However, the expectation is that over time, multiple identity brokers will compete in the marketplace as shown in the NSTIC trust framework model in Figure 4.

17







Figure 8 - Identity Federation Broker Model

This approach allows agencies to invest technical, operational and security resources into establishing a connection with the identity broker. Once in place, this connection could be utilized by any agency program or mission area that wished to utilize a cloud service provider that was also connected to the broker. Each program and mission area would need to establish a business and trust relationship with the cloud service provider but would not need to re-implement the identity federation services required to authenticate their users to the cloud service provider. By providing an enterprise service for external identity federation, agencies will be able to more aggressively utilize the cloud computing model. Connecting to identity brokers will also benefit cloud service providers as they will essentially be ―pre-connected‖ to participating agencies. The White House has established an inter-agency tiger team to craft requirements for a Federal Cloud Credential Exchange (FCCX) that would play the role of an identity federation broker.




Agencies should support external credentials and trust frameworks

Given the need for an ecosystem of trusted identity providers and the desire to support both the provision of citizen services and the consumption of external cloud services by the Government, it is imperative that the mechanisms be implemented to allow access to government systems using trusted externally issued credentials as well as the use of externally issued credentials by government employees and contractors to access external cloud systems, where it makes sense. A recent OMB memo18 provides guidance on the mechanisms and policy for access to government systems using trusted external credentials. The memo establishes policy and direction for adoption of the process and criteria for evaluation and acceptance of these credentials. In many cases we are seeing examples of situations where government agencies would like to use external cloud services but conflicts exist in the implementation of IAM processes and policy, or TFPAP compliance has not be assessed or is not at a level high enough for direct authentication using government credentials (i.e. weak protection of PII in assertions). Many agencies have already invested in federated IAM tools for internal use. Where possible, these should be used and expanded to include support for direct use of TFPAP approved external credentials. The FCCX working group has posited the ability for an identity exchange to support a ―trust elevation‖ (step up, step down) function. Current policy is clear that access to government systems requires a FICAM compliant credential, but the ability to manage the level of trust with external cloud services could allow government users the ability to access commercial services that would otherwise be prohibited if only FICAM certified credentials are allowed. Rather than engineer special exceptions or waivers for each cloud provider or change agency or provider policy, the use of federated identity brokers may offer a sensible solution to gain access to external cloud services to support mission objectives. We encourage NIST to investigate how government users may either implement direct use or brokered use of external credentials in a consistent manner. NIST’s support of the FCCX tiger team meets the spirit of our recommendation. FICAM should provide government assessors guidance on assessing the risk of compromise when policies on either side of a federated identity broker differ, so as to ensure an effective end to end trust.

Merge FedRAMP and FICAM Assessment and Authorization

As agencies move forward with plans to adopt external cloud services as part of different programs and missions across the Government, it is inevitable that multiple agencies and programs will need to accredit the same external service. Under the current program based accreditation approach, providers of cloud services would be faced with having to recertify their service against potentially conflicting requirements from the various programs. Forward thinking government leaders have taken a proactive approach to better manage these demands on cloud providers through the creation of the FedRAMP, which promotes an ―authorize once, use

18

http://www.cio.gov/Documents/OMBReqforAcceptingExternally_IssuedIdCred10-6-2011.pdf

http://www.cio.gov/Documents/OMBReqforAcceptingExternally_IssuedIdCred10-6-2011.pdf




many times‖ philosophy. Based on the latest available version of FedRAMP controls19, the normal NIST 800-53 controls regarding IAM are included but the accommodations needed for using public cloud services and external credentials are not. The continuous monitoring of compliance also makes the assumption that cloud service providers are building for the government market and does not speak to how the Government can use and monitor commercial cloud services. It is recommended that the NIST Cloud Standards, NSTIC, FICAM, and FedRAMP teams coordinate guidance for standards and approval for external cloud provider assessment, covering the facilities, services, and IAM practices.

Provide Change Management Guidance to Agencies

One of the more significant challenges to agency adoption of cloud computing and the ecosystem of federated and brokered credentials described in this report is the need to overcome the cultural inertia that binds agencies to business as usual. Making the most of cloud computing requires a shift in operational processes, acquisition, roles and responsibilities around IT systems that should not be understated. Among the more significant challenges associated with this change are:

- The perception that ALL facets of the Government are somehow different from their

commercial counterparts and require special accommodation.

- The concept of shared IT resources integrating with or replacing purpose built and

locally controlled IT systems. The concept of shared risk and operational best practices

for maintaining mission readiness without total control needs to be communicated.

- Procurement practices that embrace a dynamic environment rather than seek to manage

and control all changes. The use of ―not to exceed‖ pools of IT services that can be

easily reconfigured to meet program needs rather than seeking contracting officer

approval for minor configuration changes should be considered.

- The ability to use, manage and audit external providers using both government and

commercial identity and credential trust frameworks.

It is recommended that GSA and OMB provide guidance to agencies on the impacts of migration to cloud computing, training in best practices, and collaborative environments. This is recommended to share successes and failures across the Government in order to demystify and help agencies manage the high degree of perceived risk in migrating to cloud computing and IAM with external providers.

19






Authors and Key Contributors ACT-IAC would like to thank the following members that contributed significantly to the development of this paper: Michael Donovan, HP – Co-Chair, Identity and Access Management (IAM) Working Group William Corrington, Stony Point Enterprises – Co-Chair, IAM Working Group Barbara Allen, AAC, Inc. Deborah Blanchard, Verizon Treb Farrales, Deloitte Annette Hagood, Deloitte Steve Lazerowich, HP Matt Schmidt, Sailpoint

ACT-IAC would also like to recognize other members of the Cloud Computing Cross-SIG Task Group that participated in the review and comment of this paper: Habib Nasibdar, USmax Corporation, Chair, Cloud Computing Cross-SIG Task Group Jeremy Grant, National Institute of Standards and Technology (NIST) Fred Whiteside, NIST Jonathan Rich, GSA Bryan Ward, Serco-NA Pete Johnson, Serco-NA Tommy Osborne, Maden Technologies Harold Youra, Alliance Solutions

The Cloud Computing Cross-SIG Task Group would also like to acknowledge and thank Katie Lewin and Bajinder Paul of the GSA FCCI program office for their input and guidance that assisted the working group members to identify and understand the unique challenges of the program.