Rational Survivability

Alan Shimel pointed us to an interesting article written by Matt Hines in his post here regarding the "herd intelligence" approach toward security.  He followed it up here. 

All in all, I think both the original article that Andy Jaquith was quoted in as well as Alan’s interpretations shed an interesting light on a problem solving perspective.

I’ve got a couple of comments on Matt and Alan’s scribbles.

I like the notion of swarms/herds.  The picture to the right from Science News describes the
notion of "rapid response," wherein "mathematical modeling is
explaining how a school of fish can quickly change shape in reaction to
a predator."  If you’ve ever seen this in the wild or even in film,
it’s an incredible thing to see in action.

It should then come as no surprise that I think that trying to solve the "security problem" is more efficiently performed (assuming one preserves the current construct of detection and prevention mechanisms) by distributing both functions and coordinating activity as part of an intelligent "groupthink" even when executed locally.  This is exactly what I was getting at in my "useful predictions" post for 2008:

Grid and distributed utility computing models will start to creep into security
A
really interesting by-product of the "cloud compute" model is that as
data, storage, networking, processing, etc. get distributed, so shall
security.  In the grid model, one doesn’t care where the actions take
place so long as service levels are met and the experiential and
business requirements are delivered.  Security should be thought of in
exactly the same way. 

The notion that you can point to a
physical box and say it performs function ‘X’ is so last Tuesday.
Virtualization already tells us this.  So, imagine if your security
processing isn’t performed by a monolithic appliance but instead is
contributed to in a self-organizing fashion wherein the entire
ecosystem (network, hosts, platforms, etc.) all contribute in the
identification of threats and vulnerabilities as well as function to
contain, quarantine and remediate policy exceptions.

Sort
of sounds like that "self-defending network" schpiel, but not focused
on the network and with common telemetry and distributed processing of
the problem.
Check out Red Lambda’s cGrid technology for an interesting view of this model.

This basically means that we should distribute the sampling, detection and prevention functions across the entire networked ecosystem, not just to dedicated security appliances; each of the end nodes should communicate using a standard signaling and telemetry protocol so that common threat, vulnerability and effective disposition can be communicated up and downstream to one another and one or more management facilities.

This is what Andy was referring to when he said:

As part of the effort, security vendors may also need to begin sharing more of that information with their rivals to create a larger network effect for thwarting malware on a global basis, according to the expert.

It
may be hard to convince rival vendors to work together because of the
perception that it could lessen differentiation between their
respective products and services, but if the process clearly aids on
the process of quelling the rising tide of new malware strains, the
software makers may have little choice other than to partner, he said.

Secondly, Andy suggested that basically every end-node would effectively become its own honeypot:

"By
turning every endpoint into a malware collector, the herd network
effectively turns into a giant honeypot that can see more than existing
monitoring networks," said Jaquith. "Scale enables the herd to counter
malware authors’ strategy of spraying huge volumes of unique malware
samples with, in essence, an Internet-sized sensor network."

I couldn’t agree more!  This is the sort of thing that I was getting at back in August when I was chatting with Lance Spitzner regarding using VM’s for honeypots on distributed end nodes:

I clarified that what I meant was actually integrating a
HoneyPot running in a VM on a production host as part of a standardized
deployment model for virtualized environments.  I suggested that this
would integrate into the data collection and analysis models the same
was as a "regular" physical HoneyPot machine, but could utilize some of
the capabilities built into the VMM/HV’s vSwitch to actually make the
virtualization of a single HoneyPot across an entire collection of VM’s
on a single physical host.

Thirdly, the notion of information sharing across customers has been implemented cross-sectionally in industry verticals with the advent of the ISAC’s such as the Financial Services Information Sharing and Analysis Center which seeks to inform and ultimately leverage distributed information gathering and sharing to protect it’s subscribing members.  Generally-available services like Symantec’s DeepSight have also tried to accomplish similar goals.

