Home › ICIF Guiding Principles

ICIF Guiding Principles

To support and enable an effective solution for scalable, trusted, and cost-effective information sharing and safeguarding within the TR ISE, the ICIF must adhere to the following set of guiding principles:

  1. Align with ISE Requirements from the IRTPA
  2. Respect the Autonomy of IS&S Stakeholders
  3. Leverage Existing Standards, Policies, and Infrastructure
  4. Provide a Clear Roadmap for Stakeholder Engagement
  5. Support Scalability Across Multiple Dimensions
  6. Drive Interoperability through Convergence and Smart Reuse
  7. Favor Agility and Flexibility over Brittleness
  8. Increase the Speed of Execution

We expand upon each guiding principle below.

Align with ISE Requirements from the IRTPA

Section 1016 of the Intelligence Reform and Terrorism Prevention Act of 2004 (IRTPA) describes a list of 15 attributes that the TR ISE must uphold. One of the guiding principles of the ICIF, therefore, is that it must align with and/or support these aspects of the TR ISE that have been identified through federal law. The following breakout box replicates the relevant IRTPA language.

[stextbox id=”info” caption=”IRTPA Section 1016 (b)(2) Excerpt: Attributes of the TR ISE“]The President shall…ensure that the ISE provides and facilitates the means for sharing terrorism information among all appropriate Federal, State, local, and tribal entities, and the private sector through the use of policy guidelines and technologies. The President shall, to the greatest extent practicable, ensure that the ISE provides the functional equivalent of, or otherwise supports, a decentralized, distributed, and coordinated environment that—

  1. connects existing systems, where appropriate, provides no single points of failure, and allows users to share information among agencies, between levels of government, and, as appropriate, with the private sector;
  2. ensures direct and continuous online electronic access to information;
  3. facilitates the availability of information in a form and manner that facilitates its use in analysis, investigations and operations;
  4. builds upon existing systems capabilities currently in use across the Government;
  5. employs an information access management approach that controls access to data rather than just systems and networks, without sacrificing security;
  6. facilitates the sharing of information at and across all levels of security;
  7. provides directory services, or the functional equivalent, for locating people and information;
  8. incorporates protections for individuals’ privacy and civil liberties;
  9. incorporates strong mechanisms to enhance accountability and facilitate oversight, including audits, authentication, and access controls;
  10. integrates the information within the scope of the information sharing environment, including any such information in legacy technologies;
  11. integrates technologies, including all legacy technologies, through Internet-based services, consistent with appropriate security protocols and safeguards, to enable connectivity among required users at the Federal, State, and local levels;
  12. allows the full range of analytic and operational activities without the need to centralize information within the scope of the information sharing environment;
  13. permits analysts to collaborate both independently and in a group (commonly known as “collective and non-collective collaboration”), and across multiple levels of national security information and controlled classified information;
  14. provides a resolution process that enables changes by authorized officials regarding rules and policies for the use, and retention of information within the scope of the information sharing environment; and
  15. incorporates continuous, real-time, and immutable audit capabilities, to the maximum extent possible.[/stextbox]

Respect the Autonomy of IS&S Stakeholders

The Internet has thrived in large part due to its design philosophy of a “dumb core”—essentially providing only addressing via DNS and bit-level transport via TCP/IP—and a “smart edge” that comprises various servers and other devices leveraging the “dumb core” to communicate through a vast and growing set of application-layer protocols and data formats. To succeed and meet their missions, the ISE communities must abide by a similar philosophy. We must allow IS&S stakeholders to gain the benefits of ISE participation without compromising their autonomy. In other words, rather than trying to manage trust in the “middle” of the system, we must push trust to the “edges” of the system and give IS&S stakeholders the tools to autonomously establish and manage their own trust relationships. We can accomplish this through a loosely coupled, decentralized, inherently federated model of trust, in which participants can enter into peer-to-peer trust relationships and information sharing agreements at will based on their mission needs, without having to rely on a central operational trusted authority.

Leverage Existing Standards, Policies, and Infrastructure

Designing and implementing a TR ISE is not a “greenfield” project. Many valuable ISE-related resources already exist, including technical specifications, policy guidance, and operational information sharing systems. We must leverage these existing assets by enabling them to be incorporated into the ISE where they fit and can provide value. Specifically:

  1. We must leverage and reuse, or enable the reuse of, existing technical standards and profiles wherever possible, and enable ISE solutions and products built upon those standards to be reused. Or, conversely, we must NOT require IS&S stakeholders to adopt an entire new suite of standards that re-implement capabilities already supported by existing standards.
  2. We must leverage existing policy-level and regulatory requirements to which IS&S stakeholders already conform, and we must enable those stakeholders to receive appropriate credit for their prior work in achieving compliance with those requirements. Or, conversely, we must NOT require IS&S stakeholders to expend considerable resources adopting and complying with an entire new set of policy-level requirements while also still complying with their current policy-level requirements for which they have already invested resources.
  3. To the greatest extent possible, we must enable IS&S stakeholders to leverage existing legacy infrastructure—servers, networks, software, bilateral agreements, etc.—for which they have already invested resources.

Provide a Clear Roadmap for Stakeholder Engagement

The TR ISE communities include a wide range of stakeholder agencies with varying needs and capabilities. Different stakeholders naturally need to use the ISE for different purposes. For example, some stakeholders may take on a “data producer” or “data provider” role due to their position as owners, aggregators, or custodians of data, while other stakeholders may need to play a “data consumer” role to access and/or disseminate important data on behalf of their employees or partners who need it to carry out operational tasks and missions. In addition, some stakeholders may want to more fully embrace the ISE’s capabilities, e.g., by aligning their broad organizational data sharing strategy with the ISE and its capabilities, while others may want to leverage the ISE for more limited purposes, e.g., for sharing information with only one or two partners across only one or two use cases.

To adequately support the needs of these different participation scenarios and others, we must provide a clear roadmap that any IS&S stakeholder can follow to become involved in the ISE, regardless of the roles it wants to play or the extent to which it wants to participate. This roadmap must have the following characteristics.

  1. It must “meet stakeholders where they are at today” and enable them to leverage their existing installations, solutions, and practices as they begin to embrace and work towards the  vision of a broader ISE.
  2. It must support a broad set of well defined on-boarding paths, so that every IS&S stakeholder can readily understand how to most effectively participate, regardless of its capabilities.
  3. It must support partial participation, so that participants must not make an all-or-nothing decision when choosing whether to participate in the ISE. In addition, it must have a low bar for entry, such that getting involved within the ISE at a “bare minimum” level of participation is neither costly nor onerous.
  4. It must support the elevation of trust and interoperability over time, so that we can meet ISE communities where they currently are (relatively low trust and little interoperability) and gradually increase their capabilities and expectations around trust and interoperability from there. Improvements in a community’s level of maturity around trust and interoperability tend to enable richer information sharing capabilities within that community.
  5. It must support graceful evolution of trust and interoperability requirements over time, so as to not punish early adopters.

Support Scalability Across Multiple Dimensions

Currently, much of what constitutes the ISE can be characterized as a set of “stovepipe” solutions: single-purpose, custom-built systems that cannot easily scale beyond their original use case or their original stakeholders. This “NxN” model is highly inefficient and impractical from a pure scalability perspective. To effectively support the IS&S stakeholder community, the ISE must transcend the NxN paradigm and scale elegantly and cost-effectively across many different dimensions, including stakeholder agencies, end-users, use cases, and communities of interest, as follows.

  1. Stakeholder Agencies: We must facilitate and support an environment for counter-terrorism information sharing that goes beyond the usual counter-terrorism agencies and includes the partners and “tangential” actors that may need to collaborate with them, even if the identities of these agencies are not known today.
  2. Use Cases: We must support a wide range of information sharing and safeguarding use cases and allow for an essentially unbounded scope of sharing, including use cases and partner relationships that are not yet known. We must support all of these scenarios within a single framework, because the alternative—falling back into the NxN paradigm and building a separate and independent framework for each use case—would be extremely complex and cost-prohibitive.
  3. End-Users: We must support a scalable framework for trusted, high-assurance federated identity management, so that individuals who work within the counter-terrorism community can leverage their identities and credentials to obtain the information they need to do their jobs.
  4. Communities of Interest: We must recognize that what we call the “ISE Communities” comprises multiple COIs, including law enforcement, intelligence, critical infrastructure, health care, and others. We must enable each of those COIs to leverage the ISE to support their respective missions and goals, and in addition, we must enable these COIs to leverage the ISE for not-yet-known cross-COI missions and goals that may arise due to unforeseen future circumstances.

Drive Interoperability through Convergence and Smart Reuse

The term “interoperability” is sometimes misunderstood to pertain only to protocol standards and data payload formats, but in truth, especially in the ISE, interoperability matters at both the technical level and the policy level.

Technical-level interoperability is a complex and multifaceted challenge involving multiple layers of technology and varying levels of detail related to conformance. For example, “full” technical interoperability between two systems within the ISE may require that the systems use common protocols and standards at the transport layer (e.g., TCP/IP), the secure session layer (e.g., TLS), the federated identity layer (e.g., SAML or OpenID Connect), the identity attribute layer (e.g., NIEF attribute definitions and attribute bundles), the data payload layer (e.g., NIEM), and others. In addition, for each layer, interoperability may depend not only on the use of a specific standard, but also on the specific profile(s) used or implementation choices made by the two systems within that layer. We must allow for ISE participants to manage these aspects of the interoperability challenge at arbitrary levels of specificity, as needed for each layer of the interoperability puzzle.

