Lab 3 - Vulnerability Analysis and Attack Graphs

Attack graphs allow an administrator to see not just the vulnerability analysis for a single system but for a composition of systems across the network. Not all attack graph projects use vulnerability analysis however. Some projects iterate through known exploits (similar to what Nessus does) rather than consider classes of vulnerabilities with similar exploit structures. On the flip side of the coin, some vulnerability analysis projects are essentially computing exploit paths, but do not call them attack graphs. The first UC Davis project, http://isis.cs.ucdavis.edu/vuln/, has many features of attack graphs, but does not consider itself an attack graph project for example. They instead call their work "characteristic trees".

One feature of that VA project and of my work is the use of preconditions and postconditions to define the nature of an attack or vulnerability. This derives from an earlier work at UC Davis called A Requires/Provides Model for Computer Attacks. The nickname for the requires/provides project was Jigsaw, so that term may be seen in the documentation too. The basic idea is that every attack has certain conditions that must be met before it can execute, such as the presence of a vulnerability. This set of conditions are the preconditions. The second part of the basic idea is every attack has some consequence, such as giving the attacker root on a system. The set of consequences are the postconditions. The final part of the basic idea is that some consequences are actually preconditions for other attacks. So you can build an attack dependency graph by chaining consequences of one attack to preconditions of another attack.

Attack graphs are simply all such chains of attacks that exist in the network put together in one, typically large, graph. To compute an attack graph, the description of the network is needed. This lists the connectivity between hosts and the attacker's initial capabilities on each host, including privilege level and vulnerabilities present on the host. There should also be an additional external host that the attacker has root access on that is the starting point of the attack sequence. One also needs a set of rules to define the attacks possible in the system. For methods which use one rule per vulnerability like Nessus, this will be a very large set of rules. For methods which use abstracted vulnerability classes to define the rules, the set of rules will be much smaller. Here is a link to my set of rules. The expert system JESS is used to compute the attack graph. We will go through a demo in the lab.

5 node network
Attack graphs for 5 node network
JESS Rete network

Updating Nessus Rules

Nessus rules can be updated for the 2.x branch via the command 
      /usr/local/sbin/nessus-update-plugins
The machine must be connected to the Internet for this to work. We will update the plugins and re-run tests for the second half of the lab. Note any vulnerabilities that are new, if any, with this plugin set.

Write a brief summary of what you've seen and email it to my Helios account.