Rational Survivability

James McGovern over at the Enterprise Architect blog wrote a really fantastic Letterman’s Top 10 of mistakes that CIO’s make regarding enterprise security.  I’ve listed his in its entirety below and added a couple mineself… 😉

Use process as a substitute for competence: The answer to every problem is almost always methodology, so you must focus savagely on CMMi and ITIL while not understanding the fact that hackers attack software.

Ostritch Principle:
Since you were so busy aligning with the business which really means
that you are neither a real IT professional nor business professional,
you have spent much of your time perfecting memorization of cliche
phrases and nomenclature and hoping that the problem will go away if
you ignore it.

Putting network engineers in charge of security:
When will you learn that folks with a network background can’t possibly
make your enterprise secure. If a hacker attacks software and steals
data yet you respond with hardware, whom do you really think is going
to win the battle.

Over Rely on your vendors by relabelling them as partners:
You trust your software vendors and outsourcing firms so much that you
won’t even perform due diligence on their staff to understand whether
they have actually received one iota of training

Rely primarily on a firewall and antivirus:
Here is a revelation. Firewalls are not security devices, they are more
for network hygiene. Ever consider that a firewall can’t possibly stop
attacks related to cross site scripting, SQL injection and so on.
Network devices only protect the network and can’t do much nowadays to
protect applications.

Stepping in your own leadership: Authorize reactive, short-term fixes so problems re-emerge rapidly

Thinking that security is expensive while also thinking that CMMi isn’t: Why do you continue to fail to realize how much money their information and organizational reputations are worth.

The only thing you need is an insulting firm to provide you with a strategy:
Fail to deal with the operational aspects of security: make a few fixes
and then not allow the follow through necessary to ensure the problems
stay fixed

Getting it twisted to realize that Business / IT alignment is best accomplished by talking about Security and not SOA:
Failing to understand the relationship of information security to the
business problem — they understand physical security but do not see
the consequences of poor information security. Let’s be honest, your
SOA is all about integration as you aren’t smart enough to do anything
else.

Put people in roles and give them titles, but don’t actually train them: Assign untrained people to maintain security and provide neither the training nor the time to make it possible to do the job.

Here are some of my favorites that I’ve added.  I’ll work on adding the expanded explanations later:

1. Keep talking about threats and vulnerabilities and not about risk
2. Manage your security investments like throw-away CapEx cornflakes and not as a portfolio
3. Maintain that security is a technology issue
4. Awareness initiatives are good for sexual harassment and copier training, not security
5. Security is top secret, we can’t talk about what we do
6. All we need to do is invest just enough to be compliant, we don’t need to be secure
7. We can’t measure security effectiveness
8. Virtualization changes nothing in the security space.
9. We’ve built our three year security strategy and we’re aligned to the business
10. One audit a year from a trusted third party indicates our commitment to security

Got any more?

/Hoff

We had a little chat a few weeks ago at the apparent shock suffered by many a security professional in discovering that the three-legged stool of security was constructed of unequally leveraged legs of C, I and A.

Some reckon that by all practical accounts C, I and A should not be evaluated or assessed in a vacuum, but depending upon your line of business, your line of work and how you view the world, often this is how things get done — we have very siloed organizations, so it leads to siloed decision matrices.

Specifically, availability (or service delivery) in reality — despite what theory and purists espouse — often trumps "security" (the C and I functions.)  As distasteful as that sounds, this is endemic.  From operating systems focused on "usability" rather than security to routing protocols focused on rapid convergence and assumed trust as opposed to secure and authenticated mechanisms.

To wit (from the Renesys Blog):

Pakistan hijacks YouTube

Late in the (UTC) day on 24 February 2008, Pakistan Telecom (AS 17557)
began advertising a small part of YouTube’s (AS 36561) assigned
network. This story is almost as old as BGP. Old hands will recognize
this as, fundamentally, the same problem as the infamous AS 7007 from 1997, a more recent ConEd mistake of early 2006 and even TTNet’s Christmas Eve gift 2004.

Just before 18:48 UTC, Pakistan Telecom, in response to government order to block access to YouTube (see news item)
started advertising a route for 208.65.153.0/24 to its provider, PCCW
(AS 3491). For those unfamiliar with BGP, this is a more specific route
than the ones used by YouTube (208.65.152.0/22), and therefore most
routers would choose to send traffic to Pakistan Telecom for this slice
of YouTube’s network.                           
                              

