Rational Survivability

One of the more interesting things I get to do in my job is steer discussions with customers and within industry on the topic of innovation.  After all, the ‘I’ word is in my official title: Chief Architect, Security Innovation.  You don’t often see those two words utilized in union.

Specifically, I get my jollies discussing with folks up and down the stack how "Information Security" can and should embrace disruptive technology/innovation and actually become innovative in the process.

It’s all a matter of perspective — and clever management of how, what and why you do what you do…and as we’ve discovered, how you communicate that.

Innovation can simply be defined as people implementing new ideas to creatively solve problems and add value.  How you choose to define "value" really depends upon your goal and how you choose to measure the impact (or difference as some like to describe it) on the business you serve.  We don’t need to get into that debate for the moment, however.

Disruptive technology/innovation is a technology, product or service that ultimately overturns the dominant market leader, technology or product.  This sort of event can happen quickly or gradually and can be evolutionary or revolutionary in execution.  In many cases, the technology itself is not the disruptive catalyst, but rather the strategy, business model or marketing/messaging creates the disruptive impact.

It’s really an interesting topic and an important one at this period in time; we’ve got a rough patch to hoe in the "Information Security" world.  The perception of what we do and what value we add is again being called into question.  This is happening because while the business innovates to gain competitive advantage, we present bigger bills that suckle profit away from the bottom line without being viewed as contributing to the innovative process but rather strictly as a cost of doing business.

I’m delivering my keynote at the Information Security Decisions conference on this very topic. The focus of the presentation will demonstrate that how even with emerging disruptive innovations that have profound impact upon what we do such as SaaS, the consumerization of IT and virtualization, "Information Security" practitioners and managers can not only embrace these technologies in a prescribed and rational manner, but do so in a way that provides alignment to the business and turns disruptive technology into an opportunity rather than a curse.

If you’re in Chicago on November 5th at the ISD conference, come throw stuff at me…they’ve got a great cast of speakers queued up: Bruce Schneier, Howard Schmidt, Eugene Spafford, David Litchfield, Dave Dittrich, David Mortman, Stephen Bonner, Pete Lindstrom, and many more.  It’ll be a good conference.

/Hoff

Many of my more recent posts on Information Survivability and the death of the TERM Information Security have focused on bringing attention to the assertion that the current definition and scope of "Information Security" is causing resources, money and effort to be focused on solving the wrong sets of problems, or at least those that are missing alignment to the business. 

The world has evolved and yet the manner in which we attempt to secure it has not.

Specifically, "Information Security" has, for the most part, become very narrow and technically-focused.  As computing and the manner in which we create, access and use information have become more and more distributed and decentralized, the model of "Information Security" continues to operate in a very archaic centralized manner (ye olde Castle/Moat paradigm.)

I think it’s fair to assume that folks grok that "Information Security" is classically defined as the protection of information and information systems from unauthorized
access, use, disclosure, disruption, modification, or destruction.^[1]  The model is clearly built upon the "holy trinity" of Confidentiality, Integrity and Availability (CIA.)  There is little merit in debating the utility or efficacy of this model as it is generally useful and reasonable.  However, as a model, it is also an incomplete definition of the problem set it seeks to solve.

It’s very important to recognize that I’m not saying that Information Security is "wrong" or that the operational practitioners that are in the trenches every day fighting what they perceive to be the "good fight" are doing anything wrong.  However, and as Rich Mogull so eloqently described, we’ve lost the language to describe what it is we should be doing and the title, scope, definition and mission of "Information Security" has not kept up with the evolution of business, culture, technology or economics.

"Information Survivability" is a model which represents a superset of "Information Security."  It focuses on bringing together the tenets of the CIA triumvirate with the business-focused practices of risk management as an enterprise-wide discipline.  Today, "Information Security" focuses on providing technical solutions designed to defend against threats targeting vulnerabilities.  There is little context of business impact, risk or the fact that many of the problems we face in "securing" information are actually social issues not technical ones which require different ways of thinking about solving problems.

