Rational Survivability

I’ll give Rothman the props/ping for highlighting an interesting post from Sammy Migues at the Cigital "Justice League" blog.

Sammy’s post is titled "The Risk of Too Much Risk Management." 

Short of the title and what I feel is a wholly inappropriate use of the "meaning" of risk management as the hook for the story, the underlying message is sound: security for security’s sake is an obstructionist roadblock to business; the deployment of layer after layer of security controls as a knee-jerk reaction to threats and vulnerabilities is a bad thing.

I totally get that and I totally agree.  The problem I have with Sammy’s post is he’s doing the absolute worst thing possible by defining what he improperly describes as "risk management" and it’s meaning to the business and suggesting that a technology-centric application of rapid-fire reflexive information security is the same as risk management.

It’s basically making excuses for people practicing "information security" and calling it "risk management."

They are NOT the same thing. 

By associating the two he’s burying the value of the message and marginalizing the impact and value that true risk management can have within an organization. 

To wit, let’s take a look at how he describes what risk management means:

Let’s put a stake in the ground on what risk management means. I’m
not referring to how it’s defined so much as what it actually means to
business. Risk management means there is a thought process that
includes ensuring the right people with adequate skills are given
useful information and actually decide whether to do this or that to
more effectively achieve security goals. Something like, “The available
data indicate that path A at price B mitigates problems C, D, and E,
but causes problem F, while path Z at price Y, mitigates problems C, E,
and X, but causes problem W. What’s your decision?”

I’m very puzzled by this description because what’s stated above is not  "…what [risk management] actually means to the business."   The first part which describes ensuring that the right people are given access to the right data at the right time is really the output of a well-oiled business resilience operation (information survivability/assurance) which factors risk assessment and business impact into the decision fabric.

However, the "business" doesn’t "…actually decide whether to do this or that to
more effectively achieve security goals" they factor on whether they can achieve their business goals.  Security is the stuff that gets added on usually after the decision has been made.

Some people have
good gut instincts, shoot from the hip, and end up with decisions that
only occasionally burst into flames. For my risk appetite, that’s too
little risk management. Others wait for every possible scrap of data,
agonize over the possibilities, and end up with decisions that only
occasionally aren’t completely overcome by events. That’s too much risk
management.

Again, neither of those cases describes "good" risk management.  The example paints a picture of "luck, decent guesswork and perhaps a SWAG at risk assessment" or "irrational and inflexible analysis paralysis due to the lack of a solid framework for risk assessment" respectively.

The impact of too little risk management is usually too few security
controls and, therefore, too much unpredicted expense in a variety of
areas: incident response, litigation, and recovery, to name a few.
These are often the result of public things that can have lasting
effects on brand. This is easy to understand.

The impact of too much risk management is usually too many security
controls and, therefore, too much predicted expense in a variety of
areas: hardware, software, tools, people, processes, and so on. These
are all internal things that can setiously impair agility, efficiency,
and overhead, and this is usually much harder to understand.

This isn’t a game of measures from the perspective of "too little" or "too much."  Risk management isn’t a scaled weighting of how many controls are appropriate by unit volume of measure.  Within this context, risk management describes investing EXACTLY enough — no more and no less — in the controls required to meet the operational, business and security requirements of the organization.

The next paragraph is actually the meat of the topic — albeit with the continued abuse of the term risk management.  Substitute "Information Security" for "Risk Management" and he describes the very set of problems I’ve been talking about in my "Information Security is Dead" posts:

Let me clarify that I’m being a little fast and loose with “too much
risk management” above. In my experience, the problem is almost never
too much “risk management,” it’s almost always too much security fabric
resulting from a fixation on or over-thinking of each and every
security issue, whether applicable or not, combined with a natural
tendency to equate activity with progress. As a consultant, I’ve heard
some form of the following dialog hundreds of times: “What are we doing
about the security problem I’ve heard about?” followed by a confident
“We have people choosing A as we speak.” More security controls,
especially generic plug-n-play things, does not automatically mean less
risk, but it sure is highly demonstrable activity (to managers, to
auditors, to examiners).

The last paragraph basically endorses the practices of most information security programs today inasmuch as it describes what most compliance-driven InfoSec managers already know…"good enough is good enough":

