1:34 p.m.
On Wednesday, May 11, 2016 06:28:11 PM Wyatt, Curtis wrote:
I don't understand why the STIG audit rules have -F
auid!=4294967295 in it.
If auid is unset, why wouldn't you still want to see the events in the
logs?
When a user logs in, the auid gets set to the uid that they used to login
with. Daemons are not user sessions and have the loginuid set to -1. The auid
representation is an unsigned 32 bit integer. So, -1 becomes 4294967295. The
rules use a directive like this: -F auid>=1000 to trigger on user activity. It
turns out that would trigger on daemons doing something because 4294967295 is
greater than 1000. So, we exclude daemons because user activity is the prime
target.
-Steve
1:40 p.m.
New subject: Why exclude unset auid in STIG rules
Ok, so the assumption is that daemons are not compromised? In other words, if a daemon is
compromised (or could be compromised), wouldn't you want to monitor it's behavior
as well?
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Wednesday, May 11, 2016 11:35 AM
When a user logs in, the auid gets set to the uid that they used to login with. Daemons
are not user sessions and have the loginuid set to -1. The auid representation is an
unsigned 32 bit integer. So, -1 becomes 4294967295. The rules use a directive like this:
-F auid>=1000 to trigger on user activity. It turns out that would trigger on daemons
doing something because 4294967295 is greater than 1000. So, we exclude daemons because
user activity is the prime target.
2:10 p.m.
New subject: Why exclude unset auid in STIG rules
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.
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.)
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.
I don't see anything in the SRG that leans towards IDS-like rules. Do you see
any?
-Steve
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Wednesday, May 11, 2016 11:35 AM
When a user logs in, the auid gets set to the uid that they used to login
with. Daemons are not user sessions and have the loginuid set to -1. The
auid representation is an unsigned 32 bit integer. So, -1 becomes
4294967295. The rules use a directive like this: -F auid>=1000 to trigger
on user activity. It turns out that would trigger on daemons doing
something because 4294967295 is greater than 1000. So, we exclude daemons
because user activity is the prime target.
3:16 p.m.
New subject: 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
3:43 p.m.
New subject: Why exclude unset auid in STIG rules
This is an interesting development. I will have to keep my eyes peeled for this thread.
Warron French, MBA, SCSA
________________________________________
From: linux-audit-bounces(a)redhat.com <linux-audit-bounces(a)redhat.com> on behalf of
Wyatt, Curtis <Curtis.Wyatt(a)gd-ms.com>
Sent: Wednesday, May 11, 2016 4:16 PM
To: Steve Grubb
Cc: linux-audit(a)redhat.com
Subject: 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
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
3146
days inactive
3146
days old
linux-audit@lists.linux-audit.osci.io
4 comments
3 participants
participants (3)
-
Steve Grubb -
Warron S French -
Wyatt, Curtis