Vulnerability Scanning - A must
Intro
* A short overview of the elements you need to consider when implementing a Vulnerability Scan solution.
* What are some common pitfalls when implementing a Vulnerability Scanner
Best practices for implementing an automated Vulnerability Scanner
______
Preparation
Implementing a Vulnerability Scanner requires much preparation. You must ensure a clearly defined scope of what you want to scan.
A starting point here is your organization's CMDB (that hopefully is up to date).
Once you have a good overview of the systems within the scope, you can start to investigate WHAT you want to scan for.
To give you a head start, here are some often used Scanning rules:
- [ ] Vulnerabilities related to the vendor. (Known Vulnerabilities in specific solutions are often published in CVE's)
- [ ] Vulnerabilities by default settings (don't ask me the number of times that I came across servers, switches, and firewalls that still had default admin accounts or management ports)
- [ ] Software features: Some features pose more risks than others. For example, you can have a system that, by default, is reporting everything over SNMPv1, which gives a malicious actor a lot of information on the system he is trying to breach. A similar one is NETBIOS which is exposed to the internet port.
- [ ] Misconfigurations: For instance, folders from a web application that have incorrect access rights and are accessible with read and write capabilities.
Decide on the way that you will scan.
- Including discovery scans and discovering new hosts or services on the network.
- Do unauthenticated scans of your environment, like a malicious hacker would do when trying to find a Vulnerability to exploit.
- Also, perform authenticated scans. Because a malicious actor maybe already has credentials and a foothold within your organization.
Decide on when is the best time to perform the scans. When is the impact on the environment less? It is not wise to perform a full-blown scan on the HR server when they close the month and need to run all paychecks.
Also, decide which systems should be excluded on a particular scan or each scan.
Should you have web applications, Include them in your scan or run specialized solutions to scan for vulnerabilities or programmatic issues in your web applications.
Plan for the placement of the scanning solution. Depending on the model and sort of Vulnerability scanning solution, it can be on-premise or cloud-based.
Vulnerability Scans are most effective when on-prem and not hindered by Firewalls or other security solutions. Cloud-based gives a better view of Vulnerabilities from the standpoint of an outside malicious hacker. Both have their pros and cons.
Implementation
When implementing, make sure to check the system requirements for the Vulnerability Scanner of your choice.
Vulnerability scanners are resource-hungry machines, as a lot is happening in the back end. (Often, we need more than 28 cores and 64GB of memory)
So it is not something that you throw as an extra virtual appliance on a virtual environment that is already challenged for its resources.
In general, you also need to have two NICs (Network Interface Cards). One for out-of-band management of the scanner and one to perform the actual scanning and capturing.
For organizations with dispersed environments, with Datacenters to host their central IT infrastructure, or with public cloud (Azure, Aws, ...) as their prime infrastructure. A central management hub with dispersed scanning nodes can be the way to go. Again, don't underestimate the number of connections that intense scanning can create. Even if the "pipe" is wide enough, meaning that you have enough bandwidth, the number of new connections may impact the performance. So having your nodes close to the environment you wish to scan is something to consider.
Maintaining
According to an article in [SecurityWeek](https://www.securityweek.com/over-28000-vulnerabilities-disclosed-2021-report), there were a staggering 28695 Vulnerabilities disclosed in 2021. So by the time you download a Vulnerability scanner and have it installed, the Vulnerability database is out of date.
Make sure that you keep your Vulnerability Scanner up to date with the latest definitions.
Your IT department should also keep an eye out if there are any major vulnerabilities that are published that could be relevant.
Some good sources for CVEs:
- https://cve.mitre.org/cve/
- https://www.cvedetails.com/vulnerability-list/
- https://www.cve.org
- https://openliberty.io/docs/latest/security-vulnerabilities.html
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Vulnerability scanners
Here are some links to the most recognized vulnerability scanners:
- https://www.tenable.com/products
- https://www.rapid7.com/products/nexpose/
- https://www.openvas.org
- https://www.qualys.com/apps/vulnerability-management-detection-response/
Pitfalls when implementing a Vulnerability Scanning solution
Incomplete Scope / Incorrect CMDB
One of the first pitfalls is that the CMDB (Configuration Management Database) is out of date or that not all systems are included within the CMDB. When your CMDB is incomplete, you will miss systems in your vulnerability scan and undoubtedly also in your update and patch management.
When performing Vulnerability scanning, ensure that your scope is complete and no systems are left out.
Except should there be systems that are critical and react badly to scanning that is done? Those systems require a more manual investigation and approach.
Be sure to add those systems to an exclusion list for scanning.
Scans that are too restricted or limited
Do not limit the scans to only the primary services that are running, but include all system services. Often, when an organization is breached, malicious actors enable certain services with known vulnerabilities to gain an extra path into the organization.
When you aren't scanning for these services, you will miss them should they get reactivated. If they are reactivated, this is a perfect IoC (Indicator of Compromise)
Also, do not restrict the scans to the servers alone. Other systems can also contain vulnerabilities and a path into your organization. When using containers, VM's our Cloud solutions, don't forget to include those in Scope. Sometimes it can be a simple misconfiguration than can be a Vulnerability.
Scanning without mitigating
Just performing scans without investigating the results is like buying a book to put it on a shelf. There is no use.
Especially at first, the results of those scans can be intimidating. Still, if you don't analyze and plan to mitigate, you miss the opportunity to improve your organization's security posture.
When Vulnerabilities are discovered, what are your actions? Do you just plug the hole, so the system isn't reachable through that means, or do you do an actual root cause analysis and "grab the bull by the horns". Just patching holes in your defenses doesn't really solve the problem, and the security issue remains.
When you plan for mitigating measures, do you analyze the criticality and likelihood of an incident occurring? In other words, do you put your efforts where they are meaningful, or do you choose the low-hanging fruits and the easiest to solve vulnerabilities first?
Too many scans or too little scans
Both too many and too little can be pitfalls. If your scans are too far apart, you could miss vulnerabilities or take too long to discover them. On the other hand, If you run scans continuously, you risk an overload of information, and vulnerabilities get lost or overseen.
You should test and strive for a frequency of scans that is sustainable for your team and gives a good balance between risk mitigation and exposure.
Mismanaged exceptions
Does your Vulnerability scanner have a long list of exceptions? Are you sure those exceptions are justified and do you have other means to verify for Vulnerabilities in those systems? If not, they are just a way to ignore potential vulnerabilities in your environment. When you create exceptions for specific systems, you should put a date on them to review if the exception is still required, or you can include it in the following scan.
Managing privileges for your Vulnerability Scanner
Many IDS solutions and Firewalls will treat scans as "malicious" and block the scan at the gateway. This can give you a false scan result and a false sense of security. Your Vulnerability Scanner should have access to your environment as if it were an internal system. Only this way can you trust the scan results.
Take into account that it can be another system that is breached in your network that does the scanning., In that case, your security controls at the gate have no use.
Scanning bandwidth consumption
Vulnerability Scans consume bandwidth and, even more, have a high connection rate per second. Take this into account for your connectivity. Is it going to impact other processes? Do you need to toggle the bandwidth? Is there enough bandwidth left to perform the scans for your environment, or should you use an out-of-band solution? It is the same scenario as with off-site backup policies. If you are trying to take a full daily backup of any data, your connectivity cannot transfer that much data in one night. You have no backup as it is incomplete when the next cycle commences.
Conclusion
So as you see, there are quite some things to consider when implementing a Vulnerability Scanner, but I think we can all agree that without it, it no longer is an option.
The number of different systems that we use daily and maintaining these systems has become too complex to manually do all the manual scanning, which in turn causes "Cyberfatigue."