Trackr.Live The landing site for Trackr Services
§ Trackr.Live

SC — System and Communications Protection

System and Communications Protection is the largest and most technical family in NIST SP 800-53. It is the one where the controls stop being process and start being protocol: TLS versions, cipher suites, validated crypto modules, DNSSEC, boundary firewalls, the encryption sitting under your storage volumes. SC governs how the system protects information moving across the wire, sitting at rest, and crossing the perimeter, plus the supporting machinery (keys, certificates, name resolution) that makes any of that real. If AC is about who gets in, SC is about what the network and the cryptography do once they are in motion.

A network boundary rendered as a layered perimeter: an outer managed interface filtering traffic, an encrypted tunnel crossing it, and an inner enclave of data blocks shown locked at rest.

SC is a control catalog family, not a phase of the RMF. The RMF is the SP 800-37 process: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. SC controls get pulled in at Select off your baseline, stood up and written into the SSP at Implement, and graded at Assess, with whatever fails landing in the POA&M. The catch with SC is that its controls are unusually checkable. An assessor can’t easily prove your account recert is theater, but they can absolutely run nmap --script ssl-enum-ciphers against your boundary and watch TLS 1.0 answer. SC findings tend to be concrete, reproducible, and hard to talk your way out of.

The two that carry the family

Two clusters do most of the work, and most of an assessor’s time lands on them.

SC-7, Boundary Protection, is the headliner. It is the control behind your firewalls, your DMZ, your managed interfaces, the whole question of how traffic crosses the system boundary and what inspects it on the way. SC-7 is baseline-allocated at Low, Moderate, and High, and the enhancements stack hard as you climb. SC-7(3) wants you to limit external access points (fewer ingress paths, each one watched). SC-7(4) covers external telecommunications services and the managed-interface posture around them. SC-7(5) is the one assessors check first: deny-by-default, allow-by-exception on the boundary. If your egress rules are permissive and you’re filtering inbound only, SC-7(5) is a finding and a real risk both. SC-7(8) routes internal traffic to authenticated proxy servers before it reaches external networks. On a High system the SC-7 enhancement set alone can run longer than some entire control families.

The crypto cluster is the other anchor. SC-8, Transmission Confidentiality and Integrity, protects data in motion; SC-8(1) is the cryptographic-mechanism enhancement, which in practice means TLS for almost everyone and IPsec for the rest. SC-28, Protection of Information at Rest, is its at-rest counterpart, with SC-28(1) again calling for cryptographic protection. Both typically show up at Moderate and above. Note that SC-9, Transmission Confidentiality, was withdrawn and rolled into SC-8 back in Rev 4; it stays withdrawn in Rev 5. If your SSP still cites SC-9 as a live control, that’s a Rev-4 artifact someone forgot to retire, and it’s a tell that the document predates the current catalog.

Sitting underneath both is key and crypto management. SC-12 is cryptographic key establishment and management (generation, distribution, storage, rotation, destruction). SC-13, Cryptographic Protection, is the control that says where cryptography is required, it has to be the right cryptography. And that is where the most important finding in this family lives.

SC-13 and the FIPS 140-3 trap

SC-13 doesn’t just want encryption. It wants FIPS-validated cryptography, and “validated” is a specific, checkable thing that vendors routinely blur.

A module is FIPS 140-3 validated when it appears on NIST’s Cryptographic Module Validation Program (CMVP) active list with an actual certificate number. That certificate ties to a specific module, a specific version, and a specific operational configuration. What you’ll see in vendor marketing instead is “FIPS compliant,” or “uses FIPS-approved algorithms,” or the product runs its crypto library “in FIPS mode.” None of those are the same claim. A library can implement AES correctly and still have no CMVP certificate, which means it satisfies the spirit of the algorithm and fails the letter of SC-13. The assessor-facing version of this check is blunt: get the CMVP certificate number, look it up, confirm the version you’re running matches the validated version, and confirm the module is in its validated configuration. “We use OpenSSL in FIPS mode” is the start of that conversation, not the end of it.

