• No results found

Field Field name Pseudonymised Comment

52 TargetHostIPGeoLong - Longitude of<TargetHostIP>or empty string if it is a private IP address

53 TargetPort - The port targeted by the threat.

54 TargetProtocol - The protocol targeted by the threat.

55 TargetProcessName - The process name which was the target of the threat.

56 TargetFileName Yes The name of the file which was the target of the threat.

57 ThreatCategory - Common threat categories are anti-virus

detec-tion (av.detect) or firewall detecdetec-tion(fw.detect)

58 ThreatEventID - Unique event ID of the logged threat.

59 ThreatSeverity - Severity of the threat

60 ThreatName - Description of the logged threat (e.g. name of

the virus).

61 ThreatType - Type of the threat (e.g. buffer overflow).

62 ThreatActionTaken - Description of the action taken (e.g. deleted).

63 ThreatHandled - Indicator if the threat was handled or not

64 The Timestamp - Sequence number the ePO expects from a

con-necting agent. If the sequence number does not match, communication is rejected.

Table 5.8: Input Vector of McAfee Events

The events were transformed according to the above specification and test cases, and pro-duced a normalised set of logs. The resulting event log is an output from the input vectors in CSV format.

The highlighted fields indicated the geolocation information present within the logs. The geolocation data is identifiable for source and destination of events. The Windows events, contain two sources for geolocation as shown in the table. One source is of geolocation is from the TSOM sensor itself and the second is from the windows raw events, extracted from the

$EVENT.INFO token.

In Figure 5.1 we highlighted the connection between the TSOM environment output and our experimental solution - the data received from the CMS was retrieved, normalisation per-formed according to the input vectors specified above and retrieved for use in this ‘enhanced’

SIEM testbed to carry out the determined technical objectives.

critical infrastructure process control and managed enterprise service infrastructures. The data used is from a managed enterprise environment therefore, the considerations are focused on the tools applied within that scenario.

As a next-generation SIEM framework support for service infrastructures it encourages in-telligent, scalable, multi-level/multi-domain security event processing and predictive security monitoring[40]. Figure 5.3 provides an architectural overview of the MASSIF framework at a high level.

Figure 5.3: MASSIF Architecture Overview[40]

On the basis of proper multi-level event correlation MASSIF can provide innovative techniques to enable the detection of upcoming security threats and trigger remediation actions even before the occurrence of possible security incidences.

This service-level SIEM technology involves the modelling and formal validation of security, including trusted computing concepts, architecture for dependable and resilient collection of service events, supported by an extremely scalable and high performance event collection and processing framework, in the context of service-level attack models[40].

The tools and elements of MASSIF can be integrated with two SIEM solutions, these are Alienvault OSSIM and 6Cure. The defined elements within the MASSIF architecture are modular, allowing a tool or combinations of tools to be used with other systems. For this

research this ability is exploited in the consideration of integration with OSSIM.

Technical Summary

The modularity of the tool structure that defines the MASSIF framework covers a range of software requirements. However, the differences are not incompatible and easily deployable in many environments. In terms of installation and implementation requirements, most tools just require a Java friendly environment with the appropriate runtime environment version installed. A summarised technical breakdown of the tools and elements of the conceptual framework is shown in Table 5.9. The functionality area and it’s technical requirements can assist an evaluation of compatibility for a testing environment and integration with other software.

Component/Functionality General Tool Specifications Event and Information Collection

Multi-Level Event Collection Java Runtime Environment (JRE) version 1.7

Languages SQL, Java, Python, UML

Multi-level event correlation JREv1.7, JDKv1.6, Derby DBMS v10.10.1.1, Apache Tomcat 6.0.20 or later Event, Process and Attack Models

Process & Attack Simulation Syslog, JREv1.7 , Linux MOTIF Library1, Ruby

Multi-level security event modelling JREv1.7, Python, Apache Felix 4.0 Predictive security analysis Python, Netbeans IDE, JRE v1.7

Other tools

Alert and Reaction Generation Python(requiring packages e.g python-lxml,python-mysqlb, python-setuptools, figlet), JRE1.7

Trustworthy Event Collection JRE 1.7 Resilient Framework Architecture JRE. 1.7

Table 5.9: MASSIF tools software specifications

5.3.2 OSSIM Alienvault Solution

OSSIM is a fully featured SIEM solution offering all necessary functionality from event col-lection and incident detection to alarm response and feedback visualisation. The foundation for Alienvault’s security management solution is Open Source SIEM(OSSIM) which provides SIEM vulnerability assessment, network and host intrusion detection, and file integrity mon-itoring. Alienvault markets and supports commercial software or application offerings that extends OSSIM with enhancements in scaling, log management, reporting, administration and multitenanting for managed security service providers (MSSPs). Therefore, OSSIM works as an open-source framework as well as commercial depending on the level of SIEM tool provi-sion. Enabling the facility of open-source allows users to experiment with the current solution

and help suggest even better adjustments to this framework.

In a summarised overview the solution provides the following features;

• Low level, real-time detection of security events

• Compliance automation

• Data log management and storage

• Event log and alarm visualisation

• Security intelligence that enhances the accuracy of threat detection

• Network behaviour analysis and situational behaviour awareness

Figure 5.4 provides a high level overview of OSSIM solution, it’s capabilities and security event flow.

Figure 5.4: High level view of the OSSIM Architecture[36]

Technical Summary

The OSSIM solution based on the Linux Debian operating system, is available as a complete solution using virtualisation software, such as VMware2. The entire solution can then be

2www.vmware.com

installed in the virtual environment and accessed through its assigned static IP specified for that machine instance. The system requirements for testing purposes use a minimum of 8GB RAM, 2 CPU cores, with at least 250GB storage capacity.

This architecture is based and centered on the efforts of four main components:

• OSSIM sensor: The sensors collect and normalise the events generated by the different security equipment. One can deploy as many sensors as needed

• OSSIM server: The server receives events from sensors, and does Risk Assessment and Correlation tasks

• OSSIM database: For storage purposes, there is a provision of a MySQL database that stores the events, configurations, and useful information.

• OSSIM framework: The framework encapsulating the solution is the PHP/Python code that “serves” the information to the webfront-end.

Events are received by the sensors, once they are normalised on the sensor they are sent forward to the remote or local OSSIM server[21]. The server collects the normalised events and applies user defined policies on them. Depending on the policy definition the event is sent for correlation in the correlation engine or not. The correlation engine is a powerful feature of the solution, providing users the ability to write correlation rules using XML to parse the events and trigger certain responses from the SIEM solution. After policy enforcement, the next phase is risk assessment, then finally events are sent to the correlation engine.

Correlation of events is performed, which enables the generation of alarms that are visualised in the interface. Any alarms generated are stored in the OSSIM database for a certain time period.

The solution allows tight control over widely distributed enterprise networks from a single location. In summary, the system considers the context of each threat and the importance of the assets involved, evaluates situational risk, discovers and distinguishes actual threats from the thousand of false positives that are produced each day in each network.

Related documents