Showing posts with label virtualization security. Show all posts
Showing posts with label virtualization security. Show all posts

Monday, October 8, 2012

Key Properties of Security Virtualization for Virtualization Infrastructure


Independence from security hardware

This is an extension of the everything is software model inherent within virtualization. This creates several operational advantages:
  • Simplifies data center resiliency and failover
  • Reduces upgrade costs
  • Enables "designed-in" security across data center fabric
  • Scaling enhanced due to elimination of architectural constraints
  • Hardware refresh cycle and technology advance is accelerated due to shortened engineering cycle
  • CPU resource pool remains uniform

Faithful reproduction of the physical network security model in the virtual space, including security for both physical and virtual workloads

There's a lot of room for argument here, mainly because we don't necessarily have broad agreement on the physical network security model. I'll assert the following requirements:
  1. Defense in depth
  2. Segmentation of data
  3. Access control
  4. Separation of duties
  5. Deliver at least the top five controls from the SANS top-20:
    • Inventory of Authorized and Unauthorized Devices
    • Inventory of Authorized and Unauthorized Software
    • Secure Configurations for Hardware and Software
    • Continuous Vulnerability Assessment and Remediation
    • Malware Defenses

Additionally, these must all be applied to the network, software objects, management tools, and APIs within the virtualized data center

Follow the operational model of compute virtualization

Security Virtualization must enable scaling, elasticity, mobility, and seamless disaster recovery. It also requires the conversion of security tools into software objects and the creation of new tools and capabilities for deployment, automation, and recovery of security capabilities. These are obvious capabilities for virtualization architects but rather new for security. Until recently we could not have a conversation about the auto-deployment or orchestration of security tools, now there are COTS products ready to do this. This operational model challenges the "security way" of doing things and impacts the culture of security within IT. This requires the transition of security professionals into new operational roles that are more flexible than existing silos within typical large IT organizations.

Compatible with any hypervisor platform

Security virtualization must be platform independent and ultimately it must be capable of protecting virtualized workloads in any data center. While it's not clear how many platforms will be in common use, I assert that there will be at least four:
  • VMware
  • RHEV (KVM)
  • HyperV
  • Mobile (ultimately there will be more than one here)
Therefore as workloads are established on multiple platforms in multiple locations by any given entity, security virtualization must support a single security policy model across these platforms. 

Logical isolation of virtualized workloads, audit and security for control plane elements

At the hypervisor layer or above, everything is software. Logical isolation, rather than some form of physical segmentation, enables diverse workloads of differing sensitivity to run anywhere. Workloads will then run most efficiently when allowed to be run within common resource pools for CPU, Memory, Storage, and Networking. For example, fire walling must control access at the virtual NIC and be configured by policies that are not required to identify layer 3 or 4 attributes. This allows network segmentation of systems that share a single software switch, VLAN, or Host. In addition to isolation, security virtualization must also audit and protect the management objects, tools, and APIs that are utilized to provision, modify, or delete workloads, objects, and resources. In the ideal case, logical isolation enables multi-compartment zoning of workloads with the requisite capabilities for cross-domain security in both private or public clouds. This requires sophisticated capabilities for delineating a zone of trust that both isolates systems and applies common security policies within each specific trust zone, even when this zone spans multiple data centers.

Cloud performance and scale

Large-scale compute clouds are composed of thousands to millions of hypervisor instances. Security virtualization must enable resilient and protected operations at this scale. Security management tools, incident response, control automation, and event analysis must all be modified. This will require new security management architectures, analytics, and closed-loop controls that operate across millions of security objects in multiple locations. Additionally, cloud performance is not just IOPS or CPU cycles, it is also the capability to provision, modify, and decommissions hundreds or more systems with minutes or seconds. Security virtualization also enables security to accelerate operationally.

Open, programmatic security provisioning and control

Security virtualization must be integrated with provisioning, management, and operations of the data center. This must be a set of APIs that will fit into the management stacks developed and developing for each hypervisor platform. Security virtualization vendors will be able to differentiate on performance, complexity, completeness of solution, etc. However, each vendor must be able to interoperate with a common protocol like SCAP and must support their own orchestration by 3rd party or platform tools and management platforms. Specifically the API must, at minimum, support
  • create/modify/delete for security policy elements
  • create/modify/delete of security zones
  • bidirectional updates of inventory attributes
  • bidirectional event communication
  • integration with workflow and incident escalation systems

In closing