All in all, too few security controls is probably the greater of the
two evils. On the other hand, it’s probably the easiest to remedy. Even
if you do no risk management at all, if you have the money to purchase
and correctly install most of the major security technologies out
there, the shotgun approach will in fact reduce security risk. You’ll
never know if you’ve done enough or if you’ve overspent, but you’ll
have a story to tell to the masses. On the other hand, a thoughtful
security approach based on sound risk management will give you a story
to tell to savvy customers and increasingly well-educated auditors and
examiners.

If the shotgun approach gives the appearance of "reducing risk" why do anything else?  Sammy certainly did not make the case as to why evolving to managing risk is paramount, valuable, and necessary and worse yet, risk management is ill defined.

If you had limited resources, limited budget, limited time and limited enthusiasm, given the options above, which would you pick?  Exactly.

Risk management is hard work.  Risk management requires a focus, mission, and operational role change.  That sort of thing has to be endorsed by the organization as a whole.  It means that in many cases what you do today is not what you’d do if you transformed your role into managing risk. 

Managing risk is a business function.  Your role ought to be advisory in nature.  It can even be operational  once the business decision has been made on how best and how much to invest in any controls needed to manage risk to an appropriate level.

Rothman summarized this well in his post "The
point I want to make is that all risk management (and security for that
matter) need to be based on the NEEDS OF THE BUSINESS. If your business
is culturally risk-taking, entrepreneurial and nimble, then you are
probably going to be on the less side of the risk management continuum.
The converse also applies. Just remember to map your security strategy
to the characteristics of your business, not the other way around."

Today, Information Security has positioned themselves as the judge, jury and executioner as a red-headed stepchild outside of the risk management process.  The problem is, it’s not really Information Security’s problem to "solve," but we nevertheless bear the weight of the crucifix we nail ourselves to.

Time to get off the cross…someone else needs the wood.

/Hoff

Update: Of course the moment I hit "Send" on this, my Google Reader alerted me that Alex Hutton had already responded in kind.  He, of course, does it better and more succinctly 😉

I found the following dialog which I borrowed liberally (and slightly modified) from the script of "A Few Good Men" deliciously apropos.

Given the recent rash of status quo apologists who continue to cling to some bizarre notion that all I want to do is steal their girlfriends, call them names and separate them from their precious firewalls, I couldn’t help myself. 

Two outa three ain’t bad, I suppose.

I’ve got people putting together bitchin’ soundtracks in my honor and showing real concern that I’ve just gone off the deep end, pleading with me to revert to my prior ways before an intervention is required.

So what the hell…let’s have some fun with that concept.

In this scene, I imagine myself (I’ll be Tom Cruise) interrogating one of my firewall-fanboy antagonists (Nicholson) regarding the unnatural attachment to implementing technology rather than solving business problems right after a botched cover-up of (and if this isn’t serendipity…) a "Code Red"

Son, we live in a world that has firewalls, and those firewalls have to be configured by men with  policy editors, bad attitudes and an extensive knowledge of ACL’s.  Who’s gonna do it? You? You Lt. Weinburg?  I have more responsibility here than you could possibly fathom.

You weep for de-perimeterization, and you curse the firewall jockies. You have that luxury.  You have the luxury of not knowing what I know. That the perimeter’s much greatly exaggerated death, while tragic, probably saved my ass from not patching my servers.  And that my existence, while grotesque and incomprehensible to you, saves machines.

I know deep down in places you don’t talk about at parties, you don’t want me on that firewall, you need me on that firewall.

We use words like threat, vulnerability, budget. We use these words as the backbone of a life spent defending "something." You use them as a punchline.

I have neither the time nor the inclination to explain myself to a man who rises and sleeps under the blanket of the very security I provide, then question the manner in which I provide it.

I prefer you said thank you, and went on your way, Otherwise, I suggest you pick up an IPS and weed out false positives. Either way, I don’t give a damn what you call what I do!

That pretty much sums up the situation thus far, I’d say…

You can find the original dialog here.

/Hoff
(If even one of you takes this seriously, I’ll really put some effort into annoying you…)

