SIEM in practice: make friends with Prelude + Cisco IPS and reveal HeartBleed operation through correlation

Good day to all!
The SIEM theme itself has recently been popular. In view of the complex complexity of these systems, the issues associated with their use are deep and voluminous. There are quite a few articles (on Habré and not only) devoted to SIEM. However, the vast majority of them touch on the topic in terms of theory, methodology and general principles for the construction of processes. But there are no catastrophically few articles describing the practical aspects of the application / configuration of these systems . This article describes how to make IPS and SIEM friends in practice using the examples of Cisco IPS and Prelude, as well as an example of a correlation rule that reveals the successful exploitation of the HeartBleed vulnerability that has become painful in recent days.

1. Introduction / statement of the problem

So, we have implemented IPS in Inline , what next?
Obviously, the next step is to somehow monitor what IPS catches, in what quantity, whom and from where they are attacking, etc.
To be more specific:

1. It is necessary to maintain a set of active signatures relevant for the protected hosts.
2. For the effective operation of IPS-sensors, you must constantly "keep abreast": you need to constantly adapt the sensor to specific networks and traffic. This is achieved by setting up rules with exceptions.
3. Among the many alerts received from IPS, it is necessary to highlight the truly important and critical.
4. For critical alerts, it is also necessary to provide the correct set of aggressive actions (blocking traffic, resetting sessions, IP bans, etc.) undertaken by the sensor, as well as notifying the administrator about them.
5. The state of the sensor itself also needs to be monitored (load of the scanning engine, update errors, license validity periods, etc.).

To solve such problems, you need to choose a convenient and at the same time functional tool.

2. Native IPS Event Viewer

There are many ways to collect and process events from IPS.
Of the standard event viewers from Cisco sensors, there are such options:

2.1 Viewing Events Locally on the Sensor

This tool, the principle of which can be described as "in the forehead." Each sensor has its own local event store. Of course, you can see in it only what was found directly on a particular sensor.



Any grouping / aggregation of events on any grounds is not provided. The maximum that you can afford is to filter the displayed events according to a number of criteria (signature criticality, sampling time, show / not show sensor system events). The event listing itself looks like this:



Actually, using this functionality makes sense either for debugging (when transferring events to external systems), or when the organization uses one single sensor (although even for such a situation, the solution, to put it mildly, is not the most convenient )

2.2 Cisco IPS Manager Express

The next "native" alternative to the previous tool is IME. This is a free Cisco solution that allows configuration and event monitoring for up to 10 IPS sensors. In terms of configuration, it is worth noting that here we are talking about a common console for devices, i.e. There is no way to create configuration policies (with the exception of three parameters related to the Global Correlation, Reputation Filtering, and Network Participation features).
As for the collection of events, the situation is much better here: alerts from various sensors are collected in a common database.



Event collection is supported both from IPS-applications / modules, and from IOS-IPS routers. It is possible to group and filter events according to various criteria. In each event, you can “fail” to view more detailed information:



Another useful feature of IME is the ability to notify via email about events received from IPS. There are only two selection criteria for alerts: Attack Severity Rating and RiskRating.



Although IME is a fairly functional tool, it is not without some limitations. One of the significant drawbacks is that IME is not a client-server system, but is essentially a regular application that uses a MySQL database. In previous versions, IME was not even supported on server and x64-bit operating systems. Also, the restrictions are the maximum number of supported devices (no more than 10) and the number of processed events per second (100 EPS).

2.3 Cisco Security Manager

CSM is already positioned as a full-fledged Enterprise solution designed for centralized management of various devices (IPS, ASA / PIX, IOS routers, etc.). The number of devices that can be controlled depends on the license purchased. The management itself is already carried out on the basis of policies: you can make a reference set of settings, which can later be replicated.
In terms of collecting, storing and displaying events, CSM is very similar to IME:



Here, as in IME, it is possible to group / aggregate and filter displayed events according to various criteria. In addition to events from IPS, CSM also has the ability to track events from ASA / FWSM / PIX firewalls.
You can also “fail” into each alert to view more detailed information:



Although CSM is positioned as an Enterprise solution, unlike the same IME, it does not know how to collect alerts from IOS-IPS (but at the same time knows how to configure them through policies). Also, CSM cannot e-mail alerts about events captured by IPS.

3. SIEM

The solutions described above are each good in their own way. But, from the point of view of collecting events, they are quite narrowly focused: in addition to events from IPS (and from firewalls, in the case of CSM), we will not be able to see anything else in them.

Quite often, in my practice, colleagues from neighboring departments have questions:

