• United States

Why Nsure Audit still doesn’t measure up

Aug 21, 20034 mins
Enterprise Applications

* The issue of recording changes in Nsure Audit

I ranted on recently about Novell’s Nsure Audit product due to be available with NetWare 6.5 as well as all future versions of eDirectory. My original newsletter on the product was based on preliminary, beta-version, impressions. Some of the areas most complained about have been changed for the shipping version.

In particular, I said that Nsure audit logs an event when a value within the directory is changed but doesn’t record either the old value or the new value. The shipping product does record the new value. Not the old value, though, and we’ll get to that in a moment.

I also claimed that the time stamp wasn’t very readable (it logs the number of seconds elapsed since Jan. 1, 1970) but that’s only if you wish to view raw data. All of the user interfaces and reporting tools correctly translate that to a more familiar day, date and time (corrected to local time) timestamp when viewed.

When an attribute’s value gets changed and I’m notified that there has been a change I can always check the current value to find out what the value was changed to. But there isn’t anywhere I can look up the old value, the value it was changed from. Here’s the explanation from the product group.

EDirectory allows event listeners to register for events in different ways – two of these are “In line” (synchronous) and “Journal” (asynchronous).  A product that uses the in-line method will actually halt eDirectory’s progress in order to read and record the current, unchanged value of an attribute. Then the event is allowed to proceed and the new value is recorded. The advantage here is you get a record of the new and old values. However, the trade off is that eDirectory has to stop until the log entry is made. With the asynchronous/journal method, which Nsure Audit uses, the event is logged after it’s completed. For that reason, the old value isn’t recorded … *but* eDirectory also doesn’t have to stop operation because of the audit log.

You don’t get a choice, though, it’s been made for you – no recording of the old value.

Another point I made was that not only was there a log entry for a change in an attribute’s value, but there was an entry for every replica the attribute was in. Here’s the product group’s explanation of that.

“[O]ur approach is not to choose the security-related events that we perceive to be important … but to log all the events across the network. With Nsure Audit there is no architecture limitation on collecting very large numbers of events – so why not log events from all replicas (clearly identifying which are replicated and which are not) and have the peace of mind that you’ll be able to pinpoint an attack or a breach in policy anywhere on the system? And the filtering and reporting tools in Nsure Audit allow administrators to quickly evaluate even very large sets of data.”

In other words, Nsure Audit doesn’t give me the old value of an attribute because “the trade off is that eDirectory has to stop until the log entry is made” implying some sort of large slowdown. Yet the relatively worthless (to me) logs of replica updates, which take time, bandwidth and disk space, are included because their affect on performance is trivial.

Also, Nsure Audit gives me the replica data (which I can filter out) because “…our approach is not to choose the security-related events that we perceive to be important…” but the piece of data I consider really valuable (the “old value” that was changed) isn’t available because of a design decision on Novell’s part.

The shipping Nsure Audit is better (marginally) than the beta product, but it still appears to be a relatively new, raw product in need of one or two revisions and – most importantly – some experience in the marketplace before it could be considered a full-fledged auditing tool.