Yes, this is really a demonstration of unavailability, but what I’m getting at here is that fundamentally, the core routing protocol we depend upon for the backbone Internet transport is roughly governed by the same rules that we depend upon whilst driving down a road separated by nothing more than painted lines…you simply hope/trust that nobody crosses the line and crashes into you head-on.

There is very little preventing someone from re-routing traffic.  This could result in either a denial of service (as the traffic would not reach its destination) or even something akin to an interception, "storage" and eventual forwarding for nefarious means.

So, here we have a case where again we depend upon a protocol that was designed to provide (A)vailability, yet C and I are left floundering in the wings.  We’ll no doubt see another round of folks who will try and evangelize the need for secure BGP — just like secure DNS, secure SMTP, secure…

This will hit deaf ears until we see the same thing happen again…

/Hoff

Read more…

There’s a little bit of serendipity floating about today and timing is everything.

Ed Skoudis (IntelGuardians) and I were chatting last week at ShmooCon regarding his previous research on VM guest escapes in hosted platforms and I raised a concern regarding my use of Parallel shared folders between my hosted XP installation and the underlying OSX host operating system.

I reckoned that this would be a very interesting vector for potential exploitation as it provides a direct pipeline to the underlying host OS and filesystem. 

While this bit of news isn’t about Parallels, it is about VMware’s comparable products (workstation, ACE, player, etc.) and it exploits the same vector.  From Computerworld:

February 24, 2008 (Computerworld)  A critical vulnerability in VMware Inc.’s virtualization software for Windows lets attackers escape the "guest" operating system and modify or add files to the underlying "host" OS, the company has acknowledged.

As of Sunday, there was no patch available for the flaw, which affects VMware’s Windows client virtualization programs, including Workstation, Player and ACE. The company’s virtual machine software for Windows servers, and for Mac- and Linux-based hosts, are not at risk.

The bug was reported by Core Security Technologies, makers of the penetration testing framework CORE IMPACT, said VMware in a security alert issued last Friday. "Exploitation of this vulnerability allows attackers to break out of an isolated Guest system to compromise the underlying Host system that controls it," claimed Core Security.

According to VMware, the bug is in the shared folder feature of its Windows client-based virtualization software. Shared folders lets users access certain files — typically documents and other application-generated files — from the host OS and any virtual machine on that physical system.

"On Windows hosts, if you have configured a VMware host-to-guest shared folder, it is possible for a program running in the guest to gain access to the host’s complete file system and create or modify executable files in sensitive locations," confirmed VMware.

There is currently no patch available.  The mitigation strategy is to disable shared folders.

It’s important to reiterate that this vulnerability does not affect VMware’s Type 1 (bare metal) virtualization platforms such as ESX.  However, on Friday, VMware released fixes for 5 vulnerabilities in ESX, some of which could be exploited to bypass security controls, gain access to data or result in denial of service.

/Hoff

{image from Anthony Martin Escapes}

UPDATE: Coverage of this is being hammed up quite a bit in the press to sound like it’s going to shake the very foundations of virtualization…not so much.  It’s an issue that is reasonably easy to address and represents what can be generally referred to as a relatively small attack surface.  Yes, it reinforces the need to think about VirtSec in the Type 2 (hosted) virtualization world, but as I said in the comments, it really depends upon how and why you’ve deployed client-side virtualization.

Right, so I’m in the UK from the 25th to the 27th. I’ll be tagging my usual suspects, but if you’re up for something in the evening, send me an email [choff @ packetfilter.com] or call my call router and it will find me:
+1.978.631.0302

/Hoff

You’ve no doubt seen the latest handywork of Ed Felten and his team from the Princeton Center for Information Technology Policy regarding cold boot attacks on encryption keys:

Abstract: Contrary to popular assumption, DRAMs used in
most modern computers retain their contents for seconds to minutes
after power is lost, even at operating temperatures and even if removed
from a motherboard. Although DRAMs become less reliable when they are
not refreshed, they are not immediately erased, and their contents
persist sufficiently for malicious (or forensic) acquisition of usable
full-system memory images. We show that this phenomenon limits the
ability of an operating system to protect cryptographic key material
from an attacker with physical access. We use cold reboots to mount
attacks on popular disk encryption systems — BitLocker, FileVault,
dm-crypt, and TrueCrypt — using no special devices or materials. We
experimentally characterize the extent and predictability of memory
remanence and report that remanence times can be increased dramatically
with simple techniques. We offer new algorithms for finding
cryptographic keys in memory images and for correcting errors caused by
bit decay. Though we discuss several strategies for partially
mitigating these risks, we know of no simple remedy that would
eliminate them.