• We have here <channel loading increased | service stopped responding | system has moved off | something happened> do not know what is connected with?
• And you (IS) didn’t notice anything suspicious there?
• etc

It is in such cases that it becomes necessary to check events from routers, switches, logs from unix / windows, logs of specific systems, antiviruses, mail gateways, etc. In fact, the list goes on and on.
And yet, compare all this with each other according to some criteria (make correlation), get additional information on the go about the hosts participating in the event: what kind of resource is vulnerable or not, which ports are open, etc.
This is where SIEM systems come to the rescue. They are able to do all of the above, and with due diligence - also automated.

One of such systems is a little-known in Runet beast named Prelude. It will be discussed.
Why exactly about him?

1. I like him.
2. It works (and for quite some time).
3. He has an OSS version.
4. Has native compatibility with other OSS systems .
5. If desired, you can connect any source that writes a log.
6. From it you can assemble your own “Swiss knife” for your tasks of identifying, investigating and responding to incidents.
7. The correlation module is implemented as plug-in scripts in Python, which means flexibility in the fullest sense of the word. A full-fledged programming language provides the ability to write any correlation rules.
8. There is a convenient Prewikka interface.

Prelude is based on the IDMEF format , which predefines the fields in received messages. In addition to predefined fields, you can also create your own, with a given name and format (additional data), where you can write everything that does not fit into standard fields. Based on the data recorded in various fields, filtering, aggregation and correlation of events can be carried out.

3.1 Prelude Architecture

In a simplified version, the system architecture can be represented as follows:



Manager - is the core of the system. It is responsible for receiving already normalized (unpaired) events from LML agents, the correlation module, third-party systems or subordinate managers (available in the commercial version). The received messages are written to the database. He is also responsible for email alerts.

LML is a system agent and a primary event provider. It receives logs from various systems (via a local file or through syslog to a UDP port). It parses / normalizes the received logs based on a set of rules consisting of regular expressions. Normalized events are given to Manager. LML can work both locally (on the same server as the Manager), and remotely.

Correlator- correlation module. Connects to Manager as an agent. Correlates events received by Manager based on plugins implemented as Python scripts.

DataBase is the database itself, where all events processed by the system are stored.

3 ^rd Party Systems - third-party systems with IDMEF support, allowing you to connect them directly to Manager.

Prewikka is the main system interface implemented on the Web. Designed to display processed events, their aggregation / filtering, statistics output, etc.

It all looks like this:



Events are displayed in a table, in the columns of which information about / about is located:

• classification of alerts (Classification), containing fields with the name of the event, a sign of its (unsuccessful) completion, id-event (signature number, vulnerability number by CVE, etc.), criticality of the event, etc.
• source / target (Source / Target) containing fields with ip-address, mac-address (if it was present in the event), the original username, process, file, etc.
• analyzer (Analyzer - event source) containing fields with ip-address, analyzer class, etc.

The number of IDMEF fields displayed depends on the type of event and the rule for processing it. Some fields can be indexed, i.e. contain multiple values. For example, there may be two userid.name fields, in one of which the value samaccountname will be written, and in the second - the SID of the same account. And, for example, in the event of an event from the system for checking the integrity of files in the source and target information, neither the address, nor the port, nor the protocol will be displayed - these fields will be occupied with information about the changed file, checksums and other additional information.
In any event, you can “fail” to view more detailed information:

4. How to pick up events from sensors?

Before connecting IPS to our system as a source, you need to understand how you can get from the IPS the alerts stored in it.
There are two methods for transmitting events from Cisco sensors (and one semi-method for IOS-IPS) to external systems:

1) Via SNMP Trap , which sends the sensor itself upon the fact of a signature or system event.
Gangways sent by the sensor are as follows:

