Talk:Database audit

message: "what is a database ..." and other basics informations should be removed an replace by a link to the relevant pages; anybody workign with databases should know that you should not double informations ;) (Apply the same principle when using Wikipedia!)  —Preceding unsigned comment added by 207.236.194.136 (talk) 14:09, 11 September 2007 (UTC)
thread_title:  Removal of a few sections 

message: The following sections have been removed from the article as they are (i)wholly unreferenced & (ii) Off-topic and/or How-to. What remains is almost wholly unreferenced and likewise Off-topic/How-to, so probably will also be removed shortly. HrafnTalkStalk(P) 04:58, 22 January 2011 (UTC)
thread_title:  Unreferenced Off-topic & How-to sections 

message: 
Auditors may also use audit software to achieve their audit objectives.  There are a number of approaches including using a log management solution to collect, store and analyse the native audit records produced by the database management systems. Vendors such as SenSage provide log management solutions and database collectors that do not require agents.
Specialized database auditing solutions include: IBM Guardium 7, DB Audit created by SoftTree Technologies, Audit DB by Lumigent Technologies Inc., DbProtect by Application Security, Imperva SecureSphere and Hedgehog Enterprise from Sentrigo.  Some of these solutions rely on a network appliance to inspect and audit SQL traffic sent over the network.  Appliance only approaches are unable to detect activity carried out solely on the server, such as the actions of DBAs.  Other approaches utilize light-weight agents that can monitor all local database activities.  Agents can be implemented to also capture all network activity, making network appliances for monitoring unnecessary.  However it should be pointed out that many of these solutions provide network appliances to capture and store agent reports, even if they are not required for network monitoring.  This off loads the storage/reporting task from the servers and provides the separation of duties (SOD) required by auditors.  Hybrid approaches using both agents and network appliances for sniffing also exist.
IBM Guardium 7 is a widely deployed enterprise-wide solution which provides modules for managing the entire database security lifecyle.  This includes database discovery, sensitive data discovery and classification, Vulnerability Assessment, database activity monitoring, policy based actions including blocking, compliance reporting and workflow management.  Guardium can be deployed through networking monitoring appliances, host monitoring agents or both.  Database support includes Oracle, Microsoft SQL Server, IBM DB2 (mainframe, AS/400 and LUW), Informix, Sybase, MySQL and Teradata.  Guardium can also monitor enterprise applications including Oracle EBS, PeopleSoft, Siebel, JD Edwards, SAP, Cognos and Business Objects for database fraud carried out through the pooled connections of these applications.
Core Audit from Blue Core Research is a Database Auditing and Activity Monitoring (DAM) solution for Oracle. Using a unique collection technology, Core Audit is capable of capturing all database activity including local activity, internal activity (such as stored procedures and triggers) and execution of dynamic SQLs. It has a built-in policy engine, repository, reporting engine and alerting to provide a complete out of the box solution. Core Audit is a software only solution that is easy to install and configure to get a complete picture of database activity.
The DB Audit solution from SoftTree helps ease the problems associated with enabling the built-in audit utilities of most databases.  DB Audit is easy to customize and does not require installation of any additional software or services on the database server and network.  It works with Oracle, Microsoft SQL Server, Sybase ASE, Sybase ASA and IBM DB2. This solution is implemented on the database back-end and eliminates any possibility of back door access that would otherwise be unrecorded.
Lumigent Audit DB provides the comprehensive monitoring and auditing of data access and modifications.  Audit DB’s trusted auditing approach provides an unimpeachable audit trail of who has accessed or modified what data, and supports best auditing practices including segregation of duties. Audit DB supports IBM DB2, Microsoft SQL Server, Oracle and Sybase databases.
Application Security's DbProtect is a centrally-managed enterprise solution for comprehensive database security. In addition to auditing capabilities, DbProtect combines discovery, vulnerability scanning and real-time activity monitoring for a more complete database security solution.
The Sentrigo Hedgehog Enterprise suite includes capabilities for DB audit, real-time database activity monitoring & intrusion prevention, virtual patching, and end-user accountability through pooled connections.  All of the components take advantage of a memory-based, autonomous sensor model, which allows Hedgehog to identify threats from all sources (including intra-database attacks from stored procedures, triggers, and views).  Unlike agent- and appliance-based solutions, the distributed, software-only architecture can be efficiently deployed in virtualized and cloud computing environments.
[End of wholly unreferenced and Off-topic/How-to sections. HrafnTalkStalk(P) 04:58, 22 January 2011 (UTC)
thread_title: Audit solutions

message: Removed to talk per WP:NOT & WP:V. HrafnTalkStalk(P) 06:51, 7 May 2012 (UTC)
thread_title:  Almost-completely-unreferenced how-to sections 

message: ==== Automated auditing ====
In order to ensure that unauthorized users have not accessed the database, the auditor will need to audit user activity.  Auditing user activity provides the auditor with assurance that the policies, procedures, and safeguards that management has enacted are working as intended (Mazer).  This also helps the auditor to identify any violations that may have occurred.
Auditing user activity can be accomplished via continuous data auditing.  Continuous data auditing is the process of monitoring, recording, analyzing, and reporting database activity on a periodic basis.  This is a critical concept because unauthorized access to the database and the information contained within can occur at any time.  If the auditor is using a testing schedule, violators can easily sidestep that schedule.  This is not the case, however, with continuous data auditing.  The auditor and management must be able to identify which behavior is suspicious versus which behavior is routine.  Any behavior that is not identified as routine and valid access to the database must be examined and analyzed further.
Before beginning the audit, the auditor should access the database environment.  This includes identifying and prioritizing the users, data, activities, and applications to be monitored (Mazer).  The Internal Audit Association lists the following as key components of a database audit:
*Create an inventory of all database systems and use classifications.  This should include production and test data. Keep it up-to-date.
*Classify data risk within the database systems.  Monitoring should be prioritized for high, medium, and low risk data.
*Implement an access request process that required database owners to authorize the "roles" granted to database accounts. (roles as in Role Based Access not native database roles).
*Analyse access authority.  Users with higher degrees of access permission should be under higher scrutiny, and any account for which access has been suspended should be monitored to ensure access is denied and attempts are identified.
*Access application coverage.  Determine what applications have built-in controls, and prioritize database auditing accordingly.  All privileged user access must have audit priority. Legacy and custom applications are the next highest priority to consider, followed by the packaged applications.
*Ensure technical safeguards.  Make sure access controls are set properly.
*Audit activity.  Monitor data changes and modifications to the database structure, permission and user changes, and data viewing activities. Consider using network based database activity monitoring appliances instead of native database audit trails.
*Archive, analyse, review, and report audit information.  Reports to auditors and IT managers must communicate relevant audit information, which can be analysed and reviewed to determine if corrective action is required.  Organizations that must retain audit data for long-term use should archive this information with the ability to retrieve relevant data when needed.
The first five steps listed are to be performed by the auditor manually, while the last two steps are best achieved by using an automated solution.
The ideal approach to effectively capture and analyze database activity, is through non-trigger audit agents associated with each database server.  Non-trigger audit agents capture all relevant activity, regardless of the application used (Mazer).  In comparison, database triggers-an automatic procedure that occurs when data has been altered in a table-are not recommended, as database administrators can easily disable them.  The non-trigger database audit agents gather information through three means:
# database transaction log – Each database maintains a database transaction log through the normal course of its operation, which gathers data modifications and other activity. This approach is not practical however as these logs are used for forward recovery and their formats are largely undocumented. Additionally, SQL SELECT access to database objects is not logged.
# the database's built-in native logging– Obtains additional information, such as permission changes and data viewing activities. Each database management system has some type of audit trace capability such as Oracle's Fine Grain Auditing (FGA) capability.
# third-party tools that monitor network and/or system activity looking for database access. Some solutions use agents which enable both local access as well as network access to be monitored; while others are restricted to just monitoring network traffic.  These solutions are typically called database activity monitoring.
[End of Almost-completely-unreferenced how-to sections. HrafnTalkStalk(P) 06:51, 7 May 2012 (UTC)
thread_title: Modes of auditing

message: In order to ensure that unauthorized users have not accessed the database, the auditor will need to audit user activity.  Auditing user activity provides the auditor with assurance that the policies, procedures, and safeguards that management has enacted are working as intended (Mazer).  This also helps the auditor to identify any violations that may have occurred.
Auditing user activity can be accomplished via continuous data auditing.  Continuous data auditing is the process of monitoring, recording, analyzing, and reporting database activity on a periodic basis.  This is a critical concept because unauthorized access to the database and the information contained within can occur at any time.  If the auditor is using a testing schedule, violators can easily sidestep that schedule.  This is not the case, however, with continuous data auditing.  The auditor and management must be able to identify which behavior is suspicious versus which behavior is routine.  Any behavior that is not identified as routine and valid access to the database must be examined and analyzed further.
Before beginning the audit, the auditor should access the database environment.  This includes identifying and prioritizing the users, data, activities, and applications to be monitored (Mazer).  The Internal Audit Association lists the following as key components of a database audit:
*Create an inventory of all database systems and use classifications.  This should include production and test data. Keep it up-to-date.
*Classify data risk within the database systems.  Monitoring should be prioritized for high, medium, and low risk data.
*Implement an access request process that required database owners to authorize the "roles" granted to database accounts. (roles as in Role Based Access not native database roles).
*Analyse access authority.  Users with higher degrees of access permission should be under higher scrutiny, and any account for which access has been suspended should be monitored to ensure access is denied and attempts are identified.
*Access application coverage.  Determine what applications have built-in controls, and prioritize database auditing accordingly.  All privileged user access must have audit priority. Legacy and custom applications are the next highest priority to consider, followed by the packaged applications.
*Ensure technical safeguards.  Make sure access controls are set properly.
*Audit activity.  Monitor data changes and modifications to the database structure, permission and user changes, and data viewing activities. Consider using network based database activity monitoring appliances instead of native database audit trails.
*Archive, analyse, review, and report audit information.  Reports to auditors and IT managers must communicate relevant audit information, which can be analysed and reviewed to determine if corrective action is required.  Organizations that must retain audit data for long-term use should archive this information with the ability to retrieve relevant data when needed.
The first five steps listed are to be performed by the auditor manually, while the last two steps are best achieved by using an automated solution.
The ideal approach to effectively capture and analyze database activity, is through non-trigger audit agents associated with each database server.  Non-trigger audit agents capture all relevant activity, regardless of the application used (Mazer).  In comparison, database triggers-an automatic procedure that occurs when data has been altered in a table-are not recommended, as database administrators can easily disable them.  The non-trigger database audit agents gather information through three means:
# database transaction log – Each database maintains a database transaction log through the normal course of its operation, which gathers data modifications and other activity. This approach is not practical however as these logs are used for forward recovery and their formats are largely undocumented. Additionally, SQL SELECT access to database objects is not logged.
# the database's built-in native logging– Obtains additional information, such as permission changes and data viewing activities. Each database management system has some type of audit trace capability such as Oracle's Fine Grain Auditing (FGA) capability.
# third-party tools that monitor network and/or system activity looking for database access. Some solutions use agents which enable both local access as well as network access to be monitored; while others are restricted to just monitoring network traffic.  These solutions are typically called database activity monitoring.
[End of Almost-completely-unreferenced how-to sections. HrafnTalkStalk(P) 06:51, 7 May 2012 (UTC)
thread_title:  Automated auditing