From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EC3E4C77B7F for ; Fri, 12 May 2023 21:23:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683926626; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=pGJTqX7bIunpeufx57O12wUXDf2+CIsihURVuD+EUqg=; b=QOTg3+pys6yx+9IwjmhpMwZbQE7p7HMeydLZUAl9pOeInilh8Dd47RG4wAPdAdTjxfzDo2 0dnGh6gONCUt5nNzfY1Vg2vJ6RhdeRNuB3RwGe5t8yQGzHsrv530u3J0lW19NPvOArAh6O wrgGBQTV0DWMKzAwJbPgwz28CXJqe4U= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-553-v7OE4iykOdKPl2Kr0pBQ5Q-1; Fri, 12 May 2023 17:23:44 -0400 X-MC-Unique: v7OE4iykOdKPl2Kr0pBQ5Q-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 89C6E1C09064; Fri, 12 May 2023 21:23:43 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id D4FEC63F5F; Fri, 12 May 2023 21:23:40 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 8B91719451E4; Fri, 12 May 2023 21:23:40 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 7B11819451E3 for ; Fri, 12 May 2023 21:23:34 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 76B272027043; Fri, 12 May 2023 21:23:34 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast08.extmail.prod.ext.rdu2.redhat.com [10.11.55.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6ED852026DFD for ; Fri, 12 May 2023 21:23:34 +0000 (UTC) Received: from us-smtp-inbound-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 49383381D4CD for ; Fri, 12 May 2023 21:23:34 +0000 (UTC) Received: from aplegw01.jhuapl.edu (aplegw01.jhuapl.edu [128.244.251.168]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-264-QxCGtasUNQC211qEy7-uaQ-1; Fri, 12 May 2023 17:23:30 -0400 X-MC-Unique: QxCGtasUNQC211qEy7-uaQ-1 Received: from pps.filterd (aplegw01.jhuapl.edu [127.0.0.1]) by aplegw01.jhuapl.edu (8.17.1.19/8.17.1.19) with ESMTP id 34CKo0NF029976 for ; Fri, 12 May 2023 17:17:58 -0400 Received: from aplex22.dom1.jhuapl.edu (aplex22.dom1.jhuapl.edu [10.114.162.7]) by aplegw01.jhuapl.edu (PPS) with ESMTPS id 3qf778vgmq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 12 May 2023 17:17:58 -0400 Received: from APLEX26.dom1.jhuapl.edu (10.114.162.11) by APLEX22.dom1.jhuapl.edu (10.114.162.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Fri, 12 May 2023 17:17:57 -0400 Received: from APLEX26.dom1.jhuapl.edu ([fe80::8b67:5cb8:8fbe:fd18]) by APLEX26.dom1.jhuapl.edu ([fe80::8b67:5cb8:8fbe:fd18%12]) with mapi id 15.02.1118.026; Fri, 12 May 2023 17:17:57 -0400 From: "Wieprecht, Karen M." To: "Linux-audit@redhat.com" Subject: What STIG audit rule picks up type=SOFTWARE_UPDATE events? Thread-Topic: What STIG audit rule picks up type=SOFTWARE_UPDATE events? Thread-Index: AdmFCk3zm3FM9tdHSrSSGqt8WBugUw== Date: Fri, 12 May 2023 21:17:57 +0000 Message-ID: <7622dda18a1544c3bb52052019e34d72@jhuapl.edu> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.162.18] MIME-Version: 1.0 X-CrossPremisesHeadersFilteredBySendConnector: APLEX22.dom1.jhuapl.edu X-OrganizationHeadersPreserved: APLEX22.dom1.jhuapl.edu X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-05-12_13,2023-05-05_01,2023-02-09_01 X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-audit-bounces@redhat.com Sender: "Linux-audit" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: jhuapl.edu Content-Language: en-US Content-Type: multipart/mixed; boundary="===============4869946541222567185==" --===============4869946541222567185== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7622dda18a1544c3bb52052019e34d72jhuapledu_" --_000_7622dda18a1544c3bb52052019e34d72jhuapledu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Do you happen to know which if the standard STIG rules is picking up type= =3DSOFTWARE_UPDATE events on RHEL 7 and 8 ? I'm trying to figure out if w= e missed one of these rules on an Ubuntu 20 system we are configuring or i= f maybe the audit subsystem implementation on that system doesn't pick up a= ll 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 i= s 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 G= itHub - Neo23x0/auditd: Best Practice Auditd Configuration (actual rules file is here: auditd/audit.rules at maste= r * Neo23x0/auditd * GitHub) which included some software management rules that don't appea= r to be part of the standard "30-stig.rules" . If the standard STIG rules don't pick up type=3DSOFTWARE_UPDATE events on = Ubuntu20, I might add some of these , so I was hoping to have a quick sani= ty check on whether these look like appropriate alternatives. Any recommen= dations or comments regarding these sample rules would be much appreciated.= Basically it looks to me like they are just setting watches for anyone e= xecuting 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 moni= toring 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 --_000_7622dda18a1544c3bb52052019e34d72jhuapledu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All, 

 

Do you happen to know which if the standard STIG rul= es is picking up   type=3DSOFTWARE_UPDATE events on RHEL 7 and 8 = ?   I’m trying to figure out if we missed one of these rule= s 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 s= ame record types as we get on our RHEL boxes.  I realized when I start= ed looking at this that it’s not easy to determine which audit rule i= s picking up a particular event if it’s not one of the rule that has a key associated with it.    <= /p>

 

As a possible alternative,   I ran across = a sample audit.rules  list here GitHub - Neo23x0/auditd: Best= Practice Auditd Configuration  (actual rules file is here: audit= d/audit.rules at master · Neo23x0/auditd · GitHub) 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=3DSOFTWARE_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 lo= gs except maybe when we are patching which is one of the continuous monitoring items I  need to be able to confirm.&nbs= p;   

 

Thanks much!

Karen Wieprecht

 

# Software Manageme= nt ---------------------------------------------------------

 

# RPM (Redhat/CentO= S)

-w /usr/bin/rpm -p = x -k software_mgmt

-w /usr/bin/yum -p = x -k software_mgmt

 

# DNF (Fedora/RedHa= t 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 (D= ebian/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/aptitud= e -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 in= stalls)

-w /usr/bin/pip -p = x -k T1072_third_party_software

-w /usr/local/bin/p= ip -p x -k T1072_third_party_software

-w /usr/bin/pip3 -p= x -k T1072_third_party_software

-w /usr/local/bin/p= ip3 -p x -k T1072_third_party_software

 

# npm

## T1072 third part= y software

## https://www.npmj= s.com

## https://docs.npm= js.com/cli/v6/commands/npm-audit

-w /usr/bin/npm -p = x -k T1072_third_party_software

--_000_7622dda18a1544c3bb52052019e34d72jhuapledu_-- --===============4869946541222567185== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit --===============4869946541222567185==--