« November 2007 | Main | January 2008 »

Posts from December 2007

December 28, 2007

Thinning the Herd & Chlorinating the Malware Gene Pool...

Anchovyswarm 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

December 20, 2007

Really Interesting Blog Snippets I Don't Have Time to Comment On...

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.

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

December 15, 2007

BeanSec! Wednesday, December 19th - 6PM to ?

Beansec3_2 This month's BeanSec! will be held in a different location due to a facility booking at the usual location.

This month's meeting will be located at the Middlesex Lounge, 315 Massachusetts Avenue, Cambridge MA  02139 (right down the street.)


Yo!  BeanSec! is once again upon us.  Wednesday, December 19th, 2007.

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... (see above)

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

It's On The Internet, It Must Be True!!

Internettruth

Case in point, here.

That is all.

/Hoff

December 13, 2007

Breaking News: Successful SCADA Attack Confirmed - Mogull Is pwned!

Scada 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.

CctvSo 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

December 12, 2007

Complexity: The Enemy of Security? Or, If It Ain't Fixed, Don't Break It...

Hammerhead 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

Don't Hassle the Hoff: Recent Press & Podcast Coverage...

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

/Hoff

December 10, 2007

Consolidating Controls Causes Chaos and Certain Complexity?

Simplicity_complexity 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

December 08, 2007

WARNING: Tunneling Traffic Means Filtering On 5-Tuple Insufficient. Welcome to 1995!

Tunnelsbad ...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:
Panacchoff_2

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

Continue reading "WARNING: Tunneling Traffic Means Filtering On 5-Tuple Insufficient. Welcome to 1995!" »

The Seesaw CISO...Changing Places But Similar Faces...

Seesaw_shadow ...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:

In the last few months I’ve been hearing more and more from CEOs, CIOs and CSOs about the changing role of the CSO (or CISO, depending on your org chart) in the enterprise. In the past, the CSO has nearly always been a technically minded person who has risen through the IT ranks and then made the jump to the executive ranks. That lineage sometimes got in the way when it came time to deal with other upper managers who typically had little or no technical knowledge and weren’t interested in the minutiae of authentication schemes, NAC and unified threat management. They simply wanted things to work and to avoid seeing the company’s name in the papers for a security breach.

But that seems to be changing rather rapidly. Last month I was on a panel in Chicago with Howard Schmidt, Lloyd Hession, the CSO of BT Radianz, and Bill Santille, CIO of Uline, and the conversation quickly turned to the ways in which the increased focus on risk management in enterprises has forced CSOs to adapt and expand their skill sets. A knowledge of IDS, firewalls and PKI is not nearly enough these days, and in some cases is not even required to be a CSO. One member of the audience said that the CSO position in his company is rotated regularly among senior managers, most of whom have no technical background and are supported by a senior IT staff member who serves as CISO. The CSO slot is seen as a necessary stop on the management circuit, in other words. Several other CSOs in the audience said that they no longer report to the CIO and are not even part of the IT organization. Instead, they report to the CFO, the chief legal counsel, or in one case, the ethics officer.

I've talked about the fact that "security" should be a business function and not a technical one and quite frankly what Dennis is hearing has been a trend on the uptick for the last 3-4 years as "information security" becomes less relevant and managing risk becomes the focus.  To wit:

The number of organizations making this kind of change surprised me at the time. But, in thinking more about it, it makes a lot of sense, given that the daily technical security tasks are handled by people well below the CSO’s office. And many of the CSOs I know say they spend most of their time these days dealing with policy issues such as regulatory compliance. Patrick Conte, the CEO of software maker Agiliance, which put on the panel, told me that these comments fit with what he was hearing from his customers, as well. Some of this shift is clearly attributable to the changing priorities inside these enterprises. But some of it also is a result of the maturation of the security industry as a whole, which has translated into less of a focus on technology and more attention being paid to policies, procedures and other non-technical matters.

How this plays out in the coming months and years will be quite interesting. My guess is that as security continues to be absorbed into the larger IT and operations functions, the CSO’s job will continue to morph into more of 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

December 07, 2007

And Now Some Useful 2008 Information Survivability Predictions...

Noculars So, after the obligatory dispatch of gloom and doom as described in my 2008 (in)Security Predictions, I'm actually going to highlight some of the more useful things in the realm of Information Security that I think are emerging as we round the corner toward next year.

They're not really so much predictions as rather some things to watch.

Unlike folks who can only seem to talk about desperation, futility and manifest destiny or (worse yet) "anti-pundit pundits" who try to suggest that predictions and forecasting are useless (usually because they suck at it,) I gladly offer a practical roundup of impending development, innovation and some incremental evolution for your enjoyment. 

