by Blake Cormier
Content Manager, E-N Computers
12+ years experience in enterprise IT and managed services.
If you’re a defense contractor, this new year is bringing you painfully closer to the time when you’ll have to meet tougher cybersecurity standards if you want to keep working with the Department of Defense. Never fear. We’ll explain the 110 requirements most businesses will need to get Cybersecurity Maturity Model Certification (CMMC), and we’ll give practical examples on how you can implement everything related to DFARS and NIST 800-171, even in a small network.
E-N Computers is a Virginia-based IT managed service provider with remote services from coast to coast. We are a certified CMMC provider focused on small business defense contractors, particularly manufacturing and engineering firms.
If you want help preparing for CMMC, schedule a free strategy session with a certified CMMC practitioner with 29 years of experience in IT. In just 30 minutes, we will go over what your next steps should be to quickly move toward certification.
First, some important dates. We don’t know exactly when the new standards will go into effect, but it could be as soon as late spring 2023. (Get more details about who needs to be certified and what steps are involved in the certification process in our Ultimate Guide to CMMC.)
And then some important acronyms. If you’re looking into CMMC certification, you have likely heard a whole list of acronyms: DFARS, NIST 800-171, CMMC, CMMC 2.0 and more.
Here’s a broad generalization of what they are: NIST 800-171 recommends cybersecurity standards. DFARS requires those standards to be followed by defense contractors. CMMC proves whether a contractor follows the standards.
DFARS, or the Defense Federal Acquisition Regulations Supplement, lays out cybersecurity requirements for defense contractors. The requirements are largely based on NIST SP 800-171, a set of recommended standards developed by the Department of Commerce. NIST SP 800-171 is a 113-page document that outlines 110 security recommendations. Up until now, defense contractors have been able to self-attest that they are compliant with these requirements. When CMMC 2.0 is finalized, most defense contractors will have to complete third-party audits to certify their compliance.
Our guide will walk you through those 110 NIST recommendations, which will become requirements for CMMC certification. (You can also download this post as a PDF and review it later.)
NOTE: The public draft of NIST SP 800-171 Rev. 3 is scheduled to be released in late spring 2023. This article will be updated to reflect significant changes.
Each of the requirement families is divided into basic security requirements and derived security requirements. Basic requirements outline the overall goal of the security requirements while derived requirements list specific controls or processes that implement those goals. But, even in these derived requirements, there are no specific means to implement these requirements — that is up to each organization’s system security plan (SSP). So, we’ll mention a few ways that these requirements can be met, but the specifics will depend on the requirements of your company and network environment.
QUICK ANSWER:
What is the difference between CMMC, DFARS and NIST 800-171?
NIST 800-171 recommends cybersecurity standards. DFARS requires those standards to be followed by defense contractors. CMMC proves whether a contractor follows the standards.
DFARS, or the Defense Federal Acquisition Regulations Supplement, lays out cybersecurity requirements for defense contractors. The requirements are largely based on NIST SP 800-171, a set of recommended standards developed by the Department of Commerce. NIST SP 800-171 is a 113-page document that outlines 110 security recommendations.
Table of Contents
- Access Control
- Awareness and Training
- Audit and Accountability
- Configuration Management
- Identification and Authentication
- Incident Response
- Maintenance
- Media Protection
- Personnel Security
- Physical Protection
- Risk Assessment
- Security Assessment
- System and Communications Protection
- System and Information Integrity
3.1 Access Control
Basic Requirements
The two basic security requirements in the Access Control family are:
- Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems)
- Limit system access to the types of transactions and functions that authorized users are allowed to execute
In other words, only authorized users should be able to access your systems, and those users should only be allowed to do what they are authorized to do. For example, a visitor to your offices shouldn’t be able to log on to one of your computers. But there’s more. For example, while your staff accountant of course needs to be able to log on to her computer and access financial data to do her job, she shouldn’t have access to engineering drawings and R&D data from another section of your office.
Derived Requirements
There are 20 derived security requirements in the access control family. These requirements cover specific ways that access control must be maintained on your network. First, let’s talk about “least privilege”. Three of the security requirements cover this important security principle:
- Employ the principle of least privilege, including for specific security functions and privileged accounts.
- Use non-privileged accounts or roles when accessing non-security functions.
- Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
“Least privilege” means granting only the rights or access needed for a specific job, task, or function. One basic way is making sure that all users — even those who occasionally need local admin rights — are not using administrative accounts for day-to-day use. This is especially true of admins who have rights to administer secure systems: they should use a secondary login for those functions, with a more limited account for things like Web browsing and email. See an example of least privilege in action with our video Least Privilege Made Simple with AutoElevate.
Another set of security requirements in this section involves remote access to your systems.
- Monitor and control remote access sessions.
- Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
- Route remote access via managed access control points.
These three requirements almost certainly involve the use of a VPN gateway to enable remote access to your systems. Even still, just using a VPN does not guarantee security. It must be configured in a way that keeps authorized users secure while keeping unauthorized users out. A well-configured VPN service will allow you to restrict access to authorized users, route VPN traffic via encrypted tunnels, and control what services VPN users may access. Additionally, logging is required to prevent data breaches and exfiltration. The requirements also extend to your wireless network.
- Authorize wireless access prior to allowing such connections.
- Protect wireless access using authentication and encryption.
Of course, this means that open Wi-Fi networks are right out. But even consumer-grade encryption, such as WPA2-PSK, is probably not secure enough to meet this standard. Enterprise-grade authentication and strong encryption should be used, for example by authenticating users and devices via a RADIUS service. And any Wi-Fi access provided to guests also needs to be secured and separated from your internal network.
The final set of security requirements that we’ll cover involves mobile devices, including laptops.
- Control connection of mobile devices.
- Encrypt CUI on mobile devices and mobile computing platforms.
- Verify and control/limit connections to and use of external systems.
- Limit use of portable storage devices on external systems.
If your mobile devices are connected to untrusted networks, then extra care must be taken to ensure that they remain secure. Additionally, a full disk encryption solution, such as BitLocker, is required. Several significant data breaches in recent years were caused by theft or loss of a laptop holding sensitive information, which would have been mitigated by a disk encryption solution.
The next two requirement families are Awareness and Training and Audit and Accountability. These two categories are less technical than the others we’ve discussed, but they are still vital to protecting your network against threats.
3.2 Awareness and Training
The basic security requirements for the Awareness and Training family are:
- Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.
- Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities
And these are condensed down into a single derived requirement:
- Provide security awareness training on recognizing and reporting potential indicators of insider threat.
These requirements leave plenty of leeway for you to craft your own strategy for security awareness and training for your users and employees. We’ve covered some security training basics before (such as detecting a phishing attempt and protecting yourself from cybercrime), and these techniques should be part of your security training program. This can include:
- Phishing awareness
- Internet security
- Email hygiene and safety
- Social engineering training
The security requirements also mention “insider threats.” While it’s generally not good business to be constantly suspicious of your own employees, caution is sometimes necessary. Your IT team in particular should be aware of users asking for access to information outside their job scope without good reason. Rights requests should be screened and properly approved before being granted. Generally, policies such as these will serve to keep the “honest people honest” and deter any potential insider threats.
Watch: What is a Replay-Resistant Authentication Mechanism?
NIST 800-171 and CMMC both mandate the use of “replay-resistant authentication mechanisms.” What exactly does that mean? Which authentication methods are replay-resistant? Find out (with a little help from Jason Bourne) in the video below:
3.3 Audit and Accountability
Basic Requirements
The basic requirements for the Audit and Accountability family are:
- Create and keep system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
- Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
There are several logging and auditing solutions that will meet this section’s requirements (for example, Graylog, Windows Event Forwarding, or Splunk). But the derived requirements for this family will help you design and implement a solution that complies with DFARS.
Derived Requirements
For example, one of the derived requirements is: “Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.” If all your systems’ clocks are out of sync, then the logs from those systems cannot easily be correlated in an intrusion.
Two other derived requirements help to reinforce the concept of role separation:
- Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
- Limit management of audit logging functionality to a subset of privileged users.
If your logging service can be changed by unauthorized users, then it is essentially worthless for a forensic investigation. So, while some users will need access to the logged data for various purposes, only a small group should be able to delete that information — and that action itself needs to be monitored and alarmed. That will help protect against both intruders and insider threats.
Get the DFARS guide as a PDF
Get our comprehensive DFARS checklist as a PDF. You’ll receive a clear, actionable 28-page summary of everything a small defense contractor needs to know about DFARs and NIST 800-171 compliance.
Don’t have time to read it now? Enter your email address (totally optional!) and we’ll send you a link so you can download it later or share it with your team.
3.4 Configuration Management
The fourth security family is Configuration Management. Configuration management is a set of practices that ensures that your systems and devices are configured correctly from the start, and that any changes made to their configuration does not affect the security of your systems. It’s a big topic — but even small enterprises can benefit from enacting configuration management principles before things grow to be more complex.
Basic Requirements
The two basic security requirements in this requirement family are:
- Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
- Establish and enforce security configuration settings for information technology products employed in organizational systems.
While these requirements may sound similar — and they are closely related — they emphasize two different sides to configuration management that are both important.
The first is the importance of having a configuration baseline for all devices and services on your network. This baseline should include things like minimum software version, basic configuration, and anything else that will allow for consistent configuration of devices on your network.
The second basic security requirement emphasizes the security aspect of configuration. All systems have settings that affect their security, and so special emphasis needs to be placed on that when designing your security baseline.
Derived Requirements
The derived requirements for this section highlight some important things to consider when designing a configuration management process. The first three involve change management processes. While the basic requirements highlight the importance of having a configuration baseline, that baseline will need to change over time as your system changes. Change management is the set of processes that will allow you to design and implement those changes successfully.
- Track, review, approve or disapprove, and log changes to organizational systems.
- Analyze the security impact of changes prior to implementation.
- Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
The first and most important requirement is simply to have a formal change management process. For smaller systems, this could be as simple as having the CIO and IT Director review all changes. For larger companies, this usually means a “change review board” or other formal committee that approves changes.
The second requirement is a reminder that security should be a main concern when reviewing changes. The requestor, technology owner, or subject matter expert should provide an in-depth explanation of the security risks and mitigations of any change, and the change review board should carefully consider this before approving a change.
Finally, changes should only be implemented by authorized individuals after they’re approved. This goes back to the principle of least privilege, mentioned in Part 1. But this principle needs to be built in to the design of your system from the beginning to ensure security and consistency.
Speaking of least privilege, a similar principle is highlighted in the next two requirements:
- Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
- Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
This means that just accepting the “defaults” isn’t good enough when it comes to securing vital systems. For example, by default, Windows has dozens of services enabled that may serve a function on a client OS, but on a server system, they simply increase the attack surface. These should be identified and disabled. Other network gear may come with management interfaces or other features exposed. These should likewise be evaluated and either secured properly or disabled. Additionally, firewalls on servers should be configured so that programs cannot accept inbound connections unless specifically allowed.
The final two security requirements involve software, particularly on workstations:
- Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
- Control and monitor user-installed software.
While these requirements can seem hard to manage, solutions like AppLocker can help you by whitelisting locations from which software may be run, and by checking security certificates for software in both authorized and unauthorized locations. Implementing these kinds of software restriction policies can help to reduce instances of malware and software licensing violations.
While configuration management is a broad set of topics, applying these security principles early on in your organization can help you to keep your systems secure and compliant.
3.5 Identification and Authentication
The next security requirement family is Identification and Authentication. This requirement family covers how we verify that the users and devices connected to our systems 1) are who they say they are, and 2) should have access to what they’re accessing.
Basic Requirements
There are two basic requirements in the Identification and Authentication family.
- Identify system users, processes acting on behalf of users, and devices.
- Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.
So, to successfully implement proper identification and authentication, both users and devices must be identified uniquely, and that identification must be properly verified before that user or device is allowed access to your network and systems. The Derived Requirements give us some more insight into how to do this.
Derived Requirements
The first of the derived security requirements mentions multifactor authentication (MFA):
- Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
Multifactor authentication includes “something you know”, like a password or PIN, and “something you have”, like a smartcard, token, soft token, or biometric information. The DOD uses the smartcard-based Common Access Card (CAC), but the requirements for DFARS say you are free to choose from other MFA solutions. Interestingly, the footnote for “network access” mentions that this includes access to systems over any network, including a local one. So even local workstations need to be protected with MFA in some way.
The next few requirements deal with the specifics of identifier security.
- Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
- Prevent reuse of identifiers for a defined period.
- Disable identifiers after a defined period of inactivity.
A “replay-resistant” authentication mechanism is one that prevents someone who is snooping on network traffic from being able to store authentication and re-use it later. Modern authentication mechanisms such as Kerberos are designed to resist replay attacks, but you will need to make sure that your systems cannot be tricked into “falling back” to a less-secure mechanism by an attacker. For more information, watch our video What is a Replay Resistant Authentication Mechanism? (Explained by Jason Bourne).
The next two requirements have more to do with administrative housekeeping, but there are technical means to enforce them. Reuse of an identifier means assigning the same identifier (e.g. a username) to a different individual. For example, imagine you have a user named Bob Smith with the username BSMITH, and he resigns. Then, the next week a new user named Barbara Smith joins your company. You would need to make sure that Barbara is not assigned Bill’s old username — she will need a unique username, unless a certain amount of time has passed since Bob left.
Secondly, you’ll need to make sure that unused identifiers are disabled after a period of time. For users, typically you would disable their account at the time they leave the company, but you’ll want to run regular checks to make sure that no one was overlooked (a common occurrence). Similarly, machine accounts for domain-joined computers should be disabled after a certain amount of inactive time if they’re not removed when the device is removed from service.
The last few security requirements for Identification and Authentication are specifically about passwords.
- Enforce a minimum password complexity and change of characters when new passwords are created.
- Prohibit password reuse for a specified number of generations.
- Allow temporary password use for system logons with an immediate change to a permanent password.
- Store and send only cryptographically protected passwords.
- Obscure feedback of authentication information.
Tools like password re-use prevention and temporary password enforcement are built in to Microsoft Active Directory (AD DS), so enabling these is as simple as configuring a group policy. AD DS also stores passwords with one-way hashing by default, but you still need to verify that insecure legacy protocols are disabled.
3.6 Incident Response
The next two security families, Incident Response and Maintenance, involve taking steps to make sure that the security infrastructure that you’ve put in place still is functional and responsive to new threats.
Basic and Derived Requirements
The Incident Response security requirement family has only two basic requirements and a single derived requirement:
- Basic: Set up an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
- Basic: Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization.
- Derived: Test the organizational incident response capability.
Good incident response begins with preparation — recognizing that security incidents can and will happen and having a plan to deal with them when they do. So having a thorough, written incident response plan is key. Additionally, you’ll need to figure out how and when that plan gets put into effect. Detections from antivirus systems, intrusion detection systems, and event log systems must be triaged and then followed up on if they present a real threat. Security incidents also need to be tracked — primarily internally, but also to outside authorities if the need arises. For example, your contract may specify that the DoD must be notified of certain incidents, so those details should be included in your incident response plan.
Finally, the derived requirement for this family mentions testing the response capability. This can include “fire drills” where the incident response plan is checked for accuracy, as well as disaster recovery scenarios where backups and recovery plans are tested and verified. This is also an opportunity to figure out the operation effects of various disaster scenarios.
3.7 Maintenance
Basic Requirements
The Maintenance security requirement family includes just two basic requirements.
- Perform maintenance on organizational systems.
- Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.
The first one is simple: just do it! But maintenance on complex IT systems is not a simple matter. There are dozens of “moving parts” in even the simplest systems, including software updates, firmware updates, and preventative maintenance on hardware components. So, setting up a set schedule for these procedures will minimize system downtime and security threats from unpatched vulnerabilities.
And since maintenance operations are by their nature sensitive — requiring high-level administrator access and having the potential to cause serious outages — the second basic requirement reminds us of the importance of both technical and procedural controls on these processes.
Derived Requirements
The derived requirements get into some more specifics on how to perform maintenance securely:
- Ensure equipment removed for off-site maintenance is sanitized of any CUI.
- Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems.
These two derived requirements remind us that even during maintenance, it’s important to be mindful of data flowing out and the potential for malware to flow in to your systems. And since diagnostic utilities are often run with privileged credentials, extra care must be taken to ensure they’re from a trusted source.
The final derived requirement in this family is an interesting one.
- Supervise the maintenance activities of maintenance personnel without required access authorization.
From time to time, it’s necessary for a vendor, consultant, or other individuals to access your systems to perform maintenance or diagnostics. Since these would fall outside of your organization’s authentication mechanisms, it’s important to supervise their work closely, whether it’s on-site or remote. For example, only use screen sharing software that you’ve approved, and observe any remote session from beginning to end to make sure that nothing untoward is happening.
With a good incident response plan and a regular maintenance program, you can keep your systems secure and compliant with DFARS.
3.8 Media Protection
The next three security families we’ll discuss are Media Protection, Personnel Security, and Physical Protection. These security families all relate to the concept of physical data protection. Even though our imaginations are captured by the idea of a hacker breaking into systems from the other side of the world, physical data loss is a much more common — but equally serious — security threat. Numerous breaches in the last few years have involved unsecured removable storage devices being stolen, or unsanitized media being sold or disposed of improperly. So, the requirements in these three families are just as important to implement to ensure a safe, compliant network.
Basic Requirements
There are three security requirements for the Media Protection family.
- Protect (i.e., physically control and securely store) system media containing CUI, both paper and digital.
- Limit access to CUI on system media to authorized users.
- Sanitize or destroy system media containing CUI before disposal or release for reuse.
System media here refers to both removable media and anything else that could contain CUI — backup tapes, hard drives, microfilm, decommissioned hard drives, etc. These devices need to be protected from unauthorized access, either physically or digitally, even at the end of their life.
Derived Requirements
The derived security requirements shed some more light on how to do this:
- Mark media with necessary CUI markings and distribution limitations.
- Control access to media containing CUI and maintain accountability for media during transport outside of controlled areas.
- Implement cryptographic mechanisms to protect the confidentiality of CUI stored on digital media during transport unless otherwise protected by alternative physical safeguards.
A clear process needs to be in place for handling and transporting media containing CUI in an unencrypted format, including logging and accountability. Of course, if the media is properly encrypted, then the requirements are less stringent. Either way, steps need to be taken to ensure that confidential information is protected in all formats.
There are also some system-level media safeguards that need to be put in place:
- Control the use of removable media on system components.
- Prohibit the use of portable storage devices when such devices have no identifiable owner.
- Protect the confidentiality of backup CUI at storage locations.
Take technical steps to prevent the use of unauthorized or unprotected media on workstations and servers. BitLocker now includes features that can disable the use of unencrypted removable storage devices on domain computers. Or, Group Policy can be used to prevent the use of any removable media on the operating system. These policies have the added benefit of reducing the spread of malware via removable media.
3.9 Personnel Security
The Personnel Security requirement family has just two basic requirements:
- Screen individuals prior to authorizing access to organizational systems containing CUI.
- Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.
While the first requirement mainly deals with company policy, the second has some technical impact for sysadmins.
In many companies, poor communication between HR and IT can result in delays between an employee leaving and her computer account being disabled. A clear organizational policy and good cooperation from both HR and IT can prevent such a scenario. For example, where should the request be sent? What information is needed? What “special handling” is needed for a more serious incident such as an immediate termination?
Having this down in writing will help ensure compliance with these requirements.
3.10 Physical Protection
Basic Requirements
Next, we’ll discuss the requirements of the Physical Protection family. There are two basic requirements:
- Limit physical access to organizational systems, equipment, and the respective operating environments to authorized individuals.
- Protect and monitor the physical facility and support infrastructure for organizational systems.
Whether you have a small telecom closet or a large datacenter, physical security is key to maintaining secure systems. If an intruder can get physical access to your systems, then just about any other security measures you’ve taken are moot. So physical access especially to data centers and infrastructure should be limited to only those who absolutely need access.
Derived Requirements
The derived requirements offer some important points for physical security:
- Escort visitors and monitor visitor activity.
- Maintain audit logs of physical access.
- Control and manage physical access devices.
- Enforce safeguarding measures for Controlled Unclassified Information (CUI) at alternate work sites.
Even those who have a need to access a datacenter should only do so when absolutely necessary, since most management tasks can and should be handled remotely. Logging and good physical access controls (i.e., locks) will help maintain physical security of your systems.
3.11 Risk Assessment
As both your systems and threats against those systems continue to evolve over time, you’ll need to implement routine checks to make sure that you’re still secure and in compliance with regulations. The next two security families will help you to do just that.
Basic Requirements
The Risk Assessment requirement family has one basic security requirement.
- Periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
This security requirement invites us to take a holistic approach to risk assessment. While it does specifically mention storing and processing CUI, it also mentions other security risks to the organization, including image and reputation. This reminds us that maintaining security is a broad business objective, not a narrow focus of the IT or security team.
Derived Requirements
Two derived requirements elaborate on how to handle risk assessments.
- Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
- Remediate vulnerabilities in accordance with risk assessments.
All systems, but particularly externally accessible systems, should be scanned for vulnerabilities routinely. This can be done by an outside auditor, or by an in-house security team. Tools such as Nessus and OpenVAS are useful for finding and cataloging potential exploit vectors on your network, but their results still require careful analysis to properly assess risk.
3.12 Security Assessment
While risk assessment involves the overall picture of organizational and system security, security assessment is focused on the nuts and bolts of security controls that mitigate the risks and secure your systems.
Basic Requirements
The four basic security requirements in this family are:
- Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
- Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
- Monitor ongoing security controls to ensure their continued effectiveness.
- Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
These assessments need to be periodic and continuous — it’s not a one-and-done thing. You need to evaluate existing controls for effectiveness and make improvements as new complexities are introduced to your systems.
The requirements also mention two key items that any DFARS-compliant system needs: A System Security Plan (SSP) and Plan of Action (POA). Essentially, the SSP explains exactly how you are going to secure your systems, and the POA says what steps you still need to take to get there. For example, do you need to implement a stronger MFA system for your VPN? That should go in your POA, including deliverables and deadlines. And as you continually assess the security of your system, both your SSP and POA will grow and evolve along with your security requirements.
3.13 System and Communications Protection
The next two security families are System and Communications Protection. These security requirements 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.
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, not an afterthought, in designing your network. The derived security requirements give us a better idea of how to implement some of these concepts in your network design.
Derived Requirement: Separation
The first three derived requirements emphasize the separation of network and system resources 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 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.
Derived Requirement: Permit by Exception
The next derived security requirement is for firewalls.
- Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, allow by exception).
Like LUA, deny-all, permit-by-exception firewall rules are the best way to ensure that only the devices and services you know can 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.
Derived Requirement: Cryptography
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 must 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 added security in the future.
Miscellaneous 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 these technologies are common in the consumer technology world, they require special consideration when deployed 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.) has 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.
3.14 System and Information Integrity
While you may have spent fantastic amounts of time and energy securing your systems, the requirements in this family remind us that security is an ongoing process, which requires constant monitoring and adjustment. Meeting the requirements of system and information integrity means that you’ll have implemented a process of continuous evaluation and improvement of your security posture.
Basic Requirements
The first basic requirement of this family is a crucial step for system administrators.
- Identify, report, and correct system flaws promptly.
- Monitor system security alerts and advisories and act in response.
“System flaws” most often take the form of vendor-reported security vulnerabilities. It’s important to monitor a system like the Common Vulnerabilities and Exposures database (CVE) for reports on the software, hardware, and systems that you support — and immediately take steps to patch or otherwise remediate any vulnerabilities as soon as possible.
Also, US government organizations, like US-CERT, publish security advisories that you will need to triage and act on.
- Provide protection from malicious code at designated locations within organizational systems.
Malware scanning isn’t only applicable to endpoints. Modern firewalls and IDS/IPSs can scan traffic in real time for signs of malicious code, as well as connections to known-hostile addresses. Plus, email and web traffic should be scanned for malicious code too, helping to head off any potential infections before they reach your clients or servers.
Derived Requirements
The derived security requirements mainly elaborate on the systems needed to protect your systems from malicious activity.
- Update malicious code protection mechanisms when new releases are available.
- Perform periodic scans of organizational systems and real-time scans of files from external sources as files are downloaded, opened, or executed.
- Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
- Identify unauthorized use of organizational systems.
The first two requirements — automatic definitions updates and scheduled and real-time virus scanning — can seem rather basic to most experienced administrators. But, it’s important to verify these mechanisms and make sure that they’re working as expected.
The next two requirements again deal with network logging and general log auditing. A variety of systems can be used for this purpose, but the point is to get them to deliver quality, actionable data that you can use to ensure that your systems are secure. A system that constantly gives false alerts will quickly be ignored, while a system that doesn’t alert when needed can be even worse.
How We Can Help You Reach Compliance
If you have any questions about how to achieve compliance, consider partnering with a trusted managed service provider (MSP) like E-N Computers. Our compliance consulting and fully managed IT services have helped hundreds of clients, including in the defense industry, to practice better security and enjoy more reliable infrastructure. Let our expert system administrators help you to build a secure, stable network that contributes to the success of your business. Contact us today to start working toward DFARS compliance.
Take the IT Maturity Assessment
Is your business ready to weather changes, including employee turnover? Find out by taking our IT maturity assessment.
You’ll get personalized action items that you can use to make improvements right away. Plus, you’ll have the opportunity to book a FREE IT strategy session to get even more insights into your IT needs.