The standard transition matters too. CMVP stopped accepting new FIPS 140-2 submissions and moves 140-2 certificates to the Historical list as their sunset dates pass; FIPS 140-3 is the active validation standard. A 140-2 certificate isn’t worthless the day it goes Historical, but pointing at a long-expired one as SC-13 evidence on a system being authorized today invites the question of what your refresh plan is.

Deeper: where “encrypted at rest” quietly stops meaning what you wrote.
SC-28 says protect information at rest, and the cloud makes it easy to check a box that doesn’t mean what the SSP implies. “Encrypted at rest” on a managed service usually means the cloud provider encrypts the storage substrate with provider-managed keys. That protects against a stolen physical disk. It does almost nothing against a compromised tenant or an over-broad IAM role, because the platform transparently decrypts for anyone your access controls let through. If your SC-28 narrative leans on provider-managed encryption, an assessor who knows the difference will ask who holds the keys and who can scope them. Customer-managed keys (a real KMS/CMK boundary you control, ideally tied to SC-12 key management) are a materially different control than the provider’s default storage encryption. Writing “encrypted at rest” and meaning “the CSP encrypts its own disks” is the most common SC-28 overstatement in cloud SSPs, and it conflates your control with the provider’s.

The rest of the family, by weight

SC runs from SC-1 all the way to SC-51 in Rev 5, so the back half matters as much as the front. The ones worth naming:

  • SC-1 is the family policy and procedures. Same -1 pattern as every family, first thing pulled, everything else inherits its existence.
  • SC-2 (Separation of System and User Functionality), SC-3 (Security Function Isolation), and SC-39 (Process Isolation) are the architectural isolation controls. SC-2 keeps admin interfaces away from general user functionality, SC-3 isolates the security-relevant functions, and SC-39 wants separate execution domains per process (on any modern OS you largely inherit that from the kernel and document it accordingly).
  • SC-4 (Information in Shared System Resources) is the no-residual-data control: memory and storage shouldn’t leak the last tenant’s information to the next.
  • SC-5, Denial-of-Service Protection, and SC-6, Resource Availability. SC-5 is real but often thinly implemented; in cloud it frequently maps to the provider’s DDoS protection plus your own rate limiting and capacity headroom. SC-6 is live but minor.
  • SC-10 (Network Disconnect) terminates the network connection after a defined period of inactivity. SC-11 (Trusted Path) is narrower than it sounds: it’s a protected channel between the user and the system’s security functions, the classic example being a local logon path that can’t be spoofed by a fake prompt. It is not “a trusted path to access the network,” which is a common misread.
  • SC-15 (Collaborative Computing Devices) is the camera-and-mic control: no remote activation without the user knowing, an explicit indication when they’re on. SC-16 is Transmission of Security and Privacy Attributes in Rev 5 (the catalog systematically added “and privacy” across families; an SSP calling it just “Security Attributes” is quoting Rev 4).
  • SC-17 (PKI Certificates) governs issuance and management of certificates from an approved CA. SC-18 (Mobile Code) handles Java, ActiveX, and the rest of the executable-content surface.
  • SC-20, SC-21, SC-22 are the DNS trio. SC-20 is secure name resolution at the authoritative source (DNSSEC signing your zones). SC-21 is secure resolution at the recursive/caching resolver (DNSSEC validation on the way in). SC-22 is the architecture and provisioning behind both, including resolver redundancy and internal/external separation.
  • SC-23 (Session Authenticity) protects session integrity against hijacking and man-in-the-middle, which in web terms means TLS done right plus sane session-token handling.
  • SC-45 (System Time Synchronization) is new in Rev 5 and quietly important: it ties directly to AU-8 audit timestamps. If your hosts drift, your correlated logs lie, and your incident timeline falls apart.

