CMMC Weekly Series #6
Posted on May 1, 2020 by Theodore Wernet, CISSP
System and Communications Protection (SC)
The System and Communications Protection domain contains 27 practices making it the largest domain in the CMMC framework. Within this domain we have two capabilities: “Define security requirements for systems and communications” and “Control communications at system boundaries”. Let’s review each practice to gain a better understanding of what the requirements are. Some practices are straightforward and require little elaboration while others require a bit of a deeper dive.
SC.1.175 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 the information systems. This practice is straightforward. Implement firewalls or other network security devices to control traffic and protect your internal networks. And, if needed, internal network segregation/protection might be in order.
SC.1.176 Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. Demilitarized Zone (DMZ). A fancy term for a network that is less secure than the inside (Internal) network, but more secure than the outside (External/Internet) network. If have any resource that require public access they should live in a DMZ. This would include things like a web server, email connectors, SFTP sites, etc.
SC.2.178 Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device. This practice is straightforward and does not need any elaboration.
SC.2.179 Use encrypted sessions for the management of network devices. When setting up your network devices, it is always a good idea to enable encrypted connections. Well now it’s a requirement for CMMC. You can use CLI utilities like Putty to connect over SSH or enable TLS on your web interfaces. The whole idea is to make sure that management session is encrypted.
SC.3.177 Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. This practice is straightforward. Here is a link to the Cryptographic Module Validation Program (CMVP) webpage which has some good resources and links to current modules that are approved.
SC.3.181 Separate user functionality from system management functionality. For this practice you want to develop an organizational policy defining system management and administrative functions and who can perform them. This will be coupled with a process for how these management functions are separated from standard user functions. At a minimum, you want to employ separate accounts for these functions. In larger, more robust environments, it is a good practice to implement physical/logical separation of these systems so standard users cannot access them.
SC.3.182 Prevent unauthorized and unintended information transfer via shared system resources. This practice should be easily met as most common Operating Systems have employed the idea of “sandboxing” resources such as processes, memory, cache, etc. for years. It is a good idea to review vendor best practices on system hardening and, if possible, apply those to your systems to aid in implementing this control.
SC.3.183 Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception). For years firewalls have had an out-of-the-box implicit rule to block all inbound traffic. You would then create “permit” rules for inbound communication. However, the standard outbound rule is “let everything through”. This practice goes a step further by saying “block ALL traffic in both directions” and create rules for necessary traffic only. This can be a challenge but with tools like packet sniffers and port scanners it can be made a bit easier.
SC.3.184 Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling). Another straightforward one. Disable split-tunneling in your VPN configuration and ensure it has not been enabled on any of your devices.
SC.3.185 Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. Encryption, Encryption, Encryption! This practice really focuses on how your organization handles CUI in transit. If that data is leaving the security of your internal networks you need to ensure you are protecting it. An example would be setting up VPN tunnels when moving data across networks (example: branch offices, remote employees, etc.). The key is to encrypt the data in transit and ensure you are using FIPS-validated encryption to do it.
CUI is a peculiar and seemingly amorphous type of information. Simply put, it requires safeguarding and dissemination controls but is not classified. Still not sure if you traffic in CUI? Read this.
SC.3.186 Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity. This practice is clear-cut. Ensure you have idle connection timeouts configured on the applicable resources. Timeout thresholds should also be documented in organizational policy.
SC.3.187 Establish and manage cryptographic keys for cryptography employed in organizational systems. Create a policy and develop procedures for crypto key management. This could be a manual process or automated process. It just needs to exist to ensure your crypto keys are managed properly.
SC.3.188 Control and monitor the use of mobile code. Let’s face it, mobile code has inherent security risks and needs to be treated as such. The best policy is to disable it all together. If it is needed, you should track where it is used, periodically review the need for it, and disable it when it is no longer needed.
SC.3.189 Control and monitor the use of Voice over Internet Protocol (VoIP) technologies. VoIP used to be a luxury for large organizations that afford to spend the money on local call management solutions and the IT overhead to administer them. Now with affordable hosted solutions, VoIP is everywhere. The intent of this practice is to ensure you have a organizational VoIP policy that defines how these systems should or should not be used and ensure you configure these devices as securely as possible.
SC.3.190 Protect the authenticity of communications sessions. This practice is focused on integrity of user authentication. Things like single factor authentication, expired certificates and the use of weak cipher suites can all lead to compromised authentication sessions. Keep your certs updated and review your cipher suites and system configurations. Implementing a form of multifactor authentication can also help you meet this practice.
SC.3.191 Protect the confidentiality of CUI at rest. Encrypt your data! With built-in solutions like BitLocker, it can cost very little to implement this practice. Just be sure to test thoroughly and understand your recovery options before you implement this practice.
SC.3.192 Implement Domain Name System (DNS) filtering services. DNS filters are available in both on-premise and hosted solutions. Many products offer low priced entry points for small businesses, so you don’t have to break the bank on this one.
SC.3.193 Implement a policy restricting the publication of CUI on externally owned, publicly accessible websites (e.g., forums, LinkedIn, Facebook, Twitter). Develop a policy that addresses who is responsible for posting information on public sites, who is responsible for reviewing the data before it is posted and what measures are used to ensure CUI is not posted in these locations.
SC.4.197 Employ physical and logical isolation techniques in the system and security architecture and/or where deemed appropriate by the organization. The intent of this control is to separate your CUI data from unnecessary access. This can be done in a myriad of ways from logical separation using VLANs to physical separation by setting up standalone systems. The idea is to protect the data by ensuring only people who need access to it have it.
SC.4.228 Isolate administration of organizationally defined high-value critical network infrastructure components and servers. Out-of-Band Management (OOBM) network. This type of network separation has been utilized for years and just makes sense. Place your management traffic on separate (physical/logical) network from your production network – or any other network for that matter. It takes some foresight to make this work, but it’s a good security practice.
SC.4.199 Utilize threat intelligence to proactively block DNS requests from reaching malicious domains. For this practice I recommend bundling your DNS filtering service with a threat intelligence service to automatically update and provide maximum protection. As a best practice you still should subscribe and review publications/feeds/etc.
SC.4.202 Employ mechanisms to analyze executable code and scripts (e.g., sandbox) traversing Internet network boundaries or other organizationally defined boundaries. “System and information Integrity SI.3.220” is already covering the email portions of sandboxing. This practice looks at all incoming files as requiring a sandbox. The intent of this practice is that as malicious code gets harder to detect, we must look at all objects as possible methods of malicious execution and treat them as such.
SC.4.229 Utilize a URL categorization service and implement techniques to enforce URL filtering of websites that are not approved by the organization. There are several solutions on the market today to meet this practice. The idea here is to ensure you set up a solution with a subscription service to update the list of URLs dynamically to help reduce the chances of someone accessing a malicious site.
SC.5.198 Configure monitoring systems to record packets passing through the organization’s Internet network boundaries and other organizationally defined boundaries. Packet capture. There are a couple of different technical approaches one can take. You could mirror the port and send it to a collector. You could install an inline tap device to capture the data or utilize a third-party appliance to process the packet capture. The real trouble begins with data retention. Packet capture can generate huge volumes of data so you may need a very large amount of storage. This will also be compounded by your retention policy. So, make sure you plan ahead in your purchase by sampling how much data you collect over a given period and determining what your retention policy will be.
SC.5.230 Enforce port and protocol compliance. This practice is straightforward. Ensure you have a device that is capable of port/protocol inspection and configure it to meet your organizational needs.
SC.5.208 Employ organizationally defined and tailored boundary protections in addition to commercially available solutions. Malicious actors have developed methods to subvert standard out-of-the-box security devices. To help defend against this threat, this practice demands organizations customize their security products to prevent these types of exploits. This could mean custom IPS signatures, customer configurations or even custom developed solutions.