One of the seminal reference works which describes Information Survivability is a paper written in 2002 by Julia Allen and Dr. Carol Sledge from Carnegie Mellon’s Software Engineering Institute.  In their paper titled "Information Survivability: Required Shifts In Perspective," Allen and Sledge describe a (then) new model for integrating the business’ perspective, risk management practices, and embracing disruptive innovation and technology shifts whilst ensuring the survivability of critical information and systems.

If you read this paper I believe you’ll draw both parallels and recognize the differences in thought, execution and relevance between Information Survivability and Information Security.  This work was really well ahead of its time.  Here are some snippets from the paper.  Remember, this was written back in 2002.

Organizations today are part of an interconnected, globally networked environment – one that continuously evolves in ways that cannot be predicted. What effect does this environment have on the survivability of the mission of an organization? To improve survivability, organizations must shift their focus from a more information security-centric perspective to one that includes an information survivability-centric perspective.

Survivability, an emerging discipline, incorporates a new technical and business perspective on security, creating solutions that focus on elements such as the continuity of critical services.  In terms of solution space, security takes a technology centric point of view, with each new technology solving a specific set of issues and concerns that are generally separate and distinct from one another.  Survivability takes a broader, more enterprise-wide point of view looking at solutions that are more pervasive than point-solution oriented.

Survivability is defined as the capability of a system to fulfill its mission, in a timely manner, in the presence of attacks, failures, or accidents to ensure
that the right people get the right information at the right time.  A survivability approach combines risk management and
contingency planning with computer security to protect highly
distributed information services and assets in order to sustain
mission-critical functions. Survivability expands the view of security
from a narrow, technical specialty understood only by security experts
to a risk management perspective with participation by the entire
organization and stakeholders.

To improve the survivability of the organization’s mission, senior management must shift its focus and that of the organization from an information technology (IT)-based, security-centric, technology solution perspective, to an enterprise-based, survivability-centric, risk management perspective.

To underscore the need for change in thought space, Allen and Sledge define seven shifts in perspective that are essential in grasping the difference between "security" and "survivability" and reflect quite eerily the exact state of the challenges we face today:

1. Central to Global
   Systems that are centrally-networked under organizational control with full
   visibility are shifting to systems that are globally-networked with no well-defined
   boundaries, limited (if any) visibility and no centralized management or control.
2. Bounded to Unbounded
   Systems that have well-defined geographic, political, cultural, and legal or jurisdic-
   tional boundaries are shifting to systems characterized by the absence of these boundaries.
   Centralized administrative control with trustworthy, known, inside users evolves
   to systems with distributed administrative control without central authority and
   unknown users.
3. Insular to Networked
   Viewing systems as insular and fortress-like, to viewing systems as being net-
   worked and interdependent; the ability to distinguish between insiders and outsiders
   decreases. Outsider roles go from being well-defined to the realization that an out-
   sider can be a customer, collaborator, partner, contractor, or vendor; outsider
   access to the network changes based on that role.
4. Predictable to Asynchronous
   Describes the shift wherein processing events that happen in predictable, prescribed
   sequences and patterns with predictable loads, to one where events often occur
   asynchronously, independent of time sequence with unpredictable loads.
5. Single Responsibility to Shared Responsibility
   Progress from single responsibility to shared organizational responsibility to distributed
   responsibility. This is a shift from having a single point of known responsibility to
   correct failures, to having shared sometimes unknown responsibility.
6. Overhead to Essential
   The sixth shift in perspective is from viewing security as an overhead activity
   and expense, to viewing survivability as an investment that is essential to the
   organization, along with ensuring that there is always a contingency plan. It
   reflects a change of view. Instead of security being IT’s responsibility, with IT and
   the CIO constantly having to justify their budget for security, survivability is regu-
   larly reviewed and discussed in senior-level management meetings and is accepted
   by all as part of being in business.
7. Security to Survivability
   The seventh shift in perspective is from technologic IT-based solutions to enterprise-wide, risk-management solutions.  Instead of viewing security as a narrow, technical specialty
   accessible only to experts and focusing on the protection of specific components, survivability
   is embraced as a risk-management perspective that requires involvement of the whole organization and focuses on the survival of the mission rather than a particular component.

   Senior managers must change their view that “protecting the network is a matter of listening
   to the right experts and installing the right technology solutions.”Rather, their declared view is that “the survival of the mission depends on the ability of the network to provide continuity of service, albeit degraded, in the presence of attacks, failures, or accidents.”

   The shift is indicated by the absence of silver-bullet thinking. It is replaced by understanding that this is a long-term, continuous activity required for the success of the organization.

