By Cameron Camp
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.