Rational Survivability

Too Much Risk Management? Not Possible

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

You Want the Truth? You Can't Handle the Truth...

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 the HyperVisor Heats Up...

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

Running With Scissors...Security, Survivability, Management, Resilience...Whatever!

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

I Can Has Cheezburger & R U Secure?

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

Why Security Should Embrace Disruptive Innovation -- and Become Innovative In the Process

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

Pimp My Blog: TypePad Says "Rational Security Is the Schizzle, Yo!"

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

A Primer on Information Survivability: Changing Your Perspective On Information Security

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

Companies Must Update Thinking About Security Spending

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

Finally...A Good Use for Encryption Trading Computational Haste for Being Chaste...

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

Version 1.0 of the CIS Benchmark for VMware ESX Server Available

Version 1.0 of the Center for Internet Security (CIS) benchmark for securing VMware ESX server is available.  This is specific to version 3.x of ESX and covers the basic best practices of preparing an ESX server for deployment.

We've still got a ton of stuff that didn't make the deadline cut-off for the first version of the document in follow-on iterations, but it's a good start.  Please sign up if you can contribute to making this document even better.

You can find it here.

/Hoff

Information Security: Deader Than a Door Nail. Information Survivability's My Game.

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

Apathy and Alchemy: When Good Enough Security is Good Enough

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Timing is everything.

/Hoff

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/Hoff

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Think different.

/Hoff

BeanSec! Wednesday, October 17th - 6PM to ?

Yo!  BeanSec! is once again upon us.  Wednesday, October 17th, 2007.

BeanSec! is an informal meetup of information security professionals, researchers and academics in the Greater Boston area that meets the third Wednesday of each month. 

I say again, BeanSec! is hosted the third Wednesday of every month.  Add it to your calendar.

Come get your grub on.  Lots of good people show up.  Really.

Unlike other meetings, you will not be expected to pay dues, “join up”, present a zero-day exploit, or defend your dissertation to attend. Map to the Enormous Room in Cambridge.

Enormous Room: 567 Mass Ave, Cambridge 02139.  Look for the Elephant on the left door next to the Central Kitchen entrance.  Come upstairs. We sit on the left hand side...

Don't worry about being "late" because most people just show up when they can.  6:30 is a good time to aim for.  We'll try and save you a seat.  There is a parking garage across the street and 1 block down or you can try the streets (or take the T)

In case you're wondering, we're getting about 30-40 people on average per BeanSec!  Weld, 0Day and I have been at this for just over a year and without actually *doing* anything, it's turned out swell.

We've had some really interesting people of note attend lately (I'm not going to tell you who...you'll just have to come and find out.)  At around 9:00pm or so, the DJ shows up...as do the rather nice looking people from the Cambridge area, so if that's your scene, you can geek out first and then get your thang on.

The food selection is basically high-end finger-food appetizers and the drinks are really good; an attentive staff and eclectic clientèle make the joint fun for people watching.  I'll generally annoy you into participating somehow, even if it's just fetching napkins. ;)

See you there.

/Hoff

Security is NOT the Primary Limiting Factor Inhibiting SOA's Growth

Peter Schoof over at eBizQ's Twenty-Four Seven Security makes a couple of very interesting assertions regarding the lack of growth of Service Oriented Architecture (SOA.) 

I haven't seen much discussion in the blogosphere about the security challenges that arise from loosely coupled service orientated systems, but that will soon change. As more and more companies move towards open applications ala SOA, data is also opened up to a whole new series of exploits and vulnerabilities.

I will agree that SOA provides some very interesting security challenges that, much like many emerging technologies, are attempted at being solved by having security bolted on instead of baked in.    I'd also agree that SOA will manifest new attack surfaces and potential vulnerabilities; it already has. 

Interestingly, the market for SOA security solutions came out of the gate strong, looked hot in the midst of consolidation and M&A madness, but then stumbled as the adoption of SOA (or specifically SOA security) did not support this nascent market kindly.  It has, in fact, become a feature, not a market. 

As to there not being much discussion in the blogosphere surrounding SOA, perhaps Peter missed Gunnar Peterson, Lori MacVittie, Arnon Rotem-Gal-Oz, or even Me.  Obviously Joe McKendrick has been blogging about SOA and security for some time also since he's the person moderating the webinar that Peter is referring to in his full post.

