COTS application suggestions for auditing

Hello,

I have a requirement to pretty thoroughly audit some W2K machines.
Among other things, the users want to track all permission changes,
failed access attempts, policy changes, yada yada yada. Enabling
auditing for all these types of events across the entire PC has
significantly affected performance.

I was wondering if anyone had any suggestions regarding any COTS
applications which could meet the user's expectations and relive
Windows of the burden of tracking all this junk. I'm not looking for
an IDS application per se... I want something to keep track of the file
system and some local security items, not tracking hacking attempts.

For example, in the NT 4.0 days there was a program called Kane
Security Monitor which I've seen on an old NT 4 machine... but the
original developers have been bought out by Intrusion, Inc.
(http://www.intrusion.com/). On NT4, Kane does a wonderful job of
keeping track of user accounts that change file/folder permissions and
security policy changes. However Intrusion has for all intents and
purposes discontinued Kane Security Monitor as it doesn't work on
Active Directory machines and Intrusion is not throwing any company
resources at making what was once known as KSM work on W2K or greater.

Suggestions are greatly appreciated.

Thanks!

Roger
Tue Apr 26 09:35:58 CDT 2005

I am not sure what all is within yada yada, but of what you did
list auditing of those items, if done narrowly and specifically,
should not be causing much performance slowdown.

I would suspect any third-party tool would show a greater
slow-down as it would layer on top of the OS, and at best
make calls to what Windows is already using in a highly
tuned fashion.

Are you sure, for example, that you are auditing for specifically
"permissions changes" on the filesystem instead of something
that would generate much more logging, like full control that
includes permission change events ??

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA
"Adam Sandler" <corn29@excite.com> wrote in message
news:1114524619.387243.230230@z14g2000cwz.googlegroups.com...
> Hello,
>
> I have a requirement to pretty thoroughly audit some W2K machines.
> Among other things, the users want to track all permission changes,
> failed access attempts, policy changes, yada yada yada. Enabling
> auditing for all these types of events across the entire PC has
> significantly affected performance.
>
> I was wondering if anyone had any suggestions regarding any COTS
> applications which could meet the user's expectations and relive
> Windows of the burden of tracking all this junk. I'm not looking for
> an IDS application per se... I want something to keep track of the file
> system and some local security items, not tracking hacking attempts.
>
> For example, in the NT 4.0 days there was a program called Kane
> Security Monitor which I've seen on an old NT 4 machine... but the
> original developers have been bought out by Intrusion, Inc.
> (http://www.intrusion.com/). On NT4, Kane does a wonderful job of
> keeping track of user accounts that change file/folder permissions and
> security policy changes. However Intrusion has for all intents and
> purposes discontinued Kane Security Monitor as it doesn't work on
> Active Directory machines and Intrusion is not throwing any company
> resources at making what was once known as KSM work on W2K or greater.
>
> Suggestions are greatly appreciated.
>
> Thanks!
>

Adam
Tue Apr 26 11:08:57 CDT 2005

Thanks for the reply...

> but of what you did
> list auditing of those items, if done narrowly and specifically,
> should not be causing much performance slowdown.

I understand that... but I'm not the one making the requirements. The
customer has a current mainframe system which pretty much tracks
everything. They want the same from their W2K system. With that said,
and as I previously wrote, they want all the permission changes, policy
changes, and access attempts tracked across every object on all the
hard drives. I have absolutely no latitude at this point in time to
narrow down the scope of the auditing.

> Are you sure, for example, that you are auditing for specifically
> "permissions changes" on the file system instead of something
> that would generate much more logging, like full control that
> includes permission change events ??

Yes, but I also need to audit for more than just permission changes...
of course all this audit activity is indeed generating much more
logging. That is why I posted... everyone pretty much understands that
auditing must be implemented smartly, except the customer... and in my
experience, a COTS application (Kane Security Monitor) potentially
gives the project what it wants without a performance hit. It's just
that the COTS app isn't available anymore.

I'm open to any alternative... whether its COTS, automatically dumping
the log file into a text file to relieve the pressure on the event
logging service, or whatever... I just want to meet the customer's
requirements.

Roger
Tue Apr 26 20:06:12 CDT 2005

I guess it is all in the yada, yada
What you listed
permission changes, failed access attempts, policy changes
will not of themselves cause much overhead, unless these
specific things are happening way, way too much.

I am not so sure that something like the old Kane Sen Analyst
could do these audits any more efficiently than the OS itself,
as far as generating the audit trail. Third party tools can do
wonders on cross-tab presentation of info in the audit trail,
but capturing the info ?

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA
"Adam Sandler" <corn29@excite.com> wrote in message
news:1114531737.337019.270880@f14g2000cwb.googlegroups.com...
> Thanks for the reply...
>
> > but of what you did
> > list auditing of those items, if done narrowly and specifically,
> > should not be causing much performance slowdown.
>
> I understand that... but I'm not the one making the requirements. The
> customer has a current mainframe system which pretty much tracks
> everything. They want the same from their W2K system. With that said,
> and as I previously wrote, they want all the permission changes, policy
> changes, and access attempts tracked across every object on all the
> hard drives. I have absolutely no latitude at this point in time to
> narrow down the scope of the auditing.
>
> > Are you sure, for example, that you are auditing for specifically
> > "permissions changes" on the file system instead of something
> > that would generate much more logging, like full control that
> > includes permission change events ??
>
> Yes, but I also need to audit for more than just permission changes...
> of course all this audit activity is indeed generating much more
> logging. That is why I posted... everyone pretty much understands that
> auditing must be implemented smartly, except the customer... and in my
> experience, a COTS application (Kane Security Monitor) potentially
> gives the project what it wants without a performance hit. It's just
> that the COTS app isn't available anymore.
>
> I'm open to any alternative... whether its COTS, automatically dumping
> the log file into a text file to relieve the pressure on the event
> logging service, or whatever... I just want to meet the customer's
> requirements.
>

Adam
Wed Apr 27 09:12:30 CDT 2005


> permission changes, failed access attempts, policy changes
> will not of themselves cause much overhead

But it does... The mere act of signing on touches lots of objects on
the system. With tracking object access enabled, I get over fifty 560
event ids in the log just from a single signon only. With Dfs and AD
running, there's always some kind of replication going on... that
generates a lot of Account and Object accesses... (the system doesn't
distinguish between user account and system accounts) which in turn
bogs the performance down with all this writing to the log.

I'm not making this stuff up you know... you're more than welcome to
come to my site (I'll foot the airfare) so you can view the event logs
yourself.

Roger
Wed Apr 27 09:48:48 CDT 2005

Sure, agreed then, you are between rock and hard place.
Note that the now mentioned "tracking object access enabled"
was just pulled out of yada, yada. There are definitely some
success audits that should not be used except short-term when
needed for troubleshooting. I suppose then that they are also
wanting success/fail on Global system objects access ?!!?

About the best I can recommend if they are mandating so much
success logging would be to profile a few select systems before
auditing is set as they spec, and then after. Show them the diff
in terms of machine capacity, specifically cpu and disk/io system,
and in terms of log storage space projected to a month, a year.
Ask them to do the cost/benefit on value obtained vs cost of the
increased machine heft. Ask them how they are going to find
what really is important with all the records within a timeframe
that is useful for action. Ask them how they are going to use an
archive of say 2 months of them, how are they going to find some
item of interest. etc.

If they see it in hard number terms it may become a more
normal business decision for them.
I know, it is being mandated by them. The best you can then
do is to inform them. If they stay with their spec, you just
will have to take the "you can lead a horse to water but cannot
make them drink" viewpoint.

As I have said, I doubt that any third party product is going to
be able to capture the record trail more efficiently. I may be
wrong, certainly have been before, and would love to see others
in the NGs post experiences to the contrary; but it just does not
make sense that anything using the same hooks could do any
better or that other software would do much better at hooking
the same events.
If it were not for that I would quickly take you up on the plane
ride - but I doubt I could accomplish much, aside from offering
moral support in your presenting the business case to them,
that if they really want all that then they need to budget to
support the tasks.

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA
"Adam Sandler" <corn29@excite.com> wrote in message
news:1114611150.109795.219800@g14g2000cwa.googlegroups.com...
>
> > permission changes, failed access attempts, policy changes
> > will not of themselves cause much overhead
>
> But it does... The mere act of signing on touches lots of objects on
> the system. With tracking object access enabled, I get over fifty 560
> event ids in the log just from a single signon only. With Dfs and AD
> running, there's always some kind of replication going on... that
> generates a lot of Account and Object accesses... (the system doesn't
> distinguish between user account and system accounts) which in turn
> bogs the performance down with all this writing to the log.
>
> I'm not making this stuff up you know... you're more than welcome to
> come to my site (I'll foot the airfare) so you can view the event logs
> yourself.
>

Roger
Wed Apr 27 10:03:41 CDT 2005

OMG - I had never thought of this before, but they are
making you success audit all disk file accesses ?? that is,
as in, successful access to system32\config\SecEvent.Evt
?? setting up a no-win recursive write demand ?

For success audits they MUST be selective - file access
success audit across the board on the systems' files (not
just the reg+evt config folder) is guaranteed to bog a
system down.

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA
"Adam Sandler" <corn29@excite.com> wrote in message
news:1114611150.109795.219800@g14g2000cwa.googlegroups.com...
>
> > permission changes, failed access attempts, policy changes
> > will not of themselves cause much overhead
>
> But it does... The mere act of signing on touches lots of objects on
> the system. With tracking object access enabled, I get over fifty 560
> event ids in the log just from a single signon only. With Dfs and AD
> running, there's always some kind of replication going on... that
> generates a lot of Account and Object accesses... (the system doesn't
> distinguish between user account and system accounts) which in turn
> bogs the performance down with all this writing to the log.
>
> I'm not making this stuff up you know... you're more than welcome to
> come to my site (I'll foot the airfare) so you can view the event logs
> yourself.
>

Eric
Wed Apr 27 12:37:28 CDT 2005

Security.evt is held open exclusively

The performance impact is probably caused by having to perform two disk
i/o's for every disk i/o (one to do the "real" i/o, and one to record it).

My suggestion is to get a faster system drive (RAID 0 or RAID 0+1), or move
the audit log to a different volume.

I also suggest against auditing reads of any sort, and against auditing
"write attributes" or "write extended attributes". These are the really
high-volume accesses.

Finally I suggest that you don't audit failed access attempts without a plan
for what you're going to do with them. Many failures are normal (Windows
often tries things with more privilege, and if the access fails, retries
automatically and transparently with less privilege- this allows Explorer to
disable menu items in the UI, for instance). Without a baseline the data is
uninterpretable; without a plan the data is just extra perf impact and
storage cost.

Eric

Eric Fitzgerald
Program Manager, Windows Auditing
Microsoft Corporation

--
This information is provided "AS-IS" with no warranty, and confers no
rights.

"Roger Abell" <mvpNOSpam@asu.edu> wrote in message
news:eSeKAnzSFHA.2556@TK2MSFTNGP12.phx.gbl...
> OMG - I had never thought of this before, but they are
> making you success audit all disk file accesses ?? that is,
> as in, successful access to system32\config\SecEvent.Evt
> ?? setting up a no-win recursive write demand ?
>
> For success audits they MUST be selective - file access
> success audit across the board on the systems' files (not
> just the reg+evt config folder) is guaranteed to bog a
> system down.
>
> --
> Roger Abell
> Microsoft MVP (Windows Security)
> MCSE (W2k3,W2k,Nt4) MCDBA
> "Adam Sandler" <corn29@excite.com> wrote in message
> news:1114611150.109795.219800@g14g2000cwa.googlegroups.com...
>>
>> > permission changes, failed access attempts, policy changes
>> > will not of themselves cause much overhead
>>
>> But it does... The mere act of signing on touches lots of objects on
>> the system. With tracking object access enabled, I get over fifty 560
>> event ids in the log just from a single signon only. With Dfs and AD
>> running, there's always some kind of replication going on... that
>> generates a lot of Account and Object accesses... (the system doesn't
>> distinguish between user account and system accounts) which in turn
>> bogs the performance down with all this writing to the log.
>>
>> I'm not making this stuff up you know... you're more than welcome to
>> come to my site (I'll foot the airfare) so you can view the event logs
>> yourself.
>>
>
>

Adam
Fri Apr 29 11:41:18 CDT 2005

Thanks all... much appreciated!

Eric Fitzgerald [MSFT] wrote:
> Security.evt is held open exclusively
>
> The performance impact is probably caused by having to perform two
disk
> i/o's for every disk i/o (one to do the "real" i/o, and one to record
it).
>
> My suggestion is to get a faster system drive (RAID 0 or RAID 0+1),
or move
> the audit log to a different volume.
>
> I also suggest against auditing reads of any sort, and against
auditing
> "write attributes" or "write extended attributes". These are the
really
> high-volume accesses.
>
> Finally I suggest that you don't audit failed access attempts without
a plan
> for what you're going to do with them. Many failures are normal
(Windows
> often tries things with more privilege, and if the access fails,
retries
> automatically and transparently with less privilege- this allows
Explorer to
> disable menu items in the UI, for instance). Without a baseline the
data is
> uninterpretable; without a plan the data is just extra perf impact
and
> storage cost.
>
> Eric
>
> Eric Fitzgerald
> Program Manager, Windows Auditing
> Microsoft Corporation
>
> --
> This information is provided "AS-IS" with no warranty, and confers no

> rights.
>
> "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
> news:eSeKAnzSFHA.2556@TK2MSFTNGP12.phx.gbl...
> > OMG - I had never thought of this before, but they are
> > making you success audit all disk file accesses ?? that is,
> > as in, successful access to system32\config\SecEvent.Evt
> > ?? setting up a no-win recursive write demand ?
> >
> > For success audits they MUST be selective - file access
> > success audit across the board on the systems' files (not
> > just the reg+evt config folder) is guaranteed to bog a
> > system down.
> >
> > --
> > Roger Abell
> > Microsoft MVP (Windows Security)
> > MCSE (W2k3,W2k,Nt4) MCDBA
> > "Adam Sandler" <corn29@excite.com> wrote in message
> > news:1114611150.109795.219800@g14g2000cwa.googlegroups.com...
> >>
> >> > permission changes, failed access attempts, policy changes
> >> > will not of themselves cause much overhead
> >>
> >> But it does... The mere act of signing on touches lots of objects
on
> >> the system. With tracking object access enabled, I get over fifty
560
> >> event ids in the log just from a single signon only. With Dfs and
AD
> >> running, there's always some kind of replication going on... that
> >> generates a lot of Account and Object accesses... (the system
doesn't
> >> distinguish between user account and system accounts) which in
turn
> >> bogs the performance down with all this writing to the log.
> >>
> >> I'm not making this stuff up you know... you're more than welcome
to
> >> come to my site (I'll foot the airfare) so you can view the event
logs
> >> yourself.
> >>
> >
> >

Adam
Wed May 18 16:10:05 CDT 2005


Roger Abell wrote:

> As I have said, I doubt that any third party product is going to
> be able to capture the record trail more efficiently. I may be
> wrong, certainly have been before, and would love to see others
> in the NGs post experiences to the contrary; but it just does not
> make sense that anything using the same hooks could do any
> better or that other software would do much better at hooking
> the same events.

I stumbled across a progam called Winalysis
(http://www.winalysis.com/). Without changing any W2K auditing
settings or GPOs, it tracks all different types of security settings...
DACL changes, GPO changes, registry changes, etc. And since the
Windows configuration isn't changed by the admin, there's no chance of
bogging the log file down and affecting system performance.