If you’re interested in a graphical format, you should most definitely check out "Concepts and Trends in Information Survivability" as it’s a wonderful illustrated presentation that highlights the concepts above.

You should also check out Howard Lipson and David Fisher’s excellent paper titled "Survivability — A New Technical and Business Perspective on Security."

I also liked Dr.
Wm. A. Wulf of the National Academy of Engineering’s testimony before the US House of Representatives in 2001 titled "Cyber Security: Beyond the Maginot Line"  I think I’ve been channeling him for quite some time now 😉

I’ve received about a dozen emails suggesting that Information Survivability just focuses on availability.  I would hope that it’s clear this is not the case and in fact availability is one component of survivability. 

I’ll post more relevant background on Information Survivability soon but I thought this would give you something to chew on for a while.

/Hoff

*Picture at top left from 2006 Cyber Security and Information Infrastructure Research Workshop

This isn’t going to be a fancy post with pictures.   It’s not going to be long.  It’s not particularly well thought out, but I need to get it out of my head and written down as tomorrow I plan on beginning a new career. 

I am retiring from the Information Security rat race and moving on to something fulfilling, achievable, impacting and that will make a difference.

Why?

Mogull just posted Information Security’s official eulogy titled "An Optimistically Fatalistic View of The Futility of Security."

He doesn’t know just how right he is.

Sad, though strangely inspiring, it represents the highpoint of a lovely internment ceremony replete with stories of yore, reflections on past digressions, oddly paradoxical and quixotic paramedic analogies, the wafting fragility of the human spirit and our unstoppable yearning to all make a difference.  It made me all weepy inside.   You’ll laugh, you’ll cry.  Before I continue, a public service announcement:

I’ve been instructed to ask that you please send donations in lieu of flowers to Mike Rothman so he can hire someone other than his four year old to produce caricatures of "Security Mike."  Thank you.

However amusing parts of it may have been, Rich has managed to catalyze the single most important thought I’ve had in a long time regarding this topic and I thank him dearly for it.

Along the lines of how Spaf suggested we are solving the wrong problems comes my epiphany that this is to be firmly levied on the wide shoulders of the ill-termed industrial complex and practices we have defined to describe the terminus of some sort of unachievable end-state goal.  Information Security represents  a battle we will never win.

Everyone’s admitted to that, yet we’re to just carry on "doing the best we can" as we "make a difference" and hope for the best?  What a load of pessimistic, nihilist, excuse-making donkey crap.  Again, we know that what we’re doing isn’t solving the problem, but rather than admitting the problems we’re solving aren’t the right ones, we’ll just keep on keeping on?

Describing our efforts, mission, mantra and end-state as "Information Security" or more specifically "Security" has bred this unfaithful housepet we now call an industry that we’re unable to potty train.  It’s going to continue to shit on the carpet no matter how many times we rub it’s nose in it.

This is why I am now boycotting the term "Information Security" or for that matter "Security" period.  I am going to find a way to change the title of my blog and my title at work.

Years ago I dredged up some research that came out of DARPA that focused on Information Assurance and Information Survivability.  It was fantastic stuff and profoundly affected what and how I added value to the organizations I belonged to.  It’s not a particularly new, but it represents a new
way of thinking even though it’s based on theory and practice from many
years ago.

I’ve been preaching about the function without the form.  Thanks to Rich for reminding me of that.

I will henceforth only refer to what I do — and my achievable end-state — using the term Information Survivability.

Information Survivability is defined  as “the capability of a system to fulfill its mission, in a timely manner, in the presence of attacks, failures, or accidents to ensure
that the right people get the right information at the right time.

A survivability approach combines risk management and contingency planning with computer security to protect highly distributed information services and assets in order to sustain mission-critical functions. Survivability expands the view of security from a narrow, technical specialty understood only by security experts to a risk management perspective with participation by the entire organization and stakeholders."

