> -----Original Message----- > From: Steve Grubb [mailto:[email protected]] > Sent: Wednesday, May 11, 2016 12:11 PM > > On Wednesday, May 11, 2016 06:40:52 PM Wyatt, Curtis wrote: > > Ok, so the assumption is that daemons are not compromised? > > This is a complicated topic. Basically there are different levels of paranoia. > The STIG in my mind addresses basic robustness. If you read through the > SRG, the things its requiring are reasonable but not paranoid. > > I also think of it as a starting point. You can certainly tighten your system > more than the STIG calls out. This is because you have specific knowledge of > your operating environment and the threats that go with it. This might be for > example knowledge about a daemon you have installed and whether or not > its likely to be compromised. You can, with specific knowledge, add rules just > for that daemon. But I don't think everyone wants to be held to the needs of > a particular setup.
That makes sense, because the STIGS are applied to a wide variety of systems operating in a variety of threat environments. > > I think there is a difference in what rules you would use to spot bad user > activity vs the rules you would use for intrusion detection. (I am working on > and testing rules for intrusion detection and they will be in an upcoming > release.) Love this. > > In other words, if a daemon is compromised (or could be compromised), > > wouldn't you want to monitor it's behavior as well? > > Perhaps if you feel that this is likely to happen in your environment. You may > also wind up with so many events that you cannot see what a rogue > employee just did right before they quit. Or so many events that you only > can keep the last hour's logs on-hand. Which is why I'm also exploring the best options for compressing logs. But that's another topic for another time. > > I don't see anything in the SRG that leans towards IDS-like rules. Do you see > any? No, I do not. But now I understand all the reasoning. As always, your very helpful, thanks. Curtis -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
