Event correlation is the art of taking data from host or applications logs and discerning useful information from...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
that data. Many organizations consider event correlation a complicated and costly exercise with expensive tools and time-consuming configuration, but tools exists that can simplify the process.
SEC (Simple Event Correlator) is one such tool. In part one of this tip I explained how to install and run SEC. In this part, I will briefly introduce the rules SEC uses to match and correlate events.
As mentioned in part one, SEC can read events from files, named pipes or standard input. A common model is SEC monitoring the output from a syslog daemon; in the Linux world, an example would be the contents of /var/log/secure or /var/log/messages. You define rules that match events in the output and then perform some action; for example, you can send an email or text message.
You can see an example of one of these rules below:
type=Single ptype=RegExp pattern=PORTSCAN DETECTED FROM (\S+) TO \S+:(\d+) desc=Port scan started from source $1 to target port $2 action=pipe '%t: %s' /bin/mail -s "Snort Port scan Alert" root@localhost
The first start of the rule is the type, in this case Single. The Single rule type is the simplest type of rule. It matches an event and then executes an action immediately.
Some other rule types are:
SingleWithSuppress - This rule type matches an event, executes an action immediately and then ignores any other matching events for a specified period.
SingleWithThreshold - This rule type matches events during a specified period, and if a specified threshold of events is reached, an action is executed.
Pair - This rule type matches an event and executes an action immediately. All other events are ignored until a second specified event is matched. This matched event executes a further action.
PairWithWindow - This rule type matches an event and waits for a specified period for another event to match. If no event is matched in that period, an event is executed. If an event is matched in the period, an alternative event is executed.
You can read about other rules types in the SEC man page or at http://kodu.neti.ee/~risto/sec/sec.pl.html.
The next line in the rule, ptype, specifies the type of pattern matching being used, in this case RegExp for Regular Expression. This tells SEC to treat the content of the next line, pattern, as a regular expression. You can also read about other ptypes in the SEC man page.
The next line, the pattern, uses a regular expression (as indicated by the ptype statement) to match incoming events. You can see in the pattern line above that it matches Snort port scan alerts. You can also see the use of two sets of bracketed expressions.
When SEC matches the rule against an incoming event, the portions of the event matched by the bracketed pieces of the expression are stored as variables. Each variable is assigned a value starting with $1, then $2 and so on. In this case, the $1 is the source IP address of the port scan and $2 is the destination port. SEC can use these variables in a resulting action, to perform some evaluation, or even in another rule.
The next line, desc, assigns a description to the rule; you can use this description in an action. You can see that the desc line also contains the two variables we assigned on the previous line, $1 containing the IP address and $2 the port. So in the event of a port scan came from an IP address of 192.168.0.1 and was destined for port 25, the resulting description would read:
Port scan started from source 192.168.0.1 to target port 25
The last line, action, defines the action that SEC will execute if an event is matched. In this case, I've used the pipe action that outputs text to a shell command, /bin/mail here. The event text takes advantage of two special parameters, %t and %s.
The %t parameter represents the textual timestamp (on most systems this is what is returned by the date command). The %s parameter returns the event description (as defined by the desc line). This event text is then mailed to the email address root@localhost. There are other special parameters you can use and you can define your own. Refer to the SEC man page for more details.
SEC can initiate a number of other actions, and you can specify more than one action by separating them with semi-colons. Other actions include writing to files, calling shell commands and more complex actions like evaluating the contents of an event.
So in summary, our very simple SEC rule would be triggered by the appearance of an event that matched the specified pattern (a Snort port scan alert in this case), and the source IP and destination port of the scan would be captured as variables and inserted into the description of the matched event. The description of the matched event would be emailed to the root user with a subject of Snort Port scan Alert.
This example of a rule is simple, but the combination of different rule types, actions and other features like contexts can make SEC a powerful tool for event correlation. Multiple events can be correlated and acted on, complex patterns of events can be monitored for and the data from events can be manipulated and acted upon.
The best place to start learning about SEC rules is the man page, also located online at http://kodu.neti.ee/~risto/sec/sec.pl.html . You can also refer to a number of sources like http://www.bleedingthreats.net/sec/ that contain examples and samples of SEC rules. So go forth and correlate.
What other security tips do you want to see? Still have questions? Email us and let us know.