Re: [logs] What "should" be logged? (long)

From: Ian O'Brien (iobat_private)
Date: Tue Aug 20 2002 - 10:01:41 PDT

  • Next message: Marcus J. Ranum: "Re: [logs] Logging: World Domination"

    comments inline ...
    
    Tina Bird wrote:
    
    > 
    > - System startup: are there multiple run levels?  If so, system
    > should
    > record which level is starting in some way that a human can make sense of
    > it
    > - System shutdown: are there multiple modes of shutdown?  Does the system
    > have any capacity to send "oh my god i'm going down" messages in the case
    > of an emergency crash or power loss?  Are there distinctions between
    > normal and abnormal shutdowns that can be differentiated in the logs?
    > - File system full: including thresholds (default or user defined) -- boy
    > wouldn't it be nice if the logs "automagically" included the three (or
    > however many) biggest culprits in terms of file size or space consumed by
    > a directory or folder in an error message?
    > - Hardware failures: power supplies, network interfaces, etc.  I am
    > relatively uneducated about hardware diagnostics, other than Cisco gear...
    > - Logins: failed and successful; console, remote (what protocol if
    > remote); anonymous account, unprivileged user account, privileged user
    > account, including switches to other users (unprivileged, privileged) from
    > user accounts
    > - Account creation: failed and successful; adding new user ID, assigning
    > rights and privileges to new user, adding password to new user
    > - Account modification: failed and successful; assigning or removing
    > rights and privileges, resetting password; privileged user or unprivileged
    > user
    > - Account removal: failed and successful
    > - Account disabled: too many failed logins, account expired, etc.
    > - Password/security information copied: failed and successful
    > - System configuration change: failed and successful; including access
    > control, network addressing, audit policy; who made change, what changed,
    > from system kernel on out to user-level applications
    > - Operating system patch applied: who applied patch, what system
    > components changed, source of patch (?)
    > - Network connections: failed and successful connection attempts;
    > anonymous service, user-specific service, access to administrative tools
    > or control connection; DNS zone transfers, etc.
    > - Audit logs: failed and successful attempts to modify or clear audit logs
    > - Object access: failed and successful attempts to read files, start or
    > stop processes, etc (understanding that most organizations will not need
    > or want this level of detail)
    
    
    I would add to this:
    
    the explicit concept of "connection accounting" - how many bytes did that user 
    transfer, in which direction, between which IPs, using which firewall rules, etc.
    
    internal resource accounting (kernel level) - especially of "non-accounting" 
    nature - eg crossing certain threshholds causing unusual mechanisms to kick in 
    (like swapping or forced pagefree's)
    
    In your list above, you mentioned DNS actions like zone transfers, wouldn't that 
    come under the heading of "application logging"? Not that an app's needs are 
    very different:
    
    startup / shutdown / reinitialize event
    logging state / verbosity level change (= debugging state change?)
    config file change
    unexpected "working file" change
    Standard usage accounting (detailed & summarized)
    Access Control activity - accepts, denies, rejects, alerts
    Authentication activity - successes, failures, others (eg: new PIN req'd?)
    Authorization activity - successes, failures, (others? anomalies?)
    
    personally - i believe that much of this information is actually available (or 
    can be easily made so) in any given computer system, but it is in so many 
    different places and in different formats that it is difficult to pull it all 
    together.
    
    > 
    > *whew*
    > 
    > I'm sure I've left things out, and I'm sure this can be sorted into a less
    > intimidating list of message categories.  But in addition to worrying
    > about format and how to handle the expected flow of data and how to
    > protect audit data traveling across networks, we need to worry about what
    > we expect to see.
    
    
    categories? I think about "accounting" and "anomaly". the former are related to 
    normal day-to-day use and can include errors, but ones that are "well handled" 
    by the system, or within its design parameters. the latter are the events 
    reflecting on "state change" of the application itself or the OS itself. but 
    that is probably a very subjective definition
    
    Ian
    -- 
    
    Ian O'Brien      What kind of head of security would I be if I let people
    408-696-2182=Pgr       like me know things that I'm not supposed to know?
    iobat_private                                  --- Michael Garibaldi, B5
    
    _______________________________________________
    LogAnalysis mailing list
    LogAnalysisat_private
    https://lists.shmoo.com/mailman/listinfo/loganalysis
    



    This archive was generated by hypermail 2b30 : Tue Aug 20 2002 - 11:17:43 PDT