Skip to content
We’re writing this blog because several of our clients have been told by CMMC assessors that their router / firewall needs to be “in FIPS mode” or they will fail the encryption requirements for CUI, even if they are not operating a VPN or corporate WiFi.* This assertion betrays the assessors’ lack of understanding of basic networking, especially the principle of “encapsulation”. And insisting on such a requirement can mean an unecessary and expensive replacement job for small businesses. So, we’re writing this blog to explain the basics of encapsulation and how it relates to encryption so that the reader has some understanding and can effectively push back on this assertion. Enjoy!
*Editors Note: Yes, that is five acronyms in the opening sentence; we promise we’ll explain these acronyms further on. Also: specific brands and models mentioned in this blog are provided as examples only and not intended to imply endorsement.
What the heck is encapsulation?
Let’s explain the basic networking principle of encapsulation by way of analogy:
Did you know you can mail-order precious metals? That’s right, you can get 10s of 1000s of dollars worth of gold, silver, platinum, collectors coins, you name it, from companies like Kitco or JM Bullion delivered right to your door via good old fashioned shipping organizations like USPS. “Sure seems risky”, you say. While it’s not without risk, the principle of encapsulation helps mitigate that risk to an acceptable level. Let’s explore.
When a precious metal supply company ships bullion, it takes out an insurance policy on loss or theft of the delivery, but more importantly it takes steps to ensure they never have to make an insurance claim. One of the primary steps is concealment — ensuring the delivery people and other ne’er-do-wells have little clue as to what’s in the package. So with coins or other metals that go “clink” when moved around, they bind the metal tightly in cushioned plastic sleeves so that they don’t make noticeable metal-on-metal sounds, and then bind the sleeves together in a layer or two of heavy-duty cardboard. Then the whole thing is packaged up for shipping in a standard box.
This illustrates well the concept of using encapsulation to shield valuable assets from prying eyes, helping to reduce risk. For sure, if the supplier or consumer feels simple encapsulation does not mitigate the risk enough, the supplier can take additional steps to ensure lower risk such as placing the sleeves inside a locked box within the cardboard packaging, and then sending the lock combination to the consumer via separate means, such as email or text. This “locking” concept is important and we’ll come back to it. But the point is: risk is mitigated by ensuring the outside world can’t easily discern what’s inside the package.
IT networks such as the Internet run on this same principle of encapsulation. In a nutshell, networking protocols, like HTTPS (web), SMTP (email), TCP, IP, 802.11 (WiFi) are encapsulated from the inside out to make up “packets” of data that traverse the radio, WiFi, copper, and fiber links that connnect us all together. Protocols like HTTPS and SMTP are analogous to the sleeves the metal coins are wrapped in, TCP is like the heavy-duty cardboard box, and IP and 802.11 are like the outside package with the mailing label.
This encapsulation is illustrated in the graphic below, where the green “Data” block (the valuable stuff) at the Application layer is subsequently encapsulated by the Transport, Internet, and Link layers before being transmitted. We’ll call these layers the “stack”.
But here’s the crucial difference between precious metal and digital data: encapsulation alone does not mitigate the risk enough for the transmission of sensistive digital data across public networks like the Internet. Internet ne’er-do-wells can intercept network traffic and see all the contents inside unless we “lock” up the data using — you guessed it — encryption.
So now we need to talk about encryption, the “locked box” of digital data. Onward…
It matters where digital data is encrypted
Encyption is what prevents adversaries from stealing our precious digital data as we transmit it across the Internet. We use encryption protocols (mathematical algorithms) to make digital data unreadable to anyone that doesn’t have the decryption key.
When contemplating encryption, the first consideration is what type of encryption to use. For those of us in the Defense Industrial Base (DIB) who handle Controlled Unclassified Information (CUI) and face Cybersecurity Maturity Model Certification (CMMC) assessment requirements, the government has already told us what type to use: Federal Information Processing Standard (FIPS) validated encryption. (Told you we’d get to the acronyms 😉 We explain FIPS Validated encryption in detail in a separate blog, so we won’t do that again here. The downside is that requiring FIPS Validated encryption significantly limits the networking technologies we in the DIB can use, so it becomes critical to understand where to encrypt data, which is the second major consideration.
Where to encrypt data in an IP packet represents the intersection between encryption and encapsulation. If we appropriately encrypt data at the Application layer using end-to-end encryption like SSH we don’t need to encrypt further down the stack at the Transport layer. Alternatively, if we appropriately encrypt data at the Transport layer using protocols like HTTPS (the “S” stands for “Secure”) we may not need to encrypt at the IP / Internet or Link layers.
The graphic below shows some of the example encryption protocols overlayed on the encapsulation stack.
To return to our precious metals analogy, deciding where to encrypt is like deciding where to put the locked box:
- at the sleeve level
- at the shipping package level
Locking the sleeves in a small box is the simplest and least cumbersome method, analogous to encrypting at the Application layer, using a protocol like SSH, or using an Application/Transport encyption protocol like HTTPS.
Locking everything in a locked shipping container — like a Pelican case or some other ruggedized case — is the most cumbersome and expensive locking method. (Ask anyone who’s had to ship golf clubs or skis!) This is analagous to encrypting at the IP / Internet layer using protocols like TLS VPN or IPsec or at the Link layer using WiFi Protected Access (WPA).
If you’re using proper locks and keys, neither of these locking methods is better or worse per se, they just do different things for you and may or may not be easier to ship.
This lock-box / encryption relationship is illustrated in the graphic below:
Given the choice, most of us will opt for the smallest and least cumbersome locked box method, as long as the method is effective. But it really all depends on multiple factors: how precious the metals are, routes the shipment takes, quality of shipping organization, etc. But ultimately the most important factor is probably how valuable the contents are.
On the digital data side, luckily for us, the government has evaluated its CUI, and has said that we must use FIPS validated encryption, but they don’t specify at which layer. This means we get to choose, and we can choose to ship our metals in the locked wooden box instead of the Pelican case.
“Great,” you’re saying. “Thanks for the primer on encapsulation and encryption, but what does this have to do with my firewall?” Onward…
Your firewall probably isn't doing the encryption
Most small businesses operate a router / firewall combination appliance as the “gateway” to — and protection from — the Internet. This appliance can be provided by the Internet Service Provider (ISP), i.e. the ISP “modem”. But since consumers have very minimal control over ISP modems, if your business needs to establish remote access for home office workers or setup corporate WiFi networks, the modem isn’t going to cut it. So most of us end up installing our own small business grade router / firewall combo, like a FortiNet FortiGate or Ubiquiti Unifi Cloud Gateway or Cisco Meraki. For brevity, we’ll just call this appliance the “firewall” going forward.
Most modern Internet traffic is encrypted by default at the Application / Transport layer, using the HTTPS protocol. You may have noticed browsers stopped facilitating unencrypted HTTP traffic serveral years ago. Key point: this encryption is done by applications like your web browser and the web servers you connect to, not by your firewall.
The only way your firewall provides the encryption for your network traffic is if you’re operating a Virtual Private Network (VPN), if it provides the WiFi connection, or if it is doing Deep Packet Inspection (DPI). Otherwise, it’s just passing already encrypted traffic through and monitoring for bad guy activity. Kind of like the UPS guy carrying the locked wooden box inside a simple cardboard package through a tough neighborhood on the way to your place.
VPNs are used to provide secure remote access to your local network resources (e.g. fileshares, ERP servers, AI data labs) for home or satellite office workers, to ensure all remote worker network traffic is monitored and controlled, or a mix of both.
WiFi is, well, WiFi and is considered by the US government as remote access into your network.
For DPI, the firewall is pre-loaded with a decryption key that allows it to decrypt packets encrypted at the Transport layer to look for signs of malicious content. If no malicious content is found the firewall re-encrypts the packet and sends it on its way. This is like TSA inspecting all shipping packages and luggage using an X-ray machine before they are loaded onto an airplane for transport. In this case, since the firewall is re-encrypting, it must support FIPS validated encryption if the data is CUI. But very few small businesses are doing DPI (or doing it properly), so that’s all we’ll say about DPI.
When a firewall does apply encryption it’s at the Transport layer for a TLS VPN or DPI or the IP / Internet layer for IPsec or at the Link layer for WPA. In our precious metal analogy, encrypting the VPN or WiFi is like shipping the coins in a Pelican case. But what if all we need is a simple locked box for the sleeves, inside the cardboard packing box? As long as we use the correct locks (FIPS validated crypto) then that’s just fine according to the government. We don’t need to stop the UPS guy halfway through the delivery and put our whole package in a Pelican case.
In this case we rely on the Application or lower Transport layer to do the encryption for our CUI, using protocols like SSH or HTTPS. We use FIPS validated encryption at this level, and then it doesn’t matter what type of encryption we have on our VPN or WiFi. The precious data is already locked up before it even hits the VPN / WiFi protection.
And, if you’re not using a VPN or WiFi, the firewall isn’t doing any encryption anyway. In that case the topic of FIPS validated encryption on the firewall shouldn’t come up at all. So why do we have assesors telling us that our firewall needs to be FIPS validated when we don’t have a VPN or WiFi running? Onward…
So why is my assessor telling me my firewall needs FIPS-validated encryption?
Most likely, your CMMC assessor is telling you your firewall needs FIPS-validated encryption for one of two reasons:
- You’re using the firewall VPN or WiFi as the primary source of encryption for CUI data as it is transmitted outside of your network, or
- They don’t understand the requirement or basic networking concepts, including encapsulation, encryption, and routing.
In the first case, they are correct and you need to make sure your firewall has FIPS validated encryption modules and is operated in the manner to take proper advantage of those modules, aka “FIPS mode”. Using our analogy, you need the Pelican case to ship your metals because the inside wooden box is not sufficient.
In the second case, as long as as your SSH, HTTPS, etc. Application layer protocols are FIPS validated, you can and should push back on this assertion. You’re just fine shipping your wooden coin lock box in a cardboard box; you don’t need the Pelican case.
Unfortunately we see this second case too often, hence this blog. Assessors that don’t know better seem to have been trained that “all routers / firewalls need to be in FIPS mode”. All the FIPS validated encryption, all the time. This is not correct.
This misunderstanding from assessors can lead to four failed NIST 800-171 controls:
3.1.13 Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
(5 points CMMC)
3.1.17 Protect wireless access using authentication and encryption.
(5 points CMMC)
3.13.8 Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
(3 points CMMC)
3.13.11 Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
(3 points CMMC)
Since those controls are worth 3 or 5 points each, the CMMC Framework dictates that any single one of these controls marked Not Met on a CMMC assessment means you fail the assessment. Thus, major repercussions stem from the assessors’ misunderstanding of where encryption can and must happen in the encapsulation process.
You may be asking “why don’t we just get the Pelican case anyway?” You certainly can, but for many small businesses that would mean swapping out their perfectly fine firewall, paying for and onboarding a new appliance that is not necessary. Why? Because not all vendors invest in the FIPS validation process. Ubiquiti, makers of the Unifi Cloud Gateway — which is an excellent small-business-grade router / firewall device — is one such example. Ubiquiti has stated they are not willing to invest in FIPS validation, which is understandable when a vendor is trying to keep their products’ price points within small business reach. FIPS Validation is an expensive, time-consuming (and quite frankly, antiquated) process.
So, if what you have now works just fine, and you don’t need to have a FIPS validated firewall, you shouldn’t have to abide the assessors mistaken assertions and onboard new unecessary hardware. And that’s the bottom line.
Wrapping up
So now you have some information you can reference if you need to push back on a 3rd party assessor declaring arbitrarily that your firewall needs to be in FIPS mode. You don’t necessarily: if the data is properly encrypted at the Application or Transport layer, it doesn’t also need IP / Internet or Link layer encryption.
If you’re interested in learning more about this, or want to talk through the details of your business’ particular encryption stack, you may consider our Totem™ Cybersecurity Compliance Management tool Engaged subscription tier. Engaged comes with a library of training materials on all aspects of CMMC, including encryption and FIPS validation. You also have the ability to book one-on-one consultation sessions with us. We’re here for you if you need us.
Good Hunting!
–Adam