information security strategy

A FAIR measure of defense in depth

2009-05-08T12:48:00.002-04:00

Recently, the owners of a system containing sensitive information where I work began planning an upgrade to the latest available version. In addition to performance improvements and bug fixes, the new release also modified authentication and authorization processes. Compared to the current model, these changes would offer significant cost improvements in administration and support. But before flipping the switch, business and security stakeholders wanted to know “which configuration is more secure?”

To provide an objective answer to that question, we defined “more secure” as the configuration and support processes (i.e. security controls) that would result in the smallest amount of residual risk to the organization.

Initially, this looked like a simple consulting request from a business unit. Normally, the security team reviews the proposed security architecture and provides a recommendation. But long after the system upgrade, system owners and administrators will face new decisions that impact the security of the system. They needed advice and a full knowledge transfer on how security controls work together.

The Factor Analysis of Information Risk (FAIR) methodology makes this kind of analysis transparent by decomposing the analysis into lower levels of detail only as needed. In situations where the alternatives are very similar, FAIR allows an analyst to identify and focus only on the relevant differences.

FAIR defines risk as “The probable frequency and probable magnitude of future loss.” Given that we looked at two possible configurations of the same system, the underlying information value was equivalent in both situations, and the expected threats were also the same. So the probable magnitude of loss could only be determined by the controls, not by any differences in the underlying information. Since the FAIR framework structures the analysis in a hierarchy along impact and likelihood boundaries, an analyst can isolate the comparison to only the parts of the analysis to the subset of factors that are different. In this case, the focus was on control strength and control depth against the range of expected threats.

Using FAIR, we looked at the type and frequency of contact that threats would have with the system, their probability of action, and the number and strength of controls applied in each case.

In the end, the analysis objectively determined which configuration had enabled more layers of security controls that could not be circumvented by an attacker. (As an example of circumventing a control: logon banners may be required for legal reasons on certain systems, but an attacker may not interact with the system through those defined interfaces and thus circumvent the control. The AOL mumble attack is another.) And the threat-oriented focus provided a context for evaluating future system changes: owners, auditors and security team members now share a common understanding of how control changes add or remove layers of protection between threats and assets.

Eventually, we wound up with a reasonably portable security metric for comparison: defensive layers per threat vector.

It’s not the number of controls or compliance gaps that determine the security of a system, but the strength and depth of that protection that attackers can’t sidestep.

Security policy pest control: Exterminate weasel words

2009-04-24T15:38:00.001-04:00

Do your security policies suffer from an infestation of “weasel words?” If so, they need to be captured and destroyed. If that seems inhumane, they can also be recycled and sold to professional politicians, United States Federal Reserve Bank chairmen, or used in ready-to-make waffle mix.

What are weasel words, why don’t they belong in a security policy, and why are they associated with “waffling?” In the information security policy space, weasel words fall into two basic categories: undefined terms, and inherently vague phrases. For example:

Undefined terms:
“Shall be limited to authorized personnel…”
“…only IT-approved software may be installed”
“…must be restricted.”

Inherently vague phrases:
“…where possible…”
“…where feasible…”

So what’s the problem? Left unchecked, weasel words weaken an information security program by:
1. Generating an excessive amount of consulting requests for the security team. Scarce analyst time is consumed answering questions about the meaning of security requirements, instead of advising on how to implement them.
2. Creating uncertainty for functional teams. If the requirements aren’t clear, team leaders will not know how to prepare for audits, or how they will perform when examined because boundaries aren’t clear.
3. Allowing inconsistent implementation of security controls. Unspecified requirements are not requirements: the phrases used must constrain action in some way. Otherwise, you’ll see 20 different interpretations for each, and no consistency across organizational boundaries. And as the 2008 and 2009 Verizon breach investigation survey and the recent joint strike fighter intrusion incident shows, successful attacks gravitate to the areas of weakest security.
4. Leading to weak enforcement. What is the boundary between authorized and unauthorized? Where and how is IT approval granted? Without being specific, it isn’t possible to enforce.
5. Causing ineffective reporting. If there isn’t a clear threshold for when a requirement is “met” or “not met,” then how can you report on the state of security? If each control allows for a wide span of interpretation, a list of “met” controls doesn’t cover it. One caveat here: Fusion Risk Management has a great solution to this issue; when assessing current implementations, their processes allow for the assignment of a maturity level to each control implementation. This gives greater context than a simple “met” or “not met.” But even in this setting, there are defined thresholds that separate each level of maturity, which is the key to visibility and continuous improvement.

Policies are an opportunity to set direction for an organization at a high level. What is the intent of management? It’s important to be flexible, but vague is not the same as “high-level.”

The appeal of using inherently vague phrases is that they can be quickly inserted at draft time, and at first look they appear to allow for flexibility. The intent is to account for the give-and-take between risk and cost at the policy origination stage, since organizations do not have the resources to evaluate the cost of dozens (or hundreds) of controls across a wide range of teams, departments and business groups.

But weasel words are not a substitute for meaningful security governance. If a control is too restrictive, or isn’t clear, it needs to be reviewed by leadership and aligned with the needs and capabilities of the organization. And if there are substantial differences between units, then there needs to be an explicit documentation of how that risk will be handled. But a well-designed ISO 27001 Information Security Management System (ISMS) accounts for this.

When documenting a security requirement, follow this simple rule: if the organizational impact of a requirement isn’t clear enough to specify management intent in a given category, then leave it out until that impact is known.

Good security hygiene requires a pest-free environment. Find and exterminate all weasel words, and use governance to weigh risks and costs in a planned approach. This will help you trap them before they get back in again. Catch and release …

Getting the most out of virtual teams

2009-04-19T21:57:00.000-04:00

Most of the big challenges in information security require a multi-disciplinary approach. It takes specialized knowledge and input from many different areas for leaders to successfully balance costs to the business against the expected benefits of reducing risk while ensuring that operational goals are reached.

In global organizations, this usually involves virtual teams working with a mix of collaboration tools, with relatively few opportunities for face to face interaction. These matrixed teams can often feature a more diverse mix of countries, cultures, educational backgrounds and perspectives. But their value can be easily lost if one or more dominant voices crowd out the rest.

To keep that from happening, there are several decision making tools that can be helpful in a virtual setting which encourage collaborative and creative development within a project structure.

Spiral Development Methodology
If the goal of the project is to develop a process or internal service offering under tight timelines, and if role definitions and/or project deliverables have a significant amount of ambiguity, it may make sense to use the spiral development approach in order to ensure that a working process is implemented right away. While it isn’t labeled a “spiral” methodology, Kevin Behr, Gene Kim and George Spafford detail the essential steps for establishing control over change management in their book The Visible Ops Handbook: Implmenting ITIL in 4 Practical and Auditable Steps.

In contrast to traditional development methodologies that use a top-down approach which begins with fully specified requirements and ends with a final product, the spiral approach uses these steps:
1. Plan – specify requirements in as much detail as possible
2. Design – design the solution based on known requirements
3. Prototype – build a working process / solution and deploy it
4. Evaluate – compare prototype performance against expected performance; have the initial goals been met? Identify lessons learned and new requirements, and repeat steps 1-4 as needed.

By taking an iterative approach, the team can deliver a working solution that meets immediate operational and/or regulatory requirements while gaining experience that will be helpful in refining and improving the solution.

Improving decision making in virtual teams
As typically implemented, brainstorming in a team setting involves a facilitator documenting alternatives in the order in which they are most loudly, and frequently, repeated. Because they’re generated one at a time, some ideas get lost along the way, and at a certain point the list seems “long enough” and that’s the end of the input.

Even in a motivated team with good interpersonal relations, the “tyranny of the enthusiastic” may unwittingly crowd out other options. One way to prevent this is to use what is called the Nominal group technique:
1. Before the meeting, each team member writes down their own ideas on the problem; requirements, design issues, and solution approaches.
2. The team meets:
a. Each member presents one idea to the group; no discussion takes place until all ideas have been recorded.
b. The team asks questions to each presenter to ensure that their approach is clearly understood, and then evaluates it.
3. Each team member ranks the ideas presented and sends their “votes” to the facilitator. A final decision is based on the highest aggregate ranking.

While this involves more pre-work and coordination than the typical “brainstorming” approach, the advantage is a much fuller reflection of the capabilities of the team. And since all team members must present, it makes “social loafing” much less likely as everyone is expected to provide input.

Another approach, originally pioneered by RAND as a forecasting tool is called the “Delphi” method:
1. Each member provides a written forecast, along with supporting arguments and assumptions.
2. The facilitator edits, clarifies and summarizes the data
3. Data is returned as feedback to the members, along with a second round of questions.
4. The process continues, usually for about 4 rounds, until a consensus is reached.

Sometimes it’s possible to just throw people on a conference call and just hash it out. But other times, you need all of the creativity, engagement and effort that a matrixed team can muster, and all on a very short deadline. In those circumstances, an ounce of smart structure can yield a pound of results.

Boiling the O.C.E.A.N.

2009-04-04T11:21:00.005-04:00

Metrics projects that are intended to consolidate and report on the state of security for an organization rarely fail for a lack of measures. Information technology systems, processes and projects all throw off an impressive amount of data that can be captured and counted. The Complete Guide to Security and Privacy Metrics suggests over 900 metrics, and NIST Special Publication (SP) 800-55 Rev. 1, Performance Measurement Guide for Information Security extends this analysis from the system level to an executive view by providing a framework for summarizing the results.

So given all of the measures, structure and guidance available, why is it so tough to be successful? The silent killer in this space is often a lack of focus: too many metrics, too much aggregation, and too little analysis connected to business problems and goals to provide useful insight.

Instead, its better start with the stakeholders and focus on fully understanding their goals and decisions without limiting the conversation with assumptions about what is or isn’t going to be measureable.

Consider this subset of stakeholders, and some of their goals:
Executive management – financial health and strategic direction of the organization. Are we profitable and are we executing effectively in the markets we serve?
Risk governance / Security management – are we keeping risk at an acceptable level? Are we making the best use of the security resources we have?
Line Management – are we achieving operational goals, and aligning with strategic initiatives?
These questions become an effective filter for removing the measures that don’t matter, and for finding common measures that, with analysis, can serve many different purposes. Here’s where it may be useful to classify measures from a stakeholder perspective in terms of the types of decisions that they enable:
Output measures - what is the primary deliverable from a given team?
Coverage measures – how many locations, systems or groups are covered by a given process or policy?
Exposure measures – what proportion of the environment stores or processes regulated information?
Activity measures – how many requests have been received during a given reporting period? Addressed?
Null measures – which teams have not provided data?

The last category is an important one, as it highlights the difference between a measure and a metric. A measure is an observation that increases your understanding about a situation and improves the quality of decision making; a metric is a standardized measurement. Inconsistent, incomplete and missing data from key teams or groups are an important measure of program maturity. Sometimes it’s what you can’t count that counts.

