DFARS in Depth – Part 8: System and Communications Protection

DFARS in Depth – Part 8: System and Communications Protection

We’ll continue our in-depth look at NIST SP 800-171 and DFARS requirements with the next security requirement family: System and Communications Protection.

These security requirements in this set involve making separations between your systems and the outside world. They also require internal separations in certain cases. While some of these principles are outlined in other security requirements, here they specifically apply to the boundaries between your internal systems and other systems.

System and Communications Protection - Basic Requirements

There are two basic security requirements in this family:

  • Monitor, control, and protect communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of organizational systems.
  • Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.

These requirements are quite broad, but they emphasize the importance of making data security a priority in designing your network -- not just an afterthought. The derived security requirements give us a better idea of how to implement some of these concepts in your network design.

Separation Is Key

The first three derived requirements highlight how important separation of network and system resources is in a secure environment:

  • Separate user functionality from system management functionality.
  • Prevent unauthorized and unintended information transfer via shared system resources.
  • Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.

Separating user and management functionality again reinforces the principle of least-user access -- that a particular user account should only have the rights that it needs, and nothing more. However, for even more sensitive environments, you may need to use dedicated management workstations (or VMs) to keep management interfaces secure.

Another security requirement involves VPN connections:

  • 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).

Preventing split tunneling by VPN clients will help to keep your network secure by funneling all traffic through your network firewall and IDS/IPS. Even though it may prevent access to some local resources, such as printers, the security benefits are essential when dealing with sensitive communications.

Permit By Exception

The next derived security requirement has to do with firewalling:

  • Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).

Similar to LUA, deny-all, permit-by-exception firewalling is the best way to ensure that only the devices and services that you are aware of are able to communicate with each other and the outside world. For example, a SQL server should not normally need to listen for connections on port 80, and so such connections should be blocked at the host and/or network level.

Cryptography Requirements.

The next set of derived security requirements touch on how cryptography and PKI are used in the organization to protect confidential information:

  • Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
  • Establish and manage cryptographic keys for cryptography employed in organizational systems.
  • Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
  • Protect the authenticity of communications sessions.
  • Protect the confidentiality of CUI at rest.

Strong, secure cryptography is essential for protecting information that’s traversing network boundaries. However, unless it’s managed correctly, cryptography can give a false sense of security. So, managing and maintaining your public key infrastructure (PKI) is a key part of your overall network security.

The requirements mention “alternate safeguards”, suggesting that internal network traffic doesn’t need to be encrypted. However, many organizations are moving to a zero-trust model, where even “internal” clients are required to authenticate and encrypt traffic. While that hasn’t quite reached the NIST/DFARS standards yet, it’s a good idea to keep an eye out for these concepts that can provide additional security in the future.

Miscellaneous Security Considerations

The final security requirements that we’ll look at in this family are a few miscellaneous “housekeeping” items that can help to beef up the overall security of your network:

  • Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
  • Control and monitor the use of mobile code.
  • Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.

While all of these technologies are common in the consumer technology world, special consideration is required when deploying them in a secure environment. For example, collaboration devices, like smart white boards and videoconferencing systems can be used maliciously to monitor confidential conversations. And mobile code (ActiveX, JavaScript, etc.) have long been used for malicious purposes when run indiscriminately. So keeping a handle on the use of these technologies will help to keep your network secure.

Next week, we will conclude our discussion of DFARS and NIST SP 800-171 with the final security requirement family: System and Information Integrity. Stay tuned!