Detecting data tampering and verifying session integrity

When you create your audit store database, you have the option to enable data integrity checking. Data integrity checking provides the ability to detect if auditing data has been tampered with.

For example, data integrity checking can detect if a user who has write privileges over the Audit Store database directly manipulates the audited session data by making a direct connection to the Microsoft SQL Server database.

Session data that is stored in audit store databases is typically accessible to database administrators and/or database owners in an unrestricted fashion. For these users with write privileges on the audit store database, it’s fairly easy to tamper with data in such a way that it can help manipulate the outcome of an AQL query.

For example, someone could change the searchable tags in such a way so that the session is never returned by a query. Or, someone could remove suspicious activity from a recorded session, such as by changing the list of commands that are executed or changing the command output.

Note:   Data integrity checking cannot detect tampering if a database administrator deletes an entire session or database. Also, data integrity checking is not yet available for audit trail events.

Once you enable data integrity checking, you can do the following:

  • Use the Audit Analyzer console or a PowerShell cmdlet to check the integrity of audited sessions.
  • Determine if any data in the following tables has been modified and where it was modified:
    • Session
    • RawData
    • Command
    • SyscallCommand
    • SyscallFilemon
    • WashData
    • WashEvent
  • Determine if any database rows belonging to an audited session were permanently deleted.

If you have not enabled an audit store database for data integrity checking and you try to check session integrity in Audit Analyzer, an error message appears.