Check out the video below (if you have scripting disabled, here’s the link.)  Fascinating and scary stuff.

Would a TPM implementation mitigate this if they keys weren’t stored (even temporarily) in RAM?

Given the surge lately toward full disk encryption products, I wonder how the market will react to this.  I am interested in both the broad industry impact and response from vendors.  I won’t be surprised if we see new products crop up in a matter of days advertising magical defenses against such attacks as well as vendors scrambling to do damage control.

This might be a bit of a reach, but equally as interesting to me are the potential implications upon DoD/Military crypto standards such as FIPS140.2 ( I believe the draft of 140.3 is circulating…)  In the case of certain products at specific security levels, it’s obvious based on the video that one wouldn’t necessarily need physical access to a crypto module (or RAM) in order to potentially attack it.

It’s always amazing to me when really smart people think of really creative, innovative and (in some cases) obvious ways of examining what we all take for granted.

I was browsing through the RSA 2008 conference agenda today and noticed that two of my talks and topics I blog about constantly were being featured as RSA keynotes!

How cool is that!?

It seems besides the talk I’m already giving, the fine folks @ RSA forgot to tell me that I was to deliver these, also.

They also accidentally attributed the speaking roles to someone else:

I’ll be busy sorting out this correction.

In the meantime, you can just preview them here:

Security and Disruptive Innovation

Information Centricity

😉

/Hoff

Last week I posted about a press release announcing a new product from Catbird called HypervisorShield.

I was having difficulty understanding some of the points raised in the press release/product brief, so I reached out to Michael Berman, Catbird’s CTO (also a blogger,) for a little clarification. 

Michael was kind enough to respond  to the points in my blog posting.

Rather than repost the entire blog entry, I have paraphrased the points Michael responded to and left his comments intact.  I think some of them invite further clarification and I’ll be following up with a Take5 interview shortly.  Some of the answers just beg for a little more digging…

Just to ground us all, here’s the skinny on HypervisorShield:

Catbird, provider of the only comprehensive security solution for virtual and physical networks, and developer of the V-Agent™ virtual appliance, today announced the launch of HypervisorShield™, the industry’s first dedicated comprehensive security solution specifically designed to guard against unauthorized hypervisor network access and attack.

Here are my points and Michael’s responses:

1. Hoff: The press release speaks to HypervisorShield’s ability to protect both the hypervisor and the "hypervisor management network" which I assume is actually referring to the the virtual interface of the management functions like VMware’s service console? Are we talking about protecting the service console or the network functions provided by the vKernel?

   Berman: We’ve built a monitor function that uses VMware APIs to watch for changes to/management of the virtual machines. We also have signature templates and customizable policies for network connections to the service console and the host.
    

2. Hoff: The press release makes it sound like protecting the hypervisor is accomplished via an IPS function that isolates VM’s from one another like Reflex and Blue Lane?

   Berman: With all due respect to our colleagues in this space, intrusion detection and protection is one element.  Catbird combines several technologies to extend separation of duties, dual control and strict change control to the virtual infrastructure. Deploying a signature for VMSA-2008-0001 is nice, but detection or prevention of a rogue virtual center administrator from pulling off a Societe Generale hack is priceless.
    

3. Hoff: What exactly does Catbird do (in partnering with IPS companies like SourceFire) that folks like Reflex and BlueLane? don’t already do.

   Berman: Rather than talk about the differences, let’s talk about the most important similarity.  I think I speak for all of us when I say that it’s like we are in a time warp to 1996 and I am explaining why you need a firewall for your DMZ.  Customers have little appreciation for the magnitude of the threats facing their virtual infrastructure.  Once we get past that, then we can talk about why Catbird is the best. (hint: we’re smarter, faster and stronger)
    

4. Hoff: How do you monitor the Hypervisor?

   Berman: We deploy a virtual machine that hooks into the vSwitch environment and that also monitors the ESX hypervisor via the VI API.
    

