Intrusion Detection in AlienVault

(1)

AlienVault Unified Security Management™ Solution

Complete. Simple. Affordable

(2)

AlienVault™, AlienVault Unified Security Management™, AlienVault USM™, AlienVault Open Threat Exchange™, AlienVault OTX™, Open Threat Exchange™, AlienVault OTX Reputation Monitor™, AlienVault OTX Reputation Monitor Alert™,

(3)

1. INTRODUCTION ... 4

2. OVERVIEW ... 4

3. ALIENVAULT SENSORS AND NETWORK VISIBILITY ... 4

4. PACKET ANALYSIS, SIGNATURE MATCHING AND FALSE POSITIVES ... 5

5. SIMPLE SIGNATURES ... 6

6. PREPROCESSORS ... 6

7. INTRUSION DETECTION WITHIN OSSIM... 7

7.1. Feeds ... 8

7.2. SIEM Events ... 9

7.3. Correlation, Cross Correlation ... 9

7.4. Suricata SIEM Events in OSSIM ... 9

7.5. Suricata Data Source Plugins in OSSIM... 10

7.6. Suricata Message SIDS in OSSIM ... 11

7.7. Unified IDS and SIEM Capabilities ... 12

7.8. Analyzing IDS Events – IDS is not antivirus ... 14

(4)

1. INTRODUCTION

AlienVault includes a Network Intrusion Detection system on the Sensor. This document introduces the feature set and usage of the NIDS system for Analysts.

2. OVERVIEW

AlienVault’s open source advantage means we can include all the essential security controls into a single single: perhaps no other control is as identifiable with modern security operations as the Network Intrusion Detection system. Network IDS started to become an established part of security detection and investigation in the late 1990’s and since then has proved itself as an essential go-to tool for security analysts – a Network IDS system positioned correctly, can grant visibility into a wide range of security issues, without the reliance on the systems being correctly configured to log information properly, run endpoint controls or any number of machine-dependent security considerations.

NIDS have their limitations in return, however, they can only see activity that transpires over the network, not within the hosts on it – so while a network IDS may see an attack attempt against a system, it is not always possible for it to make a determination as to whether that attack was successful or not.

By combining the information form a Network IDS, with the system-side logs in the SIEM, AlienVault can present the complete picture of activity relevant to security defenses to the analysts.

The following is an overview of NIDS configuration and usage within AlienVault.

3. ALIENVAULT SENSORS AND NETWORK VISIBILITY

The AlienVault Sensor component is responsible for all functions involving the monitoring of network traffic. A typical sensor should be configured at least with two network interfaces (but it is normal to be configured with more): an ‘administrative’ interface, configured with an IP address and reachable from the network; and a ‘monitor’ interface. This interface will often have no configured address and is unreachable from the network, instead being connected to a ‘Spanning’ or ‘Mirror’ port on a network switch, that copies all other traffic travelling through the switch to a single port, to allow those packets to be captured and analyzed.

For the NIDS Component of AlienVault to function this configuration is essential, without it the NIDS will only be able to monitor traffic going to the AlienVault machine itself.

(5)

Figure 1. NIDS Component of AlienVault configuration

4. PACKET ANALYSIS, SIGNATURE MATCHING AND FALSE

POSITIVES

While there have been many variations of the underlying technology to implement Network Intrusion Detection, signature-based detection remains the most reliable and easiest method to interpret.

Different IDS systems use different signature detection methods, but in general they will all examine the following things:

IP addresses: Is the source of the traffic internal or external? Does it come from a host that is known to run a particular service (e.g. DNS) or not?

Transport Protocol: TCP, UDP, IGMCP, ICMP?

Ports and Services: what TCP/UDP port is being connected to? Is the client-side port from a low (<1024) port?

TCP Flags: Is this a new connection, or an established stream?

Protocol Headers: what settings are configured in the application-layer protocol being used?

Protocol Data: what is being sent over the application layer protocol?

