Much has been said in the last five years about how security “needs a seat at the business table”. When this is uttered by a security professional, usually among other security professionals, everyone typically nods and looks at one another knowingly, as if this is a foregone conclusion. Well, it’s not.
Most security teams are still those thankless security nerds that focus on the compliance checkbox. Why? We provide real value…right? We’re defenders of the univer….errr, enterprise!
In the first post of this two-part series, I described security guidance regimes and tools while focusing on VMware. In this part, I extend the conversation to include Citrix and Microsoft, and provide some advice that is applicable across platforms.
Citrix distributes a “User Security Guide” that has valuable security information for configuring the platform, but is not a benchmark suitable for audit purposes.
As virtualization adoption grows, organizations are becoming more attuned to the need to properly configure and lock down virtualization. Virtualization is a complex technology with many facets, and there are numerous types of controls that can be implemented to secure these assets. Most security teams are still developing internal policies and processes to define how virtual infrastructure should be enabled and maintained.
In my last post, I explored the idea of improving information security with virtualization technology, namely in the areas of inventory and configuration management. These are likely the most visible and applicable places for “crossover” improvement, affecting both security and IT operations.
The news these days in security is mostly “doom and gloom”. Just consulting a site like DatalossDB.org is enough to depress even the most hardened security professional. However, there are technology advances happening all around us - some which may lead to new security issues, and others that may help security teams out enormously.
I’m willing to argue that virtualization technology falls into the latter category on most counts. Sure, there are flaws in virtualization software, and new attack vectors (the hypervisor, management tools, etc.).
In last post of this series, I described what a Software-Defined Data Center (SDDC) is, and asked the question, “In a SDDC environment, should security simply be treated as another layer in a software stack? If so, where should it go?” I presented the first scenario for creating Software-Defined Security (SDS), which is basically migrating security from physical to virtual, but found it lacking. Here, I’ll cover a better approach to SDS.
The next way to look at SDDC security is on a “per layer” basis. Security tools are integrated into the hypervisor layer (or compute layer), the storage layer, the networking layer, and the operating system and application layers. This extends the idea of a virtualized control model, with multiple integration points that may be collectively more capable than a single “layer”.
Based on what we’re seeing with organizations implementing heavily virtualized infrastructure, followed by private clouds, hybrid clouds, and all things in-between, it’s a logical conclusion that IT organizations are moving toward a Software-Defined Data Center (SDDC).
What exactly is a software-defined data center?
In my last two posts in this series, I’ve covered hardware abstraction and virtualization, and new technologies like software-defined networking, where data and control planes are separate. Organizations extrapolating this to represent the entirety of a data center environment; everything is virtualized and abstracted.
One of the hottest topics in IT today is software-defined networking, or SDN. SDN separates the control layer for the network from the underlying hardware typically associated with networking functionality. Applications that interact with the network are also separate, and can potentially communicate with the control plane via APIs. The control plane and hardware also communicate with emerging protocols and APIs like OpenFlow. A related concept is Network Functions Virtualization (NFV), where network capabilities like NATing, firewalling and access controls, and intrusion detection are all decoupled from the hardware, as well, usually in a virtual machine or software-based implementation.
If this all sounds confusing, it can be, so here’s the short version - hardware is a commodity, and all network controls and functions are now software somewhere else. That “somewhere else” is where things get interesting, and make for some compelling pros and cons related to security.
There is no question that the footprint of today’s data center is rapidly moving toward the virtual. This changes so many things about the way IT operations functions that we must start asking hard questions about security, continuity, and control of our data. Perhaps one of the biggest questions is this - what happens when everything is a file?
All of our virtual server and desktop instances are simply files run by hypervisors.
The trend toward Software-Defined Data Centers (sometimes abbreviated SDDC) is moving fast. Increasingly, organizations are implementing Software-Defined-Networks (SDN), systems, and application instances, with less focus on hardware-based tools and standalone software installation.
There’s no question that the majority of organizations are virtualizing servers, and increasingly, desktops within their environments. With this shift comes a plethora of new risks. We’re getting better at porting network security platforms to a virtual format, primarily firewalls and intrusion detection and prevention systems. Encryption for virtual and cloud environments is also slowly improving. Another area that seems to be evolving is endpoint security.
In some ways, the challenges of endpoint security are more complex than some others, for a few different reasons. First, endpoint security has to scale across a larger number of systems, in many cases. In addition, traditional endpoint security products are usually agent-based, and consume significant amounts of resources (disk, memory, and CPU). This can easily throttle a shared infrastructure environment.
