Archive | Uncategorized RSS feed for this section

Closing Open Doors by Bringing Vulnerabilities to Resolution – Six Essential Questions

New vulnerabilities are discovered every day,Vulnerabilities and they are an intruders’ best friend. It’s a bit like a burglar finding the door
unlocked and wide open; he’s going to have a really easy day at work and you’ll be wondering for a long time why you left it open.

Therefore, it is absolutely critical to resolve them as soon as possible before they are exploited.

A vulnerability report can be a bit daunting though, especially for a complex solution which relies on many different technologies.  Over the years, I‘ve found that asking these six questions can help bring even the most obscure vulnerability to resolution.

Question #1: Can I remove/upgrade the vulnerable software?
Many times we find a solution is installed with supporting software components that may no longer be required. If this is the case, the easiest way to resolve the vulnerability is to completely remove that component. Best of all, once removed, you no longer have to worr
y about new vulnerabilities presenting themselves in the future for this piece of software.

There are also times that version upgrades may be available for these software components. Upgrading those components to the latest version not only resolves the vulnerability, but also ensures you are working with the latest and fully supported version of that software.

Question #2: Would a configuration change resolve this vulnerability?
Some vulnerability’s cannot be patched, and can only be corrected with a configuration change to the system.

A good example of this is SSL 3.0, an encryption standard used by many web services that has recently been found to be insecure. Changing the configuration of the web service to use TLS 1.2 not only resolves the vulnerability, but also brings the solution in to compliance with PCI and other security standards.

Question #3: Can a security patch be applied?
If the affected software is still supported by the developer, a security patch may be required. If this is the case, submit a request to have the patch installed after testing it thoroughly with your solution.

Question #4: Is the supporting data accurate?
Vulnerability scanners are not perfect, and false positives are a real possibility. Fortunately, the vulnerability report will contain supporting data that was used to determine the presence of a vulnerability. If you suspect a false positive, validate it by performing a manual inspection to invalidate the results the vulnerability scanner provided. If you confirm that it is indeed a false positive, submit evidence to your vulnerability management team to have the finding removed from the report.

Question #5: Can the vulnerability be mitigated?
If the software is current, and the developer does not have an expected release date for a security patch, an alternative method may be required to bring this vulnerability to resolution. This may involve firewall rules to restrict access, or the disablement of non-essential services that would be required for an attacker to take advantage of the vulnerability. Once mitigated, submit evidence of the mitigation to your vulnerability management team to have the finding removed from the report.

Question #6: Is an exception warranted?
There are rare circumstances where a vulnerability must be accepted.  It may be a business process that relies on an end-of-life solution, or the vendor is unable/unwilling to supply a security patch. Whatever the case, when a vulnerability must be accepted it is essential to raise awareness through your vulnerability governance processes. The appropriate security teams can then work to determine what other defenses could be leveraged in to limit exposure. This may involve segmenting the solution from the rest of the network or increasing the visibility of anomalous activity on the solution.

Advertisements