What STIG audit rule picks up type=SOFTWARE_UPDATE events?

[Steven Grubb]

Hello,


On Fri, May 12, 2023 at 5:23 PM Wieprecht, Karen M. <
Karen.Wieprecht at jhuapl.edu> wrote:

> All,
>
>
>
> Do you happen to know which if the standard STIG rules is picking up
>   type=SOFTWARE_UPDATE events on RHEL 7 and 8 ?
>

None. rpm has been altered to produce these much the same as pam produces
login events. It was too tricky to tell the intent to update vs querying
the rpm database. And you have no way to answer the question about success
without originating from inside rpm itself. I don't think any external
rules can meet all requirements imposed by OSPP, which the STIG audit rules
are loosely based on.

-Steve


>   I’m trying to figure out if we missed one of these rules on an Ubuntu 20
> system we are configuring  or if maybe the audit subsystem implementation
> on that system doesn’t pick up all of the same record types as we get on
> our RHEL boxes.  I realized when I started looking at this that it’s not
> easy to determine which audit rule is picking up a particular event if it’s
> not one of the rule that has a key associated with it.
>
>
>
> As a possible alternative,   I ran across a sample audit.rules  list here GitHub
> - Neo23x0/auditd: Best Practice Auditd Configuration
> <https://github.com/Neo23x0/auditd>  (actual rules file is here: auditd/audit.rules
> at master · Neo23x0/auditd · GitHub
> <https://github.com/Neo23x0/auditd/blob/master/audit.rules>) which
> included some software management rules that don’t appear to be  part of
> the standard “30-stig.rules” .
>
>
>
> If the standard STIG rules don’t pick up  type=SOFTWARE_UPDATE events on
> Ubuntu20,  I might add some of these , so I was hoping to have a quick
> sanity check on whether these look like appropriate alternatives.  Any
> recommendations or comments regarding these sample rules would be much
> appreciated.  Basically it looks to me like they are just setting watches
> for anyone  executing these various commands, which shouldn’t cause to much
> noise in the logs except maybe when we are patching which is one of the
> continuous monitoring items I  need to be able to confirm.
>
>
>
> Thanks much!
>
> Karen Wieprecht
>
>
>
> # Software Management
> ---------------------------------------------------------
>
>
>
> # RPM (Redhat/CentOS)
>
> -w /usr/bin/rpm -p x -k software_mgmt
>
> -w /usr/bin/yum -p x -k software_mgmt
>
>
>
> # DNF (Fedora/RedHat 8/CentOS 8)
>
> -w /usr/bin/dnf -p x -k software_mgmt
>
>
>
> # YAST/Zypper/RPM (SuSE)
>
> -w /sbin/yast -p x -k software_mgmt
>
> -w /sbin/yast2 -p x -k software_mgmt
>
> -w /bin/rpm -p x -k software_mgmt
>
> -w /usr/bin/zypper -k software_mgmt
>
>
>
> # DPKG / APT-GET (Debian/Ubuntu)
>
> -w /usr/bin/dpkg -p x -k software_mgmt
>
> -w /usr/bin/apt -p x -k software_mgmt
>
> -w /usr/bin/apt-add-repository -p x -k software_mgmt
>
> -w /usr/bin/apt-get -p x -k software_mgmt
>
> -w /usr/bin/aptitude -p x -k software_mgmt
>
> -w /usr/bin/wajig -p x -k software_mgmt
>
> -w /usr/bin/snap -p x -k software_mgmt
>
>
>
> # PIP(3) (Python installs)
>
> -w /usr/bin/pip -p x -k T1072_third_party_software
>
> -w /usr/local/bin/pip -p x -k T1072_third_party_software
>
> -w /usr/bin/pip3 -p x -k T1072_third_party_software
>
> -w /usr/local/bin/pip3 -p x -k T1072_third_party_software
>
>
>
> # npm
>
> ## T1072 third party software
>
> ## https://www.npmjs.com
>
> ## https://docs.npmjs.com/cli/v6/commands/npm-audit
>
> -w /usr/bin/npm -p x -k T1072_third_party_software
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://listman.redhat.com/mailman/listinfo/linux-audit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20230514/2d89f1eb/attachment.htm>