Looking for opinions on the 800-171 requirement regarding split tunneling for VPN connected users. Have seen and heard nothing but dissenting opinions. But the three flavors I’m seeing are below. Curious if anyone has strong opinion or audit experience.
Option 1: full tunnel, everything including Teams calls must tunnel back through the firewall.
Options 2: Tunneling with exclusions. Most everything must tunnel back except a few trusted applications like Teams.
Options 3: Split tunneling remains allowed, but instead endpoints are protected against connection to bad actors via Sentinel One, strong DNS filtering, etc.
Option 3 is out, the control literally says no split tunneling. I think depending on your assessor, you may be able to get away with option 2 - but to the letter of the law option 1 is the only real choice.
Edit: I was wrong, with the updates to 800-53 and 800-171r3, option 1 and 2 are viable solutions with appropriate security compensation.
I coauthored a whitepaper (“CMMC and Split Tunnels”) on this topic a few years ago. https://defcert.com/resources/
Using a combination of host-based firewalls to deny inbound traffic and web content filtering or DNS resolution tools, you can land somewhere between option 2 and 3.
The approach documented in the whitepaper has worked in numerous DIBCAC audits and CMMC JSVAs so far.
We use option 2 and call it “dynamic routing”.
There’s a lot of reasons to prevent split tunneling, and forcing all the traffic through your standard firewall is one. Another big reason is that it drastically lowers the capabilities of a bad actor on an open network. Another really important reason is that your network config will change over time and things you didn’t know existed will come up. Will you update to accommodate? Probably, but maybe not.
Ipsec throughput on even a cheap firewall is insane, bandwidth is cheap, and your client systems have the encryption optimized. Just full tunnel and call it a day. It’s so much more work otherwise. Hell a 600$ fortigate will do 6.5gbps. Just run the tunnel to it and have it come out of your standard firewall.
You cannot split tunnel under Rev 2. Rev 3 allows it as long as you’re ensuring the protection. Since this control is VPN-specific, I dropped VPN altogether and do all the firewall, filtering, et cetera at the endpoint level.
We are moving to a Ztna type vpn with fortinet. So it’s not really a vpn
https://csrc.nist.gov/pubs/sp/800/207/final
Rybo is an expert. Options 1 and 2 will pass. Based on the requirement going away in 171rev3 I dont see many assessors deep diving it.
Doesn’t draft rev 3 allow it?
After 800-171 R2 was published, NIST updated 800-53 (the controls catalog 800-171 is based on) to allow multiple “securely provisioned” connections.
We’ve used that change to argue options 2 and 3 in formal assessments. Option 3 requires multi-layered policy enforcement, where EDR, content filtering, and DNS based SASE evaluate an outbound connection before allowing it.
Let’s play devil’s advocate on option #2. I read Rybo’s white paper. The split tunnel assumes the O365 cloud tenant is GCC or above. What if as a policy we do not store CUI in our cloud tenant, it’s just there for email and teams. Everything really lives in our on prem hardware. Does that change the answer?
Oh that’s great if true. Im not at my desk to check, ill update my comment when i do. For now though, the CMMC is still based off r2, the proposed rule released in December still mentions it rather than saying r3 or the current version of 800-171.
Rev 3 does away with this requirement.
Oh cool, that’s great to hear. I’ll update my comment.
Still commercial Microsoft. Actually still FedRAMP moderate. Even if not I still think it will pass. Have a good explanation on how you are controlling it.
Hey there! In the case of the whitepaper, M365 really just represents a system that’s under your organizational control and needs to be accessed remotely (over the internet). It’s also a system that would benefit from a direct connection instead of routing through your corporate firewall first (your NGFW was going to allow microsoft.com traffic anyways).
Even if you never store CUI in Office 365, securely provisioning a direct tunnel to Microsoft services would drastically improve Teams meeting performance and reduce latency for remote workers compared to routing them through your corporate firewall.