You know, good news.

As Mogull mentioned, I don't require a Cray XMP48, chicken bones & voodoo or a prehensile tail to make my picks.  Rather I grab a nice cold glass of Vitamin G (Guiness) and sit down and think for a minute or two, dwelling on my super l33t powers of common sense and pragmatism with just a pinch of futurist wit.

Many of these items have been underway for some time, but 2008 will be a banner year for these topics as well as the previously-described "opportunities for improvement..."

That said, let's roll with some of the goodness we can look forward to in the coming year.  This is not an exhaustive list by any means, but some examples I thought were important and interesting:

  1. More robust virtualization security toolsets with more native hypervisor/vmm accessibility
    Though it didn't start with the notion of security baked in, virtualization for all of its rush-to-production bravado will actually yield some interesting security solutions that help tackle some very serious challenges.  As the hypervisors become thinner, we're going to see the management and security toolsets gain increased access to the guts of the sausage machine in order to effect security appropriately and this will be the year we see the virtual switch open up to third parties and more robust APIs for security visibility and disposition appear.
     
  2. The focus on information centric security survivability graduates from v1.0 to v1.1
    Trying to secure the network and the endpoint is like herding cats and folks are tired of dumping precious effort on deploying kitty litter around the Enterprise to soak up the stinky spots.  Rather, we're going to see folks really start to pay attention to information classification, extensible and portable policy definition, cradle-to-grave lifecycle management, and invest in technology to help get them there.

    Interestingly the current maturity of features/functions such as NAC and DLP have actually helped us get closer to managing our information and information-related risks.  The next generation of these offerings in combination with many of the other elements I describe herein and their consolidation into the larger landscape of management suites will actually start to deliver on the promise of focusing on what matters -- the information.
     
  3. Robust Role-based policy, Identity and access management coupled with entitlement, geo-location and federation...oh and infrastructure, too!
    We're getting closer to being able to affect policy not only based upon just source/destination IP address, switch and router topology and the odd entry in active directory on a per-application basis, but rather holistically based upon robust lifecycle-focused role-based policy engines that allow us to tie in all of the major enterprise components that sit along the information supply-chain.

    Who, what, where, when, how and ultimately why will be the decision points considered with the next generation of solutions in this space. Combine the advancements here with item #2 above, and someone might actually start smiling.

    If you need any evidence of the convergence/collision of the application-oriented with the network-oriented approach and a healthy overlay of user entitlement provisioning, just look at the about-face Cisco just made regarding TrustSec.  Of course, we all know that it's not a *real* security concern/market until Cisco announces they've created the solution for it ;)
     
  4. Next Generation Networks gain visibility as they redefine the compute model of today
    Just as there exists a Moore's curve for computing, there exists an overlapping version for networking, it just moves slower given the footprint.  We're seeing the slope of this curve starting to trend up this coming year, and it's much more than bigger pipes, although that doesn't hurt either...

    These next generation networks will really start to emerge visibly in the next year as the existing networking models start to stretch the capabilities and capacities of existing architecture and new paradigms drive requirements that dictate a much more modular, scalable, resilient, high-performance, secure and open transport upon which to build distributed service layers.

    How networks and service layers are designed, composed, provisioned, deployed and managed -- and how that intersects with virtualization and grid/utility computing -- will start to really sink home the message that "in the cloud" computing has arrived.  Expect service providers and very large enterprises to adapt these new computing climates first with a trickle-down to smaller business via SaaS and hosted service operators to follow.

    BT's 21CN (21st Century Network) is a fantastic example of what we can expect from NGN as the demand for higher speed, more secure, more resilient and more extensible interconnectivity really takes off.
     
  5. 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.
     
  6. Precision versus accuracy will start to legitimize prevention as the technology starts to allow us the confidence to start turning the corner beyond detection
    In a sad commentary on the last few years of the security technology grind, we've seen the prognostication that intrusion detection is dead and the deadpan urging of the security vendor cesspool convincing us that we must deploy intrusion prevention in its stead. 
       
    Since there really aren't many pure-play intrusion detection systems left anyway, the reality is that most folks who have purchased IPSs seldom put them in in-line mode and when they do, they seldom turn on the "prevention" policies and instead just have them detect attacks, blink a bit and get on with it.

    Why?  Mostly because while the threats have evolved the technology implemented to mitigate them hasn't -- we're either stuck with giant port/protocol colanders or signature-driven IPSs that are nothing more than IDSs with the ability to send RST packets.

    So the "new" generation of technology has arrived and may offer some hope of bridging that gap.  This is due to not only really good COTS hardware but also really good network processors and better software written (or re-written) to take advantage of both.  Performance, efficacy and efficiency have begun to give us greater visibility as we get away from making decisions based on ports/protocols (feel free to debate proxies vs. ACLs vs. stateful inspection...) and move to identifying application usage and getting us close to being able to make "real time" decisions on content in context by examining the payload and data.  See #2 above.

    The precision versus accuracy discussion is focused around being able to really start trusting in the ability for prevention technology to detect, defend and deter against "bad things" with a fidelity and resolution that has very low false positive rates.

    We're getting closer with the arrival of technology such as Palo Alto Network's solutions -- you can call them whatever you like, but enforcing both detection and prevention using easy-to-define policies based on application (and telling the difference between any number of apps all using port 80/443) is a step in the right direction.
     
  7. The consumerization of IT will cause security and IT as we know it to die radically change
    I know it's heretical but 2008 is going to really push the limits of the existing IT and security architectures to their breaking points, which is going to mean that instead of saying "no," we're going to have to focus on how to say "yes, but with this incremental risk" and find solutions for an every increasingly mobile and consumerist enterprise. 

    We've talked about this before, and most security folks curl up into a fetal position when you start mentioning the adoption by the enterprise of social neworking, powerful smartphones, collaboration tools, etc.  The fact is that the favorable economics, agility , flexibility and efficiencies gained with the adoption of consumerization of IT outweigh the downsides in the long run.  Let's not forget the new generation of workers entering the workforce. 

    So, since information is going to be leaking from our Enterprises like a sieve on all manners of devices and by all manner of methods, it's going to force our hands and cause us to focus on being information centric and stop worrying about the "perimeter problem," stop focusing on the network and the host, and start dealing with managing the truly important assets while allowing our employees to do their jobs in the most effective, collaborative and efficient methods possible.

    This disruption will be a good thing, I promise.  If you don't believe me, ask BP -- one of the largest enterprises on the planet.  Since 2006 they've put some amazing initiatives into play:

    ...like this little gem:

    Oil giant BP is pioneering a "digital consumer" initiative that will give some employees an allowance to buy their own IT equipment and take care of their own support needs.

    The project, which is still at the pilot stage, gives select BP staff an annual allowance — believed to be around $1,000 — to buy their own computing equipment and use their own expertise and the manufacturer's warranty and support instead of using BP's IT support team.

    Access to the scheme is tightly controlled and those employees taking part must demonstrate a certain level of IT proficiency through a computer driving licence-style certification, as well as signing a diligent use agreement.

    ...combined with this:

    Rather than rely on a strong network perimeter to secure its systems, BP has decided that these laptops have to be capable of coping with the worst that malicious hackers can throw at it, without relying on a network firewall.

    Ken Douglas, technology director of BP, told the UK Technology Innovation & Growth Forum in London on Monday that 18,000 of BP's 85,000 laptops now connect straight to the internet even when they're in the office.

  8. Desktop Operating Systems become even more resilient
    The first steps taken by Microsoft and Apple in Vista and OS X (Leopard) as examples have begun to chip away at plugging up some of the security holes that have plagued them due to the architectural "feature" that providing an open execution runtime model delivers.  Honestly, nothing short of a do-over will ultimately mitigate this problem, so instead of suggesting that incremental improvement is worthless, we should recognize that our dark overlords are trying to makethings better.

    Elements in Vista such as ASLR, NX, and UAC combined with integrated firewalling, anti-spyware/anti-phishing, disk encryption, integrated rights management, protected mode IE mode, etc. are all good steps in a "more right" direction than previous offerings.  They're in response to lessons learned.

    On the Mac, we also see ASLR, sandboxing, input management, better firewalling, better disk encryption, which are also notable improvements.  Yes, we've got a long way to go, but this means that OS vendors are paying more attention which will lead to more stable and secure platforms upon which developers can write more secure code.

    It will be interesting to see how the intersection of these "more secure" OS's factor with virtualization security discussed in #1 above.

    Vista SP1 is due to ship in 2008 and will include APIs through which third-party security products can work with kernel patch protection on Vista x64, more secure BitLocker drive encryption and a better Elliptical Curve Cryptography PRNG (pseudo-random number generator.)  Follow-on releases to Leopard will likely feature security enhancements to those delivered this year.
     
  9. Compliance stops being a dirty word  & Risk Management moves beyond buzzword
    Today we typically see the role of information security described as blocking and tackling; focused on managing threats and vulnerabilities balanced against the need to be "compliant" to some arbitrary set of internal and external policies.  In many people's assessment then, compliance equals security.  This is an inaccurate and unfortunate misunderstanding.

    In 2008, we'll see many of the functions of security -- administrative, policy and operational -- become much more visible and transparent to the business and we'll see a renewed effort placed on compliance within the scope of managing risk because the former is actually a by-product of a well-executed risk management strategy.

    We have compliance as an industry 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.

    What's traditionally preventing the transition from threat/vulnerability management to risk management is the principal focus on technology with a lack of a good risk assessment framework and thus a lack of understanding of business impact.

    The availability of mature risk assessment frameworks (OCTAVE, FAIR, etc.) combined with the maturity of IT and governance frameworks (CoBIT, ITIL) and the readiness of the business and IT/Security cultures to accept risk management as a language and actionset with which they need to be conversant will yield huge benefits this year.

    Couple that with solutions like Skybox and you've got the makings of a strategic risk management strategy that can bring the security more closely aligned to the business.
     
  10. Rich Mogull will, indeed, move in with his mom and start speaking Klingon
    'nuff said.

