Vulnerability Scanning Requirements for NIST SP 800-171

3.11.2 Scan for vulnerabilities in the information system and applications periodically and when new vulnerabilities affecting the system are identified.

According to the NIST glossary, vulnerability scanning is “a technique used to identify hosts/host attributes and associated vulnerabilities.” Vulnerability scans are important for your organization’s security because they allow you to identify vulnerabilities on your systems so that you can remediate them before a threat actor exploits them.

You scan for vulnerabilities using a vulnerability scanner. The most well known vulnerability scanner is called Nessus. It can be used to scan everything from network devices, servers, applications, and workstations. It provides useful scanning reports that list the identified vulnerabilities, their associated remediation, and how critical each vulnerability is.

If you are looking to save some money, nmap (free tool) can be used as a vulnerability scanner, nikto and OWASP zap (free tool) can be used to scan web applications.

The frequency at which you scan for vulnerabilities should be dictated by your risk assessment. Some organizations may choose to scan for vulnerabilities weekly on their public facing systems, and monthly for internal systems. Other organizations may perform vulnerability scans at another frequency. NIST SP 800-171 requirements do not specify a frequency, it is up to your organization to set one.

If you become aware of new vulnerabilities affecting your systems and application (for example via a vendor newsletter), you should perform a vulnerability scan as soon as possible to determine if your systems are affected.

Once you identify vulnerabilities on your systems and applications you should document them in your plan of action and milestones document. Assign a person who is responsible for remediating the vulnerability, describe how you plan to remediate it, and set a date by which the vulnerability shall be remediated. In some cases you may have to accept a vulnerability. For example you may have an application that is critical to your business operations but the application uses an outdated version of TLS, in this case you may have to accept the risk associated with this vulnerability until you can replace the application.