Logging is an effective and useful way to determine what is happening on your system. The resulting data can be used for many administrative activities, including troubleshooting, usage characterizations (determining how people are using a system), and determining the cause (or responsible party) of an undesirable event.
However, if you are trying to hold someone accountable for an undesirable event (such as accessing unauthorized information or sabotaging data), standard unprotected logs can be insufficient. This is because individuals can tamper with logs to delete any trace of their actions or to imply another cause for the event. Alternatively, an individual might simply claim that the logs have been tampered with, even if they haven’t. Either case makes it difficult to hold an individual accountable for an event, especially if the individual in question is a system administrator who has access to the logs or has the ability to generate counterfeit events.
For this reason, any logging system that is used for forensic evidence must provide non-repudiation. In other words, the system must, at a minimum, be able to prove that logs have not been tampered with so that a clear tie to the responsible party can be made.
Novell Audit achieves non-repudiation by digitally signing each event that is logged to the data store. To sign an event, the logging application or the Platform Agent hashes the event data and signs the hash with the Logging Application’s private key. The signature is then stored as part of the event. This signature allows the auditor or investigator to determine if an event has been changed. To validate an event, the signature process is simply repeated and the two signatures are compared. If the signatures match, the event is valid; if not, the event has been tampered with.
To allow auditors to determine if an event has been deleted or if the sequence of events has been changed, Novell Audit can chain its event signatures. That is, if event chaining is enabled, each event’s signature includes its own data as well as the signature from the previous event. To validate the event chain, all the logged events for a single application are re-signed and the event signatures are compared. If an event has been deleted or the sequence of events has been changed, the signatures in the chain will not match.
NOTE:Event chaining is enabled either in the Platform Agent’s configuration file, logevent, or the Logging Server object’s property. For information on configuring this option, see Logevent or Section 4.2.3, Logging Server Object Attributes . For information on validating events in Novell Audit Report, see Section 8.2.7, Verifying Event Authenticity in Novell Audit Report.
Using digital signatures and event chaining, auditors can prove with certainty that specific events did in fact occur. If a log includes the events and the events’ digital signatures confirm that the log has not been modified, that log can be used as non-repudiable forensic evidence in disciplinary or legal proceedings.
For example, let’s say that an employee (Joe) has been accused of insider trading. To prove this charge, the company must be able to provide evidence that Joe accessed financial information that then influenced his stock trades. The investigator audits the logs to determine if and when Joe accessed the financial information. The log events show that Joe did indeed access the financial information before making the stock trades in question. If Joe denies the allegation, the investigator can show that digital signatures have been used, that the signatures on the events are valid, and that the logged events indicate that Joe performed the action.