Re: CIS vs NIST

["Bridges, Robert A." <bridgesra () ORNL GOV>]

Thank you, Valdis!

--
Robert A. Bridges, PhD, Research Mathematician, Cyber & Information Science Research Group, Oak Ridge National 
Laboratory
On 4/30/18, 12:52 PM, "The EDUCAUSE Security Constituent Group Listserv on behalf of Valdis Kletnieks" <SECURITY () 
LISTSERV EDUCAUSE EDU on behalf of valdis.kletnieks () VT EDU> wrote:

    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.