Dawning of the Age of Caprica: Software-defined Security

I'm giving this talk live at 11:00 PT, Today. Please attend live, or watch it anytime.




--Michael

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.

Interesting Flame News

It's my understanding, Flame made use of a cryptographic weakness in the certificate generation algorithm to create fraudulent certificates and then execute a MITM attack. This is discussed here.

A few thoughts:

1. The NSA deserves their reputation.
2. Further, they were willing to let the world know about this weakness. This denies them further use but also denies it to an adversary
3. This weakness would have allowed them to plant software on just about any Windows system
4. Makes you wonder what else they have up their sleeve (this is deterrence)

--Michael

The Cyber Cold War has Started

We are engaged in a cyber cold-war. The primary adversaries are the US, China, and Russia. China has directed attacks at the US, Russia has targeted former republics, and the US striking at Iran. With respect to the great powers, Mutual Assured Destruction (MAD) is in everyone's mind. The 5th wave nations are all incredibly vulnerable to cyber-attack and as Anonymous and others have shown, no one has even a modestly effective defense.

IMHO, the MAD risk of cyber will keep the major powers in-line, just like it has done with nuclear. However, the cyber-weapon genie is 100 times more difficult to keep in the bottle. We are fast approaching an era where a cult or perhaps even a lone gunman could use Stuxnet or perhaps now Flame as the blue print for a devastating attack on critical infrastructure.

Lastly, these weapons often effect more than their target. Collateral damage, friendly-fire, and blowback are more likely with a cyber-weapon due to the nature of cyberspace and the difficulty of distinguishing friendly systems and networks from those of the adversary.

More here.

Today’s Phish

Like everyone on the planet, I am sent free phish every day. Since I can’t turn these into loaves or wine, I usually don’t waste time on them. Today’s phish caused me to reminisce, and when I reminisce, I get curious, so I looked further. First, here is the phish:

A document was scanned and sent to you using a Hewlett-Packard JET ON4412867SSent to you by: KRYSTIN
Pages : 6
Filetype: Image (.jpeg)  View

Location: NPSK1.4FL.
Device: OP218S5OD2054128Mailprint: d72e6d72-e624bbbb

---

A document was scanned and sent to you using a Hewlett-Packard JET ON4412867S

Sent to you by: KRYSTIN
Pages : 6
Filetype: Image (.jpeg)  View  http://donteverclickalinkinemail.example.com/oCzgKm43/index.html

Location: NPSK1.4FL.
Device: OP218S5OD2054128

Mailprint: d72e6d72-e624bbbb 

Really, I think it's been years since I last saw this type of phish. The initial URL runs through three secondary URLs (a .com, .ro, and .ir) that in turn point to a single host (173.44.136.197). At the time of this phish all three secondaries and the host were alive and serving the scam. The payload when I research the .ro link, the payload (using curl) at 16:43 PDT. The payload reported by another blogger dynamoo. The payload now on .ir link -- note that the folks in IR appear to have now blocked the scam, or are running something else, I am leaving their CGI alone.

According to wepawet the payload contains two vulnerabilities first reported in 2010, here, and here. The Adobe Reader vulnerability applies up to 9.3 and the Microsoft applies to Win2003sp2. So that's a decent target space.

What did I learn today?

• dynamoo
• lastline some of the smart guys involved with wepawet and anubis

A good day.

(updated 4/23)
This phish is harder to detect on my phone, see image :

Hackers force us to make JSF more secure

There's been some commentary on the recent article, "China's Role in JSF's Spiraling Costs." TaoSecurity (Richard Bejtlich’s) has an excellent blog on this, which follows up on a tweet by @4n6ir.

However, I have a different take:

“Before the intrusions were discovered nearly three years ago, Chinese hackers actually sat in on what were supposed to have been secure, online program-progress conferences, the officials say.”

This sounds a lot like “FBI Admits Hacker Group’s Eavesdropping.” So after at least three years we still haven’t learned how to keep our secure conference calls, well, um, actually secure – but that’s a digression.

The article on the Joint Strike Fighter (JSF) goes on: ”…need for redesign of critical equipment. Examples include specialized communications and antenna arrays for stealth aircraft, as well as significant rewriting of software to protect systems vulnerable to hacking.”