Unfortunately, these offerings generally lack the capacity to garner ubiquitous data gathering and real-time enforcement capabilities.

As Matt pointed out in his article, gaining actionable intelligence on the monstrous amount of telemetric data from participating end nodes means that there is a need to really prune for false positives.  This is the trade-off between simply collecting data and actually applying intelligence at the end-node and effecting disposition. 

This requires technology that we’re starting to see emerge with a small enough footprint when paired with the compute power we have in endpoints today. 

Finally, as the "network" (which means the infrastructure as well as the "extrastructure" delivered by services in the cloud) gains more intelligence and information-centric granularity, it will pick up some of the slack — at least from the perspective of sloughing off the low-hanging fruit by using similar concepts.

I am hopeful that as we gain more information-centric footholds, we shouldn’t actually be worried about responding to every threat but rather only those that might impact the most important assets we seek to protect. 

Ultimately the end-node is really irrelevant from a protection perspective as it should really be little more than a presentation facility; the information is what matters.  As we continue to make progress toward more resilient operating systems leveraging encryption and mutual authentication within communities of interest/trust, we’ll start to become more resilient and information assured.

The sharing of telemetry to allow these detective and preventative/protective capabilities to self-organize and perform intelligent offensive/evasive actions will evolve naturally as part of this process.

Mooooooo.

/Hoff

I’m swamped right now and have about 30 tabs open in Mozilla referencing things I expected to blog about but simply haven’t had the time to.  Rather than bloat Mozilla’s memory consumption further and lose these, I figured I’d jot them down.

Yes, I should use any number of the services available to track these sorts of things for this very purpose, but I’m just old fashioned, I guess…

Perhaps you’ll find these snippets interesting, also.

• Princeton University Center for Information Technology Policy: Computing In the Cloud Workshop – I really want to go to this
• Ten Virtualization Vendors to watch in 2008 – Management & Security top the list
• Google as predicted in 1964 – Cool!
• Forrester lays out 10 reasons why IT shouldn’t support the iPhone – Get over yourself, it’ll happen anyway.
• How to manage your multivendor firewalls like a pro – This is a nasty problem in large enterprises.
• Unix admin tries to axe California power grid – Forget SCADA attacks, we need dual authentication for the EPO button!
• Is Google your next hosted security partner? – Don’t say I didn’t tell you so…
• Scott Berinato’s top 10 data breaches of 2007 – Hurry, there’s still time for more!
• Virtual machine sprawl will challenge IT management skills – Um ,yup.
• Stiennon’s 2008 Predictions are so right, they happen in 2007. That’s all I’m gonna say about that.
• Anton’s excited about Ranum’s rants on stuff we’ve been arguing about for 10 years – Arguing about stateful inspection is so last decade.
• DIY "secure virtual machine network in a box" – Holy crap.  The end of the world is nigh!
• Measuring the return on IT Security Investments – Intel does a lovely job with this.  Hat tip to Lindstrom.
• Information security strategies fail to meet corporate needs – Ernst & Young survey
• NSA’s Central Security Service: Security Configuration Guides – Good resource for config. baselines.
• No browser for you today! – Pixar’s "extreme" security policies
• Mobile & Wireless: 2007’s biggest emerging technology disappointments – Sigh.
• Data Centrism, De-Perimeterization, and fanatacism – Didn’t we cover this already?
• Jericho still speaking in Tongues – …I guess not!
• You can’t buy "just a firewall" anymore – Don’t look now, it’s UTM!
• Charlie Giancarlo resigns from Cisco – Buy stock in wherever he goes!
• Orkut XSS Worm – If Stiennon can do it, so can I!  Told ya so…
• Backdoors in software distribution points – The Chris’ from Veracode tell us why MD5 ain’t your friend
• 8 Bold predictions on Google’s next moves – Good read; some I’ve blogged about.
• Security’s Top 5 priorities – More technology…that’s the problem.
• Common Criteria = Safe? – Eric Bidstrup’s very good read

