Research

For Database Activity Monitoring, Virtual Appliances result from hardware appliances not fitting into virtualization models. Management, hardware consolidation, resource and network abstraction, and even power savings don’t fit. Infrastructure as a Service (IaaS) disrupts the hardware model. So DAM vendors pack their application stacks into virtual machine images and sell those. It’s a quick win for them, as very few changes are needed, and they escape the limitations of hardware. A virtual appliance is ‘built’ and configured like a hardware appliance, but delivered without the hardware. That means all the software – both third party and vendor created – contained within the hardware appliances is now wrapped in a virtual machine image. This image is run and managed by a Virtual Machine Manager (VMware, Xen, Hyper-V, etc.), but otherwise functions the same as a physical appliance. In terms of benefits, virtual appliances are basically the opposite of hardware appliances. Like the inhabitants of mirror universes in Star Trek, the participants look alike but act very differently. Sure, they share some similarities – such as ease of deployment and lack of hardware dependancies – but many aspects are quite different than software or hardware based DAM. Advantages over physical hardware include: Scale: Taking advantage of the virtual architecture, it’s trivial to spin up new appliances to meet demand. Adding new instances is a simple VMM operation. Multiple instances still collect and process events, and send alerts and event data to a central appliance for processing. You still have to deploy software agents, and manage connections and credentials, of course. Cloud & Virtual Compatibility: A major issue with hardware appliances is their poor fit in cloud and virtual environments. Virtual instances, on the other hand, can be configured and deployed in virtual networks to both monitor and block suspicious activity. Management: Virtual DAM can be managed just like any other virtual machine, within the same operational management framework and tools. Adding resources to the virtual instance is much easier than upgrading hardware. Patching DAM images is easier, quicker, and less disruptive. And it’s easy to move virtual appliances to account for changes in the virtual network topology. Disadvantages include: Performance: This is in stark contrast to hardware appliance performance. Latency and performance are both cited by customers as issues. Not running on dedicated hardware has a cost – resources are neither dedicated nor tuned for DAM workloads. Event processing performance is in line with software, which is not a concern. The more serious issue is disk latency and event transfer speeds, both of which are common complaints. Deployment of virtual DAM is no different than most virtual machines – as always, you must consider storage connection latency and throughput. DAM is particularly susceptible to latency – it is designed to function in real time monitoring – so it’s important to monitor I/O performance and virtual bottlenecks, and adjust accordingly. Elasticity: In practice the VMM is far more elastic the the application – virtual DAM appliances are very easy to replicate, but don’t take full advantage of added resources without reconfiguration. In practice added memory & processing power help, but as with software, virtual appliances require configuration to match customer environments. Cost: Cost is not necessarily either an advantage or a problem, but it is a serious consideration when moving from hardware to a virtual model. Surprisingly, I find that customers using virtual environments have more – albeit smaller – databases. And thus they have more virtual appliances backing those databases. Ultimately, cost depends entirely on the vendor’s licensing model. If you’re paying on a per-appliance or per-database model costs go up. To reduce costs either consolidate database environments or renegotiate pricing. I did not expect to hear about deconsolidation of database images when speaking with customers. But customer references demonstrate that virtual appliances are added to supplement existing hardware deployments – either to fill in capacity or to address virtual networking issues for enterprise customers. Interestingly, there is no trend of phasing either out in favor of the other, but customers stick with the hybrid approach. If you have user or vendor feedback, please comment. Next I will discuss data collection techniques. These are important for a few reasons – most importantly because every DAM deployment relies on a software agent somewhere to collect events. It’s the principal data collection option – so the agent affects performance, management, and separation of duties. Share:

I just wrote up my portions of tomorrow’s Incite, and talked a bit about the importance of standards in product selection. But it’s hard to treat cogently in 30 words, so let me dig into it a bit more here. Mostly because of prevailing opinion on the importance of standards, and to what degree standards support should be a key selection criteria. From the news angle, our pals at the Cloud Security Alliance are driving down the standards path, recently partnering with the ISO to get some standards halo on the CSA Guidance. Selfishly, I’m all for it, mostly because wide acceptance of the CSA Guidance means more demand for the CCSK certification. That means more demand for CCSK training, which Securosis is building. So from that perspective it’s all good. (Note: Our next CCSK training class will be June 8-9 in San Jose, taught by Rich and Adrian.) But if I can see through my own selfish economically driven haze, let’s take a step back to understand where standards matter and where they don’t. Just thinking out loud, here goes: Mature markets: Standards matter in mature markets and mature products. In these, you will likely need to support a heterogeneous environment, because buying criteria are more about price/TCO than functionality. So being able to deal with standard interfaces and protocols to facilitate interoperability is a good thing. Risk averse cultures: Yes, this goes hand in hand with mature markets. Most risk-averse organizations aren’t buying early market products (before standards have gelled), but when they do, if a product does support a “standard,” it reduces their perceived risk. This is what the CSA initiative is about. Folks want legitimacy, and for many people legitimacy = standards. I’m hard pressed to find other situations where standards matter. Did I miss one (or many)? Let me know in the comments. As I tried to describe, standards don’t matter when dealing with emerging threats, where people are still figuring out the best way to solve the problem. Standards also don’t matter if a company tends to buy everything from a single vendor – assuming the vendor actually integrates their stuff, which isn’t a safe assumption (ahem, Big Yellow, ahem. Cough. Barf.) And vendors tend to push their proprietary technology through a standards process for legitimacy. Obviously if the vendor can say their technology is in the process of being standardized, it reduces perceived risk. But the unfortunate truth is that by the time any technology works its way through the standards process, the game has already changed. Twice. So keep that in mind when you are preparing those fancy RFPs asking for all kinds of standards support. Are you asking because you need it, or to reduce your risk? Or maybe just to give the vendor a hard time, which I’m cool with. Share: