Object Oriented Relationships

Vulnerabilties so far appear to be mostly fields of data, however a rather unusual relationship exists between two of the more complicated aspects: fault and consequence. It has been noted in the "Anatomy of a Vulnerabilty" chapter that both fault and consequence are very specific to each vulnerability, having a unique description at the actual exploit level. To refresh your memory, here is the table again:

	Fault	Severity	Authentication	Perspective	Consequence
Logic Error	Specific	Independent	Independent	Independent	Specific
Weakness	Specific	Independent	Independent	Independent	Specific
Social Engineering	Specific	Independent	Independent	Independent	Specific
Policy Oversight	Specific	Independent	Independent	Independent	Specific

However, consider the fault "buffer overflow". It can have a number of different consequences - it could gain shell access (common with UNIX computers), it could gain execution of a single command (common with Microsoft Windows computers), or it could cause a denial of service attack where the service being attacked ceases to function. However, not all computers are susceptible to buffer overflow attacks that gain shells - but may still be vulnerable to the denial of service consequence.

Lets investigate the properties of an object quickly, because how this relates to a computer vulnerability is a bit difficult to visualize (virtual elements often are.) An object has two aspects: data and functions. These are sometimes visualized in the form of a circle with a line separating data from function. The data determines how the functions behave when they are called. The functions always exist, but not all of them need to be called for the object to function.

The data aspect of the object is clearly fault. The vulnerability has a state that

brings about the vulnerability at any given time, and this state is the data aspect of a vulnerability object. This state can be altered, presumably by the system administrator installing patches and security tools and not by the vulnerability itself. However, the ability for the vulnerability to exist rests on the conditions set forth in the data object. The fault doesn't determine the end result, or the method in which the vulnerability is called.

The aspect of the object that is its function is the consequence. There may be a large number of consequences for each possible fault, but they all apply. With the large number of possible consequences for each fault, the choice can be made by the attacker how the attack can manifest itself.

By looking at the vulnerability object in this way, other more specific attributes can be considered as being inheritors of this parent object. Example, a "buffer overflow" fault with all the consequences describes a basic vulnerability possibility, but a specific buffer overflow (such as a buffer overflow in the Finger service) would specifically determine the severity, tactic, and if authentication is required. This causes the fault/consequence pairing to be a template that is called by specific vulnerability situations.

YiibiGrabilUy Trmplatu Objett       YTihuerabiEty Attributes  Spe-cilif Vulnerability SihiAtiwt

At this point, it should be noted that a "specific vulnerability situation" makes an exceptional roadmap for automated risk assessment, but doesn't quite equate to a "real world" vulnerability.

The final object evolution adds details to the vulnerability. Several papers have been written describing which details are important. However, its fairly obvious from the vulnerability road map from the Anatomy of a Vulnerability chapter that no single set of specifics will cover all of the situations. However, just about all the vulnerabilities will contain:

• discovery time

• discoverer

• reference to patch(s)

• reference to advisory(s)

• reference to exploit(s)

• short description

• detailed description

Logic errors may also contain:

• operating system(s)

• computer CPU type(s)

• wire type(s)

• software package(s)

• hardware type(s)

Weaknesses may also contain:

• hash(s)

• encryption(s)

• protocol(s)

• locations of "moving targets"

• size of N-space (depending on situation)

name

Computer Vulnerabilities Object Oriented Relationships Page 64

Social Engineering and Policy Oversights may also contain:

• Phone numbers

• Web Pages

• names and positions of people

• information agencies

• associated companies

• project stakeholders

• street addresses or physical locations