RE: Why exclude unset auid in STIG rules
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
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