Poorly designed technology & security

An enclave that aims to provide information to a large group of people, including data as sensitive as PPBE information, must be built within secure and monitored infrastructure with security best practices firmly in place. It must account for security controls that protect sensitive or potentially classified information and provide accurate representation of data across security boundaries.

Substantial administrative and programmatic work has already been accomplished in this regard. The Advana team in the Chief Digital and Artificial Intelligence Office has infrastructure, data processing, and data storage tools in place. Building on the programmatic successes of Advana’s existing products, contracts, data connections, and previously approved Authorities to Operate (ATO)¹ provide the best approach to the rapid delivery of a technically acceptable enclave.

CDAO’s current development and delivery strategy, however, has proven insufficient to build the enclave. Initial efforts are so unstable, inaccurate, and unusable that Congressional staff have ignored or abandoned them. What has been developed so far reduces, rather than increases, trust between the two institutions.

Data access

Both SDC and the PPBE Commission’s research uncovered several barriers to Congressional data access. Congressional staff need access to a wide variety of information to make informed decisions. Most of that information is sensitive and not publicly available. DoD uses Impact Levels (IL) to describe the sensitivity of their program data. To support the PPBE process, Congressional staff will need access to at least Impact Level 5 (IL 5) for CUI.

Advana currently relies on a Secure Unclassified Network (SUNet) to provide non-DoD users access to limited data. The enclave pilot is accessed through the public internet with a username, password, and a two factor authentication code. It currently contains three applications: Historical Selected Acquisition Reports (SAR), the Defense Acquisition Visibility Environment (DAVE), and Middle Tier of Acquisition (MTA) programs.

Because DoD policy states that usernames and passwords are only adequate to protect IL 2 data, the usefulness of the enclave pilot has been severely curtailed. A large portion of the budget and execution information for the DoD is held at IL 5. To access more sensitive IL 5 data, Congressional staff must often rely on classified email in a separate facility that is able to host higher levels of information. They must access secure materials through sensitive compartmented information facilities (SCIFs) or travel to secure locations like the Pentagon. Congressional staff discussed how impractical this is.

If staffers must leave the location where they do the majority of their jobs to access unclassified information, it will create undue burden. In order to get the information and context they require, they will instead resort to requests for information and additional briefings. Requests for information create duplicative and time-consuming work for the DoD. In-person briefings are extremely useful but take a tremendous amount of coordination and preparation for all parties, which is not feasible for answering one-off questions.

Even though DoD has granted Congressional staff access to classified email, the Department has not issued Congressional staffers CACs or PIVs. These physical identification cards would allow Congressional staff expanded access to IL 5 data without forcing them to resort to classified systems.

Data management

Data in Advana does not currently follow consistent standards or labeling constructs. As data is brought into the enclave, it should be labeled with metadata: information such as where it came from, when it was received, what security levels or user restrictions that data carries with it, when it expires or is no longer relevant. This is necessary to control access and properly serve data in a relevant, timely manner.

Advana gathers data from around DoD and stores it in segmented instances of Advana. If data from one version is needed in another, the data may be either fetched or replicated internally. Replication creates copies of the same data set in different locations, risking syncing and accuracy issues as those datasets age or are edited. Advana solves the issue of each DoD component needing to implement their own data repository and tooling but their decision to create separate instances of Advana for the Services eliminates the benefits of a central platform and further isolates data into separate communities of interest.

Single platform instance

The multiple instances of Advana are managed separately, creating inefficiency. For example, a user needing to access both Army and Air Force data would need to log in to two separate versions of Advana, one for each service. Once logged in, they would have different access to different types of data in each.

These separate instances are not sitting on independent infrastructure, instead portions of the existing infrastructure are allocated to specific sets of users and only they have access to them. These instances each maintain separate access to data and separate user controls which increases the maintenance burden and complexity of the environment. Data in one instance may be pulled from a different source or be pulled at a different time. This means the buckets of data that are available to each instance are not guaranteed to be in sync with one another.

Because the sections are managed separately and data is duplicated at different times or manipulated in separate environments, a user could look up the same data point in each system and get two different results. This structure creates inconsistent results and adds unnecessary complexity to information retrieval.²

Ideally, a user with a need to access data from both Services would query one database, with one authoritative set of data. If their permissions were more restricted in one location, they would simply not be able to see the result of a restricted search. Such a system would be more technically efficient and prevent errors in data replication from affecting critical decision making. Implementing this change requires examining the background decision making that led to the current implementation. Further research is needed to understand and potentially change policy decisions and directives that would make a DoD-wide system more tenable.

Usage & data metrics

Based on demonstrations that SDC observed, metrics and data usage statistics do not appear to be managed in a central location on the Advana platform. This would mean there is no way to know how many times a piece of data is accessed or what information garners the most interest from the largest number of people. While data access may be logged, we were unable to verify that is this case.

Once Congress is regularly accessing enclave data and using it to make decisions, these types of tracking metrics will be critical to answering questions, especially those related to sources of truth and data recency. If a specific piece of data is needed every year at the same time, the enclave could track this and ensure the information is updated and accurate when it is needed most. Other metrics like usage rates and frequently accessed data sets can help drive usability improvements and puts checks in place to ensure information availability.

1. An Authority to Operate (ATO) is given to systems that are deemed secure scoring to the Risk Management Framework. Receiving an ATO is a required, lengthy, and expensive compliance process that applies to any unclassified technology product deployed by the government. ↩

2. PPBE Commission Final Report March 2024, “Years of Technical and Functional Debt,” page 105 ↩