This is a question I’ve been previewing since 2017, when information came out indicating that FISA Section 702 search-term queries were implicated in the surveillance of former President Trump and his associates.
The news last week that in 2012 the FBI put a remote “secure work environment” (SWE) at Perkins Coie – news verified by the FBI – has renewed the interest in the question, which from the public’s standpoint remains unanswered to this day.
The original question was this. Has anyone used auditing tools on the FBI’s Sensitive Compartmented Information (SCI) system to compile a record of what users were doing with Section 702 queries in 2015 and 2016?
The new question, in light of the SWE at Perkins Coie, is whether the auditing tools have been used to verify the nature of user transactions on and with that SWE element fielded at the law firm.
Though the forensics question was obviously of specific interest to the 702 queries, it is of generic interest for multiple purposes, extending to what use the SWE at Perkins Coie has been put to.
Those questions even intersect for Perkins Coie, going by the FBI explanation of why the SWE exists. The explanation, as discussed at the link above, appears to be connected to Perkins Coie’s representation of telecoms that may be served with communications data requirements under national security letters (NLSs).
That reasoning would also apply to Perkins Coie clients served under named-target FISA authorizations, like the surveillance of Carter Page.
In 2016, when the FBI was using the Steele dossier created by the oppo research firm Fusion GPS, under contract to Perkins Coie, to seek FISA authorization for surveillance of Trump associate Carter Page – a form of surveillance likely to involve Perkins Coie’s telecom clients – what exactly were users of the Perkins Coie SWE doing? Whom were they communicating with? What files did they post or access?
It’s an FBI SWE. The systems and everything on them belong to the FBI and are subject to statutory monitoring. And the SWE involves national security systems, which are subject to monitoring and auditing requirements carefully spelled out in information security regulations, at a baseline level of stringency the FBI doesn’t get to pick and choose for itself. The entire FBI SCION (SCI Operational Network) involves national security systems, for that matter. Agencies can apply more stringent controls to their SCI systems in-house, but in relation to the U.S. government’s baseline stringency of controls, they cannot apply less.
As regards the 702 queries (which, per se, I very much doubt Perkins Coie was involved in), the FBI is and has always been by far the biggest user agency for queries that could return U.S. person identifying information. That makes sense given the FBI’s domestic and counterintelligence missions, and the strong restrictions on such queries by the national security agencies with overseas, foreign-threat portfolios (CIA, NSA, DIA). We would expect to see the latter agencies making only 4,000 such queries in a given timeframe, while the FBI made far more – even if 3.4 million sounds remarkably excessive. That number over a year works out to some 9,300 per day.
For some perspective on the very high FBI numbers, this May 2022 commentary is essential reading. An important factor in the widely disparate numbers is how the FBI counts queries, which is different from how other agencies count them. In general, the other agencies (mainly NSA and CIA) count a targeted query as a single query, independent of how many search terms are used. The FBI, by contrast, literally logs each search term used as a separate query. In the case of a target set approached with 100 search terms, the FBI logs 100 queries. The other agencies may log a similar process as a single query, or, say, seven, if there are seven elements in the target set.
Another factor, implied but not explicitly stated in the May 2022 article, is that the FBI acquires Section 702 data (i.e., collects it as a FISA collection authority). It’s the only agency besides NSA that does so. That’s the meaning of this sentence in the May 2022 article’s Point 2 on U.S. person queries: “Reportedly, the FBI receives less than 5% of the IC’s total Section 702 collection, but the frequency with which the FBI uses U.S. person query terms is greater than its IC counterparts because of the FBI’s domestic-focused mission versus the IC’s foreign-focused missions.”
The other 95% of Section 702 collection is going to NSA. Something to keep in mind as we continue the survey in this article is that the FBI, as an acquiring agency, does not have all its front-end data-handling managed by NSA, as is the case for most of the 702 data used by the intelligence community. The FBI has its own arrangements, and in a great number of its query activities – a point repeatedly acknowledged in ODNI and FISA court documents – is not subject to the same NSA monitoring other agencies are when queries are run.
The FBI can also, however, run queries against the NSA-acquired 702 data. This mish-mash of processes and requirements results from the FBI’s hybrid operating environment, including domestic law enforcement and terrorism threats, and foreign threats inside the U.S. It makes accounting for 702 queries something of a problem, however – one that I think is being made more difficult than it has to be. The result is that the public is never certain there’s an authoritative handle on what the FBI is doing. That uncertainty, given that other agencies’ query reporting doesn’t look like the FBI’s, casts the other agencies in a dubious light as well.
All of this relates to 702 queries. But there is also a real need for accountability on what else is being done inside SCI systems, especially when jarring developments like the SWE at Perkins Coie show up. Merely asking the FBI to explain itself may not be like asking the bank robber to explain why you shouldn’t suspect him of robbing the bank. But it could be. With national security systems, there needs to be a more assured method of verification.
That’s what this article is about. The potential is there for better assurance of accountability in the use of classified systems and sensitive information – but if it’s being brought to bear today, there’s no sign of that being vouchsafed to Congress in good faith.
The balance of the article will lay out that argument.
Resuming the discussion of 702 queries: most observers have been apt all along to imagine that it’s NSA performing all the 702 queries. Convincing them that’s not the case has been an uphill battle, but the reality is still that almost all of the queries that can return USPI are performed by the FBI (or at least on FBI systems where the FBI is perforce the reporting agency).
The queries stick out like a sore thumb at the other agencies (mainly NSA and CIA). They require positive accounting and explanation.
The queries in this category – search terms that could return USPI – are also few enough in number, at the other agencies, that handling them and retaining or discarding information from them in accordance with agency and White House guidance (i.e., executive order) is much less time-consuming than it would be at the FBI.
This is presumably why the FBI has consistently been dinged in compliance reviews for failing to meet standards for handling 702 queries.
Probably the chief formal concern about FBI handling has been the Bureau’s failure to log search-term queries with annotations as to whether they are likely to return USPI. This complaint was expressed by the FISA court in 2017 and was recorded as a continuing concern by a Justice Department OIG inquiry in October of that year. The same deficiency was reiterated in a FISC opinion in October 2018. The FBI lodged a counter-argument that its existing practices are sufficient to satisfy the statutory requirement for accountability and control of search-term queries. In 2019, Bill Barr instituted specific procedures for query records, which are still percolating through the FISA court labyrinth.
The upshot is that, as of December 2021, the question remains an open, unresolved item.
This has all been happening while search-term queries that could return USPI have continued unabated in very large quantities.
In the sense of formal handling procedures and controls, therefore, we start out with a legitimate basis for concern about what the FBI is doing.
But I took you on that very abbreviated tour of the formal handling guidance because it’s not what I’m talking about in this article, and it’s extremely important to understand that. (Just as our contextual understanding is enhanced by being aware that the formal handling procedures are also an area of deficient performance.)
IT system-level accountability, as opposed to procedural measures
What I’m talking about is system-level monitoring and auditing that should afford a forensic view into who has done what with user activities such as making search-term queries. The FBI, as noted in compliance reviews, has had difficulty accurately tallying all its 702 queries – in particular, those done for law enforcement (versus CI/national security) – based on its procedures for formally recording them. But user activity monitoring should make that moot. The FBI should be able to have its system produce a record of how many queries there have been.
SCI national security systems – the ones on which 702 queries are executed – are supposed to be equipped with such capabilities by design, with criteria for implementation covering precisely such audit-worthy events as running search-term queries that may return identifying information on U.S. persons. (Note: there is specific discussion of SCION throughout this article, but I haven’t found documentation to verify whether the FBI runs 702 queries via an application that is programmatically part of SCION, or perhaps uses a portal provided by NSA. In either case, we’d be discussing an SCI system, and now a cloud-enabled network capability, to which all the measures referred to in this article apply. For simplicity, I’ll refer to SCION to cover the basis for infosec capability and requirements.)
It’s not clear from publicly available information how the FBI treats its self-acquired Section 702 data, or even if it’s all treated the same way. At a minimum, however, it would be protected when it’s returned in query results that contain USPI. Although we won’t be discussing protection and auditing standards in his article, they exist, and can be applied.
This whole area of administration intersects with what’s called Insider Threat monitoring, and every agency with sensitive information, including the handling of national security information and Americans’ privacy information, is supposed to have an Insider Threat program. An Obama Executive Order, 13587 of 2011, is the baseline for current policy on this.
Within the category of Insider Threat administration, the main lines of monitoring and interest for our purposes here are “user activity monitoring” (UAM) and “enterprise audit management” (EAM). They’re what they sound like: UAM is about monitoring the activities of system users: e.g., logging in/out for sessions, creating files, running queries, communicating with other users, communicating outside the system. EAM is about the agency or multiagency IT system as an “enterprise,” and the controls it is required to have for detecting, alerting on, recording, and auditing both user activities and other system events (such as intrusions and crashes).
Think of UAM as the goal, which you would measure by criteria set for meeting it, and EAM as the set of arrangements put in place so that the goal can be met. The UAM goal is to be able to monitor for improper – potential threat – activities by internal users of the systems so as to detect, alert on, and reconstruct abuse of access.
The reason I’m going through this is to establish that there’s a whole dedicated discipline for this matter – information security – and “Insider Threats” nest within it and draw their implementation standards from guidance that overarches the entire federal government, and can’t be dispensed with.
Thus, we ought to be able to demand answers – to questions like “What the heck has the FBI been doing?” – on the basis of system-level UAM/EAM accountability, and not just procedural controls and personnel interviews.
To arrange the brief most simply: the FBI is required, like all agencies with SCI systems that interact with the broader intelligence community enterprise, to meet UAM and EAM criteria. That point isn’t in question. The FBI’s SCION must afford UAM/EAM capabilities that conform with those prescribed for SCI national security systems. (Secret-level systems and those handling sensitive-but-unclassified information have such requirements as well.)
Readers can satisfy themselves, on the matter of SCION being the FBI’s SCI national security system, with FBI testimony to that effect in 2004. The testimony affirmed that SCION is the FBI’s version of “Intelink-TS,” the desktop environment for the U.S. intelligence community, which operates on the SCI network called Joint Worldwide Intelligence Communications System, or JWICS.
Whatever is prescribed for JWICS and Intelink-TS, SCION must meet or exceed.
The prescriptions for JWICS as an SCI network nest, in turn, with requirements for national security systems. And requirements for national security systems nest with requirements for information systems as a whole – which in their turn nest with requirements for the general realm of information security.
Both of the latter include security categories that go beyond national security systems; e.g., the private medical information of Americans, for which the agency principally concerned with data-handling is obviously HHS. Also included in the general realm of information security, or infosec, are security considerations such as physical access to spaces where information is processed (involving elements like hardening against unauthorized entry, perimeter security, and so forth), and personnel access (where things like background checks, security oaths, clearances, etc. come into play). There are others.
Within this comprehensive realm of infosec, the filtered area we are concerned with is the UAM/EAM element of an Insider Threat Program, which monitors the computer events relevant to alerting on misconduct – or at least unusual activity – by system users.
The pain for readers would be immense if I took you through all the ins and outs of the criteria for setting monitoring requirements. You’ll see why in a moment. So the brief overview here is merely to establish that there are very closely defined criteria, and there’s little if any mystery to them.
I’ll start by observing that in the category of infosec for IT systems, including national security systems, there’s a new kid on the block, and that’s cloud-computing security. In the 2000s, a set of criteria and practices known as “FedRAMP” was developed to address that up-and-coming IT security field.
The use of cloud computing has been expanding in the U.S. government for about a decade, and as we’ve discussed numerous times before, it applies to SCI national security systems: those operated by the U.S. intelligence community, for which Amazon Web Services got a cloud-provider contract in 2013. NSA also developed its own cloud separately – GovCloud – which is now a legacy system migrating to merge with the IC enterprise solution.
The FBI’s SCION and the other agencies’ flagship SCI systems operate in the cloud now, and are subject to FedRAMP security criteria.
But FedRAMP, along with all IT system infosec requirements, maps back to the criteria and definitions for system controls that allow administrators to plan for, implement, and account for the performance of their security standards.
Preceding FedRAMP, and still in use and underlying it, are the baseline requirements for legacy, non-cloud-enabled systems. The criteria for UAM and EAM largely covered the security issues of any networked IT system, and the regulatory resources for those criteria are still in effect.
At the nested levels, criteria for JWICS can be pursued through this DNI-posted document on Insider Threat Programs (put out by the National Insider Threat Task Force, NITTF), with an extensive list of references starting at the bottom of page 1.
National security systems are subject to CNSSI No. 1253 (Committee on National Security Systems (CNSS) Instruction No. 1253). As regards auditing standards in particular, the reference is CNSSI 1015, Enterprise Audit Management Instruction for National Security Systems (NSS). (This is where EAM is defined.)
The baseline definitions and criteria for infosec controls across government operations come from NIST SP 800-53 (National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, Security and Privacy Controls for Federal Information Systems and Organizations). NIST SP 800-53 is one in a set of five instructions that outline the parameters for the security of U.S. government information; i.e., “infosec.” The set of five can he handily viewed by title on page 1 (PDF 4) of CNSSI 1253.
I regret to say that at each level you will find an array of additional regulations and instructions. I’m not going to go into that.
It’s more profitable here to give readers a window into what is being translated from NIST SP 800-53 into the filtered application at a more specific level. It takes this visual to understand that the definitions and criteria do address the standards for “doing UAM and EAM,” and referring to the NIST guide is the way of complying with the requirements at more specific levels.
The NIST document enumerates what are called the “controls” that may apply to the security of U.S. government information, including (but not restricted to) information handling in IT systems. There are hundreds of controls, across categories that include account security, personnel security, and others, but for our purposes what we care about are the controls for user activity (UAM) and system auditing (EAM).
Here’s a pair of captures of the baseline guidance matrix from NIST SP 800-53, depicting some of the controls; in this case, user access control. Feel free to roam the complete database at the NIST link to see as many controls as seem good to you. The last link above is to a PDF, but the NIST SP 800-53 webpage will have you adventuring through spreadsheets if you prefer.
And here, for comparison, are some (of many) controls relevant to monitoring user access and activity and auditing events, captured from the CNSSI 1253 matrix for national security systems. The CNSSI 1253 explanation of relating NIST controls to the selection of controls for national security systems starts at paragraph 2.3 on page 4 (PDF).
Measures to implement these controls in agency systems, geared to how secure we want to be, are the issue at hand. They exist, for every IT system operated by the U.S. government. They’re integral to the Threat Insider Program, and they’re supposed to afford insight into a core aspect of infosec: user activity on the system.
So how are we doing?
To resume the thread to our goal: the reason we’re going through this is to establish that the FBI is supposed to be able to record user activities, to make a practice of routinely reviewing and updating which user activities to record, to set alert criteria for unusual events, to define auditable events and ensure they are recorded, and so forth.
I haven’t been able to find an FBI instruction on this matter online. But we know from other documents, including those on the FBI’s delinquency in annotating search-term queries, that the FBI does perform user activity monitoring. The documents refer to occasions when the FBI might do this, and specifically to the existence of rules for retaining USPI information that may be captured as part of UAM records.
In 2017, however, a DOJ OIG inquiry revealed that the FBI still didn’t have UAM in place covering all the systems that require it. (See page 8 in this report.) The deficient systems are not named, and, as summarized below, that’s actually a key problem. Declining to name and transparently track the FBI’s progress by system evidently isn’t working. It’s too vague: the people can’t verify that ODNI, the FISC, or – especially – Congress knows what the state of UAM is in FBI systems.
Now, in 2022, SCION is supposed to conform to ODNI requirements for UAM stated in guidance updated in 2017.
It’s not clear we have a means to verify that it does. Yet the SCI system is the interface with the IC apparatus for running search-term queries on 702-acquired data that may return U.S. person identifying information.
The mechanism for levying the requirement has been there for years. The problem is we can’t tell what good it’s doing. A melancholy finding by GSA in 2019 indicated that 15 of 24 key federal agencies had not properly instituted FedRAMP security-forensics standards for their cloud services. That seems like an awful lot of federal agencies out of compliance, even if the FBI is not stated to be one of them. It’s not going all that well, apparently.
A major problem, in fact, is that the GSA report doesn’t list the non-compliant agencies by name, except for four that GSA presents as discussion cases. That itself is unsatisfactory. With incessant vulnerabilities reported in government systems, and continued huge numbers of 702 queries on which the people never see any accounting, while reporting piles up of IT data abuse (as with the Russia hoax) and gaping moral hazards like an FBI SWE at the DNC’s law firm, it’s just not acceptable to rely on blind assurances about what agencies have been doing.
Where Congress comes in
The point of knowing this background is to understand that Congress could and should require the FBI (or any other agency with an SCI national security system) to produce and account for the records of its users’ activities, when major questions arise about things like improper use of 702 queries and an FBI SWE at a private law firm.
That may require the formal adaptation or refinement of existing UAM/EAM criteria and standards. It may well require rethinking the structure and purpose of the infosec auditing system, to take advantage of current technology and produce a more responsive output. There may be adjustments necessary to align accountability measures with what the people have the right to expect. It may that “the way we’ve always done it” just doesn’t work, for what we really need.
THAT’S OK.
The way we’ve always done it appears to rely too much on procedural anecdote, while simultaneously turning in a pastiche of meaningless numbers from different agencies that (a) make no sense, and (b) quite understandably foster unease and suspicion in the people.
The way we’ve always done it isn’t getting the job done.
A better premise is this. When a user enters search terms for a 702 query, that should be an auditable event and be automatically recorded by the system, with the ability to correlate the query to reconstructible search results* (even if the latter information isn’t retained as a related record in its original form), to determine whether the search yielded USPI. Congress should then expect to receive an accounting based on such information. The raw numbers may not be that informative, and can be misleading when people are trying to figure out how things went wrong. There’s no reason the system can’t be made to record information about user activity that, when audited, will actually shed light on the intent and methodology at the time.
The personal identities of an agency’s system users need not be revealed. That’s not the point. The nature of the system transactions, including features like when they occurred and how much use the same user was making of them, need to be verifiably available for authoritative review and accounting.
IT systems can tell us a lot of things we need to know, which is why the U.S. government already requires that systems be set up to talk to us afterward.
Alert readers are likely to ask the excellent question whether we know for sure this isn’t being done.
That’s precisely the question Congress needs to get to the bottom of. In five years, I haven’t seen anything that reassures me these accountability forensics have been pursued as they should be, especially in light of the Russia hoax, but also just because overuse of 702 queries is perennially a matter of legitimate concern. Accountability tools should be used as a routine practice of security administration and good faith.
In 2017, when Trump appointee Ezra Cohen left the National Security Council for a job with Oracle – which operates huge structured databases for U.S. agencies, including some national security systems – it appeared that the Trump administration hoped to pursue this question. Oracle could offer an excellent window into some major slices of UAM and EAM in national security systems.
And perhaps Cohen did discover some important facts and conditions. But that has never been made clear, and with each passing month that becomes less and less OK.
The people are owed an answer on this. I think the five-year retention requirement for SCI IT system logs and user-activity reconstruction has run out, as regards activity in 2016. For that year, we may never have the accounting our agencies’ UAM/EAM arrangements are supposed to make available.
But I’ve drawn a picture here, with references and arrows. This is what Congress needs to pursue: the IT-enabled infosec accountability we’re supposed to have from standards for UAM and EAM. If it’s been pursued already, then cop to it and tell the people what’s going on.
The American people are the targets whose interests aren’t being protected. Keeping the people in the dark about it, while discrepancies, failures, and extremely questionable outcomes persist, is our national security emergency.
* This shouldn’t be as hard as it might sound. Search-term 702 queries are run against structured data, meaning that the results returned are compiled from data “cells” which contain defined types of information. The presence of cells that are security-tagged as containing elements of USPI can be flagged for a search result, even if the actual cell contents are not part of the auditing record. (The use of structured databases for returning information to users is the basis for James Clapper’s bumper-sticker vision of IT infosec in the IC: “Tag the people, tag the data.” Querying a tagged-cell database is supposed to return only what the user account is cleared for. The structure and tagging scheme are also the means of recording what a user was able to see when he or she ran the query.)
Ideally, the auditing record of a 702 search-term query should enable an auditor to rerun the query and view what came up in the original. Again, this isn’t too hard for existing technology to implement.
Feature image: Servers, Pixabay; “Man with Green Eye Shade,” Currier Museum video, YouTube. Author
The Optimistic Conservative 
Bureaucracy expands to fulfill the needs of the ever-expanding bureaucracy. -Civ III
JE – That’d all be great, and it’s actually required by most of the federal government – they didn’t pay NIST to write and maintain all of those chapters of all of that Cybersecurity Risk Management Framework stuff, not to implement it….
EXCEPT
When it’s inconvenient and the blizzard of paperwork and pile of systems that can’t be actually managed or monitored by human eyes is used as a convenient screen to operate a “black market dope deal”, which this entire thing looks to be. It’s therefore unlikely that any RMF controls would be present, documented, and continuously monitored. Much less an actual legitimately functioning Authorizing Official accept the risk and issue an Authority to Operate.
Sometimes the best place to hide your illicit schemes is in broad daylight, in a huge crowd with their focus on their own idiosyncratic needs.
One wonders how many of these “SWEs” in partisan political operations erroneously labeled as law firms there are? No one is likely to spill the beans, and no penalties will be issued for not spilling them. The Deep State protects its own and self-deals in all things.
-OAB
Hope you’ll string your latest twitter thread together into a blog post for sharing: https://nitter.net/i/status/1536157725465657347
It’s a very valuable summary that more people need to see. If you have guidance on how we can right the ship before it sinks, I hope you’ll share it.