I'm often asked "How secure is Change Tracking?", and whether it can be referred to as Auditing. The correct answer is:
The Change Tracking log is as secure as the ISA configuration it documents. No more, no less.
No more: Change Tracking is not intended to be a hacker-proof, audit-trail-providing feature. A bad guy with sufficient permissions to change the ISA configuration can use the same permissions to change the log and cover his tracks. Change Tracking will only provide an additional hoop that the prospective bad guy needs to jump through. A determined attacker will be able to overcome it using a number of ways: running a pre-SP1 management console (which doesn't honor Change Tracking settings), changing ISA configuration directly via regedit and/or ADAM-ASDIEdit, tampering with the log using COM scripts, and many other ways.
No less: Change Tracking goes in-line with the ISA configuration permission model. This means that an array administrator can write only to his array's change log, that an enterprise policy editor can write only to his policy's log, that auditor roles can only view change logs, and the an enterprise administrator can write to all logs.
So is this auditing? Now that you have the facts, you can decide whether it fits into your definition of auditing, or more to the point, to the level of security you're aiming for.
-Jonathan Barner, ISA Sustained Engineering Team