At this point, security is the primary limiting factor inhibiting SOA's growth. In order to counteract that, "Enterprises need to apply non-invasive, externalized security policy enforcement mechanisms consistently throughout their SOA ecosystems, while also centrally managing security policy."

<Cough!> Um, no.  Firstly, please shoot the marketing drone that wrote that.

Secondly, and most important, the primary limiting factor inhibiting SOA's growth is gross sum of: the definition of SOA, the state (mess) of Enterprise Architecture, operationalizing SOA and message buses, the business case, business value, complexity, and the cost center.  Security's in there somewhere, but it's far from being THE primary limiting factor, Peter.

I'm all for trying to raise the flag regarding SOA and the need for security, but please don't play pin the tail on the donkey with security as the Ass...you're only going to look like one.

/Hoff

Everybody Wing Chun Tonight & "ISPs Providing Defense By Engaging In Offensive Computing" For $100, Alex.

You say "defense" I say "offense."  I know the argument's coming, but it's just a matter of perspective.  What am I talking about?  ISPs ultimately going on the "offense" to provide a defense to protect their transport networks customers from the ravages of bots, worms and viri.

Let's look at the latest spin on how services which are represented as protecting customers are really meant to transfer accountability and can potentially punish subscribers by addressing the symptoms instead of fixing the problem. 

Saving money operationally across a huge network makes for a better P&L.  It goes back to my posting on some of the economics of Clean Pipes here.

I'm guessing I won't be getting a Qwest service discount any time soon after this...

Qwest's announcement regarding their "Customer Internet Protection Program" in which they will "help a customer remediate an infected machine connected to it's network" can be perceived in one of two ways.  I'm a cynic, but to be fair let me first present Qwest's view:

The Qwest^(R) Customer Internet Protection Program (CIPP) notifies Qwest Broadband customers about viruses and malware that may be on their computers, informs them of safe Internet security practices and helps them clean viruses and malware from their computers. The CIPP is part of Qwest's ongoing commitment to make the Internet safer for customers and is available to residential and small-business Qwest Broadband ADSL* customers at no additional charge.

That's a nice concept and is meant to give us the warm and fuzzies that Qwest "cares."  I would agree that on the surface, this sounds terrific and Qwest is doing the "right thing."  Now we just need to explore what the "right reason" might be for this generous outreach.

Given the example above, the client machines are only actually "protected" and "more secure" once they have been discovered to be infected.  Now, this means that either they became infected whilst connected to Qwest's "secure" network (thus bypassing all that heady protection levied by their network defenses) or during some out of band event.  More on that in a minute.

Here's some additional color from Qwest:

The proliferation of cyber crime continues to require individuals, businesses and even government agencies to take action against ever-changing methods of attack. Because viruses and malware can cause problems not only for individual Qwest Broadband customers, but also for the online community, Qwest proactively monitors its network to detect viruses or malware. When one of these is discovered, the Qwest Customer Internet Protection Program notifies the specific customer of the infection; gives the customer information on how to remove the infection; educates the customer on good Internet security practices; and provides the customer with additional resources, including downloadable or online anti-virus software.

The Qwest CIPP only acts on malicious network traffic on the public Internet; the program does not scan or otherwise monitor content on customers' computers.

Again, that sounds nice, but let's back up a second because there's something missing here.  What happens when they can't remediate an infection and a zombie continues to spew crap across the network?  What happens if I'm running a BSD, Linux or Mac and not Windows?  What then?  Geek Squad in black helicopters?

Larry Seltzer gives us an idea in his write-up:

What Qwest is doing is something like NAC for ISP clients, however there are a lot of differences, so I don't want to take that analogy too far. The system actively monitors clients for behaviors characteristic of malware; spamming, for example. When it determines that the system meets its profile, it takes action.

The monitoring is entirely at the network level. No software is installed on any PC, nor are there any active probes of them. SMTP and HTTP are blocked; other services like POP3 and VOIP are unaffected. Attempts to send e-mail, legitimately or not, will fail. This is something like the "walled garden" idea of NAC implementations where the user is isolated from the rest of the network and expected to spend their time cleaning up the system.