#012iso.3.6.1.2.1.1.3.0 15:1:47:08.58#011iso.3.6.1.6.3.1.1.4.1.0 iso.3.6.1.4.1.9.9.383.0.1#011iso.3.6.1.4.1.9.9.383.1.1.1.0 6822393729640#011iso.3.6.1.4.1.9.9.383.1.1.2.0 "07 DE 04 0A 0B 2C 0E 00 "#011iso.3.6.1.4.1.9.9.383.1.1.3.0 "07 DE 04 0A 07 2C 0E 00 "#011iso.3.6.1.4.1.9.9.383.1.1.4.0 "IPS-SENSOR-01"#011iso.3.6.1.4.1.9.9.383.1.2.2.0 2147516416#011iso.3.6.1.4.1.9.9.383.1.2.3.0 "Heartbleed"#011iso.3.6.1.4.1.9.9.383.1.2.4.0 "OpenSSL Information Disclosure"#011iso.3.6.1.4.1.9.9.383.1.2.5.0 4187#011iso.3.6.1.4.1.9.9.383.1.2.6.0 0#011iso.3.6.1.4.1.9.9.383.1.2.7.0 "S785"#011iso.3.6.1.4.1.9.9.383.1.2.13.0 0#011iso.3.6.1.4.1.9.9.383.1.2.14.0 "iBCRX+m57XRkOtzSnz0MSIw/CJWscqWUKqhEjadJYMWue6yLZAgTFpc8+LuL#012H/4o5rulPzbm1D9tQZ2tnoY/qfwSZ3H1VE2Wt2/rwUHcjVaKjGue9I0FdGZN#012JgpdbIcOOiBxB0T0JJ0qsqAzTMO37pf6GNOcByoHVgcgubBM2x148331MWSP#012O4hROt/p8Zpk8ZmNBIfUwy4yA0ByxPANY4e+ixHoPOe0aJGk1GUthnyAhKn8#012ztzv/kfCXHyPH5X7DBXTTXYZN+Xv6vnWYJV3tojoaOIpv6shRYLjeg84qeO5#012vY3P0uXwcYSCj1YY4rdgQpQvL8PkOxYDAgAEDgAAAA=="#011iso.3.6.1.4.1.9.9.383.1.2.15.0 "FgMCANwBAADYAwJTQ1uQnZtyC7wMvCuSqEiXz705BMwWCoUDkJ93BDPU3gAA#012ZsAUwArAIsAhADkAOACIAIfAD8AFADUAhMASwAjAHMAbABYAE8ANwAMACsAT#012wAnAH8AeADMAMgCaAJkARQBEwA7ABAAvAJYAQcARwAfADMACAAUABAAVABIA#012CQAUABEACAAGAAMA/wEAAEkACwAEAwABAgAKADQAMgAOAA0AGQALAAwAGAAJ#012AAoAFgAXAAgABgAHABQAFQAEAAUAEgATAAEAAgADAA8AEAARACMAAAAPAAEB#012GAMCAAMBQAAYAwIAAwFAAA=="#011iso.3.6.1.4.1.9.9.383.1.2.16.0 "192.168.1.1:51716"#011iso.3.6.1.4.1.9.9.383.1.2.17.0 "osIdSource=\"unknown\" osRelevance=\"relevant\" osType=\"unknown\" 10.10.10.1:443"#011iso.3.6.1.4.1.9.9.383.1.2.21.0 "InterfaceAttributes:  context=\"single_vf\" physical=\"Unknown\" backplane=\"PortChannel0/0\" ; "#011iso.3.6.1.4.1.9.9.383.1.2.25.0 70#011iso.3.6.1.4.1.9.9.383.1.2.26.0 5#011iso.3.6.1.4.1.9.9.383.1.2.27.0 6#011iso.3.6.1.4.1.9.9.383.1.2.42.0 70#011iso.3.6.1.4.1.9.9.383.1.2.49.0 "vs0"#011iso.3.6.1.4.1.9.9.383.1.3.1.0 "high"

2) Through the SDEE standard. In this case, the IPS-sensor acts as a Web server, and external systems connect to it independently and pick up new alerts. This method is used in CSM and IME products. Cisco's SDEE uses the CIDEE extension, which describes additional fields.
You can see SDEE alerts in “pure form” through the browser by scoring https: // in the address bar/ cgi-bin / sdee-server (authentication will be required).
The alerts themselves look like this:

IPS-SENSOR-01sensorApp27106139266879604444500017TCP segment is out of state ordervsx302192.168.0.144310.10.10.124479true2525ge0_3tcp

Running a little ahead, it is immediately worth noting that the use of SDEE has its pros and cons. Data received via SDEE contains more information about the alert compared to the SNMP trap. For example, there is information about the actions taken by the sensor. But to export data via SDEE to SIEM, a special connector is required (in Prelude it is only in the commercial version).

3) Via syslog(only for IOS-IPS). For completeness, it is also worth noting some of the features of IOS-IPS. They also support SDEE, but they cannot send alerts via SNMP. Unlike its "older" brothers, IOS-IPS can write information about alerts to the local syslog repository of the router. The syslog of the router, in turn, can be transferred to an external server. However, the data that is written to syslog is extremely scarce:

For iOS 12.x :

Aug 20 14:21:35 MSK: %IPS-4-SIGNATURE: Sig:15002 Subsig:1 Sev:50  [192.168.1.1:1066 -> 10.10.10.1:5938] RiskRating:30

