Rational Survivability

Firstly, my apologies to both Ron and Stephen for the grotesque visual…especially when you consider that this ridiculous analog is all the more absurd when you consider that I’m suggesting I’m the bologna in the middle. 

Ew. 

As I write this, I regret it immediately.

I’m referring to being included — along with the usual cast of characters; Rothman, Shimel, Williams, Stiennon, etc. — in ITSecurity.com’s Top 59 Influencers in IT Security listing.  I’m #24, right in between Gula and Toulouse!  This is how we roll, yo!

I’m sure Alan’s going to complain that Amrit beat him out for #1, but I find it hysterical that John Thompson and Tom Noonan are below me!  Technically, I’m listed twice; once in the bloggers section and again under the Corporate Security Officers section. 

The only way this list is in actual order of anything is the possibility that the ranking represents the number of complaints regarding content from my rabid blog readership of 4 (and you know who you are.)  Nonetheless, thanks for voting 6 times each, ya’ll!   

You can check out this interesting list of people here.

/Hoff

Hey, do you remember reading this little snippet as a quote from a certain industry personality we all know and love in regards to his lack of love for UTM?

"I have a problem with the idea of Universal Threat Management
appliances.  Leaving aside the horrible terminology (Who wants to
manage threats? Don’t you want to block them and forget about them?)
the question that I always ask is: If best-of-breed is the standard for
large enterprises why would it be good practice for a smaller entity to
lump a lot of security functions such as firewall, email gateway, spam
filter, anti-virus, anti-spyware, IDS, IPS, and vulnerability
management all in one under-powered device?"

I’ll give you a hint.  It was posted here by the original author and I responded to it, here.

That’s right!  It was my buddy, Richard Stiennon — lambasting Universal (sic) Threat Management appliances…like those of Fortinet, before they offered him a job.  Perhaps Fortinet doesn’t count because they make Unified, not Universal, Threat Management devices?

Don’t hate the player, baby, hate the game!  (i.e., be careful what you blog, it could come back to hire haunt you.)

Sorry, Rich.  3 Bourbons and a long week make Johnny a lit boy.  Couldn’t help myself.  Fire Away!

/Hoff

Gunnar Peterson (1 Raindrop blog) continues to highlight the issues of implementing security models which are not keeping pace with the technology they are deployed to protect.  Notice I didn’t say "designed" to protect.

Specifically, in his latest entry titled "Understand Web 2.0 Security Issues – As Easy as 2, 1, 3" he articulates (once again) the folly of the security problem that we cannot solve because we simply refuse to learn from our mistakes and proactively address security before it becomes a problem:

"So let’s do the math, we have rich Web 2.0 and its rich UI and lots
of disparate data and links, we are protecting these brand new
2007-built apps with a Web 1.0 security model that was invented in
1995. This would not be a bad thing at all if the attacker community
had learned nothing in the last 12 years, alas they have already
upgraded to attacker 3.0, and so can use Web 2.0 to both attack and distribute attacks.

2.0 functionality, 1.0 security, 3.0 attackers. this cannot stand."

A-Friggin’-Men.  Problem is, unless we reboot the entire human race (or at least developers and security folk) it’s going to take a severe meltdown to initiate change.

Oh, and BTW, just because it bugged me when Thomas Ptacek bawked while asking what I meant in a presentation of mine where I said:

"What happens when we hit Web3.0 and we’re still only at
Security 2.4beta11?"

…and he asked:

What does this even mean?

…the answer is simple: Please see Gunnar’s post above.  It’s written much better, but i trust this is all cleared up now?

I read ZDNet’s coverage of the Wharton Technology Conference in Philadelphia by Larry Dignan and was astounded by what Larry reported was said in regards to comments made by TD Ameritrade’s Chief Security Officer, Bill Edwards.

I’m not trying to pick on Mr. Edwards as I have never met the man, but his comments regarding SOA left me disillusioned about how security and emerging technologies are approached in what continues to be a purely reactive, naive and disconnected manner.

Specifically, SOA is not exactly "new."  The evolution of technology, maturing of standards, proliferation of Web 2.0 and massive deployments of SOA’s in some of the world’s largest companies shouldn’t come as a surprise to anyone…even in the risk averse financial services sector.  That being said, SOA is disruptive and innovative and needs to be approached both strategically as well as tactically.

