Referential Integrity When Performing a Vulnerability Assessment

James Thurber wrote back in 1959, “When all things are equal, translucence in writing is more effective than transparency, just as glow is more revealing than glare.” The critical aspect of his statement is based on equality. When using multiple distributed applications, regardless of technology, having the same version on all the systems is sometimes very critical to making sure the desired results are achieved. When using applications for security, like an antivirus product, making sure all of the signatures are up to date and running the same version is critical for protecting assets. If some signature versions are older, and not in sync, those systems may miss critical malware that could infect these devices. This problem is an “old school discussion” that everyone managing endpoint antivirus solutions is aware of and they have many tools in their arsenal to solve this problem. Other technologies used for security are unfortunately not so mature. Let us consider a vulnerability management solution. Audit updates for these solutions are released almost as frequently as an antivirus solution. These audits add, remove, and update vulnerability signatures to check for the latest vulnerabilities across the entire environment and potentially interact with every device plugged into the network. If you use a signature database that is too old (arguably older than one week) you are potentially missing critical threats that could jeopardize your business. Compliance mandates indicate that crucial vulnerabilities should be remediated within 30 days so any audit database older than one month is definitely too old. Let us now consider a vulnerability management solution that uses multiple distributed scanners. If the scanners are using old or different versions of audit databases, the results will be skewed and not contain an equal perspective of vulnerabilities across the enterprise. The results are ultimately stored in a database and reported on and will only be partially accurate. Unfortunately, based on the different audit databases used to assess these results, you end up with a referential integrity problem with the data. This effects your short term remediation reports and your long term historical reporting and your regulatory compliance monitoring initiatives. Consider a vulnerability report that would cover two locations using two different physical vulnerability assessment scanners from the same vendor. One scanner was updated at the beginning of the month and the other a mere two weeks later. One database would contain the latest Patch Tuesday Audits from Microsoft and the other would not. Even though the scans were run at the same time, the report would show vulnerabilities exist in one environment and not the other. This could lead to false conclusions that patching of those vulnerabilities occurred in one location and not in the other. This is obviously not correct since the vulnerabilities are not in the audit database and therefore not assessed. This then causes the security team to incorrectly focus resources on one location and not properly allocate any for the other. Management ultimately gets a skewed historical report and the equality of the data is not as transparent as it should be. In order to solve this problem, vulnerability assessments that are scheduled to run near simultaneously, or per job, need use the same audit database in order ensure the reports are concise and do not contain any referential integrity errors. For eEye Solutions, we offer a solution for this type of problem. eEye provides the Enterprise Update Server as a software solution and embedded on our appliances. This solution provides full change control management for downloading and distributing eEye updates to maintain the audit databases across the enterprise for distributed for scanners regardless if they are local agents or networks scanners. This allows us to ensure that all of the scanners are automatically or manually (change control) updated to the same (or latest) versions and send the appropriate alerts when updates are available. In addition, eEye’s management console, Retina CS, allows detailed reporting and drill down compatibilities to a remote scanners version in order verify the current state, is the desired state. While this problem may not necessarily be a problem for users of only one scanner. It is just as important for them if they update the solution in between jobs that are used to produce a single and final report for a snapshot in time. Half the job would run with one audit database version, and the other with a newer (potentially critical) difference. So when performing vulnerability assessment, consider not only the age of the vulnerability database you are using, but when you apply updates and if those updates are properly distributed to your remote scanners. Differences in the audit databases can lead to false negatives that can mis-prioritize your remediation efforts.