Rational Survivability

Sacred Cows, Meatloaf, and Solving the Wrong Problems...

Just as I finished up a couple of posts decrying the investments being made in lumping device after device on DMZ boundaries for the sake of telling party guests that one subscribes to the security equivalent of the "Jam of the Month Club," (AKA Defense-In-Depth) I found a fantastic post on the CERIAS blog where Prof. Eugene Spafford wrote a fantastic piece titled "Solving Some of the Wrong Problems."

In the last two posts (here and here,) I used the example of the typical DMZ and it's deployment as a giant network colander which, despite costing hundreds of thousands of dollars, doesn't generally deliver us from the attacks it's supposedly designed to defend against -- or at least those that really matter.

This is mostly because these "solutions" treat the symptoms and not the problem but we cling to the technology artifacts because it's the easier road to hoe.

I've spent a lot of time over the last few months suggesting that people ought to think differently about who, what, why and how they are focusing their efforts.  This has come about due to some enlightenment I received as part of exercising my noodle using my blog.  I'm hooked and convinced it's time to make a difference, not a buck.

My rants on the topic (such as those regarding the Jericho Forum) have induced the curious wrath of technology apologists who have no answers beyond those found in a box off the shelf.

I found such resonance in Spaf's piece that I must share it with you. 

Yes, you.  You who have chided me privately and publicly for my recent proselytizing that our efforts are focused on solving the wrong sets of problems.   The same you who continues to claw disparately at your sacred firewalls whilst we have many of the tools to solve a majority of the problems we face, and choose to do otherwise.  This isn't an "I told you so."  It's a "You should pay attention to someone who is wiser than you and I."

Feel free to tell me I'm full of crap (and dismiss my ramblings as just that,) but I don't think that many can claim to have earned the right to suggest that Spaf has it wrong dismiss Spaf's thoughts offhandedly given his time served and expertise in matters of information assurance, survivability and security:

As I write this, I’m sitting in a review of some university research in cybersecurity. I’m hearing about some wonderful work (and no, I’m not going to identify it further). I also recently received a solicitation for an upcoming workshop to develop “game changing” cyber security research ideas. What strikes me about these efforts — representative of efforts by hundreds of people over decades, and the expenditure of perhaps hundreds of millions of dollars — is that the vast majority of these efforts have been applied to problems we already know how to solve.

We know how to prevent many of our security problems — least privilege, separation of privilege, minimization, type-safe languages, and the like. We have over 40 years of experience and research about good practice in building trustworthy software, but we aren’t using much of it.

Instead of building trustworthy systems (note — I’m not referring to making existing systems trustworthy, which I don’t think can succeed) we are spending our effort on intrusion detection to discover when our systems have been compromised.

We spend huge amounts on detecting botnets and worms, and deploying firewalls to stop them, rather than constructing network-based systems with architectures that don’t support such malware.

Instead of switching to languages with intrinsic features that promote safe programming and execution, we spend our efforts on tools to look for buffer overflows and type mismatches in existing code, and merrily continue to produce more questionable quality software.

And we develop almost mindless loyalty to artifacts (operating systems, browsers, languages, tools) without really understanding where they are best used — and not used. Then we pound on our selections as the “one, true solution” and justify them based on cost or training or “open vs. closed” arguments that really don’t speak to fitness for purpose. As a result, we develop fragile monocultures that have a particular set of vulnerabilities, and then we need to spend a huge amount to protect them. If you are thinking about how to secure Linux or Windows or Apache or C++ (et al), then you aren’t thinking in terms of fundamental solutions.

Please read his entire post.  It's wonderful. Dr. Spafford, I apologize for re-posting so much of what you wrote, but it's so fantastically spot-on that I couldn't help myself.

Timing is everything.

/Hoff

{Ed: I changed the sentence regarding Spaf above after considering Wismer's comments below.  I didn't mean to insinuate that one should preclude challenging Spaf's assertions, but rather that given his experience, one might choose to listen to him over me any day -- and I'd agree!  Also, I will get out my Annie Oakley decoder ring and address that Cohen challenge he brought up after at least 2-3 hours of sleep... ;) }

