Archive for September, 2009

Security Decisions – How do you make them?

Monday, September 28th, 2009
As a student of both the fields of Information Technology/Security and Management Science (http://en.wikipedia.org/wiki/Management_science), I often find myself looking at security issues through a “decision-oriented” lens. For the most part, these two disciplines make good bedfellows – especially when one considers that engineers dominate the Information Security field. Please don’t misinterpret this; I have a healthy respect for and advocate our need of engineers (I’ve even helped teach and graduate some of them). However, not all of our problems are engineering problems and I do believe that our ability to truly manage information risk is hindered by a shortage of input from other disciplines (though I’ve seen at least some improvement in recent years).
One area where the engineering and management mindset clash is in decision-making. The engineer asks “What do I need to know to precisely formulate all factors in this decision?” while the management scientist asks “What do I need to know to make a good decision?”. In such matters, I side heavily with the management scientist.
The obvious application of this is in evaluating potential security initiatives or projects (“Should we do X, Y, or Z?”). In most cases, it is impossible to precisely formulate all factors in the decision, so we abandon the “scientific” route and revert to some other method of making it (see below). This is where our predominantly engineering mindset hurts us. Instead, we should realize that organizations have always made decisions using varying amounts of information of varying quality. Our dilemma is not new. Valid and vetted approaches exist for structured decision problems with an abundance of precise data and also for unstructured problems with sparse amounts of “fuzzy” data. They are out there and eagerly waiting for us to apply them to problems in our domain.
Ok, I’m off the soapbox. The main goal of this post is to ask how your company makes “Should we do X, Y, or Z?” decisions. I’ll start the conversation by listing the methods I see used most often. In doing so, I make no judgment on any method’s ability to support good decisions (though it’s clear some have more value than others).
• The “Adamant Auditor” method: You’ve been here. The 22 year old kid shows up 3 months out of the university with his checklist etched in stone. He darn well better be able to check off all those boxes or you’re toast. “But if X does Z and Y does Z, then X=Y… and we’ve done Y” you argue only to receive blank stares. Good luck with that. Unless you can build a credible risk-based argument, you might as well just do X like he says.
• The “Peer Pressure” method: This is the grown-up equivalent to doing what the cool kids do “Peers X and Y are doing Z, so we should too” is the justification here. It might be that X and Y have their act together and are great role models. Then again, they might think that alcohol, blindfolds, and a game of high-speed Chicken make for a great Friday night. Remember what your Mama said – “If so and so jumped off a cliff, would you?”
• The “WIBeHI” method: If you’ve ever used anything that sounds remotely like “Wouldn’t It Be Horrible If X happened, therefore we should do Y” to justify a security initiative, then you’ve used this method. The potential worst-case scenario (and often some extra FUD for good measure) is the main decision criterion in this approach.
• The “Guru Guidance” method: Every organization has its guru and every guru has his opinion. Just ask him. It might be that nobody understands the technical justification behind what they’re recommending, but he knows his stuff, right? Right?
• The “Poll the Panel” method: Often called the “Delphi Method” but I’ve never thought the name very fitting. No journey to a mystical oracle with secret knowledge is required; you simply gather your smart folks and get them to come to a decision. The assumption is that decisions made by many are better than decisions made by one.
• The “Pet Project” method: Perhaps it was the advertisement in that magazine on the plane. Maybe that analyst report. Who knows why your boss wants that project so badly, but its clear she does. And in this job market, who’s going to argue? If you can get it done while also squeezing in something with actual benefit, there’s a chance you can still put a mark in the Win column.
My tone here is obviously facetious but I am quite serious that I believe these methods (or some form of them) account for the majority of security decisions made in most organizations. Is this your experience as well? We’ve put up a quick, one-question poll on the topic here and would love to hear from you (we’ll share the results later). If any of these methods resonate or if you have some to add, please chime in.

As a student of both the fields of Information Technology/Security and Management Science, I often find myself looking at security issues through a “decision-oriented” lens. For the most part, these two disciplines make good bedfellows – especially when one considers that engineers dominate the Information Security field. Please don’t misinterpret this; I have a healthy respect for, and advocate our need of, engineers (I’ve even helped teach and graduate some of them). However, not all of our problems are engineering problems and I do believe that our ability to truly manage information risk is hindered by a shortage of input from other disciplines (though I’ve seen at least some improvement in recent years).

One area where the engineering and management mindset clash is in decision-making. The engineer asks, “What do I need to know to precisely formulate all factors in this decision?” Meanwhile, the management scientist asks “What do I need to know to make a good decision?” In such matters, I side heavily with the management scientist. (more…)

Tags: , ,
Posted in Analysis | 6 Comments »

Re-imagining Information Security Standards

Tuesday, September 22nd, 2009

Hollywood calls it “Re-imagining”.  The creative types call it “rebooting”.  We might settle for “re-thinking”. But since it seems to be all the rage these days to take a second look at a subject, I thought I’d apply the concept to one of our favorite topics, Information Security Standards.

RE-IMAGINING INFORMATION SECURITY STANDARDS
Hollywood calls it “Re-imagining”.  The creative types call it “rebooting”.  We might settle for “re-thinking”.  But since it seems to be all the rage these days to take a second look at a subject, I thought I’d apply the concept to one of our favorite topics, Information Security Standards.
I admit that this is an incomplete thought, but I’d like to share it with you for two reasons:
1.)  At the end of a podcast I was part of recently, one of the other panelists challenged our industry to stop whining about our current state of affairs and do something better.
2.)  To request your feedback on the idea.
So here’s my thought: if we’re going to re-imagine InfoSec standards, as if we could do it all over again, I think there are three basic requirements any standard needs in order to be useful at all:
1.) A standard must provide for its own obsolescence/evolution  (falsification and a transparent falsification process must be built in)
2.) A standard must provide means of measurement (both for the outcome of the standard, and to measure the quality of standard adherence)
3.) A standard must reference, and be able to be referenced in, vernacular and in measurement (the language of the standard has to make sense to other standards)
RE-IMAGINING INFOSEC STANDARDS: THEIR NATURE
Digging right in, if we want to re-imagine standards we might start by reviewing the fundamental nature of what a standard is.  In a very real sense, our standards are models.  As such, any standard is only a hypothesis about how to keep our information confidential and available while maintaining its integrity.  But if we’re going to (finally) acknowledge that InfoSec standards are models/hypotheses, then we need to embrace a fundamental premise behind scientific theory: a model or hypothesis is meant to be tested, falsified, and evolved.  As such, our new view of InfoSec standards would require that we keep whoever developed the standard (or its current custodian), accountable for that scientific method.
Science Requires Falsification and Innovation
Now ideally, we’d have two things built into the concept of accountability.  These two ideas would mean that the standard would provide for its own obsolescence or evolution, and are the premise behind my first usefulness requirement, “a standard must provide for it’s own obsolescence/evolution  (falsification and a transparent falsification process must be built-in).”
1.)  The InfoSec standard itself should have a falsification process built into them.  The standard might describe the pursuit of falsification, what falsification/failures for the standard might look like, and provide us with the means to report a probable failure.
2.)  The standard custodian should provide transparency and reporting about that falsification process. Practitioners would have up to date knowledge about failures so that they can keep an eye out for them in their own environment, and hopefully be able to offer a modification to or alteration of the standard based on new information.  So whether this is just “patching” the standard or if it leads to a whole new hypothesis, we (the InfoSec community) would at least have visibility into a need to “re-secure”.
RE-IMAGINING INFOSEC STANDARDS:  THEIR PURPOSES
Related to our examination of fundamental nature, let’s think about what InfoSec standards are a model *of*.  We said that they are models we build to help us with our quest for maintaining the C, I, and A of our business data.  In that regard, we might suggest that they are about Information Security “engineering” and management.  In other words, design and implement practices to ensure C, I, and A and then establish practices to maintain the desired level of C, I, and A.  But if you’re building a control framework or understanding how you should best operate it, both disciplines require the use of measurements. This then necessitates the development, use, and reporting of metrics (indeed, the concept of measurement would be very useful in the scientific method process above).
The Purpose of Standards Requires Measurement
So while we’re re-imagining InfoSec standards, let’s imagine this: standards that tell us not only how to measure the standard’s outcome (secure enough) in a state of nature assessment, but also how to measure the actions that cause “secure enough” – what we might call the quality of standard adherence.  This gives us my second standards usefulness requirement,  “a standard must provide means of measurement (both for the outcome of the standard, and to measure the quality of standard adherence)”.
This way (and only in this way) we might know that by having expended X amount of effort for compliance to the InfoSec Standard, it produced Y amount of outcome.  Then people who implement the standard can discuss how they got Y+n amount of outcome for X-z amount of effort thanks to some new control, or how they are consistently seeing Y amount of outcome from year to year regardless of whether they spent X-1 or X+1 amount of effort, and so on.  But we are at the point, as an industry, where measurement is not just desirable – these days it’s actually necessary.
RE-IMAGINING INFOSEC STANDARS: PLAYING NICELY TOGETHER
Finally, since we’re trying to describe a new way of looking at security standards, maybe we could discuss the creation of a means by which models might be able to contribute information to each other.
You see, my belief is that Information Security, as we’re able to describe it right now, is too complex for one over-arching textbook sized model.  Rather, I believe that we’ll be more effective if we break the big problem up into smaller, more digestible chunks.  So practitioners of the various operational security duties can actually focus on their area of expertise, and not try to be masters of multiple domains (specialization is good, they say).
Standards Must Communicate To Have Aggregate Value
However, if we took the time with a whiteboard to try to paint a picture of all the components of organizational security (talking about the various areas of security specialization in sort of an object oriented sense, if you will), I’m betting we’d see that each area of security needs to be able to share information with others in a meaningful manner.  So Software Development processes need to exchange information with Vulnerability Management, who needs to talk to Intrusion Detection/Prevention, who needs to talk to Incident Response, and so on.  Now if we can establish rationalized metrics for the models (above), then ideally we’d be using a common security taxonomy, or at least using translation documents provided by the standard that would allow us to use one disciplines metrics (prior or posterior) if relevant to another discipline.  This gives us my final standard requirement, “a standard must reference, and be able to be referenced in, vernacular and in measurement (the language of the standard has to make sense to other standards)”.
Carrying that idea forward, it would probably be a great thing to have multiple competing models in any specific field, and wouldn’t it be wonderful if the language and meaning that they used were the same or easily translated (other than measurement models, obviously)?  So we would have an idea of comparative (in)effectiveness between competing models!
MOVING TOWARD A RE-IMAGINING
Yeah, so I’ve described a dream world of candy cane trees, rainbows, and happy unicorns.  Sure.  And I know it might take a generation or two of security professionals to get there.  But that doesn’t mean we can’t start now, and start with our current standards bodies – especially within the context of the pursuit and transparency of falsification and the development of meaningful metrics.  All it takes is the will to try and the willingness to fail.  As my co-presenter David Mortman and I said at Black Hat this year, “Models don’t have to be perfect, just ego-less”.Hollywood calls it “Re-imagining”.  The creative types call it “rebooting”.  We might settle for “re-thinking”. But since it seems to be all the rage these days to take a second look at a subject, I thought I’d apply the concept to one of our favorite topics, Information Security Standards.