This is what I am referring to.  This is what Spaf is referring to.  This is what the Jericho Forum is referring to.

This is my new mantra. 

Information Security is dead.  Long live Information Survivability.  I’ll be posting all my I.S. references in the next coming days.

Rich, those paramedic skills are going to come in handy.

/Hoff

Despite the consistent heel nipping assertions that all I want to do is have people throw away their firewalls (I don’t,) I think Shrdlu nailed it with a comment posted on Lindstrom’s blog.  I’ll get to that in a second.  Here’s the setup.

Specifically, Pete maintains that Spaf’s comments (see here) are an indicator that security isn’t failing, rather we are — and by design.  We’re simply choosing not to fix the things we ought to fix:

This is a simple one, from Dr. Eugene Spafford’s blog:

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.

So,
we have resources that are unallocated – we have time, money, and
bodies we could throw at the security problem. We have the know-how and
the tools to reduce the risk. And yet, we aren’t doing it.

If security were "failing" there would be evidence of people either
giving up entirely and reducing their IT investments and resources, or
spending more money on success.

An interesting perspective and one I’m bound to agree with.

Here’s Shrdlu’s comment which I think really nails the reason I am going to continue to press the issue regardless; I think the general apathetic state of the security industry (as Pete suggests also) is the first obstacle to overcome:

Cherchez l’argent, mes amis. Mix in Spaf’s argument with Pete’s and
add Marcus and Bruce, and you’ve got the answer: people don’t think
security is failing enough to spend money doing something about it. The
externalities aren’t intolerable. The public isn’t up in arms; if
anything, security breaches have reached the same level of public
semi-awareness as bombing in Iraq — it happens every day, everyone
agrees how awful it is, and then they go back to their lattes.

We’re not going to fire or retrain a generation of cheap programming
labor to Do the Right Thing and redesign systems. Not until it hurts
enough, and let’s face it, it doesn’t. All the FUD and hand-wringing is
within the security industry. We’re doing our jobs just well enough to
keep things from melting down, so why should anyone pay more attention
and money to something that’s mediocre but not a disaster?

There’s not a whole lot more that needs to be said to embellish or underscore that argument.

I’ll be over here waiting for the next "big thing" to hit and instead of fixing it, we’ll see SoX part Deux.

See, Shrdlu’s not the only one who can toss in a little French to sound sophisticated 😉

/Hoff

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… 😉 }

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

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

Dude, maybe if we put bras on our heads and chant incoherently we can connect directly to the Internet…

Somebody just pushed my grumpy button!  I’m all about making friends and influencing people, but the following article titled "You Wouldn’t Actually Turn Off Your Firewall, Would You?" is simply a steaming heap of unqualified sensationalism, plain and simple. 

It doesn’t really deserve my attention but the FUD it attempts to promulgate is nothing short of Guinness material and I’m wound up because my second Jiu Jitsu class of the week isn’t until tomorrow night and I’ve got a hankering for an arm-bar.

Larry Seltzer from eWeek decided to pen an opinion piece which attempts for no good reason to collapse two of my favorite topics into a single discussion: de-perimeterization (don’t moan!) and virtualization. 

What one really has to do directly with the other within the context of this discussion, I don’t rightly understand, but it makes for good drama I suppose.

Larry starts off with a question we answered in this very blog (here, here, here and here) weeks ago:

Opinion: I’m unclear on what deperimeterization means. But if it means putting
company systems directly on the Internet then it’s a big mistake.

OK, that’s a sort of a strange way to state an opinion and hinge an article, Larry. Why don’t you go to the source provided by those who coined the term, here.  Once you’re done there, you can read the various clarifications and debates above. 

But before we start, allow me to just point out that almost every single remote salesperson who has a laptop that sits in a Starbucks or stays in a hotel is often connected "…directly on the Internet."  Oh, but wait, they’re sitting behind some sort of NAT gateway broadband-connected super firewall, ya?  Certainly the defenses at Joe’s Java shack must be as stringent as a corporate firewall, right?  <snore>

