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. / Bakgrund. Sårbarhetshantering underlättar arbetet för företag att hitta, hantera och korrigera sårbarheter i ett nätverk. Det görs genom att skanna nätverket efter kända sårbarheter. Mängden information som samlas under skanningar kan vara stor och medföra till att analysprocessen av upptäckterna försenas. Resultaten av de upptäckta sårbarheterna brukar vanligtvis presenteras som en trend av antalet funna sårbarheter över ett tidsintervall. Trenderna förklarar dock inte andledningen till de funna sårbarheterna. Syfte. Målet med denna avhandling är att undersöka hur det är möjligt att identifiera anledningen till skillnaden i funna sårbarheter genom att jämföra sårbarhetsrapporter från olika tidpunkter. Ett andra mål är att utveckla ett automatiskt system som kopplar skillnaderna i funna sårbarheter till specifika händelser i nätverket. Metod. En fallstudie utfördes där tre sårbarhetsrapporter, från Outpost24s interna testnätverk, undersöktes för att få förståelse kring strukturen av rapporterna samt för att koppla upptäckter i rapporterna till händelser. För att komplementera fallstudien satte vi upp ett nytt, simulerat testnätverk för att kunna utföra egna tester samt för att uppnå en högre precision vid identifiering av förändringar. Resultat. Utifrån fallstudien fick vi förståelse för hur vi skulle tolka informationen från rapporterna samt för hur man kan ge orsak till förändring genom ett regelbaserad system. Informationen från rapporterna tolkades och förändringarna delades in i tre olika kategorier; tillagda, borttagna eller modifierade. Utifrån testerna från det simulerade nätverket byggdes signaturer som identifierar orsak till föränding av funna sårbarheter. Signaturerna användes sedan för att göra regler, vilka implementerades i ett konceptverktyg. Konceptverktyget jämförde sårbarhetsrapporter i par för att upptäcka skillnader. De identifierade skillnaderna försökte sedan matchas ihop med reglerna och skulle skillnaden inte matcha någon regel så flaggas skillnaden som ''oförklarad''. Konceptverktyget användes slutligen för att finna orsak till förändringar i rapporterna från fallstudien. Ramverket validerates genom att utvärdera hur reglerna byggda utifrån det simulerade nätverket presterade för fallstudien. En domänexpert verifierade att händelserna som presenterades och orsaken till förändringarna var korrekta genom att analysera sårbarhetsrapporterna från fallstudien manuellt. Slutsatser. Det är möjligt att identifiera orsak till förändringar i upptäckta sårbarheter i sårbarhetsrapporter genom att identifiera signaturer för händelser, och använda dessa signaturer i ett reglerbaserat system. Systemet är också möjligt att implementera automatiskt, i form av mjukvara, för att kunna identifiera orsaken till förändring snabbare än om det skulle gjorts manuellt.
| Identifer | oai:union.ndltd.org:UPSALLA1/oai:DiVA.org:bth-16710 |
| Date | January 2018 |
| Creators | Persson, Andreas, Landenstad, Lukas |
| Publisher | Blekinge Tekniska Högskola, Institutionen för datalogi och datorsystemteknik, Blekinge Tekniska Högskola, Institutionen för datalogi och datorsystemteknik |
| Source Sets | DiVA Archive at Upsalla University |
| Language | English |
| Detected Language | Swedish |
| Type | Student thesis, info:eu-repo/semantics/bachelorThesis, text |
| Format | application/pdf |
| Rights | info:eu-repo/semantics/openAccess |
Page generated in 0.0026 seconds