I admit that this is an incomplete thought, but I’d like to share it with you for two reasons:

1.)  At the end of a podcast I was part of recently, one of the other panelists challenged our industry to stop whining about our current state of affairs and do something better.

2.)  To request your feedback on the idea.

So here’s my thought: if we’re going to re-imagine InfoSec standards, as if we could do it all over again, I think there are three basic requirements any standard needs in order to be useful at all:

1.) A standard must provide for its own obsolescence/evolution (falsification and a transparent falsification process must be built in)

2.) A standard must provide means of measurement (both for the outcome of the standard, and to measure the quality of standard adherence)

3.) A standard must reference, and be able to be referenced in, vernacular and in measurement (the language of the standard has to make sense to other standards)

(more…)

Tags: , ,
Posted in Analysis | No Comments »

Security concerns in a “D-I-Y” Economy

Monday, September 21st, 2009

 

A few months ago C|Net published an article claiming current economic conditions have resulted in greater enterprise use of free and open source technologies.  This sparked an internal discussion about whether the supposed tendency would have an impact on risk to the enterprise.   As such discussions are wont to do, it descended into the quagmire of “how secure is open source”, and eventually died a quiet death after the RISK team grew weary with the topic. I had already half-heartedly begun a blog article framing the debate, but quickly filed it away under ‘do not resuscitate’.
However, three subsequent events brought additional insight to the matter, namely:  an XKCD cartoon, the build-out of a lab test bed, and a team-member’s ailing water heater. These unrelated events convinced me to go ahead and blow the dust off the blog entry and get it posted.
Suppose your enterprise is one of those which are attempting to “do more with less” (as we all are), and further suppose that the task of building, testing, and deploying “something new” falls to the technology group that has expertise in doing “other things.”   It isn’t too much of a leap from here to see where the technology choice for “something new” might be guided by price.  After all, if the CFO’s daughter’s grade school can download a “something new” and make it work then surely the enterprise technology group can do at least as well.  Does this sound familiar?
Returning to our theoretical DIY technology team, we find them diligently at work deploying and debugging the aforementioned “something new.” As is often the case, something goes awry when following the published documentation. As you are undoubtedly aware, when technologists find themselves in unfamiliar territory they tend to rely on the “wisdom of the collective” to solve problems.  This phenomenon is well expressed in the Tech Support Cheat Sheet published in a recent XKCD ( http://xkcd.com/627/ ).   The prevailing thought goes along the line of this, “surely someone else has had the same problem, and was diligent enough to document the experience for the good of the order.”   Therefore, after plugging the salient details into their favorite search engine, the erstwhile tech team awaits the wisdom of the oracle.
What follows are excerpts from  “free advice” to searches related to diverse “something new” deployments on a lab test bed over the past several weeks:
-                       chmod 777 fixes  this
-                       grant all on database.* to  …
-                       allow tcp any  any
-                       community  public
-                       allow tcp  23
-                       do not change the default  password
-                       allow from  any
-                       security  manager=”no”
-                       disable rules which generate  excessive log entries
-                       allow root login:  yes
-                       everyone  fullcontrol
-                       chown -R www-user  *
-                       allow-update { any;  };
In almost every case the first several rounds of online advice included advice to RTxM in various states of  dudgeon, and if reading the fine manual didn’t suffice there was always some  well meaning individual with an expedient (though potentially dangerous) solution: “I did X and it works!”
And what about the water heater? One of the Risk Team members’ water heater died a few weeks ago, and as he had never experienced a water heater replacement in any home, he asked for any advice his colleagues might have to offer.  After much discussion about what sorts of plumbing problems qualify as “DIY” , Bill Murray of the RISK team gave the following advice: “Do it  yourself. You will learn a lot that you will never use again.  You will also learn that even when the pros are not cheaper, they are still worth the difference.  You will use that over and over.”
So, in wrapping this together I would say that one of the significant risks posed to the enterprise by “economically driven DIY” could result from situations where “community advice” might make its way into production without appropriate review and control.  Clearly this is not the problem when the enterprise has “the pro” plumbers on staff or on call.

A few months ago C|Net published an article claiming current economic conditions have resulted in greater enterprise use of free and open source technologies.  This sparked an internal discussion about whether the supposed tendency would have an impact on risk to the enterprise.   As such discussions are wont to do, it descended into the quagmire of “how secure is open source”, and eventually died a quiet death after the RISK team grew weary with the topic. I had already half-heartedly begun a blog article framing the debate, but quickly filed it away under ‘do not resuscitate’.

However, three subsequent events brought additional insight to the matter, namely:  an XKCD cartoon, the build-out of a lab test bed, and a team-member’s ailing water heater. These unrelated events convinced me to go ahead and blow the dust off the blog entry and get it posted.

(more…)

Tags: , ,
Posted in Analysis | 3 Comments »