Every ISE that is in operational use today must fill a fundamental gap between the basic infrastructure provided by commodity Internet technologies and the additional layers of infrastructure required to support trusted information sharing and safeguarding. The public Internet, and other private networks that leverage commodity Internet technologies, provide addressing (DNS), routing and reliable transfer of “bits on the wire” (TCP/IP), and basic session-level encryption (TLS) through a public key infrastructure (PKI). But this commonly available stack of commodity Internet technologies does not include any solution or framework to support many of the additional requirements that matter for an ISE. Most importantly, there exists no commodity technology to support the expression, proof-of-satisfaction, or enforcement of the semantic properties that underpin trust among participants within an ISE. These requirements typically include compliance with appropriate organizational security, privacy, and identity assurance policies and practices. They often also include satisfaction of specific “bona fides” requirements, e.g., proof of organizational legitimacy or proof of membership in a specific community, such as the U.S. law enforcement community. In addition, these requirements also can include conformance and interoperability requirements related to the semantics of the data exchanged, e.g., payload schemas, attribute schemas for user identity attributes, etc.
Adequately filling this gap – the gap between what is offered through commodity technologies and what is required for trusted information sharing and safeguarding – is a challenge that has faced ISE implementers for decades. Until now, this gap has been filled through a variety of unique, single-purpose-built monolithic solutions that were founded on differing assumptions and differing requirements identified by their various implementer communities. In addition, even in cases where assumptions and requirements may have been similar, implementers have tended to reinvent similar solutions that nevertheless are incompatible due to gratuitous variation, i.e., implementing solutions that are functionally equivalent but differ in unimportant or minor details. (See breakout box below.) This has led to a lack of wide-scale interoperability at the technical, functional, security, and policy levels.
[stextbox id=”info” caption=”Gratuitous Variation Considered Harmful!“]The term gratuitous variation refers to the practice of designing and building a new solution (policy, agreement, technical specification, or live system) that differs from other existing solutions in one or more trivial details, but otherwise accomplishes the same basic objective as the other solutions. The problem with gratuitous variation is that it causes unnecessary technical incompatibilities and conditions of non-interoperability that are grounded not in fundamental differences in requirements or design goals, but rather in minutiae. When interoperability is the goal, gratuitous variation is to be avoided.[/stextbox]
The primary purpose of the ICIF is to fill this gap properly and enable wide-scale semantic interoperability and trust across the broader ISE. But to fill the gap, the ICIF must provide a standard framework and roadmap so that independent ISE efforts and participants know how to plug in and leverage the framework for use with their respective unique sets of trust requirements, just as they can do today with the Internet. In essence, the ICIF needs be agile and flexible enough to support a wide range of trust, policy, and interoperability requirements across all present and future Information Sharing and Safeguarding (IS&S) stakeholders, all within a common framework. To meet this goal, the ICIF leverages an Assertion-Based Architecture (ABA).
The Concept of Trusted Assertions Within an Assertion-Based Architecture
The ABA concept is based on the concept of trusted assertions that convey claims of information about their subjects. Assertions are commonly used today across many aspects of our lives in the physical world. For example, a driver’s license constitutes an assertion about an individual, issued by a well-known and trusted authority (e.g., a state department of motor vehicles), claiming that the individual identified on the license is allowed to operate a motor vehicle in accordance with state laws. Similarly, an employee ID conveys the claim that a particular individual is an employee of a specific company, and a diploma conveys the claim that a specific individual has graduated from a specific school or university. In the online world, examples of assertion-based frameworks and systems include PKI, SAML, OAuth, and others. In most of these examples, assertions are made by organizations about individuals. But more generically, assertions can be made about many different types of entities, including organizations, persons, computer systems and applications, and devices.
To meet our needs and fill the gap of semantic interoperability and trust between organizations in the ISE, the ABA leverages digital assertions about organizations and about computer systems and applications. These assertion definitions can cover a wide range of topics, but would typically pertain to concerns related to trust and interoperability, e.g., organizational and system security policies and practices, privacy policies and practices, organizational “bona fides” (i.e., organizational legitimacy and integrity), user identity assurance policies and practices, conformance to various normative technical specifications, and others.
One critical implication of an assertion-based approach to trust is that assertions tend to push decisions about trust and risk to the “edges” of the system, rather than centralizing those decisions within a “smart” centralized policy engine. Centralized trust is neither realistic nor desirable in a distributed environment composed of many autonomous actors. See the breakout box below for more about this topic.
[stextbox id=”info” caption=”Empowering the Edges: A Timeless Network Design Principle“]One of the fundamental principles embraced by the designers of the Internet is that a network should have smart edges and a dumb core. In the case of the Internet, this means that the network’s only purpose is to move bits from point A to point B. All other, higher-level concerns, such as application protocols, data semantics, security, etc., are squarely out of scope at the “core” of the network.
For example, routers on the Internet have no concept of the World Wide Web. They do not understand the HTTP or HTML standards. They simply move bits from one computer to another as instructed. The fact that some of those bits represent HTTP messages and HTML content is important only at the endpoints, where the data is encoded and decoded by applications such as web servers and web browsers.
By keeping the core of the Internet “dumb” with respect to higher-level constructs, the Internet’s designers were able to make it very good at doing its job by keeping its job very simple. This same principle — empowering the edges and keeping the middle simple — is a sound design principle for the ISE. Rather than trying to centrally manage or mandate trust rules for all ISE participants, we leverage an assertion-based framework that enables the “edges” of the network (i.e., the individual ISE participants) to make autonomous trust and risk decisions about each other based on their needs.[/stextbox]
A Simple Assertion-Based Example
Consider the following simplified example of how assertions would be used within the ICIF to underpin trust and facilitate information sharing. Suppose that Organization A holds Suspicious Activity Report (SAR) data and is willing to share its SAR data with U.S. law enforcement agencies that comply with the FBI CJIS Security Policy (CJIS SP). Suppose that Organization B is a U.S. law enforcement agency and complies with the CJIS SP, but does not have a prior relationship with Organization A. Using the ABA, Org. B can provide compelling evidence to Org. A that it is a U.S. law enforcement agency and complies with the CJIS SP, in the form of one or more digital assertions. Org. A can then inspect the assertions, verify their legitimacy and trustworthiness, and make a trust decision based on them. If Org. A believes that the assertions are legitimate and trustworthy, then it can permit Org. B to see its SAR data.
Assertion-Based Trust for Data Exchange
Despite its simplicity, this example scenario raises some critical issues regarding how the ABA operates and how it enables such a transaction to occur in a trusted manner. Consider, for example, the following questions related to the trustworthiness of digital assertions.
- What person or organization made the assertions that Org. B is a U.S. law enforcement agency and complies with the CJIS SP?
- Is the issuer of the assertions trustworthy? Is the issuer competent to assess whether Org. B actually is a U.S. law enforcement agency? Is the issuer competent to assess whether Org. B actually complies with the CJIS SP?
- How can Org. A be certain that the assertions were actually made by the purported issuer, and not merely forged by Org. B?
- Assuming that the assertions are not forged, how can Org. A be certain that the assertions were actually made about Org. B? In other words, how can Org. A be sure that Org. B is the actual subject of this assertion, and not fraudulently trying to leverage an assertion made about a different organization?
- When were the assertions made? Were they made recently? Or are they so old that they may not be accurate anymore? Might they have been revoked already by the issuer?
- How does Org. A extract the correct semantic meaning from the assertions that it receives about Org. B? What syntactic schemas and semantically meaningful identifiers exist within the assertions that allow Org. A to determine that the assertions convey claims about Org B. with respect to its status as a U.S. law enforcement agency and its compliance with the CJIS SP?
These questions, and other similar questions not listed here, highlight the need for assertions in the ABA to meet certain fundamental requirements. For example, an assertion must contain a digital signature to prevent tampering with its contents. An assertion must clearly and precisely identify its issuer and its recipient with globally unique identifiers. An assertion must clearly and precisely convey its semantic meaning. An assertion must contain an issue date and an expiration date, to allow for checks of its freshness or staleness, as well as a mechanism to allow for real-time revocation checking. And an assertion must conform to a standard syntactical structure, or schema, to permit machine-readability and interoperability. To meet this need, there exists a normative specification that defines standard data structures for assertions and all other data objects within the ABA.
The Semantics of Assertions and Assertion Definitions: High-Level vs. Low-Level
As we have noted, for Org. A to trust assertions made about Org. B, Org. A must be able to clearly understand and trust the semantic content conveyed by each assertion. Within the ABA, an assertion conveys its semantic meaning by specifying its assertion type. Assertion types are akin to data types or object types in a programming language, and each assertion type is formally defined by an Assertion Definition (AD) that unambiguously describes the meaning of that assertion type. [1] Each AD must convey sufficient semantic precision about its assertion type, so that the ISE participants that rely upon assertions of that type can understand them unambiguously and use them as a basis for making trust decisions. To ensure clarity of assertion definitions and minimize ambiguity, each AD includes a set of normative requirements, or issuance criteria, that a subject must meet to receive an assertion of that assertion type. In addition, to further minimize ambiguity, each AD prescribes a specific sequence of assessment steps that a would-be issuer of an assertion must follow to assess whether a subject meets the specified issuance criteria and qualifies to receive the assertion. Finally, ADs must be published in well-known locations (i.e., at well-known URLs) and in a standardized format, so that all ISE participants can locate them and understand them.
The ABA places no formal constraints on the semantic content that can be conveyed by an AD, and in theory, an AD can represent any normative requirement or set of multiple requirements, as long as it clearly specifies the assessment steps that assessors must follow to perform assessments on subjects. Thus, for example, an AD can convey a relatively simple and low-level requirement, e.g., “Maintain Physical Access Control to Data Centers at All Times”, or a more complex, higher-level requirement, e.g., “Comply with the Entire FBI CJIS Security Policy.” Each of these example ADs could be used within the example data sharing scenario that we presented earlier. The high-level example would be sufficient in itself for demonstrating compliance with the CJIS SP. And the low-level example could be used in conjunction with other low-level assertion definitions to create a bundle of assertion definitions that represent compliance with the CJIS SP in the aggregate. When we consider this particular example scenario in isolation, either approach would work, and using a single higher-level AD instead of a bundle of many lower-level ADs may appear to be simpler and more elegant. But one of the requirements of the ICIF is to enable participants to engage in many different information sharing use cases spanning many different communities of interest and many different policies and requirements. So, for example, suppose that Org. B needs to exchange SAR data with Org. A, and it also needs to exchange offender health record data with Organization C. This new use case between Org. B and Org. C is subject to HIPAA data security and privacy requirements, and now Org. B must demonstrate compliance with both the CJIS SP and HIPAA. The higher-level example AD (“Comply with the Entire FBI CJIS Security Policy”) has no value in the HIPAA use case, but the lower-level example (“Maintain Physical Access Control to Data Centers at All Times”) could be reused as part of a new bundle of assertion definitions that represent compliance with HIPAA requirements. This multi-use-case scenario illustrates the potential value for reuse associated with lower-level assertion definitions. If the ADs themselves can be reused and re-bundled in new ways to specify requirements for many use cases, then the actual assertions corresponding to those assertion definitions can also be reused. This property of reusability has the potential to save time and money for ISE participants that need to meet multiple sets of complex data sharing and safeguarding requirements.
Componentization, Aggregation, and Harmonization of Requirements
This multi-community, multi-use-case data sharing scenario begins to illustrate the potential benefits of componentization of requirements into relatively low-level, generic, “atomic” units and aggregation of those generic, atomic units into higher-level bundles, or Assertion Profiles (APs), that meet the higher-level requirements of specific use cases. By creating a commonly used set of small, reusable, machine-readable ADs and higher-level machine-readable APs, we can enable automated analysis of the precise semantic difference between any two sets of requirements for any two use cases. The benefit of this property is that it enables an organization to easily determine the additional work required to acquire the new assertions and comply with a new set of requirements for a new use case, given the set of assertions that it has already earned for one or more prior use cases.
To enable these benefits, however, the componentized requirements represented within ADs must be truly generic and reusable across many different communities. It is therefore not sufficient to merely componentize a set of high-level requirements (e.g., CJIS SP requirements) into lower-level requirements in isolation. For true reusability, the lower-level components must be harmonized across multiple high-level policies. Thus, for example, the low-level components derived from the CJIS SP must be harmonized against the low-level components derived from HIPAA, to create a generic set of low-level components that can be reassembled in different ways into either CJIS SP requirements or HIPAA requirements. This process of harmonization is an important aspect of the ABA, as without careful harmonization of components, the componentization process has little or no value.
The ABA includes tools and other facilities to enable the development, vetting, and publication of ADs and APs by ISE stakeholders and sub-communities. And in addition to enabling mission participants to define their own ADs and APs based on their unique mission requirements, the ABA also provides a library of pre-defined ADs and APs that capture the requirements specified within certain well-known policies and guidance documents, such as the CJIS SP, NIST SP 800-53, NIST SP 800-63, and others. This common library can grow over time to include additional pre-defined ADs and APs, and ICIF participants can of course leverage these pre-defined artifacts as needed within their own mission-specific assertion profiles. See this page for more information.
Enabling an Ecosystem of Assertion Assessors
Many ISE participants already undergo regular audits and assessments to demonstrate compliance with regulatory requirements within their core communities. One goal of the ABA is to unlock the existing value already generated by those existing assessment processes by enabling componentization of the assessment results and making the results reusable to meet additional requirements from additional use cases beyond their original scope. To meet this goal, the ABA includes assertion assessor tools to enable assessment against assertion definitions, generation of assertions based on those assessments, and publication of those assertions for use by partner agencies. The ABA allows for a variety of assessment and assertion models, including self-attested assertions to enable a participant to assess itself and generate assertions about itself for use cases in which self-assessment is acceptable, and third-party-attested assertions for use cases where the objectivity of a trusted third-party opinion is required. In addition, to enable and encourage assessors and auditors to participate and serve the ISE communities, the ICIF includes an assessor training and certification program. See this page for more information.
Automated Policy Analysis and Discoverability of Data Sharing Opportunities
In the example introduced previously, Org. A requires Org. B to demonstrate possession of assertions that indicate satisfaction of specific requirements. Using ABA terminology, Org. B is an Assertion Recipient (AR), as it is the recipient of one or more assertions made about it. Org. A is an Assertion Relying Party (ARP), as it relies upon assertions made about its prospective data sharing partners as a basis for making trust decisions about them. Note that in most information sharing use cases, trust between ISE participants is bidirectional, which means that each participant in a use case would act as both an AR and an ARP. As we have noted, many ISE participants need to engage in many such use cases with many different information sharing partners. The ISE must therefore enable greater scalability as well as greater automatability of trust so that its participants can more easily manage their various information sharing trust relationships. Also, the ISE must enable greater discoverability of information sharing opportunities, so that its participants can react to changing requirements and rapidly establish new trust relationships when necessary.
The ABA includes several features that enable these properties of scalability, agility, and discoverability. First, the ABA enables ARPs to convey their trust policies in a standard machine-readable format that uses references to specific assertion types to precisely specify the assertions that prospective information sharing partners must possess. Second, the ABA enables assertions and trust policies to be registered online in registries, which facilitates discovery of potential data sharing partners as well as the requirements they stipulate (through their published trust policies) and the requirements they meet (through their published assertions). Third, the ABA enables assertions issued to an organization to be cryptographically bound to one or more of that organization’s system or application communication endpoints (e.g., endpoint URLs, IP addresses, etc.) These features, in combination, allow the ABA to provide two important benefits to ISE participants.
- Since ISE participants’ assertions and trust policies are published in registries, it is possible to automatically compute the degree of trust interoperability between any two participants for any given information sharing use case. Trust interoperability is a measure of whether two ISE participants mutually satisfy each other’s trust policies for a given information sharing use case, based on the assertions they possess. If each participant fully satisfies the other’s trust policy, then the participants should be able to rapidly establish the necessary trust relationship for information exchange to occur. And if there exists a trust interoperability gap between what one participant requires and what the other participant can meet, then the participants can at least begin a dialogue about what additional work would be required (e.g., what additional assertions would need to be acquired) to establish a trust relationship.
- Since assertions can be bound to actual system endpoints that engage in actual information-sharing transactions, it is possible for ISE participants’ systems and applications to perform trust interoperability computations in a “just-in-time” fashion, thereby allowing trust decisions to be made and enforced in real-time by the systems that rely upon those decisions.
For more information about these aspects of the ABA, see this page.
Leveraging the ABA for Information Sharing Agreements
Traditionally, ISE participants often execute legal agreements with each other to formalize the nature of their information sharing relationships. These agreements tend to include the requirements that each signatory is expected to meet, as well as various “terms and conditions” legal clauses related to liability, termination of the agreement, etc. But these agreements typically take the form of “lawyer prose”, which makes them difficult to read and even more difficult to componentize or compare with other legal agreements. We believe that the ABA provides an opportunity for substantial improvement in this area. By leveraging machine-readable assertion profiles and trust policy artifacts, we can enable most or all information sharing agreements to be recast in a machine-understandable format, while still being valid agreements from a legal perspective. This can help to further increase the speed of trust, as well as the speed of agreement, among ISE participants, thereby making ISE communities more agile and better able to quickly respond to new terrorism threats and data sharing opportunities as they arise, even when responding requires establishment of new formal legal agreements with partner agencies. We discuss this aspect of the ABA in greater detail on this page.
[previous] [next]