Defining event rules in Simple Event Correlation

Event correlation is the art of taking data from host or applications logs and discerning useful information from 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.

Requires Free Membership to View

More on Simple Event Correlation:
Simple Event Correlation installation and configuration

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:



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 and was destined for port 25, the resulting description would read:

Port scan started from source 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.

More open source, Linux security tips:
Firefox plug-ins: Download or tune out?

OSSEC: The server and agent model

Host intrusion detection with OSSEC

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.

This was first published in November 2006

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.