Above all else, resist the pressure to measure everything. A few well-chosen measures will allow for versatile and powerful analysis. There are literally dozens of ways to analyze and present a limited number of well-chosen data points. And when captured consistently over time, the correlations between seemingly unrelated activities offer the opportunity to surprise.

Security Policy as concept car

2009-03-28T13:50:00.013-04:00

In the JMU Information Security MBA program, the main assignment for the second class is to put together an information security policy manual. During the lectures we spent most of our time focusing on frameworks and sources such as ISO 27001, COBIT, ITIL, NIST, SANS and many other sources of policy content. Thankfully, we also spent time working through some themes from The Design of Everyday Things by Donald Norman.

My favorite takeaway from the class was the realization that "fit" is an important concept in information security; so much so that it should be explicitly recognized in the policy framework. Policies must fit the security requirements, cost constraints, culture and capabilities of an organization.

At the risk of leaving out a number of "must haves" in my policy manual, I wound up putting together a Concept Car for security -- a collection of statements and requirements oriented around three questions:
* What does your business need?
* What can you execute?
* What can you afford?

They're not complete, but hopefully reflect a decent start in each of the categories that they address. I've also included links to all reference sources for more detail:

Information Security Strategy and Architecture
Information Security Charter
Acceptable Use Policy
Data Owner Security Policy
System Owner Security Policy
Platform Infrastructure Security Policy
Messaging Security Policy
Network Security Policy
Physical_Security_Policy

Information Supply Chain Security

2009-03-24T19:40:00.003-04:00

Abraham Maslow once wrote “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” But what if your toolbox has everything except a hammer? At the very least, it limits what you can build.

Last week at the University of Maryland I had the opportunity to be a part of a workshop to develop a Cyber-Supply Chain Assurance Reference Model, sponsored by the RH Smith School of Business and SAIC. Looking at the security challenges that organizations are now facing, the old toolbox seems about half empty.

Prior to the workshop I was very comfortable with confidentiality, integrity, availability, authenticity, and non-repudiation along with risk management definitions of loss expectancy as the basic language of information assurance. But after a few hours of looking at information technology in the context of a cyber-supply chain, it became apparent that we need better tools to characterize and manage emerging risks. There were a number of different perspectives represented at the meeting, but here’s my take:

Traditionally, assets are assessed individually and independently as part of the information assurance process. For internally facing systems with limited or explicit interdependencies, this isn’t a bad representation. But for organizations where boundaries with suppliers and customers are blurring, the interdependencies among these systems eclipse the value of the data they hold. From a risk perspective, Verizon’s 2008 Data Breach survey shows how attacks against vendors and suppliers become the entry point into “secure” organizations because of trust relationships. And from a financial perspective, high confidentiality requirements can make it difficult to ensure high availability in a cost-effective way.

Existing risk frameworks such as COBIT and ISO 27001 can describe these issues, but are not designed to model the trade offs in a way that helps security leaders optimize.

This is the point where the information security toolbox needs to draw on research capabilities from other disciplines. The Supply-Chain Operations Reference Model (SCOR) provides a proven framework for analysis that captures these dependencies.

The information supply chain analyst asks: where is information captured (created) and processed? What are the storage and delivery requirements? Risk, cost and the traditional “CIA” triad are variables in a business decision, rather than optimization goals on their own.

In contrast, infrastructure protection often takes an asset-centric view that attempts to identify the intrinsic value of an application or environment, separate from its role within an extended system. This makes the connection to business value more difficult to express, and to optimize.

The reference model will be published in April. In the meantime, there are still a few details that are being … hammered out …

Securing the organization, despite management’s best efforts to stop you

2009-03-18T22:46:00.008-04:00

Looks like the abstract below is going to get the green light for the May 2009 Grand Rapids ISSA meeting. Ok, so the title is a bit of "red meat" for a largely technical audience, but the straw man here isn't management ... or security: it's the "ivory tower" textbook description of how security is supposed to work.

In reality, the most effective leaders that I have seen have been the ones who are pragmatic, patient, and unconcerned about "style points" when it comes to building an effective program. They just make sure that the number and severity of incidents keep trending in the right direction, even if the drivers of that success come from other parts of the organization.

Hopefully, I'll capture some of that in the slides that go with this presentation:

"Every text on information security says “be sure to get executive management support” before you start. But what should you do when that support is less than what you need, as is often the case in today’s cost-conscious environment? Management isn’t really out to stop you, although at times it may seem that way because of the contradictory pressures that affect the entire business.

Meanwhile, threats to information security are recession-proof, they don’t have layers of approval to contend with, and they’re not going to go away any time soon. Information security professionals need to respond to these threats regardless of the organizational challenges, and in the process build that support by demonstrating the value of the work they do. And they need to be strategic in their approach as it comes to requesting additional resources and support. The purpose of this presentation is to build on the concepts introduced in the Harvard Business Review “Managing Up” article collection, and presenting the impact of security with management-centric measures and analysis that will build the case for improving security by highlighting the facts, rather than fear, uncertainty and doubt.

Suggestions, success stories and one-line management rebuttals are welcome.

Something to the effect of: "Enabling the business / Serving customers / earning a profit ... despite security's best effort to stop you ..."

Making the right call

2009-03-16T20:47:00.002-04:00

Cloud computing, or on-premises: which is more secure, and which is the better option for your organization?

It’s a simple yes or no question, and yet it shows just how much further security risk management needs to mature in order to command the stature of marketing or finance in driving company strategy. This isn’t to suggest that security is less important to an organization; it just hasn’t made as much progress formalizing and defending its decision making processes. Financial analysis tools can help in this category, so long as they’re not applied too literally.

For example, the “cloud vs. onsite” decision shares some important similarities with the “lease vs. buy” decisions that finance supports all the time. Finance uses a very simple decision rule to choose between alternatives: accept the decision that maximizes the net present value of the investment. Specifically: what is the sum of all cash flows (i.e. investments, expenses and revenues generated) and what discount rate should be applied to reflect the rate of return that is appropriate for this kind of investment decision?

Often the underlying assumptions and analysis are as important to decision makers as the final recommendation, so transparency is essential.

Given the rate of change in most organizations, security isn’t often asked to weigh in on a single investment choice in isolation. Usually, the decision involves picking the best course among alternatives, so it just needs to be clear, based on a consistent set of evaluation criteria, which alternative is comparatively better. And just as with the “lease vs. buy” scenario, decision makers need to see the analysis as well as the recommendation.

To compare alternatives, objectively, from a security perspective:
* Compare architectures. Which has greater complexity, and why? Higher complexity works against high availability.
* Compare security models: count the number and severity of exposures in each environment to attack.
* Compare control strength, using a common framework such as COBIT or ISO 27001: which environment provides greater defense in depth? What controls must perform effectively in order to ensure the security of systems and critical processes?

So long as both alternatives are assessed with standard, open frameworks the analysis will provide both a recommendation and a basis for evaluating all of the essential underlying assumptions. The intent is not to reduce the inherent variability of threat behavior into a single score that can be applied to both environments, or to conduct an expensive, overly detailed exercise. If there is a significant difference among the alternatives, it will begin to appear with a basic review of high level architectures and security models. If there isn’t much difference, then the decision threshold for security is likely to be met by either environment, and the decision rightly shifts to an evaluation of business benefits.

It only becomes difficult when you’re trading off performance and risk. But there’s a way to deal with that as well …

Strategy-based Bracketology

2009-03-08T23:02:00.024-04:00

In the information economy, it’s important to cross-train on select skills from other fields: there’s Operations Management for MBAs, Finance for Senior Managers, and perhaps the most important of all, Bracketology for Information Security Risk Managers.

Managing bracket risk
In the NCAA tournament, on average, the higher seed wins about 70% of the time. Most bracket pools score the results of each round the same, with 32 possible points for picking all of the winners in that round. There are six rounds, so the maximum possible score is 192. If you follow a high-seed strategy (i.e. pick the higher-ranked team) you’ll likely wind up with a score that's better than average.

Of course, if you pick straight seeds, you can expect the following:
* You’ll do well in tournament years that feature exceptionally strong top teams.
* You’ll be ridiculed by your friends for having no imagination and playing it safe.
* In a bracket pool of any size, you’re odds of winning are very, very low.

Everyone else picks upsets. Most people get most of them wrong, but a few get lucky, and the lucky ones come out on top. To have a shot at winning against your friends, prognosticators, or the masses on Pickmanager, you have to go with some underdogs. Each year there are usually a bunch of upsets, and the more you pick, the higher your potential score will be--at least in theory.

(As an aside, this perspective sheds a little light on how the current Wall Street mess started, and why it was so hard to stop: to attract investors, you have to produce top returns. And you’re not going to get top returns by always playing conservative.)

Start with history
Obviously, seeds are a strong indicator of performance, so it doesn’t make sense to just pick upsets at random. It’s good to look at the historical performance of each seed as a starting point. There are some upsets that happen every year, and the conventional wisdom is that they are “safe” to pick. For example, let’s look at 5 v. 12 first round matchup. Historically the 5 seed wins 67% of these games; an average of 1 to 2 upsets per year.

If you pick all 5 seeds, you’ll usually get 3 out of 4 possible points in the first round from those matchups. Sometimes they’ll all win and you’ll get 4 points; other times there will be two upsets and you’ll only get 2.

So putting your risk management hat on, which is that the best approach? Without any additional information, what strategy will give you the highest payoff? Consider the 2008 tournament 5 v 12 pairings:

(5) Notre Dame v (12) George Mason
(5) Clemson v. (12) Villanova
(5) Michigan State v. (12) Temple
(5) Drake v. (12) Western Kentucky

The left column on the chart below shows the 16 possible outcomes, with the historical probability of each. To see which one has the highest payoff, compare the columns to the right for each strategy: no upsets, 1 upset, or 2 upsets. (In the table, 2008 team names are listed instead of scenarios for clarity.)

				Pick Strategy
		All high seeds win		Notre Dame upset		MSU and Drake upset
Outcome	Hist. Prob.	Max Points	Exp. Value	Max Points	Exp. Value	Max Points	Exp. Value
All high seeds win	20.2%	4	0.81	3	0.60	2	0.40
Notre Dame upset	9.9%	3	0.30	4	0.40	1	0.10
Clemson upset	9.9%	3	0.30	2	0.20	1	0.10
Michigan State upset	9.9%	3	0.30	2	0.20	3	0.30
Drake upset	9.9%	3	0.30	2	0.20	3	0.30
MSU and Drake upset	4.9%	2	0.10	1	0.05	4	0.20
Clemson and Drake upset	4.9%	2	0.10	1	0.05	3	0.15
Clemson and MSU upset	4.9%	2	0.10	1	0.05	2	0.10
Notre Dame and Drake upset	4.9%	2	0.10	3	0.15	2	0.10
Notre Dame and MSU upset	4.9%	2	0.10	3	0.15	2	0.10
Notre Dame and Clemson upset	4.9%	2	0.10	3	0.15	2	0.10
Clemson, MSU and Drake upset	2.4%	1	0.02	0	0.00	3	0.07
Notre Dame, MSU and Drake upset	2.4%	1	0.02	1	0.02	3	0.07
Notre Dame, Clemson and Drake upset	2.4%	1	0.02	1	0.02	1	0.02
Notre Dame, Clemson and MSU upset	2.4%	1	0.02	1	0.02	1	0.02
All low seeds win	1.2%	0	0.00	1	0.01	2	0.02
Expected Value (number of wins)	100.0%		2.68		2.27		2.15

