Re: CIS vs NIST

[Valdis Kletnieks <valdis.kletnieks () VT EDU>]

On Mon, 30 Apr 2018 16:12:58 -0000, "Bridges, Robert A." said:
> So (one of) the questions (that still remains) for anyone willing to chime in
> does anyone use audit logs?

You'll probably need to qualify the question somewhat.  There's the general
concept of an audit log where a note of any sketchy/wonky events get logged,
which can be anything from network logs tracking a probe (and could be
Splunk, firewall, or iptables or Windows event log) to failed logings to event
logs regarding attemted access to restricted file data.

And then there's a specific Linux thing called 'audit', which is a kernel
facility for logging security-relevant events detected by the kernel.  The
output from that can vary based on the configuration - on my laptop it runs
about 1 megabyte a day of various stray SELinux messages with the canned Fedora
default config. At the other end of the spectrum, you can configure it to log
every single system call - which can be voluminous indeed. For example,
modelling with 'strace', just building the NVidia kernel driver involves 148
compiles, 5,500 processes, and 2.5 million system calls - and logging that at
260 bytes or so per call leaves you looking at 4 gigabytes of logging. My
laptop doesn't have enough disk to do syscall-level logging for an entire
kernel build (5,000 or so compiles).  And it's *really* easy to tell it to log
the wrong things, or misinterpret the results - for example, the module build I
just mentioned had this:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 95.12  448.089860       59294      7557      2626 wait4
  1.65    7.756550          14    537697    247580 openat
  0.65    3.078594           9    310831           read
  0.55    2.600349           8    301260       870 close
  0.48    2.283084           7    289726           fstat
  0.34    1.594304          12    123804           mmap
  0.14    0.680137          17     38842           mprotect
  0.14    0.658445          46     14024           munmap
  0.13    0.618032          12     49516     22266 stat

Wow, is there a problem because half the open() and stat() calls failed?  Nope -
it's standard Linux behavior, trying to open a file at multiple locations in
a search path, which can cause 4 or 5 attempts to find the file in various site
and user operride locations before settling on the system-provided file.

To the best of my knowledge, nobody's using the Linux kernel audit logs for
near real time detection of events - it's of more use for forensic analysis of
incidents and system/package testing.

Attachment: _bin
Description: