CMMC SC Controls: Protecting Boundaries and Data in Transit

Paul Netopski

Welcome back. Today we’re in System and Communications Protection, or SC. And this really builds on prior CMMC topics. Access control told us who should get in, auditing told us what happened, and configuration management gave us a stable setup. Now we protect the pathways.

Roz the Rulemaker

Right. Start with plain language. Your external boundary is where your environment meets the outside world, usually the internet or another outside network. Key internal boundaries are the important dividing lines inside your environment, like between office users and a CUI enclave, or between development and production.

Paul Netopski

For SC.L1-3.13.1, assessors want those boundaries defined, and communications at those points monitored, controlled, and protected. Firewalls, proxies, and logs are common ways to do that. And document your inbound and outbound rules, then review them periodically so they remain intentional.

Roz the Rulemaker

Next is SC.L1-3.13.5. If the public can reach it, identify it. Websites, applicant portals, customer portals, maybe a public file drop. Those systems should not sit on the same network segment as your internal business systems.

Paul Netopski

Exactly. Put them on a separate subnetwork, often called a DMZ, meaning a demilitarized zone. The point is physical or logical separation from internal networks. And the safe default is to block access back into the internal environment unless a specific business need has been approved and configured.

Roz the Rulemaker

From an assessment standpoint, if you have no public-facing systems, this control might be not applicable. But if you do have them, be ready to show the diagram, the firewall rules, and how you prevent that public server from becoming a bridge into the rest of the company.

Paul Netopski

SC.L2-3.13.2 is security engineering. This is less about one device and more about how you design systems. The guide points to layered protections, defined security architecture, clear boundaries, security requirements in the lifecycle, and threat modeling.

Roz the Rulemaker

Or, in more everyday terms, don’t bolt security on at the end. Build it in when you change a system, upgrade a platform, or stand up something new. A small business might choose segmented design and layered defenses because they’re practical and understandable.

Paul Netopski

Good implementation advice: define security requirements before the change, review the design, and ask simple threat questions like, “What could go wrong here, and what would stop it?” Assessors will look for identified designs and principles, and evidence you actually used them, not just named them in policy.

Roz the Rulemaker

SC.L2-3.13.3 is role separation. User work and system administration work should be separated. That means email, web browsing, and daily office tasks should not happen from the same account or path used to manage servers, firewalls, or databases.

Paul Netopski

Yes. System management functionality usually requires privileged access. The guide allows physical or logical separation. Different computers, different operating system instances, different network paths, jump boxes, separate admin interfaces, those are all valid patterns.

Roz the Rulemaker

And this is where earlier access control topics matter. Separate accounts are key. A regular user account for normal work. A privileged account for administrative work. If an assessor asks, “Show me how admins manage systems,” you want a clean answer, not, “Well, they just use the same laptop and same login for everything.”

Paul Netopski

SC.L2-3.13.4 deals with shared system resources. The concern is residual data. One user should not get information left behind by another user through shared memory, disks, cache, or similar resources.

Roz the Rulemaker

This one sounds abstract, but the business point is simple: no leftovers. If a workstation is reassigned, if a virtual environment is reused, if a shared platform hosts many users, the prior user’s data should not still be exposed. Operating systems and vendors often handle much of this, but you still need to verify settings and configurations.

Paul Netopski

Sandboxing, cleanup features, current patches, and secure default settings all help. Assessors may ask how you prevent unintended transfer through shared resources. So be ready to point to vendor controls, configuration baselines, and any validation you performed.

Roz the Rulemaker

SC.L2-3.13.6 is one of my favorites because it is very clear: deny by default, allow by exception.

Paul Netopski

Agreed. At relevant boundaries, inbound and outbound traffic should start blocked. Then you permit only what is required: specific ports, protocols, services, and destinations. Nothing more.

Roz the Rulemaker

