What is database auditing

Database audit tools and their applications

There are four basic platforms that can be used to create, collect and analyze database audits, they are: local database platform, system information/event management and its log management, database activity monitoring and database auditing platform.

1. Local auditing: refers to using a local database for data acquisition, but using the database system itself to store, classify, filter and report events. IBM, Microsoft, Oracle and Sybase all offer different solutions for this situation, but essentially they all seek to obtain the same information. Although the data is typically stored in a database, it can be exported to plain text files or provided as XML data to other applications. The use of native capabilities saves the costs associated with acquiring, deploying, and managing dedicated audit tools, but it imposes additional performance overhead on the database, provides limited management of basic collection and storage, and requires manual management. . Local auditing occurs database-wide and is only applicable to analysis of databases housed within a single facility.

2. SIEM and log management: Security information and event management (SIEM) and similar log management tools have the ability to collect audit files, but they provide more than local database tools. Function. Keep in mind that these tools take much of the load off the database by not incurring the overhead of local auditing, which requires a dedicated server to store and process it. In addition to database audit logs, these tools collect information from network devices, operating systems, firewalls, and applications. SIEM and log management can provide comprehensive reporting, data collection, heterogeneous database support, data aggregation and compression capabilities, which are advantages that local database auditing does not have. Log management systems launched by companies such as LogLogic and Splunk are specifically designed to accommodate large amounts of data and are more focused on management and reporting. SIEM, launched by vendors such as ArcSight and EMC's security division RSA, is designed to be more suitable for near-real-time monitoring of network security devices, allowing for more in-depth analysis of correlations between events and security alarms and other information. However, the distinction between SIEM and log management can become blurry as most vendors offer both platforms, although the two are not fully integrated.

3. DAM: Database activity monitoring platform is designed to monitor database activity for threats and enforce rule compliance controls. Vendors such as Application Security, Fortinet, IBM, Netezza, and Oracle provide event retrieval from heterogeneous databases. Most vendors provide multiple ways to obtain information, including collecting information from multiple parties such as the network, the operating system where the database is located, and database audit logs. DAM tools are designed for high-speed data retrieval and real-time policy enforcement. Like SIEM tools, DAM tools can collect data from heterogeneous databases and multiple data sources and are designed for analysis and alerting. Unlike SIEM, DAM is not designed specifically for databases. It focuses more on database analysis at the application level rather than at the network or system level. In addition to forensic analysis of database operations, DAM also provides advanced functions such as active blocking, virtual patching, filtering and evaluation.

4. Database audit platform: Some database vendors provide specialized databases, which are very similar to log management servers. These databases consist of a dedicated platform that stores log files obtained from local database audits and collects log files from multiple databases into a central location. Some of these platforms also provide heterogeneous database log file collectors. Reporting, forensic analysis, aggregation of log files into a common format, and secure storage are all benefits that such a platform can bring. Although these platforms do not provide multiple data sources, or conduct detailed analysis like DAM, do not have the correlation and analysis capabilities like SIEM, and are not as simple and easy to use as log management, but for those IT operations that focus on database auditing, This is a cost-effective way to generate security reports and store forensic security data.

Database Audit Selection Process

To assist with the database audit selection process, you need to consider the following characteristics of each platform type, as well as the characteristics of each vendor solution. In order of importance, they are as follows:

Data sources: The primary source of the information described in this article is the database audit log, which is created by the database engine. However, audit logs vary from database to database, and in some cases a variety of information can fall into the audit log category. In addition, some platforms can create activity logs of a user's database operations. Although this log is not as accurate as one created by the native platform, it does contain all SELECT statements and has better boot performance. You need to carefully examine what data is available from different data sources and see if the information is sufficient to meet your security, operational and compliance requirements.

Regulatory Compliance: Since compliance with industry and government regulations is the primary driver for adopting a database audit solution, you need to review the policies and product reports provided by the vendor. These reports can help you quickly meet compliance requirements and reduce customization costs.

Deployment: User complaints about all solution descriptions*** are that they need to face many difficulties when deploying. Installation, configuration, policy management, false positive reduction, custom reporting or data management are also issues that users need to solve. It is for this reason that you need to focus your resources on conducting on-the-ground comparisons to evaluate the strengths and weaknesses of tools. Additionally, testing against a deployment of one or two databases is not enough, you need to plan for some scalability testing across multiple databases to simulate real-world scenarios. Of course, this increases the burden of the proof-of-concept process, but it is worth it in the long run, because the UI problems, policy management and architecture choices that the vendors have will only be affected by actual testing. It will show up in the middle.

Performance: It has little to do with the vendor platform, but is more closely related to the data auditing options of the database itself. There are multiple versions and options out there, and the performance of local auditing changes quickly, so you'll want to run some tests. You may also need to balance the data you want to collect with the data you need, and look for ways to have the fewest policies in place to meet the needs, since more policies means more money spent on all systems.

Integration: You need to verify the integration of working processes, trouble-ticketing, system and policy management products with partner suppliers.

Audit logs contain a lot of information that is helpful to auditors, security experts, and database administrators, but they can impact performance. For any novelty that database auditing can provide, you need to understand the burden it may add. Auditing incurs some performance penalties, and depending on how you implement them, the penalties can be significant. However, these issues can be mitigated, and for some business problems, database audit logging is essential for compliance and security analysis.

With the exception of local database auditing (which sits atop database resources), all the tools we describe are deployed as a standalone appliance or software. All database audits provide central policy and data management, reporting, and data aggregation capabilities. SIEM (Security Information and Event Management), log management and database activity monitoring vendors offer a tiered deployment model for scalability, in which multiple servers or devices are distributed across a large IT organization to improve user experience. processing and storage needs.

Aggregated data makes it easy to manage and report on the huge amounts of data being collected. Additionally, information collection is placed on a central server to protect transaction logs from tampering.

Which approach is better for you depends on your needs, the business problem you need to solve, and how much time and money you are willing to invest in solving the problem. The good news is that you have a number of options, such as asking your database administrator to perform local audits of the database to obtain basic information, or aggregating data across thousands of devices.

The above is the detailed content of What is database auditing. For more information, please follow other related articles on the PHP Chinese website!