As a former CISO of a $25 Billion financial services firm, I was embroiled in our first SOA deployments 2.5 years ago.  It’s blood and guts.  It involves dealing with the business, business partners, IT and development staffs in ways you never have.  It takes communication, education, expertise and business acumen.  It’s not something you wait to be dragged into.

The notion that a security team would be "dragged" into SOA rather than embrace and approach it proactively and from the perspective of a thought leader and collaborative contributor astounds me.

That said, here’s what I had a problem with:

TD Ameritrade Chief Security Officer Bill Edwards figures that he’s
going to be pulled onto the service oriented architecture (SOA)
bandwagon soon. He might as well use it to enhance security.

"When the architects approached me about SOA my first reaction was ‘no
you can’t do that,’" said Edwards, who spoke at a financial services
online fraud panel at Wharton Technology Conference in Philadelphia on
Friday. "But then I realized I’m going to be dragged along with SOA
anyway so I should use it to rebuild security from the ground up. I
know it’s coming so my team got friendly with the architecture group."

What disturbs me is that SOA represents potentially monumental impact to business, technology and security and instead of embracing (see below) this in a proactive manner, the ad hoc formation of a "strategic" response is "…if you can’t beat ’em, join ’em" and perhaps leverage this to fix problems that weren’t fixed prior.

Paying for sins of the past with currency of the future and confusion in the present isn’t exactly showing alignment to the business as an enabler.  But that’s just me.

It’s clear that the first reaction of saying "no, you can’t do that" is so incredibly typical and representative of the security industry in general; fear what you don’t understand and can it. I can’t imagine how making decisions on risk without an effective model is doing the business justice.

Realizing that this is a train on the tracks that can’t be ducked and that he’s going to be "dragged along with SOA" and that something must be done to head off disaster at the pass (or at least get more budget,) I’m having trouble reconciling this:

"SOA is going to be embraced by security. I don’t know if the industry
is ready for security on SOA, but I’m looking forward to it as it will
make my job easier," he said. "SOA allows you to get granular on
security and focus on specific modules."

I am really having trouble understanding whether this is a statement or a question, but I just cannot comprehend how much sense that last sentence fails to make. 

You’re not embracing SOA when you describe being "dragged into it" and your first reaction is "no." Further, if you’re deploying SOA and you’re not baking in security, you should be fired.

Secondly, Explain to me how SOA is going to make security (his job) easier?  Because you can get "granular on security?"  Huh?  SOA is complex.  If you don’t have your "stuff" together in the first place, it’s only going to make your life more difficult.

I’m sorry for this reading like I’m a grumpy bastard (I am) and that I’m singling out Mr. Edwards (he chose to be on a panel) but this just doesn’t jive.

My advice to Mr. Edwards and anyone else looking for the right approach to take with SOA and security is to read Gunnar Peterson’s blog or some more of his work.
 

/Hoff

Over the last couple of months, the topic of virtualization and security (or lack thereof) continues to surface as one of the more intriguing topics of relevance in both the enterprise and service provider environments and those who cover them.  From bloggers to analysts to vendors, virtualization is a greenfield for security opportunity and a minefield for the risk models used to describe it.

There are many excellent arguments being discussed which highlight in an ad hoc manner the most serious risks posed by virtualization, and I find many of them accurate, compelling, frightening and relevant.  However, I find that overall, to gauge in relative terms the impact  that these new combinations of attack surfaces, vectors and actors pose, the risk model(s) are immature and incomplete. 

Most of the arguments are currently based on hyperbole and anecdotal references to attacks that could happen.  It reminds me much of the ballyhooed security risks currently held up for scrutiny for mobile handsets.  We know bad things could happen, but for the most part, we’re not being proactive about solving some of the issues before they see the light of day.

The panel I was on at the RSA show highlighted this very problem.  We had folks from VMWare and
RedHat in the audience who assured us that we were just being Chicken Little’s and that the risk is
both quantifiable and manageable today.  We also had other indications that customers felt that while the benefits for virtualization from a cost perspective were huge, the perceived downside from the unknown risks (mostly theoretical) were making them very uncomfortable.