Even the name of the signature is missing. Only her SingatureID and SubsibgnatureID.

For iOS 15.x :

Mar  3 11:15:24 MSK: %IPS-4-SIGNATURE: Sig:11020 Subsig:0 Sev:25 BitTorrent Client Activity [192.168.1.1:62809 -> 10.10.10.1:6881] VRF:NONE RiskRating:25

But through SDEEthe same alerts will be presented in a "normal" form, i.e. with detailed information:

IOS-IPS-ROUTER13977992510799519200jabber:tcp25192.168.1.16120810.10.10.15222NONEFa0/1NONE

5. Setup

To implement the version conceived on OSS, only the option with SNMP traps is suitable.
The connection diagram will look like this:

1. IPS catches the attack and sends SNMP-Trap about it. (IOS-IPS immediately sends a log to rsyslogd).
2. We accept SNMP-Trap and send it to syslog.
3. rsyslogd writes the received ladder to a file.
4. LML parses the log, normalizes it, pulls the values ​​from the fields of interest to us, and writes them to the corresponding IDMEF fields (mapping).
5. The normalized event is passed to Manager, which it writes to the database. After that, the event becomes available for viewing through Prewikka.
6. Incoming events from IPS can also be sent to the correlation module (this stage will be considered separately).

5.1 Preparation

You must first install and configure Prelude itself. How to do this has already been described here .
In addition to Prewikka and prelude-manager, we will need prelude-lml and prelude-correlator .
Additional information can also be found on the official Prelude website .

To handle snmp traps, you will need to configure the snmptrapd and rsyslogd daemons (or similar).
The main task is to take snmp traps and write them to a file.
You can do this, for example like this:

snmptrapd.conf

donotlogtraps  no
printeventnumbers  yes
ignoreauthfailure  yes
authCommunity log,execute public
traphandle default /usr/sbin/snmptthandler

rsyslog.conf

if $programname == 'snmptrapd' \
then /var/log/snmptrapd
& ~

5.2 Sensor side setting

The next step is to force our sensor to send snmp-traps every time the signature is triggered, as well as in case of errors on the sensor itself. To do this, globally enable SNMP traps and specify the target server and community where to send them:



In addition, it is necessary to assign the action “Request SNMP Trap” through Event Action for all RiskRating ranges (we don’t want to lose sight of anything) Override:



After these settings, when IPS is triggered, in our log / var / log / snmptrapd events should start to appear:

Apr 18 16:01:59 prelude-server snmptrapd[11106]: 2014-04-18 16:01:59 10.0.0.1 [UDP: [10.0.0.1]:60457->[192.168.0.1]]:#012iso.3.6.1.2.1.1.3.0 24:12:04:52.86#011iso.3.6.1.6.3.1.1.4.1.0 iso.3.6.1.4.1.9.9.383.0.1#011iso.3.6.1.4.1.9.9.383.1.1.1.0 6822393753725#011iso.3.6.1.4.1.9.9.383.1.1.2.0 "07 DE 04 13 16 01 3B 00 "#011iso.3.6.1.4.1.9.9.383.1.1.3.0 "07 DE 04 13 12 01 3B 00 "#011iso.3.6.1.4.1.9.9.383.1.1.4.0 "IPS-SENSOR-01"#011iso.3.6.1.4.1.9.9.383.1.2.2.0 2147516416#011iso.3.6.1.4.1.9.9.383.1.2.3.0 "[ \\x26=?.]/etc/passwd[ \\x26=?]"#011iso.3.6.1.4.1.9.9.383.1.2.4.0 "Unix Password File Access Attempt"#011iso.3.6.1.4.1.9.9.383.1.2.5.0 3201#011iso.3.6.1.4.1.9.9.383.1.2.6.0 1#011iso.3.6.1.4.1.9.9.383.1.2.7.0 "S238"#011iso.3.6.1.4.1.9.9.383.1.2.13.0 0#011iso.3.6.1.4.1.9.9.383.1.2.15.0 "R0VUIC9uZXdzL2luZGV4LnBocD9FTEVNRU5UX0lEPS4uLy4uLy4uLy4uLy4u#012Ly4uLy4uLy4uLy4uL2V0Yy9wYXNzd2QgSFRUUC8xLjENCkhvc3Q6IA=="#011iso.3.6.1.4.1.9.9.383.1.2.16.0 "192.168.1.1:22238"#011iso.3.6.1.4.1.9.9.383.1.2.17.0 "osIdSource=\"unknown\" osRelevance=\"relevant\" osType=\"unknown\" 10.10.10.1:80"#011iso.3.6.1.4.1.9.9.383.1.2.21.0 "InterfaceAttributes:  context=\"single_vf\" physical=\"Unknown\" backplane=\"PortChannel0/0\" ; "#011iso.3.6.1.4.1.9.9.383.1.2.25.0 65#011iso.3.6.1.4.1.9.9.383.1.2.26.0 5#011iso.3.6.1.4.1.9.9.383.1.2.27.0 6#011iso.3.6.1.4.1.9.9.383.1.2.42.0 65#011iso.3.6.1.4.1.9.9.383.1.2.49.0 "vs0"#011iso.3.6.1.4.1.9.9.383.1.3.1.0 "medium"