On Castles: Moats, Machicolations, Burning Oil and Berms Vs. The Trebuchet (or DMZ's teh Sux0r!)

Check out the comments in the last post regarding my review of the recently released film titled "Me and My DMZ - 'Til Death Do Us Part"

Carrying forward the mental exercise of debating the application of the classical DMZ deployment and it's traceable heritage to the concentric levels of defense-in-depth from ye olde "castle/moat" security analogy, I'd like to admit into evidence one interesting example of disruptive technology that changed the course of medieval castle siege warfare, battlefield mechanics and history forever: the Trebuchet.

The folks that advocated concentric circles of architectural defense-in-depth as their strategy would love to tell you about the Trebuchet and its impact.  The problem is, they're all dead.  Yet I digress.

The Trebuchet represented a quantum leap in the application of battlefield weaponry and strategy that all but ended the utility of defense-in-depth for castle dwellers.  Trebuchets were amazingly powerful weapons and could launch projectiles up to several hundred pounds with a range of up to about 300 yards!

The Trebuchet allowed for the application of technology that put the advantages of time, superior firepower and targeted precision squarely in the hands of the attacker and left the victim to simply wait until the end came. 

To review the basics, a castle is a defensive structure built around a keep or center structure.  The castle is a fortress, a base from which to mount a defense against a siege or center of operations from which to conduct an attack.  The goal of these defenses is to repel, delay, deny, disrupt, and incapacitate the enemy. However, the castle on its own will not provide a defense against a determined siege force.

One interesting point is that the assumption holds true that all the insiders are "friendlies..."

Here we have an illustration of a well-fortified castle with the Keep in the center surrounded by multiple cascading levels of defense spiraling outward.  Presumably as an attacker breached one defensive boundary, they would encounter yet another with the added annoyance of defensive/offensive tactics such as archers, spiked pits, burning oil, etc.

Breaching one of these things took a long time, cost a lot of lives and meant a significant investment in time, materials, and effort.  Imagine what is was like for the defenders!

Enter the Trebuchet.  You wheel one of these bad boys within effective strike range, but out of range of the castle defender's archers, and launched hurling masses of projectiles toward and over walls, obliterating them and most anything nearby.  You have a BBQ while a rotated crew of bombardiers merrily flung hunks of pain toward the hapless and helpless defenders.  They can either stay and die or run out the gate and die.

This goes on and on.  Stuff inside starts to burn.  Walls crumble.  People start to starve.  The attackers then start flinging over dead corpses -- animals, humans, whatever.  Days and perhaps weeks pass.  Disease sets in.  The bombardment continues until there are no defenses left, most of the defenders have either died or plan to and the enemy marches in and dispatches the rest.

What's the defense against a Trebuchet?  You mean besides rebuilding your castle in the middle of a lake out of range making it exceedingly difficult to live as an inhabitant?  Not a lot.  In short, artillery meant the end of the castle as a defensive measure.  It simply stopped working.

Let's be intellectually honest here within the context of this argument.  We're facing our own version of the Trebuchet with the tactics, motivation, skill, tools and directed force of how attackers engage us today.  Most modern day castle technology apologists are content to simply sit in their keeps, playing Parcheesi and extolling the virtues of their fortifications, while the determined leviathan force smashes down the surrounding substructure.

There came a point in the illustration above wherein the art of warfare and the technology involved completely changed the playing field.  We've reached that point now in information warfare, yet people still want to build castles.

What I think people really want to say privately in their stoic defense of the DMZ and defense-in-depth is that they can't think of anything else that's better at the moment and they're simply trying to wait out the bombardment.  Too bad the attackers aren't governed by such motivating encouragement.

Look, I'm not trying to be abrasively critical of what people have done -- I've done it, too.  I'm also not suggesting that we immediately forklift what's in place now; that's not feasible or practical.  However, I am being critical of people who continue to hang onto and defend outmoded concepts and suggest it's an acceptable idea to fight a conventional war against a force using guerilla tactics and superior tools with nothing but time and resources on their hands.

There has to be a better way than just waiting to die.

If you don't think differently about how you're going to focus your efforts and with what, here's what you have to look forward to:

/Hoff

The DMZ Isn't Dead...It's Merely Catatonic

Joel Espenschied over at Computerworld wrote a topical today titled "The DMZ's not dead...whatever the vendors are telling you."  Joel basically suggests that due to poorly written software, complex technology such as Web Services and SOA and poor operational models, that the DMZ provides the requisite layers of defense in depth to provide the security we need.

I'm not so sure I'd suggest that DMZ's provide "defense in depth."  I'd suggest they provide segmentation and isolation, but if you look at most DMZ deployments they represent the typical Octopus approach to security; a bunch of single segments isolated by one (or a cluster) or firewalls.  It's the crap surrounding these segments that is appropriately tagged with the DiD moniker.

A DMZ is an abstracted representation of a security architecture, while I argue that defense in depth is an control implementation strategy...and one I think needs to be dealt with as honestly by security/network teams as it is by Enterprise Architects.  My simple truth is that there are now hundreds if not thousands of "micro-perimeterized single host" DMZ's in most enterprise networks today and we lean on defense in depth as a crutch and a bad habit because we're treating the symptom and not the problem -- and it's the only thing that most people know.

By the way, defense in depth doesn't mean 15 network security boxes piled on top of one another.  Defense in depth really spoke to this model which entailed a holistic view of the "stack" -- but in a coordinated manner.  You must focus on data, applications, host and networking as equal and objective recipients of investment in a protection strategy, not just one.

Too idealistic?  Waiting for me to run out of air holding my breath for secure applications, operating systems and protocols?  Good.  We'll see who plays chicken first. 

You keep designing for obsolescence and the way things were 10 years ago while I look at what the business needs and where its priorities are and how best to balance risk with sharing information.  We'll see who's better prepared in the next three year refresh cycle to tackle the problems that arise as the business continues to embrace disruptive technology while you become the former by focusing on the latter.

There's a real difference between managing threats and vulnerabilities versus managing risk.  Back to the article.

Two quotes stand out in the bunch, and I'll focus on them:

The philosophy of Defense in Depth is based on the idea that stuff invariably fails or is cracked, and it ought to take more than one breach event before control is lost over data or processes. But with this "dead DMZ" talk, the industry seems to be inching away from that idea -- and toward potential trouble.

Right.  I see how effective that's been with all the breaches thus far.  Please demonstrate how defense in depth has protected us against XSS, CSRF, SQL Injection and fuzzing so far?  How about basic wireless security issues?  How about data leakage?  Your precious design anachronism isn't looking so good at this point.  You spend hundreds of thousands of dollars and are still completely vulnerable.

That's because your defense in depth is really defense in breadth and it's being applied to the wrong sets of problems.  Where's the security value in that?

The talking heads may say the DMZ is dead, but those actually managing enterprise IT installations shouldn't give it up so easily. Until no mistakes are made in application coding, placement, operations and other processes -- and you know better than to hold your breath -- layered network security controls still provide a significant barrier to loss of data or other breach. The advice regarding application configuration and optimization is useful and developers' efforts to make that work are encouraging, but when it comes to the real-world network, organizations can't just ignore the reality of undiscovered vulnerabilities and older systems still lurking in the corners.

Look, the reality is that "THE DMZ" is dead, but it doesn't mean "the DMZ" is...it simply means you have to reassess and redefine both your description and expectation of what a DMZ and defense in depth really mean to your security posture given today's attack surfaces.

Keep your firewalled DMZ Octopi for now, but realize that with the convergence of technologies such as virtualization, mobility, Mashups, SaaS, etc., the reality is that a process or data could show up running somewhere other than where you thought it was -- VMotion is a classic example.

If security policies don't/can't travel with affinity to the resources they protect, your DMZ doesn't mean squat if I just VMotioned a VM to a segment that doesn't have a firewall, IDS, IPS, WAF and Proxy in front of it.

THAT'S what these talking heads are talking about while you're intent on sticking yours in the sand.  If you don't start thinking about how these disruptive technologies will impact you in the next 12 months, you'll be reading about yourself in the blogosphere breach headlines soon enough.

Think different.

/Hoff

Captain Stupendous -- Making the Obvious...Obvious! Jericho Redux...

Sometimes you have to hurt the ones you love. 

I'm sorry, Rich.  This hurts me more than it hurts you...honest.

The Mogull decides that rather than contribute meaningful dialog to discuss the meat of the topic at hand, he would rather contribute to the FUD regarding the messaging of the Jericho Forum that I was actually trying to wade through.

...and he tried to be funny.  Sober.  Painful combination.

In a deliciously ironic underscore to his BlogSlog, Rich caps off his post with a brilliant gem of obviousness of his own whilst chiding everyone else to politely "stay on message" even when he leaves the reservation himself:

"I formally submit “buy secure stuff” as a really good one to keep us busy for a while."

<phhhhhht> Kettle, come in over, this is Pot. <phhhhhhttt> Kettle, do you read, over? <phhhhhhht>  It's really dark in here <phhhhhhttt>

So if we hit the rewind button for a second, let's revisit Captain Stupendous' illuminating commentary.  Yessir.  Captain Stupendous it is, Rich, since the franchise on Captain Obvious is plainly over-subscribed.

I spent my time in my last post suggesting that the Jericho Forum's message is NOT that one should toss away their firewall.  I spent my time suggesting that rather reacting to the oft-quoted and emotionally flammable marketing and messaging, folks should actually read their 10 Commandments as a framework. 

I wish Rich would have read them because his post indicates to me that the sensational hyperbole he despises so much is hypocritically emanating from his own VoxHole. <sigh>

Here's a very high-level generalization that I made which was to take the focus off of "throwing away your firewall":

Your perimeter *is* full of holes so what we need to do is fix the problems, not the symptoms.  That is the message.

And Senor Stupendous suggested:

Of course the perimeter is full of holes; I haven’t met a security professional who thinks otherwise. Of course our software generally sucks and we need secure platforms and protocols. But come on guys, making up new terms and freaking out over firewalls isn’t doing you any good. Anyone still think the network boundary is all you need? What? No hands? Just the “special” kid in back? Okay, good, we can move on now.

You're missing the point -- both theirs and mine.  I was restating the argument as a setup to the retort.  But who can resist teasing the mentally challenged for a quick guffaw, eh, Short Bus?

Here is the actual meat of the Jericho Commandments.  I'm thrilled that Rich has this all handled and doesn't need any guidance.  However, given how I just spent my last two days, I know that these issues are not only relevant, but require an investment of time, energy, and strategic planning to make actionable and remind folks that they need to think as well as do.

I defy you to show me where this says "throw away your firewalls."

Repeat after me: THIS IS A FRAMEWORK and provides guidance and a rational, strategic approach to Enterprise Architecture and how security should be baked in.  Please read this without the FUDtastic taint:

Rich sums up his opus with this piece of reasonable wisdom, which I wholeheartedly agree with:

You have some big companies on board and could use some serious pressure to kick those market forces into gear.

...and to warm the cockles of your heart, I submit they do and they are.  Spend a little time with Dr. John Meakin, Andrew Yeomans, Stephen Bonner, Nick Bleech, etc. and stop being so bloody American ;)  These guys practice what they preach and as I found out, have been for some time.