Security virtualization has the potential to drastically improve the protection of sensitive data while at the same time simplifying the application of these protective capabilities. As with hardware virtualization, the most effective use of security virtualization will require changes to IT staffing, processes, and procedures. This will be disruptive to the way security "has always been doing it" -- something that is both necessary and good because the way we have been doing it has not been effective.

Wednesday, September 22, 2010

HyperSentry

HyperSentry is a technology that uses IPMI to allow an out-of-band method for checking hypervisor integrity.

IPMI is a backdoor to the system, so it is something that has to be managed carefully. When I did pen-testing I often found that it was not secured properly. That said, it is a very interesting idea.

I think the hardware "root-of-trust" technology: that has been developed by AMD and Intel is also interesting

I think we will see availability of tools, including Catbird, where a combination of these technologies is built-in to the system. I do have to point out that IPMI based checks have been possible for years and yet no one has touted them as a solution for detecting conventional rootkits. I've learned that anything with "IBM" in the release has a certain amount of FUD factor and it may be a year or longer before we see a real capability that can be built into a product.

Perhaps the broader implication is that work like this is common on open-source hypervisors and is much harder to perform on proprietary systems.

Tuesday, February 3, 2009

Heartland Breach

Summary:
  • Level 1 credit card processor fails to prevent data loss effecting hundreds of millions of transactions.
  • Attacker installed tools on Heartland server, inside the PCI trust path network
  • Tools “sniffed” transactions and sent data to system(s) outside North America
“Heartland has said intruders broke into its systems sometime last year and planted malware that they used to steal the card data. The number of compromised cards still isn't known. But Heartland processes more than 100 million transactions per month.”
- Banks, customers feel the fallout of the Heartland breach. 2/2/2009. Jalkumar Vijayan, Computer World, Security.

Breach analysis:

Root cause includes but is not limited to the following:
  • Failure of host based intrusion prevention system (HIPS)
  • Failure of network based intrusion prevention systems (IDP)
  • Failure of configuration management, to detect changes to host and network configuration
  • Failure of separation of duties and detection of abuse or escalation of privilege
  • Failure to segment the processor network and enforce a zone of trust

In summary, Heartland failed to properly implement and enforce defense-in-depth, network segmentation and separation of duties. Remember, Heartland is a level 1 PCI processor and was required by regulation to get this right. This means Heartland's auditors failed.

Solution:

Catbird directly addresses all of the above, except for HIPS. HIPS requires an agent on every end-point, this is not a component of our architecture, which is agent-less by design. Our customers are able to implement and enforce defense-in-depth using Catbird TrustZones™ security policies, virtual infrastructure configuration management and virtual machine tracking technologies. These technologies include but are not limited to:
  • Policy and detection templates for IDP, to monitor and control network flows between zones and intra-machine flows inside a trust zone
  • Policy based configuration monitoring and enforcement using session blocking and quarantine, including quarantine of virtual machines
  • Monitoring of virtual administrator activities and enforcement of dual controls for virtual machine connection to network zones
  • Catbird TrustZones monitor and enforce network segmentation within and between machines on any network, VLAN or port group

In summary, proper deployment of Catbird TrustZones technology would have detected and prevented a data breach like the one that occurred at Heartland.

Friday, December 12, 2008

Guardians? What Guardians?

Yesterday, the New York Times covered the recent arrest of Bernard L. Madoff.

Madoff, a prominent Wall Street Hedge fund manager, has admitted to running a $50 Billion Ponzi scheme.

While law enforcement has been quick to react, the revelation came when Mr. Madoff confessed to an associate. While rival Hedge fund managers had been suspicious that Madoff's results were too good to be true, THE REGULATORS HAD NO CLUE.

Years ago, there were many warnings on and off the Hill. Regulators, economists and many others sounded the alarm that allowing an entire financial industry to exist without regulations was a bad idea. However, the standard responses were: regulations are bad, the market will police itself, we can trust our Hedge fund managers. Well, look at what has happened. AIG failed to accurately assess and hedge their risks. Dozens of financial institutions have gone under and hundreds more are at risk. Hedge fund managers have admitted to running a crooked game.

The lesson is clear, systems and the people who work within them are not self-policing. Shocker. I am sure Machiavelli and Juvenalis are laughing at the continuing naivete of the human race.

Now, right now, we have a very similar pattern emerging in information technology. Institutions around the world are virtualizing like crazy. IT is deploying the vast majority of these virtual infrastructures without any of the protections I recommend here. PCI, HIPAA, SOX, you name it, these IT Groups are putting sensitive data about you and me, valuable data worth billions of dollars is at risk.