Out of the 150+ folks in the room, approximately 20 had virtualized systems in production roles.  About 25% of them had collapsed multiple tiers of an n-tier application stack (including SOA environments) onto a single host VM.  NONE of them had yet had these systems audited by any third party or regulatory agency.

Rot Roh.

The interesting thing to me was the dichotomy regarding the top-down versus bottom-up approach to
describing the problem.  There was lots of discussion regarding hypervisor (in)security and privilege
escalation and the like, but I thought it interesting that most people were not thinking about the impact on the network and how security would have to change to accommodate it from a bottoms-up (infrastructure and architecture) approach.

The notions of guest VM hopping and malware detection in hypervisors/VM’s are reasonably well discussed (yet not resolved) so I thought I would approach it it from the perspective of what role, if any, the traditional  network infrastructure plays in this.

Thomas Ptacek was right when he said "…I also think modern enterprises are so far from having reasonable access control between the VLANs they already use without virtualization that it’s not a “next 18 month” priority to install them." And I agree with him there.  So, I posit that if one accepts this as true then what to do about the following:

If now we see the consolidation of multiple OS and applications on a single VM host in which the bulk of traffic and data interchange is between the VM’s themselves and utilize the virtual switching fabrics in the VM Host and never hit the actual physical network infrastructure, where, exactly, does this leave the self-defending "network" without VM-level security functionality at the "micro perimeters" of the VM’s?

I recall a question I asked at a recent Goldman Sachs security conference where I asked Jayshree Ullal from Cisco who was presenting Cisco’s strategy regarding virtualized security about how their approach to securing the network was impacted by virtualization in the situation I describe above. 

You could hear cricket’s chirp in the answer.

Talk amongst yourselves….

P.S. More excellent discussions from Matasano (Ptacek) here and Rothman’s bloggy.  I also recommend Greg Ness’ commentary on virtualization and security @ the HyperVisor here.

One of the benefits of living near Boston is the abundance of amazing museums and historic sites available for visit within 50 miles from my homestead.

This weekend the family and I decided to go hit the Museum of Science for a day of learning and fun.

As we were about to leave, I spied an XP-based computer sitting in the corner of one of the wings and was intrigued by the sign on top of the monitor instructing any volunteers to login:

Then I noticed the highlighted instruction sheet taped to the wall next to the machine:

If you’re sharp enough, you’ll notice that the sheet instructs the volunteer how to remember their login credentials — and what their password is (‘1234’) unless they have changed it!

"So?" you say, "That’s not a risk.  You don’t have any usernames!"

Looking to the right I saw a very interesting plaque.  It contained the first and last names of the museum’s most diligent volunteers who had served hundreds of hours on behalf of the Museum.  You can guess where this is going…

I tried for 30 minutes to find someone (besides Megan Crosby on the bottom of the form) to whom I could suggest a more appropriate method of secure sign-on instructions.  The best I could do was one of the admission folks who stamped my hand upon entry and ended up with a manager’s phone number written on the back of a stroller rental slip.

(In)Security is everywhere…even at the Museum of Science.  Sigh.

/Hoff

