Misconfigurations and components with known vulnerabilities have been a persistent issue for organizations over the last couple of years. They’ve even achieved a respectable place 6 and 9 in the OWASP top 10. The list summarizes the most critical vulnerabilities to applications. The most common types of misconfigurations include:
- Unpatched systems and applications
- Poorly configured network devices
- Default account credentials (usernames and passwords)
- Unprotected files and directories
The majority of cyber-attacks targets these known and fixable vulnerabilities. These can happen because of underqualified staff or limiting procedures. If a system administrator does not understand the importance of changing a default password or patching a critical vulnerability, you’re at major risk. The big question is how is this still possible?
We think vulnerability management starts by selecting proper staff and partners to validate configurations according to best practice policies on continuous basis.
Vulnerability management tools
Who checks the checker? In this case we use vulnerability management tools to make sure we’re not missing anything. Because, if we are, we want to be informed what’s wrong and how we should fix it – ofcourse with as much automation as possible. The most common vulnerability scanners are Nessus, Nexpose and Qualys. OpenVAS is a great open source alternative, but has its limitations for the enterprise.
So, what else is important in vulnerability management.
You should use tools that looks for both code-based and configuration-based vulnerabilities across the network. This is our double check that should verify our (lack of) patching management and human errors in configurations. These should be automated and authenticated scans with dedicated accounts. You don’t want to use an administrator or user account for this – your audit logs would go crazy! Third party intel like software update, patch information, security advisories and threat bulletins should be integrated in vulnerability management.
Prioritize the risks
Use a risk-rating process to prioritize the discovered vulnerabilities and categorize them using de facto standards like Common Vulnerabilities and Exposures (CVE) and Open Vulnerability and Assessment Language (OVAL). Combine this with an internal service level agreement (SLA) based on severity and time needed to patch the bug. If the documented time was exceeded, security should work with management to improve the patching process. Prioritizing the risks tells us what could be high impact and must be resolved first.
Automate patch management
We don’t know when the next vulnerability will be discovered. How can we schedule testing and implementing the fix? To be honest, we can’t. That is why we should mitigate the discovered vulnerabilities automatically. In a perfect scenario we would like to do the following:
- Detect a vulnerability using a scheduled vulnerability scanner
- Report this to your patch management solution
- Deploy the patch automatically in your test or production environment
- Run a back-to-back scan to validate the vulnerability has been fixed
Depending on your internal procedures of implementing patches, we can automate this almost completely. Together we can finally get these notations out of the OWASP top 10!