What is Federal Contract Information (FCI)?
If you have a contract to develop or deliver a product or service to the Federal Government, you undoubtedly process, store, or transmit Federal Contract Information (FCI). FCI is information which is generated by the contractor or received from the government or other contractors, during the execution of any part of a Federal contract. This could include items such as process documentation, performance reports, proposal responses, organizational charts, delivery or purchase orders, or invoices. FCI is sensitive enough in that it cannot be shared publicly without explicit permission from the Federal government, but it is not as sensitive as Controlled Unclassified Information (CUI). FAR Clause 52.204-21 dictates a “basic” set of 17 cybersecurity safeguards you must put in place to adequately safeguard FCI. In this post, we will explore these basic requirements and provide some interpretation for you as you prepare to self-assess in accordance with the CMMC. We have also created a CMMC Level 1 Checklist, which you can download for free at the end and use to assess your implementation of FAR 52.204-21.
What does FCI have to do with CMMC?
The Cybersecurity Maturity Model Certification (CMMC) program is the DoD’s method for holding us, its supply chain, accountable for protecting DoD information, including FCI. Although CMMC is not in any contracts at the time of this writing, the DoD has stated that it could begin appearing as soon as May of 2023. As the table below indicates, the type of information that you handle will determine the level of CMMC certification you can plan to receive:
So, if you just handle FCI, you will perform a self-assessment against the 17 basic safeguards laid out in FAR 52.204-21 (the “FAR 17”, as we call it), and this equates to a CMMC Level 1 certification. Since every contractor within the DoD supply chain handles FCI, every contractor will require at least a CMMC Level 1 certification. Note that all CUI is FCI, but not all FCI is CUI. If you are looking for help identifying CUI in your own environment, we recommend you follow the steps outlined in our CUI identification blog. We should also mention that the FAR 17 is entirely “baked in” to the NIST 800-171 framework; meaning that if you are implementing NIST 800-171 to protect CUI, as required by DFARS clause 252.204-7012, you will inevitably address all of the FAR 17 controls. We explore this further in the next section.
A deep dive into the FAR 17 and CMMC Level 1
OK, time to get our hands dirty interpreting these requirements. The FAR 17 can be summarized into six different “capabilities”, each of which will be addressed in this post individually:
- Identify what to protect
- Describe your system
- Control access
- Protect system from malicious code
- Identify and fix system flaws
- Prevent accidental release of FCI
Identify what to protect
According to the CMMC Scoping Guide, all assets which process, store, or transmit FCI are considered “in-scope”, and thus the FAR 17 applies to those assets. The same goes for CUI, only instead of the FAR 17, all of NIST 800-171 would apply. So, once you have identified what is FCI, you’ll need to determine how FCI travels throughout your environment. To do this, we recommend you send each piece of FCI through our information lifecycle exercise. This means describing how each element of FCI is:
Unfortunately, this is a step many DoD contractors tend to overlook, as they assume that they already know the full extent of where their sensitive information is traveling. We recommend you take the time to be thorough during this step, as it will help you fully reveal your FCI scope, and it might also help you realize some nice business efficiency gains as a result. This is a crucial first step to identifying and protecting FCI, as the reason the FAR 17 doesn’t specifically address this step is because it assumes that this has already been done.
Describe your system
Now knowing where FCI exists in your environment, it’s time to begin describing the IT system assets which are facilitating the processing, storing, or transmitting of FCI. There is one FAR 17 safeguard (referenced using the NIST 800-171 control ID) which deals with this capability:
This is going to involve developing a clear and detailed IT system inventory. You will need to maintain a list of all the hardware, software, and system users within your environment, and we recommend that you refer to our CUI and System Inventory template to do so. Additionally, you need to identify “processes acting on behalf of authorized users” (PAOBOAU), which is a common point of confusion among us contractors, given that neither NIST 800-171 nor CMMC really explain this phrase. As we posted on our Knowledge Base, we interpret a PAOBOAU to be:
- a piece of software that installs a “user” type account in a system and relies on user credentials instead of SYSTEM credentials. For example:
- in Linux, software that installs a user that you can find in /etc/passwd or /etc/shadow
- on Windows, software that installs a user listed in Computer Management > System Tools > Local Users and Groups > Users, or installs a user in an Active Directory tree
- a process that requires credentials to access a system, such as a cloud backup agent that you install locally and that requires some sort of username/password/certificate/SSH keypair to access its cloud service “mothership”.
Regardless of your industry or size, knowing your assets is one of the very first things that you must do when spinning up a cybersecurity program within your organization. See “Our honest opinion on the FAR 17” section below for more on this concept.
The majority of the FAR 17 safeguards fall under this capability, which probably won’t come as a surprise, since the theme of FAR 52.204-21/NIST 800-171/CMMC is protecting the confidentiality (no unauthorized access) of FCI and CUI. There are 10 safeguards spanning this capability, and we will address them according to their NIST 800-171 family, as to avoid turning this blog into a novel:
The Access Control requirements shown above vary somewhat widely in purpose from one another, but a commonality among them is limit or control. This will include taking actions such as:
- maintaining a baseline of users, PAOBOAUs, and devices, as described in the previous section
- centrally managing user accounts and credentials
- enforcing the principle of least privilege – users will be given only the minimum necessary permissions to perform their jobs (e.g., no administrative privileges for employees who don’t need them)
- listing how internal devices are communicating with each other and with external devices
- using a firewall
The lone Identification & Authentication requirement for this capability is simple: require all your individual system users to have a username and password. See our password policy blog for recommendations on creating an effective password policy. Additionally, implement a means of authenticating all network devices; this could be through technology such as MAC filtering.
Next up: Physical Protection. When we are performing on-site CMMC gap assessments, it is not uncommon for us to encounter clients deficient in this area. Aside from the common-sense measure of locking doors and windows, the FAR 17 also expects that we are monitoring and logging all entry into our facilities; this includes using motion sensors and/or security cameras, radio-frequency identification (RFID) badges, and keeping an inventory of all keys. Another important theme of these requirements is holding individual users accountable for their actions. Gone are the days of just being able to waltz right into your work environment (and holding the door open for the person behind you).
Finally is System & Communication Protection. What’s not to love about reading confusing government jargon when, in reality, a simple concept is being described? The idea behind Control 3.13.1 is simple: use a firewall. When configured correctly, this will block unauthorized communications at the “internal boundaries” (inbound connections) and at the “external boundaries” (outbound connections). As for Control 3.13.5, you are going to need to stop operating on a “flat” network, where all devices are on the same subnetwork and can easily communicate with each other. Chop it up using Virtual Local Area Networks (VLANs) and isolate asset types from one another, as to prevent an adversary from breaking in and moving around with impunity. You’ll also need to ensure publicly-facing servers, such as web and email servers, are relegated to a DMZ. See a basic example of a flat network topology vs. a segmented network topology below:
Protect system from malicious code
Three safeguards have to do with protecting your IT system from malicious code, all from the System & Information Integrity family:
Once again, the idea behind all of these controls is simple: install an antivirus on all possible devices, update it regularly, and use it. You’re likely already doing this, but if not, were you aware that Windows has a built-in antivirus called Windows Defender? It is a pretty robust antivirus right out of the box, but it does require some further hardening to really lockdown. See this excellent post from 0UT3R SPACE if you’re curious (and nerdy) like we were: https://0ut3r.space/2022/03/06/windows-defender/.
Identify and fix system flaws
One System & Information Integrity safeguard pertains to identifying and fixing system flaws:
Your software vendors should be releasing regular (monthly, ideally) patches. These are necessary for correcting known errors and vulnerabilities within the software or operating system. The FAR 17 expects that you are patching your systems “in a timely manner” – our preference is whenever new patches are released. Additionally, you should be hardening all system components so that they are less prone to “system flaws”. This involves developing secure configuration settings, such as changing the default administrative credentials and using the strongest form of encryption on your router, which likely may not have been enabled by default. If you operate a Windows environment and are interested in hardening your workstations and servers, check out the Microsoft Security Compliance Toolkit.
Prevent accidental release of FCI
You’d like to wish that FCI and CUI never “accidentally” slipped into enemy hands or got posted to social media, but alas. The FAR 17 is pretty clear on what you need to do to prevent FCI from being released:
If you find yourself on Facebook really wanting to broadcast the super cool project you are a part of at work, we would caution you to stop and… not do that. Posting FCI (much less its more sensitive subset, CUI) on any form of publicly accessible website, forum, or the like is not allowed. Pretty straightforward, hopefully.
NIST 800-88, the chief framework for media sanitization of FCI and CUI, defines sanitization as, “a process to render access to target data on the media infeasible for a given level of effort”. They categorize sanitization into three different techniques: Clear, Purge, and Destroy. The sanitization technique you will take will vary depending upon what you want to do with the device housing that media; for example, if you have an old engineering laptop with FCI stored on the hard drive, and you want to pass on the laptop to a coworker, you’ll need to clear (overwrite; wipe) the hard drive first. You could use a tool such as Darik’s Boot and Nuke (DBAN) to accomplish this.
Or, if you want to help out some gamer kid on eBay and sell them the laptop, you’ll first need to destroy the media housing that FCI. So, the kid will have to find himself a new hard drive too, because you will have shredded or incinerated yours (per 800-88). We recommend that you just hold onto media (lock it away) ready for sanitization, then dispose of it in batches every now and again. Should save you a few bucks instead of doing it every time you’re moving on from old hardware.
Our honest opinion on the FAR 17
We have been asked our honest opinion of the FAR 17, and whether or not we believe it is an effective framework for “basic” safeguarding of sensitive information such as FCI. Our honest answer is… not really. Not that our opinion really matters, since the law is the law, and the FAR 17 is what is required for CMMC Level 1. However, that didn’t stop us from compiling our list of what we would like to see as the basic set of protections for creating a “defense-in-depth” cybersecurity program. We call it the Totem Top 10™:
- Know Your Assets
- Train Your Users
- Whitelist Software
- Patch Software & Operating Systems
- Restrict Admin Privileges
- Harden System Components
- Segment Your Network
- Backup Your Data & Test Restoration
- Enable Multi-Factor Authentication
- Collect & Analyze Event Logs
Some of these are baked into the FAR 17 already, but some aren’t, and that is the concerning part to us. These aren’t just our opinion, either – many of the world’s leading security organizations are already advocating for these basic safeguards. So, when we are working with small businesses who want to take cybersecurity seriously and not just do the bare minimum to be compliant with the law, we point them to the Totem Top 10™. Implementing these safeguards will not only result in a well-rounded defense-in-depth cybersecurity program, but it will also put you well on your way towards being compliant with the FAR 17. Contact us if the Totem Top 10™ is something you are interested in implementing. We can help.
During this blog, we examined all 17 safeguards required by FAR 52.204-21 and CMMC Level 1, and we provided some interpretation to help you get started. Hopefully, you concluded that none of these requirements are particularly difficult to implement, and you already have some ideas about how you will implement them in your own environment. Feel free to download our CMMC Level 1 Checklist – a tool we created for you to perform a preliminary assessment of your implementation of the FAR 17.
If you find that you would like further guidance on FAR 52.204-21, FCI, CUI or the like, grab a seat in one of our Workshops, where we talk about everything you need to know for CMMC. Or, drop us a line; we love talking about all this stuff!
Keep fighting the good fight!
–Nathan Cross, Cybersecurity Engineer