OSSIM + SEC
I don’t know about you, but for me in the Alienvault OSSIM (USM) product there was always a lack of flexibility in setting correlation rules. Those. there is such an opportunity, and the solution is positioned as a “combine” as part of which there is also a SIEM component. But the possibilities of this SIEM in terms of correlation are currently very, very limited. I sincerely hope that in future releases, developers will add at least some kind of lookup / active lists, and at least the possibility of correlation not only in the fields DST_IP, SRC_IP, DST_PORT, SRC_PORT.
In the meantime, I came up with the idea of using SEC (Simple Event Correlator) to expand the functionality of the correlation of IS events in OSSIM / USM.
The solution architecture is shown in the figure below.
')
A SEC deployed on an OSSIM server or on a stand-alone server receives a copy of the logs from text files processed by OSSIM PLUGINs (in FILE 5). Based on the analysis performed, the SEC generates events and alerts that are written to a file (FILE 6). This file is read by a specially designed PLUGIN for OSSIM. Thus, the events generated by the SEC can be seen in the OSSIM console, prioritize them, perform alerts, etc.
Of course, in this solution, the drill-down search for events that generated the SEC alerts will be difficult. To compensate for this shortcoming, it is possible in the alerts generated by the SEC to include copies of the original events that generated them (alerts).
Further I will sort a small example.
The example is very primitive and created only to demonstrate the functionality. In further development, the functionality that will put the "raw events", on the basis of which the SEC correlation rule worked, into the userdataX fields of the OSSIM system. Thus, opening an event in the OSSIM interface, which is an incident generated by the SEC, you can immediately see the source events that caused it.
Let's look at an example. Let's say we want to register events for the modification of suricata signatures.
The trigger for this alert will be two events following each other:
Suppose that auditd is already configured as necessary, to record events for changing the configuration file suricata.yml. Then, to solve this problem you need:
Here, everything is pretty trivial. To solve the problem, I use the following configuration
Accordingly, the audit log and surikat logs (only stop and start) are sent to the /var/log/sec_input.log file. This file reads SEC.
Contents of the main SEC configuration file (/ etc / default / sec):
It specifies the file that reads the SEC (input parameter), the file that contains the correlation rules (the conf parameter), and the file to which the SEC writes a response log and just informational messages (the log parameter).
The file with the SEC rules (/etc/sec.conf) looks like this:
It contains only one rule, which correlates two events from the sources, as shown in the figure below:
The OSSIM plugin is created to handle events generated by the SEC. For the convenience of processing them, they (events) should have one format.
This plugin is developed as a regular plugin for reading text files, as described, for example, here. If you are not involved in the development of plug-ins, I recommend to read the article at a quick reference to make everything described below have meaning for you.
The SEC event format for description in the plugin for this example I took "from the head." You can make it any, add or remove fields.
What is a uniform format for? After all, is it possible to add regexp to the plug-in configuration file for each type of SEC event?
Yes you can. However, I am a supporter of unification. In the presence of a single format, all that will be needed to add new types of SEC events is to add one line of description to the corresponding sql file. Adding new event types will be a very simple process.
So, the format is as follows (without the syslog header, of course):
event_name = <event name> src_ip = <address> dst_ip = <address> user = <user name> msg = <informational message itself>
SEC message example:
The sec.conf plugin configuration file looks like this:
Configuration file sec.sql:
Import the .sql file:
Enable the plugin:
And enjoy the result:
And more:
In the meantime, I came up with the idea of using SEC (Simple Event Correlator) to expand the functionality of the correlation of IS events in OSSIM / USM.
The solution architecture is shown in the figure below.
')
Brief description of the solution
A SEC deployed on an OSSIM server or on a stand-alone server receives a copy of the logs from text files processed by OSSIM PLUGINs (in FILE 5). Based on the analysis performed, the SEC generates events and alerts that are written to a file (FILE 6). This file is read by a specially designed PLUGIN for OSSIM. Thus, the events generated by the SEC can be seen in the OSSIM console, prioritize them, perform alerts, etc.
Of course, in this solution, the drill-down search for events that generated the SEC alerts will be difficult. To compensate for this shortcoming, it is possible in the alerts generated by the SEC to include copies of the original events that generated them (alerts).
Further I will sort a small example.
The example is very primitive and created only to demonstrate the functionality. In further development, the functionality that will put the "raw events", on the basis of which the SEC correlation rule worked, into the userdataX fields of the OSSIM system. Thus, opening an event in the OSSIM interface, which is an incident generated by the SEC, you can immediately see the source events that caused it.
Example
Let's look at an example. Let's say we want to register events for the modification of suricata signatures.
The trigger for this alert will be two events following each other:
- an auditd daemon event indicating changes to the /etc/suricata/suricata.yml file;
- event from the suricata log about the start of the suricata service.
Suppose that auditd is already configured as necessary, to record events for changing the configuration file suricata.yml. Then, to solve this problem you need:
- configure the auditd and suricata log redirection to a file that reads SEC, say /var/log/sec_input.log
- configure the SEC rule that generates an alert when the above condition is met;
- create an OSSIM plugin that reads the file in which the SEC writes alert logs, /var/log/sec_output.log.
Configure Redirects
Here, everything is pretty trivial. To solve the problem, I use the following configuration
syslog-ng (/etc/syslog-ng/syslog-ng.conf): source s_audit_file { file("/var/log/audit/audit.log"); }; source s_suricata_file { file("/var/log/suricata.log"); }; destination d_sec { file("/var/log/sec_input.log"); }; log { source(s_ audit_file); source(s_suricata_file); destination(d_sec); }; Accordingly, the audit log and surikat logs (only stop and start) are sent to the /var/log/sec_input.log file. This file reads SEC.
SEC Setup
Contents of the main SEC configuration file (/ etc / default / sec):
RUN_DAEMON="yes" DAEMON_ARGS="-conf=/etc/sec.conf -input=/var/log/sec_input.log -pid=/var/run/sec.pid -detach -log=/var/log/sec_output.log" It specifies the file that reads the SEC (input parameter), the file that contains the correlation rules (the conf parameter), and the file to which the SEC writes a response log and just informational messages (the log parameter).
The file with the SEC rules (/etc/sec.conf) looks like this:
type=PairWithWindow ptype=RegExp pattern=syscall=5\s+success=yes.*key="suricata-file" desc=Suricata config modified action=logonly ptype2=RegExp pattern2=threads initialized, engine started desc2=src_ip=NULL dst_ip=NULL user=NULL msg="Suricata restart initiated with new config file" action2=logonly window=600 It contains only one rule, which correlates two events from the sources, as shown in the figure below:
OSSIM plugin
The OSSIM plugin is created to handle events generated by the SEC. For the convenience of processing them, they (events) should have one format.
This plugin is developed as a regular plugin for reading text files, as described, for example, here. If you are not involved in the development of plug-ins, I recommend to read the article at a quick reference to make everything described below have meaning for you.
The SEC event format for description in the plugin for this example I took "from the head." You can make it any, add or remove fields.
What is a uniform format for? After all, is it possible to add regexp to the plug-in configuration file for each type of SEC event?
Yes you can. However, I am a supporter of unification. In the presence of a single format, all that will be needed to add new types of SEC events is to add one line of description to the corresponding sql file. Adding new event types will be a very simple process.
So, the format is as follows (without the syslog header, of course):
event_name = <event name> src_ip = <address> dst_ip = <address> user = <user name> msg = <informational message itself>
SEC message example:
Sun Sep 3 23:26:06 ossim_server: src_ip=NULL dst_ip=NULL user=NULL msg="Suricata restart initiated with new config file" The sec.conf plugin configuration file looks like this:
[DEFAULT] plugin_id=9006 [config] type=detector enable=yes source=log location=/var/log/sec_output.log create_file=false process= start=no stop=no restart=no startup= shutdown= [translation] suricata_conf_change=1 [0001 - Suricata Modified Config] event_type=event regexp="(?P<DATE>\w+\s+\w+\s+\d+\s+\d+\:\d+\:\d+)\s+(?P<HOST>\S+)\:\s+event_name=(?P<EVENT_NAME>\S+)\s+src_ip=(?P<SRC_IP>\S+)\s+dst_ip=(?P<DST_IP>\S+)\s+user=(?P<USER>\S+)\s+msg=(?P<MSG>.*)" plugin_sid={translate($EVENT_NAME)} device={$HOST} username={$USER} src_ip={$SRC_IP} dst_ip={$DST_IP} userdata1={$MSG} Configuration file sec.sql:
DELETE FROM plugin WHERE id = "9006"; DELETE FROM plugin_sid where plugin_id = "9006"; INSERT IGNORE INTO plugin (id, type, name, description) VALUES (9006, 1, 'sec', 'Simple Event Correlator'); INSERT IGNORE INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (9006, 1, NULL, NULL, 'SEC: Suricata Config Changed'); Import the .sql file:
ossim-db < /usr/share/doc/ossim-mysql/contrib/plugins/sec.sql Enable the plugin:
And enjoy the result:
And more:
Source: https://habr.com/ru/post/340042/
All Articles