Security Event Management

If you would like more information sign up for our Webcast below!


What is Security Event Management?

Security Event Management (SEM) is often referred to as the brain of the SIEM solution. To manually analysis millions or billions of logs would require a significant investment in head count. The SEM portion of a SIEM solution will allow automated analysis or the billions of logs looking for unusual behaviours.

To be considered a true SEM, the solution should be able to monitor for behaviours, rather than individual events. A number of solutions will be able to correlate events, but not all correlation is the equal in capability.

A Correlation or Behavioural engine should be able to look for multiple TYPES events. For example some SEM vendors will say they do correlation, when they can look for multiple failed logins, that is to say, five failed logins within a specified timeframe, say 60 seconds. While this is useful, it is not true correlation.

Stateful based correlation is the ability to track multiple types of events, for example, five failed logins, followed by a successful login, followed by a new user created, followed by the user added to a privileged group. This is true Correlation, looking for a collection of events that make up a suspicious behaviour and is critical when you are taking many billions of logs and filtering them down to tens or hundreds of behaviours they need to b investigated by the security or compliance team.

Many SIEM projects have failed because the SOC, NOC or platform owners have been flooded with alerts from the SIEM after being switch on. The more intelligent your behavioural engine is, the less likely you will be overloaded with false positives, and he more likely your project will succeed.

Tip #1 - Ask your potential vendor if their Correlation Engine can identify behaviours based on multiple event types occurring in a specified order.

It is great to have a powerful behavioural engine, however if it takes a genius, or vendor professional services to create new correlation/behavioural rule then the system becomes infinitely less useful. If the success of your project rests on how easy and intuitive it is to identify new behaviours it is critical that your team can create new rules on the fly.

Tip #2 - Ask your potential vendor how easy it is for your team to create new correlation rules to identify unexpected behaviours.

Once you have identified the suspect behaviour you need to inform the appropriate team. This is likely to be a Security Operations Centre (SOC) or Network Operations Centre (NOC) in a large enterprise or the Platform Owners in smaller environments.

The challenge is notification. Most SEM solutions will allow email Alerts to be generated; however these can overload an inbox, particularly true in large environments. A better option would be to populate a dashboard with colour coded alerts indicting the suspect behaviours have been identified.

The dashboard should allow you to see trends of events, for example, every environment on the planet will have failed logins within the network. Getting an email alert every time someone fails to login would quickly overload your inbox, if however you placed this alert in to a trended dashboard you can keep an eye on the failed logins as they occur and look for peaks in the activity, which would typically be an indication of something abnormal happening. Stay away from SEM solutions that require you to run reports to populate a dashboard, no team in the world has time to sit there all day continually running reports looking for suspect behaviours, the dashboard should be automatically generated as the events are processed.

Tip #3 - Any solution that is heavily Reports based, as opposed to being Dashboard based becomes an operational nightmare.

| Page 1 | Page 2 |

| SIEM Overview | SIM | SEM | SIEM Tips | SIEM Vendors | Top 10 SIEM Criteria |

Please read our "Terms" before making a comment.
blog comments powered by Disqus
To The Top