For weeks now I’ve been thinking on and off about "deperimeterization,"
a term that has been used in a variety of ways for years. Some analyst talk got it in the news recently.

So you’ve been thinking about this for weeks and don’t mention if
you’ve spoken to anyone from the Jericho Forum (it’s quite obvious you haven’t read their 10 commandments) or anyone mentioned in the article
save for a couple of analysts who decided to use a buzzword to get some
press?  Slow newsday, huh?

At least the goal of deperimeterization is to enhance security.
That I can respect. The abstract point seems to be to identify the
resources worth protecting and to protect them. "Resources" is defined
very, very broadly.

The overreacting approach to this goal is to say
that the network firewall doesn’t fit into it. Why not just put systems
on the Internet directly and protect the resources on them that are
worthy of protection with appropriate measures?

Certainly the network firewall fits into it.  Stateful inspection firewalls are, for the most part today, nothing more than sieves that filter out the big chunks.  They serve that purpose very nicely.  They allow port 80 and port 443 traffic through unimpeded.  Sweet.  That’s value.

Even the inventors of stateful inspection will tell you so (enter one Shlomo Kramer and Nir Zuk.)  Most "firewalls" (in the purest definition) don’t do much more than stateful ACL’s do today and are supplemented with IDS’s, IPS’s, Web Application Firewalls, Proxies, URL Filters, Anti-Virus, Anti-Spam, Anti-Malware and DDoS controls for that very reason.

Yup, the firewall is just swell, Larry.  Sigh.

I hope I’m not misreading the approach, but that’s what I got out of
our news article: "BP has taken some 18,000 of its 85,000 laptops off
its LAN and allowed them to connect directly to the Internet,
[Forrester Research analysts Robert Whiteley and Natalie Lambert]
said." This is incredible, if true.

Not for nothing, but rather than depend on a "couple of analysts," did you think to contact someone from BP and ask them what they meant instead of speculating and deriding the effort before you condemned it?  Obviously not:

What does it mean? Perhaps it just means that they can connect
to the VPN through a regular ISP connection? That wouldn’t be news. On
the other hand, what else can it mean? Whitely and Lambert seem to view
deperimeterization as a means to improve performance and lower cost. If
you need to protect the data on a notebook computer they say you should
do it with encryption and "data access controls." This is the
philosophy in the 2001 article in which the term was coined.

Honestly, who in Sam’s Hill cares what "Whitely and Lambert" seem to view deperimeterization as?  They didn’t coin the term, they butchered its true intent and you still don’t apparently know how to answer your own question. 

Further, you also reference a conceptual document floated back in 2001 ignoring the author’s caution that "The actual concept behind the entire paper never really flew, but you may find that too thought provoking."  Onward.

But of course you can’t just put a system on Comcast and have it
access corporate resources. VPNs aren’t just about security, they
connect a remote client into the corporate network. So unless everyone
in the corporation has subnet mask of 0.0.0.0 there needs to be some
network management going on.

Firstly, nobody said that network management should be avoided, where the heck did you get that!?

Secondly, if you don’t have firewalls in the way, sure you can — but that would be cheating the point of the debate.  So we won’t go there.  Yet.  OK, I lied, here we go.

Thirdly, if you look at what you will get with, say, Vista and Longhorn, that’s exactly what you’ll be able to do.  You can simply connect to the Internet and using encryption and mutual authentication, gain access to internal corporate resources without the need for a VPN client at all.  If you need a practical example, you can read about it here, where I saw it with my own eyes.

Or maybe I’m wrong. Maybe that’s what they actually want to do. This certainly sounds like the idea behind the Jericho Forum, the minds behind deperimeterization. This New York Times blog echoes the thoughts.

Maybe…but we’re just dreamers.  I dare say, Larry, that Bill Cheswick has forgotten more about security than you and I know.  It’s obvious you’ve not read much about information assurance or information survivability but are instead content to myopically center on what "is" rather than that which "should be."

Not everyone has this cavalier attitude towards deperimeterization. This article from the British Computer Society
seems a lot more conservative in approach. It refers to protecting
resources "as if [they were] directly exposed to the Internet." It
speaks of using "network segmentation, strict access controls, secure
protocols and systems, authentication and encryption at multiple
levels."

