Why exclude unset auid in STIG rules

[Warron S French]

This is an interesting development.  I will have to keep my eyes peeled for this thread.

Warron French, MBA, SCSA

________________________________________
From: linux-audit-bounces at redhat.com <linux-audit-bounces at redhat.com> on behalf of Wyatt, Curtis <Curtis.Wyatt at gd-ms.com>
Sent: Wednesday, May 11, 2016 4:16 PM
To: Steve Grubb
Cc: linux-audit at redhat.com
Subject: RE: Why exclude unset auid in STIG rules

> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb at 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

--
Linux-audit mailing list
Linux-audit at redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit