DAM In The Cloud

A common question people ask when considering cloud deployments is whether they can continue to use their database activity monitoring (DAM) platform. Rich Mogull gave a partial answer to that question last week when fielding questions on cloud security, but I wanted to go into a little greater detail on what you should look for. To keep it simple, I am going to keep the discussion focused on infrastructure providers such as Rackspace, Go Grid, and Amazon's EC2.

Out of the box, most DAM products need some tweaking before they work in a cloud environment. The modifications come in two specific areas: the monitoring server that stores and analyzes data, and the agent that does the data collection. Let's look at the agent requirements first.

While virtualization and the cloud are not the same things, every cloud provider relies on virtualization to provide the multitenant, self-sizing, and metered usage characteristics that differentiate cloud computing. Since the database and the operating system are contained within a virtual machine running atop a hypervisor, the features that many kernel and memory-scanning data collectors rely on need to be "ported." In essence, the agent code is altered to take advantage of APIs in the virtual machine manager (Xen, VMWare, HyperV) to maintain functionality and performance. You'll want to verify the vendor has modified their agents to work in your cloud --- most support only Amazon at this time. Added to the mix are vendor-specific idiosyncrasies in IP addressing, security zones, and certificate-based user authentication schemes. This makes it difficult for kernel-based collectors -- as well as data collection based on native tracing and auditing features -- to fully determine user identity and query source.

When considering data collection, it's worth noting, depending on the cloud provider, that network monitoring won't work. A virtual network is not the same as a physical network. The logical topology differs from the physical reality in that virtual machines can communicate through the same physical backplane, or across an undefined physical network. The virtual machine manager can provide APIs from your cloud vendor to plug a network probe in, or it might not. In simpler terms, there is no cloud equivalent to a span port for you to hook into and see all of the traffic. Further, because of multitenant environments, many providers encrypt VLAN traffic, making "promiscuous" modes of listening impossible.

For the server component, there are a couple of important considerations. Obviously, if your DAM provider does not offer software or a virtual server image, you're out of luck. Most DAM customers are served by physical appliances because this has long been the preference until the advent of server virtualization. Luckily, at this point most every DAM provider offers either software or a virtual appliance, so it should not be a problem. How well these are configured for the cloud is an issue and varies per monitoring vendor. At least one vendor offers prebundled Amazon Machine Images, with suitable initializations scripts, and deployment instructions for monitoring and blocking. Others advertise seamless operation in the cloud, but don't provide the scripts, documentation, or prebuilt images to make it easy for customers to use cloud services.

You'll need to pay attention to the virtual location of your DAM server. For example, Amazon's EC2 security model relies on security zones with strictly defined communication ports. If you want to collect data remotely, then you need to understand the communication ports the agent uses -- hopefully it's not port 80. Second, if you want to deploy DAM as a firewall, you'll need to set up your security zones to force the database connections through the DAM server and configure the network to limit database connections to the private network address space.

Finally, if you are using a virtual server image, make sure you get it directly from the vendor. Community AMIs on Amazon, as one example, are known to occasionally have malware prebundled. Vet the image and make sure you update the installer and load scripts to patch and preconfigure settings to your environment. Taking control of your initialization scripts ensures continuity when you spin up new images to support new databases.

There are a few more subtle issues, but those are the important ones to consider. If you are looking at platform-as-a-service, your issues will be different, and you will need to work with your cloud vendor to determine what is allowed.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.