Vulnerability Assessment (VA) is a very simple concept to understand.
It is about identifying ‘potential methods’ which may be used by attackers to gain unauthorized entry to your network. The intention is also simple that you want to remedy or mitigate the vulnerabilities (once they become known to you), before they are found or exploited by attackers.
Vulnerability assessments are important, because they would produce the foundational elements of your security controls. VA requires you to do some proper planning, prioritizing, and reporting. Right?
All in all, A vulnerability assessment is a systematic review of ‘Security Weaknesses’ in your IT systems. It evaluates if your IT system, applications, or network are susceptible to any KNOWN vulnerabilities, assigns severity levels to those vulnerabilities, and recommends remediation or mitigation, if and whenever needed.
Vulnerability Assessment target areas.
1. Host assessment.
The assessment of critical servers, which may be vulnerable to attacks if not adequately tested or not generated from a tested machine image.
2. Network and wireless assessment
The assessment of policies and practices to prevent unauthorized access to private or public networks and network-accessible resources.
3. Database assessment
The assessment of databases or big data systems for vulnerabilities and misconfigurations, identifying rogue databases or insecure dev/test environments, and classifying sensitive data across an organization’s infrastructure.
4. Application scans
The identifying of security vulnerabilities in web applications and their source code by automated scans on the front-end or static/dynamic analysis of source code.
Better Way To Approach Vulnerability Assessments
A lot may depend upon your work or understanding which goes ‘before’ you hit the SCAN-button of your scanning software.
Your goal should be to fully understand the IMPORTANCE of devices on your network. You should understand that what is the RISK associated with each of those devices. In order to gage the respective risk, you need to ask some key questions, for example…
What is the role or importance of (this) device in key business-process(es)?
What degree of permissions its users need? Do they need elevated permissions or low-levels of permissions are sufficient?
Is this device accessible to internet? How is it getting its IP address?
How critical is the data that is stored or maintained on this device?
Whether the device is publicly accessible to anyone (such as a kiosk machine)?
There can be many more important factors for consideration here…
Once you are done with this part of exercise then you are ready to prioritize the next part(s) of VA. Now you can establish the right order for VA Scans. Trust me, a lot many info collected here would go as input when you would be doing ‘Business Impact’ Analysis (Risk Management).
Once you know all the ‘key devices’ or ‘Apps’ making your IT systems, then you should focus on identifying whether they are meeting security best practices in terms of their configurations. It would greatly help you in defining the BASELINE for each of those.
It means that you are closely looking at their OS, version, service packs/build, etc (if they are applicable). You are looking at what software are approved to be installed on those devices. You are looking at installed services and their required ports. You also want to know if there any undesirable ports which are left open. You would also dwell into if they need any special security configuration, for example.
This is something where your offensive mindset will hold all the keys. Ultimately, you want to discover all the weak-spots which your adversaries would want to exploit. You will be in a unique position to compare that against known-vulnerabilities and insecure configurations. You also will able to interpret the results of your scans properly. You may also want to know that whether all important LOGS are being sent in to your SIEM solution properly or not.
The above mentioned due-diligence performed well, you are now fully ready to execute the actual ‘Vulnerability Scanning’.
There are many solutions available to you for scanning, but each one provides you a bit of different context to the results. In general, vulnerability scans are performed either via unauthenticated or authenticated means.
1. Unauthenticated scan
In these scans, you access a system from the network perimeter, looking for open ports and testing for the use of exploits and attacks.
2. Authenticated scan
In these scans, you will perform a credentialed scan of the operating system and applications looking for misconfigurations and missing patches that can be taken advantage of by threat actors, such as weak passwords, application vulnerabilities and malware, etc.
We already know that many regulations such as PCI-DSS, HIPAA, GDPR etc mandate the regular Vulnerability Assessments/Scans. That’s why all the reports of these assessments must be properly documented and archived, for all times.
You MUST always generate and take print-outs of your results of VA. Because it will dictate what mitigation or remedies can be and have been applied. Your VA reports must be actionable. If they are not action-able, they are useless!
Reporting should include pertinent details that can be used to respond to found vulnerabilities, for example:
The date of discovery
Common Vulnerabilities and Exposure (CVE) database reference and score; those vulnerabilities found with a medium or high CVE score should be addressed immediately
A list of systems and devices found vulnerable
Detailed steps to correct the vulnerability, which can include patching and/or reconfiguration of operating systems or applications
Mitigation steps (like putting automatic OS updates in place) to keep the same type of issue from happening again
If you take the above mentioned approach to VA, then your organization will have a full understanding of their current security posture and what work is necessary to both fix the potential threat and to mitigate the same source of vulnerabilities in the future.
Vulnerability assessment cannot be a one-off activity. To be effective, you must operationalize this process and repeat it at regular intervals. It is also critical to foster cooperation between security, operation and development teams – a process known as DevSecOps.