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. Eric -----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 makes 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 about, 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 logging is on because referrers are important for a lot of attacks against Web servers...) > 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? Thanks, Paul ------------------------------------------------------------------------ ----- Paul D. Robertson "My statements in this message are personal opinions probertsat_private which may have no basis whatsoever in fact." probertsonat_private Director of Risk Assessment TruSecure Corporation _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Mon Jan 20 2003 - 15:36:03 PST