Focus on specific outcomes, not typical results
It seems that if you know that one high seed is going to lose, you should pick at least one upset --and yet picking only the high seeds has the highest expected payoff (2.68). So what’s going on here?

Across the 16 possible outcomes of the four 5 v 12 games, a “no upset” strategy for this particular matchup ensures that the most likely scenario gives you the highest possible payoff, and the least likely scenario is the one that would leave you with the lowest possible payoff. (It does not hold true in the 8 v 9 case.) Knowing that 33% of the number 12 seeds are going to come out on top doesn’t help you pick the right ones. (Clemson and Drake were knocked out in the first round last year.)

The moral of the story: historical averages are important, but there’s a world of difference between knowing what typically happens and predicting what will specifically happen. You need a much higher level of confidence about specific outcomes (i.e. risks) in order to be more effective than just playing the odds.

How much more confident? Working backwards, if you adjust the probability of the scenario you think is most likely (e.g. MSU and Notre Dame as the only 5 seed winners) you can see what level of confidence you need in your prediction to justify making that choice.

Getting to that level of confidence requires research; knowing that you’ve reached it takes practice ...

March Madness and Risk Management Strategy

2009-03-07T16:24:00.020-05:00

Every vice, if it hangs around long enough, starts attracting self-justifying quotes. Ben Franklin came up with one of my favorites: “Beer is proof that God loves us and wants us to be happy.” I don’t necessarily agree, but I can empathize with anyone looking for ways to reduce their own cognitive dissonance. I also have a vice that I find virtuous: "March Madness," the annual NCAA college basketball tournament.

Each year, along with about 2 million other people, I sign up for Yahoo’s College Basketball Tournament Pick’em to see how many I can get right. Personal obsessions and Izzomania aside, I will proclaim with all sincerity that the skills you need to consistently make good picks in the NCAA tournament will also make you better at security risk management. Both risk management and tournament bracketology are based on making risk choices under uncertainty; both involve the judicious use of outside experts, rich statistical data, and intangibles. They also share the trait that over the short term, it’s really tough to tell the difference between luck and skill.

March Madness 101
The single elimination tournament is played in six rounds, with 64 teams seeded in 4 regions. In the first round, teams are paired with the highest seed playing the lowest seed e.g. 1 plays number 16, 2 goes against 15, all the way down to 8 against the 9th seeded team. Winners advance, so assuming that the high seed wins each game, in the second round the number one seed would then play the number eight team in the region; the two seed will play number seven, etc. Of course, the high-seed teams are regularly upset by lower seeds with a randomness and regularity that is … maddening.

Points are awarded during each round for correct picks as follows:

Round	Points per correct pick	Number of games	Possible points
1	1	32	32 points
2	2	16	32 points
3 ("Sweet 16")	4	8	32 points
4 ("Elite 8")	8	4	32 points
5 ("Final Four")	16	2	32 points
6 (National Championship)	32	1	32 points
Maximum Possible			192 points

So there are 63 decisions to take before the first game begins, and the goal is to predict the winner of each game, in each round, in such a way as to maximize your total score:

Score for the round = points available * number of correct picks

This equation bears a very strong resemblance to the standard information risk equation below, which is used to calculate loss expectancy as part of the risk assessment process. Both equations define a payoff as the product of something you know quite a bit about (impact) and something that you can estimate to some level of confidence but not perfectly predict:

Risk exposure = risk impact * event probability

So if you get pushback for following the tournament in minute detail, obsessing over your picks and constantly checking your rankings every time there’s an update, take heart: It's not just a tournament, it’s a huge learning opportunity. Decision making in a dynamic, competitive situation with limited information and lots of uncertainty is a great environment for building your risk optimization skills.

Organizational Agility

2009-03-04T21:52:00.002-05:00

It seems that 2009 is stacked against just about everyone trying to get new security initiatives off the ground. First we saw the waves of cuts and layoffs, with information security budgets left largely intact. But now the freeze is turning into cuts for security departments as well.

If only the threats to our environment were also struggling with the pressures of downsizing. But they’re not, so we have to stand up the most robust set of administrative, technical and physical controls we can muster with the resources we have.

Security departments aren’t the only teams that have to figure out how to win under these circumstances. Hockey teams are used to playing outnumbered for short periods of time. When a player is sent off to the penalty box, their team must carry on short-handed until the penalty time expires.

During this “power play,” the penalized team changes its defensive stance. They still directly challenge the attacking player with the puck, and maintain a depth of defenders in front of the goal to take away any open shots. But the defense can’t cover everything, and so they do their best to recognize and respond quickly as their opponent constantly shifts the point of attack.

Until the economy rebounds and budgets recover, many organizations won’t be able to fully staff every function and administer every control. It might take a year or two, but for now we’re in “penalty kill” mode. Situational awareness and the ability to respond quickly and cohesively is going to be especially important.

So how agile is your organization, and how does that agility impact your short-handed security strategy in a “power play” environment?

Measuring agility
Organizational agility is the ability of groups and teams to react to change in a way that benefits the overall organization. Agile business organizations observe market conditions, analyze opportunities, decide on a course of action and execute those plans effectively. (Well, in theory anyway. As military strategists like to say: “No plan survives contact with the enemy.”)

An organization with staff overburdened with responsibilities isn’t agile. So before trying to press on with a labor-intensive approach to security, it’s important for management to assess the organizational capacity to carry it out.

A good indicator of staff workload is meeting availability. So to measure agility, pick 30 people at random across the company and schedule a meeting without sending it. See how many are available during 2 or 3 different time slots this week. Then push it out 2 weeks, and choose a few more time slots. Then push it out a month. With a random spot sample of time availability, you can get a sense of the capacity of the organization to support key security initiatives.

If you find that the capacity is there, then labor-intensive activities such as security awareness training, information classification and risk assessment work can be sustained with a good chance of uptake and success. But if the calendar space isn’t there, it’s likely that your strategy will need to change. It may be better to focus on delivering technical security controls to your organization, instead of expecting as much from them.

Security, Functionality, and Profitability

2009-02-27T00:00:00.023-05:00

As a security manager, are you frequently at odds with your business leadership regarding risk decisions? If the answer is yes, then good … the process is working.

So long as it is surfaced and resolved, conflict can lead to better decisions: but only if the process considers in detail how adjustments to the mix of security and functionality within IT systems affect the long run profitability of the organization. To quote Alfred P. Sloan: “If we are all in agreement on the decision - then I propose we postpone further discussion of this matter until our next meeting to give ourselves time to develop disagreement and perhaps gain some understanding of what the decision is all about.”

To be useful, IT systems need to operationalize business processes at a cost that allows the organization a reasonable return on investment. At the same time, these systems and the data they contain must be protected from unauthorized disclosure, modification, or loss.

Security professionals are hired for their specialized knowledge in deploying and managing systems that provide defense in depth: multiple layers of independent security controls that reduce the exposure of these systems to security incidents, and reduce the impact of these incidents when they do occur. Likewise, business leaders bring a similar level of specialization to key business processes, but with a focus on maximizing functionality and performance; reduced overhead, increased throughput, and so on.

So if both expertise and incentives are cross-aligned, what is the solution? Split the difference? Each time a firewall rule change, or configuration exception, or other deviation from best practices is under review, flip a coin? Well, not exactly. Compromise is important – but not to the exclusion of understanding the forces at work in the situation.

There are a lot of ways to represent this, but in the interest of promoting “Green IT” I’m recycling a few things from my microeconomics classes. The graph below shows the financial impact of securing an IT system. The vertical axis represents profitability; higher is better. The horizontal axis is a continuum: the left side represents a high degree of functionality, but lower security. Moving to the right involves adding layers of security controls, which in turn reduces the functionality and efficiency of the system from the perspective of the end user. The semi-circle on the graph is a benefit curve, which shows what happens to profitability as more controls are implemented. Moving from left to right, increasing protection up to point “A” makes the company more secure and more profitable. Functionality begins to decrease, but the value of protection over the long run pays for itself...up to a point. Eventually, adding “more security” begins to frustrate end users and slow business processes. And at point “B” the company is more secure, but worse off.

Ideally, leadership will recognize the trade-off that maximizes profitability, work to reach point “A,” and when they get there, stop. If the company finds itself at point “B,” exception requests which greatly ease the business process without significantly eroding the quality of protection should be approved until point “A” is reached.

If it's this obvious, then why does the process break down? Typically, security managers have more experience finding risks than business opportunities, and are rewarded for decreasing the former, rather than increasing the latter. Perhaps it's written into the annual goals this way:

Manage information security threats (30%)
Define security architecture, direct daily operations of staff. (50%)
Support financial targets of company (20%)

In this scenario, security incentives outweigh profitability incentives by a 4:1 ratio.

So the second illustration below shows how a security manager might evaluate different levels of functionality and protection. The curve, “U”, that runs from the top left to bottom right of the graph represents the trade-offs between security and profitability that a manager is willing to make. At any point on the curve, the security manager is indifferent (equally satisfied) with a given mix of security and profitability. The point at which the indifference curve "U" touches the profitability curve is the point a security leader sees as optimal.

From the shape of this curve, to accept low levels of security, the organization has to be exceptionally profitable. Moving to the right, a security manager might be willing to continue locking systems down even when there is a measurable profit impact.

And finally, one last graph below. Consider a business manager who understandably wants to maximize functionality, specifying requirements for a new customer-facing application. Business requirements put the tradeoff at “X” while the security chief pushes for “B”. Point “A” again represents the maximum benefit to the company. Sometimes “X” is closer to “A”; other times “B” is. So how do you determine where you actually are, and then make the improvements needed to get closer to “A?”

Risk Governance
IT governance processes, if properly designed and well managed, can be a huge help in bridging the natural divide between specialized experts with widely differing preferences. While it’s important over the long run to teach security professionals the fundamentals of the business, and equally important to have business leaders recognize the impact of security vulnerabilities, the reality is that rational decision makers will be influenced most strongly by the incentives that directly apply. Or as they say in the political realm: “where you stand depends on where you sit.” But back to Sloan -- what really matters is the shape of the curve, and how well the governance group understands it. Where is the “A” investment, and given the available architecture and implementation choices, how close to “A” are the various alternatives?