Sadly I may not get around to blogging about many of these.  I’ve got a ton more from the emerging technology, VC and virtualization space, too. 

I don’t want to become another story summarizer, but perhaps I’ll use this format to cover things I can’t get to every week.

/Hoff

A couple of weeks ago, right after I wrote my two sets of 2008 (in)security predictions (here and here), Mogull informed me that he was penning an article for Dark Reading on how security predictions are useless.  He even sent me a rough draft to rub it in.

His Dark Reading article is titled "The Perils of Predictions – and Predicting Peril" which you can read here.  The part I liked best was, of course, the multiple mentions that some idiot was going to predict an attack on SCADA infrastructure:

Oh, and there is one specific prediction I’ll make for next year:
Someone will predict a successful SCADA attack, and it won’t happen.
Until it does.

So, I’m obviously guilty as charged.  Yup, I predicted it.  Yup, I think it will happen.

In fact, it already has…

You see, Mogull is a huge geek and has invested large sums of money in his new home and outfitted it with a complete home automation system.  In reality, this home automation system is basically just a scaled down version of a SCADA system (Supervisory Control and Data Acquisition.)  Controlling sensors and integrating telemetry with centralized reporting and control…

Rich and I are always IM’ing and emailing one another, so a few days ago before Rich left town for an international junket, I sent him a little email asking him to review something I was working on.  The email contained a link to my "trusted" website.

The page I sent him to was actually trojaned with the 0day POC code for the QT RTSP vulnerability from a couple of weeks ago.  I guess Rich’s Leopard ipfw rules need to be modified because right after he opened it, the trojan executed and then phoned home (to me) and I was able to open a remote shell on TCP/554 right to his Mac which incidentally controls his home automation system.  I totally pwn his house.

So a couple of days ago, Rich went out of town and I waited patiently for the DR article to post.  Now that it’s up, I have exacted my revenge.

I must say that I think Rich’s choice of automation controllers was top-shelf, but I think I might have gone with a better hot tub controller because I seem to have confused it and now it will only heat to 73 degrees.

I also think he should have gone with better carpet.

I’m pretty sure his wife is going absolutely bonkers given the fact that the lights in the den keep blinking to the beat of a Lionel Ritchie song and the garage door opener keeps trying to attack the gardener.  I will let you know that I’m being a gentleman and not peeking at the CCTV images…much.

Let this be a lesson to you all.  When it comes to predicting SCADA attacks, don’t hassle the Hoff!

/Hoff

When all you have is a hammer, everything looks like a nail…

A couple of days ago, I was concerned (here) that I had missed Don Weber’s point (here)
regarding how he thinks solutions like UTM that consolidate multiple
security functions into a single solution increased complexity and
increased risk.

I was interested in more detail regarding Don’s premise for his argument, so I asked him for some substantiating background information before I responded:

The question I have for Don is simple: how is it that you’ve
arrived at the conclusion that the consolidation and convergence of
security functionality from multiple discrete products into a
single-sourced solution adds "complexity" and leads to "increased risk?"

Can you empirically demonstrate this by giving us an example of
where a single function security device that became a multiple function
security product caused this complete set combination of events to occur:

1. Product complexity increased
2. Lead to a vulnerability that was exploitable and
3. Increased "risk" based upon business impact and exposure

Don was kind enough to respond to my request with a rather lengthy
post titled "The Perimeter Is Dead —  Let’s Make It More Complex."  I knew that I wouldn’t get the example I wanted, but I did get
what I expected.  I started to write a very detailed response but stopped when I realized a couple of important things in reading his post as well as many of the comments:

• It’s clear that many folks simply don’t understand the underlying internal operating principles and architectures of security products on the market, and frankly for the most part they really shouldn’t have to.  However, if you’re going to start debating security architecture and engineering implementation of security software and hardware, it’s somewhat unreasonable to start generalizing and creating bad analogs about things you clearly don’t have experience with. 
   