The battle for Hypervisor supremacy is beginning to heat up.  While Geordi LaForge certainly had a primo "hypervisor" unrivaled by shade designers across the galaxy, let’s focus on the virtualization persuasion.  I promise, it’s equally as exciting…

Besides the more well known players in the virtualization space such as VMware, Citrix (nee XenSource,) Sun and Microsoft working diligently to differentiate and provide lighter weight and more secure hypervisors, I found the news regarding Phoenix Technology’s entry into the VMM wars quite interesting on several fronts.  Here’s what they have to say:

1. Phoenix will provide a very thin footprint hypervisor called HyperCore that sits on top of their SecureCore BIOS which will be loaded before any other OS.
2. HyperCore would naturally support the installation/execution of non-virtualized OS’s such as Vista, Linux, etc. running on top of it.
3. HyperCore provides a capability called HyperSpace which offers self-contained embedded operating systems/virtual machines which will allow users to dynamically switch between them and utilize them as isolated virtual appliances delivered in firmware.  The prospective HyperSpace applications include web browsing, messaging, management and encrypted data stores.
4. Phoenix has engaged with Joanna Rutkowska and her Invisible Things Lab to leverage her work done with her Blue Pill research which she is (now) describing as a very lightweight hypervisor (rather than a hypervisor rootkit) in order to deliver a more secure VMM.

I have yet to see the technical details regarding how VMware’s 3i product loads out of flash, but certainly Phoenix is on a head-on with VMware in this space given their BIOS implementation.

This is very interesting because Phoenix has great BIOS market penetration (about 50% of the overall market and 60% of the mobile x86 market) and is in a good position to offer desktop machines with a compelling option for secure application environments.  I mention desktops and not servers because the folks I’ve spoken to expect to utilize the VMM provided by their main virtualization infrastructure vendor for support, performance and reliability reasons.

I wonder how many more boutique VMM’s we will see popping up soon and driving innovation? 

Hypervisors today really represent an evolution in operating systems. In many respects, the virtualization capabilities they bring to the table really make Scott McNealy’s mantra of "the Network is the Computer" seem just that much more profound.  Everything’s virtualizing; applications, network, storage, policy, data, operating systems…

In fact, when I was at VMworld, I spent a considerable amount of time in the VMware and Cisco booths speaking with product managers and engineers about service composition, provisioning and deployment in the virtualized infrastructure and it became clear that the game was going to change in wholesale fashion very soon.

Chambers referenced the Datacenter OS in his keynote and described that we’ll shortly have a "fabric" which interconnects compute stacks, storage and networking which is managed by tools that allow for realtime dynamic infrastructure, including virtual machines.

You can bet that we’ll see build/buy/ally decisions being executed here soon enough as the virtualization players jock for positioning within this ultra hot segment.

I plan to follow up with another post on the topic of the Datacenter OS shortly, but it will be interesting to see where new players factor into the mix and how sustainable they are under the weight of companies like Cisco, VMware and Microsoft.

/Hoff

Pointy Things Can Hurt

Mom always told me not to run with scissors because she knew that ugly things might happen if I did.  I seem to have blocked this advice out of my psyche.  Running with scissors can be exhilarating.

My latest set of posts represent the equivalent of blogging with scissors, it seems. 

Sadly, sometimes one of the only ways to get people to
intelligently engage in contentious discourse on a critical element of our
profession is to bait them into a game of definitional semantics;
basically pushing buttons and debating nuance to finally arrive at the
destination of an "AHA! moment."

Either that, or I just suck at making a point and have to go through all the machinations to arrive at consensus.  I’m the first to admit that I often times find myself misunderstood, but I’ve come to take this with a grain of salt and try to learn from my mistakes.

I don’t conspire to be tricky or otherwise employ cunning or guile to goad people with the goal of somehow making them look foolish, but rather have discussions that need to be had.  You’ll just have to take my word on that.  Or not.

You Say Potato, I say Po-ta-toe…

There are a number of you smart cookies who have been reading my posts on Information Survivability and have asked a set of very similar questions that are really insightful and provoke exactly the sort of discussion I had hoped for.

Interestingly, folks continue to argue definitional semantics without realizing that we’re mostly saying the same thing.  Most of you bristling really aren’t pushing back on the functional aspects of Information Security vs. Information Survivability.  Rather, it seems that you’ve become mired in the selection of words rather than the meme.

