On 17 June 2016 at 14:54, JDS <[email protected]> wrote: > The impression I get is that the answer is "tune your system to ignore or > suppress alerts from known OK system events" > > So, a rule that suppresses the Puppet apply events. > > I'm not saying it's gonna be easy, but that's the approach I'm starting to > take atm. > > I've had this same basic question about Snort and OSSIM (a project that > incorporates OSSEC) and that's the gist of the responses I've gotten.
I'm going to throw my 2p in because I'm coming from the other side of things. OSSEC is a system audit tool. It lets you know something has changed - ideally, something you care about whether it changed. For me, it's a tool to let me know whether: o an attacker has changed something on one of our servers o a sys-admin has made a change on one of our servers o a developer has made a change on one of our servers If an attacker makes a change, that is Very Bad. If a sys-admin makes a change, it may or may not be Very Bad. Is it an *authorised* change? Is there documentation that supports why it changed, the expected outcome of the change, etc? The same questions exist for whether developers make the change. Just because it's pushed through puppet, chef, ansible, whatever, doesn't mean it's an approved or authorised change - it just means it came through an approved channel. If something changes and it's a surprise to InfoSec, I want the SA for that box (or cluster) to tell me why something changed outside of an established maintenance window, who approved it and why we weren't notified of emergency changes to production systems. If you KNOW you're going to change certain files at certain times then add filters to reflect those things. For example, if your devs push code to <these projects> between 9.00 and 11.30, put in an ignore for those directories at those times. Better yet, have a list of files you're changing, check the syscheck alerts against the list of changes and if something is not on the list, time to email an alert. As long as you don't take the "change all the things at any time" approach, and have an established approval process for changes to production systems, this is a very workable issue. kmw -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