The next time the user attempts to connect to the Web they are presented with a special page that warns of a possible "virus" on the computer. (Their use of the word virus on this page is technically off, but they're trying to be colloquial and accessible, not strict-geek.) The page says that malicious traffic has been monitored coming from this computer or another on the same account; they can't know which computer behind your router is the dirty one.

The page gives you three options: remove the virus now, remove it later, or assert that you have already removed it. In the first case, they enter a removal process, the details of which I don't have, but it could be something like Trend Micro's HouseCall.

In the second case you are allowed to connect even though your system is infected, but you will be given the same warning again soon, and after a few times you won't have the "later" option anymore. In the third case, I presume they let you back on the Internet and monitor you once again.

In the second case, where they actually block out users who refuse to clean up their systems, we've got big news. Will they really shut off customers? Anecdotal evidence will come out of course, but we won't know how many times they really had to do this unless Qwest volunteers the numbers.

Wowie!  That last paragraph presents a doosie of a case.  You mean you're going to prevent me from accessing the network I am paying to use when I'm not knowingly engaging in malicious activity (I'm stupid and got infected, remember?)  I don't really care about the mechanism for doing so, but this is offensive in multiple meanings of the word.

Oh, but wait.  The security remediation "service" Qwest is generously donating to their subscribers is free (as in beer) and there's no guarantees, right?  Actually, there are.  They guarantee, based upon their terms of service, to remove you from service whenever and however they see fit.

If you look at the vagaries of Qwest's Broadband Subscriber Agreement, you might have a hard time recognizing the rainbows and unicorns from the realities of what they "could" do should your machine, say, start transmitting SPAM on their network because you're infected. 

It doesn't matter why you're doing it, because if you are, you've already agreed to them charging you $5 per spam message in the TOS!  It's in there.  Don't believe me?  Read it yourself in the AUP section.

What this really means to me is because ISPs can't stop the infection across their network, can't stop the true source of the infection in the first place, and are having to bear the brunt of the transport and security costs to alleviate financial strain due to operational impacts on their networks, they're going to penalize the users.  Why?  because they can.

"But Hoff," you say, "you're overreacting to a gracious and no-cost way to make Internet denizens more secure!  You've got this all wrong!"

I'm sure that for every 1 user they can't remediate they'll be 5 more that think this is terrific.  Until they get nuked off the network a-la option #2 in Larry's write-up above, that is.  Qwest maintains all is well in Mayberry:

Qwest Broadband customers have responded positively to the CIPP. In fact, since the program began, more than three-quarters of infected customers who were surveyed said they appreciated the CIPP and Qwest's efforts to help them get rid of viruses and malware on their computers.

I wonder what happened to the other 25%.  This is why Enterprise NAC deployments often have the potential to suck donkey balls (that is a technical term relating to the spherical multidimensional paradoxes faced by the burros who bear the brunt of operationalizing security technology.)  All's well and good until someone important, like the CEO, can't get on the network.  Flexible quarantine that like that above, you say?  Sort of defeats the purpose, doesn't it?

Here is where the fluff falls away and we have to come to grips to how ISP's are "combating" the waves of attacks which are overwhelming their "defenses."   This is when we have to start talking about what it means to truly defend networks. 

I reckon it means that we're going to see the very subtle uptake of "offensive" measures to provide "defensive" capabilities in  many different forms.  I don't know many wars that were "won" on defense alone.  I'm not a military historian, so can someone help me out here?

I'm sure Bejtlich can give you some cool martial arts fu analogy, so I'll beat him to the punch (ha!) and offer up the fact that you need what Wing Chun Fu offers as a tenet of the art:

Wing Chun Kung Fu assumes that an opponent will be bigger and stronger than you. Therefore, WC emphasizes fast and strong structure over physical strength and speed and simultaneous attack and defense.

Wing Chun focuses on combining a defensive movement with an offensive movement, or using offensive techniques that provide defense.  In this way, WC is structurally faster that those styles that teach one to defend first, then attack.

So it's clear to me that we need offense paired with defense, described transparently and with expectations set as to what pushing the "launch" button might mean.  Again, what was the customer satisfaction of the remaining 25% who had this feature applied to them when Qwest prevented them accessing the Internet?

People don't like talking about this within the context of networks because the notion of "ethics" and "collateral damage" bubble up.   Look, it's happening anyway.  We're pretty much screwed at the moment.  And you, dear broadband Internet user, are paying for the privilege of being bent over.

You go ahead and define DoS anyway you see fit, but when an ISP turns on the customer because they can't combat the true attacker, I smell a rat because for what appears to be economic reasons, they can't really be honest about what they're doing and what they'd really like to do in order to defend "their" network.

Get ready for more offense(s.)

That's my $0.02 ($5 if I sent this from Qwest's network) and I'm stickin' to it.

/Hoff

Loose Lips Sink Ships But They Also Float Boats...

I'm going to play devil's advocate again as I ponder a point.  Roll with me here.  I'm slightly conflicted.

Jeff Hayes blogged about an interesting encounter in a sports bar he had with the head of physical security for an international accounting firm.  It turns out that as part of a casusal conversation, this person disclosed some very interesting facts about his company's security:

It turns out this guy handles physical security for a major international accounting firm. He travels around North America doing premises and access control assessments and deployments. He described to me, without me asking specific questions, the technology they use, the problems they deal with including the push-back they get from each office complaining about burdensome security, their budgets, his working environment, how he moved up the company ladder and his qualifications or lack thereof, and a number of other tidbits that would prove valuable to anyone doing surveillance.

It would appear that this guy had one too many and the apparent level of detail disclosed seems excessive.  Jeff's point about confidence and accelerated reconnaissance for targeted profiling seem to be quite relevant in this scenario.  This person was being reckless and was potentially endangering his company.

However, let's look at this a little differently to illustrate a counterpoint.

This encounter sounds like what many of us read and talk about under the guise of non-attribution at many of the security forums and "professional" security gatherings we attend and participate in with our "peers."  You know the ones where we all sit around, hoping that the badges actually represent the fact that the organizers have appropriately vetted and authenticated that the person wearing it is who they say they are...

Moreover, it sounds a lot like the conversations at the bar after said forum roundtables.  We share our collective experiences in order to gain insight and intelligence so we can improve our security posture, accelerate our intelligence on short-listing vendors and not make mistakes by learning from others.

How about those Visio diagrams you show on the whiteboard to VARs when they send their SE's in for work and pitches?

It gets even more interesting when you have CISO's/CSO's (like I do) talk to the press and do case studies describing technologies and solutions deployed.  Some CISO's don't mind doing so after making a tactical risk-based decision that what they reveal does not expose the company adversely.  Others simply don't talk at all about what they do.

I understand there exists the potential that by disclosing that you use vendor ABC or technology XYZ that someone could exploit that knowledge for malignant purposes.  I suppose this is where the fuzzy area (I'm sorry Mr. Hutton!) of thin-slicing and quickly assessing risk comes into play.   What is the likelihood that this information when combined with a vulnerability (in policy, architecture, deployment) in the presence of a threat might become a risk to my company?

I use Check Point NGX R65.  I run it on a Crossbeam X-Series.  It filters a bunch of packets.  I use Cisco routers.  Is that information you couldn't have found out with a network scan, fingerprinting and enumeration?  Have I made your job of attacking me orders of magnitude easier?

Ah, the slippery slope is claiming me as a victim...

Have you seen the Military Channel?  I watched several fantastic Navy/Marine-sponsored documentaries on Carriers, NextGen APC's, new weapons systems...all of which are deployed.  Is Al Qaeda now in a more advantageous position because they know how the de-desalinization plant on a fast frigate functions?

Everyone in a company is both a sales and marketing rep as well as a potential security breach waiting to happen. Most businesses like people to present their company in a good light. We want people to know that we work for a good employer. What we don’t want people to do is to tell others how crappy our employer is. Likewise, we probably don’t want our security personnel describing the details of our security systems, policies and procedures.

So Jeff's right, but I guess that depends upon the level of "details" he's referring to?  Is Jeff's point still valid when we're talking about a breakfast conversation at an Infragard meeting?  How about the forums over at SecurityCatalyst.com?  There's that level of trust and judgment factor again.  How about an ISAC gathering?  Aren't we all supposed to share knowledge so we can help one another? 

Where do we draw the line as to who gets to say what and to whom?  Those policies either have to get really fuzzy or very, very black and white...which goes to Jeff's point:

Loose lips have been known to sink ships; they can also hurt organizations.

Yes they have.  They've also been known, when appropriately pliable with a modicum of restraint, to float the boat of someone whose time, energy and budget you've been able to save by sharing relevant experience.  Let's be careful not to throw the baby out with the bilge water.

So, how do you establish "trust" and assess risk before you talk about your experience with technology you've deployed or are thinking about deploying?  What about policies and procedures?  How about lessons learned?

Obviously anybody who answers is not a true "security guy" ;)

/Hoff