The governance process should seek to draw out all of the pieces of the proposed solution: what are the key components of the business process? Which elements are the most important contributors to the business value produced? What are the constraints? Likewise with security: what configuration requirements, administrative overhead, monitoring capabilities or other concerns are involved?

Without a sense of the size and shape of the benefit curve, and the location of various options on it, decisions will be based on the relative political strength of the participants. It's available to do better than that. While it is always going to be difficult to tell if you’ve actually reached “A,” it can be very apparent that you’re doing better than “X” or “B.” And if that decision comes at the cost of some challenging discussions, it’s a debate worth having.

The next 12 months

2009-02-20T22:19:00.003-05:00

Yesterday at the Chicago ISACA meeting I had the opportunity to hear Dave Ostertag from Verizon walk through the 2008 Verizon Data Breach Investigations Report, point by point. At the time of publication, the report included over 100 data points from 500 cases, but the base is now up to 700 cases and still more interesting patterns in the data continue to emerge.

The report is 27 pages long, but it informs an information security strategy by simply and persuasively answering one simple question: “What changes can I make in the next 12 months that will significantly reduce the likelihood and impact of a security incident in my organization?”

Across all the activities lumped under the banner of information security, Verizon found that a surprisingly small set of outcomes (or more accurately, the absence of these outcomes) mattered most. The survey lists nine recommendations, but I’ve re-worded and consolidated them a bit here:
1. Execute: ensure that security processes implement the identity management, patch management and configuration management basics. From the survey: “Eighty-three percent of breaches were caused by attacks not considered to be highly difficult. Eighty-five percent were opportunistic…criminals prefer to exploit weaknesses rather than strengths. In most situations, they will look for an easy opportunity and, finding none, will move on.” In contrast, among poor-performers, “…the organization had security policies … but these were not enacted through actual processes…victims knew what they needed to do … but did not follow through.”
2. Inventory, segment and protect sensitive information: “Sixty-six percent of breaches involved data that the victim did not know was on the system.” Know where critical data is captured and processed, and where it flows. Secure partner connections, and consider creating “transaction zones” at the network level to separate baseline business activities from high sensitivity environments.
3. Increase awareness. “Twelve percent of data breaches were discovered by employees of the victim organization. This may not seem like much, but it is significantly more than any other means of internal discovery observed during investigations.”
4. Strengthen incident handling capabilities. Monitor event logs, create an incident response plan, and engage in mock incident testing.

Steps 1 and 2 reduce the likelihood of an incident; steps 3 and 4 primarily reduce the potential impact by decreasing the time lag between an intrusion and its eventual identification and containment.

As for step four, my first thought is that mock testing won’t be much of a need for most incident response teams because of the natural cycle of event monitoring, suspected incident reporting, and initial response to events that are often false positives. Organizations that promote active reporting of suspicious events, and who treat each one as an actual incident will have much of the practice in a live setting that mock drills would otherwise offer. Instead of trying to prevent false postitives from occurring, an IR team should work to become more efficient at quickly ruling them out. As they do, the threshold for activating an initial review will drop, and ultimately they’ll catch more events closer to the time of occurrence.

It’s still a good idea to ensure that all stages from identification through remediation and recovery are fully practiced, but in general achieving containment quickly reduces the number of records exposed, and thus the eventual full cost of the breach.

Which brings us to next steps for Verizon; it seems that they’re now working on developing an incident costing model. This will be huge, because without it, organizations will continue to struggle with how to set specific protection goals that align with their cost structure and business strategy.

As an example, the survey looked at four sectors. Retail was one that contributing a sizeable amount of data (which is a polite way to say they got hacked a lot.) No surprise that simple survival is usually a bigger concern than security for many retailers: net profit margin among publicly traded companies in this sector often ranges between two and six percent. An additional dollar spent on physical security needs to be matched by up to $25 in additional sales … just to break even. Considering the wholesale cost of merchandise, it’s understandable why management accepts the risk of physical theft, formally accounting for it as “shrinkage.”

Unfortunately, while this mindset towards risk carries over into the electronic space, the analogy doesn’t. A dollar lost to computer crime, either through the cost of the incident itself, or the cost of organizational response, comes straight out of profits. It’s a much more damaging effect.

But, without a clear measure of the cost of an incident, the value of steps 1-4 to the CFO are murky at best. It doesn’t need to stay this way: calculating the direct and indirect handling costs of an incident isn’t a terribly difficult exercise, and most organizations already have the data needed to put it together. At JMU I started down this path with Dr. Mike Riordan in his Managerial Accounting class, drawing heavily on Gary Cokins’ paper Identifying and Measuring the Cost of Error and Waste to frame the problem. We need a credible model backed by lots of data, and I’m really hoping Verizon is able to put it together.

As for the next 200+ cases, I can’t wait to see how they present the 2009 findings. To characterize the survey as “pathology” might be a bit strong, but I thought it was interesting to note Dave’s background as a former homicide investigator. During the live session, you get some answers to the “so then what happened?” questions that the report doesn’t touch.

On our end it may feel like a never ending battle, so it’s good to talk to someone with a broad view of what is going on internationally. It’s more than a little comforting to learn how much progress is being made in locating and taking legal action against the bad guys…

Change as a catalyst for security

2009-02-10T23:42:00.009-05:00

IT Budgets are expected to be flat for just about everybody in 2009; IT security spending will likely be the same. After years of relatively strong management support this may seem like a setback, but I’m convinced that the proverbial glass is still at least half full.

Even if new security technology rollouts are being delayed, that doesn’t mean the entire organization is standing still. Management faces pressure on revenues and costs, and they’re going to be very active pursuing any and all strategies to make improvements in both of those categories. These pressures are going to drive change, and change can become a powerful catalyst if you can influence the organization to address security issues opportunistically.

There are two keys to an opportunistic security strategy: first, a thorough understanding of the gaps in administrative, technical and physical controls across the enterprise. And second, an equally sound understanding of how to produce better security as a side effect of operational improvements.

As an example, the Visible Ops Handbook describes high performance organizations which have gained control over their change management processes, boosting efficiency. More importantly, “by putting in controls to find variance, they have implemented preventative and detective procedures to manage risk.” Security is a side effect; an externality of operational improvements.

The output of security control gap assessments effectively becomes a shopping list for an opportunistic security manager. Once you start looking at security as a positive side effect, there are at least four main opportunistic strategies available:
1. Attrition: retire systems with known gaps. Network gear with password length / strength limitations? Applications on end-of-life operating systems? Security won’t drive these retirement decisions – but it makes a good tiebreaker.
2. Relocation: consolidate critical systems from environments with low control coverage in areas with better protection capabilities.
3. Extension: broaden the asset base addressed by compliant platforms as an overlay, reducing configuration diversity and streamlining support costs.
4. Outsourcing: When transitioning, fully document procedural controls that were informally implemented, but not consistently.

Visible Ops describes the mechanics of strategies 3 and 4, but in a different context. They’re two instances of a common theme: quality and control make a strong foundation for both security and cost efficiency. Some organizations will be better positioned to take an opportunistic approach in 2009. A lot depends on the manager, but there are other factors that will also play a significant role:
1. Metrics maturity: does the organization have an objective view of control coverage and control strength?
2. Communications: Accountable system owners and project sponsors need to be aware of the current state of protection, and the expected effects (benefits) of proposed changes.
3. Line of sight to business objectives: how does coverage and exposure impact profit and loss?
4. A significant volume of organizational change.
5.Operational flexibility and creativity to modify projects, ensuring that opportunities to improve security are incorporated.
6. Continuous improvement: once a change has been made, capture and replicate it. And just as important: make sure that subsequent change in these environments do not reopen old vulnerabilities.

“Progress, of the best kind, is comparatively slow. Great results cannot be achieved at once; and we must be satisfied to advance in life as we walk, step by step.”
--Samuel Smiles [Scottish author, 1812-1904]

Assessing Enterprise Risk with forensic tools

2009-02-05T20:42:00.009-05:00

There’s no need for FUD (fear, uncertainty and doubt) or guesswork when making the case to management for improving the protection of sensitive information. A serious incident or close call is often the most effective form of persuasion, but it’s not the most desirable. Ironically, forensic investigation tools can be just as useful in preventing incidents as they are in responding to them. But the key is how they’re used. To make the case for change, build on a foundation of reasonably sized data samples, transparent criteria for characterizing results, and focus on the decisions these data are intended to support.

For example: in the 2008 Global State of Information Security Survey, authored by CSO Magazine, CIO Magazine and PriceWaterhouseCoopers, 54% of executives surveyed admitted that they did not have “an accurate inventory of where personal data for employees and customers is collected, transmitted or stored.”

Organizations that don’t normally handle personal data in the course of business might not put the risk of sensitive information loss high on their priority list. Businesses that routinely process high volumes of sensitive information may reach the same conclusion if they feel confident that all systems are consistently protected with highly restricted access. But in either case, without knowing how many copies of these records have been created and shared across end user systems--over the course of several years—a blind decision to either accept or mitigate this risk is likely to be off the mark.

Enter the forensic investigator, often overworked, with relatively little down time to spare. Armed with forensic tools and a basic understanding of what and how much to measure, they can provide a compelling case for decision makers without the expense of a huge data gathering exercise.

With sample results from 30 systems chosen at random, using predefined search strings that are applied the same way to each search, you can get a good feel for the scale of the problem with a reasonable margin of error, where reasonable is defined as: “precise enough to support a decision, while maintaining confidence in your conclusions and credibility with your audience.”

Consider a company of 40,000 employees, with no prior formal assessment of how much sensitive information is on its end user systems. Even a basic estimate would be a huge improvement in understanding the problem. Using output from this online calculator, the table below shows the confidence interval for sample proportions that range from 0 to 6 out of 30, and an estimate of the fraction of the 40,000 that these results most likely represent:

So if it turns out that 5 of the 30 systems from across the company contained sensitive information, you could reasonably conclude that up to 12,000 systems are affected. Is this too much risk? Depending on the threats and current protection capabilities, it could be. It may justify putting more education and enforcement behind a records retention policy, strengthening access controls and account reviews, or implementing a data loss prevention (DLP) solution.

One word of caution: while the initial sample showing 5 out of 30 may make the case for an awareness campaign, a second random test several months later with another small sample may not definitively show that things are improving. If the second sample shows 6 out of 30 (20%) still contain sensitive information, this sample proportion is within the margin of error of the first assessment (9% to 31%). That is, with a population of 40,000 end users, you’re about as likely to get 6 out of 30 as you are to get 5 out of 30 in a random draw. However, if you get zero out of 30 – then you’re much more likely to have achieved a (statistically) significant improvement.

How much more likely? To test against a threshold, use this calculator: http://www.measuringusability.com/onep.php.

Making the most of forensic downtime

2009-01-27T21:17:00.002-05:00

