Research

“It’s anything you want it to be – it’s software!” – Adrian. Database Activity Monitoring software is deployed differently than DAM appliances. Whereas appliances are usually two-tier event collector / manager combinations which divide responsibilities, software deployments are as diverse as customer environments. It might be stand-alone servers installed in multiple geographic locations, loosely coupled confederations each performing different types of monitoring, hub & spoke systems, everything on a single database server, all the way up to N-tier enterprise deployments. It’s more about how the software is configured and how resources are allocated by the customer to address their specific requirements. Most customers use a central management server communicating directly with software agents with collect events. That said, the management server configuration varies from customer to customer, and evolves over time. Most customers divide the management server functions across multiple machines when they need to increase capacity, as requirements grow. Distributing event analysis, storage, management, and reporting across multiple machines enables tuning each machine to its particular task; and provides additional failover capabilities. Large enterprise environments dedicate several servers to analyzing events, linking those with other servers dedicated to relational database storage. This later point – use of relational database storage – is one of the few major differences between software and hardware (appliance) embodiments, and the focus of the most marketing FUD (Fear, Uncertainty, and Doubt) in this category. Some IT folks consider relational storage a benefit, others a detriment, and some a bit of both; so it’s important to understand the tradeoffs. In a nutshell relational storage requires more resources to house and manage data; but in exchange provides much better analysis, integration, deployment, and management capabilities. Understanding the differences in deployment architecture and use of relational storage are key to appreciating software’s advantages. Advantages of software over appliances include: Flexible Deployment: Add resources and tune your platforms specifically to your database environment, taking into account the geographic and logical layout of your network. Whether it’s thousands of small databases or one very large database – one location or thousands – it’s simply a matter of configuration. Software-based DAM offers a half-dozen different deployment architectures, with variations on each to support different environments. If you choose wrong simply reconfigure or add additional resources, rather than needing to buy new appliances. Scalability & Modular Architecture: Software DAM scales in two ways: additional hardware resources and “divide & conquer”. DAM installations scale with processor and memory upgrades, or you can move the installation to a larger new machine to support processing more events. But customers more often choose to scale by partitioning the DAM software deployment across multiple servers – generally placing the DAM engine on one machine, and the relational database on another. This effectively doubles capacity, and each platform can be tuned for its function. This model scales further with multiple event processing engines on the front end, letting the database handle concurrent insertions, or by linking multiple DAM installations via back end database. Each software vendor offers a modular architecture, enabling you to address resource constraints with very good granularity. Relational Storage: Most appliances use flat files to store event data, while software DAM uses relational storage. Flat files are extraordinarily fast at writing new events to disk, supporting higher data capture rates than equivalent software installations. But the additional overhead of the relational platform is not wasted – it provides concurrency, normalization, indexing, backup, partitioning, data encryption, and other services. Insertion rates are lower, while complex reports and forensic analyses are faster. In practice, software installations can directly handle more data than DAM appliances without resorting to third-party tools. Operations: As Securosis just went through a deployment analysis exercise, we found that operations played a surprisingly large part in our decision-making process. Software-based DAM looks and behaves like the applications your operations staff already manages. It also enables you to choose which relational platform to store events on – whether IBM, Oracle, MS SQL Server, MySQL, Derby, or whatever you have. You can deploy on the OS (Linux, HP/UX, Solaris, Windows) and hardware (HP, IBM, Oracle, Dell, etc.) you prefer and already own. There is no need to re-train IT operations staff because management fits within existing processes and systems. You can deploy, tune, and refine the DAM installation as needed, with much greater flexibility to fit your model. Obviously customers who don’t want to manage extra software prefer appliances, but they are dependent on vendors or third party providers for support and tuning, and need to provide VPN access to production networks to enable regular maintenance. Cost: In practice, enterprise customers realize lower costs with software. Companies that have the leverage to buy hardware at discounts and/or own software site licenses can scale DAM across the organization at much lower total cost. Software vendors offer tiered pricing and site licenses once customers reach a certain database threshold. Cost per DAM installation goes down, unlike appliance pricing which is always basically linear. And the flexibility of software allows more efficient deployment of resources. Site licenses provide cost containment for large enterprises that roll out DAM across the entire organization. Midmarket customers typically don’s realize this advantage – at least not to the same extent – but ultimately software costs less than appliances for enterprises. Integration: Theoretically, appliances and software vendors all offer integration with third party services and tools. All the Database Activity Monitoring deployment choices – software, hardware, and virtual appliances – offer integration with workflow, trouble-ticket, log management, and access control systems. Some also provide integration with third-party policy management and reporting services. In practice the software model offers additional integration points that provide more customer options. Most of these additional capabilities are thanks to the underlying relational databases – leveraging additional tools and procedural interfaces. As a result, software DAM deployments provide more options for supporting business analytics, SIEM, storage, load balancing, and redundancy. As I mentioned in the previous post, most of these advantages are not visible during the initial deployment phases

I’ve taught a lot of different classes over the years, and always found the different structures to be pretty interesting. On one end were highly scripted first aid classes that forced us to show crappy “Help! I’ve fallen!” videos produced in 1878 accompanied by a mandatory script. The name of the game was baseline consistency. Lock everything down as tight as possible because you can’t predict the quality of the instructor. Heck, few CPR instructors have ever actually done CPR. I know how I taught changed after I cracked some ribs on mostly-dead people. (No, they don’t wake up and thank you like on Baywatch. And they are never that hot or in bikinis. Well sometimes bikinis, but trust me, you really should dress more appropriately before letting your heart stop.) In a completely different direction is martial arts – which is all about tailoring the experience to best connect with the student over many years. I only ran a solo class for about 6 months while my instructor ran off to start his family, and learned a hell of a lot in the process. Then my IT career hit and that was the end of that. Why bring this up now? I’ve been hip-deep in pulling together all the final materials for the first fully packaged CCSK class we will be teaching June 8-10. For the first time I’m in the position of developing courseware for a structured class, with hands-on, which others will have to teach. The lecture slides are pretty straightforward, although we have to be careful to include plenty of instructor notes and not assume any experience level. The hands-on exercises? Those are a challenge. Building the scenarios wasn’t too tough. But it takes me 5 times longer to convert one into a package someone else can teach from. Everything has to be scripted, packaged, and able to run on everything from a high-end Mac Pro to a freaking Speak-n-Spell. And run a private cloud for 40 students on a Windows ME netbook. A lot more people have performed CPR than have built private clouds. I’m not complaining – it’s a blast to work with my hands again. Although I have always sucked at debugging, and my wife is pissed I keep bleeding on the floor from banging my head against all our walls. But it’s very cool to put everything together like a puzzle. Pre-script pieces in module 1 we won’t need until module 8, just so students can focus on the concepts rather than the command lines, while still giving advanced folks freedom to explore and play so they don’t get bored. I just hope it all works. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted in CSO Magazine. Rich on security and the AWS outage. The Network Security Podcast, Episode 239. With special guest Josh Corman. Favorite Securosis Posts Mike Rothman: Why We Didn’t Pick the Cloud (Mostly) and That’s OK. Who else gives you such a look into the thought processes behind major decisions? Right, no one. You’re welcome. David Mortman: Why We Didn’t Pick the Cloud (Mostly), and That’s Okay. Adrian Lane: Why We Didn’t Pick the Cloud. Operations played a bigger part in the decision process than we expected. Rich: Software vs. Appliance: Software. Other Securosis Posts Incite 4/27/2011: Just Write. Security Benchmarking, Beyond Metrics: Benchmarking in Action. Security Benchmarking, Beyond Metrics: Index. Favorite Outside Posts Mike Rothman: DHS chief: What we learned from Stuxnet. How cool would it have been if Secretary Napolitano had just said “We’re screwed.”? We are, but this article hits on responding faster and more effectively. David Mortman: TCP-clouds, UDP-clouds, “design for fail” and AWS. Because DR is a security issue Adrian Lane: Anatomy of a SQL Injection Attack. Dave Lewis: DHS needs to point finger at self, not private industry. Rich: Richard Bejtlich’s Cooking the Cucko’s Egg. Research Reports and Presentations React Faster and Better: New Approaches for Advanced Incident Response. Measuring and Optimizing Database Security Operations (DBQuant). Network Security in the Age of Any Computing. The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Network Security Operations Quant Metrics Model. Network Security Operations Quant Report. Understanding and Selecting a DLP Solution. Top News and Posts Sony’s PlayStation Network and Qriocity hacked. How SmugMug survived the Amazonpocalypse. Flash + 307 Redirect = Game Over. Amazon Is Amazing! Smells of back-handed compliments, but much of the content is accurate. Share: