NIST SP 800-171 Control 3.13.1 / CMMC Practice SC.1.175 requires us to “Monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of information systems.”
So what the heck is a "key internal boundary" and how do we "monitor, control, and protect" them?
NIST defines boundary as “Physical or logical perimeter of a system.” (https://csrc.nist.gov/glossary/term/boundary). An internal boundary then is any logical or physically separated internal aspects of a system. A system is comprised of the hardware, software, users, processes, and procedures that your organization uses to process, store, transmit, or protect information. Internal network boundaries are established by devices and can include the following:
WiFi router establishing guest vs. corporate WiFi networks
Network switch or router establishing VLAN segments
Network switch establishing logical network subnets
Multiple network switches establishing separate physical LANs
Routers establishing gateway-to-gateway VPNs between, say, separate buildings or cost centers
Routers establishing client-to-gateway VPNs between headquarters and remote user workstations
A virtual host establishing connections between various virtual machines
A server establishing partitions to separate user interface, application processing, and database functions
Your job is to determine which of those boundaries are “key” (critical) for your organization and then to monitor network traffic across those boundaries, control the types of information that flows across those boundaries, and implement protection (such as encryption) if needed.
For instance, the separation between guest and corporate WiFi is something many of us have in place. The WiFi router does the “control” part in that it doesn’t allow guests access to the corporate network. As for the “protect” part, the WiFi router should be set up to encrypt the corporate network traffic and to authenticate users on that link. And you can certainly “monitor” both guest and corporate WiFi traffic (using an IDS or network traffic analysis tool) to look for anomalous behavior.
Another example is gateway-to-gateway VPNs across business cost centers. If your engineering staff is located in Silicon Valley, but your HR staff is located in downtown San Francisco, you may want to establish a VPN between the two facilities. But you probably want to restrict the types of information that can flow across that VPN. The HR staff don’t need access to the engineering servers, and the engineering staff don’t need access to the HR servers. But each staff would need access to the common timeclock system and email servers. So you’d setup a firewall to control each facility’s access to servers across the VPN, you’d protect email traffic by encrypting it so that potential eavesdroppers can’t listen in on email conversations, and you’d monitor all traffic across the VPN to make sure the control and protection mechanisms continue to work.
It’s important to ensure that if you designate any of these boundaries as “key” you must provide compelling evidence that you monitor, control, and protect the traffic that crosses the boundary. So you may want to be sparing in your designation to save your organization some work, especially as you begin your DoD contractor cybersecurity compliance journey. We think the minimum designations in the DFARS / CMMC environment would be:
Guest vs. corporate WiFi, and
VLAN segments separating–at a minimum–workstations from server VLANs