Determining Storage Requirements for Auditing

There are two important policy decisions your organization must make to determine how much disk space you need for storing audit data and how frequently you should plan to rotate the active database. Early on in the deployment, your organization should consider the following policy decisions:

• What is your rotation policy?

  To answer this question, you should decide the period of time audited sessions should be available in the active and attached database for auditors to review using the Audit Analyzer console. For example, you might decide that you want to be able to query audited activity for a minimum of 90 days. Alternatively, you might want to define a rotation policy that is based on the size of the database, so that the active database is not allowed to exceed a specific size. For example, you might decide that the database should not exceed 4GB to optimize performance for archiving.

• What is your retention policy?

  To answer this question, you should decide the period of time to keep audited data available in attached databases and the maximum period of time to keep archived audit data available before purging data that’s no longer needed.

To illustrate how these policies affect database management, consider a rotation policy based on a monthly schedule. In this example, an organization decides that audit data must be available for querying for a minimum of 90 days. On the first of each month, a new active database is brought online and the previous 3 months remain available as attached databases to support querying 90 to 120 days of audit data.

In this model, there are four databases online at the same time. This example organization has also decided on a two-stage retention policy. In the first stage, older databases are detached from Audit Analyzer, but remain stored on the SQL Server instance for up to one year. The detached databases provide up to a year of audit history and can be reattached, if that data is needed. In the second stage of the retention policy, the organization archives the audit store databases for up to 3 years. After three years, the oldest data is permanently purged.

Depending on your requirements, you might use a similar retention policy or have different policies based on the session activity you are capturing. For example, you might keep sessions that capture normal user activity for three years, but keep sessions that capture SOX compliance for ten years.

To project your storage requirements, you will need additional information that is specific to your organization, including the number of computers you plan to audit, the number of sessions that are active on audited computers, and whether you record all activity using video capture or only summaries of user activity. To collect this information, you should monitor a pilot deployment. You can then use the information from the pilot deployment as described in Estimating database requirements based on the data you collect to estimate your storage requirements based on how much audit data you are generating. The decisions you make for the rotation and retention policies will help you further refine those estimations as you expand the deployment.

If you define a rotation policy similar to this example, you can automate the monthly database rotation using Delinea application programming interfaces or using scheduled SQL Server jobs or scripts that perform database maintenance operations. For more information, see the Database Management Guide.