---

Manual Reference Pages  - OODA (7)

---

ooda - overview of the ooda Body Cycle model

CONTENTS

Description
Authors
Bugs
See Also

This manpage is intended to give an overview of the internal functioning of the ooda widget. Information about command line usage may be found in the ooda(8) manpage.

The internal state model implemented by ooda is that of the Boyd Cycle. Conceived by John Boyd, the Boyd Cycle (sometimes called the OODA Loop) is a description of decision making cycles. It consists of four stages:

Observation
	This is the stage at which information is collected---from the environment, from situational context, and so on. In ooda(8), this primarily involves querying event information from the shoki database. A broader Boyd Cycle model of the shoki NIDS would actually include the operation of most of the other widgets as part of this phase. Indeed, most current intrusion detection systems exist primarily in the observation phase of the Boyd Cycle and rely on human operators for the rest of the loop. An example observation (in the context of the ooda(8) widget) would be an event logged to the shoki database. Informally, the information content would be something like, "A packet matching signature foo was seen", with the corresponding IP/TCP/UDP/ICMP/whatever information.
Orientation
	In this stage, information collected in the observation stage is used to construct a model of the current situation. In the case of ooda(8), this involves things like comparing event data with asset data (i.e., to determine if an attack is being directed at a machine believed to be vulnerable to that attack). Doctrine rules (explained in greater detail in the decision section below) provide the guidelines used by ooda in building its situational model. An example of a correlation established in this stage would be something like: A packet matching signature foo was seen Signature foo corresponds to CVE-xxxx-yyyy The destination address of the packet is the IP of an asset believed to be vulnerable to CVE-xxxx-yyyy
Decision
	The decision phase is where a hypothesis about the current situation is made based on the model created in the orientation phase. The hypothesis is often predicated on explicit decision making criteria. In ooda these criteria are enunciated as shoki doctrine rules (see the shoki.doctrine(5) manpage for more details). These rules describe combinations of events and conditions monitored by the other components of the shoki NIDS. When the all the rules in a complete doctrine have been matched, ooda recognises that some situation (as described by the doctrine rules) exists. It’s worth noting that the decision phase is often tightly coupled with the observation phase, with doctrine rules describing new filter rules to be run against the raw packet data to test for new conditions based on previously-observed behaviour. More details about this process can be found in the shoki.topology(7) manpage. An example of a decision made at this stage might be (informally) something like: An exploit was directed at a machine believed to be vulnerable to that exploit That machine shortly thereafter established an outbound connection to the source of the exploit Therefore, the machine is assumed to have been compromised
Action
	Having formed a hypothesis about the situation, ooda now does something with this information. The action is typically something which will test the hypothesis or something which will notify the incident analyst of its discovery. An example of an action made at this phase would be something like adding a new filter rule (for subsequent observations) or adding an alert to the shoki alerts table.

The OODA loop is repeated continuously, with each iteration potentially providing additional information to be used as input to subsequent iterations. An example:

First Iteration
Observation
	A packet matching signature foo is seen
Orientation
	The destination of the foo packet is vulnerable to the attack tested for by signature foo
Decision
	The potential for compromise is high enough to warrant additional investigation.
Action
	Write a new filter rule (or signature) testing for traffic originating from the destination of the foo packet and directed at the foo packet source. call this new signature bar

Second Iteration
Observation
	A packet matching signature bar is seen
Orientation
	The target of an exploit, believed to be vulnerable to that exploit, has sent traffic to the source of the attempted exploit.
Decision
	The target is assumed to have been compromised.
Action
	Add an alert indicating that the destination of the foo packet (which is the source of the bar packet) has been compromised.

.An Stephen P. Berry <spb@meshuggeneh.net>

More information can be found at the shoki homepage:

Check the README at the top of the source tree.

dlex(8), ooda(8)