As a computer forensic investigator, at times the caseload can become a bit overwhelming. Sometimes the requests come pouring in; other times the queue will be empty. Looking back through several months of work, you can put together a reasonable estimate of the average arrival rate and average completion rate for forensic investigation requests. Armed with these two pieces of data and some equations from queuing theory, you’ll be able to estimate the amount of cumulative non-investigation time that will likely be available for other tasks over the course of a year.

Naturally much of that down time should be spent “sharpening the saw;” maintaining tools and scripts, etc. But as discussed in the last post, it may also be helpful to leverage those forensic tools and skills to measure risks in the end user environment. Taken periodically, these measurements support the execution of a security strategy by providing the evidence needed to drive changes that will ultimately reduce the frequency and impact of incidents that do occur.

Queuing theory can become complex in a hurry, but there are a few formulas that are easy to use and very helpful if you make a few reasonable simplifying assumptions. For the long version, check out Contemporary Management Science by Anderson, Sweeney and Williams. Or an online excerpt of the relevant chapter is available here.

If you know the average arrival rate of requests, and have a good feel for how long it takes to complete the typical investigation, you can calculate the following:

1. Probability of an empty queue with no requests in process:
1 – (arrival rate / service rate)
2. Average number of pending requests:
((arrival rate) ^ 2) / (service rate * (service rate – arrival rate))
3. Average number of investigations in the systems:
Average number of pending requests + (arrival rate / service rate)
4. Average time a request has to wait before the investigation starts:
Average number of pending requests / arrival rate
5. Average resolution time; from initial request to completed resolution:
Request wait time + (1 / service rate)
6. Probability that a new request has to wait for service:
Arrival rate / service rate
7. The probability of N number of investigations and requests that are in the system at a given point in time:
(arrival rate / service rate)^N * probability of an empty queue

These equations provide a good approximation if the following assumptions hold true:
1. For a given time period, you’re almost always going to get between zero and 2 requests (i.e. 95% likely) and only rarely do you get a bunch of requests (5% chance of 3 or more requests arriving at once).
2. Few service requests will take significantly than the average service time to complete.
3. You’ve got one investigator servicing requests – a “single service channel.”

So, as an example, suppose the average request arrival rate is about 3 cases per month, and an investigator can complete about 4 cases each month. Calculate expected downtime using this proces:

First, convert the monthly numbers to a weekly rate, 3 arrivals per month is a 0.75 weekly arrival rate, and 4 completions per month is a 1.0 service rate. Then, plug and go:

The probability of zero requests in queue is:

1 – (.75 / 1) = 0.25

A 25% chance of having a week with no requests in progress.

So in this “best case” scenario, roughly 25% of an annual 2000 hours worked won’t be directly allocated to investigating live cases; 500 hours. In reality, this estimate is almost certainly too low for a couple of reasons. First, management isn’t likely to over-staff a forensic role; demand will rise to fill that capacity, and inevitably many long-running difficult cases will come up that fall outside the average completion rate by a big margin. And investigators will need to factor in time for script development, system administration, and other tasks.

Assuming that a residual 200 hours (10%) of time remains available throughout the course of the year, this can provide the perfect opportunity to quantify policy compliance against specific goals.

So how much can you do with 200 hours? Turns out, quite a bit.

Four things to do with computer forensic tools (besides forensics)

2009-01-17T23:16:00.001-05:00

When staffing an internal computer forensics capability for an organization, management needs to determine how to balance capacity with demand. At the extremes, you either have a backlog of cases waiting on available investigators, or investigators waiting on requests for support.

Even under the best of circumstances, the investigative caseload won’t follow a regular schedule and some amount of downtime is inevitable. Forensic analysts will need to spend some of that time putting together hash sets, updating scripts, evaluating new tools and doing all of the other arcane tasks that go along with keeping pace with the changing needs of the function. But for an IT risk manager, if you can tap into it, unused forensic capacity is an asset that can be extremely helpful in other contexts as well. Here are just a few examples:

1. Identify the prevalence of sensitive information on end user systems. Because they’re fast, thorough, minimally disruptive and often support remote data capture, forensic tools can help determine the “hit rate” of confidential documents across a randomly selected cross-section of the end user environment.
2. Measure the compliance rate against system usage policies. A scan of Internet usage can show the proportion of systems accessing content that poses a risk to the organization and/or its users. Over time, the amount should decrease if the training and awareness efforts are having an effect.
3. Estimate the amount of data at risk that is not being backed up. Depending on the architecture, this may be a bit more difficult to determine. A comparison of data files created or edited locally that are outside of backup routines will give a good sense of the amount of work lost each time a hard drive crashes, or a laptop is stolen.
4. Identify the level of unauthorized configuration changes. How long is the screen saver timeout supposed to be? What applications or changes are not allowed on a standard system build? This is less of an issue in organizations where IT has locked down the desktop. But where this is a contested issue, actually quantifying the impact can show the best tradeoff between control and usability for a given department or organization.

It goes without saying that nobody likes to be investigated. If the purpose, scope, approach and usage of this information isn’t spelled out in advance (i.e. good-faith random anonymous survey, not a warrantless wiretap) and communicated with the proper level of support, it’ll be the last time you get to try using forensic capabilities to tune security policies and practices.

But let’s face it – all of the critical data in any business either originates or is viewed from an end user system, which is often the least-defended part of the environment. Attackers realize this, and end user systems will always be a popular target. Unless you know what your exposure is, you won’t have a good understanding of what your policies and protection capabilities should be.

Getting privileged accounts under control: spend less time finding, more time fixing

2009-01-10T00:15:00.001-05:00

Are there too many privileged accounts on the business critical systems in your organization? If you suspect so, how would you find out, and how would you energize the leadership in your organization to act? And once you get management endorsement, what number would you set as the maximum allowable number of accounts on a system as a benchmark for non-compliant system owners to shoot for? You'll want all owners to verify compliance, but would a positive response from 50% of those owners justify the call to action?

Perhaps most important of all, after driving this change and moving on to the next problem, will you have the time and resources needed to follow up later in the year and make sure that the problem hasn’t reappeared?

As with any security issue, a small amount of effort should go into finding the problem, and the majority into solving it. To paraphrase Tom Clancy from Into the Storm: “The art of command is to husband that strength for the right time and the right place. You want to conduct your attack [in this example, on the problem] in such a way that you do not spend all your energy before you reach the decisive point." (page 153)

Using a tool like dumpsec for Windows it doesn’t take long to pull group memberships remotely from any given system. But if you’re dealing with hundreds or even thousands of systems, well, that’s a lot of energy to spend before reaching the decisive point, i.e. when system owners start removing excessive accounts.

Intuitively, it makes sense that you wouldn’t want to poll every system in a large environment. Instead, you’d take a sample. But how big of a sample is needed for you – and senior management – to be confident that you know the current state?

Turns out, you (and your boss) can be 90% confident of knowing the median number of privileged accounts on all systems across the server population if you start with a randomly selected sample of 18 systems. And because by definition the median is the middle value, you know that half of the systems are above the sampled value. If this value is too high based on the risk requirements of the environment, you can set a compliance goal such as “reduce the number of privileged accounts on each Windows systems to X by the end of the year.”

To find the median, follow these steps:
1. Pick 18 systems at random across the system population. Dump the list of users with privileged access from each system.
2. Arrange them from fewest to most accounts.
3. Throw out the lowest six and the highest six values, and keep the middle six.

The median number of privileged accounts will be between the low value and the high value of the middle six numbers out of the sample of 18.

For example, if I dumped the local admins group across a set of systems, I might get a result like this. (The “middle six” values are highlighted in bold):

49, 23, 17, 33, 17, 16, 28, 14, 29, 40, 12, 44, 34, 12, 25, 9, 10, 32**

So based on this sample, the median number of privileged accounts across all systems are 90% likely to be between 17 and 29. Granted, due to the architecture certain accounts may be present across all systems. And other factors may help determine if 29 is too high … or 17. But once you decide, you have a baseline value that defines the boundary between acceptable risk and excessive access, which can be communicated across the organization.

Once you’ve gotten buy-in and communicated the requirement, each system owner who wasn’t sampled can compare and confirm that they comply. And in keeping with Clancy’s principle above, only a fraction of your time was spent identifying the problem and communicating it: the rest goes in to helping fix it.

But why does 18 work? Where does the 90% confidence come from, and why throw out the bottom six and top six values?

Doug Hubbard explains it in Chapter 3 of his book “How to Measure Anything.” And while this isn’t a specific example in the text, there are a lot of intriguing applications to information security that he does cover.

Hubbard introduces the idea of finding the median from a small sample as “the rule of five:”

“When you get answers from five people, stop…Take the highest and lowest values in the sample…There is a 93% chance that the median of the entire population … is between those two numbers.” Why? “The chance of randomly picking a value above the median is, by definition, 50% -- the same as a coin flip resulting in “heads.” The chance of randomly selecting five values that happen to be all above the median is like flipping a coin and getting heads five times in a row.(pp. 28-29)”

In other words: 0.5 x 0.5 x 0.5 x 0.5 x 0.5 = .03125 With a random sample of five, there’s only a 3.125% chance of being above the median all five times, and the same 3.125% chance of being below the median all five times. So each time you take five random samples, you’re going to get values on both sides of the median 93% of the time -- the median will very frequently be between your lowest and highest value.

So if five samples gives you 93% confidence, why take 18 samples? From the example above, if you picked the first five at random and stopped, you would have found this:

49, 23, 17, 33, 17

With 93% confidence, you’d be able to assert that applications contain between 17 and 49 privileged accounts. With small samples randomly chosen, high confidence comes at the expense of intervals that are often quite wide. And in this case, it may be too wide to be useful. But picking more samples and tossing out six of the lows and six of the highs retains roughly the same level of confidence in the middle six, with the advantage of a much smaller range between the low and high values. And it’s the smaller range that allows you to understand the state of the environment, and set a credible level of improvement that the organization can meet.

More info I found useful:
How to Measure Anything http://www.howtomeasureanything.com/ Lots of gems on the site; check out the PowerPoint on measuring unobserved intrusions in information systems.

Confidence intervals for a median, with different size samples: http://www.math.unb.ca/~knight/utility/MedInt95.htm

**These numbers were generated by Excel; try it out for yourself. For this example I used the formula =5+(40*RAND()) to give a higher starting value than just "1."

Security career snapshot - January 2, 2009

2009-01-04T22:56:00.002-05:00

Now that the holiday break has ended and everyone is heading back to work, it seems like a good time for information security professionals at every level to take stock of available opportunities and chart a course for the new year.

Is it safer to stay put, or move?

While there's an abundance of forecasts available that predict where 2009 is headed, most are discouraging, few will turn out to be correct, and there doesn’t seem to be a method for sorting between the good and bad estimates that’s any more trustworthy than the estimates themselves.

Instead, I'd argue that it makes more sense to take a second look at the current role, the financial health of the organization, external opportunities, and the stability of the regional and national economy ... and plan according to current actualities.