• Believe it or not, most security companies that create bespoke security solutions do actually hire competent product management and engineering staff with the discipline, processes and practices that result in just a *little* bit more than copy/paste integration of software.  There are always exceptions, but if this were SOP, how many of them would still be in business?
   
• The FUD that vendors are accused of spreading to supposedly motivate consumers to purchase their products is sometimes outdone by the sheer lack of knowledge illustrated by the regurgitated drivel that is offered by people suggesting why these same products are not worthy of purchase. 

  In markets that have TAMs of $4+ Billion, either we’re all incompetent lemmings (to be argued elsewhere) or there are some compelling reasons for these products.  Sometimes it’s not solely security, for sure, but people don’t purchase security products with the expectations of being less secure with products that are more complex and put them more at risk.  Silliness.
   

• I find it odd that the people who maintain that they must have diversity in their security solution providers gag when I ask them for proof that they have invested in multiple switch and router vendors across their entire enterprise, that they deliberately deploy critical computing assets on disparate operating systems and that they have redundancy for all critical assets in their enterprise…including themselves. 
   
• It doesn’t make a lot of sense arguing about the utility, efficacy, usability and viability of a product with someone who has never actually implemented the solution they are arguing about and instead compares proprietary security products with a breadboard approach to creating a FrankenWall of non-integrated open source software on a common un-hardened Linux distro.
   
• Using words like complexity and risk within a theoretical context that has no empirical data offered to back it up short of a "gut reaction" and some vulnerability advisories in generally-available open source software lacks relevancy and is a waste of electrons.

I have proof points, ROI studies, security assessment results to the code level, and former customer case studies that demonstrate that some of the most paranoid companies on the planet see fit to purchase millions of dollars worth of supposedly "complex risk-increasing" solutions like these…I can tell you that they’re not all lemmings.

Again, not all of those bullets are directed at Don specifically, but I sense we’re
really just going to talk past one another on this point and the emails I’m getting trying to privately debate this point are agitating to say the least.

Your beer’s waiting, but expect an arm wrestle before you get to take the first sip.

/Hoff

Here’s a rundown of some recent press and some podcast coverage on topics relevant to content on my blog:

• DarkReading: Firewalls Read for Evolutionary Shift
• CIO Magazine: Future Threats to Virtualization Security: Fact vs. Fiction
• CIO Magazine: How to Find and Fix 10 Real Security Threats On Your Virtual Servers
• TechTarget: SearchSecurity Ask the Expert – Selling Security Technology & Services
• DarkReading: Virtual Vulnerabilities About to Become Reality
• CIO/CSO: Hacker Economics – Malware as a Service
• Information Security Magazine: Seven Winners, One Mission
• Network Security Podcast: 2008 Security Predictions
• Institute of Applied Network Security: 2008 Security Predictions

/Hoff

Don Weber wrote a post last week describing his thoughts on the consolidation of [security] controls and followed it up with another today titled "Quit Complicating our Controls – UTM Remix" in which he suggests that the consolidation of controls delivers an end-state of additional "complexity" and "higher risk":

Of course I can see why people desire to integrate the technologies. 

• It is more cost effective to have two or more technologies on one piece of hardware.
• You only have to manage one box.
• The controls can augment each other more effectively and efficiently (according to the advertising on the box).
• Firewalls usually represent a choke point to external and potentially hostile environments.
• Vendors can market it as the Silver Bullet (no relation to Gary McGraw’s podcast) of controls.
• “The next-generation firewall will have greater blocking and
  visibility into types of protocols,” says Greg Young, research vice
  president for Gartner.
• etc

Well, I have a problem with all of this. Why are we making our
controls more complex? Complexity leads to vulnerabilities.
Vulnerabilities lead to exploits. Exploits lead to compromises.
Compromises lead to loss.

