Honestly, had you asked last August whether I would cover fault trees (and success trees) as part of SRA 311, I would have probably said no.  After all, this tool is most often found in engineering reliability and failure analysis and less so in IST.  Recently, however, I recalled that there are in fact  a number of uses for fault trees in security analysis, as evidenced by their use as part of the RAM-D-style security risk assessment methodologies developed by Rudy Matalucci and colleagues.  Then I recalled that analogous tools such as attack graphs and Wigmore charts (though these were not necessarily designed to diagnose reasoning failures) were, in fact, part of the IST curriculum.  So, this semester I decided to introduce fault trees, and their complement success trees, as a tool for reasoning from undesired event to its root causes considering the logical interaction of different states of a system.  That is, fault trees will be used to answer the question “how can an outcome come about?”  This is a vulnerability assessment question.

The coverage of lecture 8 spanned simple logic, to include truth tables and logic gates (e.g., AND, OR, NOT, NAND, NOR, and XOR).  We covered the expression of complex logical interactions using both tree form and mathematical notation.  We spoke about fault tree construction, to include definition of a “top event,” “basic event” and “intermediate event,” and how basic events relate to intermediate events and the top event through logical connectives.  In order to provide advice on how to convert fault-trees to their logical complement (i.e., “success trees”), we also spoke about DeMorgan’s laws.  Finally, we defined a cut set (not path sets, though) and discussed how they provide insight into how different combinations of only a few elements can lead to the undesirable event.

To illustrate these concepts, I attempted to run a group exercise centered on the undesired (top) event “building break-in.”  The class, as a group, brainstormed what things must happen for building break-in to occur, to include lock failure, failure to detect, and so on.  We then focused on a small branch of the fault tree – failure to detect – and used this to write the logical expression for the top event.  Applying DeMorgan’s laws, we then determined the expression for the complementary success tree, and used this expression to draw it using the logical connectives.  Finally, we identified cut sets for the original fault tree.  My plan is to have groups develop a big fault tree for HW #3 and use it for various reasons that are still to-be-determined.

Overall, this exercise went ok considering the horrible layout of the room I am using.  As I mentioned in a previous post, I no longer have a tablet PC to use for class.  Thus, I find myself having to resort to the use of white boards and chalk boards to run through problems (as opposed to just writing everything on my screen and projecting it to the class).  The problem is that the rooms we use in IST are not setup for using white-boards the way engineering instructors use them – that is, the rooms are very deep and flat, thus people sitting in the rear half of the room will have a lot of trouble deciphering my chicken scratches from, say, >30 feet away.  Perhaps I need to slow down, write neater and write bigger.  I am sure I will get better with this over time.

(by the way – there was no “book of the day” today).

Send article as PDF to