So, there we have it.  A little bit of sunshine in your otherwise gloomy day.

/Hoff

December 03, 2007

2008 Security Predictions -- They're Like Elbows...

Carnacangled_2 Yup.  Security predictions are like elbows.  Most everyone's got at least two, they're usually ignored unless rubbed the wrong way but when used appropriately, can be devastating in a cage match...

So, in the spirit of, well, keeping up with the Jones', I happily present you with Hoff's 2008 Information (in)Security Predictions.  Most of them are feature attacks/attack vectors.  A couple are ooh-aah trends.  Most of them are sadly predictable.  I've tried to be more specific than "cybercrime will increase."

I'm really loathe do these, but being a futurist, the only comfort I can take is that nobody can tell me that I'm wrong today ;)

...and in the words of Carnac the Magnificent, "May the winds of the Sahara blow a desert scorpion up your turban..."

  1. Nasty Virtualization Hypervisor Compromise
    As the Hypervisor gets thinner, more of the guts will need to be exposed via API or shed to management and functionality-extending toolsets, expanding the attack surface with new vulnerabilities.  To wit, a Hypervisor-compromising malware will make it's first in-the-wild appearance to not only produce an exploit, but obfuscate itself thanks to the magic of virtualization in the underlying chipsets.  Hang on to yer britches, the security vendor product marketing SpecOps Generals are going to scramble the fighters with a shock and awe campaign of epic "I told you so" & "AV isn't dead, it's just virtualized" proportions...Security "strategery" at it's finest.

  2. Major Privacy Breach of a Social Networking Site
    With the broadening reach of application extensibility and Web2.0 functionality, we'll see a major privacy breach via social network sites such as MySpace, LinkedIn or Facebook via the usual suspects (CSRF, XSS, etc.) and via host-based Malware that 0wns unsuspecting Millenials and utilizes the interconnectivity offered to turn these services into a "social botnet" platform with a wrath the likes of which only the ungoldly lovechild of Storm, Melissa, and Slammer could bring...

  3. Integrity Hack of a Major SaaS Vendor
    Expect a serious bit of sliminess to occur with real financial impact to occur from a SaaS vendor's offering.  With professional cybercrime on the rise, the criminals will go not only where the money is, but also after the data that describes where that money is.  Since much of the security of the SaaS model counts on the integrity and not just the availability of the hosted service, a targeted attack which holds hostage the (non-portable) data and threatens its integrity could have devastating effects on the companies who rely on it.  SalesForce, anyone?
     
  4. Targeted eBanking Compromise with substantial financial losses
    Get ready for a nasty eBanking focused compromise that starts to unravel the consumer confidence in this convenient utility; not directly because of identity abuse (note I didn't say identity theft) but because of the business model impact it will bring to the banks.   These types of direct attacks (beyond phishing) will start to push the limits of acceptable loss for the financial institutions and their insurers and will start to move the accountability/responsibility more heavily down to the eBanker.  A tiered service level will surface with greater functionality/higher transaction limits being offered with a trade-off of higher security/less convenience.  Same goes for credit/debit cards...priceless!

  5. A Major state-sponsored espionage and cyberAttack w/disruption of U.S. government function
    We saw some of the more noisy examples of low-level crack attacks via our Chinese friends recently, but given the proliferation of botnets, the inexcusably poor levels of security in government systems and network security, we'll see a targeted attack against something significant.  It'll be big.  It'll be public.  It'll bring new legislation...Isn't there some little election happening soon?  This brings us to...

  6. Be-Afraid-A of a SCADA compromise...the lunatics are running the asylum!
    Remember that leaked DHS "turn your generator into a roman candle" video that circulated a couple of months ago?  Get ready to see the real thing on prime time news at 11.  We've got decades of legacy controls just waiting for the wrong guy to flip the right switch.  We just saw an "insider" of a major water utility do naughty things, imagine if someone really motivated popped some goofy pills and started playing Tetris with the power grid...imagine what all those little SCADA doodads are hooked to...
     
  7. A Major Global Service/Logistics/Transportation/Shipping/Supply-Chain Company will be compromised via targeted attack
    A service we take for granted like UPS, FedEx, or DHL will have their core supply chain/logistics systems interrupted causing the fragile underbelly of our global economic interconnectedness to show itself, warts and all.  Prepare for huge chargebacks on next day delivery when all those mofo's don't get their self-propelled, remote-controlled flying UFO's delivered from Amazon.com.

  8. Mobile network attacks targeting mobile broadband
    So, you don't use WiFi because it's insecure, eh?  Instead, you fire up that Verizon EVDO card plugged into your laptop or tether to your mobile phone instead because it's "secure."  Well, that's going to be a problem next year.  Expect to see compromise of the RF you hold so dear as we all scramble to find that next piece of spectrum that has yet to be 0wn3d...Google's 700Mhz spectrum, you say? Oh, wait...WiMax will save us all...
     
  9. My .txt file just 0wn3d me!  Is nothing sacred!?  Common file formats and protocols to cause continued unnatural acts
    PDF's, Quicktime, .PPT, .DOC, .XLS.  If you can't trust the sanctity of the file formats and protocols from Adobe, Apple and Microsoft, who can you trust!?  Expect to see more and more abuse of generic underlying software plumbing providing the conduit for exploit.  Vulnerabilities that aren't fixed properly combined with a dependence on OS security functionality that's only half baked is going to mean that the "Burros Gone Wild" video you're watching on YouTube is going to make you itchy in more ways than one...

  10. Converged SensorNets
    In places like the UK, we've seen the massive deployment of CCTV monitoring of the populous.  In places like South Central L.A., we have ballistic geo-location and detection systems to track gunshots.  We've got GPS in phones.  In airports we have sniffers, RFID passport processing, biometrics and "Total Recall" nudie scanners.  The PoPo have license plate recognition.  Vegas has facial recognition systems.  Our borders have motion, heat and remote sensing pods.  start knitting this all together and you have massive SensorNets -- all networked -- and able to track you to military precision.  Pair that with GoogleMaps/Streets and I'll be able to tell what color underwear you had on at the Checkout counter of your local Qwik-E-Mart when you bought that mocha slurpaccino last Tuesday...please don't ask me how I know.

  11. Information Centric Security Phase One
    It should come as no surprise that focusing our efforts on the host and the network has led to the spectacular septic tank of security we have today.  We need to focus on content in context and set policies across platform and transport to dictate who, how, when, where, and why the creation, modification, consumption and destruction of data should occur.  In this first generation of DLP/CMF solutions (which are being integrated into the larger base of "Information" centric "assurance" solutions,) we've taken the first step along this journey.  What we'll begin to see in 2008 is the information equivalent of the Mission Impossible self-destructing recording...only with a little more intelligence and less smoke.  Here come the DRM haters...
     
  12. The Attempted Coup to Return to Centralized Computing with the Paradox of Distributed Data
    Despite the fact that data is being distributed to the far reaches of the Universe, the wonders of economics combined with the utility of some well-timed technology is seeing IT & Security (encouraged by the bean counters) attempting to reel the genie back in the bottle and re-centralize the computing (desktop, server, application and storage) experience back into big boxes tucked safely away in some data center somewhere.  Funny thing is, with utility/grid computing and SaaS, the data center is but an abstraction, too.  Virtualization companies will become our dark overlords as they will control the very fabric of our digital lives...2008 is when we'll really start to use the web as the platform for the delivery of all applications, served through streamed desktops on thinner and thinner clients.

So, that's all I could come up with.  I don't really have a formulaic empirical model like Stiennon.  I just have a Guiness and start complaining.  This is what I came up with.

In more ways than one, I hope I'm terribly wrong on most of these.

/Hoff

[Edit: Please see my follow-on post titled "And Now Some Useful 2008 Information Survivability Predictions" which speak to some interesting less gloomy things I predict to happen in 2008]

My Photo

Lijit Search

Disclaimer

  • The views and opinions expressed here are those of Christofer Hoff only and in no way represent the views, positions or opinions - expressed or implied - of my employer or anyone else.

July 2008

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31