To cut through that uncertainty, I spent some time over the break going through online job postings to compile a snapshot of security jobs that are currently open and available. I looked at job titles, years of experience required, expected regulatory / compliance background, certifications, and the most active hiring locations. This snapshot won’t show hiring trends for 2009, but my hope is that it’ll at least make a decent starting point for figuring out where the holes in the resume are, and which types of work assignments today may open doors for the next role.

I started with a query of security jobs using an aggregator site, and randomly selected a subset of 200 for analysis. I downloaded each full post directly from the offering website and parsed them locally using some scripts. Below are some of the high points. The margin of error on the survey should be plus or minus 7%. If you want a detailed look at the approach, or the data itself, just drop me a line.

Here’s what I found:

Most common job titles
A bit less than half of all security job openings are for the role of engineer, analyst, or administrator. Managers jobs appear less than 5% of the time, and director level only 1%.

Without more information it's tough to be definitive, but the numbers could imply a couple of things: first, that security organizations may be flattening right now as managers hire more staff; and second, that “individual contributor” roles may have more mobility across organizations than leadership positions. It’s also possible that management roles are filled through other means (internal candidates, etc.) more frequently than staff positions are.

Position title	Number of postings	Percent
Engineer	45	(22.5%)
Analyst	30	(15.0%)
Administrator	14	(7.0%)
Manager	9	(4.5%)
Consultant	9	(4.5%)
Architect	5	(2.5%)
Director	2	(1.0%)

Years of experience expected for each role
Across all positions, five years was the median level of experience required. Only 30% of positions expected two or fewer years of prior relevant work history. One interesting fact was that out of 41 postings with a specific requirement, that requirement was described 21 different ways (e.g. 1 to 4 years, 2 or more, 4-6 years, etc.) It seems the industry has generally standardized on which certifications and skills are expected, but not the level of experience associated with those skills that represent appropriate minimum requirements.

Years of experience required	Number of job postings
0 to 1	3
2 or more	10
3 or more	3
4 or more	2
5 or more	12
6 or more	3
7 or more	2
8 or more	1
9 or more	1
10 or more	5

Most common regulatory / compliance keywords
Not every posting specifically cited regulatory requirements or security framework experience. But for those that did, the following are the most commonly listed:

Regulatory or governance requirement	Number of postings
Federal Information Security Management Act (FISMA)	14
Code of practice for information security management (ISO 17799/2701/2702)	12
Sarbanes-Oxley (SOX 404)	12
Payment Card Industry Data Security Standard (PCI DSS)	12
Health Insurance Portability and Accountability Act (HIPAA)	7
Gramm-Leach-Bliley Act (GLBA)	3

Most common certifications
As of early 2009, candidates with a security certification have an edge over non-certified candidates, but certification is not usually a make-or-break requirement. Less than half (47%) of all security job postings examined had listed certification as a requirement; around 20% described certification as “required” or “highly desirable.”

CISSP is the most commonly listed credential, although it often is provided as one of several examples e.g. “Professional security certification such as CISSP, CISM, GIAC, CCNA, CCSP, CCNP, MCSE, Security+, Network+.”

Security Certification (n=94)	Number of postings	Percent
Certified Information Systems Security Professional (CISSP)	48	(52.7%)
Other (Cisco, etc.)	12	(13.2%)
Certified Information Security Manager (CISM)	11	(12.1%)
Certified Information Systems Auditor (CISA)	10	(11.0%)
SANS Global Information Assurance Certification (GIAC)	10	(11.0%)

Most active hiring locations
Finally, the top ten states (and Washington D.C.) listed by frequency of job posting:

State	Number of postings (n=200)
California	32
Virginia	32
Maryland	24
Washington D.C.	17
Texas	11
Massachusetts	11
New York	8
New Jersey	6
Illinois	6
Pennsylvania	4

So if you're a Security Engineer with a CISSP and five or more years experience in your current role, with a strong background in FISMA, SOX and ISO 17799 who lives in the Washington D.C. area ... relax ... even in the midst of this economic mess, it looks like the world is still beating a path to your door. For the rest of us, though, we probably have some work to do.

Best of luck to everyone trying to improve their skills and find the right organizational fit in 2009. I hope this was helpful; if you have questions about specific skills, opportunities or regions not listed in this overview that you haven't been able to ferret out using the job search engines - let me know and I'll help if I can.

Twitter Security

2009-01-01T19:44:00.001-05:00

A few weeks ago I decided to give twitter a try, following some friends and colleagues scattered throughout the Midwest. Like sets of data points on a time-series plot, it’s amazing to see patterns develop 140 characters at a time.

As with most things that are new, cool or interesting, I wondered if there was a practical way to translate the things that make twitter ‘work’ into something useful at the office.

A few months ago I put together a one page summary of key metrics my project team had gathered and sent it to a number of stakeholders throughout the organization. The response was decent, but not as strong as I’d hoped. As nice as it would be for facts to flow like electrical current throughout an organization, powering change, I needed to put a lot of follow-on effort into making sure the themes of the report registered with decision makers.

As an experiment in communications, I wanted to see if the size and frequency of the message could make the change process any easier. I decided to “twitter” a single metric from a follow on project to see if I could make a bigger impact by dialing down the content but increasing the frequency. To start, I sent a four line Email that put the metric in context along with a recommended organizational response. So far, the hit rate is up.

Not every security metric or message reduces down to one or two sentences. But for those that do, sharing status, concerns and recommendations in a “blackberry friendly” format seems to increase the likelihood that it’ll get read, and re-sent, gaining momentum throughout the organization.

Risk metrics should drive security, without dictating it

2008-12-05T23:26:00.001-05:00

How precise do risk measures need to be in order to be of value to an organization? Is it necessary to calculate an annual loss expectancy (ALE) for each type of information security risk in order to justify security decisions? For better or worse, most organizations have settled on a security budget that is a fraction of the overall IT budget, which in mature companies remains a steady proportion of annual revenue.

Given the challenge of putting together credible loss numbers across the range of identified threats against the organization, it doesn’t make much sense to try to optimize budgets purely against a risk forecast. Instead, security is best treated as a constraint in decisions to optimize revenue, operating costs, profit or other key measures. Protection for critical assets needs to cross an “adequacy” threshold. Conversely, when changes stress or stretch protection capabilities to the point of exposing critical assets to threats, the information security function begins raising the case for change.

So if risk management is more about being on the right side of a threshold, as is literally specified in the EU Privacy Directive / US Safe Harbor guidance, then precision is not nearly as important as confidence. Polling organizations such as Gallup provide a margin of error of 2% because the difference between winning and losing a contest is often very close. But in contrast, safety and security based decisions i.e. “we need to act, now” can become clear with margins of 10-15% or more. As an example, if the brakes on the family minivan squeak and start slipping, its time to get them replaced.

With the help of a few reasonable, simplifying assumptions, it is possible to make trustworthy risk-based decisions based on just two critical metrics: security control coverage, and information asset exposure.

These assumptions are as follows:
1. The impact of security incidents are best characterized in financial terms, i.e. information security incidents have the potential to affect current and/or future costs, and current and/or future sales. (Health and safety critical environments are an exception that should be treated differently.)
2. The value that IT security provides to an organization comes from decreasing the frequency and severity of security incidents by:
a. Preventing incidents from occurring whenever possible
b. Detecting relevant events where and when they occur, and mobilizing an effective response to minimize the damage and restore normal operation as quickly as possible.
3. Security control coverage is a leading indicator of risk to information systems, business processes and data.

Based on these assumptions, two key metrics for decision makers can persuasively frame the security “threshold” decision without requiring an unreasonable level of precision:
1. Information asset exposure: a measure of the relative contribution of that asset to the current and future revenue of the organization.
2. Security control coverage: a measure of the number and type of industry best practice recommendations implemented independently as layers of protection on each asset and process owned or used by the organization to serve its customers and stakeholders.

As an example, consider a company with $120 million in annual sales, $150 million in assets, 500 employees, tens of thousands of current and former customers, Market capitalization of $110 million, and an operating margin of about 18%. Based on these estimates, here’s a quick back-of-the-envelope estimate of the scale involved in information protection decisions:

$120 million in annual sales works out to about $330,000 per day or between $10,000 and $25,000 per hour. So to this company, the loss of several hours of downtime from a key system or systems, plus incident handling costs and lost worker time, etc. can run between $150,000 to $200,000.

According to a 2006 report from the Association of Certified Fraud Examiners, the median fraud loss for asset misappropriation (skimming, payroll fraud or fraudulent invoicing) is $150,000.

Forrester estimates that a privacy breach cost between $90 and $305 per record to address; the Ponemon Institute provides a similar number. Based on those estimates, losing personal information on 5,000 customers would result in costs of between $500,000 and $1,000,000.

Asset exposure, described as a fraction of revenue, is a linear function: the longer the downtime, or more records exposed, the higher the cost. But as described in an earlier post, security is not linear. In a population of systems connected by trust relationships, a failure in server A will lead to a compromise of server B, C, D and on down the line.

Earlier this year, Verizon published a Data Breach Investigation Report based on follow-up on over 500 cases in a four year period. While there’s much to take away from the results, two measures stand out in terms of shaping risk decisions: 85% of identified breaches were the result of opportunistic attacks, and 87% were considered avoidable through reasonable controls. That is; security control coverage provides a strong leading indicator as to the likelihood of experiencing a security breach.

So, given an operating margin of 18% (roughly average for the S&P 500) it could take $5 to $6 of additional revenue to make up for each dollar lost due to a security incident.

Against these measures, determining levels of acceptable risk becomes a much more straightforward exercise without the need for precise risk forecasting. Instead, it becomes a question of risk tolerance: will the extensions to the customer-facing systems generate enough new revenue to justify exposure to some of the scenarios listed above?

Metrics can frame the issues, but ultimately the business has to drive it.

Can you afford bad security?

2008-10-26T23:45:00.001-04:00

Within the current economic turmoil and uncertainty its becoming clear that the global economy is slowing, pressuring organizations of all sizes to compete more intensely for revenue while taking an even harder look at reigning in costs. These concerns cascade through the overall project portfolio to IT and security in the form of two very basic questions: What do we need? What can we afford?

In a company fighting for its survival, talking to management about improvements in information security may seem as relevant as changing the locks on a burning building. Naturally, fire is an immediate threat to an asset and its contents, but over a longer time horizon so is the risk of theft … or foreclosure.

Bottom line, some organizations can afford bad security. Others can’t. In some situations, immediate survival concerns will temporarily trump long term protection goals. But as the market meltdown in the United States in 2008 is showing us, it is just as plausible to see that relaxing key control requirements for short term profitability puts entire companies, and even markets, at risk.

The only way to get this right is to view security in light of the survival needs of the firm, and measure it to the same standard of every other investment. In the past, information security hasn’t been held to this standard, mostly due to measurement challenges. Hopefully, for the good of the profession as well as the entities we protect, those days are over and we can take up the challenge of proving our value more accurately and more persuasively than we have in the past.

