Squeezing out best from SIEM

Squeezing out best from SIEM Rules

-Ashok S. Patil

Well you have that product, SIEM, very efficient and impressive for features and it boasts a lot!!

It is good to have an intelligent event and log analysis tool which correlates thousands of events, otherwise, impossible to manually sort out and analyze, that too in near real time.

But here is a caveat.

All security products have one inherited vulnerability – they all are prone to human errors!

They are prone, because of the human nature, it is common psychology that people tend to think and apply more of “advanced” knowledge even when things are too simple, and leave room for mistakes – then with the same complexity, these mistakes are gradually eliminated, ultimately arriving to the simplicity, that they were required to keep initially.

SIEM products are no exception. There are lot of things to do and there are lot not to do too.

This article will focus on these – it will be impossible to write everything down here, else I shall end up writing a whole book!!

(*Yeah these are excerpts from my forthcoming book on Information Security, a book that will stand apart, with issues that remained, untouched so far.)

Nonetheless, I shall mention some common human errors (mistakes, actually!!).

Here is number one, not understanding basic terminology. It is worth to go through the Glossary of terms before you actually start to work on it. The Glossary of terms here, does not mean a standard Information Security Glossary, normally found elsewhere like websites of ISACA, (ISC)² etc.

Companies have their own terminology. One good example is the term “risk”.

People tend to mix their basic security understanding with that which does not apply to a specific Information Security product, particularly management and analysis software like SIEM.

Being more precise, the basics do remain the same but the terminology and words may change or have different meanings!!

Well, as a first step, you have taken your IT infrastructure, and its architecture into consideration, but you also need to understand the logic, how SIEM will correlate events.

Number two, it is sometimes seen that people put AND in place of OR and vice versa, particularly, when using negative parameters as inputs. Here your good old study of Logic gates will help you.

Avoid negative input values (e.g. not equal to), for analysis, instead treat it like inverted inputs (bubbled gates) and convert the logic gate itself into resultant logic gate using de Morgan's Theorem.

A . B = (A+B)                                               A + B = (A.B)

Consider you wanted to filter out events which have values “attack is equal to blocked” or “attack is equal to stopped”.

Check for what is desired output for trigger and create a truth table, like the one given below

The desired is, if either Blocked or Stopped is false, it should return a value true (1)

Here, see that when events have both “Blocked” and “Stopped” values equal to TRUE, only then the incident will not be triggered. Anyways we don't want to miss a single true positive, do we? And is important even if we get a few false positives.

Compare this table with basic logic gates, and you will have a solution.

“attack is equal to blocked” NAND “attack is equal to stopped”
 

But since you do not have NAND operation directly available, you may use the following -

“attack not equal to blocked” OR “attack not equal to stopped”

That is equivalent to - 

“attack is equal to blocked” NAND “attack is equal to stopped”

NAND gate truth table -   (A.B) 

                                        A + B = (A.B)

    converting this to our example -

Be aware that such methods can be eliminated, instead use of something like event filters and look-up tables serve the very purpose of filtering out false positives, in fact they are meant for the same.

“Any intelligent fool can make things bigger and more complex. It takes a touch of genius – and a lot of courage to move in the opposite direction.” - Albert Einstein

Copy the system correlation rules as templates to further customize it, and depending on your requirement start “fine tuning” them. It should strictly be “fine tuning” and not “tuning” else you will mess up with the rule.

What is “fine tuning”? Well I have elaborated this below.

A couple of years ago, in a school, kids were asked to watch a series of programs on "National Geographic" channel, my younger daughter was one of them. During the same, the local cable operator had messed up with frequencies of transmission resulted in scrambled channels (The TV is a bit old fashioned!). She herself tried to "tune" the channel, finally she thought she did it, to later understand that it was an English movie channel playing a science fiction at that time.

So she started again to tune to the right channel and finally got success.

This is called as "Tuning".

When it looked like she had successful in doing so, later when I was back home from office, I found that the picture and the sound quality of that channel was not as good as it used to be. So I started to set its frequency accurately, and yep! the channel was playing correctly.

This is "Fine Tuning"

Number Three, in SIEM (and also in Risk Analysis), "Quantitative Analysis" should never be used, where you will have to go through hundreds of false positive incidents and then decide how to "tune" the correct rule, this tuning process may continue for a stretched time, improvements will be there but at a very slow rate.

"Qualitative Analysis" on the other hand, is a good practice, where you use "System Rules" (these are as good as preset channels for your TV or bookmarks for your internet browser) as templates and then fine tune them using something like "Event Filters" and "Table Look-up" instead of tampering with the basic template, unless it is extremely necessary and there are no alternatives.

Not following this will make you prone to make mistakes.

Remember a general rule “As the complexity increases so does the probability of problems”

A classic example is using “network traffic” in exploit related rules though traffic direction is not important for security monitoring, it is still incorporated, inviting many false positives, and also missing out true positives.

You never know which traffic will be proved to be malicious generated by viruses, Trojans, spybots, adwares etc. and other malicious activities(intentional or unintentional).

Here again I repeat, better to have a few false positives rather than missing out a single true positive incident. 

On the other hand too many false positives will make a security analyst miss out incidents due to the difficulty in picking up the right one, he will have to analyze everything, and finally drop out many incidents!!

Good old “Garbage in garbage out” still stands firm!!

If the rules have been all messed up, correlation engine will receive the “garbage*” and its output will essentially be “garbage”, no matter how good the SIEM product is.

On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.                                                  —Charles Babbage, (Passages from the Life of a Philosopher)