Explaining change : Comparing network snapshots for vulnerability management

Abstract: Background. Vulnerability management makes it easier for companies to find, manage and patch vulnerabilities in a network. This is done by scanning the network for known vulnerabilities. The amount of information collected during the scans can be large and prolong the analysis process of the findings. When presenting the result of found vulnerabilities it is usually represented as a trend of number of found vulnerabilities over time. The trends do not explain the cause of change in found vulnerabilities.  Objectives. The objective of this thesis is to investigate how to explain the cause of change in found vulnerabilities, by comparing vulnerability scanning reports from different points in time. Another objective of this thesis is to create an automated system that connects changes in vulnerabilities to specific events in the network. Methods. A case study was conducted where three reports, from vulnerability scans of Outpost24's internal test network, were examined in order to understand the structure of the reports and mapping them to events. To complement the case study, an additional simulated test network was set up in order to conduct self defined tests and obtain higher accuracy when identifying the cause of change in found vulnerabilities. Results. The observations done in the case study provided us with information on how to parse the data and how to identify the cause of change with a rule-based system. Interpretation of the data was done and the changes were grouped into three categories; added, removed or modified. After conducting the test cases, the results were then interpreted to find signatures in order to identify the cause of change in vulnerabilities. These signatures were then made into rules, implemented into a proof-of-concept tool. The proof of concept tool compared scan reports in pairs in order to find differences. These differences were then matched with the rules and if it did not match any rule, the change in the report was flagged as an ''unexplained'' change. The proof-of-concept tool was then used to investigate the cause of change between the reports from the case study. The framework was validated by evaluating the rules gathered from the simulated test network on the data from the case study. Furthermore, a domain expert verified that the identified causes were accurate by manually comparing the vulnerability reports from the case study. Conclusions. It is possible to identify the cause of change in found vulnerabilities from vulnerability scan reports by constructing signatures for events and use these signatures as rules. This can also be implemented automatically, as a software, in order to identify the cause of change faster than manual labor.