RE: [logs] RE: NT Event Log and Web Server Attacks

From: Eric Fitzgerald (ericfat_private)
Date: Mon Jan 20 2003 - 15:21:07 PST

  • Next message: Paul D. Robertson: "RE: [logs] RE: NT Event Log and Web Server Attacks"

    Hey Paul,
    We would never get rid of timestamp.  In fact in an enterprise event
    collection system there are two timestamps and two sequence numbers that
    are interesting:
    * Generation timestamp (already integral to Windows event log)
    * Receive timestamp on event collector
    * Generation sequence number (already integral to Windows event log)
    * Transmit sequence number.
    Timestamps alone may be insufficient for sequencing if it is not
    granular enough, as with the Windows event log which has 1s resolution.
    Receive timestamp is necessary to properly do time-interval-based
    queries on a regular basis at the collector, if the transmission of
    events from monitored machines is not guaranteed to be real-time.
    Transmit sequence number is necessary to be able to remotely detect gaps
    in the event stream, if some events are filtered at the source prior to
    transmission to a collector.
    All those reasons aside, we wouldn't exclude timestamp if for no other
    reason than backwards compatibility.
    Ok, enough geeking on that.
    The Microsoft Audit Collection Service which will debut this summer will
    have a choice of two transports- TCP and SSL.  In either case the
    connection will be reliable, ordered, mutually authenticated, and
    encrypted.  Other than this choice of transports, there will be no other
    choice, configurability, or extensibility in transport mechanism, and we
    are not going to be compatible with any flavor of syslog in version 1.
    We investigated syslog thoroughly including the new RFCs for BEEPCORE,
    syslog-reliable and syslog-sign, but none of those protocols seemed both
    appropriate and sufficient for our purposes (I will not debate this
    issue further, as it is likely to start a religious war, I just wanted
    to report that we did not arbitrarily or lightly choose not to use
    syslog).  Our protocol will be published- third parties will be able to
    write code to interoperate.
    Event collection might be built into Windows at some point in the
    future, internally we are still in the discussion stage of this and
    would want to converge all our efforts (MACS, MOM, etc.) in this area.
    We are also working on a project called "Secure Server Roles" which will
    have, among many other things, user-selectable auditing templates for
    Forensic and Intrusion Detection scenarios.  These templates will set
    audit policy as well as SACLs on the file system, services, and the
    registry.  The templates are focused around detection of
    security-sensitive changes to OS binaries or configuration.  The
    forensic configuration focuses on changes that were actually successful
    while the ID configuration also includes unsuccessful attempts.
    -----Original Message-----
    From: Paul D. Robertson [mailto:probertsat_private] 
    Sent: Monday, January 20, 2003 12:26 PM
    To: Eric Fitzgerald
    Cc: H C; Rainer Gerhards; loganalysisat_private; Tina Bird; Marcus
    J. Ranum; Ben Laurie
    Subject: RE: [logs] RE: NT Event Log and Web Server Attacks
    On Mon, 20 Jan 2003, Eric Fitzgerald wrote:
    > This is a really interesting idea- the ability to pivot audit data 
    > around other criteria besides time.
    Again, I think it's really useful to look at admin questions as a good 
    criteria, but we still need timestamped paths for forensics.  I'd 
    encourage you to keep the raw format in timestamp order, just so it
    presentation easier in legal situations.
    > I think that the main problem is that Event Viewer was never designed 
    > for correlation or advanced querying, which need to be built-in 
    > functions when dealing with large data sets that change rapidly. 
    > Hopefully we'll resolve that in our next release of Windows; we are 
    > aware of that problem.
    We've been doing a fair ammount of correlation and log sawing over the 
    last two years.  If there are any specific things you'd like input
    I'd be happy to oblige ;)
    > For a single machine, using an object-based view for analysis is 
    > already possible with only a little work: use the EventQuery.vbs tool 
    > on Windows XP or Windows Server 2003 to dump the events to a csv file,
    > then import into Excel. Excel has a feature called "autofilter" which 
    > greatly simplifies querying the log, as well as PivotTable and 
    > PivotChart functionality. I will occasionally chart audit data to see 
    > trending- for instance a few weeks ago I used this method to analyze 
    > logon traffic to our domain controllers in one of our development 
    > domains.
    Do you have any specific non-standard things turned on for auditing 
    purposes?  I'm really chomping at the bit to get folks to set up more 
    forensics-friendly environments- part of that includes what sort of 
    logging things should be premptively configured (for instance, Apache 
    servers are much better for doing incident analysis when combined
    is on because referrers are important for a lot of attacks against Web 
    > We have something up our sleeve but I don't want to over-promise & 
    > under-deliver.  Look for a significant audit collection and analysis 
    > tool from us this summer, and a completely replaced event log service 
    > with some really neat analysis capabilities in the next version of 
    > Windows.
    Will the new service make it easy to drop in new transports?    
    Paul D. Robertson      "My statements in this message are personal
    probertsat_private      which may have no basis whatsoever in fact."
    probertsonat_private Director of Risk Assessment TruSecure
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Mon Jan 20 2003 - 15:36:03 PST