We do have an ELK stack as well but right now we are optimising on OSSEC. Thanks!
On Friday, 17 June 2016 16:57:04 UTC+1, Audrey wrote: > > I agree with you, but unfortunately, I'm required to have some sort of > HIDS running. Commercial solutions won't work because of $$. > Moving away from Tripwire has saved my sanity as i used to spend half my > week dealing with it when i first started this job. OSSEC is so much > better, even if it was designed in 2002. > Are you going to go the ELK stack route? Wazuh has some nice pre-built > dashboards you could use. > > > > On Friday, June 17, 2016 at 3:01:28 AM UTC-7, Tahir Hafiz wrote: >> >> My feeling is that the nature of creating, managing and maintaining >> systems has changed recently - part of it is this concept or idea of DevOps >> tools (the Cloud, configuration management like Chef, Puppet, Salt, >> Continuous Integration tools like Jenkins or Travis) >> Bear in mind that OSSEC was created in 2002 when each server was >> individually configured (if you were lucky there would have been some >> custom bash scripts to set-up a server, they would run once and wouldn’t be >> repeatedly run). >> Limited stuff. But now with configuration management tools like Salt, >> Chef, Puppet, Salt you run recipes or whatever on thousands of servers (the >> scale of the server estate has increased exponentially because it is so >> easy to spin up thousands of systems in the Cloud) - OSSEC was simply not >> designed for that kind of environment. >> >> We are looking into pushing the alerts into a log analysis tool so it can >> try and figure out when something bad has happened. >> >> There also seems to be more modern, unfortunately commercial, tools >> designed for the modern cloud based DevOps type environment: >> >> https://www.threatstack.com/ >> >> https://evident.io/about/ >> >> >> >> >> >> >> >> >> On Thursday, 16 June 2016 22:40:34 UTC+1, Audrey Gallimore wrote: >>> >>> I'm wondering the same. I'm testing OSSEC as a Tripwire replacement, but >>> its little things like adjusting a config with Chef and 40 alerts come in. >>> I suppose I can whitelist in local_rules for some things like our Sensu >>> config, but there are lots of changes via Chef that will happen across the >>> board that can result in a lot of email. >>> >>> >>> >>> On Wednesday, June 15, 2016 at 3:19:19 AM UTC-7, Tahir Hafiz wrote: >>>> >>>> We are tuning our OSSEC server/agent environment. >>>> We have multiple environments and use Puppet for configuration >>>> management and AWS for our cloud based systems. >>>> >>>> We baseline (run OSSEC) at the start of an environment build, and then >>>> do a Puppet apply. >>>> We seem to have thousands of alerts coming in (many to do with syscheck >>>> on subsequent Puppet applys). >>>> >>>> How do you guys deal with so many alerts - do you try and whitelist all >>>> of them in the local_rules.xml file or just let them all go in to the >>>> alerts file? >>>> How do you know if an intruder has compromised a system if you >>>> constantly have login sessions opened and closed by system users and have >>>> level 7 syscheck alerts by Puppet applys happening as part of the normal >>>> running of your environment? >>>> How do you have warning systems based on alerts set-up (e.g. a script >>>> that triggers to Nagios ? or something else?). >>>> >>>> Cheers >>>> >>>> -- --- 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.
