I was invited by the ISSA Belgium chapter to talk last night about log management & SIEM (“Security Information and Event Management“). This is a very interesting topic but almost everything has been said (good as bad) on SIEM. I decided to innovate and to use some articles posted in this blog as practical examples of fraud detection. After the theory, some practice is always welcome! Let’s make your logs more valuable…
Fraud can be defined as “a deliberate deception, trickery, or cheating intended to gain an advantage“. This term is often closely linked to the world of finances. That’s why I prefer to use the word “suspicious“. An event can be flagged as suspicious if it does not follow strict baselines. Four practical examples of suspicious activities were discussed:
- MySQL Database changes
- USB stick detection
- Rogue access to resources
- Mapping events to Google Maps
Each example was reviewed as a quick recipe to detect the suspicious event. All of them reported by OSSEC. The goal was to explain how to gain more visibility and more value from your logs at… an affordable price, read – without an (expensive) SIEM solution. Even, if smallest organizations don’t have budgets and resources, they can implement solutions to increase their security.
The presentation is available on Slideshare.com.
Hey Eric,
Hehe, Well known quote from Paul 😉
Your remark does not only affect a SIEM environment, every time you perform a change (new application, new feature), potentially you can add security holes…
Hello Xavier,
Thanks for the moderation and the reply 🙂
More remarks to feed the debate :
“The bunch of scripts based on free tools is not to replace a real SIEM solution but to prove that, even small organizations, can have “something†to detect suspicious activities.”
Free, or commercial tools, will maybe help them to detect some basic suspicious activities (virus, ids alert, basic triggering), but I think you remember the XMass present delivered to Exploit-DB and BackTrack Linux servers.
Take a look a the Exploit-DB server process list. OSSEC was installed (maybe badly configured), host-deny.sh, firewall-drop.sh, fail2ban, etc. They have been owned & exposed. So whatever the “tools” you have, if you don’t know or assess your risks and vulnerabilities on regulary base, you will still continu to be owned.
As always, design, processes, procedures, organisation and then tools 🙂
“Young padawan, don’t forget: Lack of focus leads to sloppiness, sloppiness leads to misconfiguration, and misconfiguration leads to compromise.” –> Pauldotcom 🙂
Regards
Hello Eric,
Thank you for the comments. Some slides will be updated!
About the open source(free) vs commercial solutions, both have risks and impacts! Your infrastructure changes almost every day. Whatever the solution used, you have to update it to reflect the changes. Can we dream of a self-provisional system with enough intelligence to adapt itself?
The bunch of scripts based on free tools is not to replace a real SIEM solution
but to prove that, even small organizations, can have “something” to detect suspicious activities.
/x
Very interesting !
Hello XME,
Good presentation, I would like to share with you some experiences and remarks.
P°28 of the presentation, the graph goes directly from “Correlation” to “Incident Handling”.
All events are not incidents, you should go through event management process, to categorize your events as Incident, or Problem, or Change. If your hard disk monitoring is generating a Warning (80% usage trigger for example), is this an Incident or only a request to adapt your capacity storage to the demand (Change)? Everything is not Incident.
SIEM or traditional monitoring tools are designed to handle events, not incidents. The incidents are only the result of your definition on what is an incident for you.
P°30 SIEM are expensive. I agree for SMB SIEM are expensive. I have play, and continue to play, with Prelude-IDS (SIM), with OSSEC and other open-source tools, but these tools have not the level of maturity of commercial tools (maybe by a motivated and wide community).
Developing log parsing regex rules, and reviewing these rules, each time the vendor update the product, is expensive. Developing rules “correlation” with regex, perl, whatever, in shell is expensive. To not have integrated event weighting mechanism in front off business reality is time consuming. To not know id the open-source software will be maintained in the future is a risk.
P°38, this is not correlation, this is simply triggering. Correlation is a little more complex than triggering (time, space, occurrences, information value, etc). All this factor have to be analyzed, in the correlation mechanism, to provide useful events.
If you have any comments don’t hesitate to contact me.
Regards
Great presentation XME! There’s a lot of potential using SIEM, but also people need to be educated to understand what’s present in their logs and how to handle and act on it. Cheers!