5. Hoff: You say in the press release that "hypervisor exploits have grown 35% in the last several years."  Which hypervisor exploits, exactly? You mean exploits against the big, fat, Linux-based service console from VMware? That’s not the hypervisor!

   Berman: I believe that the real threat to the virtual infrastructure comes from the collapse of separation of duties and the breakdown in implicit and explicit security controls within the virtual data center.  That being said, the hypervisor management application is probably the most significant area of the attack surface. If I can own the management GUI I own the hypervisor. If I can pull a stack smash against the ESX web server I own the hypervisor. If some poor shlemozzle configures Samba and NFS for the storage network then they become part of the attack surface too. You can blame us for some hyperbole, but the stat came from the CVE database. Gartner/451/Edison report that virtual infrastructure (VI) is less secure than physical and we have private data that shows people are deploying VI with no network security at all – this is just wrong.  I also think that writing about, or writing off the only risk as being some sort of red pill/blue pill hack is also wrong.

Thanks again to Michael for responding.  Look for a follow-on Take5 shortly to dig a little deeper.

/Hoff

Yo!  BeanSec! is once again upon us.  Wednesday, February 20th, 2008.

BeanSec! is an informal meetup of information security
professionals, researchers and academics in the Greater Boston area
that meets the third Wednesday of each month. 

I say again, BeanSec! is hosted the third Wednesday of every month.  Add it to your calendar.

Come get your grub on.  Lots of good people show up.  Really.

Unlike other meetings, you will not be expected to pay dues, “join
up”, present a zero-day exploit, or defend your dissertation to attend.
Map to the Enormous Room in Cambridge.

Enormous Room: 567 Mass Ave, Cambridge 02139.  Look for the Elephant
on the left door next to the Central Kitchen entrance.  Come upstairs.
We sit on the left hand side…

Don’t worry about being "late" because most people just show up when
they can.  6:30 is a good time to aim for.  We’ll try and save you a
seat.  There is a parking garage across the street and 1 block down or
you can try the streets (or take the T)

In case you’re wondering, we’re getting about 30-40 people on
average per BeanSec!  Weld, 0Day and I have been at this for just over
a year and without actually *doing* anything, it’s turned out swell.

We’ve had some really interesting people of note attend lately (I’m
not going to tell you who…you’ll just have to come and find out.)  At
around 9:00pm or so, the DJ shows up…as do the rather nice looking
people from the Cambridge area, so if that’s your scene, you can geek
out first and then get your thang on.

The food selection is basically high-end finger-food appetizers and
the drinks are really good; an attentive staff and eclectic clientèle
make the joint fun for people watching.  I’ll generally annoy you into
participating somehow, even if it’s just fetching napkins. 😉

See you there.

/Hoff

Martin McKeay took exception to some interesting Microsoft research that suggested that the similar methodologies and tactics used by malicious software such as worms/viri, could also be used as an effective distributed defense against them:

Microsoft researchers are hoping to use "information epidemics" to distribute software patches more efficiently.

Milan Vojnović
and colleagues from Microsoft Research in Cambridge, UK, want to make
useful pieces of information such as software updates behave more like
computer worms: spreading between computers instead of being downloaded
from central servers.

The research may also help defend against malicious types of worm, the researchers say.

Software
worms spread by self-replicating. After infecting one computer they
probe others to find new hosts. Most existing worms randomly probe
computers when looking for new hosts to infect, but that is
inefficient, says Vojnović, because they waste time exploring groups or
"subnets" of computers that contain few uninfected hosts.

Despite the really cool moniker (information epidemic,) this isn’t a particularly novel distribution approach and in fact, we’ve seen malware do this.  However, it is interesting to see that an OS vendor (Microsoft) is continuing to actively engage in research to explore this approach despite the opinions of others who simply claim it’s a bad idea.  I’m not convinced either way, however.

I, for one, am all for resilient computing environments that are aware of their vulnerabilities and can actively defend against them.  I will be interested to see how this new paper builds off of work previously produced on the subject and its corresponding criticism.

Vojnović’s team have designed smarter strategies that can exploit the way some subnets provide richer pickings than others.

The
ideal approach uses prior knowledge of the way uninfected computers are
spread across different subnets. A worm with that information can focus
its attention on the most fruitful subnets – infecting a given
proportion of a network using the smallest possible number of probes.

But
although prior knowledge could be available in some cases – a company
distributing a patch after a previous worm attack, for example –
usually such perfect information will not be available. So the
researchers have also developed strategies that mean the worms can
learn from experience.