At the policy level, interoperability is no less important and perhaps even more complex. Many IS&S stakeholders have existing policies with which they must comply, covering topics such as security and privacy, based on their mission or their membership in a specific community. But not all agencies follow the same policies. For example, a state-level or local-level law enforcement agency typically adheres to the FBI CJIS Security Policy. A federal agency typically follows the security policy rules in NIST Special Publication 800-53. And private organizations may comply with any number of industry-specific security regulations or guidelines. For a group of information sharing partners that come from only one community (e.g., state and local law enforcement agencies), establishing a basis for mutual trust through “policy interoperability” may be as simple as demonstrating compliance to the prevailing policy requirements from that community. But as organizations come together to share information within the ISE, they must often cross community boundaries and establish trust with information sharing partners outside their “home” communities. In such cases, “policy interoperability” becomes much more difficult, as an agency may need to demonstrate simultaneous compliance with multiple policy sources from multiple communities. We must consider these more complex use cases and provide the necessary tools for IS&S stakeholders to cost-effectively participate in them.

We can help facilitate broad interoperability at both the technical and policy levels through two separate but related strategies.

  1. Encourage convergence on common baseline requirements over gratuitous variations. For example, the SAML 2.0 standard is widely known to be too loosely defined to promote wide interoperability among its implementers. As a result, for many years it was common practice for communities using SAML to create their own custom interoperability profiles of SAML to facilitate greater interoperability among their participants. But these custom profiles often included gratuitous variations—that is, they differed from each other in small but meaningful ways that contributed no additional benefit but hampered cross-community interoperability. This same phenomenon often happens at the policy level too, when communities develop new and unique sets of security or privacy rules for there participants, even when their underlying requirements are not unique. We must be careful to avoid these outcomes, and seek instead to encourage IS&S stakeholders to converge and agree upon on a single standard or profile rather than inventing new solutions that are almost-but-not-quite interoperable with other similar solutions.
  2. Encourage reuse of what exists over reinvention. The corollary to the previous strategy, and the most practical way to facilitate convergence on common requirements, is to encourage reuse of existing solutions whenever possible. This strategy too is applicable at both the technical and policy levels. For example, if a community within the ISE seeks to implement the sharing of a specific type of data (e.g., suspicious activity reports), then before building a custom solution, it should first check whether any other community has already implemented such a use case, as this may represent an opportunity to borrow and reuse technical specifications, policy guidance, and even software implementations. We must encourage this path of reuse over reinvention, and provide tools and other capabilities to facilitate it.

Favor Agility and Flexibility over Brittleness

As we have already noted, too many systems and applications across the ISE today are monolithic, single-purpose-built “stovepipes” that are incapable of being readily repurposed to meet new needs: new technologies, new threats, new requirements, new use cases, new stakeholders, new policies, new communities, etc. They are, in other words, brittle. To fulfill its mission, the ISE must be agile and flexible enough to elegantly evolve over time as new needs emerge. There are many characteristics that promote agility and flexibility, but the most important ones are:

  1. Open Architecture: The ISE must be fundamentally “open” in the sense that the technology standards it uses must be non-proprietary and available for anybody to inspect and use. A “closed” single-vendor solution, or a solution based on a proprietary design and/or proprietary specifications is unacceptable. This need for openness highlights the role of broader communities (standards bodies, vendors, etc.) in the success of the ISE. The ISE communities must embrace and coordinate with standards bodies and product vendors, so that over time the technical aspects of the ISE architecture get “baked into” widely accepted industry standards and implemented in widely available COTS products.
  2. Orthogonality, Modularity, and Composability: The ISE must be designed in accordance with the principles of orthogonality, modularity, and composability. For example, the data payload standard used within a system should be orthogonal and unrelated to that system’s transport protocol or identity assertion protocol. This “separation of concerns” philosophy allows for the standards at each layer of the system to exist independently of the other layers as modular components, so that they can evolve independently in response to changing requirements and be reused and composed in new and unique ways where appropriate.

Increase the Speed of Execution

To fulfill their missions, ISE communities must recognize that speed matters. An otherwise ideal information sharing solution is ineffective at countering terrorism if the agencies that would benefit from it cannot deploy it in time to neutralize the threats that they face. Accordingly, the ISE must facilitate speed of execution in several dimensions.

  1. Speed of Partner and Capability Discovery: The ISE must enable participants to rapidly discover prospective mission partners and quickly assess their characteristics and capabilities to determine whether there is value in establishing an information sharing partnership.
  2. Speed of Legal Agreement Execution: The ISE must enable prospective mission partners to rapidly define and execute information sharing legal agreements with each other when such agreements are needed for specific missions and use cases.
  3. Speed of Trust and Interoperability Assessment: The ISE must enable prospective mission partners to rapidly (and automatically, when possible) assess each other’s trust and interoperability characteristics and make on-the-fly decisions about whether sufficient trust and interoperability exists to permit sharing of information.

[previous] [next]