Embed Size (px)
Citation preview
1
Trustmark Implementer Guidance for Public Safety Agencies
SAFECOM-NCSWIC Implementer Guidance and Roadmap Sub-Working Group 29 October 2018, v0.42
DRAFT
Executive Summary Trustmark technology fills an important gap toward enabling efficient automated information sharing in the Public Safety multi-organizational environment. The implementation of Trustmarks is straight-forward and is addressed in Section V of this white paper, including (In Section V.3) an implementation checklist with the six main steps from start to finish. Other sections provide background and introductory materials for ICAM (Identity, Credentials, and Access Management), for identity federation, and for the Trustmark technology itself. The background and introductory materials help the reader to appreciate the steps listed in the implementation checklist. Some of the listed steps that are not explained here will be described in detail in a subsequent version of this implementer white paper when their details become available in practice.
I. Introduction and Purpose In the Public Safety (PS) environment efficiency in information sharing can be critical in certain stressful operations, while at most other times it is a requirement for the effective and efficient operations of their organization. The police, fire, emergency medical, highway department, national guard, utilities, NGOs, networking support, and others involved with public safety personnel or organizations do not work in a vacuum. Multi-organizational, or multi-domain, information sharing within their work environments is essential. This paper focuses on the core underlying communications electronic technology known as identity federation and often referred to in this paper and elsewhere as “federation.” Federation technology is the foundation for exchange of information and data between parties involved in a transaction that are associated with separate, different organizations. Within this paper the emphasis will be on users and their access to applications across organizational boundaries. The users are often on a browser accessing the app, or they might be using their cell phone or laptop. Traditional voice, as with Land Mobile Radio (LMR), is unavoidably a common participant with PS, but it does not support the breadth or power of digitally-based data interoperability and is not addressed in this paper. There are also two major types of use cases addressed with multi-domain Public Safety: (a) emergency response, and (b) intelligence analysis. As the reader will discover in the next section, at present this project only has gathered use cases dealing with the former, emergency response. This paper will first introduce the technology and benefits of the identity federation technology just mentioned, and as part of that introduction the reader will learn of the intimate tie-in of federation with the need for trust within the parties to the federation. As a part of that need for trust the technology known as Trustmarks will be introduced, a technology that provides a certification and quantification of particular implementation assurance (trust) levels within a federation environment. I.1 Intended Audience and Assumptions This paper is targeted to professionals that will be responsible for implementation of identity federation, ranging from management with responsibility for staffing and provisioning, to those who are or will be
2
working at the hands-on installation and configuration level. The reader will need to have certain foundational knowledge, such as
An ability to appreciate the value propositions (use cases) presented in the next section.
For mid-level management an appreciation of the various functional system parts that will be introduced.
For installation staff an understanding of the technical parts as introduced in order to support their coming configuration requirements.
I.2 Publication Information
I.3 Assumptions
I.4 Goals of This Document This white paper will attempt to give a well-rounded and all-inclusive introduction to the information sharing topic for the PS and LE environment. Combined with references as appropriate for those wishing to drill deeper.
I.5 Sections That Follow 1. Introduction and Purpose
2. The Value Proposition of Federated ICAM
3. A Brief Primer on Federated ICAM for Information Sharing
4. Trustmarks – An Overview
5. Implementing the Trustmark Infrastructure for managing Federated ICAM and Information
Sharing
6. Quick-Start Guide: What Do You Want To Do?
7. Purpose of the Artifacts
8. Other Available Resources
9. Appendices
II. The Value Proposition of Federated ICAM There are two general types of value propositions, or use case scenarios, where identity federation technology is particularly and indispensably important in providing for the success of a mission. Each will be explained. 1. Time Zero Events. These types of value propositions occur when a PS or LE event suddenly occurs
that brings together various types of participants (who work for different organizations) working toward a common objective. Some common examples include: bombings, school shootings, hurricanes, floods, acts of terrorism, dangers from well-attended sporting events, and a lot more. The time-zero event presents a situation where federation can greatly assist with:
Different organizations
Information that must be shared
Information being shared is of a sensitive and restricted access basis
There is varying, quantified levels of trust between the participants
Standards-based federation to enable universal participation
3
Use of authorization techniques based on environmental variables, user attributes, and other factors is to be expected.
2. Intelligence Analysis. Analysis of information from multiple sources is a continual PS and LE task, and information is continually being shared among different organizations. Some of the sharing takes place in a machine-to-machine transfer manner, with an underlying technology known as Web services that is not being addressed in this paper. Also not being explicitly addressed in our value propositions, is where users in one organization in the normal daily pursuit of their job responsibilities use Web browsers to access intelligence information hosted by a partner organization, using federation to support the transfer.
II.1 Examples
1. Time Zero Event – Hurricane. o Event: Hurricane Maria o Focus: Puerto Rico o Date/Time: Landfall on 20 September 2017 o Effect: More than 2,000 people died, extensive infrastructure damage, other effects
were still being evaluated one year later o Participating organizations: EMS, Fire Dept / Services; Law Enforcement; Paramedics;
Physicians; Morticians; Utilities; Emergency Disaster Departments; Highways and DOT; Hospitals; Public Transportation; Communications; Federal Special Agents
o Duration: Indeterminate. At least one year. o Coordination needs: LMR; data; applications; o Specific data needs: TBD. Very important. o Specific application needs: TBD. Also very important.
III. A Brief Primer on Federated ICAM for Information Sharing Traditionally a person wishing to access resources at a particular Web site needed to be known ahead of time to the owning organization, and needed to pre-establish their persona and their need to access. Identity federation allows a user to browse to a Web site that does not know the user and to retrieve information that they are qualified to have. The resource owner will first (real time) obtain trusted information about the user before release of a resource. As indicated above, this will typically involve user attributes and user assurance information such as how well their identity is established at their local or home organization, and how securely they logged in today. User identity information might also be typically exchanged, but with normal audit facilities existing on both ends of the transaction, as well as the use of cover in some instances, such personal identification is not necessary or mandated. III.1 Terminology A little terminology for identity federation work.
Standards. There are two identity federation standards that are in primary use today. SAML1 is one, or more precisely “SAML Web Browser SSO Profile” from the OASIS standards body, and OpenID Connect (OIDC) is the other, from the OpenID Foundation standards body.
SP/RP. An SP, or Service Provider, in SAML is the resource-owning party. In OIDC this is referred to as the Relying Party (RP) but the two are now used somewhat interchangeably.
1 SAML, Security Assertion Markup Language, is from the OASIS standards body. SSO refers to Single Sign-On.
4
IdP/OP. An IdP, or Identity Provider, is the service that will attest to the authentication and characteristics of the end user. Within OIDC this same position is known as the OP, or OpenID Provider.
Figure 1. Typical federation infrastructure representation – from Microsoft2
As noted by Microsoft with the above figure,
“The figure illustrates the Federated Identity pattern when a client application needs to access a service that requires authentication. The authentication is performed by an IdP that works in concert with an STS [Security Token Service, WS-Trust standard]. The IdP issues security tokens that provide information about the authenticated user. This information, referred to as claims, includes the user’s identity, and might also include other information such as role membership and more granular access rights.”
In the figure, the “Service” can be considered as the SP/RP introduced above. The “Consumer’ would be the user or a browser controlled by the user. III.2 SAML
2 Figures taken from “Federated Identity Pattern,” https://docs.microsoft.com/en-us/azure/architecture/patterns/federated-identity
5
Among Public Safety and Law Enforcement installations SAML plays the dominant role for identity federation purposes. It is the standard of excellence that other protocols are compared against. All commercial ICAM (Identity, Credential, and Access Management) offerings provide for both SAML and OIDC support. The XML foundations of SAML are much wordier than the JSON basis of OIDC, but with modern data bandwidth and software library support it is not obvious that XML is the drawback that it was considered several years ago. Figure 2 shows a typical operational scenario for a particular type of SAML installation, what is known as a profile, drawn in what is called an “SP Initiated” transaction manner. Figure 3 gives a walk-through of its sequence of operation.
Figure 2. SAML “SP Initiated” transaction3
3 OASIS, “Security Assertion Markup Language (SAML) V2.0 Technical Overview,” https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf
6
Figure 34. Sequence of steps for the “SP Initiated” transaction shown in the preceding figure
4 Federal Identity, Credential, and Access Management, “Security Assertion Markup Language (SAML) 2.0, Web Browser Single Sign-On Profile,” GSA, https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/SAML20_Web_SSO_Profile.pdf
7
Another SAML installation, known as “IDP-Initiated,” is shown in Figure 4. In this case the IdP understands from previous agreements with the SP which user attributes the SP expects for a particular transaction and supplies them within the HTTP protocol exchange. The previously-illustrated SP-Initiated approach is different in that it allows the Service Provider to request just which user attributes it requires to support a given transaction.
Figure 4. SAML “IdP Initiated” Transaction with POST Binding5
As is typical with a standard that has been in active use for over a decade, there are a lot of documented variations to the use of SAML, some of which like end-to-end encryption and digital signature and artifact resolution are a part of the standard, and some like Backend Attribute Exchange that are not. The set of options available within the SAML environment are beyond the scope of this paper, not to mention identifying which are in active use and which are not. III.3 OIDC OpenID Connect is an Identity Federation protocol built upon the OAuth authorization protocol and provides an identity federation infrastructure. As with SAML, OIDC has multiple profiles in use, with the main ones being:
5 OASIS, “Security Assertion Markup Language (SAML) V2.0 Technical Overview”, https://www.oasis-open.org/committees/download.php/20645/sstc-saml-tech-overview-2%200-draft-10.pdf
8
Authorization Code Flow
Implicit Flow
Hybrid Flow The Authorization Code Flow is most likely to be adaptable to PS needs, and will be the center of discussion here. The OIDC operational components are introduced in the following figure, with the various operational components being:
1. User/User Agent. This is the user and their browser. 2. OpenID Provider (OP). This is the user’s identity system that will vouch for their identity and
attributes and assurance levels once the user properly authenticates. This will often be a local identity resource for the user. The OP has 3 types of interfaces that will be of use for our federation purposes:
Authorization Endpoint. Labeled as “OpenID Provider” in the figure. Challenges the user to authenticate and issues an “Authorization Code” that the user agent passes to the RP.
Token Endpoint. This provides the back channel interface point at which the RP can present the Authorization Code in exchange for an ID Token and an Access Token.
UserInfo Endpoint. In cases where an Access Token, usually the default form of the ID Token, is presented to the RP, this endpoint allows the RP to request a set of additional pre-arranged user attributes.
3. Client or Relying Party. This is the Web system, such as a portal, or Web application that has the target resource which the user wishes to access.
4. ID Token. This token has user information established within the OIDC standard. It can be custom extended by agreement between federation partners, but usually such additional information exchange takes place via use of an Access Token and the UserInfo endpoint.
9
Figure 5. Typical system flow in an OIDC identity federation6 Another view of the Authorization Code Flow of OIDC is provided in the following figure from Oracle. Authorization Code Flow is chosen to be illustrated here because Public Safety information sharing based on federation will usually include an exchange of user attributes. While other profiles of OIDC can be adapted, the Authorization Flow shows the most practical use. The user first attempts access to the resource (the RP in figure), and after authentication occurs (at Yahoo or at Google) they are returned to the RP with the authorization code
Figure 6. Illustration of use of OIDC components7
The next figure is a different look at the OIDC sequence of operation with Authorization Code Flow. Again, the user first attempts access to the resource, and after authentication occurs they are returned to the RP with the code. Additional, subsequent flow is included.
6 “Dev Overview of OpenID Connect,” https://developers.onelogin.com/openid-connect 7 From ‘Oracle Access Management Federation Service,” www.oracle.com/technetwork/middleware/id-mgmt/identity-federation-wp-129458.pdf
10
Figure 7. OIDC Sequence Diagram from Ping Identity8
8 Ping Identity, “OpenID Connect, from www.websequencediagrams.com,
11
III.4 Attribute Agreements As explained above, federation of information in the PS environment requires a real-time attribute-exchange foundation due to the information being exchanged often being of a sensitive nature. One word of caution is that sometimes federation participation can be of a partial (or hybrid) nature, meaning that users can be required to pre-register with an RP before participation in the federation; that instance will be ignored in this paper since it is not conducive to the level of participation that PS use cases can require. Getting agreement on a set of attributes to be exchanged in a federation is a very common task within an ICAM infrastructure for any particular domain of partners. Some of the considerations that are encountered include:
The set of required attributes for a particular target resource, in practice, is in the purview of the RP’s since they have the responsibility to protect their resources.
Personally identifiable Information (PII) only adds more complexity to the requirements.
Federation protocols, and particular profiles within a protocol, can provide selection criteria based on the previous two items. For example, during a PS emergency, it might not be appropriate to pass all user agreed-upon attributes to all emergency participants for all federation session setups. o A non-governmental entity being accessed for information on hazardous materials might
not need PII or home organizational information about the National Guard soldier who is requesting the information.
An example of a multi-domain federation for public safety support is STAC, or the Sensitive But Unclassified (SBU) Technical Advisory Committee. STAC provides federation support and coordination, including for attributes, for PS information sharing at the federal / state / local / tribal area with DHS’s HSIN, FBI’s LEEP, DEA’s EPIC, IC’s Intelink-U, and RISS’s RISSNet. This group uses SAML and has agreed on a set of 27 attributes for exchange. Seven of the attributes are requested to be included on every exchange, while the other twenty are passed at the real-time discretion of the particular IdP based on the information resource that is being accessed. Examples from the set of 27 includes:
LocalID. Unique to a user’s IdP
EmployerName
CitizenshipCode
SwornLawEnforcementOfficerIndicator Again, participants to a federation partnership should expect a set of agreed-upon attributes for exchange among partners. In cases where multiple domains are involved, as can occur in a time-zero event involving disparate types of Public Safety organizations (like, say, highway and public health and poison control organizations) it would not be unusual for multiple sets of agreed-upon user attributes to be in use. III.5 Policies and Access Controls From the preceding in situ descriptions of information exchange involving sensitive materials, the reader understands that organizational ICAM installations will be involved that include the use of access control to restrict access to those individuals or organizations with an established need to access. The owning organization’s responsibilities can also extend to Digital Rights Management (DRM), the process of maintaining control on how their resources can be used by the receiving party; control of printing or
12
passing materials to others and more. Access control technology known as Attribute-Based Access Control (ABAC) is often in use and in turn is controlled by a set of rules or policies that specify and enforce the access permissions. III.6 Identity Proofing Identity proofing establishes that a person is who they claim to be, and is associated with the issuance of identity credentials by an identity provider. It is expected that an IdP organization participating in PS federation has established the true identity of their participants with reasonable certainty. This assurance of a person’s identity is addressed in the next sub-section on assurance. III.7 Assurance and Trust Trust between users and their organizations, RP’s and IdP’s, is a key element to successful federation among members of the Public Safety community. It falls into several general categories that will be reviewed here.
1. Handling Policies and Procedures. Before an RP is willing to share SBU information with members of another organization, it will need to understand that its materials will be handled appropriately. All parties associated with an operation need to trust that the participating organizations will handle information appropriately.
a. For example, if a user expects to receive information about the contents of a railroad car that is dangerously near a fire, it would be hoped that they will not unnecessarily panic the public with a premature release of such information.
b. Since information obtained is often of a digital nature, the use of DRM to encompass and protect the information can sometimes help with concerns about its release.
2. Identity. In a federation-based exchange of information, a user’s actual identity may not be as important to the particular transaction to an RP as a logging of the event, and some method of tracing the transaction back to a particular individual should the need arise. This includes when cover is in use. It is up to an RP to specify what user attributes it requires, including identity. Of more relevance to a particular access decision can be the Identity Assurance Level (IAL) as specified in the NIST Digital Guidelines document9. IAL can be used by the RP to satisfy its concerns that the user has been well-established within their user community.
a. One source of identity assurance for use in a Public Safety transaction can come directly from the user’s identity credential. GSA, for example, has its “Trust Services”10 for Government, Business, and Consumer use. Some of those identity credentials carry a “Level of Assurance” (from a previous NIST rating) similar to IAL.
3. Authentication. An RP can also make its decision for access based on the assurance associated with a user’s particular authentication for the current session. The latest measure of assurance for this is known as Authenticator Assurance Level (AAL) and is based on the same NIST SP 800-63-3 document referred to above, and can bring in technology such as Multi-Factor Authentication or MFA. If a PS user leaves their FIDO11 hardware FOB home by accident, an RP might decide to show them less information than would normally be presented.
4. Implementation Assurance. An important measure of trust for the operational and implementation environment has been developed by the Georgia Tech Research Institute (GTRI)
9 NIST Special Publication 800-63-3, “Digital Identity Guidelines,” https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf 10 GSA Trust Services, https://www.idmanagement.gov/trust-services/ 11 FIDO Alliance, https://fidoalliance.org/about/what-is-fido/
13
and is known as Trustmarks. In particular there are Trustmark Interoperability Profiles (TIPs) that provide a certification that an organizations has met levels of quality and completeness as established by organizations such as NIST and its set of security Controls12.
a. So in actual operation, from an RP’s perspective, it can be important whether the IdP has been certified (has been granted an approved TIP) for support of IAL 2 (where permissible values range from 1 to 3) and for support of AAL 3 (also with values that can range from 1 to 3)13. Or important if the Credential Service Provider in use by the user’s organization is Trustmark certified. Other TIPs support certification for particular types of MFA use, derived credential use, One-Time Password (OTP) use, and more.
b. Or TIPs from a user’s perspective that certify the RP can include audit controls, contingency planning, handling of incident response, support the handling of PII, and more.
Based on its foundations of Trustmark Definitions (TDs) and of TIPS, Trustmarks introduces into an ICAM system a new level of granularity, not previously available. This in turn will affect ICAM implementations in at least one of the following two types of manners, in part because each ICAM installation in a multi-organizational partnership will likely have a different level of Trustmark certification.
1. Identity Federation installations of the SAML or OIDC protocol will show normative effects within the protocol operations, meaning modified protocol functionality of a policy nature associated with Trustmark operational requirements.
2. Some aspects of Trustmarks, such as those dealing with low, medium, or high system impact (wrt Confidentiality, Integrity, and Availability), will be implemented at the ABAC level based on attributes. This is potentially in addition to implementation at the SAML or OIDC protocol level described in #1.
III.8 Specific Profiles and Metadata Exchange An organization implementing identity federation must expect some adjustment to fit the requirements of a particular information environment. Protocol specifications in practice are usually too broad and need to be tailored to a particular using environment. Public Safety is no exception. Organizations should expect to need to follow profile specifications, as well as adapt to specific exchanges of metadata with their participating federation partners to facilitate setup of operational specifics. III.9 Miscellaneous A few other federation implementation considerations that will arise in a typical PS installation will include the following:
Partial or Hybrid Federation. This was mentioned earlier, where a partner to a federation requires advance registration of all partners before a time-zero event or an intelligence sharing can occur. The SP/RP finds that the IdP/OP cannot be trusted to satisfy its organizational set of authorization requirements via a set of user attributes.
12 NIST, “Security and Privacy Controls for Federal Information Systems and Organizations”, https://csrc.nist.gov/csrc/media/publications/sp/800-53/rev-4/archive/2013-04-30/documents/sp800-53-rev4-ipd.pdf 13 Trustmark Binding and Usage, https://trustmark.gtri.gatech.edu/technical-framework/trustmark-binding-and-usage/, and Trust Interoperability Profile examples, https://trustmark.gtri.gatech.edu/operational-pilot/trust-interoperability-profiles/ and https://trustmark.gtri.gatech.edu/operational-pilot/trust-interoperability-profiles/tip-tree.html
14
o For example there might be background checks, or a quantification of need to access, that no one else is considered qualified to perform.
o A hybrid federation is not adequate for the handling of most types of Time-Zero Events (see Section II above).
End-to-End Encryption. This will often be a domain partnership requirement, and is an implementation capability of the selected federation protocol.
Digital Signature. As with end-to-end encryption, the signing of information tokens is often a domain partnership requirement.
Authentication Context. There may be a requirement for SP/Rps to be able to specify the quality or assurance level in use for the user’s local authentication, or at least for an RP/SP to be notified of its value.
Confirmation Method. Avoidance of Man-In-The-Middle (MITM) attacks can incorporate subject confirmation as one mechanism. SAML has its Holder Of Key, while OIDC is developing a token ID binding approach. Differences between the two is discussed in the next section.
III.10 Comparisons of SAML and OIDC An appropriate topic to conclude our introduction to identity federation is to compare the SAML and OIDC protocols from a Public Safety perspective. Both protocols are in everyday use on the Internet. The comparison will not be exhaustive but will suffice to show that SAML has some advantages over OIDC wrt Public Safety.
Byte Count and Readability. The OIDC protocol is more compact in term of bytes to assemble and send over the network, and this has been one of the traditional justifications for use of OAuth and OIDC. An advantage of 2:1 to 3:1 is to be expected, plus OIDC’s JSON is more readable than with SAML’s XML. But if a query is for multiple Web pages from a single target resource, where SSO is usually employed, this byte count comparison becomes insignificant. Plus with the use of software libraries or the availability of off-the-shelf vendor packages it is not necessarily significant to a developer which federation profile is in use. And mobile (and stationary) network bandwidths have been increasing, making the operational effects of the byte-count delta small.
Attribute Request. As explained above, the SAML profile most commonly used for PS purposes, Web Browser SSO, allows options for a Service Provider to selectively ask for the particular attributes needed to justify access to a requested resource. What is known as Request/Response (R/R)14. OIDC is based on an all-inclusive attribute set to be passed on the establishment of each federated session. The privacy and security considerations for passing of, say, 3 attributes versus 20 or more can be significant.
Profile Differences. Both protocols will have a certain uniqueness to their set-up parameters, such as what the National Identity Exchange Federation (NIEF) specifies for use of their PS membership. Pre-exchange of metadata provides good assistance in the initial setup.
Subject Confirmation. SAML’s use of Holder of Key uses a direct “link” between the IdP and SP as a means to discourage MITM attacks. Its use is illustrated in the NIEF SAML spec15. OIDC’s Enhanced Authentication Profile Working Group16 uses an approach that needs active browser
14 For more information on SAML’s use of Request/Response, such as for attributes, see the Wikipedia writeup on SAML and the references given there. https://en.wikipedia.org/wiki/SAML_2.0#Assertion_Query/Request_Profile 15 NIEF, “NIEF Web Browser User to System Profile,” https://nief.org/specs/nief-web-browser-user-to-system-profile-1.0.pdf 16 OpenID Foundation, “Enhanced Authentication Profile (EAP) Working Group,” https://openid.net/wg/eap/
15
participation. Both approaches are PKI based, but the OIDC proposed approach can introduce an additional attack point.
Common Use. In the LE and PS communities, and others, the use of SAML is well-established and is achieving its objectives. OIDC has a lot more normal everyday Internet use at present than SAML, as organizations like Google, Facebook, Twitter, etc. serve as a community user identity resource.
See the following Table for a summary of key SAML and OIDC differences from a Public Safety use perspective
Consideration Comment Addition Considerations
Support for Attribute Request/Response
SAML has more native support for R/R, important for a multi-domain emergency response environment17.
Some SAML adaptions are not practical (easy) with actual commercial SAML implementations. Open source implementations are more suitable.
Support for front channel SAML is more suitable for use with front channel only.
Except for implicit mode, which is less secure, OIDC is tied to back channel use. Requires ports besides 443 to be open with the potential security and logistical problems associated with such use.
Existing usage Public Safety currently exclusively uses SAML. Such as LEEP for law enforcement and NIEF (and STAC) for multi-domain
HSIN, RISSNet, EPIC, Intelink-U, LEEP, etc.
Table SAML versus OIDC for Public Safety
IV. Trustmarks – An Overview The preceding section on Federated ICAM For Information Sharing gave the ICAM technical foundations that permit information sharing to occur between Public Safety, Law Enforcement, Emergency Medical Services (EMS), and associated organizations. Topics ranging from authentication to authorization and identity federation and others. Doing so while providing necessary protections for the information being shared was briefly addressed In the sub-section on “Assurance and Trust.” The Trustmark Infrastructure / Framework addresses many of the trust and the authorization aspects necessary for this PS information sharing. This Section IV provides an introduction, and Section V continues the introduction and also offers the practical set of steps in the implementation of Trustmarks.
17 See other SAML references [noted earlier], plus: OASIS, “SAML V2.0 Protocol Extension for Requesting Attribute Per Request Version 1.0,” https://docs.oasis-open.org/security/saml-protoc-req-attr-req/v1.0/saml-protoc-req-attr-req-v1.0.html
16
IV.1 Introduction18 This sub-section will present a brief primer on the trustmark framework, including a high-level summary description and a more detailed description of the anatomy of the framework, along with pointers to sources of additional information for readers who want to learn more. At a high level, the trustmark framework aims to make trust criteria transparent and explicit, so that all parties to a trusted Federated ICAM transaction can understand exactly what conformance criteria must be met for trust and interoperability to exist, as well as what assessment steps must be completed — through either a self-assessment process or a more rigorous third-party assessment — to demonstrate satisfaction of those requirements. The framework also embraces and encourages componentization and modularity around trust requirements, to promote reusability of assessment results and therefore reduce costs. Finally, the trustmark framework leverages machine-readability of artifacts to promote automation and scalability. The trustmark framework includes five key components that enable it to fulfill its goals.
Trustmark Framework Functional Model — Figure 9 depicts the trustmark framework functional model. This functional model defines the types of actors and machine-readable artifacts that comprise the framework, including trustmarks, trustmark definitions, trust interoperability profiles, trustmark defining organizations, trustmark providers, trustmark recipients, and trustmark relying parties.19
Trustmark Framework Technical Spec — The trustmark framework technical specification (TFTS) is a normative document that formally defines the trustmark framework, including technical artifact structures and rules for encoding those artifacts. The TFTS provides a foundation for wide-scale implementation of the framework.20
Library of Policy Artifacts — There exists a large and growing library of trustmark framework artifacts that faithfully represent many prominent policies and technical standards with direct applicability to the nationwide Federated ICAM and information sharing challenge. Policies and standards that are either represented today or will soon be represented include the following: National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, NIST SP 800-63-3, the FBI CJIS Security Policy, and the Health Insurance Portability and Accountability Act (HIPAA).21
18 For a more detailed introduction to Trustmarks see “Enabling Scalable, Multidimensional Trust in Heterogeneous Distributed Systems with Machine Readable Trustmarks,” Matthew Moyer et al, Georgia Tech Research Institute, March 15, 2016, https://trustmark.gtri.gatech.edu/wp-content/uploads/2017/09/trustmark-white-paper.pdf
19 For brevity, terms not defined here. To learn more, please See Section 5.2 of GTRI’s trustmark overview white paper,
available for download at https://trustmark.gtri.gatech.edu/wp-content/uploads/2017/09/trustmark-white-paper.pdf 20 The most recent version of the TFTS is available at https://trustmarkinitiative.org/specifications/trustmark-framework/1.2/ 21 This library of policy artifacts is available online at https://aapc.trustmarkinitiative.org/registry/
17
Figure 9: The Trustmark Framework Functional Model
Trustmark Framework Software Tools and Libraries — One of the core tenets of the trustmark philosophy is that standardized, machine-readable artifacts promote automation and scalability of trust management. The trustmark framework therefore includes a rich suite of software tools and libraries that enable automation for each major trustmark use case: (a) authoring of componentized trust and interoperability policies, (b) rigorous assessment of organizations and systems for compliance and conformance with applicable policies, (c) issuance and lifecycle management of trustmark artifacts based on assessment results, (d) registration and binding of trustmark artifacts to operational systems, and (e) trust management based on logical comparison of policy requirements with trustmarks. These software components exist today in various states of maturity; some are quite mature and in operational use, while others are prototypes that require substantial further development.
Trustmark Legal Framework — The trustmark framework includes a pragmatic legal framework that was modeled after the well-understood and widely adopted public key infrastructure (PKI) legal framework. This legal framework enables trustmarks to be issued and relied upon for trusted Federated ICAM transactions by allowing transaction participants to precisely understand the guarantees, liabilities, and risks inherent in the use of trustmarks.xn
IV.2 Rationale for the Trustmark Framework
18
The rationale for Trustmarks has been broadly outlined earlier in this paper, and basically is for
establishing the trust that enables a somewhat heterogeneous set of PS and LE and first responder
organizations to come together in the public good. The rationale can be summarized as:
The Philosophy of Componentized and Machine-Readable Policy Artifacts
o Policy rules for info sharing are nuanced and differ slightly based on the type of info
being shared, but there is substantial overlap in policy across a wide variety of info
sharing scenarios
o By “componentizing” policy into “right-sized” chunks, it enables and encourage reuse of
the chunks wherever they apply
o By making the reusable chunks machine-readable and expressing them in a standard
format, and developing software tools that understand the standard format, it enables a
wide range of efficiencies and conveniences that do not exist today
Design for purpose: the framework solves a portion of the challenges of Federated ICAM for info
sharing. Section III above outlined the broad set of challenges an organization faces in providing
an ICAM environment and supporting identity federation within ICAM. Such as:
o ICAM challenges included providing for authentication, authorization, identity proofing,
and more.
o Federation challenges included support for an appropriate protocol, a particular profile
within that protocol, encryption, digital signature integrity, a PKI infrastructure, and
more.
o And within the above was included trust challenges, with some of the types relating to
identity and to authentication, and for many purposes being represented by a set of
policies and procedures. The Trustmark framework provides quantification and
assurance for a complete ICAM installation, including its federation. Where NIST
security controls quantify the ICAM implementation building blocks, Trustmarks provide
a high level ICAM and Federation implementation certificattion.
IV.3 An Overview of Trustmark Terminology and the Roles Supported by the Framework
An enhanced or improved operational environment like Trustmarks carrries with it some new
terminology. Some of the immediate Trustmark terms that the reader will be interested in are:
Trustmark. A statement of conformance to a well-scoped set of identity trust and/or interoperability requirements. A rigorously defined, machine-readable statement of compliance with a specific set of technical or business/policy rules.
Trustmark Definition (TD). Specifies the formal assessment process for a Trustmark.
Trustmark Defining Organization (TDO). Develops and maintains Trustmark Definitions.
Trustmark Framework Technical Specification. Defines the normative structure and rules for Trustmark Definitions.
Trustmark Infrastructure. The overall portions of an ICAM-based authorization / access-control environment that Trustmarks takes responsibility for to create an effective and trusted operational multi-partner multi-domain information sharing environment. Often generically referred to as the “Trustmark” environment, or the “Trustmark Framework” or just “Trustmarks.”
19
Trustmark Interoperability Profiles (TIP). Expresses trust criteria as a set of Trustmarks that a Trustmark Recipient must possess, in order to meet the trust and interoperability requirements of Trustmark Relying Parties in that community.
Trustmark Provider (TP). An organization authorized to develop and issue Trustmarks.
Trustmark Recipient (TR). Receives Trustmarks, based on a formal assessment process.
Trustmark Relying Party. Any entity (organization or individual) that relies on Trustmarks as a means for establishing third-party-based trust.
IV.4 Generic Categories of Trustmark Definition (TDs) and Trustmark Interoperability Profiles (TIPs) TDs and TIPs are fundamental components of a Trustmark infrastructure. They provide an ICAM assessment for an information-sharing partner, whether an IdP or a SP. There are two ways to quantify the TDs and TIPs for a given infrastructure, and from there to proceed to derive an operational access control environment.
1. One approach, described in section IV.4.1 below, is to derive (certify) the TDs and TIPs for a given operational infrastructure based on actual existing operational characteristics. The references accompanying the next section give clear examples of the several ways that TDs and TIPS have been derived over the past several years.
2. The second approach, described In section IV.4.2, is to derive the objective TDs and TIPs needed for an operational environment based upon characteristics of the information (data) being shared along with accompanying characteristics such as privacy. The TDs and TIPs are derived as organizational objectives, based on data categories and privacy objectives (and other categories such as assurance levels and attributes), rather than being based on an existing ICAM installation. For an SP, the system owner could then take these objective TDs & TIPs and compare against their existing TD & TIP certifications (section IV.4.1) and clearly understand which security controls are necessary for implementation.
IV.4.1. TDs and TIPs Analysis/Certification For An Existing Installation Trustmarks have now been certified for enough organizations that we can use the multiple documented instances to illustrate their practical creation. The reader will see the flexibility in certifying the assurance of a federation partner. As already introduced, the core Trustmark foundations are the certification of what are called Trustmark Definitions (TD) and Trustmark Interoperability Profiles (TIPs). These are applied (certified) to a particular SP or IdP (or RP and OP). For those familiar with NIST security controls, some TD’s are based on the various security controls found in Appendix F of NIST SP 800-53r4. See Section IV.5.1 for an explanation of one sample TIP, the CJIS Security Policy. Note that in many cases instances of the types of TIPs described below will need to be combined with other TIPs to give a complete representation of a given ICAM installation. An easy way to view TDs and TIPs is to think in term of “granularity,” for the new ICAM capability that mostly shows up or fits into the following 4 categories.
20
1. Assurance Levels. Following NIST SP 800-63-3 this in turn breaks out into the following, each with values that range from 1 (least) to 3 (best)22. These assurance levels certify what values a given SP (or IdP) can support within their transaction operations.
Identity Assurance Level (IAL). How well-established or trustworthy is a person’s identity at their local (IdP) organization.
Authenticator Assurance Level (AAL). How securely did a person log into their local computer system for today’s session.
Federation Assurance Level (FAL). How secure is the identity federation session that is underway for the information exchange.
2. Impact Categories. Following NIST 800-63-3’s explanation in section 5.3 of “Risks and Impacts” and their relationship with assurance levels, such an impact can be rated from (a) Low to (b) Moderate to (c) High. For example a release by an SP of “personal safety” information could be “high” impact if there was a “risk of serious injury or death”, or “low” if, “at worst, minor injury not requiring medical treatment.”23 Some Trustmark TIP examples then would deal with topics like:
Inconvenience, distress or damage to standing or reputation
Financial loss or agency liability
Harm to agency programs or public interests
Unauthorized release of sensitive information
Personal Safety
Civil or criminal violations 3. Operational Policy. In a similar vein to impact, individual TIPs are established that deal with
ICAM-related operational policy areas like24:
Security Awareness Training
Auditing and Accountability
Access Control
Identification and Authentication
Configuration Management
Physical Protection
Personal Security
Mobile Devices, and others 4. Organizational Assertions. A fourth category of Trustmark involves certification of a complete
organization for federation operations of various types. In this case Trustmarks are issued with a broad associated certification25. They have the potential of easily supporting interoperability between similar organizations in the same domain with the same Trustmarks. In practice some of the TDs with identical names could have operational differences internally by organization, which would need to be compensated for in operation. Examples of these TDs are shown
22 For examples of TIPS that are based on assurance levels, see https://trustmark.gtri.gatech.edu/operational-pilot/trust-interoperability-profiles/tip-tree.html 23 Examples of TIPS that are based on impact categories can be seen at https://trustmark.gtri.gatech.edu/operational-pilot/trust-interoperability-profiles?offset=50&max=25&sort=name 24 An example of a TIP that certifies to operational policies is the FBI CJIS Security Policy v1,.0, https://artifacts.trustmarkinitiative.org/lib/trust-interoperability-profiles/cjis-security-policy/1.0/ . For a more general list see https://artifacts.trustmarkinitiative.org/lib/trust-interoperability-profiles/ 25 A list of, and access to, TDs that support organizational assertions can be seen at https://nief.org/trustmarks/stats/
21
below. Also, of course, the Value Propositions for Public Safety events (see Section II) involve different domains and organizations that could in turn have significant Trustmark differences.
NIEF Member Organization
NIEF attributes for SPOs
NIEF SPO
NIEF IDP
SAML IDP-Initiated SSO for RP
FICAM SAML SSO for RP
SAML Trust and Security
NIEF SPO Requested Attributes
NIEF IDP and AP Attribute Encoding
The above four broad types of TIPs and TDs provide an excellent description of the underlying trust infrastructure of an organization that can be used to determine trust between federation partners. The TIPs and TDs are machine readable for real-time use (next section) and are scalable. While it will not be unusual to have a hundred or so TIPs (and sub-TIPs) for the certification of an organization, and hundreds of TD’s, the Trustmark infrastructure is quite manageable as:
Trustmark Providers (TPs) are trained to efficiently certify an organization
There can be high-level TIP’s that can certify in a single TIP a complete organization’s ICAM operation. An example of this is the FBI’s “CJIS Security Policy v1.0” TIP referenced earlier, with all the other probably hundred or so sub-TIPs (and sub-sub-TIPS and TDs and security controls etc.) being under the main TIP. See Section V for more on this.
IV.4.2. Trustmarks Derived Based On Operational Requirements / Objectives In some situations, rather than derive (certify) the TDs and TIPs for a given installation, it will make more sense to derive the TD and TIP objectives that are required for a given transactional environment. For example, an SP wishing to share data with partners can derive, based on the data categories involved and based on privacy requirements, the TD and TIP values necessary to allow the information to be shared. There may likely be a number of sets of TDs and TIPs, one for each of the types of information to be shared, as different types of information will require different levels of protection. Beyond data categories, there can also be established TIPs and TDs that relate to other operational considerations, such as Identity Proofing, Authenticator Assurance Levels, user attributes, and other factors that make up an operational ICAM information sharing system. The following will illustrate the derivation of Trustmarks (TDs and Tips) for Service Provider data category objectives.
1. Rough Data Categories. The NIST “Guide for Mapping Types of Information and Information Systems to Security Categories”26 is a good starting point to establish a set of rough data categories as a function of impact levels. The impact levels (low or moderate or high) are
26 NIST, SP 800-60 volume 2, “Guide For Mapping Types of Information and Information Systems to Security Categories”, Appendices, August, 2008, https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-60v2r1.pdf
22
expressed for each of the 3 impact categories (C – Confidentiality, I – Integrity, and A – Availability) as described in the NIST FIPS 19927.
2. Detailed Data Categories. Beginning with the rough data categories, one can then use the NIST IR 813528 to obtain the set of detailed data categories appropriate for the data that a SP intends to share.
3. Minimal and Ideal Risk. A next step in this process is to establish Minimal Risk Profile and Ideal Risk Profiles for all the types of detailed data gathered in the preceding step. At this point the complete set of data categories, based on CIA plus the two types of risk, has been established.
4. Security Control from Data Categories. The next step is to access NIST SP 800-53r4, Appendices D and F, and extract all the security controls that pertain to the data categories being analyzed based on matching the CIA values for the data categories with the CIA values of the security controls. Note that each security control will also have an associated Implementation Priority, or Tier, associated them to help differentiate their status.
a. The security controls will also include some associated with privacy considerations. 5. Rolled-Up TDs and TIPs. The final step in this approach to Truystmark derivation is to document
all the TDs that were derived in the above steps. This is now a clear, machine-readable, normative description of the security and trust objectives for the data-sharing organization.
IV.5 Trustmark Examples As indicated above, Trustmark certifications have been established for multiple organizations over several years. While software libraries and development tools to support the Trusrmark operational needs are still in the works, some actual certifications are available to give a good operational view. As the saying goes, “a picture is worth a thousand words”. IV.5.1 Example of an Organizational Assertion – CJIS Security Policy This operational example was referenced in the preceding sub-section and will be expanded upon here to show the rich content that it contains in documenting and certifying security policy within the FBI’s Criminal Justice Information System (CJIS)29. IV.5.1.1 Highest Level TIP: The base CJIS Security Policy TIP is a roll-up of a general family of 17 composed TIPS addressing items such as Roles and Responsibilities, Information Exchange Agreements, Protections, etc. This highest level TIP is basically an agglomeration of a family of TIPS addressing various security features necessary in the successful federated operation with the CJIS trust environment. The detailed-view (17 parts) of the Trust Expression for the highest level TIP under discussion (CJIS Security Policy) is: CJISSecurityPolicySection1.3,RelationshiptoLocalSecurityPolicyandOtherPoli
cies AND
TIP_CJISSecurityPolicySection3.2,RolesandResponsibilitiesforAgenciesandPar
ties AND
TIP_CJISSecurityPolicySection4.2,AccessUseandDisseminationofCriminalHistor
27 NIST FIPS 199, “Standards for Security Characterization of Federal Information and Information Systems,” https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf 28 NIST NISTIR 8135, “Identifying and Characterizing Data Types for Public Safety Mobile Applications,” https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8135.pdf 29 For more detail see “Trustmark Initiative, CJIS Security Policy,v1.0,” https://artifacts.trustmarkinitiative.org/lib/trust-interoperability-profiles/cjis-security-policy/1.0/
23
yRecordInformationCHRINCICRestrictedFilesInformationandNCICNonRestrictedFi
lesInformation AND
TIP_CJISSecurityPolicySection4.3,PersonallyIdentifiableInformationPII AND
TIP_CJISSecurityPolicySection5.1,PolicyArea1:InformationExchangeAgreements
AND
TIP_CJISSecurityPolicySection5.2,PolicyArea2:SecurityAwarenessTraining AND
TIP_CJISSecurityPolicySection5.3,PolicyArea3:IncidentResponse AND
TIP_CJISSecurityPolicySection5.4,PolicyArea4:AuditingandAccountability AND
TIP_CJISSecurityPolicySection5.5,PolicyArea5:AccessControl AND
TIP_CJISSecurityPolicySection5.6,PolicyArea6:IdentificationandAuthenticati
on AND
TIP_CJISSecurityPolicySection5.7,PolicyArea7:ConfigurationManagement AND
TIP_CJISSecurityPolicySection5.8,PolicyArea8:MediaProtection AND
TIP_CJISSecurityPolicySection5.9,PolicyArea9:PhysicalProtection AND
TIP_CJISSecurityPolicySection5.10,PolicyArea10:SystemandCommunicationsProt
ectionandInformationIntegrity AND
TIP_CJISSecurityPolicySection5.11,PolicyArea11FormalAudits AND
TIP_ CJISSecurityPolicySection5.12,PolicyArea12PersonnelSecurity AND
TIP_CJISSecurityPolicySection5.13,PolicyArea13MobileDevices
IV.5.1.2 Second-Level TIPs The 17 second-level TIPs in turn have 51 third-level TIPs within them. (As well as approximately 630 TDs in total – see below.) As an example, the first of the second-level TIPS is:
CJIS Security Policy Section 1.3, Relationship to Local Security Policy and Other Policies Which in turn has one third-level TIP and two TDs:
CJIS - Development, Maintenance, and Dissemination of Security Procedures CJIS - Local Policy Does Not Detract From CJIS Security Policy Organization's Policies Consistent With Applicable Legal Requirements
As another example, the second of the second-level TIPS is: CJIS Security Policy Section 3.2, Roles and Responsibilities for Agencies and Parties
Which in turn has 8 third-level TIPs: CJIS Security Policy Section 3.2.1 CJIS Security Policy Section 3.2.2 CJIS Security Policy Section 3.2.3 CJIS Security Policy Section 3.2.6 CJIS Security Policy Section 3.2.7 CJIS Security Policy Section 3.2.8 CJIS Security Policy Section 3.2.12
IV.5.1.3 Third-Level TIPs: As indicated, in some instances a second-level TIP generates into third level TIPs as well as TDs. In the feature under study (CJIS Security Policy) there are 80 third-level TIPs. As an example, the first of the third-level TIPs for CJIS is:
CJIS - Development, Maintenance, and Dissemination of Security Procedures Which in turn has 51 TDs under it:
Documented Access Control Procedures Documented Security Awareness and Training Procedures Documented Audit and Accountability Procedures
24
Documented Security Assessment and Authorization Procedures Documented Configuration Management Procedures Documented Contingency Planning Procedures Documented Identification and Authentication Procedures Documented Incident Response Procedures Documented System Maintenance Procedures (…and 42 more)
IV.5.1.4 Fourth-Level TIPs
In some instances a third-level TIP generates into fourth-level TIPs as well as TDs. In the feature under study (CJIS Security Policy) there are 123 fourth-level TIPs. As an example, the first of the fourth-level TIPS for CJIS is: CJIS - Establish Incident Response and Reporting Procedures Which in turn has 5 TDs under it: CJIS - CSA ISO Establishes Security Incident Response Procedures Documented Incident Response Procedures Incident Handling – Detection Incident Handling – Analysis Forwarding of Security Incident Information IV.5.1.5 Fifth-Level TIPs
In some instances a fourth-level TIP generates into fifth-level TIPs as well as TDs. In the feature under study (CJIS Security Policy) there are 74 fifth-level TIPs. As an example, the first of the fifth-level TIPS for CJIS is: CJIS - Information Handling and Storage Procedures Which in turn has 5 TDs under it: Media Storage - Physical Control Alternate Storage Site Safeguards Alternate Processing Site Security Remote Access | Protection Of Information Monitoring For Information Disclosure Protection Of Information At Rest | Cryptographic Protection Transmission Confidentiality And Integrity | Cryptographic Protection Transmission Confidentiality And Integrity | Physical Protection IV.5.1.6 Sixth-Level TIPs
In some instances a fifth-level TIP generates into sixth-level TIPs as well as TDs. In the feature under study (CJIS Security Policy) there are 3 sixth-level TIPs, each with a single TD. As that example, the first of the sixth-level TIPS for CJIS can be fully indicated as: CJIS Security Policy
CJIS Security Policy Section 5.6, Policy Area 6: Identification and Authentication CJIS Security Policy Section 5.6.2
CJIS Security Policy Section 5.6.2.1 CJIS - Complexity Requirements For PINs As Standard Authenticators
CJIS - Password Complexity Requirements TD: Defined Minimum Password Complexity
CJIS - Secure Password Transmission
25
TD: Cryptographic Protection of Transmitted Passwords CJIS - Password and PIN Entry TD: Authenticator Feedback
IV.5.1.7 TrustMark Definitions: The final defining level of the string of trust within any given TIP is found in the TrustMark Definitions. The CJIS Security Policy in total has approximately 630 TDs within its structure.
V. Implementing the Trustmark Infrastructure for managing Federated ICAM and Information Sharing Trustmarks address the underlying ICAM authorization and overall trust issues associated with PS organizations that need to share information. By documenting / certifying to various aspects of the ICAM and identity federation implementations of organizations within an information sharing partnership, the Trustmark Infrastructure (i.e., Trustmarks) increases the granularity of available trust information to permit better operational decisions including authorization decisions. Overall, it can be stated that Trustmarks:
Enable public safety agencies to manage their info sharing trust relationships with their mission
partners to a higher degree of granularity than previously available.
Anticipate and provide solutions to the challenges of info sharing and its associated access control
(i.e., authorization) on a wide scale, because they are designed to solve real-world info sharing
problems encountered by actual public safety agencies
Have the potential to enable public safety agencies to share info on a scale never seen before.
V.1 Overall Impact on ICAM Implementation with Use of Trustmarks
The organizational impact of implementing the powerful enhanced trust and authorization granularity
that the Trustmark infrastructure represents is still being resolved while software libraries and
development tools are being established. But this section will present an overview of the “how to” with
use of Trustmarks to give the reader a look at the implementation steps.
Implementation begins with establishing the types of organizational trust certifications
described in preceding sections. There are lots of Illustrations available, some given and
illustrated and explained and footnoted in this paper, and others available elsewhere.
Actual implementation, after Trustmark certifications are established, will then proceed to the
authorization, or access control, policy-based rule stage.
With the expected differences between partnering organizations, such as fire versus law
enforcement versus medical versus utilities etc, there will be significant differences between the
Trustmark infrastructures of the various participating organizations. Access control rules will be
important and non-trivial.
Policies that control access to information by federation partners are eligible to be installed at
the identity federation protocol level as well as at the RP/SP’s ICAM infrastructure level where
traditional ABAC occurs.
The following subsection will give a little more insight into this “how to” topic for Trustmarks. Section
V.3 gives an implementation checklist.
V.2 Trustmark Implementation Details
26
Operation with Trustmarks is easy to conceptualize, with the main recognition needing to be that there is an increase in “granularity entropy” relative to older style ICAM identity federation installations. Trustmarks presents an elevated view of the capabilities of SP and IdP’s, and that increase in granularity means that the ICAM installation also has increased functionality that is programmed into it as described below. V.2.1 Differences – Organization to Organization Operational granularity starts by recognizing that each organization within an operational partnership will likely have different Trustmark certifications. Such as:
Within one functional type of organization, such as law enforcement and sites like Texas DPS and FBI CJIS and LA County PD and Chicago PD, might have limited differences among their hundreds of TDs and TIPs that they are certified for. In part based on the resources expended on their individual implementations.
Even within the FBI CJIS community, with the FBI CJIS TIP mentioned above, not all local and state police departments will be equally configured for federation (extrapolated based on differences that have traditionally been present).
For events involving information sharing between Public Safety and Law Enforcement organizations of various types, such as intelligence sharing or such as at an emergency event involving a bombing or natural disaster, more granularity/differences in their TIPs is a given.
o For example, where one federation partner is Trustmark certified for a TIP of AAL 3, another partner (either SP/RP or IdP/OP) might only be certified for AAL 2. Incompatibilities like this increase the granularity entropy.
V.2.2 Trustmark Effects on ICAM Installations With these Trustmark differences, the impact of Trustmarks to a current type of identity federation installation, both SP/RP and IdP/OP, will show up as increased granularity in the following 2 functional areas that are common to all identity federation installations.
1. Federation Protocol installation and configuration. Some of the increased ICAM granularity will be implemented at the SAML or ODIC protocol level, probably primarily for the introduction of assurance levels. In the case of NIST SP 800-63-3, as introduced above, this means IAL, AAL, and FAL.
For example, at the protocol implementation level, the SP must inspect that all incoming assurance levels do not exceed the SP’s approved Trustmark certification level. Or the IdP must add such inspections. These issues can arise for IdP-initiated SAML Web SSO, and for the use of authentication context in SAML or as proposed by the OIDC EAP working group (for RP/OP use). Alternative this protection (and for the next example) can be considered for implementation at the IdP
As another example, the SP/RP, at the protocol level, should inspect incoming assertions for IAL and AAL to ensure adherence with the SP’s certified Trustmark capabilities.
For a third example, there needs to be coordination between SP/RP and IdP/OP to ensure that assurance levels to be provided to the SP/RP do not exceed its Trustmark-certified limits.
2. ICAM Authorization / Access Control. The SP/RP will use ABAC (Attribute-Based Access Control), with rules established for its protected resource, and with information provided by the IdP/OP, to determine which of its resources a particular user can access
For the impact categories described above, the assurance levels provided by the IdP will determine which resources the user is permitted to access. The tables from NIST SP 800-63-
27
3, reproduced in Appendix A, establish the assurance levels that the SP’s ABAC system will insist upon for the user before allowing access.
o For example, using the AAL table in Appendix A, a user wishing access to a document that could have “moderate” impact to Public Safety will need to have IAL 3 and AAL 3. Most other moderate or low impact resources only require IAL and AAL values of 1 or 2. High impact resources will require a 3.
For the Operational Policy types of Trustmark TIPS the SP/RP will have rules relating access to meeting certain requirements, and the IdP/OP will provide the mandatory attributes to enable an access decision to be made.
o For example, using a few of the TIPs that make up the CJIS Security Policy, v1.0 TIP, access to a particular resource type could require certain training (Security Awareness Training) or their mobile device could have certain configuration requirements or security restrictions (like encryption key length and logging).
For the Organizational Assertions types of TDs, their coverage has the potential for broader applicability, with adjustment of the organizational ABAC rules accordingly. But differences, like with attribute sets, would need to be resolved, and differences across organizational types is TBD.
o For example, two organizations that both have “NIEF Member Organization” and “SAML Trust and Security” certification, with one certified as “NIEF SPO” and one certified as “NIEF IDP” could be considered qualified to exchange at least certain types of information.
V.3 Implementation Checklist30 The following is a high-level checklist of the steps involved for an organization that implements the use of Trustmarks within their ICAM infrastructure to enhance the trust and granularity, and develop the authorization infrastructure, associated with information sharing among PS partners. The first two items in the list are either already established or are being worked on today, such as described earlier in this paper or via footnotes. The last few items in the checklist (as well as earlier parts) will benefit from software libraries, developer support, and community organizational and interoperability support that will be developed over time. A future expansion of this implementer white paper will be issued when more information is available on the contents of this list and on a complete set of implementation support facilities. This is expected to include tools to automate the authorization, coordination, integration, access control rule creation or documentation, and other processes.
1. Determine Trust and Security Objectives. Federal IT installations are already quite familiar with this step. Establish the security objectives via use of the appropriate FIPS materials and appropriate NIST Special Publications. Such as with the use of NIST SP 800-53 and FIPS 199. Multiple ICAM categories are involved, such as data, privacy, assurance, attributes, and more. The net result will include a characterization of the perhaps 500 or 600 or more security controls that its installation requires as well as other specifications. Be prepared from a Risk Management Framework / Impact Level perspective as already discussed.
30 Additional background on the contents of this checklist can be found in the GTRI paper referenced earlier on “Enabling Scalable Multidimensional Trust in Heterogeneous Distributed Systems with Machine-Readable Trustmarks”
28
a. For example, an organization with access control experience could already know that it requires NIST SP 800-53r4, Appendix F, Access Enforcement of AC-3-(3)-(b)-(5) to restrict “changing the rules governing access control.”
b. Or an SP organization doing an analysis of its data categories and privacy requirements, as described earlier in Section IV.4.2, will derive the security controls necessary for its operational environment.
2. Establish Trustmark Baselines. a. Establish SP Local Trustmark TD and TIP Baselines31. This is an important step for
uniformity of IT, ICAM, and identity federation infrastructure specifications among PS partners. Section IV.4 above explains how this is based on either
(1) A certification of an existing infrastructure, or (2) An analysis of the TD and TIP requirements placed on an information-sharing
organization b) Obtain all Partner Certified Trustmarks. The trust associated with a partner to a
transaction is important to know. Whether an organization is an IdP or a SP, it will need in advance the Trustmarks (TDs and TIPs) for all its transaction partners. The next implementation step will contain a little more information on this.
(1) For example, a SP will need to understand what levels of assurance it can accept from an IdP
(2) And an IdP will need to understand which types of attributes it is willing to send to a given SP.
3. Prepare Your Itemized Local RP/SP TDs&TIPs / Authorization / Access Control Information. Using Trustmarks or other machine-readable formats as appropriate. For the following categories:
(1) Objective TDs & TIPs for the SP’s Data Characterization/Containerization32. ICAM Security Controls. All data stored within the SP will be characterized by TDs and TIPs (see section IV.4.2). Each of the possible 54-types of data category storage containers will be assigned / correspond-to a set of objective security controls as defined in NIST SP 500-53r4. NOTE that at this point these security controls (TDs) are “objectives”; the next step will convert all such objectives to true, certified, Trustmarks.
(2) TDs and TIPs of any potential IdP partner. The characteristics of the IdP will be important to the decision-making of the SP, for decisions on (a) revealing existence of information, and (b) allowing access and retrieval of resources. The TDs and TIPs of each potential transaction partner will be made available to the SP.
(3) Attributes. With a multi-domain type of partnership, such as for the emergency response value propositions of SAFECOM-NCSWIC, an estimate is 50 to 60 different user attributes. An SP’s rule set will accommodate all. Representation with TIPs and TDs could likely be one TD per attribute.
(4) Assurance Levels. Following NIST SP 800-63 guidelines, this will be 3 levels for each of the 3 assurance parameters: Identity Assurance Level (IAL), Authenticator Assurance Level
31 For other examples of TIPs and TDs beyond those given in this paper, see: “Trustmark Interoperability Profiles” https://trustmark.gtri.gatech.edu/operational-pilot/trust-interoperability-profiles/, “GTRI NSTIC Trustmark Pilot”, https://trustmark.gtri.gatech.edu/, “Trustmark Initiatives” https://artifacts.trustmarkinitiative.org/lib/, and “CJIS Security Policy” at https://artifacts.trustmarkinitiative.org/lib/trust-interoperability-profiles/cjis-security-policy/1.0/ 32 For examples of TIPs and TD involved in creating authorization policies, see the references in the preceding footnote.
29
(AAL), and Federation Assurance Level (FAL). TDs and TIPs can be generated to represent all three parameters.
(5) Digital Rights Management. The concern here is providing information to a user who might subsequently email it to someone else, copy it, print it, etc. Some control over this is expected to be available based on certain security controls.
(6) Privacy. Legal and other considerations will be incorporated.
(7) Security. Considerations of encryption and integrity and digital signature for data and its transport.
(8) Environment. Considerations such as IP address / location of the user, and time of day.
(9) FirstNet. Operational considerations for the FirstNet broadband communications environment used by emergency responders will be important and is TBD. Impact areas include priority, access control, privacy, security, and possibly others.
(10) Legal Agreements for Operational Use33. Legal agreements will be put in place for all partners within a Trustmark-based information sharing environment. This will not only support the desired level of sharing, but will also protect all involved should disputes arise in the future.
4. Convert the Objective TDs & TIPs to Actual Implemented TDs & TIPs. Some of the TDs & TIPs described in the preceding step (V.3.3) followed the analysis / objective of data categories as laid out earlier in Section IV.4.2. There will be a need to convert those objective TDs and TIPs to actual implemented TDs and TIPs. In some cases where the SP already had its TDs and TIPs certified for a previous project need, the certification for this step is already done! In other cases, conversion is necessary. A few examples (in alphabetical order) of the broad categories of TDs (security controls) that will be implemented are shown below. See NIST 800-53 Appendices D and F for an itemization of the full set of over 600 security controls. a. Access Control b. Awareness and Training c. Audit and Accountability d. Security Assessment and authorization e. Configuration Management f. Contingency Planning g. (More)
5. Implement Authorization Engines a. Implement the SP Access Control / Authorization Engine. Integrate all the itemized
categories of Trustmarks (or other documentations) from the preceding two steps into the actual commercial (or open source) ABAC system. Create the actual ABAC environment of the SP.
(1) At the logical access control level, there could easily be hundreds or thousands of rules involved.
(2) Potential impact at the protocol level for an SP is TBD. (See the next step for the IdP.)
b. Implement IdP ICAM functionality. An IdP will need to be up-to-date on the Trustmark (TDs and TIPs) characteristics of all potential SP partners.
(1) At the logical operational level, the IdP will need to understand what user assurance levels will be required. Such as for step-up authentication use.
33 See the paper “Legal Aspects of the ICIF”, https://icif.standardscoordination.org/legal-aspects-of-the-icif/
30
(2) At the protocol level the IdP will need to control which attributes can be provided to any particular SP.
6. Configuration Management / Integrate Trustmark Updates. There will be a continual, ongoing CM responsibility for the TDS and TIPs of all potential PS partners. Any of the characteristics described in step 4 are subject to change. Provide for both periodic and real-time updates of Trustmarks and the Trustmark infrastructure.
a. Establishment of some type of CM service for a partnership will need to be considered. Perhaps a centralized Public Safety service established to facilitate this, to support additions, deletions, changes, expirations, etc., on at least a daily basis.
VI. Quick-Start Guide: What Do You Want To Do? As explained in the preceding sub-section on the Implemention Checklist, there are only six steps involved in implementation of Trustmarks. Some are very suited to automating via a Trustmark toolset, and in fact will be dependent on that toolset for their efficient utilization. From the perspective of a quick-start guide, when available it will likely be an elaboration of the six steps described in the Trustmark Implementation Checklist. Step 3 in the checklist on “Prepare Your Itemized Local RP/SP TDs&TIPs / Authorization / Access Control Information” will likely be the most labor intensive. As envisioned in the white paper on “Enabling Scalable Multidimensional Trust . . .” referenced earlier, in its “Long-Term Vision” section, the expectation for Step 3 is:
Organizations participating in the marketplace can acquire TMs [Trustmarks] from a variety of third-party TPs [Trustmark Providers] according to a competitive market model, and each TP offers TM assessment and issuance services according to its business goals and its areas of assessment expertise. When appropriate, organizations can even make use of self-issued TMs based on a self-assessment process,34 provided that partner organizations are willing to accept the self-issued TMs.
VI.1 How to Find Existing Requirements
TODO: Develop content.
"I want to identify any existing published policy requirements that my agency and its mission partners
must satisfy when sharing information in <Scenario X>."
VI.2 How to Define New Requirements
TODO: Develop content.
"I want to define and publish new policy requirements that my agency and its mission partners must
satisfy when sharing information in <Scenario X>."
VI.3 How to Do a Self-Assessment
34 Version 1.2, November 6, 2017, https://trustmarkinitiative.org/specifications/trustmark-framework/1.2/tfts-1.2.pdf
31
TODO: Develop content.
"My agency wants to undergo a basic self-assessment to demonstrate its compliance to info sharing policy
requirements pertaining to <Scenario X>."
VI.4 How to Do a Third-Party Assessment
TODO: Develop content.
"My agency wants to undergo a more rigorous third-party assessment to demonstrate its compliance to
info sharing policy requirements pertaining to <Scenario X>."
VI.5 How to Verify Partner Compliance
TODO: Develop content.
"My agency wants to verify that its mission partners comply with the published info sharing requirements
pertaining to <Scenario X>."
VI.6 How to Reuse Prior Assessmentrs
TODO: Develop content.
"My agency has already demonstrated compliance with the info sharing requirements pertaining to
<Scenario X>, and we would like to reuse our prior assessment results to demonstrate that we satisfy
some or all of the info sharing requirements pertaining to <Scenario Y>."
VI.7 How to Develop an Information Sharing RFP
TODO: Develop content.
"My agency wants to develop an RFP for building Federated ICAM capabilities for <Scenario X> using
the trustmark framework, and we need to know what requirements to include in the RFP language."
VI.8 How to Become a Third-Party Assessor
TODO: Develop content.
"I am an auditor, and I would like to become certified/qualified to perform rigorous third-party
assessments of public safety agencies and issue trustmarks to those agencies based on assessment results."
VI.9 How to Manage a Partner Data Breach
TODO: Develop content.
"My agency has a mission partner agency that recently suffered a data security breach, and we would like
to know when we can confidently resume info sharing with the partner agency."
32
VII. Purpose of the Artifacts
TODO: Develop content. Purpose is:
i. Provide a ready-to-use library of trustmark framework policy artifacts covering the most
common PS use cases.
ii. Enable PS agencies to quickly get up to speed with the framework.
iii. Other?
VIII. Other Available Resources
At the pages below, we provide information and links to other resources that can help public safety
agencies take full advantage of the guidance and artifacts that we have developed.
Policy and Agreement Templates
Information and Pilot Prograns
Information on Funding Opportunities
VIII.1 Policy and Agreement Templates
TODO: Develop content.
VIII.2 Information on Pilot Programs
TODO: Develop content.
VIII.3 Information on Funding Opportunities
TODO: Develop content. Appendix A. Assurance Level Requirement Tables from NIST SP 800-63-3 These tables from the NIST SP 800-63-3 document (with its numbering) help a Service Provider to understand which assurance level applies to which data.
33
34
35