Cavalier!?  What’s so cavalier about suggesting that systems ought to be stand-alone defensible in a hostile environment as much as they are behind one of those big, bad $50,000 firewalls!? I bet you money I can put a hardened host on the Internet today without a network firewall in front of it and it will be just as resistant to attack. 

But here’s the rub, nobody said that to get from point A to point B one would not pragmatically apply host-based hardening and layered security such as (wait for it) a host-based firewall or HIPS?  Gasp!

What’s the difference between filtering TCP handshakes or blocking based on the 4/5 tupule at a network level versus doing it at the host when you’re only interested in scaling to performance and commensurately secured levels of a single host?  Except for tens of thousands of dollars.  How about Nada?  (That’s Spanish for "Damn this discussion is boring…")

And whilst my point above is in response to your assertions regarding "clients," the same can be said for "servers."  If I use encryption and mutual authentication, short of DoS/DDoS, what’s the difference?

That sounds like a shift in emphasis, moving resources more
towards internal protection, but not ditching the perimeter. I might
have some gripes with this—it sounds like the Full Employment Act for
Security Consultants, for example—but it sounds plausible as a useful
strategy.

I can’t see how you’d possibly have anything bad to say about this approach especially when you consider that the folks that make up the Jericho Forum are CISO’s of major corporations, not scrappy consultants looking for freelance pen-testing.

When considering the protection of specific resources, Whitely and
Lambert go beyond encryption and data access controls. They talk
extensively about "virtualization" as a security mechanism. But their
use of the term virtualization sounds like they’re really just talking
about terminal access. Clearly they’re just abusing a hot buzzword.
It’s true that virtualization can be involved in such setups, but it’s
hardly necessary for it and arguably adds little value. I wrote a book
on Windows Terminal Server back in 2000 and dumb Windows clients with
no local state were perfectly possible back then.

So take a crappy point and dip it in chocolate, eh?   Now you’re again tainting the vision of de-perimeterization and convoluting it with the continued ramblings of a "couple of analysts."  Nice.

Whitely and Lambert also talk in this context about how updating in
a virtualized environment can be done "natively" and is therefore
better. But they must really mean "locally," and this too adds no
value, since a non-virtualized Terminal Server has the same advantage.

What is the security value in this? I’m not completely clear
on it, since you’re only really protecting the terminal, which is a
low-cost item. The user still has a profile with settings and data. You
could use virtual machines to prevent the user from making permanent
changes to their profile, but Windows provides for mandatory (static,
unchangeable) profiles already, and has for ages. Someone explain the
value of this to me, because I don’t get it.

Well, that makes two of us..

And besides, what’s it got to do with deperimeterization? The
answer is that it’s a smokescreen to cover the fact that there are no
real answers for protecting corporate resources on a client system
exposed directly to the Internet.

Well, I’m glad we cleared that up.  Absolutely nothing.  As to the smokescreen comment, see above.  I triple-dog-dare you.  My Linux workstation and Mac are sitting on "the Internet" right now.  Since I’ve accomplished the impossible, perhaps I can bend light for you next?

The reasonable approach is to treat local and perimeter security as
a "belt and suspenders" sort of thing, not a zero sum game. Those who
tell you that perimeter protections are a failure because there have
been breaches are probably just trying to sell you protection at some
other layer.

…or they are pointing out to you that you’re treating the symptom and not the problem.  Again, the Jericho Forum is made up of CISO’s of major multinational corporations, not VP’s of Marketing from security vendors or analyst firms looking to manufacture soundbites.

Now I have to set a reminder for myself in Outlook for about
two years from now to write a column on the emerging trend towards
"reperimeterization."

Actually, Larry, set that appointment back a couple of months…it’s already been said.  De-perimeterization has been called many things already, such as re-perimeterization or radical externalization.

I don’t really give much merit to what you choose to call it, but I call it a good idea that should be discussed further and driven forward in consensus such that it can be used as leverage against the software and OS vendors to design and build more secure systems that don’t rely on band-aids.

…but hey, I’m just a dreamer.

/Hoff

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