They've refined the messaging some time ago.  Unload the baggage and give it a chance.

Look at the real message above and then see how your security program measures up against these topics and how your portfolio and roadmap provides for these capabilities.

Go forth and do stupendous things. <wink>

/Hoff

The British Are Coming! In Defense (Again) of the Jericho Forum...

The English are coming...and you need to give them a break.  I have.

Back in 2006, after numerous frustrating discussions dating back almost three years without a convincing conclusion, I was quoted in an SC Magazine article titled "World Without Frontiers" which debated quite harshly the Jericho Forum's evangelism of a security mindset and architecture dubbed as "de-perimeterization."

Here's part of what I said:

Some people dismiss Jericho as trying to re-invent the wheel. "While the group does an admirable job raising awareness, there is nothing particularly new either in what it suggests or even how it suggests we get there," says Chris Hoff, chief security strategist at Crossbeam Systems.

"There is a need for some additional technology and process re-tooling, some of which is here already – in fact, we now have an incredibly robust palette of resources to use. But why do we need such a long word for something we already know? You can dress something up as pretty as you like, but in my world that's not called 'deperimeterisation', it's called a common sense application of rational risk management aligned to the needs of the business."   

Hoff insists the Forum's vision is outmoded. "Its definition speaks to what amounts to a very technically focused set of IT security practices, rather than data survivability. What we should come to terms with is that confidentiality, integrity and availability will be compromised. It's not a case of if, it's a case of when.

