public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Cc: "MAUPERTUIS, PHILIPPE" <philippe.maupertuis@equensworldline.com>
Subject: Re: PCI System level object
Date: Mon, 13 Jan 2020 17:05:35 -0500	[thread overview]
Message-ID: <2470485.v1Se5RCo8b@x2> (raw)
In-Reply-To: <5F4EE10832231F4F921A255C1D954298261DA3@DEERLM99EX7MSX.ww931.my-it-solutions.net>

On Monday, January 13, 2020 12:46:15 PM EST MAUPERTUIS, PHILIPPE wrote:
> Redhat is providing audit rules sample for PCI DSS.
> For the requirement 10.2.7 it is written :
> ## 10.2.7 Creation and deletion of system-level objects
> ## This requirement seems to be database table related and not audit
> 
> However the PCI glossary defines system level objects as :
> System-level object:
> Anything on a system component that is required for its operation,
> including but not limited to database tables, stored procedures,
> application executables and configuration files, system configuration
> files, static and shared libraries and DLLs, system executables, device
> drivers and device configuration files,and third-party components. 

This seems a lot like overkill.

> It seems It should be covered by the FIM solution and not by audit.

There is the aide program which can certainly tell you what's changed. But I 
wouldn't exactly call it an audit because it doesn't tell you when something 
changed or who did it.

If you had to meet this, then you might want to use:
30-ospp-v42-1-create-success.rules
30-ospp-v42-4-delete-success.rules

That should limit things to creation and deletion but not access or 
modification which don't seem to be called out. Expect a dnf update to flood 
the system with audit events.

> However loading and unloading kernel modules  should probably be covered by
> auditd. Could you tell me which events are generated in that case ?

The rules are in 43-module-load.rules and they create a syscall event with a 
KERN_MODULE record.

> Are there any others events that should consider for this requirement

It depends on your definition of system level objects. Some define it to also 
include sockets, shared memory, disk partitions (mounts), IPC, USB devices, 
etc. I think a more narrow interpretation is better.

-Steve

      parent reply	other threads:[~2020-01-13 22:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-13 17:46 PCI System level object MAUPERTUIS, PHILIPPE
2020-01-13 18:42 ` F Rafi
2020-01-13 22:05 ` Steve Grubb [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2470485.v1Se5RCo8b@x2 \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=philippe.maupertuis@equensworldline.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox