In the context of on-premises database activity monitoring (DAM), security teams use agents to enable them to see all requests coming into the databases as well as all responses going out of the databases. In other words, the agent-based approach enables database activity monitoring independent of the database system and the database administrator (DBA). The result is a system that collects data access information with as little friction and performance impact as possible to address the same reporting, compliance, and security requirements across an organization’s entire architecture.
What’s good about agent-based DAM
Agents work great with older on-premises, DB2 z/OS and other data repositories, and offer an alternative native logging process. Using agents requires software installation and maintenance, but so long as the number of databases and volume of data requests remains constant, the impact on the performance of collecting data access logs will be negligible.
Historically, agent-based DAM has been used primarily for compliance reporting; and this worked out well because most organizations were almost exclusively concerned with creating audit trails that demonstrated regulatory compliance.
What’s not-so-good about agent-based DAM
Today, many organizations are expanding their focus and need to leverage their DAM to perform more comprehensive security analyses. As security teams need to know more about greater volumes of data activity, across more data repositories the “data footprint” has gotten dramatically bigger. To ensure as little friction and performance impact as possible, organizations are compelled to spend more money on servers, appliances, and agents and on the staff to manage them. At the same time, compliance regulations have gotten more robust and organizations are required to retain data activity requests and responses going back years rather than weeks. The need to retain data also makes compliance even more costly.
Why a kernel-based agent deployment model is problematic
Some large DAM technology providers require a kernel-based agent deployment model. In these instances, external agents affect both CPU and latency for databases.
In a kernel-based agent deployment model, appliance-centric architecture requires data to pass through two or three devices and requires an agent to be installed on each database server. Many large environments require hundreds of appliances (collectors and aggregators). This can get very expensive, very quickly.
While the “on-premises” deployment can be solved without significant technology modifications (just more money and more agents, appliances and servers), Database as a Service (DBaaS) and containerization pose new challenges to agent-based DAM as we know it today.
Traditional DAM is not an option for cloud-managed data
84 percent of companies report that their agent-based DAM tools don’t work in cloud environments. The speed and complexity of cloud platforms, along with widespread adoption of multiple disparate environments make traditional agent-based data logging, monitoring, and auditing far too difficult and expensive to be practical. These tools simply cannot manage data in a way that enables the creation of actionable analytics that are critical to business sustainability and growth.
Any organization in the process of a digital transformation/cloud migration needs to find a new strategy. Any organization with sensitive data already hosted in cloud-managed infrastructures must have the skill set in house to gain the required visibility into the data to ensure security policies are enforced. Failing that, they need a data security solution that enables them to bypass the required skill sets for gaining visibility into cloud-managed infrastructures. The price for not having a solution in place is a far greater risk of non-compliance and of data breaches that go largely unnoticed.
With the adoption of cloud technologies, the rules of data protection have changed and agents can no longer be part of the solution. Cloud-hosted infrastructures, also known as DBaaS, are managed by the cloud provider. As such, management responsibility moves from the data owner to the cloud provider, preventing the owner from installing an agent.
A few workarounds to consider
Monitoring DBaaS with a server-side agent is impossible. If an organization wants to move to a DBaaS, they need to understand that they must rely on a database native audit trail which is enough for many use cases. As humans typically access databases from jump servers, it is possible to install client-side agents on them, making it a hybrid solution – native audit logs for applications and client-side agents for humans.
It is also worth noting that a brand new solution can be created for this use case – a database reverse proxy – it works the same way most WAFs work. The ironic part is that the customer is using a managed database because they wanted to ease their pain and such a solution would require them to manage a new service. Simply put, It moves the pain of managing a database into managing a scalable cluster of reverse-proxies per database instance.
The container challenge
Containerized databases like Kubernetes, OpenShift, etc. are challenging as well. Containers allow a user to run their application (or database for that matter) within an off-the-shelf virtualized operating system. Since containers are launched and terminated quite often, it is impractical to install an agent for every instance.
You may think embedding an agent into the actual database image would be a realistic option. Unfortunately, this interferes with CI/CD process and leaves you with two possible approaches:
- Ignoring the containerization paradigm by forcing an agent upon the database containers
- Leveraging eBpf with UProbes to allow the agent to harness the power of in-memory agents while maintaining a containerized approach and keeping the database container sterilized. It is worth mentioning that eBpf is gaining a lot of popularity in containerization environments these days.
How to make it easier
If you currently use an agent-based DAM tool to observe how users interact with your data, you can simply run an agentless solution over it and get the best of both worlds. This does a couple of things for your organization. First, it enables you to continue to get value from your agent-based DAM tool and avoid the hassle of “rip and replace” with the agentless solution. Second, as you add new data stores – on-premises or cloud-hosted, you can monitor and apply security policies without the expense of additional servers, appliances, and storage space.
Between your DAM tool and your agentless solution, you should be able to ingest all data stores continuously into a single repository and automatically detect policy-violating behavior. This provides complete visibility and dramatically reduces the risk of data breaches. It also eliminates the need for dozens of redundant data security tools and the need to know how to properly configure each cloud-managed environment to secure the data hosted in them.
At the end of the day, just remember the goal of DAM is to collect data access information with as little friction and performance impact as possible and address reporting, compliance, and security requirements across your entire architecture. Layering an agentless solution over your DAM solution enables you to accomplish this. As we have seen, trying to shoehorn existing tools into a new solution more often than not results in negative impact on performance – not to mention the cost and expertise required to pull it off.
Discover more about how agentless DAM can help you keep pace with a growing and more sophisticated data landscape.
Try Imperva for Free
Protect your business for 30 days on Imperva.
