Traditional vs. Non-Traditional Database Auditing
by Michael Semaniuk - Compliance and Security Solutions Architect at Tizor Systems - Monday, 29 July 2008.
The second type of network-based solution is passive. The network-appliance monitors activity by capturing and evaluating copies of the data stream between clients and the database servers as presented by the network infrastructure of the target environment - similar to the way a network engineer uses a network sniffer to monitor traffic. This is similar to the inline approach, in that it monitors via the network, but its deployment model is fundamentally different. Both analyze the SQL protocol to determine what is relevant and what is not. Passive deployment allows a single appliance to scale to a large number of devices because it is not in the traffic path. Passive deployment eliminates the latency that could be introduced with an inline solution and can be installed without any service interruption.

There are also tradeoffs with a passive solution. There is no ability to alter a response or block activity. Inline solutions and passive solutions handle threats somewhat differently. If an inline solution sees a username combined with an application that it has been told to intercept, it will prevent the network packets from reaching the target. Passive solutions typically reset a session at this point by sending a reset packet to both the client and the server, accomplishing the same goal in a different way.

The network-based approach will do all of the heavy lifting in typical database environments. They monitor and audit activity as it happens without impacting the server itself. But what about encrypted network communications or local console activity, such as database management on the local system via secure shell (SSH), remote desktop protocol (RDP) or console access via the local keyboard and mouse? Network-based solutions generally only understand the native database protocols themselves, leaving a hole in the audit trail. But there are other methods that capture the activity that network-based monitoring misses.

Agent-based and agent-less auditing are used to fill in the gaps left by network-based auditing. Like network-based auditing, agent-based comes in a couple of flavors, depending on the goal of the deployment. Agents can be used to parse database logs (i.e. redo logs), act as a proxy for console or encrypted activity, act as a sniffer to capture console or network activity or as a hybrid. They may utilize some combination of these methods to get the data. Agents, especially hybrids, can potentially do the same things that the network-based approach does by monitoring clients as they access the environment over the network. They can also capture the local and encrypted activity. This gives an agent-based approach a wide set of capabilities. Additionally, some agent technology can present before and after values for fields and, in addition to monitoring SQL activity, may also be able to monitor database configuration files. On the downside, agents can be very heavy on a system. If they do everything to capture the activity and aren’t supplemented by a network-based solution, they will negatively impact the target system, consuming significant CPU, disk and network I/O in order to monitor the activity of interest, and on occasion may require the use of native auditing. Not to mention the need to deploy another database to store audit data.


Email scammers stole $215M from businesses in 14 months

Posted on 29 January 2015.  |  In 14 months there have been nearly 1200 US and a little over 900 non-US victims of BEC scams, and the total money loss reached nearly $215 million.

Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.

Daily digest

Receive a daily digest of the latest security news.

Fri, Jan 30th