“What the CEO wants you to know”
In 2001 Ram Charan wrote a gem of a book called “What the CEO Wants You to Know,” distilling business acumen into the effective management of five core measures of business health: cash, margin, velocity, growth and customers. Charan: “Cash generation is the difference between all the cash that flows into the business and all the cash that flows out of the business in a given time period …it is a company’s oxygen supply” pp.30-31

Margin is the difference between the price and cost of goods sold, while velocity is the rate at which those goods are sold. Growth includes expansion (more sales) and extension (new markets) while the Customers category represents how well the organization responds and aligns with market demands.

Naturally, some of these needs can become tactical and immediate while others are more strategic in nature. But all must be functioning effectively for a company to succeed, and any threat to these measures ultimately threatens the health of the company.

“What the CISO wants you to know”
If the five factors above represent the keys to a successful business, then good security is important to a company only to the extent that it affects those factors. If there’s no impact on customers, growth, etc. then there’s no value to security. Or, as your CFO probably read in school:

“A potential project creates value for the firm’s shareholders if and only if the net present value of the incremental cash flows from the project is positive.” [Brigham and Ehrhardt, Financial Management: Theory and Practice, 11th Edition, p.389]

Security issues expressed in terms of cash, margin, velocity, growth and customers, and measured in terms of net impact to the company have the best chance of resonating with decision makers.

Gordon and Loeb propose a three dimensional Cybersecurity cost grid as a tool for building that business case. The authors suggest failures of confidentiality, integrity and availability are to be analyzed in terms of direct and indirect costs, as well as explicit and implicit costs.

For me, the distinction between indirect and implicit didn’t seem as compelling as the difference between a net positive or negative effect on security, so I started segmenting the effect of security across Charan’s five categories this way:

Of course, measuring it is the real trick. But there are quite a few resources available to help with that...

Developing an information security strategy using attack graphs

2008-07-30T00:24:00.001-04:00

In medium and large organizations, the process of developing and implementing an Information Security Management System (ISMS) as specified in ISO 27001 can take substantial time and resources. But for many organizations, a long-term slow developing program may not be practical.

In this setting it’s important to focus on making existing security data actionable, rather than spending weeks or months generating the information needed to prioritize enterprise risks.

Typically attack graphs aren't used in this context; they’re more often applied as a theoretical threat modeling tool. But because they show relationships between assets, exposures, vulnerabilities and expected threats, they’re perfect for the sort of forced ranking prioritization that a low-overhead ISMS requires.

So what is an attack graph, and how is it useful?

In a nutshell, an attack graph is a map of information assets, infrastructure, applications and systems connected by exploitable vulnerabilities. An attacker who wants to gain access to an information asset will seek the lowest “cost” path through the environment, where cost is measurable in terms of time, effort, or risk of detection or prosecution.

Some vendor tools automate the mapping of network assets, vulnerabilities and exposures between all systems on a network. But the end result is typically a graph with hundreds of systems and thousands of connections – even for relatively small networks.

This generates an enormous amount of data, which must then be reduced to a critical, actionable set. It also tends to bias the analyses towards technical vulnerabilities – while for an insider threat the process and compliance gaps may be more significant.

Instead, the illustration below shows an abstracted attack graph that represents nodes as populations of vulnerable systems, instead of each individual system:

A distinction between nodes is only necessary to the extent that it represents a trade-off from the perspective of the network security manager, and influences the potential effectiveness of an attacker.

This view approaches the environment from a threat perspective. An attacker external to the organization who is going after the customer database doesn’t need to compromise multiple end user devices; just one of them. Once inside the network, they can then use that system to target the database directly (query via user account) or indirectly (compromise the server hosting the database application.)

If each node represents an accountable system owner, or platform manager, and each line between nodes represents an exploitable exposure, the overall view provides a very straightforward model to represent trade-offs that each team can use to determine critical “upstream” and “downstream” exposures. Risk acceptance or mitigation decisions here are as much driven by context as they are by vulnerability ratings – which is exactly the point; a risk should be acceptable to an organization only if the impacted downstream teams are not exposed as a result. The owner of a vulnerable system should not be allowed to accept a risk in isolation on the basis that such a system “doesn’t contain anything important.”

Without much coaching, even to non-technical business managers a few principles and conclusions should quickly become apparent:
Perimeter security matters. Putting an enforced, monitored boundary between the attacker and the assets to be protected improves security.
Defense in depth matters. To the extent that an attacker must compromise several systems without being detected, it greatly reduces their chance of success. For example; assume a 50% chance of success for each of the following three attacks: first to compromise an end user device, then a trusted server in the data center, and finally security measures on the system hosting the database. The probability of success is 0.5 * 0.5 * 0.5 = 12.5%
Least-privilege access matters. Any steps an organization can take to “break” the connections between systems in an environment will improve security by giving an attacker fewer paths to reach a critical asset.
Linear investments in security won't produce linear results. Patching 8 out of 10 servers doesn’t make a company 80% secure. If an attacker can scan for the two vulnerable systems without a high risk of being detected, the cost of attacking the environment hasn’t increased. The asset remains as vulnerable as if only 1 or 2 servers were patched.

Once the planning process has prioritized the key risks, it may be time to graduate to a more formal, more granular view of the network. There are a number of open source and proprietary approaches to visualizing an entire environment and driving remediation down to each specific configuration vulnerability. But if you’ve won over management with a high level model that allows them to participate in the process and drive decision making, the hard part is done.

Risk Management: accept, transfer, avoid, mitigate risk ... or none of the above?

2008-07-08T23:34:00.001-04:00

When dealing with information security risks, typically the range of available options are to accept the risk, transfer it, avoid it, or mitigate it by implementing security controls. But these aren't the only options, and in some circumstances there's actually a better choice: transform the risk.

A certain large pharmaceutical organization--which I will not specifically mention--for years manufactured an over-the-counter decongestant which contained an ingredient that criminals discovered could be used to illegally produce methamphetamine. The social and public health impacts of this misuse were so significant that it presented a risk that the company needed to address.

For this particular risk it would harm patients to abandon the product, and it wasn't feasible to transfer or mitigate the risks directly. So instead, the company took a different route: it made the product unusable to criminals by changing the active ingredient and was still able to offer it over the counter to its customers.

From an information security perspective, the same principle applies: risk to an information asset is determined by the seriousness of impact and the likelihood of that impact occuring. And likelihood in turn is driven by the value of that asset to the threats which are targeting it. So any organization that can reduce the value of its assets to attackers, without lowering the value to its customers, can also reduce its risks.

Some examples:

De-identification of Protected Health Information (PHI) as per the HIPAA Privacy Rule.
Identity Theft. In countries where national IDs aren't used as an all-purpose identifier, rates of identity theft are much lower than in the United States.

SPREAD OUT!

2008-06-29T23:49:00.001-04:00

If you’ve ever seen rec-level youth soccer led by volunteer coaches I’m sure you’re familiar with this scene: a knot of kids surrounding the ball in a swarm, kicking furiously with parents cheering on. Eventually one or both of the coaches shouts “spread out!!” Usually it’s at the same moment that the ball escapes the swarm, spurring a mad dash to form a new swarm…

After a few years of this, as a youth coach I finally promised myself I’d never use that phrase again. Besides the fact that it never works, there are a couple of other issues with it:

It’s an instruction without accountability: no player can accomplish it on her own.

You can do exactly what is asked without having any impact on helping your team win. In fact, during one of my games it went the other way -- I’ve seen our defense part like the red sea and open shooting lanes for the other team. Ouch!

Instead, I prefer a different phrase that’s just as short and to the point:

GET OPEN!

Sure, it’s still an instruction delivered to the whole team, but it enables accountability in a positive sense. You can identify and praise the kids who do it, and follow up with those that didn’t hear/understand what to do. And when kids recognize and respond, it helps the team get more shots and who knows … even score on occasion. As an added bonus I started counting the number of passes made by the team during each quarter. (Hawthorne was right … measurement motivates!)

Connecting this back to information security, the key takeaway is that it’s possible even with distributed virtual teams to develop a capacity to adjust to unforeseen obstacles without building in excessive communication and coordination overhead. But efficient teams aren’t necessarily the result of teams with a high level of security domain knowledge (CISSP, GIAC, etc.) Sure, those skills are as critical as the soccer equivalent of dribbling and shooting -- but good things really start to happen when security processes collectively orient themselves around meaningful measures.

Clear goals – decomposed into individually achievable contributions – measured with simple, easy to gather data - and reported internally / externally to both team members and stakeholders are the key to preventing knots and swarms.

Information Security Requires Changing Minds

2008-02-02T11:59:00.001-05:00

It is a well documented fact that for most organizations, compliance with information security policies is a largely voluntary activity. The only way to consistently advance security is through the active support of the groups that the security organization is responsible to protect.

Everyone recognizes the need for "buy-in," but few articulate where to get it, and more importantly, how to sustain it. This is what makes Howard Gardner's book, Changing Minds, so essential for policy, governance and security practitioners. Many authors have taken on aspects of this subject, from How to Win Friends and Influence People [Carnegie] to Execution: The Discipline of Getting Things Done, [Bossidy and Charan]. But typically, they look at the techniques of successful change instead of the fundamental elements these techniques address. Bossidy and Charan argue "You cannot have an execution culture without robust dialogue...robust dialogue starts when people go in with open minds...[and]...ends with closure...people agree about what each person has to do and when." [pp.102-103] If you start with an open minded group, good for you. But what if they're not open minded, and they don't report to you?

Gardner, who is a psychologist - not a CEO or CSO, doesn't presuppose a particular starting point. Instead, he identifies the contents of the mind, the forms that this content can take, the levers which influence mind change, and the differences across various types of audiences where this change occurs.

As an example, several years ago I had a role that depended on a strong working partnership with a department that was in the process of being eliminated from the company. This team had a number of operational responsibilities that made it a likely target for attempts to access sensitive company information, and seemed highly vulnerable due to morale and turnover issues. Thankfully, the team had exceptional management and was highly professional, and was willing to look at its role beyond the soon to be ending tasks. Through a combination of education about the threats, specific training to combat likely forms of attack, and a modest reward system for successfully responding to suspicious events, I supported the process of helping the group change the view of its role in the company, add new skills, and make a significant impact during a critical transition period.

At the time I wasn't really aware of all of the "moving parts" that made that story a success. But Changing Minds provides the tools for analyzing, and (hopefully) duplicating such outcomes. In this situation the team represented a relatively uniform population with a common set of concepts and skills, but with a rather discouraging story, i.e. "our group is about to be phased out." Through a combination of reason and research with a new story that resonated, supported with training and rewards, the low resistance of the group was overcome and the team executed their new skills very effectively.

Gardner identifies six audiences for mind changing, four categories of mental "content," nine forms this content can take, and seven levers that affect the outcome.

