ApexSQL Audit SQL auditing paradigm

Having an SQL auditing system in place seems like a straightforward way to harden the security of your SQL data. This way you can at least track the activities and changes done to your SQL Server instance and databases, and depending on the specific auditing system you are using, you might even prevent or roll back malicious or inadvertent changes. However, it’s important to keep in mind that just having a SQL auditing system up and running is not enough. Poorly planned or supervised auditing solutions may lull you into a false sense of security, and actually result in you discovering an information leak or data loss much later than if you had no auditing set up in the first place

June 7, 2013

Database auditing: Tamper-Evident design

ApexSQL Audit has been designed by recognizing the principle that it is impossible to prevent tampering by trusted parties with software-only solutions. Even the worst-case scenario of an attacker obtaining trusted privileges is thus simply reduced to treating all tampering the same, no matter where it comes from. So we’ve applied this principle in all areas that affect auditing, from capturing of audited data all the way to its storage. This has been critical in ensuring not only easy compliance, but actually making tampering obvious

May 28, 2013

SQL auditing – Why We Developed ApexSQL Audit – Part II

As we have seen in the 1st part of this article, in order to solve the overarching problem of easy compliance, we had to solve many different problems main of which were:

  1. Capturing of what-was-executed and of other auditing events of interest
  2. Fault tolerant auditing
  3. Centralized storage of audited data and integrity checks
  4. Centralized reporting
  5. Prevention from tampering of audited data, or exposure when prevention is not possible (e.g. data tampered by trusted user accounts, hacked or otherwise)

In this 2nd part of this article, we will go deeper into solutions that we applied to each of these problems

May 21, 2013

SQL auditing – Why We Developed ApexSQL Audit – Part I

ApexSQL has a long history in SQL Server auditing space with two tools that either prepare databases for auditing, or actually perform auditing. ApexSQL Trigger automates creation of triggers (among other things) that track data modifications on selected tables, while ApexSQL Log reads the database transaction log, extracting data modifications from it. Both of these tools show who-did-what, achieving it in different ways, with their own relative strengths and weaknesses. But these tools also lack the means to satisfy stringent regulations on data access (including who-saw-what), and out-of-the-box prevention from tampering, and that is why we built ApexSQL Audit: to make compliance with auditing regulations easy

May 20, 2013

Database auditing – Introducing ApexSQL Audit

As part of our gearing toward the release of ApexSQL Audit beta, we will be releasing a series of posts addressing issues of why build another auditing tool, what new value it brings and how it achieves it. In the coming weeks we will be releasing posts with following abstracts:

May 14, 2013

ApexSQL Audit: Sneak Peek – Part I

We are announcing the release of a new SQL Server tool – ApexSQL Audit, which will bring a wide range of possibilities for auditing access, changes, and security on SQL Server instances, databases, and objects

April 8, 2013