Here 10.0.0.1 is the IPS-SENSOR-01 sensor address, 192.168.0.1 is the address of the prelude-server where Prelude and snmptrapd are actually installed.

5.3 Configuring LML

Now you need to configure the part where all the “magic” of turning the SNMP-Trap received from the sensor into an event that will be conveniently presented in the graphical interface takes place. The prelude-lml module is responsible for this. It must be installed on the same server where the SNMP traps come and is registered as an agent in the prelude-manager.
It is configured in several stages.

1) We determine the format (and, if necessary, the encoding) of the original log. This is done in the prelude-lml.conf file :

[format=Cisco-IPS]
time-format = "%b %d %H:%M:%S"
prefix-regex = "^(?P.{15}) (?P\S+) (?:(?P\S+?)(?:\[(?P[0-9]+)\])?: )?"
file = /var/log/snmptrapd

With this setting, we specify in advance what the time format of the events coming into the log looks like, the name and address of the analyzer (in this case, the address of the server itself), the name and number of the process that received the log.
Later, with a direct analysis of the event, all these values ​​can be redefined. If the event cannot be parsed by a set of rules, the values ​​defined at this stage will remain.

2) We indicate to which of the incoming events which set of log analysis rules to apply. This is done in the pcre.rules file and looks like this for our example:

regex=snmptrapd;                        include = cisco-ips.rules;

3) You must create the specified set of rules: cisco-ips.rules . In fact, this paragraph deserves to devote a separate article to it. In order not to double the size of the article, I’ll just list the main points:

• a set of rules consists of a sequence of regular expressions;
• we can influence the order of their processing, as well as create “sub-rules” of various nesting;
• in each rule, we can "pull out" from the log the desired value in the form of a variable and enter it in the corresponding IDMEF field. This process is called mapping;
• “Sub-rules” can be called optionally, which allows changing values ​​in events depending on their composition.

Example: by default, we assign to all events the value of the “severity” level equal to “informational”. Further, if the alert sent by the sensor contains a different Attack Severity Rating value, we rewrite our attribute. This allows you to bind in general to any parameter and write events to the database as we please. What level of criticality should SIEM assign to incoming events (with or without corrective actions) is already a more methodological question. Using the rules, you can implement any convenient / liked option.
The following set of rules was developed empirically:

cisco-ips.rules

#####
# Copyright (C) 2013 Vladimir Lapshin 
# Copyright (C) 2013 lei_wulong
#
# This file is part of the Prelude-LML program.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; see the file COPYING.  If not, write to
# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
#
#####
#<>).type=string; \
 additional_data(-1).meaning=Cisco Signature Template:; \
 additional_data(-1).data=http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=$1&signatureSubId=$2; chained; silent;
regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.13(?:\.0)? (\d+); \
 id=5004; \
 target(0).node.address(0).vlan_name=$1; chained; silent;
regex=011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.16(?:\.0)? "(?:0\.0\.0\.0 \[)?([\w:]+?|\d+?\.\d+?\.\d+?\.\d+?)(?:\])?(?::(\d+?))?"; \
 id=5005; \
 source(0).node.address(0).category=ipv4-addr; \
 source(0).node.address(0).address=$1; \
 source(0).service.port=$2; chained; silent;
#ANOMALY DETECTION
regex=011iso.3.6.1.4.1.9.9.383.1.2.16(?:\.0)? "[\d\.\:]+"\#011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.21(?:\.0)? ".\s+adExtraData: numDestIps=\d+\S currentThreshold=\d+\S protocol=\d+; \
 id=5006; \
 target(0).node.address(0).category=ipv4-addr; \
 target(0).node.address(0).address=0.0.0.0; \
 target(0).service.port=0; \
 target(0).service.portlist=0; \
 additional_data(0).type=string; \
 additional_data(0).meaning=osIdSource:; \
 additional_data(0).data=unknown; \
 additional_data(1).type=string; \
 additional_data(1).meaning=osRelevance:; \
 additional_data(1).data=unknown; \
 additional_data(2).type=string; \
 additional_data(2).meaning=osType:; \
 additional_data(2).data=unknown; chained; silent;
