Imperva Cyber Community

Handling DAM connectivity with multiple agents requires taking a careful approach to sizing and performance.

When it comes to data-centric security, database administrators have a broad range of tools to choose from.

While the native audit is a popular and easy-to-use solution, it comes with limitations. Native audits only use the database server’s built-in tools, so there is an inherent trade-off between security and performance.

Database activity monitoring (DAM), on the other hand, identifies and reports unauthorized behavior without severely impacting operations or productivity. This gives DAM solutions a valuable edge over native auditing measures.

While DAM solutions avoid dragging down performance and improve compliance, they are also necessarily complex. This is especially true in multi-agent environments, where careful planning is required to make sure every agent enjoys the appropriate level of access.

We’ve taken the time to address some of our customers more pertinent questions concerning Database Activity Monitoring in the Imperva Community. Find out more about how to establish a streamlined DAM solution here.

Important Factors for Multi-Agent DAM Deployment

There are some important factors that security professionals will need to take into account before deploying a DAM solution in a multi-agent environment. Some of the major ones include:

1. Proper Sizing

DAM size is critical for avoiding performance issues during deployment. There are two main factors for determining the size of a DAM deployment:

• Hits Per Second (HPS). This is the number of SQL hits the gateway can accept and process every second. Every gateway has a maximum number of hits per second it can support – so you have to know the model of your gateway and set this figure accordingly.

• Throughput. This refers to the amount of raw data your gateway can accept. It is the sum total of all data being sent by all agents connected to the gateway.

Managing these two factors helps to ensure that audit procedures don’t interfere with database performance.

2. Auditing Best Practices

It’s important that database managers know what data auditors want to audit. This allows everyone involved to limit the scope of an audit to a specific set of databases. This will help compliance in the long run.

Auditors who use the default policy in a DAM environment should only set that policy for a short period of time. The purpose of a default policy is to provide a snapshot of the type of database activity occurring, providing information for audit policy configuration. Using it for more than that is not recommended, because of the amount of data the default policy generates.

Agent Monitoring rules help to exclude data that does not need to be audited. For example, you may wish to exclude database maintenance tasks, since they generally do not fall into the types of processes that compliance audits target. When they do, it dramatically impacts sizing and performance – so everyone should know what to expect beforehand.

3. Organization and Maintenance

In a multi-agent environment, it’s important to archive audit data daily. If possible, try to archive audit data directly from the gateway.

On a weekly basis, you should purge audit data, although this can change. The more data auditors collect in a single audit, the more frequent the purge should be.

During deployment, it’s also important to determine whether agents should be connected to a dedicated gateway or to a gateway cluster. The size and activity of the deployment will determine which connection each agent should have. 

What To Do About Excessive Gateway Traffic

Sometimes there is too much agent-gateway traffic even with agent monitoring rules in place. In most situations, this is due to database maintenance jobs. Fortunately, within Imperva’s system you configure the source ID or process ID  in order to avoid letting the agent send data to the gateway so often.

In order to achieve this, you have to isolate the source of the gateway-bound data. If you can do this, you can establish agent criteria rules that apply to that particular source.

In most cases, this will result in reduced traffic reaching the gateway. This may not be the case if the connection uses a remote desktop protocol (RDP), or if the connections are local. But if either of those is the case, Imperva technical support team can help resolve the issue.

Troubleshooting User Exclusion Using Agent Monitoring Rules

In multi-agent environments, it is often necessary to exclude particular database users from accessing monitoring. For instance, you may wish to exclude a database maintenance user while performing an audit in order to improve performance.

Agent Monitoring Rules settings offer database administrators a great deal of power over the rights and permissions of users. In most cases, you will only need to search for database user in order to grant or revoke these kinds of permissions.

If this does not work at first, it is possible that the user ID corresponds to the operating system user – not the database user, even though both users correspond to the same individual. 

Remember: when searching for multiple match criteria, the logical operator used is “AND”. Search results will only show users whose data corresponds with every search criteria entered.

As long as the username in question is part of the agent-level criteria, you will be able to exclude the user from monitoring. If the username is not part of the agent-level criteria, the database might see the login and create an audit event before the gateway tells the agent to stop monitoring the session. This can result in unnecessary bandwidth usage, so it is generally preferable to use an agent-level rule through Agent Monitoring Rules.

Learn More with Imperva Community