Two more to flag as withdrawn in Rev 5 so nobody cites them: SC-9 (into SC-8, above) and SC-14, Public Access Protections (the capability was distributed across AC-2, AC-3, AC-5, AC-6, SI-3, SI-4, SI-5, SI-7, and SI-10). Both showing up live is a Rev-4 document tell.

Baselines and the assessor’s table

The baselines live in SP 800-53B, not in the catalog. FIPS 199 sets your impact level, FIPS 200 sets the floor, and 800-53B turns that into a starting SC control set you then tailor (CNSSI 1253 overlays it for national-security systems; FedRAMP and DoDI 8510.01 layer their own selections). SC-7 and SC-13 ride at every impact level. SC-8 and SC-28 generally show up at Moderate and climb. The SC-7 enhancement stack is where the High baseline gets heavy.

Control Typical first live at What an assessor actually checks
SC-7 Low Boundary diagram matches the real network; enumerate every managed interface and ingress/egress path, not just the documented one.
SC-7(5) Moderate Egress is deny-by-default. Permissive outbound rules are a finding even when inbound is tight.
SC-8 / SC-8(1) Moderate TLS version and cipher suites on the wire (ssl-enum-ciphers), not the SSP claim. Internal east-west traffic too, not just the edge.
SC-13 Low CMVP certificate number, version match, validated configuration. “FIPS mode” without a certificate doesn’t clear it.
SC-17 Moderate No self-signed or expired certs on in-scope services; chain to an approved CA.
SC-21 Low DNSSEC validation is actually enforced on the recursive resolver, not just “supported.”
SC-28 / SC-28(1) Moderate Who holds the keys. Provider-managed default storage encryption is not the same control as customer-managed keys.
SC-45 Not baselined (overlay/org-defined) Hosts sync to an authoritative time source; drift confirmed against AU-8 timestamp integrity.

Treat “first live at” as directional. Your overlay moves it, and a SC-7 enhancement optional at Moderate is often mandatory at High.

Where SC rots in practice

Here’s where I’ll plant a flag: most “TLS everywhere” claims under SC-8 are true at the edge and false inside the boundary. The public-facing load balancer terminates a clean TLS 1.3 connection, the assessor checks it, it passes. Then the traffic goes plaintext for the east-west hop between the app tier and the database, or between microservices on the same VLAN, because somebody decided the internal network was “trusted.” SC-8 doesn’t care that it’s internal. If the data is moving and the control applies, it applies on the inside too, and an assessor who only checks the front door is doing you no favors. Service-mesh mTLS exists for exactly this; if you’re claiming SC-8 across the system, be ready to show the internal legs.

The other recurring failures are smaller but just as findable. SC-7 boundary diagrams drift from the real network within months, and the assessor compares the diagram to a config pull. SC-17 certs go self-signed or expire on internal services nobody monitors because they “aren’t public.” SC-21 DNSSEC gets claimed but not enforced (validation present in the resolver config, never actually turned on, so a forged response still resolves). And the SC-28 provider-key problem from the callout above recurs across cloud SSPs.

Cross-family ties are where assessors connect the dots, so write them into the SSP rather than making someone derive them: SC-7 boundary protection ties to CA-3 (system interconnections) and AC-4 (information flow enforcement). SC-8 and SC-28 crypto tie down to SC-12/SC-13 key and module management and over to IA-5 authenticator protection. SC-7(4) managed interfaces touch AC-17 remote access and CM. SC-45 time sync ties straight to AU-8 timestamps, and that link is the one people forget until their incident timeline doesn’t reconcile.

The fastest way to fail an SC assessment is the same as anywhere else: an SSP that paraphrases the catalog back at the assessor instead of describing what this system actually does on the wire. They’ve read the catalog. They want the cipher suite, the certificate number, the resolver config, and the key custodian.

Sources

Adjacent material on this site