Wikipedia

Database audit: Difference between revisions

Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
refactor
No edit summary
 
(41 intermediate revisions by 31 users not shown)
Line 1:
{{Verification|date=September 2023}}
<!-- Please do not remove or change this AfD message until the issue is settled -->
{{Article for deletion/dated|page=Database audit|timestamp=20110114190334|year=2011|month=January|day=14|substed=yes|help=off}}
<!-- For administrator use only: {{Old AfD multi|page=Database audit|date=14 January 2011|result='''keep'''}} -->
<!-- End of AfD message, feel free to edit beyond this point -->
{{rescue}}
{{nofootnotes|date=January 2011}}
 
'''Database auditing''' involves [[audit|observing]] a [[database]] so as to be aware of the actions of database [[user (computing)|user]]s. [[Database administrators]] and consultants often set up auditing for security purposes, for example, to ensure that those without the permission to access information do not access it.<ref>
{{cite book
| last = Mullins
| first = Craig
| title = Database administration: the complete guide to practices and procedures
| url = httphttps://books.google.com/books?id=KVHUbiSMYjAC
| accessdate = January =19, 2011-01-19
| year = 2002
| publisher = Addison-Wesley
| isbn = 9780201741292978-0-201-74129-2
| page = 402
| quote = Audit trails help promote data integrity by enabling the detection of ''security'' breaches [...].
| pages = 703
| quote = Audit trails help promote data integrity by enabling the detection of ''security'' breaches [...].
}}
</ref>
 
