[logs] Brightmail

[Eric Fitzgerald]

Why build time?  This is a run time task.  New applications could be
installed at any time and might include new messages.

In Windows Vista, the new eventlog service has this capability.  From an
elevated command prompt (one with admin privilegs), type the following:

wevtutil gp Microsoft-Windows-Security-Auditing /ge /gm:true

This example dumps only the 360 or so unique security event messages.
Other publishers can be enumerated with the ep switch.  Output can be
formatted as XML; that is left as an exercise for the reader.

Note that these are message format strings and have substitution tokens
for the unique information in each event record- they are essentially
prototypes for what is displayed in event viewer.

All interfaces are available programmatically; for a starting point
query MSDN for EVT_PUBLISHER_METADATA_PROPERTY_ID.

For pre-Vista Windows operating systems and for some Microsoft
applications you can find some of these message prototypes on the
TechNet Events and Errors Message Center here:
http://www.microsoft.com/technet/support/ee/ee_advanced.aspx; this is
where Event Viewer goes to get the same information when you click the
link in the bottom of an event message.  I won't make any assertions
that the links won't change but they are built-into the OS...

Best regards,
Eric


-----Original Message-----
From: loganalysis-bounces at loganalysis.org
[mailto:loganalysis-bounces at loganalysis.org] On Behalf Of Mordechai T.
Abzug
Sent: Monday, July 16, 2007 9:41 PM
To: loganalysis at loganalysis.org
Subject: Re: [logs] Brightmail

On Mon, Jul 16, 2007 at 08:23:57PM +0530, harshad.mengle at wipro.com
wrote:

> Currently we are doing analysis on Brightmail. There are some issues
> getting Event ID list. Is there anybody who can provide any
> information on Brightmail Event ID for Ver 6.0.1.

[This is only tangentially related to the above.  Sorry.]

Wouldn't it be nice if programs that did calls to log frameworks had
an automatic mechanism to obtain a list of log/audit messages at build
time?  That way, ISVs could more easily document log messages.  Log
messages could even get their own data section name in the binary, so
users could extract a list of known log messages and verify for
themselves that all possible messages are documented.  This would be
really easy in languages with a preprocessor (i.e. C).  Somewhat
harder in regular compiled languages, and probably impossible in pure
interpreted languages that don't require building.

This would also fall over if the ISV implemented their own logging
wrapping function, such that all logging calls were made from the same
point in the code with generic arguments at build time.

So yeah, it's not going to happen.  But wouldn't it be nice?

- Morty
_______________________________________________
LogAnalysis mailing list
LogAnalysis at loganalysis.org
http://www.loganalysis.org/mailman/listinfo/loganalysis