Data Pipeline for Generating Attack Graphs
To facilitate the development of these attack graphs, an automated and modular data pipeline was implemented (see Figure 7). This pipeline only requires that a user enter network scenario data at the start of the pipeline, although data can be modified or substituted at any point in between.
All of the components in the pipeline read and write data in XML format. The Attributes Extractor reads information related to a network scenario including attack, attacker position, routing protocol, traffic data, and route tables (which can be manually entered or extracted from emulation, simulation, or field data). For this scenario, data were obtained using CORE to configure the scenario. During scenario execution, and after routes converged, the required data were extracted and copied from each node. These data are used to generate attributes (attribute details are described in the Network Description Scheme section of this article). The Model Evaluator uses the attributes to query the WEKA decision tree rules (that are converted into python scripts by the Model Converter) in order to determine which flows are vulnerable (i.e., can be hijacked).
Figure 7 Modular data pipeline for generating attack graphs.
For each vulnerable flow identified, the AG Input Generator will append a vulExists entry (associated with OLSR) to the MulVAL input file. The AG Input Generator also uses the data from the Attributes Extractor to encode network scenario information in the MulVAL file.
Figure 8 shows a sample MulVAL input file generated in this way. The topology information (lines 2–13) is calculated by the Attributes Extractor using the route information from the CORE execution (in our case). The network scenario configuration (lines 17–26) is provided as input by the user.
Line 29 is generated using the results of the Model Evaluator.
Executing the pipeline with the route hijacking input file produces the attack graph shown in Figure 9. In this figure, rectangles are facts specified in the MulVAL input file; ovals are the rules (either the built-in or custom) that applied to derive new knowledge (diamonds). This graph shows that an attacker can successfully hijack traffic from the ftp client and use the sniffed credentials to execute code on the ftp server.
1 /* Network Topology Definitions:*/ 2 hacl(ftpClientHost, n2, _proto, _port). 3 hacl(n2, n3, _proto, _port). 4 hacl(n3, n4, _proto, _port). 5 hacl(n4, ftpServerHost, _proto, _port). 6 hacl(n6, n3, _proto, _port). 7 8 gateway(ftpClientHost). 9 gateway(n2). 10 gateway(n3). 11 gateway(n4). 12 gateway(ftpServerHost). 13 gateway(n6). 14 15 /* Flow Definitions: */ 16 /* Flow #1 :*/ 17 flowExists(ftpClientHost, ftpServerHost,’TCP’, 21, flow1Account). 18 hasAccount(flow1Principal, ftpServerHost, flow1Account). 19 networkServiceInfo(ftpClientHost, nrlolsr, olsr, _NA_port_layer3, _NA_perm_layer3). 20 21 /* Attack Configuration */ 22 attackerLocated(n6). 23 attackGoal(execCode(ftpServerHost, _)). 24 25 /* A cleartext loginService exists on the remote machine */ 26 networkServiceInfo(ftpServerHost, ftpd, ’TCP’, 21, flow1Account). 27 28 /* Vulnerable Flow */ 29 vulExists(ftpClientHost, nrlolsrVul, nrlolsr, remoteExploit, nrlolsrHijack).
Figure 8 MulVAL input file for Route Hijack Scenario
Figure 9 Attack graph for route hijacking scenario
In the short term, ARL is working on generating models for other routing protocols, such as BGP and RIP that exist in the wired domain. Other work is looking at the effects of multiple (possibly collaborating) attackers, and using metrics from the models, such as confidence, to prioritize and prune attack paths. Longer term efforts will focus on using this work to build decision support systems and intelligent agents for improved assessment time, coverage, and accuracy.