What do I mean?  Folks are spending far too much time debating which verb/noun to use to describe what we do and we’re talking past each other.  Granted, a lot of this is my fault for the way I choose to stage the debate and given this medium, it’s hard to sometimes re-focus the conversation because it becomes so fragmented.

Rich Mogull posted a great set of commentary on this titled "Information Security vs. Information Survivability: Retaking Our Vocabulary." wherein he eloquently rounds this out:

The problem is that we’ve lost control of our own vocabulary.
“Information security” as a term has come to define merely a fraction
of its intended scope.

Thus we have to use terms like security risk management and
information survivability to re-define ourselves, despite having a
completely suitable term available to us. It’s like the battle between
the words “hacker” and “cracker”. We’ve lost that fight with
“information security”, and thus need to use new language to advance
the discussion of our field.

When Chris, myself, and others talk about “information
survivability” or whatever other terms we’ll come up with, it’s not
because we’re trying to redefine our practice or industry, it’s because
we’re trying to bring security back to its core principles. Since we’ve
lost control of the vocabulary we should be using, we need to introduce
a new vocabulary just to get people thinking differently.

As usual, Rich follows up and tries to smooth this all out.  I’m really glad he did because the commentary that followed showed exactly the behavior I am referring to in two parts.  This was from a comment left on Rich’s post.  It’s not meant to single out the author but is awkwardly profound in its relevance:

[1] This is the crux of the biscuit. Thanks for saying this. I don’t
like the word “survivability” for the pessimistic connotations it has,
as you pointed out. I also think it’s a subset of information security,
not the other way around.

I can’t possibly fathom how one would suggest that Survivability, which encompasses risk management, resilience and classical CIA assurance with an overarching shift in business-integrated perspective, can be thought of as a subset of a narrow, technically-focused practice like that which Information Security has become.  There’s not much I can say more than I already have on this topic.

[2] Now, if you wanted to go up a level to *information management*,
where you were concerned not only with getting the data to where it
needs to be at the right time, but also with getting *enough* data, and
the *right* data, then I would buy that as a superset of information
security. Information management also includes the practices of
retaining the right information for as long as it’s needed and no
longer, and reducing duplication of information. It includes deciding
which information to release and which to keep private. It includes a
whole lot more than just security.

Um, that’s what Information Survivability *is.*  That’s not what Information Security has become, however, as the author clearly points out.  This is like some sort of weird passive-aggressive recursion.

So what this really means is that people are really not disagreeing that the functional definition of Information Security is outmoded, but they just don’t like the term survivability.  Fine! Call it what you will: Information Resilience, Information Management, Information Assurance, but here’s why:
you can’t call it Information Security (from Lance’s comment here):

It seems like the focus here is less on technology, and more on process
and risk management. How is this approach from ISO 27000, or any other
ISMS? You use the word survivability instead of business process,
however other then that it seems more similar then different.

That’s right.  It’s not a technology-only focus.  Survivability (or whatever you’d like to call it) focuses on integrating risk assessment and risk management concepts with business blueprinting/business process modeling and applying just the right amount of Information Security where, when and how needed to align to the risk tolerance (I dare not say "appetite") of the business.

In a "scientific" taste test, 7/10 information security programs are focused on compliance and managing threats and vulnerabilities.  They don’t holistically integrate and manage risk.  They deploy a bunch of boxes using a cost-model that absolutely sucks donkey…  See Gunnar’s posts on the matter.

There are more similarities than differences in many cases, but the reality is that most people today in our profession completely abuse the use of the term "risk."  Not intentionally, mind you, but due to the same reason Information Security has been bastardized and spread liberally like some great mitigation marmalade across the toasty canvas of our profession. 

The short of this is that you can playfully toy with putting lipstick on a pig (which I did for argument’s sake) and call what you do anything you like.

However, unless what you do, regardless of what you call it and no matter how much "difference" you seem to think you make, isn’t in alignment with the strategic initiatives of the company, your function over time becomes irrelevant.  Or at least a giant speedbump.

Time for Jiu Jitsu practice!  With Scissors!

/Hoff