regex=\[UDP: \[([^\]]+)\]:\d+->\[[^\]]+\]\]:.012iso\.3\.6\.1\.2\.1\.1\.3\.0 \d?\d?\d?:?\d\d:\d\d:\d\d\.\d\d.011iso\.3\.6\.1\.6\.3\.1\.1\.4\.1\.0 iso\.3\.6\.1\.4\.1\.9\.9\.383\.0\.1.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.1\.1 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.1\.2 "[\d\w\s]+".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.1\.3 "[\d\w\s]+".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.1\.4 "(\S+)".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.1 "(info|low|medium|high)(?:rmational)?".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.2 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.3 "([^"]+)"#011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.4 "([^"]+)".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.5 (\d+).011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.6 (\d+).011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.7 "[^"]+".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.12 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.13 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.16 "([^"]+)".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.21 "\.\s+adExtraData: numDestIps=(\d+). currentThreshold=(\d+). protocol=(\d+) . ".011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.25 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.26 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.27 \d+.011iso\.3\.6\.1\.4\.1\.9\.9\.383\.1\.2\.42 \d+; \
  id=5030; \
  revision=1; \
  classification.text=$5; \
  classification.reference(0).origin=vendor-specific; \
  classification.reference(0).name=$6.$7; \
  classification.reference(0).meaning=ips_id; \
  classification.reference(0).url=http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=$6&signatureSubId=$7; \
  assessment.impact.severity=$3; \
  assessment.impact.type=other; \
  assessment.impact.description=$4; \
  source(0).node.address(0).category=ipv4-addr; \
  source(0).node.address(0).address=$8; \
  target(0).node.address(0).category=ipv4-addr; \
  target(0).node.address(0).address=0.0.0.0; \
  analyzer(0).node.address(0).address=$1; \
  analyzer(0).node.name=$2; \
  analyzer(0).manufacturer=Cisco; \
  analyzer(0).class=IPS; \
  analyzer(0).name=Cisco IPS; \
last;
#>>ALERT>>
#<>ERROR>>
#<>MESSAGE TYPE>>
#<
\[(\d+.\d+.\d+.\d+)\]\]:; \
 classification.text=snmp unknown message; \
 classification.reference(0).origin=vendor-specific; \
 id=5090; \
 revision=1; \
 assessment.impact.severity=high; \
 assessment.impact.type=other; \
 assessment.impact.description=This event was generated by snmptrapd; \
 source(0).node.address(0).address=$1; \
 analyzer(0).node.address(0).address=$2; \
last;
#>>MAIN RULE>>
#EOF

This rule set contains the following principle:

• the incoming log first falls under the general signature of the IPS event: rule 5090;
• optionally checked message type - error / system message / alert: rules from 5080 to 5089;
• if the received message refers to an error, we determine its type: rules from 5040 to 5079;
• if the received message is a signature triggering - we pull out everything that interests us: rules from 5000 to 5039;

Those. Log processing by the rule goes from top to bottom. But part of the rules with chained keys ; silent they do not participate in this processing until they are explicitly given a link from a subordinate rule (with the optgoto key ).

For IOS-IPS, you can also redirect logs to our server and similarly apply this set of rules:

cisco-ios-ips.rules

#
# Copyright (C) 2013 lei_wulong
#
# This file is part of the Prelude-LML program.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; see the file COPYING.  If not, write to
# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
#
#####
##RULES FOR CISCO IOS-IPS###
## id pool = [580-599]
regex=Subsig\:\d+\s+Sev\:25; \
 id=580; \
 assessment.impact.severity=info; \
 silent
regex=Subsig\:\d+\s+Sev\:50; \
 id=581; \
 assessment.impact.severity=low; \
 silent
regex=Subsig\:\d+\s+Sev\:75; \
 id=582; \
 assessment.impact.severity=medium; \
 silent
regex=Subsig\:\d+\s+Sev\:100; \
 id=583; \
 assessment.impact.severity=high; \
 silent
### For IOS 12.4(11)###
regex=(\d+\.\d+\.\d+\.\d+)\s+\d+\:\s+(.+?)\:.+?\%IPS-4-SIGNATURE\: Sig\:(\d+)\s+Subsig\:(\d+)\s+Sev\:(\d+)\s+\[([\d\.]+)\:(\d+)\s+\-\>\s+([\d\.]+)\:(\d+)\]\s+RiskRating\:(\d+); \
 classification.text=$3.$4; \
 classification.reference(0).origin=vendor-specific; \
 classification.reference(0).meaning=cisco_id; \
 classification.reference(0).name=$3.$4; \
 classification.reference(0).url=http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=$3&signatureSubId=$4; \
 id=584; \
 revision=2; \
 analyzer(0).name=Cisco IPS; \
 analyzer(0).manufacturer=Cisco; \
 analyzer(0).class=IPS; \
 analyzer(0).node.address(0).address=$1; \
 analyzer(0).node.name=$2; \
 assessment.impact.type=other; \
 source(0).node.address(0).category=ipv4-addr; \
 source(0).node.address(0).address=$6; \
 target(0).node.address(0).category=ipv4-addr; \
 target(0).node.address(0).address=$8; \
 source(0).service.port=$7; \
 target(0).service.port=$9; \
 additional_data(0).type=integer; \
 additional_data(0).meaning=Signature Severity; \
 additional_data(0).data=$5; \
 additional_data(1).type=integer; \
 additional_data(1).meaning=Risk Rating; \
 additional_data(1).data=$10; \
###FOR IOS 15.1 ###
regex=(\d+\.\d+\.\d+\.\d+)\s+\d+\:\s+(.+?)\:.+?\%IPS-4-SIGNATURE\: Sig\:(\d+)\s+Subsig\:(\d+)\s+Sev\:(\d+)\s+(.+?)\s+\[([\d\.]+)\:(\d+)\s+\-\>\s+([\d\.]+)\:(\d+)\]\s+VRF\:(.+?)\s+RiskRating\:(\d+); \
 classification.text=$6; \
 classification.reference(0).origin=vendor-specific; \
 classification.reference(0).meaning=cisco_id; \
 classification.reference(0).name=$3.$4; \
 classification.reference(0).url=http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=$3&signatureSubId=$4; \
 id=585; \
 revision=2; \
 analyzer(0).name=Cisco IPS; \
 analyzer(0).manufacturer=Cisco; \
 analyzer(0).class=IPS; \
 analyzer(0).node.address(0).address=$1; \
 analyzer(0).node.name=$2; \
 assessment.impact.type=other; \
 source(0).node.address(0).category=ipv4-addr; \
 source(0).node.address(0).address=$7; \
 target(0).node.address(0).category=ipv4-addr; \
 target(0).node.address(0).address=$9; \
 source(0).service.port=$8; \
 target(0).service.port=$10; \
 additional_data(0).type=integer; \
 additional_data(0).meaning=Signature Severity; \
 additional_data(0).data=$5; \
 additional_data(1).type=integer; \
 additional_data(1).meaning=Risk Rating; \
 additional_data(1).data=$12; \
 additional_data(2).type=string; \
 additional_data(2).meaning=VRF; \
 additional_data(2).data=$11; \
last;

After all the above manipulations, we get this result:



In the console, triggers from all IPS sensors appear. The screenshot above shows the grouping by source and destination addresses. Here there are events from IPS-modules and applications, as well as from routers with IOS-IPS enabled (this is not visible in the screenshot due to “obfuscation” technologies). We can group / filter according to all the values ​​that were determined during processing by our set of rules.
Accordingly, in any event, you can "fail" and see the details:

6. Correlation Heart bleed

The final touch in the setup will be the part that distinguishes event viewers from SIEM: correlation.
For an example of setting up the correlation rule, let’s take a recent vulnerability in the OpenSSL library - HeartBleed .

Cisco has a signature that can catch an attempt to exploit this vulnerability: tools.cisco.com/security/center/viewIpsSignature.x?signatureId=4187&signatureSubId=0
The signature number is 4187.0, it is called “OpenSSL Information Disclosure”.
By itself, triggering this signature will not yet mean that the vulnerability has been exploited, because IPS does not know if the attacked host is vulnerable or not. But SIEM may well answer this question.
The general principle of the correlation rule is as follows: if the above event from IPS arrives in SIEM, then SIEM itself checks for the HeartBleed vulnerability on the target host. If the host is vulnerable, a separate correlation event will be generated.
The rule itself is as follows:

#
# Copyright (C) 2014 Vladimir Lapshin 
# Copyright (C) 2014 lei_wulong
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; see the file COPYING.  If not, write to
# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
#
import re
from PreludeCorrelator.pluginmanager import Plugin
from PreludeCorrelator.context import Context
import time
import subprocess
localtime = time.localtime()
timestamp = time.strftime('%d %b %H:%M:%S', localtime)
print str(timestamp) + ' HeartBleed plugin  (correlator) INFO: Starting...'
class heartbleed(Plugin):
    def run(self, idmef):
        if not idmef.match('alert.classification.text', re.compile('^OpenSSL Information Disclosure$|^Other security event$')):
            return
        addr = idmef.Get('alert.target(*).node.address(*).address')
        if not addr:
            return
        port = idmef.Get('alert.target(0).service.port')
        if not port:
            port='443'
        script = str('python2.6 /etc/prelude-correlator/heartbleed.py ') + str(addr).strip('[\'\']') + str(' -p ') + str(port)
        print script
        PIPE = subprocess.PIPE
        p = subprocess.Popen(script, shell=True, stdin=PIPE, stdout=PIPE, stderr=subprocess.STDOUT, close_fds=True)
        while True:
            s = p.stdout.readline()
            if not s:
                break
            if re.findall('server is vulnerable', s):
                ctx = Context(("HEART_BLEED", addr), update=True, idmef=idmef)
                ctx.Set("alert.classification.text", "HeartBleed vulnerability detected")
                ctx.Set("alert.correlation_alert.name", "HeartBleed vulnerability detected")
                ctx.Set("alert.assessment.impact.severity", "high")
                ctx.Set("alert.classification.reference(0).origin", "vendor-specific")
                ctx.Set("alert.classification.reference(0).name", "CVE-2014-0160")
                ctx.alert()
                ctx.destroy()
                print 'Vulnerable!'
                return

In this example, to check for the vulnerability, this script is used: gist.github.com/sh1n0b1/10100394 . It should be located in the same directory as the correlation plugin. For the above example, this path is /etc/prelude-correlator/heartbleed.py.

Also, do not forget to make an exception on the IPS sensors for 4187.x signatures and the source address where Prelude is installed , otherwise we will get a recursion: attack -> correlation rule, which is also detected by IPS (we use essentially the same heartbleed) -> new IPS alert -> correlations -> etc. This can be done through Event Action Filter.
Or you can exclude recursion in the rule itself by adding:

if idmef.match("alert.source(0).node.address(0).address", re.compile("0\.0\.0\.0")) # <- Prelude-Correlator addr
    return

But if you do not configure Event Action Filter, our IPS will respond to the verification itself performed by Prelude. If its sensor (check) blocks it, we will not be able to check for a vulnerability.

After setting the rule, when the Cisco 4187.0 signature is triggered, we get the following result:



In fact, this means that a host susceptible to this attack has been attacked. The correlation rule in the example waits for events called '^ OpenSSL Information Disclosure $ | ^ Other security event $'. Of course, you can not be limited to one event from Cisco IPS. By the same principle, IPS correlation of any other vendors connected to the system can be performed.
You can also bind to the login event on the web server. If it is vulnerable, it means the account used to log in is potentially compromised.
The rule described in this article is just an example of a special case of application for the latest current events. All other Wishlist are limited only by imagination and python (read - not limited by anything). For example, in the proposed script, you can beat various scenarios: check only by your resources (only gray addresses / pool of external addresses), change the ip and port of the “victim” if our resource is behind NAT, etc.

7. Epilogue

In conclusion, it is also worth noting about the possibility of collecting events through SDEE.
Because In this article, the configuration for the OSS version of Prelude was considered, then IPS and Prelude had to be friends through SNMP (for IPS modules / applications) and syslog (for IOS-IPS). But, as mentioned in the 4th section , all of these devices can work through SDEE. At the same time, it becomes possible to receive events from IPS in a uniform form with the most complete information about each alert. To do this, you need an SDEE connector, which is present only in the commercial version of Prelude.

Other differences between the commercial version of PreludePro:

• performance;
• the ability to connect slave managers;
• add. functions in Prewikka (authentication via LDAP, the ability to embed your own commands in the web-interface, etc.);
• дополнительные модули (log-management, система инвентаризации, и т.д.)

Again it turned out voluminously, tried to “squeeze” as best he could.
Hope it was interesting and helpful.
Good luck in identifying incidents!
_____
Materials used in the article:
CSM User Guide www.cisco.com/c/en/us/td/docs/security/security_management/cisco_security_manager/security_manager/4-6/user/guide/CSMUserGuide.html
IME Notification Example: www .cisco.com / c / en / us / support / docs / security / ips-4200-series-sensors / 111659-ips-email-ime-config.html
IOS IPS events via IME: www.cisco.com/c/ en / us / support / docs / security / intrusion-prevention-system / 113576-ptn-113576.html
Prelude OSS official page www.prelude-ids.org
Overview of the Prewikka interface: is-systems.org/siem/interface