Despite Mike completely missing the point of my last point regarding Alan Shimel’s rant on Tippingpoint (he defaults to "Hoff is defending Big Iron blurb,) Mike made a bold statement:

Virtualization hasn’t changed the fundamental laws of network architecture

I am astounded by this statement.  I violently disagree with this assertion.

Virtualization may have not changed the underlying mechanisms of CSMA/CD or provided the capability to exceed the speed of light, but virtualization has absolutely and fundamentally affected the manner in which networks are designed, deployed, managed and used.   You know, network architecture.

Whether we’re talking about VLAN’s, MPLS, SOA, Grid Computing or Storage, almost every example of data center operations and network design today are profoundly impacted by the V-word.

Furthermore, virtualization (of transport, storage, application, policy, data) has also fundamentally changed the manner in which computing is employed and resources consumed.  What you deploy, where, and how are really, really important.

More importantly (and relevant here) is that virtualization has caused architects to revisit the way in which these assets and the data that flow through them, is secured.

And to defray yet another "blah blah…big iron…large enterprise….blah blah" retort, I’m referring not just to the Crossbeam way (which is heavily virtualized,) but that of Cisco and Juniper also.  All Next Generation Network Services are in a low-earth orbit of the mass that is virtualization.

"Virtualization of the routed core. Virtualization of the data and control planes.  Virtualization of Transport.  Extending the virtualized enterprise over the WAN.  The virtualized access layer."  You know what those are?  Chapters out of a Cisco Press book on Network Virtualization which provides "…design guidance" for architects of virtualized Enterprises.

I suppose it’s only fair that I ask Mike to qualify his comment, because perhaps it’s another "out-of-context-ism" or I misunderstood (of course I did) but it made me itchy reading it.

Mike?

Alan and I normally are close enough on our positions that I don’t feel it necessary to argue with him.

I certainly don’t feel compelled to come to the defense of a competitor that Alan’s unloading on, but I’m really confused about his interpretation of what TippingPoint’s Chief Architect, Brian Smith, is communicating and where Alan suggests that he and StillSecure’s position lays.

To re-cap, Brian Smith was quoted in an SC Magazine Article as describing his views on how security ought to be positioned in the network thusly:

"Brian Smith, the chief architect of 3Com and a
founder of TippingPoint, says his first-ever RSA keynote will focus on
integrating solutions such as network access control, intrusion
prevention and behavioral anomaly detection to create an intelligent
network.

"I can do all of these sorts of synergies and when you trace it
out, what ends up happening is you’re able to debug network problems
that you were never able to do before, get an unprecedented level of
security, and also lower the total cost of ownership," Smith says.
"They have to talk to each other. If we can pull all of these solutions
together, I think that’s going to be the trend over the next five to 10
years. It’s a natural evolution in the technology cycle."

Smith says he also plans to emphasize the benefits of the
bump-in-the-wire network approach to deploying security solutions.
Rather than embedding solutions into switchers and routers, Smith plans
to suggest overlaying solutions to allow for a more converged, cheaper
way to add intelligence to the network."

Amen to that.  But lest you think I am intimating that we should all just toss appliances willy-nilly across the network (in fact, that’s the opposite of what I think,) please read on…

Apparently it was the third (boldfaced) paragraph that got Alan’s goat and provoked him into a state of up-chuckedness.  Specifically, it seems that it is repugnant to Alan that someone who works for a "switch" company could suggest that overlaying security can be facilitated as a "bump-in-the wire."  I guess that depends upon your interpretation of "bump-in-the-wire." 

I’m guessing that Alan thinks that means individual appliances being inserted between network segments with one "goesinta" and one "goesouta" cable and yet I can’t figure out why  "…virtualizing some of this stuff and putting it on blades and so forth" has to be within the router or switch and not on an extensible services platform?

I have a feeling I’m going to hear the typical "not everyone can afford big iron" as a response…but if you can generalize to prove a point, I can become surgical and suggest that it’s not fair to treat the Global 2000, Carriers, Service Providers and Mobile Operators as an exception rather than the rule when it comes to describing security trends and markets, either.

Summarily, it appears that the "convergence" of networking and security in Alan’s eyes means that security functionality MUST be integrated into routers and switches in order to be successful and that adding security functionality on top of or in conjunction with the network is a lousy idea.

Strange comments from a guy whose company takes generic PC appliances  with security software on them and deploys them as bumps in the wire by sprinkling them across the network — usually at the cursed perimeter and not at the core.  Confused?  So am I.

Alan goes on:

Most of the guys who do the bump in the wire are trying like hell to
move up the stack and the network to get away from the edge to the
core.  You may be able to do IPS as a bump in the wire at the core if
you have the horsepower, but you are going to be forced to the edge for
other security stuff if you insist on bump in the wire.  Single point
of failure, scalability and cost are just working against you.
Eventually you have to turn to the switch. I just don’t get where he is
coming from here.

So you’re saying that your business model is already dead, Alan?

The final piece of irony is this:

Has selling big-ass, honking ASIC boxes to do IPS for so long totally
blinded them to virtualizing some of this stuff and putting it on
blades and so forth inside the switch and network.

Um, no. Again, not like I feel any inclination to defend Tippingpoint, but it’s apparent that Alan is not aware of TippingPoint’s M60 which is a huge multi-gigabit LAN switching platform (10-14 slots) with integrated IPS (and other functionality) that can either replace a typical switch or connect to existing switch fabrics to form an overlay security service.  It’s about a year overdue from the last announcement, but the M60 is an impressive piece of iron:

Each blade in the M60 acts as a stand-alone IPS device, similar to
TippingPoint’s T-series appliances, in which network connectivity and
IPS packet processing are done on the hardware. (The exception is with
10G interfaces; the M60 uses 3Com’s 8800 dual-port 10G blades, which
connect to TippingPoint IPS blades through the switch’s backplane.)

The blades run 3Com’s TippingPoint IPS device operating system and use the vendor’s Digital Vaccine updating service, letting  the device identify the latest threat signatures and vulnerabilities.

This was one of the results of the Huawei joint venture with 3Com.  I believe that THIS is really what Brian Smith is talking about, not device sprinkling appliances.  It’s  a switch.  It’s an IPS.  That’s bad, how?

What has me confused is that if Alan is so against hanging security services/functions OFF a switch, why did StillSecure do the deal with Extreme Networks in which the concept is to hang an appliance (the Sentriant AG) off the switch as an appliance instead of "inside" it like he suggests is the only way to effectively demonstrate the convergence of networking and security?

So, I totally get Brian Smith’s comments (despite the fact that he’s a competitor AND works for a switch vendor — who, by the way, also OEM’d Crossbeam’s X-Series Security Services Switches prior to their Tippingpoint acquisition!)

The model is valid.  Overlaying security as an intelligent service layer on top of the network is a great approach.  Ask me how I know. 😉

Chris

Alan Shimel is commenting here on his blog in this post titled "People are not appliances they’re flexible."  In this entry he muses on about vocational "flexibility" and what appears to be the "cosmic humanity" of folks in the IT/Security space.

He also keeps talking about the need to keep buying COTS hardware appliances…he’ll never learn!

Specifically, Alan’s argument (which is orthogonal to the actual topic) is that as specialized appliances proliferate, he disagrees with the fact that the operators and administrators of said appliances must also specialize.  In fact, he waxes on about the apparent good-natured ebb and flow of utilitarian socialism and how ultimately we’re all re-trainable and can fluidly move from one discipline to another irrespective of the realities and vagaries of culture and capability.

Using that as an example it seems that a help-desk admin who deploys patches from one appliance can just pick up and start doing IDS analysis on another?  How about that same  "appliance" technician reading PCI for dummies and starting to manage firewall appliances doing policy manipulation?  Sure, they’re re-trainable, but at what incidental cost?  Seems a little naive of a statement for my tastes.

Mike Murray from nCircle on the other hand suggests that Enterprises inherently gravitate toward silos.  I totally agree — emphatically as we speak about larger Enterprises.  Operationalizing anything within a big machine means that you have political, operational and economic silos occuring naturally.  It’s even a byproduct of compliance, separation of duties and basic audit-output mitigation strategies.  Specializing may be "bad" but it’s what happens. 

Appliances don’t cause this, the quest for money or the love of what you do, does.

Even if Alan ignores the fact that you don’t have to keep buying individual appliances (you can consolidate them) the fact is that different elements within the organization manage the functions on them.   Even on our boxes…when you have firewall, IDP and AV in an X80 chassis, three different groups (perhaps more) manage and operate these solutions.  Silos, each and every one of them.

Nature of the beast.

That being said, this doesn’t mean I don’t disagree that I’d *like* to see more cross-functional representation across solution sets, but it’s just not reality:

Evolution teaches us that too specialized a species is a recipe for
extinction. That is what we need from our appliance models, flexibility
and adaptability, not more silos!  We need to break down the silos and
have interaction among them to improve productivity.

One could take that argument and extrapolate it to explain why people are so polarized on certain issues such as (for example) security and its ultimate place in the Enterprise: in the network or in specialized appliances.   

Innovation, specialization and (dare I say) evolution suggests that survival of the "fittest" can also be traced back to the ability to not just "survive" but thrive based upon the ability to adapt in specificity to what would otherwise be an extinguishing event.  Specialization does not necessarily infer it’s a single temporal event.  The cumulative or incremental effect of successive specialization can also provide an explanation for how things survive.  Take the platypus as an example.  It ended up with a beaver’s tail and a duck’s bill.  Go figure. 😉

What’s important here is the timing of this adaptation and how the movie plays forward.

Hoff