January 31st, 2013
We’ve never really been adept at dealing with insider threats. Some organizations have internal detection and monitoring programs, usually aligned with anti-fraud efforts, and some also include more robust forensics programs to look for evidence after-the-fact, but we still have a problem with insiders. With the proliferation of virtualization and cloud computing, we have more trouble than ever. There are two trends I see that explain this.
First, let’s talk virtual environments. A number of things tend to happen in virtual infrastructure that can lead to poor privileged user management and monitoring practices. First, many shops hand virtualization over to an existing admin group, like say…the Windows team. Not a great move, for a lot of reasons. This team still has to manage their existing systems and infrastructure, like Active Directory, DNS, and other platforms and applications. This means they’re part-time virtualization admins, at least for a while. A lot of folks think virtualization is easy, and it is…to a point. But virt technologies can suffer from neglect just like any other systems and apps can, and missing patches and failing to implement configuration controls can have a devastating effect.
But relative to the point of insider control and monitoring, this arrangement usually leads to shortcuts in the way that admins log in and manage the environment Many use generic administrator logins, including the local Admin account on Windows systems running vCenter. AD integration is easy, and highly recommended, and this can help with audit trails, but the practices are still poor – often the full Admin role is assigned within management platforms, with little to no role assignment or separation of duties. Coupled with the minimal logging often done in these environments and potentially generic admin account IDs…a recipe for disaster. One disgruntled admin could take out the entire environment, at least for a while.
What to do about this? Well, the most effective way to approach this issue is to follow a simple regimen, none of which is really new at all:
1. Before deploying virtualization, or even once you have it up and running, set time aside to carefully plan and assign roles for VM admins, cloud admins, network teams, dev and DBA teams, etc. The major vendors, certainly Microsoft and VMware (XenServer role granularity is a bit meh), offer plenty of features to properly create and manage roles.
2. Ensure your management interfaces to all components, including integrated and 3rd-party pieces in vBlock (Cisco UCS, EMC Ionix and Symmetrix, etc) and private cloud (vCloud, System Center varieties, etc.) are on a separate segment that you control very tightly. Ensure you have monitoring in place for this segment (behavioral and traditional signature-based) and also logging on each management platform.
3. Have all administrators manage systems via a bastion host or “jump box”, which can be anything ranging from a Windows server you RDP into to vSphere Management Appliance or commercial options like the HyTrust appliance. Better management control, better audit trails, more of a pain in the ass for admins, but…something you should do.
I see a lot of organizations where security teams aren’t really monitoring the virtualization and cloud admins. This should change, quickly. Speaking of monitoring virtualization and cloud admins, let’s talk about the second trend, which is moving resource to public/hybrid/community clouds. There’s really two ways to look at the insider scenario here. The first way, while pretty defeatist in nature, could certainly resonate with some folks – you’re f**ked. You are pretty much going to have to rely on the cloud provider to do internal monitoring and privileged user management. Well, THAT’s depressing. The other way to look at this is via the standard argument for auditing and assessing providers – via SSAE 16, ISO 27001, and CSA STAR or other questionnaires and responses like those in the CSA CCM and CAIQ. At the moment, there’s really no way to monitor cloud admins actively yourself, so you’re at their mercy technically. You’ll have to rely on what the provider tells you, and continually check to make sure they’re doing what they say they’re doing. A great guide to insider threats in cloud environments has recently been published by the folks at CERT, titled “Insider Threats to Cloud Computing“. It breaks down the different types of cloud admins, what data and systems/apps they have access to (typically), and what you should be looking for when talking to providers about this. I highly recommend reading it.
Hopefully, the insider threat in both virtual and cloud environments is on your radar. If it’s not, it definitely should be.