The focus should be less on IT security and more on information survivability; a pervasive enterprise-wide risk management strategy and not a narrowly-focused excuse for more complex end-point products," he says.

But is Jericho just offering insight into the obvious? "Of course," says Hoff. "Its suggestion that "deperimeterisation" is somehow a new answer to a set of really diverse, complex and long-standing IT security issues... simply ignores the present and blames the past," he says.

"We don't need to radically deconstruct the solutions universe to arrive at a more secure future. We just need to learn how to appropriately measure risk and quantify how and why we deploy technology to manage it. I admire Jericho's effort, and identify with the need. But the problem needs to be solved, not renamed."

I have stated previously that this was an unfortunate reaction to the marketing of the message and not the message itself, and I've come to understand what the Jericho Forum's mission and its messaging actually represents.  It's a shame that it took me that long and that others continue to miss the point.

Today Mike Rothman commented about NetworkWorld's coverage of the latest Jericho Forum in New York last week.  The byline of the article suggested that "U.S. network execs clinging to firewalls" and it seems we're right back on the Hamster Wheel of Pain, perpetuating a cruel myth.

After all this time, it appears that the Jericho Forum is apparently still suffering from a failure to communicate -- there exists a language gap -- probably due to that allergic issue we had once to an English King and his wacky ideas relating to the governance of our "little island."  Shame, that.

