All of lore.kernel.org
 help / color / mirror / Atom feed
* PCI System level object
@ 2020-01-13 17:46 MAUPERTUIS, PHILIPPE
  2020-01-13 18:42 ` F Rafi
  2020-01-13 22:05 ` Steve Grubb
  0 siblings, 2 replies; 3+ messages in thread
From: MAUPERTUIS, PHILIPPE @ 2020-01-13 17:46 UTC (permalink / raw)
  To: linux-audit


[-- Attachment #1.1: Type: text/plain, Size: 1879 bytes --]

Hi,
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.
It seems It should be covered by the FIM solution and not by audit.
However loading and unloading kernel modules  should probably be covered by auditd.
Could you tell me which events are generated in that case ?
Are there any others events that should consider for this requirement

Regards
Philippe

equensWorldline is a registered trade mark and trading name owned by the Worldline Group through its holding company.
This e-mail and the documents attached are confidential and intended solely for the addressee. If you receive this e-mail in error, you are not authorized to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. EquensWorldline and the Worldline Group therefore can accept no liability for any errors or their content. Although equensWorldline and the Worldline Group endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with equensWorldline and the Worldline Group by email

[-- Attachment #1.2: Type: text/html, Size: 7386 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PCI System level object
  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
  1 sibling, 0 replies; 3+ messages in thread
From: F Rafi @ 2020-01-13 18:42 UTC (permalink / raw)
  To: MAUPERTUIS, PHILIPPE; +Cc: linux-audit


[-- Attachment #1.1: Type: text/plain, Size: 2424 bytes --]

I have used audit logs instead of a FIM solution for PCI compliance at the
system/OS level. IMO most FIM-only products do not provide a significant
value or reduction in threats.

Farhan

On Mon, Jan 13, 2020 at 12:46 PM MAUPERTUIS, PHILIPPE <
philippe.maupertuis@equensworldline.com> wrote:

> Hi,
>
> 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.
>
> It seems It should be covered by the FIM solution and not by audit.
>
> However loading and unloading kernel modules  should probably be covered
> by auditd.
>
> Could you tell me which events are generated in that case ?
>
> Are there any others events that should consider for this requirement
>
>
>
> Regards
>
> Philippe
>
> equensWorldline is a registered trade mark and trading name owned by the
> Worldline Group through its holding company.
> This e-mail and the documents attached are confidential and intended
> solely for the addressee. If you receive this e-mail in error, you are not
> authorized to copy, disclose, use or retain it. Please notify the sender
> immediately and delete this email from your systems. As emails may be
> intercepted, amended or lost, they are not secure. EquensWorldline and the
> Worldline Group therefore can accept no liability for any errors or their
> content. Although equensWorldline and the Worldline Group endeavours to
> maintain a virus-free network, we do not warrant that this transmission is
> virus-free and can accept no liability for any damages resulting from any
> virus transmitted. The risks are deemed to be accepted by everyone who
> communicates with equensWorldline and the Worldline Group by email
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

[-- Attachment #1.2: Type: text/html, Size: 3987 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PCI System level object
  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
  1 sibling, 0 replies; 3+ messages in thread
From: Steve Grubb @ 2020-01-13 22:05 UTC (permalink / raw)
  To: linux-audit; +Cc: MAUPERTUIS, PHILIPPE

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-01-13 22:05 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.