Moving security to different digital intersections may serve to reduce the load on the endpoint - thereby avoiding duplicate scans, say, during a malware storm.
However, it is just as important to understand how and when an agile approach to deploying your network defenses in real-time should be performed, and how attacks might dictate that approach. Here we look at best practices, and striking a balance between network load, endpoint load and attack defense agility.
No two attacks are alike. If you have a server room full of payment-processing physical and VM servers, you deploy a very different mix of security tools (or should) than someone deploying thin clients for a call center, and (hopefully) different defense methodologies.
Increasingly, VM environments are housing a broad mix of machines, so you might have a few servers full of accounting database servers, a few servers of Windows desktop VMs, and a smattering of other VMs to round out the enterprise. This is where the need for agility applies.
For example, with VMWare’s vShield App and Endpoint, you can route potentially suspicious traffic across virtualized networks to VM host servers with lots of power for enterprise scanning, and then add and remove endpoints from that pool dynamically, as traffic dictates.
This kind of rethinking about enterprise deployment requires us to reconsider enterprise security in a different context, since not only is moving VMs around the enterprise de rigueur, moving entire networks 'on the fly' is as well, and this means, in turn, that tracking the changes and keeping an appropriate security defense layering schema current becomes much more nuanced, but also much more important. Add that to rolling out Software Defined Networks (SDN), and your enterprise becomes very agile indeed.
But with both network and host agility across a dynamic environment, mistakes are easy to make. Knowing the state of all your endpoints and networks – especially across datacenters – means dashboarding and snapshots (and versioning to be able to replay configuration steps) become paramount. Do you know what the parameters of your perimeters, networks, and clusters of endpoints’ security look like right now? If not, you’re not alone.
Not to worry though. Last year at VMWorld there were many presentations about the real pain and suffering that can accompany a migration to this type of architecture (along with accompanying workarounds). And while you may understand security of old static systems, it is not obvious that you will be able to manage a more dynamic environment until you learn and understand the tools and can fully understand each of the missions behind groups of VMs scattered around the enterprise.
So it’s best to roll out a small mockup of the eventual architecture you want to migrate to, and even create some pseudo-real workloads (of non-critical tasks) and spin it all up and watch what happens. In this way you can establish a Phase A mockup to stage, then roll to a Phase B, which is exposed to more traffic and more potentially hostile traffic. During this exercise you can start instrumenting and tuning your sensors for the right amount of threat intelligence for a given environment. Then, when you are ready to move into production, you’ll have a fairly good idea of what the pinch points and strengths are surrounding your system. You’ll also know what loads different systems can handle, and where best to locate your security sensors.
Ten years or so ago when virtual machines were in their nascent and emergent forms, no one thought there would be a strong need to engage in this level of management. But in today’s environment, when the technology has proven itself in heavy, continuous and continually changing environments, you may want to think twice about ramping up a full production environment without really understanding your security stance, and you only get there by testing, not just fire-and-forget.
