RE: [logs] Monitoring Windows Security Events

From: Eric Fitzgerald (ericf@private)
Date: Thu Oct 09 2003 - 13:28:31 PDT

  • Next message: Daniele Muscetta: "RE: [logs] Monitoring Windows Security Events"

    Only the security log.  This is a security event collection system, not
    a general-purpose management system. 
    -----Original Message-----
    From: Safier, Adam * [mailto:Safier@private] 
    Sent: Thursday, October 09, 2003 1:23 PM
    To: Eric Fitzgerald; loganalysis@private
    Subject: RE: [logs] Monitoring Windows Security Events
    Will it also capture the other MSFT logs?  (i.e. system and application)
    or only the security Log?
    -----Original Message-----
    From: Eric Fitzgerald [mailto:ericf@private]
    Sent: Thursday, October 09, 2003 1:17 PM
    To: loganalysis@private
    Subject: RE: [logs] Monitoring Windows Security Events
    Microsoft is working on a project called the Microsoft Audit Collection
    System, which will be released at the same time as Windows Server 2003
    This is a client-server application to collect security event logs
    securely to a central database, and also to provide a platform for
    real-time intrusion detection.
    The design goals for MACS were:
    1. Move towards auditor-administrator role separation via real-time
    audit export 2. Enhance analyzability of security events 3. Provide a
    platform for real-time distributed HIDS 4. Collect events securely
    Non-goals were:
    1. Windows NT 4.0 support
    2. Support for other event logs
    3. Support for syslog, snmp, beep, etc.  (We considered and rejected
    these and other protocols before implementing our own transport
    4. Support for non-Microsoft SQL databases
    Our agent runs as a service on the monitored machine, monitors the
    security log, packages the events and transfers them to the collector in
    near-real-time (we hold non-full network buffers for a short time a la
    The agent mutually authenticates to the collector using Kerberos or SSL.
    The agent normalizes the events to a Windows Server 2003 schema, adds
    additional information (name if only SID/GUID present & vice versa),
    compresses, encrypts, and transmits the event.  All insertion strings
    are kept in their original format; we don't combine the event data with
    the event message.
    Encryption is 128-bit RC4 with periodic re-keying.
    Connection is a socket connection over a configurable TCP port; service
    location is via SRV records or local configuration.
    The agent pre-allocates all necessary memory at startup (it can't leak).
    Working set size is <2.9Mb; CPU usage is typically <0.5% even under
    heavy load.  The agent uses the security log itself as a transmit
    buffer.  There is a configurable heartbeat mechanism.
    The collector receives, decrypts, & decompresses the events.  The
    collector adds type information to each field of each event (we have
    developed an XML schema for the security event log, the collector
    pre-reads this and uses this to add the type information).
    The collector acts as a WMI provider; applications can be written to
    subscribe to the collector and receive a filtered, normalized event
    stream in real time.  In this way any HIDS logic does not have to run
    inside the collector but can be placed externally; new logic can be
    added, changed, or removed dynamically by unsubscribing and
    The collector then loads the events into a database.  The database
    loader uses a configurable pre-filter to discard unwanted events.  Note
    that the agent does not support pre-transmit filtering; this introduces
    complexity and prevents reliable event sequence gap detection.  The
    database loader then loads the events into a Microsoft SQL Server 2000
    All string data is stored in a single-instance fashion, reducing the
    storage overhead in the database and increasing query performance.  Any
    field of any event can be queried directly by value or type.  The
    database loader also prunes the database, discarding events over a
    configurable age.
    MACS will be an out-of-band release of a Windows component.  That is,
    MACS will be part of Windows in future releases.  MACS agent is a
    no-cost add-on license to Windows 2000 and all later releases.  MACS
    collector is a no-cost add-on license to Windows Server 2003.  That is
    to say, if you own a valid Windows 2000 or later license, you may run
    MACS agent on it.  If you own a valid Windows Server 2003 license, you
    may run MACS collector on it.  You will have to purchase SQL Server
    MACS is optimized to the security event log.  It collects event log data
    in a different manner than MOM (which was mentioned earlier in this
    thread).  MOM is great for system management but is very hefty for
    security log management and has a number of limitations, such as a 30GB
    database size limit.  MACS compares very favorably to MOM in terms of
    database size, network traffic volume, and speed of collection.  However
    MACS is not a general-purpose management tool.  MACS is designed to work
    with management systems in general and will include a MOM management
    pack.  It will also include all necessary documentation to use any other
    management system that supports Windows, to manage MACS.
    If you would like to participate in the MACS beta, please send me the
    1. Name
    2. Passport-enabled email address (you *MUST* have a Passport; our beta
    download site uses Passport authentication).
    3. Physical address
    4. Phone number
    I'll be happy to answer any other questions about our project.
    Eric Fitzgerald
    Program Manager
    Windows Core Security- Auditing & Security Reporting Microsoft
    LogAnalysis mailing list
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Thu Oct 09 2003 - 14:35:44 PDT