Operator selection mechanism

In conclusion, the event data manipulation performs the following cycle, summarised in Fig-ure 6.1.

Figure 6.1: Anonymisation through Generalisation

This satisfies the design objectives determined for the events and format requirements through the MASSIF elements and within the OSSIM SIEM solution.

The full details of the misuse case[41] simulated in the demonstration experiment is given in Table 6.7.

MISUSE CASE 2 Brute-Force Password Attack

1 System prompts user for login details

2 Unauthorised user performs multiple attempts to log in using many username/password combinations 3 System authenticates the authorised user’s successful

combination and creates a new session.

EXTENSIONS Step Branching Action

-VARIATIONS Step Branching Action

3a1 Detection Mechanisms discover a brute-force attack attempt and lock the computer to prevent any further combinations from being attempted.

Exceptions -

-Other Information Most systems already have in place measures which identify failed authentication attempts within close succession. The result often locks the user from accessing the machine. Through early detec-tion of port scans or automated login attempts, the damage from such an attack being successful can be reduced or eliminated

OPEN ISSUES N/A

Table 6.7: Brute-force Misuse Case MC5.5.1

The directive (Listing 6.3-8), was created for the testbed simulation to verify the retrieval of geolocation through SIEMS, and their use in detection and reponse. SIEMs stucturally, are heavy frameworks and internally complicated. It’s significant to consider the ease of integration of geolocation data into these tools and the OSSIM solution, to advocate the fundamental reasons in investing the efforts to exploiting the data.

6.5.2 The Testbed

The test solution makes use of three virtual machines named VM1, VM2, and VM3 respec-tively. These machines and their specifications are discussed in Table 6.8.

Virtual Machine Operating System Description

VM1: MASSIF-RES Windows 7 Hosts Syslog tool for event replay and the RES visualization interface VM2: OSSIM OSSIM 4.0.2 Debian The OSSIM solution with REB

node

VM3: MASSIF-GET Ubuntu 10.04 Hosts the GET Framework and RES tool

Table 6.8: Testbed virtual machines and their specifications

VM1 hosts the Syslog generator tool that replays logs generated by the MESI infrastructure.

The logs contain evidence of brute force attacks and the GPS locations of users. VM3 hosts the GET framework configured with a proper parser for Windows Server events processed by the Tivoli Security Operation Manager (TSOM). The GET communicates with the OSSIM Server through a REB node. VM2 hosts a second REB node that collects the events sent by the GET and passes them to the OSSIM Server. Once alerts are triggered, the events are stored on the RES, which is installed on the VM3. Finally, the RES visualization interface is installed on the VM1 machine. Figure 6.2 demonstrates the experimental setup for scenario provider validation with MASSIF.

6.5.3 Execution Process

1. The Syslog client tool replays raw events, as shown in Figure 6.3, using the Syslog tool of the GET. The event sets contains patterns of a brute-force attack targeting a Windows Server machine in the environment.

2. Figure 6.4 demonstrates initiation of the REB server for event transfer to OSSIM. The GET, seen in Figure 6.5, is used to collect, parse and translate these events into the OSSIM Normalized format. Figure 6.6 demonstrates the replay of event logs using rsyslog to be fed into the GET tool. The cycle of events from GET to OSSIM with the REB tool is shown in Figure 6.7.

3. The GET encrypts each original log generated by the monitored infrastructure and converts it into the OSSIM Normalized event, the formatted logs have an anonymised version of the fields required for correlation on the OSSIM server. As seen in Figure 6.8, the REB then transfers these encrypted events in OSSIM format to the OSSIM server.

4. OSSIM receives these events through the REB and applies the correlation directive. The alarms triggered from the directive are stored both on the OSSIM alarm database and on the RES. The RES contains the alarms and the triggering events with the encrypted payload. These alarms stored on the RES, seen in Figure 6.9, can be decrypted only by authorized parties(password-based encryption).

Figure 6.2: Experimental setup with MASSIF and Alienvault

Figure 6.3: Original raw event data showing accurate geolocation

Figure 6.4: Starting the REB server, ready to channel parsed events from the GET to OSSIM

Figure 6.5: Starting the GET tool

Figure 6.6: Event replay of these raw logs to be sent to the GET

Figure 6.7: OSSIM, REB and GET

Figure 6.8: REB sending encrypted events in OSSIM format from GET to OSSIM server

Figure 6.9: OSSIM generated alarms (left) and log events triggering the alarm (right) stored in RES and can be retrieved by plugin id(top)