A day or so ago, I was reflecting on one of Gunnar Peterson’s posts regarding Information Security spending and the lack of transparency and measurement therein.  His post referred to a set of five questions that Dan Geer suggested (rightly) ought to be answered by anyone managing security efforts or defending a security budget:

Awhile back, Dan Geer posed the following questions

How secure am I?

Am I better than this time last year?

Am I spending the right amount of $$?

How do I compare to my peers?

What risk transfer options do I have?

Dan asserted, and I agree, that these are perfectly reasonable for
senior management to ask, virtually any part of a business can provide
some enlightenment on them, and the exception is infosec which has
virtually no way to answer any of these today.

A few moments ago, Richard Bejtlich over at the TaoSecurity blog posted a fantastic substitute/extension to question number one above "How secure am I?" by asking "Are you Secure?"  Richard goes one step further and suggests that you prove it.

Richard sets up the scenario by establishing the ground rules:

Are you secure?  Prove it.  These five words form the core of my recent thinking on the digital security scene.  Let me expand "secure" to mean the definition I provided in my first book: Security is the process of maintaining an acceptable level of perceived risk.  I defined risk as the probability of suffering harm or loss.  You could expand my five word question into are you operating a process that maintains an acceptable level of perceived risk?

<snip>

For the purpose of this exercise let’s assume it is possible
to answer "yes" to this question. In other words, we just don’t answer
"no." We could all make arguments as to why it’s impossible to be
secure, but does that really mean there is no acceptable level of
perceived risk in which you could operate? I doubt it.

He does a fantastic job of suggesting how you might want to approach answering that question.

Read it, it’s fantastic.

/Hoff

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

From the "Tooting Your Own Horn" Department…

The lovely folks at SixApart – purveyors of the fine SaaS/Hosting functionality "TypePad" (amongst others) have kindly named the blog of your’s truly as today’s "TypePad Featured Blog."

So, out of the approximately 1.2 Million blogs claimed as being hosted by SixApart, I seem to have offended enough of you and consumed enough bandwidth to warrant attention.  I’m praying I won’t receive an email politely suggesting that I upgrade…

So, I’d like to start by thanking all the people who make this blog possible…Ummmm…

OK, so moving on, I’d like to thank all of you who read my little steaming pile of blogginess…last count has approximately 2,000 subscribers, although I believe my kids run 100 simultaneous instances of Google Reader under fake names in exchange for WebKinz and iTunes credits that I upload when they generate page views.

Seriously, though…blogging is a lot of fun.  I love blogging my ideas and interacting with the lot of you.  Even Rothman.  No, especially Rothman.  The only man I respect for wearing Crocs with socks in Vegas in 100 degree heat.  Black, of course.

I’ve learned quite a few interesting lessons since I started   blogging over a year ago (thanks to Alan Shimel who encouraged me to do so) and look forward to learning a lot more.  One of things I’m going to force myself to do is write less — less words, that is.  You people have the attention spans of gnats in heat, so I’m going to make it more A.D.D. friendly.  Besides, when I leave big logic holes due to less words, you seem to participate more.

I’ve already told my wife I need an iPhone to make sure the blog renders correctly under Safari running on a mobile.

Now that I’m Blog King for a day (and Alex Hutton has one) she couldn’t possibly turn me down, right?

/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

Gunnar Peterson’s been on a tear lately regarding how security spending is out of control and out of alignment with the business. 

He wrote about it here in a post titled "Network Security Budget Cruft – Why you are probably spending waaayyy to much on network security" and this morning pointed us to an interview he gave on the same topic with ITBusinessEdge.

Here’s the Reader’s Digest version:

Question: Is the realignment important?

Peterson: I think it is a big deal. I really think IT security is out
of control; in many cases, they are spending $10 to protect something
worth $5, and in other cases they are spending a nickel to protect
something worth $1,000. If you look at the numbers objectively, you see
why it is out of control, and you can use the investing habits of the
business to improve the situation

Coincidentally, I am giving the keynote at this year’s Information Security Decisions show in Chicago on November 5th and will be discussing about how "Security" needs to embrace disruptive technology and innovation. 