Where are the Guardians?

The Guardians are out to lunch, they missed the memo, they drank the Kool-aid from the platform vendors.

People like myself, Chris Hoff, Greg Ness, Ian Pratt, Brandon Baker and many others are sounding the alarm.

It's time for the Guardians to get to work. It's time for the IT security team to get off their butts and start addressing this issue.

Michael

Wednesday, November 12, 2008

Virtual Security and Compliance Webcast

Recorded last week, go here to register and listen (sorry, the sound is ahead of the slides, I am trying to get that fixed).

Shout out to Tarry and everyone else who participated.

Monday, November 10, 2008

Risk mitigation for virtual infrastructures

Virtualization in the Data Center introduces the following: (skip down below)





















EFFECT
RISK
1.Flattens infrastructure and networksUnauthorized network access or communication
2.Adds new operating system and infrastructure layersDenial of service and data security breach due to software defects

3.

Collapses roles and increases privilege of administrators
Escalation of privilege, abuse of privilege
4.
Increases transience, mobility and frequency of change within the data center
Misconfiguration, server sprawl and data security breach

  1. Virtual machine (VM) hosts, clusters and data centers reduce the logical and physical segmentation of systems and networks. This flattening exacerbates the risk of unauthorized access due to reduced visibility of events on the virtualized network.

  2. Mitigation: implement increased monitoring and access controls for each virtualized access layer and network. Monitoring must correlate virtual infrastructure management, network traffic, security events and validation of intra-VM access control policies.

  3. The Hypervisor is a new operating system, which along with hypervisor and virtual infrastructure management tools increases the defect, vulnerability and attack threat surface of the data center.

  4. Mitigation: incorporate all new software and management layers into your vulnerability management system (VMS). The VMS must be mandatory and integrated with automated discovery and validation of virtualized infrastructures.

  5. Like the introduction of DBAs for SQL databases and Domain Administrators for Window’s systems, Virtual Administrators have privileges that allow them to bypass existing controls and effectively access underlying systems and data at the hardware layer.

  6. Mitigation: implement compensating controls to log and audit all Virtual Administrator activities. Introduce dual controls and separation of duties for critical functions. You must deploy tools to perform continuous validation of these secondary controls to detect and prevent abuse of privilege. This will also reduce the risk from virtual machine breakout and hyperjacking.

  7. Servers are now files. Virtual machine mobility, snapshots, roll-backs and other features of virtualization have magnified the rate of change within the data center. This increase in operational velocity leads to increased risk of configuration error, capacity failures and for a security breach due to incorrect configuration or a lapse of controls.

  8. Mitigation: extend configuration and life-cycle management processes to track virtual machines. These processes must be effective regardless of the mobility and non-linear attributes of virtual machines. Configuration management tools must enforce mandatory controls and support correlation of virtual and physical infrastructure configuration attributes – extending from virtual machine internals to external network access layers. Monitor and audit direct access to virtual machines files at the operating system and storage access layers.

Tuesday, May 27, 2008

Virtualization Security Getting Some Attention

My response to "Who Owns Virtualization Security" blog:

Virtualization absolutely presents us with the possibility of avoiding past mistakes and making virtual infrastructure (VI) more secure than the physical infrastructure it replaces.

Why?

  1. Virtual security appliances and hypervisor APIs have made it possible for us to build security into the VI fabric at all layers.
  2. The virtualization platforms give us the tools to automate deployment of primary controls, secondary controls and separation of duties throughout the virtual data center.
  3. Virtualization means we can simplify security management and make true defense-in-depth affordable for everyone.
  4. Secure hypervisors, their APIs and the right application of security smarts means we can build agent-less security that protects against rootkits, spyware and almost all forms of malware.
  5. Virtual security appliances allow us not only to write good security policy but also to automatically enforce policy and provide continuous compliance auditing for the VI.
  6. All of the above means, we can create tools for secure life-cycle, trust zones, trusted data paths and secure management in ways never possible with physical infrastructure.


We (as vendors) have a responsibility to educate the IT community to the myths and realities of VI security. The platform OEMs must recognize that simply saying virtual is more secure than physical – is a disservice to all of their customers. Then, when the manufacturers provide the security community the tools and support we need _and_ intelligently inform the market about real risks, then, and only then can we make virtual more secure than physical.

(more to come)