ApexSQL Audit stores all configuration and audited data, from local and remote SQL Server instances in a centralized repository database named ApexSQLCrd. The packages with captured data are transferred automatically and safely via network, parsed, and data is stored into the central repository database. This approach makes it is easier to backup and protect captured data.
As one of the approaches to attack SQL database auditing is to tamper with the audited data once it has been stored in the central repository database. We designed the central repository database to contain several tamper-evident measures. As a software-only solution cannot provide a tamper-safe design, our goal was to make hiding tampering expensive in effort, time, and resources.
Therefore, the central repository database is designed to:
- Store configuration data in tamper-evident form, and detect all changes made to it. Changes not done through ApexSQL Audit are considered tampering
- Store audited data in tamper-evident form
- Enable fast integrity checks
- Provide fast querying of audited data
To achieve this, we have built multiple tampering-evident measures into the central repository database:
- Customized hashing – we use SHA-2 hash with 256 bits in length (SHA-256), with a specific hash calculation. Even if the attacker manages to reverse engineer the hashing order, it will not help to cover his tracks.
- Row level hashing – hash of all known
field values is calculated and inserted. If there are any row changes, they will be detected if they have not been re-hashed. - Row level versioning – every row gets a unique row version number, i.e. timestamp. If a row is modified, its timestamp is also modified, so the subsequent rows will have an earlier timestamp which is an obvious sign of data tampering.
- Rows are only inserted, never updated or deleted. This allows chained row hashing, where the hash of each row in the chain is calculated based on the hash and timestamp of the previous row in the chain.
