Subscribe by email
Organizations seeking to understand insider activity often rely on logs to detect or trace back anomalous behavior. As enterprise applications become more distributed and encompass more complex functionality, however, the ability to force traditional logging to function as a modern fraud solution becomes untenable for three reasons:
1. Isolated log entries Like your business processes, fraud is a multistep process that typically involves several applications. A transaction entered in one web application, a change to a department database through another, and a query through a mainframe system may all be part of a critical business process or a complex fraud scheme.
By contrast, traditional logging is typically focused on a single application component, such as a database, application server, or messaging subsystem. Each component creates a different log with different levels of information defined in different formats. Information remains siloed and difficult to access.
Isolated log entries are difficult to correlate with events recorded in other logs. Even a server with an out-of-sync clock can complicate the integration of data from two logs—and damage your audit trail. What’s more, logs do not share common data types or formats, so linking data depends on lucky guessing as much as sound logic.
2. Incomplete information Only a fraction of the activity that occurs between employees and applications is captured by traditional logging—which means that a significant amount of potential evidence is missing from your investigations. For example, many logs fail to capture:
Queries and read-only actions
Most existing logs track only updates and lack crucial access information such and queries and read-only actions.
Comprehensive update information
Let’s say a database trigger logs an account update, recording an original monetary value and a new value. While useful for IT system administration, this update is missing information that is crucial to investigators:
The identity of the user performing the update.
The application module used to initiate the update.
Links to events that occurred prior to and following the update.
Even if application developers wanted to include some of this information, it’s often missing at the database level.
3. Information is spread across disparate systems To create a complete audit trail, you must be able to audit access and usage of all your business systems. For example, let’s say you want to audit a single business process—the process of updating customer accounts. This might require you to gather and correlate separate log data from several applications, including a legacy mainframe app, an internally developed client-server app, and a web-based app.
But these applications were developed at different points in time using vastly different technologies. The logging data they produce is formatted differently, with varying levels of detail. Reconciling the differences and then constructing a cohesive and accurate audit trail is tedious, time-consuming, and sometimes impossible. The problem becomes exponentially more complex when you have to track multiple business processes, each dependent on a new set of applications.
Organizations seeking to understand insider activity must expand their view beyond logging to include user activity and unlogged queries if they want a more complete picture of their systems.