…and:

Don’t get me wrong. I am all for developing new technologies that will
allow organizations to analyze their traffic so that they get a better
picture of what is traversing and exiting their networks. I just think
they will be more effective if they are deployed so that they augment
each other’s control measures instead of threatening them by increasing
the risk through complexity. Controls should reduce risk, not increase
it.

Don’s posts have touched on a myriad of topics I have very strong opinions on: complex simplicity, ("magical") risk, UTM and application firewalls.  I don’t agree with Don’s statements regarding any of them. That’s probably why he called me out.

The question I have for Don is simple: how is it that you’ve arrived at the conclusion that the consolidation and convergence of security functionality from multiple discrete products into a single-sourced solution adds "complexity" and leads to "increased risk?"

Can you empirically demonstrate this by giving us an example of where a single function security device that became a multiple function security product caused this complete set combination of events to occur:

1. Product complexity increased
2. Lead to a vulnerability that was exploitable and
3. Increased "risk" based upon business impact and exposure

I’m being open-minded here and rather than try and address every corner-case I am eager to understand more of the background of Don’s position so I might respond accordingly.

/Hoff

…just to put your mind at ease, no, that’s not me.  I’m all about the boxers not briefs.  Now you know since you’ve all been wondering, I’m sure…

I really do appreciate it when people dedicate time, energy and expertise to making sure we’re all as informed as we can be about the potential for bad things to happen.  Case in point, hat tip to Mitchell for pointing us to just such a helpful tip from a couple of guys submitting a draft to the IETF regarding the evils of tunneled traffic.

Specifically, the authors are commenting on the "feature" called Teredo in which IPv6 is tunneled in UDP IPv4 datagrams.

Here’s the shocking revelation, sure to come as a complete surprise to anyone it IT/Security today…if you only look at SrcIP, DstIP, SrcPort, DstPort and Protocol, you’ll miss the fact that nasty bits are traversing your networks in a tunneled/encapsulated death ray!

Seriously, welcome to 1995.  If your security infrastructure relies upon technology that doesn’t inspect "deeper" than the 5-tupule above, you’re surely already aware of this problem as 90% of the traffic entering and leaving your network is probably "tunneled" within port 80/443.

Here’s a practical example.  I stuck a Palo Alto Networks box in front of my home network as part of an evaluation for a client I’m doing.  Check out the application profile of the traffic leaving my network via my FIOS connection:

Check out that list of applications above.  Care to tell me how many of them are tunneled over/via/through port 80/443?  True, they’re not IPv6 in IPv4, but it’s really the same problem; obfuscating applications and protocols means you need to have much more precise fidelity and resolution in detecting what’s going through your firewalls colander.

By the way, I’ve got stuff going through SSH port forwarding, in ICMP payloads, via SSL VPN, via IPSec VPN…can’t wait to see what happens when I shove ’em out using Fragrouter.

I’m all for raising awareness, but does this really require an IETF draft to update the Teredo specification?

/Hoff

Read more…

…from geek to business speak…

Dennis Fisher has nice writeup over at the SearchSecurity Security Bytes Blog about the changing role and reporting structure of the CISO.

Specifically, Dennis notes that he was surprised by the number of CISOs who recently told him that they no longer report to the CIO and aren’t a part of IT at all.  Moreover, these same CISOs noted that the skillset and focus is also changing from a technical to a business role:

I still maintain that "compliance" is nothing more than a gap-filler.  As I said here, we have compliance as an industry [and measurement] today because we manage technology
threats and vulnerabilities and don’t manage risk.  Compliance is
actually nothing more than a way of forcing transparency and plugging a
gap between the two.  For most, it’s the best they’ve got.

Once organizationally we’ve got our act together, compliance will become the floor, not the ceiling and we’ll really start to see the "…maturation of the security industry as a whole."

/Hoff