==Database security==
{{Off-topic|Database security|date=January 2011}}
[[Database]] [[Database security|security]] is a serious issue affecting an organization’s information security, damage, and loss [[#Mookhey|(Mookhey)]]. It is common for an organization to make every effort to lock down their [[computer network|network]], but leave the database vulnerable. It is critical to protect the database from unauthorized access because databases contain 90% of the organization's sensitive information. Unauthorized access into the database could be catastrophic to a company.
 
Companies often do not realize how much risk is associated with the sensitive information within their database until an internal audit is conducted, which gives the details regarding who can access the sensitive data. Tremendous financial losses could result if an employee with access to the sensitive data distributed the confidential information of the business or of its [[customer]]s. Depending on the severity of the security breach, the company’s reputation could be adversely affected, thus resulting in a decline in sales, consumer, and investor confidence.
 
Each organization needs to decide its appropriate level of security. This will require an evaluation of the sensitivity of the data within its database. While considering options to protect the sensitive database information, the organization should ensure that that its privacy protection measures do not interfere with authorized persons obtaining the right data at appropriate times (Nevins). A database security solution should also be application-transparent, meaning that no changes need to be made to the underlying applications. This will provide a faster implementation and lower support costs.
 
Scott Nevins, the author of “Database Security: Protecting Sensitive and Critical Information”, considers making sure that one has a secure audit-trail for tracking and reporting activity around confidential data the key issue when purchasing a database security solution. The author also lists additional topics to consider when selecting a database security technology, such as fast performance, the ability to work across applications, and ease of implementation. IT security experts also recommend selectively encrypting and securing sensitive database information. This process of wrapping each individual data item in a protective security is much more effective than simply building a [[firewall (computing)|firewall]] around the database. With only a firewall protecting the database, if the firewall is penetrated, the data is vulnerable to intruders. Encrypting the data provides an extra layer of protection. Nevins also notes that one of the best ways to develop an effective database security solution is to recognize that securing the data is essential to the company’s reputation, profitability, and critical business objectives.
 
Poor database security is a lead contributor to the incidence of [[identity theft]]; the fewer security measures an organization has in place to protect the database, the higher the incidence of identity theft. Much of the personal information used to commit identity theft - such as Social Security numbers and credit-card or bank-account numbers - is stored in databases. Law-enforcement experts estimate that more than half of all identity theft cases are committed by employees with access to large financial databases (Nevins). That means that more than 50% of identity theft cases are committed by employees within the organization who have access to the database. As more and more security breaches relating to databases occur, [[audit committee]]s are becoming increasingly stringent about protecting customer information.
 
There are currently data-privacy regulations in place that many companies must comply with. These regulations include best-practice requirements and industry guidelines regarding the usage and access to customer data. Data security is no longer an option: government legislation and industry regulations mandate it. Some of the privacy requirements in place for protecting personal information include proper access control, selective encryption of stored data, [[separation of duties]], and centralized independent audit functions (Nevins). . Financial institutions are currently regulated by the Gramm-Leach-Bliley Act ([[GLBA]]), which requires the protection of non-public personal data while in storage and implements a variety of access and security controls. These access and security controls are crucial. A 2002 Computer Crime and Security Survey revealed that over half of the databases in use have some kind of a security breach on a yearly basis. This security breach can cost the organization approximately $4 million dollars in losses. Many organizations will do their best to cover up security breaches within their company so as not to alarm customers and harm profitability. Many professionals in the field believe that there is much more unauthorized access to databases than corporations are willing to admit. In an effort to keep companies from covering up security breaches that occur within their organizations, the state of California recently enacted a law that mandates public disclosure of computer security breaches in which confidential information may have been compromised.
 
With the recent database hacks at companies such as [[Lexis Nexis]] and the loss of [[Bank of America]] data-tapes containing the personal and financial information of over 1.2 million customers, as well as the increase in identity theft, we are likely to see more legislation in the coming months and years regarding data security. But unauthorized access to the database and the misuse of data can be prevented with database security products and new audit procedures. [[Management]] must realize that information security is no longer just an IT function; it is a business necessity that must be grasped by the organization as a whole.
 
==Practical security measures==
{{Off-topic|Database security|date=January 2011}}
From an auditing perspective [[Database security]] can be broken down into the following key categories:
 
*[[Server (computing)|Server]] Security
*Database Connections
*Table Access Control
*Restricting Database Access
 
Server Security:
Server security is the process of limiting the access to the database server. This is one of the most basic and most important components of database security. It is imperative that an organization does not let their database server be visible to the world. If an organization’s database server is supplying information to a web server, then it should be configured to allow connections only from that [[web server]]. Also, every server should be configured to allow only trusted IP addresses.
 
Database Connections:
With regard to database connections, system administrators should not allow immediate unauthenticated updates to a database. If users are allowed to make updates to a database via a [[web page]], the system administrator should validate all updates to makes sure that they are warranted and safe. Also, the system administrator should not allow users to use their designation of “sa” when accessing the database. This gives employees complete access to all of the data stored on the database regardless of whether or not they are authenticated to have such access.
 
Table Access Control:
Table access control is related to an access control list, which is a table that tells a computer operating system which access rights each user has to a particular system object. Table access control has been referred to as one of the most overlooked forms of database security. This is primarily because it is so difficult to apply. In order to properly use Table access control, the system administrator and the database developer will need to collaborate.
 
Restricting Database Access:
Internet based databases have been the most recent targets of attacks, due to their open access or open ports. It is very easy for criminals to conduct a “port scan” to look for ports that are open that popular database systems are using by default [[#Wiedman|(Wiedman)]]. The ports that are used by default can be changed, thus throwing off a criminal looking for open ports set by default. There are additional security measures that can be implemented to prevent open access from the Internet, such as
*Trusted [[IP address]]es – Servers can be configured to answer pings from a list of trusted hosts only.
*Server account disabling – The server ID can be suspended after three password attempts.
*Special tools – Products can be used to send an alert when an external server is attempting to breach the system’s security. One such example is RealSecure by ISS.
 
In previous years, businesses focused on preventing access to their databases via perimeter security. Perimeter security includes items such as firewalls and intrusion detection equipment. The problem with this method, however, is that it protects information from those outside the organization that might attempt to retrieve information from the database. As was stated earlier, the majority of security breaches that occur are by those individuals that are within the organization. As we conclude our discussion of database security, it is important to remember that database security should occur in conjunction with other security technologies, but data protection should be the core element of a complete enterprise security infrastructure (Nevins).
 
==Issues==
{{Howto|date=January 2011}}
The primary security concerns of the auditor when conducting a database audit includes authentication and authorization issues. The following general principles for developing an audit strategy, auditing suspicious database activity, and auditing normal database activity can guide the auditor throughout the audit.
 
General Principles for Developing an Audit Strategy:
*Evaluate your purpose for auditing – In order to have an appropriate auditing strategy and to avoid unnecessary auditing, you must have a clear understanding of the reasons for auditing.
*Audit knowledgeably – In order to prevent unnecessary audit information from cluttering the meaningful information, it is important to audit the minimum number of statements, users, or objects required to get the targeted information.
 
General Principles for Auditing Suspicious Database Activity:
*Audit generally, then specifically – Enable general audit options at first, then use more specific audit options. This will help the auditor gather the evidence required to make concrete conclusions regarding the origins of suspicious database activity.
*Protect the Audit Trail – Protect the audit trail so that audit information cannot be added, changed, or deleted without being audited.
 
General Principles for Auditing Normal Database Activity:
Auditing normal database activity refers to the process of gathering historical information about particular database activities.
*Audit only pertinent actions – In order to avoid cluttering the meaningful information with useless audit information, audit only the targeted database activities.
*Archive audit records and purge the audit trail – After you have collected the required information, archive audit records that are of interest and purge the audit trail of this information.
 
==Modes of auditing==
{{Howto|date=January 2011}}
'''Using an automated database audit solution:'''
 
In order to ensure that unauthorized users are not accessing 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 assess 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).
*Analyze 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.
*Assess 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, analyze, review, and report audit information. Reports to auditors and IT managers must communicate relevant audit information, which can be analyzed 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. Additionall, SQL SELECT access to database objects is not logged.
#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 (DAM) solutions.
'''Data Access Auditing:'''
 
Data access auditing is a surveillance mechanism that watches over access to all sensitive information contained within the database. This mechanism brings only the suspicious activity to the auditor’s attention. As was previously discussed, databases generally organize data into tables containing columns. Access to the data generally occurs through a language called Structured Query Language or [[SQL]]. The perfect data access auditing solution would address the following six questions:
# Who accessed the data?
# When?
# Using what computer program or client software?
# From what location on the network?
# What was the SQL query that accessed the data?
# Was it successful; and if so, how many rows of data were retrieved?
 
The auditor can choose to either audit within the client, audit within the database, or audit between the client and the database. The following graphic depicts these options:
 
<!-- Unsourced image removed: [[Image:Data access auditing.PNG]] -->
 
Auditing within the client involves using the client’s database access tools to obtain a list of the end-user activity that has been performed through the database. In order for the auditor to obtain an adequate audit trail, all data access that occurred would have to have occurred through these client tools. It would be possible for data access to occur outside of this tool; therefore this option is the absolute worst available to the auditor.
 
The second choice involves auditing within the database. There are drawbacks to this approach, primarily due to the limited audit functionality of database management systems ([[DBMS]]), the inconsistency across DBMS types, and the performance penalty that occurs when the audit mechanism is enabled. Auditing within the database is certainly better than auditing within the client, however, the best approach is auditing between the client and the database.
 
Auditing between the client and the database involves auditing the conversations between the clients and the databases. In order to audit the conversations, it is necessary to capture and interpret the conversations that occur between the client and the database. This process can be accomplished using vendor software and is by far the best approach to data access auditing.
 
==Audit solutions==
{{Howto|date=January 2011}}
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: [[Guardium, an IBM Company|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.
 
[[Guardium, an IBM Company|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.
 
==References==
{{Reflist}}
<cite id=Mookhey>KK Mookhey (2005). IT Audit. Vol. 8. Auditing MS SQL Server Security.</cite><br />
<cite id=Nevins>Government Security. Scott C. Nevins, May 9, 2005.</cite><br />
<cite id=Wiedman>Government Security. Blake Wiedman. Database Security (Common-sense Principles). May 9, 2005.</cite><br />
<cite id=Mazer>IT Audit. Vol. 8 Murray Mazer. Database Auditing-Essential
Business Practice for Today’s Risk Management May 19, 2005.</cite><br />
<cite id=Schwartz>Three Good Reasons to Look at Database Security Software November 21, 2007 Mathew Schwartz, IT Compliance Institute</cite>
*[http://www.governmentsecurity.org/articles/Databasesecurityprotectingsensitiveandcriticalinformation.php Government Security. Scott C. Nevins, May 9, 2005.]{{verify credibility|date=January 2011}}
*[http://www.governmentsecurity.org/articles/DatabaseSecurityCommon-sensePrinciples.php Government Security. Blake Wiedman. Database Security (Common-sense Principles). May 9, 2005.]{{verify credibility|date=January 2011}}
*[http://www.governmentsecurity.org/articles/Thedatabasesecurityblanket.php Government Security. Paul Zikopoulos. The Database Security Blanket. May 9, 2005.]{{verify credibility|date=January 2011}}
*[http://www.itcinstitute.com/display.aspx?id=349 Three Good Reasons to Look at Database Security Software. November 21, 2007. Mathew Schwartz.]{{verify credibility|date=January 2011}}
*[http://e.bis.business.utah.edu/ebis_class/2003s/Oracle/database.804/a58397/ch22.html Oracle. 1999. Version 8.0. Auditing Database Use. 9 May 2005.]{{broken citation|date=January 2011}}
*[http://www.softtreetech.com/dbaudit/db_audit_wp.pdf Soft Tree Technologies. DB Audit. May 2005. Soft Tree Technologies. May 17, 2005.]
*[http://www.bluecoreresearch.com/ Blue Core Research, Inc.]{{verify credibility|date=January 2011}}
*[http://www.softmagnet.in/dbsecrets.html ]{{verify credibility|date=January 2011}}
 
==SourceFurther reading==
*Gallegos, F. C. Gonzales, D. Manson, and S. Senft. Information Technology
*Control and Audit. Second Edition. Boca Raton, Florida: CRC Press LLC, 2000.
*Ron Ben-Natan, IBM Gold Consultant and Guardium CTO. Implementing Database Security and Auditing. Digital Press, 2005.
*<cite id=Mookhey>KK Mookhey (2005). IT Audit. Vol. 8. Auditing MS SQL Server Security.</cite>
*<cite id=Mazer>IT Audit. Vol. 8 Murray Mazer. Database Auditing-Essential Business Practice for Today’s Risk Management May 19, 2005.</cite>
 
{{Database}}
Gallegos, F. C. Gonzales, D. Manson, and S. Senft. Information Technology
Control and Audit. Second Edition. Boca Raton, FL: CRC Press LLC, 2000.<br />
Ron Ben-Natan, IBM Gold Consultant and Guardium CTO. Implementing Database Security and Auditing. Digital Press, 2005.
 
{{DEFAULTSORT:Database Audit}}
==Other works==
[[Category:Database security|Audit]]
*[http://www.auditdatabase.com/AuditTools.html AuditDatabase 2006. Free web application that automates the generation of audit triggers.]
[[Category:Types of auditing]]
[[Category:Computer access control]]
 
== Footnotes ==
{{reflist}}
 
{{computer-security-stub}}
{{DEFAULTSORT:Database Audit}}
[[Category:Databases]]
[[Category:Auditing]]
[[Category:Access control]]
[[Category:Data security]]
Retrieved from "https://en.wikipedia.org/wiki/Database_audit"