Re: Too much auditing?
From: Eric Fitzgerald [MSFT] (ericf_at_online.microsoft.com)
Date: 06/28/03
- Next message: Al Yankovich: "Re: Mysterious login failures"
- Previous message: Indred Cold: "Win2k SP4"
- In reply to: Invisible: "Too much auditing?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 27 Jun 2003 18:30:14 -0700
Hi Invisible,
1. Just like any security setting, it is typically unproductive to just pick
the highest setting. You need to examine the capabilities of audit, conduct
a threat exercise (determine what threats you want to defend against),
determine which audit categories would give you information which would help
mitigate that threat, and then enable only those categories. As an adjunct
you might want to enable categories that would provide supporting
information, such as process tracking.
2. If you log everything, set your logs to a much larger size, such as 64MB
or 256MB, depending on free space and how fast the machine logs events.
3. Process tracking is a very useful audit category- it allows you to
translate a PID (process ID) into a executable image name. Except on batch
servers or CGI web servers, it's generally very useful and not too verbose.
I have a couple of general recommendations:
1. Failure auditing is not useful for most people, esp. people who don't
look at their logs regularly. I use it, but then I look at my logs every
day and I know what I'm looking for. So don't turn on failure auditing
unless you have a specific goal in mind AND you have staffed and tasked a
position to review the failure audits regularly, with an action plan on what
to do about them.
2. Privilege use auditing generates too many audits to be useful; don't
enable it.
3. Don't audit reads on objects.
4. Don't enable CrashOnAuditFail or AuditBaseObjects (aka Halt the system if
unable to log security events, Audit the access of global system objects).
You're asking for trouble.
5. Set your log file size to something nice and big, say 64MB.
6. Don't set your log file size to something bigger than 256MB (sum total of
all logs on system, not each individual log).
Eric Fitzgerald
Program Manager, Windows Auditing
"Invisible" <orphi69@hotmail.com> wrote in message
news:0d4501c3365c$7002d1f0$a101280a@phx.gbl...
> Alright, so this isn't exactly a "security" question, it's
> an "auditing" question... but I wasn't quite sure where
> else to put it.
>
> Anyway, getting to the point... I see that the folks over
> at my company's American branch have put together a
> standard Group Policy for all AD domains. One of the more,
> um, "interesting" items was their auditing settings: they
> propose to overwrite event logs as needed, set the event
> log sizes to 512KB each, and audit EVERYTHING.
>
> Yes, you heard me: everything. Logon, logoff, GP change,
> account change, system events, process events, EVERYTHING.
>
> Now, I myself happen to think this is a fairly silly idea -
> especially since the event logs will probably only be
> looked at by a human being roughly once a year (unless
> something stops working - if you follow ;-).
>
> For starters, I'm told auditing Process events is only
> supposed to be used for debugging, and generates masses of
> very verbose events about just about anything any thread
> on the system ever does.
>
> In short, SURELY these people are just going to end up
> with event logs that only cover the last 7 minutes of
> sever activity and contain nothing of any value at all.
> (Or if they do, it's totally burried amoung all the junk!)
>
> Now, what I want to know is this: have I totally
> misunderstood how Windows 2000 works, or are my American
> friends actually air-heads?
>
> Thanks.
>
- Next message: Al Yankovich: "Re: Mysterious login failures"
- Previous message: Indred Cold: "Win2k SP4"
- In reply to: Invisible: "Too much auditing?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