Starting with the audiences, ranging from addressing a nation to just one individual, or even oneself, Changing Minds gives a rich set of case studies for each:
1. Leading a Diverse Population. Changing the minds of a nation, examined through the experience of Margaret Thatcher.
2. Leading an Institution. Gardner looks at James O. Freedman's experience at Dartmouth. A reading of "Building Block Two: Creating the Framework for Cultural Change" in Execution provides intriguing parallels in a corporate context.
3. Changing minds indirectly. The role of science, scholarship and the arts.
4. Mind changing in a formal setting. This goes beyond the one-way transfer of information and assumes an interactive process of discovery and response: "consider...entrenched views...and the ways in which these views might profitably be reformulated..." [p. 145]
5. Mind changing up close. One on one.
6. Changing One's Own Mind.

Changing Minds lists four specific categories of content that is the focus of change efforts: concepts, stories, theories and skills.

Concepts are the most elementary building block; for information security, defense in depth, principle of least privilege, and “need-to-know” would represent fundamental concepts.

Stories are another fundamental category. Thatcher’s story was straightforward, easy to understand and resonated with her audience of the time: “Britain has lost its way.” When discussing levers of change, stories and their “counter-stories” form a critical battleground where change agents directly engage resistances.

Theories represent relatively formal explanations of processes; X causes Y. They can be based on facts, true or false assumptions, and personal or educational experiences. Again, in the security realm, theories could include the view that: ‘most successful attackers are: insiders / outsiders … most attacks are purely technical / involve some degree of social engineering…’

The last category of content is skills. Skills are made up of the practices of which an individual is capable. Gardner argues that when a practitioner fundamentally changes their approach to a task, this represents a significant change in mind.

He further points out that while all minds share similar types of content, this content can differ significantly in form. Drawing on the theory of multiple intelligences, these forms are described as either object-based or symbol based, with a key takeaway being that people differ in their ability and willingness to absorb content based on its form of presentation.

Mind changing is most effective when resistances are low, and the other six levers, each beginning with re-, work in concert. They are: reason, research, resonance, representational redescriptions, real world events, resources & rewards.

Research provides the "proof" that the current concepts, stories or theories are outdated and need to be replaced, while reason presents this information via logical arguments. Along with real world events, these levers affect the "potency" of a leader's message. But its not just the potency that counts -- its also how well that message is absorbed by its audience.

Resonance describes the persuasiveness of the new story, theory or concept. Ideas which resonate “feel right” to the recipient. Finding and applying the resonance can be challenging, however, as it involves not only the content of the message, but also its timing, and how well it harmonizes with the existing perspective of the audience and the persona of the messenger. On this last point Gardner contrasts Bill Clinton's talent for getting in tune with his audience to neutralize opposition, while Newt Gingrich seemed to consistently stimulate it.

And while a leader may be working with a single message, that message best resonates when it is offered and considered in many different forms through a variety of representational redescriptions. At times these redescriptions are provided by the leader, but in other cases a leader can provide resources to their audience, along with rewards and incentives for the group to develop and "try out" the idea on their own.

These levers work positively to bring about a change, but they must overcome resistances. These resistances are characterized as the "counter-story;” existing representations which a leader hopes to convince their audience to supplant. Resistances must be met with resonating integrity, in an ethical approach. “One can – and must – go through an exercise of deep and pervasive mental surgery with respect to every entrenched view: define it, understand the reasons for its provenance, point out its weaknesses, and then develop multiple ways of undermining that view and bolstering a more constructive one. In other words, search for the resonance, and stamp out the resistance.” [p.145]

Affecting an organization requires reason, and resonance – but having the right story is only the starting point. Meaningful change takes time. “New ideas do not travel easily, and it is hard for them to take hold. Because we cannot know in advance which formats will prove effective in communicating a new message, we are well advised to use several alternative formats…We need to monitor the words and actions of a leader’s constituents to glean how ideas have been translated and internalized…until we ‘get it right’--or at least until the next change in context challenges current representations and calls for yet another take on the situation at hand.” [p.102]

In conclusion, it may seem discouragingly difficult to effect change. But rather than seeking for the perfect message, or the perfect presentation, it may be better to for a leader to engage an audience--resistances and all--early and often, and find many ways to bring those ideas forward. It may also help to give an audience the tools needed to rework that message into a variety of forms and find the ones that fit. The more active a leader is on this front, the more likely that they'll be ready to capitalize on real world events as they unfold.

Information security strategy development tools

2007-07-25T20:22:00.001-04:00

In keeping with the long-held tradition of Information Security professionals appropriating tools from other disciplines (Schneier: attack trees, Open Group: security design patterns, Jaquith: Balanced Scorecard for security) I'll offer that as a starting point, "SWOT" is one of the best lightweight strategy development tools available.

SWOT stands for Strengths, Weaknessess, Opportunities and Threats. It is an analysis framework used in many different business disciplines, but marketing seems to make the best use of it.

Strategy adds value by clarifying the scope and role of security in the organization, improves effectiveness, and enables a coherent response to changes in the business and threat environment.

So, to be useful, a security strategy development tool ought to be:

1. Easy to use - so that the facilitator, subject matter experts and stakeholders are up and running quickly without fighting with the idiosyncracies and limitations of the tool.

2. Low resource requirements - so that it can be repeated as necessary, instead of as an annual off-site exercise. This will enable an effective strategy to adapt as organizational needs change.

3. Good fit for the problem - analysis results should generate action, not just reports. And preferably, those actions should add value beyond the obvious.

SWOT Approach

As described by Kerin and Peterson, SWOT analysis is "a formal framework for identifying and framing organizational growth opportunities." Naturally security is concerned about protection rather than growth, but the model still fits. Its easy to understand, apply, and cuts through the noise of threats, vulnerabilities, budgets and line-of-business requests to identify high value approaches to security management.

Here's an example template (borrowing the "TOWS" terminology from Dr. John Nugent's Managerial Forensics class:)

For the "Strengths" section of SWOT, the facilitator should start with a list of security offerings and capabilities. What does the security organization do? Then split the list into things done well, and, for "Weaknesses," the areas that need improvement.

Looking at external factors, what are the goals of the overall organization? What must the security team provide or prevent in order to be successful? These items represent the "Opportunities" for security.

Threats are external to the team; they are not weaknesses. Independent of anything the team does, what events, situations or actions of others may prevent the organization from being successful?

In this context, the normal security definition of "threat" is really a SWOT "Opportunity." Without security threats, there is no reason for the security team. SWOT threats are things like budget cuts, organizational restructuring or other actions that can interfere with plans to execute against available opportunities.

While it may start with a listing of functions or goals, SWOT is more than just lists. The results need to be discussed and debated. Bossidy and Charan describe it as "the last chance to get things right before the plan faces the ultimate test of the real world." Before you implement NAC, will your organization support it? By bringing together needs, capabilities and external risk factors, a reasonably thorough SWOT will draw out the non-obvious dependencies and risks that need to be addressed as part of an implementation. And because its such a well known business tool, it enables business-side stakeholders to participate. Getting buy-in at that early stage is never a bad idea.

Corporate Strategy, Business Strategy, and Information Security Strategy

2007-07-11T20:42:00.001-04:00

In Contemporary Strategy Analysis, Robert Grant describes successful strategy as the combination of "clear goals, understanding the competitive environment, resource appraisal, and effective implementation."

He also makes a strong case that strategy is not a plan: "Strategy is not a detailed plan or program of instructions; it is a unifying theme that gives coherence and direction to the actions and decisions of an individual or organization."

Corporate Strategy looks at industry attractiveness and asks "what industries should we be in?" while Business Strategy aims for competetive advantage by looking at "How should we compete?"

If you have an Information Security Strategy, what is it, and how does it relate to your corporate and business strategy?

To a large extent it depends on the view of how strategy is made and how to characterize it: as intended strategy (authored by management) realized strategy (actual implementation) or emergent strategy: "decisions that emerge from the complex processes in which individual managers interpret the intended strategy and adapt..."

Some published examples of Information Security Strategy fall in the intended category, such as:

Comprehensive Strategy on Information Security: Executive Summary (Japan)
"To enhance competitiveness and national security for Japan: Building economic and cultural power through realization of world-class "highly reliable society"
NATIONAL INFORMATION SECURITY STRATEGY PROPOSAL (Finland)
"Finland will be an information-secure society that everyone can trust in and that enables all parties to manage and communicate information safely."
Tulane Comprehensive Information Security Program (Tulane University, US) "To secure Tulane University Information and Information systems from cyber attacks while complying with legal, statutory, contractual, and internally developed requirements."

Interestingly, the State of Colorado has an Information Security Strategy that explicitly recognizes the resource appraisal consideration and the emergent nature of security strategy:

"The State of Colorado does not have integrated cross departmental information security architecture. As in most large governmental environments information technology has been deployed in a hap hazard [sic] as funding was available. The integrated enterprise approach has been an after thought. This methodology results in many disparate information technology systems..." And: "This document outlines the Information Security Strategy for the State of Colorado. It is an iterative process that will continue to change as we move forward."

So much for 'building security in' from the outset. But isn't that the case for every organization?

In Competetive Strategy Michael Porter describes three generic strategies for achieving competitive advantage: cost leadership, differentiation, and focus.

Are there generic strategies for Information Security? In terms of intended strategy, probably so but for the good of our industry the emergent strategy differs from these approaches. They deserve better titles, but for now I think of them as:

Bodyguard Security - identify the goals of the organization, and map security activities against each of these goals
Martial Law Security - implement industry best practices of defense in depth, least privilege. Make exceptions difficult to approve, to discourage non-standard configurations.
Lifeguard Security - minimize restrictions on user activity. Monitor the environment in real time, and move swiftly to respond to detected problems.

Does your organization explicitly take a different approach?

2007-07-04T01:00:00.000-04:00

GETTING STARTED

On Day One of my Strategic Management class at JMU our professor handed out a table showing the evolution of corporate strategy in the United States from the 1950s through today.

To me the most interesting feature was how closely the entries tracked competitive pressures and innovations in strategic approaches. Business strategy evolved to help organizations become more valuable, even as they faced stronger, more disruptive competitors.

So how does this relate to Information Security?

Competition naturally drives organizations to think and act more strategically, and the most successful organizations have known their capabilities and opportunities, articulated a realistic plan for achieving success, and energized their staff to execute it.

Information Security management faces similar pressures, but also has the ability to apply the same approach to success. Based on current trends I think a strong case can be made that every organization needs an Information Security Strategy, for the following three reasons:
- We don't have unlimited resources.
- Effective risk reduction requires an awareness and response to dynamic threats that actively work to circumvent or overcome deployed controls.
- The natural tendency of security products and processes, absent customer involvement in their design, is to hinder the effectiveness of the organizations we are trying to protect.

In short, a security strategy makes an organization explicitly resource aware, threat aware, and customer aware.