This is one problem that this transplanted Kiwi-American (same Queen after-all) is motivated to fix.

Unfortunately, the Jericho Forum's message has become polluted and marginalized thanks to a perpetuated imprecise suggestion that the Forum recommends that folks simply turn off their firewalls and IPS's and plug their systems directly into the Internet, as-is.

That's simply not the case, and in fact the Forum has recognized some of this messaging mess, and both softened and clarified the definition by way of the issuance of their "10 Commandments." 

You can call it what you like: de-perimeterization, re-perimeterization or radical externalization, but here's what the Jericho Forum actually advocates, which you can read about here:

De-perimeterization explained
    The huge explosion in business use of the Web protocols means that:    

• today the traditional "firewalled" approach to securing a network boundary is at best flawed, and at worst ineffective. Examples include:        
  • business demands that tunnel through perimeters or bypass them altogether
  • IT products that cross the boundary, encapsulating their protocols within Web protocols
  • security exploits that use e-mail and Web to get through the perimeter.
        
• to respond to future business needs, the break-down of the traditional distinctions between “your” network and “ours” is inevitable
• increasingly, information will flow between business organizations over shared and third-party networks, so that ultimately the only reliable security strategy is to protect the information itself, rather than the network and the rest of the IT infrastructure   
  

This trend is what we call “de-perimeterization”. It has been developing for several years now. We believe it must be central to all IT security strategies today.

The de-perimeterization solution
    While traditional security solutions like network boundary technology will continue to have their roles, we must respond to their limitations. In a fully de-perimeterized network, every component will be independently secure, requiring systems and data protection on multiple levels, using a mixture of

• encryption
• inherently-secure computer protocols
• inherently-secure computer systems
• data-level authentication

The design principles that guide the development of such technology solutions are what we call our “Commandments”, which capture the essential requirements for IT security in a de-perimeterized world.

I was discussing these exact points today in a session at an Institute for Applied Network Security conference today (and as I have before here) wherein I summarized this as the capability to:

Take a host with a secured OS, connect it into any network using whatever means you find appropriate, without regard for having to think about whether you're on the "inside" or "outside." Communicate securely, access and exchange data in policy-defined "zones of trust" using open, secure, authenticated and encrypted protocols.

Did you know that one of the largest eCommerce sites on the planet doesn't even bother with firewalls in front of its webservers!?  Why?  Because with 10+ Gb/s of incoming HTTP and HTTP/S connections using port 80 and 443 specifically, what would a firewall add that a set of ACLs that only allows port 80/443 through to the webservers cannot?

Nothing.  Could a WAF add value?  Perhaps.  But until then, this is a clear example of a U.S. company that gets the utility of not adding security in terms of a firewall just because that's the way it's always been done.

From the NetworkWorld article, this is a clear example of the following:

The forum’s view of firewalls is that they no longer meet the needs of businesses that increasingly need to let in traffic                         to do business. Its deperimeterization thrust calls for using secure applications and firewall protections closer to user devices and servers.

It's not about tossing away prior investment or abandoning one's core beliefs, it's about about being honest as to the status of information security/protection/assurance, and adapting appropriately.

Your perimeter *is* full of holes so what we need to do is fix the problems, not the symptoms.
That is the message.

So consider me the self-appointed U.S. Ambassador to our friends across the pond.  The Jericho Forum's message is worth considering and deserves your attention.

/Hoff