One of the most important facets of this presentation is how security managers must build and manage a strategic security portfolio with investments made over time that align to the business; if you can’t demonstrate how what you do supports the strategic initiatives of the company, you’re in a bad place.  The business innovates driven by the need to corner competitive advantage.  Security needs to do the same:

Question: How do you start building a case to confront the issue?
Peterson: You
take the budget and prove it in numbers. When you look at how the
business invests and see how security invests, many times it is the
opposite. You have to ask questions about that. It’s not a one-to-one
match. That should be the starting point, and if you want to invest
more in other areas, the burden is on you to prove [it is justified].

As Gunnar alludes, if it were easy we’d be there already and it’s really important to understand that when we talk about these things it should be understood that it’s not going to happen overnight:

Question: These spending habits must be pretty deeply engrained. It must be a big challenge to turn it around.
Peterson: It
is going to be hard to change some of these things overnight. The
company has licenses, legacy investments. I would look to where the gap
is coming from. When you look to resolve this, I think investing in
training and awareness can go a long way. It can’t completely solve the
problem, but can help by [for instance] showing them how to write more
secure code, training database administrators to configure their
databases more securely. Doing that is not a huge investment, but
ultimately having people helping to bridge the gaps is a huge advantage.

I think Gunnar’s topic goes hand-in-hand with the discussions we’ve been having lately regarding the misalignment and missing language used to describe what we do.  IT security is one of the only crafts I’ve seen where transparency and accountability for spend and alignment are represented as being too difficult and allusive to demonstrate.  From Gunnar’s initial post:

Awhile back, Dan Geer posed the following questions

How secure am I?

Am I better than this time last year?

Am I spending the right amount of $$?

How do I compare to my peers?

What risk transfer options do I have?

Dan asserted, and I agree, that these are perfectly reasonable for
senior management to ask, virtually any part of a business can provide
some enlightenment on them, and the exception is infosec which has
virtually no way to answer any of these today.

These questions are not only reasonable but required.  If you can’t answer them — and articulately defend your assertions, then you’re most certainly engaged in the practice of the bastardized and neutered ugly stepchild version of "Information Security" that our industry has become.

"I don’t know," "I guess so" and "we use a firewall and SSL" aren’t professionally-accepted answers in most career paths to these questions, why are they in ours?

Thanks for the great read, Gunnar.

/Hoff

*** Update: In a freaky bit of coincidence, Alex Hutton was remarking on a comment I made on Shrdlu’s Layer8 blog regarding security investments and pointed to Gunnar’s post also.  Alex’s questions are really good…

t’s Freaky Friday.  I’m not inspired to crank out a poem.  Instead, courtesy of BoingBoing, I found this fascinating example of applied cryptography (my apologies, Bruce)…an Internet-enabled Chastity Belt featuring encryption and distributed key management:

From the Italian site promoting this abberation of science:

"The site timelock.rules.it (NoScript didn’t like this site — use at your own risk)
has a program [Timelock, $20] that allows someone to use encryption to
lock themselves up for a set or random amount of time, or even to send
the key to their chastity belt over the internet to a trusted keyholder."

The keyholder has set the Hide Timer option so you have no idea how
much time has been set. You feel the fear and the anxiety, but, with
trembling fingers, you close the lock. Your fate is now entirely in the
hands of your keyholder. Only they know how much time has been set.
Only they know the lockword, which may grant you early release. The
need to touch yourself is already overwhelming but there is nothing you
can do about it. All is as it should be.

Oh my. 

I believe Amrit Williams
beta-tested this and reverse engineered the firmware via JTAG,
connecting it to the ‘Net using SCADA along with visualization and
"input" interfaces thanks to a set of VR goggles, a nintendo power
glove and a Novation AppleCat 300 baud modem that auto-dials "Uncle
Percy’s House of Pain and Panna Cotta"  sending DTMF tones that spell
"STICKY" in morse code.

Maynor notified me that he’d also verified a wireless vulnerability
exists in the software, despite the fact that it has no wireless
interface.  He ordered one, anyway.

I guess I was wrong about how Information Security is dead.  I should have said it’s just become a perverted (yet cryptographically secure) version of itself.

Ten bucks says they use the "Blowfish" algorithm (sorry again, Bruce.) 😉

/Hoff