An Ontology for Digital Forensics in IT Security Incidents - OPUS
An Ontology for Digital Forensics in IT Security Incidents - OPUS An Ontology for Digital Forensics in IT Security Incidents - OPUS
56 CHAPTER 7. IMPLEMENTATION 7.3 RDF The next step was to create the program that converts the output of the forensic tools that extract the information from the hard disk and random access memory images. Most forensic tools print their output to the standard output. The program, which is written in Java, asks for the location of the hard disk and memory images and the database to use and then runs the tools with the correct parameters. The output of the dierent tools is parsed and converted to RDF les that use the structures of the ontology. These RDF les are then stored in the selected database. The execution of the tools is partly parallelized to speed up the process. A screenshot of the program is shown in the appendix in listing C.4. The information about the tools that are used, the location of the database and other information that is needed to run the program is stored in a conguration le. An example for this le is shown in the appendix in listing A.1. The listing A.2 shows an example for the progress information printed by the program. One important point when lling the ontology is to add the data with references to the tools it way retrieved by. But if all values, timestamps and tools are added to an object, one cannot distinguish which timestamps and values belong to which tool. So blank nodes are put between the object and the corresponding value to eliminate this indistinguishability. For example, in gure 7.1 there is a registry key for which two tools found dierent values and the blank nodes _:blanknode* helping to separate these. 7.4 Volatility plugin: hivedump2 When implementing the extraction of the registry from the random access memory respectively the image of it, the rst solution was it to call the printkey function of volatility for each hive. The hive addresses can be located with the hivelist function. The output of the printkey function for one registry key looks similar to listing 7.1. Registry : \ Device \ HarddiskVolume1 \ WINDOWS \ system32 \ config \ SECURITY Key name : SECURITY (S) Last updated : 2012 -09 -20 10:33:58 Subkeys : (S) Policy (S) RXACT (V) SAM Values : Listing 7.1: Sample output of printkey If this function is executed with only the hive specied, it prints the root key of the hive. From this output one can extract the sub keys. For each of the sub keys the printkey function is called again. If this is done recursively,
7.4. VOLATILITY PLUGIN: HIVEDUMP2 57 reg:hasValue KEYKeyID _:blanknode0 rdf:value for:hasForensicTool for:hasTimestamp VALNodeID Tool0 214356798 reg:key reg:value reg:type reg:key reg:value reg:type _:blanknode1 _:blanknode3 _:blanknode5 _:blanknode2 _:blanknode4 _:blanknode6 rdf:value for:hasTimestamp for:hasForensicTool for:hasTimestamp for:hasTimestamp for:hasForensicTool rdf:value for:hasForensicTool rdf:value rdf:value for:hasTimestamp for:hasForensicTool for:hasTimestamp for:hasTimestamp for:hasForensicTool rdf:value for:hasForensicTool rdf:value EnableFirewall 123456798 Tool1 0 DWORD EnableFirewall 132457689 Tool2 1 DWORD Figure 7.1: Blank node
- Page 8 and 9: 6 CONTENTS
- Page 10 and 11: 8 CHAPTER 1. INTRODUCTION data lead
- Page 12 and 13: 10 CHAPTER 2. RELATED WORK investig
- Page 14 and 15: 12 CHAPTER 3. GOAL FORENSIC SEMANTI
- Page 16 and 17: 14 CHAPTER 3. GOAL FORENSIC SEMANTI
- Page 18 and 19: 16 CHAPTER 4. FORENSICS Basic rules
- Page 20 and 21: 18 CHAPTER 4. FORENSICS 4.1.2.2 Ran
- Page 22 and 23: 20 CHAPTER 4. FORENSICS entry conta
- Page 24 and 25: 22 CHAPTER 4. FORENSICS 4.2.3.1 Reg
- Page 26 and 27: 24 CHAPTER 4. FORENSICS vulnerable
- Page 28 and 29: 26 CHAPTER 4. FORENSICS The fls -m
- Page 30 and 31: 28 CHAPTER 4. FORENSICS of the sock
- Page 32 and 33: 30 CHAPTER 4. FORENSICS
- Page 34 and 35: 32 CHAPTER 5. ONTOLOGY Person name
- Page 36 and 37: 34 CHAPTER 5. ONTOLOGY 5.1.1 Creati
- Page 38 and 39: 36 CHAPTER 5. ONTOLOGY Resource Des
- Page 40 and 41: 38 CHAPTER 5. ONTOLOGY to be Augsbu
- Page 42 and 43: 40 CHAPTER 5. ONTOLOGY Gephi and Cy
- Page 44 and 45: 42 CHAPTER 5. ONTOLOGY
- Page 46 and 47: 44 CHAPTER 6. FORENSIC ONTOLOGY for
- Page 48 and 49: 46 CHAPTER 6. FORENSIC ONTOLOGY pro
- Page 50 and 51: 48 CHAPTER 6. FORENSIC ONTOLOGY reg
- Page 52 and 53: 50 CHAPTER 6. FORENSIC ONTOLOGY 6.9
- Page 54 and 55: 52 CHAPTER 6. FORENSIC ONTOLOGY Par
- Page 56 and 57: 54 CHAPTER 6. FORENSIC ONTOLOGY
- Page 60 and 61: 58 CHAPTER 7. IMPLEMENTATION the co
- Page 62 and 63: 60 CHAPTER 7. IMPLEMENTATION 1 SELE
- Page 64 and 65: 62 CHAPTER 7. IMPLEMENTATION Anothe
- Page 66 and 67: 64 CHAPTER 7. IMPLEMENTATION 7.8 St
- Page 68 and 69: 66 CHAPTER 8. EVALUATION 6. The las
- Page 70 and 71: 68 CHAPTER 8. EVALUATION key (CTEMO
- Page 72 and 73: 70 CHAPTER 9. SUMMARY after some is
- Page 74 and 75: 72 APPENDIX A. EXTRACTION TOOL LIST
- Page 76 and 77: 74 APPENDIX A. EXTRACTION TOOL LIST
- Page 78 and 79: 76 APPENDIX B. FORENSIC TOOLS OUTPU
- Page 80 and 81: 78 APPENDIX C. SCREENSHOTS Figure C
- Page 82 and 83: 80 APPENDIX C. SCREENSHOTS Figure C
- Page 84 and 85: 82 APPENDIX C. SCREENSHOTS Figure C
- Page 86 and 87: 84 APPENDIX C. SCREENSHOTS
- Page 88 and 89: 86 BIBLIOGRAPHY [Carrier, 2012c] Ca
- Page 90 and 91: 88 BIBLIOGRAPHY [Microsoft, 2010] M
- Page 92: 90 BIBLIOGRAPHY [W3C, 2004] W3C (20
56 CHAPTER 7. IMPLEMENTATION<br />
7.3 RDF<br />
The next step was to create the program that converts the output of the<br />
<strong>for</strong>ensic tools that extract the <strong>in</strong><strong>for</strong>mation from the hard disk and random<br />
access memory images. Most <strong>for</strong>ensic tools pr<strong>in</strong>t their output to the standard<br />
output. The program, which is written <strong>in</strong> Java, asks <strong>for</strong> the location of the<br />
hard disk and memory images and the database to use and then runs the<br />
tools with the correct parameters. The output of the dierent tools is parsed<br />
and converted to RDF les that use the structures of the ontology. These<br />
RDF les are then stored <strong>in</strong> the selected database. The execution of the tools<br />
is partly parallelized to speed up the process. A screenshot of the program is<br />
shown <strong>in</strong> the appendix <strong>in</strong> list<strong>in</strong>g C.4. The <strong>in</strong><strong>for</strong>mation about the tools that<br />
are used, the location of the database and other <strong>in</strong><strong>for</strong>mation that is needed<br />
to run the program is stored <strong>in</strong> a conguration le. <strong>An</strong> example <strong>for</strong> this le<br />
is shown <strong>in</strong> the appendix <strong>in</strong> list<strong>in</strong>g A.1. The list<strong>in</strong>g A.2 shows an example<br />
<strong>for</strong> the progress <strong>in</strong><strong>for</strong>mation pr<strong>in</strong>ted by the program.<br />
One important po<strong>in</strong>t when ll<strong>in</strong>g the ontology is to add the data with<br />
references to the tools it way retrieved by. But if all values, timestamps and<br />
tools are added to an object, one cannot dist<strong>in</strong>guish which timestamps and<br />
values belong to which tool. So blank nodes are put between the object and<br />
the correspond<strong>in</strong>g value to elim<strong>in</strong>ate this <strong>in</strong>dist<strong>in</strong>guishability. For example,<br />
<strong>in</strong> gure 7.1 there is a registry key <strong>for</strong> which two tools found dierent values<br />
and the blank nodes _:blanknode* help<strong>in</strong>g to separate these.<br />
7.4 Volatility plug<strong>in</strong>: hivedump2<br />
When implement<strong>in</strong>g the extraction of the registry from the random access<br />
memory respectively the image of it, the rst solution was it to call the<br />
pr<strong>in</strong>tkey function of volatility <strong>for</strong> each hive. The hive addresses can be<br />
located with the hivelist function. The output of the pr<strong>in</strong>tkey function <strong>for</strong><br />
one registry key looks similar to list<strong>in</strong>g 7.1.<br />
Registry : \ Device \ HarddiskVolume1 \ WINDOWS \ system32 \ config \ SECUR<strong>IT</strong>Y<br />
Key name : SECUR<strong>IT</strong>Y (S)<br />
Last updated : 2012 -09 -20 10:33:58<br />
Subkeys :<br />
(S) Policy<br />
(S) RXACT<br />
(V) SAM<br />
Values :<br />
List<strong>in</strong>g 7.1: Sample output of pr<strong>in</strong>tkey<br />
If this function is executed with only the hive specied, it pr<strong>in</strong>ts the root<br />
key of the hive. From this output one can extract the sub keys. For each of<br />
the sub keys the pr<strong>in</strong>tkey function is called aga<strong>in</strong>. If this is done recursively,