Week of OSSEC Day 7: Developing a Workflow

Yesterday, I discussed strategies for tuning OSSEC. In this final installment of my OSSEC series, I’m going to discuss one effective method for using the information OSSEC gives you. Developing a workflow allows you to focus on what is most important immediately, while saving other events for future analysis.

A general OSSEC workflow can be broken down as follows:

  1. Events you need to see immediately. Daily e-mail alerts should be reserved for those alerts which cannot wait until the next day and those alerts which are rare. Getting alerts for inconsequential events will result in your brain classifying them as not important. When this happens, you won’t even bother looking at them, anymore. One example of this is the Windows registry alerts. Are you acting on all of the Windows registry alerts you receive? Do you know what each one is trying to tell you? If not, you may not want to be receiving them in real-time.
  2. Events you need to see daily. These events are such that a 24 hour response would not be too long to act on, or in the case of weekends, maybe 24-36 hours. An example of this event may be a user added to the Domain Users group, while a user added to the Domain Admins group would be reserved for an immediate alert.
  3. Events you need to see weekly. Weekly events are those which tend to be low-risk yet which could cause continued problems if unnoticed. Perhaps a new application being installed fits into this category, unless of course you expect that no applications should generally be installed. Viewing these types of events on a weekly basis allows for a pulse-check on the environment, without which you may not see a situation becoming a larger issue.
  4. Events you need to see monthly. Monthly events are best suited for report-friendly information. These events are not critical in nature but could cause problems down the road with auditors, for example. A monthly report could be used to reconcile new users added to the system with help desk requests or patches installed with a monthly patch window.
  5. Events you need to see quarterly. Quarterly events are those which can be used to identify trends. These are events which, when viewed in context with previous trend reports, identify low-risk patterns. Using rule severity as a guide, these might be severity 3 or lower events.

An OSSEC GUI is critical in these activities. Examples of possible GUIs are the OSSEC WebUI, Splunk, OSSIM and PicViz. The important thing is to pick one which works well for your needs, not necessarily the one that is most popular.

Reading the “Week of OSSEC” series from day one forward will give you not only examples of how to technically use OSSEC, but how it can be used in a way which works best for you. I hope you have enjoyed reading it as much as I have enjoyed bringing it to you.

Tagged with:
2 comments on “Week of OSSEC Day 7: Developing a Workflow
  1. Harika Tandra says:

    Hi Michael,

    I have started deploying OSSEC for my group last week. Your blog posts were very helpful. Thank you !!
    I am able to write new rules to tune ossec and reduce noise but I am not able to figure out how you group alerts by level to be sent once a day/week/month as you suggest in this blog post. I would appreciate any pointers you can provide regarding this.

    Thanks again.

    Harika Tandra.

  2. Hello Harika,

    Sorry if there was a misunderstanding, but what I meant by the post was that you can use some sort of GUI to view the events that you would not normally get alerted on. OSSEC can also be configured to run daily reports, and you could cron this to match the workflow I mentioned in the post, but the better solution is to use a good GUI front-end for that.


Leave a Reply

Your email address will not be published. Required fields are marked *