In
the best of these, a worm starts by randomly contacting potential new
hosts. After finding one, it uses a more targeted approach, contacting
only other computers in the same subnet. If the worm finds plenty of
uninfected hosts there, it keeps spreading in that subnet, but if not,
it changes tack.

That being the case, here’s some of Martin’s heartburn:

But the problem is, if both beneficial and malign
software show the same basic behavior patterns, how do you
differentiate between the two? And what’s to stop the worm from being
mutated once it’s started, since bad guys will be able to capture the
worms and possibly subverting their programs.

The article isn’t clear on how the worms will secure their network,
but I don’t believe this is the best way to solve the problem that’s
being expressed. The problem being solved here appears to be one of
network traffic spikes caused by the download of patches. We already
have a widely used protocols that solve this problem, bittorrents and
P2P programs. So why create a potentially hazardous situation using
worms when a better solution already exists. Yes, torrents can be
subverted too, but these are problems that we’re a lot closer to
solving than what’s being suggested.

I don’t want something that’s viral infecting my computer, whether
it’s for my benefit or not. The behavior isn’t something to be
encouraged. Maybe there’s a whole lot more to the paper, which hasn’t
been released yet, but I’m not comfortable with the basic idea being
suggested. Worm wars are not the way to secure the network.

I think that some of the points that Martin raises are valid, but I also think that he’s reacting mostly out of fear to the word ‘worm.’  What if we called it "distributed autonomic shielding?" 😉

Some features/functions of our defensive portfolio are going to need to become more self-organizing, autonomic and intelligent and that goes for the distribution of intelligence and disposition, also.  If we’re not going to advocate being offensive, then we should at least be offensively defensive.  This is one way of potentially doing this.

Interestingly, this dovetails into some discussions we’ve had recently with Andy Jaquith and Amrit Williams; the notion of herds or biotic propagation and response are really quite fascinating.  See my post titled "Thinning the Herd & Chlorinating the Gene Pool"

I’ve left out most of the juicy bits of the story so you should go read it and churn on some of the very interesting points raised as part of the discussion.

/Hoff

Update: Schneier thinks this is a lousy idea. That doesn’t move me one direction or the other, but I think this is cementing my opinion that had the author not used the word ‘worm’ in his analog the idea might not be dismissed so quickly…

Also, Wismer via a comment on Martin’s blog pointed to an interesting read from Vesselin Bontchev titled "Are "Good" Computer Viruses Still a Bad Idea?"

Update #2: See the comments section about how I think the use case argued by Schneier et. al. is, um, slightly missing the point.  Strangely enough, check out the Network World article that just popped up which says ""This was not the primary scenario targeted for this research," according to a statement."

Duh.

I had an idea today; a platform upon which to launch a little security parody mixed with an even dose of introspective navel gazing and the odd spoonful of guffaw. The goal is to provide a healthy whilst humorous appraisal of the state of the security industry.

Think InfoSec Sellout meets Monty Python and The Apprentice.

Did you ever see the movie The Star Chamber?

In one of his earlier features,Michael Douglas plays a young judge who
becomes disillusioned with the law system he used to so admire when he finds
himself continually having to aquit particularly dispicable criminals on the
grounds of ridiculous technicalities.

Sensing his frustration,a close friend
(Hal Holbrook) informs him of a secret judicial society that meets and
dishes out the appropriate punishment to those who have escaped the clutches
of the law. 

Inspired by some conversations this last week at ShmooCon with friends new and old, I am creating the Rational Survivability version of the "Security Star Chamber."

I’m going to play the disillusioned (young) judge.  I’ve recruited my not-so-secret judicial society who will, on a weekly basis, cast judgment against a specific market of the security industry; we’ll pick on a segment in a no-holds barred look at the belly of beast, not to dispense punishment, but to rather provide perspective.

If we can’t take ourselves seriously, we may as well play the fool instead.

We expect to communicate our judgment in the most pompous, self-important and aggrandizing style as we possibly can.  Fair and balanced?  This ain’t Fox News (if you can’t sift through that irony, you’re sure as hell going to hate the SSC…)

Here’s the catch…each of the jury has to summarize his or her argument in one sentence.

This may lend itself to some awkward dialog, but it ought to be mildly interesting for sure.

You’ll meet the other judges shortly 😉

/Hoff