That means your firewall rules should read like a deliberate business list. This application needs HTTPS out. This admin tool needs a specific management port from a specific subnet. That sort of thing. Not “allow any to any” because it was faster on a Friday.

Paul Netopski

And review exceptions regularly. Small allow lists are easier to defend and easier to explain during assessment. The criteria are straightforward: traffic denied by default, and traffic allowed by exception. Your configurations should visibly prove both.

Paul Netopski

SC.L2-3.13.7 addresses split tunneling. A remote device should not use the company VPN and another outside internet path at the same time.

Roz the Rulemaker

Because that creates a side door. The laptop could be talking securely to the company while also talking to an uncontrolled network. If the outside side is compromised, risk can travel inward. Terrible arrangement, frankly.

Paul Netopski

The guide says disable split tunneling in remote devices and prevent users from easily changing that setting. You can also detect it on the system side and deny the connection if split tunneling is enabled.

Roz the Rulemaker

And test it. Don’t just trust the checkbox in the VPN console. Use a remote device and verify that all traffic stays inside the protected tunnel. That demonstration is the sort of thing an assessor may want to see.

Roz the Rulemaker

Now SC.L2-3.13.8, protecting CUI during transmission. If CUI is moving across networks, especially untrusted ones, use cryptographic protection, or in some cases alternative physical safeguards.

Paul Netopski

Common technical examples in the source are TLS tunnels and IPSec. The intent is to prevent unauthorized disclosure while data is in transit. And this applies broadly to system components that transmit information, not just servers.

Roz the Rulemaker

Practical advice: identify where CUI actually moves. Email, file transfers, remote access, cloud applications, site-to-site links. Then document where encryption is required and how you verify it. If you can’t answer where CUI travels, you can’t protect it well.

Paul Netopski

And if you rely on an alternative physical safeguard, be able to explain it clearly. Otherwise, encryption is usually the cleaner path for assessment evidence.

Paul Netopski

SC.L2-3.13.9 is about terminating network connections at session end or after a defined period of inactivity. Not just user sessions, network connections.

Roz the Rulemaker

Right, and that distinction matters. If a communications session ends, the associated connection should not just linger forever. And for idle connections, you define an inactivity period based on business need and risk.

Paul Netopski

A remote admin connection, for example, should time out after inactivity. Same for other network-access tools. The guide emphasizes defining the period, implementing the timeout, and making sure it fits the organization.

Roz the Rulemaker

So don’t copy a number from somewhere and call it done. Pick a value you can defend. Then show the configuration and, ideally, a test or screenshot proving the termination actually occurs.

Roz the Rulemaker

SC.L2-3.13.10 is key management. If you use cryptography, you need keys, and those keys need a lifecycle.

Paul Netopski

Correct. The source calls for keys to be established and managed whenever cryptography is employed. In practice, that means knowing how keys are created, stored, distributed if needed, rotated, revoked, recovered, and destroyed.

Roz the Rulemaker

And keep access narrow. The smallest practical group should handle them. If everyone in IT can reach the encryption keys, that’s not really management, that’s just hope.

Paul Netopski

For smaller organizations, simple and consistent is better than elaborate but uneven. A documented process, an inventory or tracking method, restricted access, and clear ownership go a long way. Assessors will want to see that key handling is not improvised system by system.

Paul Netopski

SC.L2-3.13.11 is specific: use FIPS-validated cryptography when encryption is protecting the confidentiality of CUI.

Roz the Rulemaker

And this is where people trip. Seeing an algorithm name like AES is not enough. The source is explicit: the cryptographic module, software or hardware, must be validated under FIPS 140. Module, not just marketing language.

Paul Netopski

Exactly. Tie your encryption decisions to where CUI is stored, sent, or accessed. Laptops, removable media, remote access, transit over untrusted networks, backup protection, all of that may bring this control into play.

Roz the Rulemaker

Assessment-minded guidance: keep records of the product, the module, and validation status. If you had to enable a specific FIPS mode in the product, document that too. That makes the conversation with an assessor much easier.