The JSF’s software systems had serious vulnerabilities: “Defense analysts note that the JSF’s information system was not designed with cyberespionage, now called advanced persistent threat, in mind.” The JSF’s Multifunction Advanced Data Link (MADL) was dropped entirely because of reported “money issues.”

We were building one of the most “computerized” and “networked” fighter planes in the world. Imagine if the plane went into production with those serious software vulnerabilities and it was open to attack via it’s own aerial network? It’s not like adversaries haven’t already demonstrated their ability to hack our communications channels in the field to hijack drone telemetry, video, and perhaps to crash them.

If there is a silver lining here, it’s that when the JSF does fly it’s systems will be better protected against software vulnerabilities and it won’t be broadcasting a SSID, although a Mach-2 WAP would have been pretty cool.

I’ll tell you what I want, what I really, really want from a Cloud Provider

If you want my business, you better make it fast

Self-service: 7x24 add, remove, change resources, workloads, and connectivity

Elastic: scale up or down automatically within the limits I set

Available: stand up to hurricanes, DDOS, and replication storms. Your mistakes should never be my problem.

If you want my data, you better make it secure

Auditing: network and management

Network – I need to audit and or inspect all the traffic between my systems. This includes but is not limited to traffic between users, systems, and applications even where they share the same physical host and virtual switch.

Management – I need to see all management events that may impact the security or configuration of my systems. This includes but is not limited to privileged access to my systems or data through the hypervisor or cloud management APIs.

Control: policy and assurance

Policy – I need to express and apply security policies via a method that is both human understandable and translatable into a machine-interpreted language.

Assurance – I need to know when an event or incident occurs that violates a policy and I need a method for testing that controls exist and are effective for enforcing my policies.

Metrics: continuous and interoperable

Continuous – Per our agreed standards of measurement I must be able to quantify the security attributes of my system. This may include but is not limited to measurements for: vulnerability, configuration, performance, incident detection, incident response, and incident containment.

Interoperable – All security relevant data and events must be available in a documented machine-readable format. It should either comply with standards such as Cyberscope and SCAP or my preferred GR&C system.

If you want my money, you better not ask for much

Value – Not just cheaper than if I do it myself. Your services should give my organization new capabilities to meet our objectives. These capabilities could include user experience, logistic support, and accessibility …

No lock-in – I should be able to easily move my data and workloads back inside my enterprise or to one of your competitors.

Tell me again where these devices are made?

I’ve been “upgrading” my home infrastructure:

Seagate GoFlex Network Storage
Netgear WNDR3800
(other stuff)

All my toys run linux, so imagine my surprise when this starts showing in my logs:
[LAN access from remote] from 210.51.17.227:40986 to 192.168.35.119:22, Thursday, January 19,2012 16:56:47
[LAN access from remote] from 210.51.17.227:39316 to 192.168.35.119:22, Thursday, January 19,2012 16:56:36
[LAN access from remote] from 210.51.17.227:37023 to 192.168.35.119:22, Thursday, January 19,2012 16:56:32
[LAN access from remote] from 210.51.17.227:34192 to 192.168.35.119:22, Thursday, January 19,2012 16:56:28
[LAN access from remote] from 210.51.17.227:50809 to 192.168.35.119:22, Thursday, January 19,2012 16:56:21
[LAN access from remote] from 210.51.17.227:47558 to 192.168.35.119:22, Thursday, January 19,2012 16:56:16
[LAN access from remote] from 210.51.17.227:44530 to 192.168.35.119:22, Thursday, January 19,2012 16:56:11
[LAN access from remote] from 210.51.17.227:42159 to 192.168.35.119:22, Thursday, January 19,2012 16:56:07
[LAN access from remote] from 210.51.17.227:39236 to 192.168.35.119:22, Thursday, January 19,2012 16:56:02
(repeat about 500 times)

whois 210.51.17.227?
Answer someone inside a /16 registered to Beijing Tongtai IDC of China Netcom.

Turns out my Seagate device was advertising port 22 via upnp and my Netgear was helpfully port mapping it to the Internet.

Go figure.