The core of a Network Intrusion Detection system is a packet capture and stream reassembly – individual packets are captured from the network, and then re-assembled into a complete ‘streams’ (all the data sent back and forth between source and destination. The contents of

(6)

these streams are then run through filters that search for particular patterns of data in certain locations (taking into account how the application layer protocol itself is written).

5. SIMPLE SIGNATURES

Simple signatures must take into account how the protocol itself is written, for example, an application protocol may use the first 27 bytes of the stream as the protocol header, with the data following after that. A signature that looks for a particular pattern in the protocol data must know to ignore the first 27 bytes of any stream, when looking for a match for that attack signature.

This makes the assumption that the data being analyzed is actually the protocol the signature is written for – an HTTP exploit signature will be looking for traffic over TCP Port 80 – but will still analyze data from any application protocol, so long as it is transmitted over TCP Port 80 – resulting in the possibility of signature ‘hits’ from the same sequence of bytes being captured, in a completely harmless data stream.

Similarly, different versions of application protocols can exist – signatures may match on data that is harmful in a particular version of a protocol, but completely innocent without a different version.

As a rule, simple signatures should be taken as an ‘informed best guess’ about the presence of attacks in network traffic – although the range of accuracy between individual signatures can vary greatly.

6. PREPROCESSORS

Protocol Preprocessors add an additional layer of intelligence to IDS systems – they pre-process streams to validate that a particular application protocol is in use, and separate out the contents of the data stream into separate blocks of data that represent functions of the protocol itself. This allows a much more fine-grained analysis of traffic contents to be performed, within the context of what is actually happening – although a simple signature may be limited to searching for a particular sequence of data within the whole datastream, or within a certain

(7)

byte position in the data, preprocessors can look for malicious data only within the functions of the protocol that are vulnerable to that attack.

When correctly written, signatures that use pre-processors can be highly accurate in making detections of real attack data coming over the network.

7. INTRUSION DETECTION WITHIN OSSIM

The intrusion detection engine that currently ships with OSSIM is the Suricata open source intrusion detection engine. Suricata is an established standard in IDS, and uses the same format and language for attack signatures that Snort (another IDS) uses. Snort is a reference standard amongst other IDS engines. There are many engines that import Snort signatures alongside their own.

When new exploits are discovered, information about how to detect them is usually first shared amongst the security community using these signatures. Since new attacks are created almost every day now, IDS signatures are published via feeds of new and updated signatures.

It is possible to configure Snort instead of Suricata in OSSIM through the Web Interface: 1. Choose “Configuration > Deployment > Components > AlienVault Center”.

2. Click on the node name.

3. Click on Sensor Configuration link. 4. Click on Collection link.

(8)

Figure 2. Enabling Data Source Plugins

This table displays 2 columns. The left column shows plugins that are enabled and the right column shows plugins that are available to be enabled.

5. To pass Snort from the right column to the left, look for it and drag and drop it or use the link [+] which are next to Snort. It will pass to the left column. To pass Suricata to the right column, look for it and drag and drop it or use the link [-].

It is not possible to have enabled Suricata and Snort at the same time.

7.1. FEEDS

There is a primary feed of signatures distributed with Suricata, populated with well-tested signatures for recognizing attacks – the signatures in this feed can be assumed to have a reasonably high degree of detection accuracy (or at least as accurate as is possible, given the nature of the attack). A secondary feed, of Emerging Threats, is also available for use in Suricata – these signatures are written for the newest attacks known in the security research community – however, this newness means that these signatures have not received the same amount of testing and validation as the primary feed, and may generate false positives more

(9)

often. Eventually the signatures in Emerging Threats will make their way into the standard feed after sufficient testing and feedback from usage in the field. Both of these feeds are available within OSSIM.

7.2. SIEM EVENTS

Signature ‘hits’ from the Suricata IDS system distributed in OSSIM, generate SIEM events, just like log events from system logs: they are normalized into source and destination, protocol, etc., and can be searched and pivoted on just as with any regular SIEM event.

Just as with any log-based decide, the IDS information is consumed into the SIEM via Data Sources Plugins (and ID’s), and message SIDs for each event type. The Preprocessors in particular, get their own Data Source ID’s, simple signatures get another, each signature gets a unique SID, and SIDs are mapped to OSSIM Taxonomy from their Suricata Taxonomy.

7.3. CORRELATION, CROSS CORRELATION

Just as how log correlation can be used to identify particular sequences of log events from devices, the events from IDS can be factored into those sequences too. This comparison between network-level and host-level events can perform some of the initial validation that would normally be performed by an analyst manually during security analysis.

E.g. an IDS system will show an attack attempt, but often has no way to validate that it has been successful. A host’s logs may show a new administrative user being added, but has no way to determine if this has been done maliciously. Yet the sequence of an IDS attack detection, followed almost immediately by the creation of an admin account, is an event that shouts ‘successful attack’ quite clearly.

Similarly, the cross - device correlation between an event (detector) and state (monitor) plugin is just as straightforward. Attacks against hosts known to have that service or vulnerability present can be correlated into alarms immediately.

7.4. SURICATA SIEM EVENTS IN OSSIM

(10)

Figure 3. Suricata SIEM Events

7.5. SURICATA DATA SOURCE PLUGINS IN OSSIM

(11)

Figure 4. Suricata Data Source Plugins

7.6. SURICATA MESSAGE SIDS IN OSSIM

(12)

Figure 5. Suricata Message SIDS in OSSIM

7.7. UNIFIED IDS AND SIEM CAPABILITIES

While any SIEM can accept IDS logs in the form of syslog messages, there is more to an IDS signature match than merely the information about the hosts involved, the network connection and the name of the signature involved. Proper investigation requires analysis of the data that was matched by the signature.

IDS Signatures are an indicator of an attack, not an infallible identifier of attacks – analysts must examine the traffic that triggered the signature and validate malicious intent before proceeding with any further investigation. With traditional IDS to SIEM setup, this often requires logging into the IDS management interface to cross-reference and locate the event in the SIEM, with the event (complete with all details) in the IDS.

Since OSSIM includes the IDS on the same system as the SIEM however, this ‘extended’ information is directly available from the SIEM UI itself: clicking on an IDS event in the SIEM will bring up the extended details page complete with packet capture breakdown and a payload.

(13)

Figure 6. Extended details of an IDS event

Events and Signatures in OSSIM can have external references attached to them, especially important in the case of IDS signatures where analysis is entirely dependent upon knowledge of the methods involved in the attack method the signature is indicating. The signature reference links to the side of every IDS event will open a new browser window and load one of several authoritative references on the vulnerabilities and exploit methods relevant to the IDS signature in question. Clicking on the event (signature) name it will bring up the event details page as normal for any event, but with an additional details panel, specific to IDS events:

(14)

Figure 7. Event details of an IDS event

There are a great many additional open-source tools out there that consume packet data for further analysis, however, and we include a link to download a ‘. pap’ file containing the matching packet data for use in those external tools.

7.8. ANALYZING IDS EVENTS – IDS IS NOT ANTIVIRUS

One of the most common issues junior analysts encounter when responding to IDS alerts, is the “One Signature, One Attack” fallacy – real world attacks may trigger several signatures, none of which references the attack by name. Complete attacks operate via several stages – exploitation of a vulnerability, delivery of a payload and reconfiguration of the victim host to allow the attacker persistent access to the system – each of which will trigger a different class of IDS signature.

The “All events from this host” option (right-click on a hostname in the event list window) from any IDS event listed in SIEM, will search for all other SIEM events between the source and destination host – this should often be the starting point for investigation of any IDS alert, to get a bigger picture of the activity between these systems (especially other IDS alerts that have triggered between them).

Many signatures in particular are ‘generic’ indicators of exploitation methods, and signify very little by themselves. A list of the signatures most commonly encountered by successful details of compromised machines lists these signatures as having the highest rate of successful detection.

(15)

Detects SID Author Phase Description

27% 22466:7 snort inbound exploit netbios smb-ds ipc$ unicode share access 26% 2002750:10 snort inbound policy reserved ip space traffic - bogon nets 2 19% 299913:1 snort inbound exploit shellcode x86 0x90 unicode noop

Yet none of these signatures by themselves demonstrates an actual attack, and in isolation, indicate either a false positive or normal network activity.

It is recommended to check if the AlienVault correlation system has generated some alarm. The event correlation is a valuable capability that saves time to Analysts.

7.9. ANALYZING IDS EVENTS – LIBEMU CODE DISASSEMBLY

With a few notable exceptions (such as SQL Injection), almost all software exploitation is performed using compiled code, this compiled code is then converted to a format suitable for transmission over network protocols (that normally would not transfer executable code) via a format dubbed ShellCode. Shellcode detection is a reliable indicator of malicious software, has a high rate of false positive when an IDS examines all transmitted data across the network (a sequence of bytes that may be shellcode, may also just be part of an otherwise harmless image file for example). To assist in the identification of actual shellcode payloads in IDS alerts, OSSIM includes the LibEMU disassembly library, which will attempt to de-compile any data detected as being shellcode, back into human-readable source code.

(16)

When an IDS signature payload is detected as containing Shellcode, LibEMU will be run against it and attempt to provide a disassembly of the code back into X86 assembly language. Success disassembly will generate call graphs (example above) that demonstrate the activities of the code in question. (Interpreting this disassembly is, however, outside of the scope of this introductory document).

The presence of a successful disassembly is an extremely strong indicator of actual exploit code being the cause of the IDS signature hit. The message “The Shellcode couldn’t be analyzed” is strong evidence of a false positive (or at least, shellcode for an unsupported CPU architecture).

Intrusion Detection in AlienVault

AlienVault Unified Security Management™ Solution

Complete. Simple. Affordable

CONTENTS

1.

INTRODUCTION ... 4

2.

OVERVIEW ... 4

3.

ALIENVAULT SENSORS AND NETWORK VISIBILITY ... 4

4.

PACKET ANALYSIS, SIGNATURE MATCHING AND FALSE POSITIVES ... 5

5.

SIMPLE SIGNATURES ... 6

6.

PREPROCESSORS ... 6

7.

INTRUSION DETECTION WITHIN OSSIM... 7

1.

INTRODUCTION

2.

OVERVIEW

3.

ALIENVAULT SENSORS AND NETWORK VISIBILITY