Roz the Rulemaker

SC.L2-3.13.12 covers collaborative devices: cameras, microphones, networked whiteboards, smart boards, things like that.

Paul Netopski

The requirements are direct. Identify the devices, provide indication when they are in use, and prohibit remote activation. The exception note in the guide is that dedicated video conferencing systems are treated a bit differently if a participant must actively connect the call.

Roz the Rulemaker

For most organizations, the practical step is inventory first. Then confirm each device gives users a visible or audible cue when active. A light, an onscreen message, something clear. And unless there is an approved need, remote activation should be off.

Paul Netopski

If a device lacks a built-in indicator, the guide suggests manual means. But technical controls are usually easier to sustain and easier to evidence.

Paul Netopski

SC.L2-3.13.13 is mobile code. That includes technologies like Java, JavaScript, ActiveX, PDF, Flash, and VBScript in the source.

Roz the Rulemaker

Not all mobile code is bad, but it needs control. Decide what is allowed, what is blocked, and what needs an exception process. Browser plug-ins, scripts, and similar code can become a delivery path for malicious activity.

Paul Netopski

Use allow lists or formal approvals for exceptions, and monitor usage through logs, boundary devices, or endpoint tools. The criteria are control and monitoring, both. Not one or the other.

Roz the Rulemaker

And please revisit old exceptions. A department that needed something three years ago may not still need it. I’ve seen ancient plug-in allowances linger forever. That’s governance drift, and assessors notice drift.

Roz the Rulemaker

SC.L2-3.13.14 is VoIP, Voice over Internet Protocol. If the organization uses it, define how it is approved, configured, and monitored.

Paul Netopski

Threats are similar to other internet-based applications. The guide mentions eavesdropping and caller ID spoofing as concerns. So require strong administration controls, authentication, and logging for the system.

Roz the Rulemaker

Also monitor for unapproved tools. Shadow IT shows up here too. People install whatever calling app is convenient, and suddenly business communications are happening outside approved controls.

Paul Netopski

If your VoIP solution supports encryption, that helps protect confidentiality and integrity. And from an assessment view, be ready to show the approved solution, the admin access controls, the patching approach, and the logs.

Paul Netopski

SC.L2-3.13.15 is communications authenticity. Both ends of a session should have confidence in who they are talking to, and in the validity of what is transmitted.

Roz the Rulemaker

The guide highlights risks like man-in-the-middle attacks, session hijacking, and false information inserted into a session. So secure protocols and sound certificate management matter quite a bit here.

Paul Netopski

Mutual authentication is one strong approach, especially between devices, though the source speaks generally about protecting session authenticity. Certificates need to be current, configurations need to be secure, and weak settings need to be avoided.

Roz the Rulemaker

In practical terms, validate the setup. Don’t just install certificates and assume all is well. Check expiration handling, trusted sources, and secure protocol settings so sessions are harder to spoof or alter.

Roz the Rulemaker

Last one, SC.L2-3.13.16: protect the confidentiality of CUI at rest. That means when it is stored, not moving. Laptops, servers, media, backups, offline storage, all of it. Encryption is one method, physical safeguards are another, depending on the environment.

Paul Netopski

And document where CUI lives and how it is protected there. That inventory and system understanding are essential. If you cannot map where the data rests, you cannot convincingly explain how confidentiality is maintained. [pauses] That’s the assessment lens through this whole domain.

Eric Marquette

[warmly] Great walkthrough, both of you. Practical, grounded, and very CMMC-minded. Paul, Roz, thanks for breaking down a dense set of controls into things leaders and operators can actually use.

Roz the Rulemaker

Always a pleasure, Eric.

Paul Netopski

Good to be here. We’ll keep building the model one domain at a time.

Eric Marquette

And we’ll see everyone next time. Take care, Paul. Take care, Roz.

Roz the Rulemaker

Goodbye.

Paul Netopski

Goodbye.