In my experience over the years, calculating security value and providing consulting to others doing the same, I have noticed the same 4 questions tend to rear their ugly heads. Requests by senior managers, finance analyst, business value analysts, project and program managers all fall into one or more of these types of inquires. And when I say they are ugly, oh they are.

In most cases the parties seeking information are in some phase of the decision cycle:

Should I spend money on security? - This is a business decision based upon compelling drivers, usually loss of some kind, including non-compliance to regulatory requirements (which could send a C-level officer to spend an extended vacation at Club Fed) or risk of a catastrophic blunder sufficient to crater the organization. The business aspects must include how many coins are in the coffers, amount of loss (both realized and unrealized) on the table, and if money could be better spent elsewhere (opportunity costs)

How much should I spend? - A value decision considering what the organization is willing to accept in losses, what can be spent on security, and the amount of loss which could be prevented. Optimally, there exists a point at any given time which management is willing to spend a certain amount on security, which prevents enough loss to bring the residual losses to an acceptable level.

What should I spend it on? - An exercise in comparative analysis of available options which drives down overall costs, while increasing the losses prevented, and maintaining the optimal level of security and residual loss.

On to the ugly questions (feel free to share your experiences):

Ugly Question #1: How do I select the security product/program with the best value?

This is typically asked by senior management or by a product/service manager seeking to identify the best solution among a pool of several competing initiatives. As an example, they might be looking to purchase an Intrusion Prevention System (IPS) and looking for the best of breed. Conversely they may be looking to establish or improve a security capability (example: data protection) and trying to determine the best product among multiple solutions (encryption, IPS, document tracking, data destruction policy, etc.) across multiple vendors.

The challenge is to be able to compare which solution will best achieve the optimal level of security. This is a function of security cost, losses prevented (effectiveness), and acceptance of residual loss. To simply go for the cheapest, most effective, or fastest to adopt is most often than not, the wrong long term answer. (..and security is a long term proposition)

Ugly Question #2: What is the value of this security product/program?

This is asked by management and project managers when a solution is in the proposal stage, by the sustaining operation folks once it has been implemented into the environment, and by management during times when the organization is looking for opportunities to cut costs. As value is a dynamic concept, it can radically change based upon business, legal, and social aspects as well as the normal fluctuations in the threat landscape. First step here is to identify what types of value was intended to be provided and the appropriate metric to measure those aspects.

As an example, management may be seeking to protect the organization's image and liability from the loss of Personal Identifiable Information (PII) through the implementation of a hard drive encryption program for company laptops. The metrics may be as simple as determining the saturation of the program and if encryption is sufficient to protect from liability in the geographies they do business in. In this manner you can estimate the amount of coverage for which liability and image concerns are abated.

You might think, wait, that is not a dollar figure! Where is the value? Well, in this case, management may be looking for the establishment of a capability. Either we are protected from this threat or we are not protected. The same stratagem could be compliance with HIPPA or other regulations. To attempt to quantify a dollar figure in this example would be overkill and may detract from what is intended. Realistically, a dollar savings cannot reasonably be calculated now matter what kind of magic hat you possess. I have seen some attempts, by people with the best intent, to do this very calculation. But not knowing if or when or to what extent a loss may occur, nor to be able to truly measure the potential losses due to the large number of unknown variables which have an astronomical range of potential damage, these assessments are pure folly (but really fun to poke holes in). Half the battle in measuring the value of security is to know what limitations exist regarding the granularity of what can realistically be measured and validated.

Ugly Question #3: How do I compare the value between security and non-security initiatives?

This one bites. Really. It is almost impossible to do, anyone can challenge the results, and if you get this wrong everybody hates you. This comes up when senior management must decide where to spend hard earned budgetary dollars. It becomes an "us versus them" battle between security and some other group. Each party wants the money to spend and the infighting can get downright dirty. So what is a manager to do? Just tap your friendly neighborhood security analyst to calculate the value (just as long as it is not me), then compare against the value of the non-security program. Easy, right?

I wish. Security programs rarely have the benefit of real dollar justification attached. Unless you are in the security products/service industry, security does not generate revenue, it is just overhead. More on that in a different blog. Non-security programs have the edge here. A marketing program may generate XX dollars, an operations efficiency program may save YY downtime or be able to cut ZZ heads from the budget. These strong arguments bark loudly to management. Security value will retort with a whimper, maybe a risk reduction of xx% or at best a loss prevented of yy dollars. Did I mention even calculating such values takes more time, with more assumptions, and can't, in most cases, ever be validated as compared to the non-security programs? Pure ugliness. Alas it is not impossible. I have seen the fight won (ie. management given accurate and comparable data to make the best decision), but be beware, the deck is stacked against security.

Ugly Question #4: How much should my organization spend on security?

This is the big-daddy of questions, posed by senior management or if the organization is large enough, by a divisional head. Although I plan on discussing this in greater detail in another blog and whitepaper, the path to take is to identify the optimal level of security.

Every organization is different with ever changing business needs and drivers. What one company desires from its security program and is willing to spend will differ from its neighbor. The willingness to accept different levels of loss also vary greatly. But there are common perspectives which are shared to a great degree by all organizations. As an example, in most instances we don't want to spend more on security than we get in return (typically in the loss prevented).

If we look at an organization individually and imagine an increasing line of spending, for each point on that line we have an amount of residual loss which will be experienced (in theory, trending down to some degree as the security spending goes up) and therefore an amount of loss prevented for each point as well. At a strategic level, these three lines give us what is needed to answer this ugly question.

How much should be spent? Optimally, an organization should spend the amount of money on security which prevents enough loss to bring the residual losses to an acceptable level. What I have found, is the target exists somewhere between the low point of a diminishing rate of return and the high crossover point where the spending exceeds the loss prevented. Only management can decide exactly where the sweet-spot exists for any given moment.

Now your turn. What ugly question has been thrown in your direction?

Practical Aspects of Measuring Security

A few of our top security analysts & strategists got together to share with Podtech how Intel's own IT department tackles security challenges. Did you know that Intel's IT organization developed a "war gaming" program to model and predict bad guy behaviors? Do you have increased challenges around securing your network perimeter due to the integration of more mobile devices? Have you developed a way to actually measure the business value of IT's security efforts? I invite you to learn how Intel's IT organization addresses these security topics and more. Check out our first video introducing the series on security, then hop over to Managing the Effort to Measure Security blog by Matthew Rosenquist. More coming soon...

In my blog inside Intel I'm exploring some ideas for social media implementation, and would like to throw them out here to the IT Community for input. Our social media implementation is a bit patchwork at the moment, so I'm looking at ways to help fill it in. In this case, the idea is to open up our current method of corporate employee communication.

Currently, our intranet is a fairly static site. Most news and articles are just fixed web posts, and what I've been exploring is adding an open discussion area on the end of every article published on any intranet site. Then any reader who has something to ask or add on a topic can contribute. It may be a simple link to related material, or it may be detailed thoughts on the topic. There may be no comments for an FYI about a local road closure, or a lengthy exchange about some of our product strategies. If the topic draws out a reader who cares enough to add thoughts, the net result of those inputs creates material that is more valuable than the post alone. At worst it shows what people think of a topic, and at best there could be ideas, information, and discourse that adds a lot more than the original post.

The second piece of this change would be to allow employees to directly submit their own articles and material, similar to something you might see on del.icio.us or Digg. Those sites are very different, but together they enable every single employee to quickly share content they find valuable, and provide a mechanism for the best of that content to rise up for all to see. It's a staggering difference from the tops-down, management sanitized communication we get today. It leverages the incredible knowledge and brainpower already present across Intel, and starts building a valuable repository of information that no centralized, "tops down" organized project could accomplish.

Perhaps it gets to the heart of an ongoing debate about the role of IT - are we an enabler for existing technical demand, or do we have an obligation to stretch the rest of the company in new behavorial directions around technology? I'm a believer in the latter, but it's far from a settled issue.

Do any of you allow that sort of deep participation in all levels of employee communications? Is your company even one that would allow it? As I work this issue internally, I'd really like to hear how others address it.

I look forward to sharing my thoughts related to IT business and management practices. I am interested in a variety of topics pertaining to the IT profession and the role of IT in creating value. We have been researching the topics of IT value and IT innovation for almost a decade, and that includes putting some tangible mechanisms in place for people to apply in their daily jobs, enabling better value creation through the use of IT. We (IT shops) have been so busy ensuring that the infrastructure runs smoothly, that customer requirements and expectations are met, that support is one click away, that we sometimes forget about a unique role that IT can play in a company by actually contributing to future value creation and business growth. In many cases we do it without acknowledging it, and so it goes unnoticed.

At the beginning of this past decade, our IT organization was challenged to measure the impact of IT's solutions to Intel's business results. So, with the help from Finance, we expanded our typical operational metrics to include those related to business impact, such as time to market for our products, capital purchase avoidance, throughput time, and others. We worked closely with our lines of business to quantify and measure improvements from IT solutions, and establishing better internal customer relationships. The data and results produced prove beneficial to IT and the customers of our solutions. We have also learned from the difficulties we encountered. For example, not every IT solution comes with a completed ROI. The lack of business value tools and understanding makes it difficult to get started. Speaking business benefit from an IT view requires common language and common indicators to gauge and value successful IT programs.

Now, more than ever, it is important that IT shops show that investment in IT will yield a positive business return that will be felt by the shareholders.

In future blogs I will share some of the methodologies we developed and continue to create in partnership with academia and industry fellow travelers, such as the IT Capability Maturity Framework (CMF).

As this is my first post in this forum, let me start by introducing myself. My name is John Dunlop and I am an IT Enterprise Service Architect responsible for Intel's IT client solution architecture. I've had this role for less than a year, having previously been responsible for some of our identity & access management services, as well as other backend core services. What an exciting time to have made the shift to the client side of IT! To say that there have been considerable and accelerating advancements in client usage models and application delivery models is truly an understatement.

Historically the most interesting and divisive discussions of client architecture have revolved around the debate over thin versus thick clients. Both models have their advantages and disadvantages, of course, but ultimately (as all IT architects know) it's all about enabling the business to have their cake and eat it too. We need to provide a client that is robust enough to survive network connectivity or performance issues, enable an increasingly mobile workforce, support data center consolidation, and satisfy the consumerization and personalization trends that are forcing IT to make more and more compromises to keep customers happy. On the other hand, competitive pressures drive IT budgets ever lower, keeping manageability center stage for providing TCO reduction and making IT managers crave more and more control over the client. Neither thin nor thick clients ultimately deliver on all of their promises, partly because the world has never been that black and white and one size rarely fits all.

Enter virtualization. Now, some will point out that we've had "presentation layer" virtualization solutions for decades, but again, this shifts us squarely into the realm of thin clients which simply don't serve our mobility needs and shift costs to the infrastructure. The benefits of true, on-board virtualization capabilities were immediately apparent on the server, but client virtualization wasn't taken seriously (as scalable) by many until fairly recently. Sure, you could run a guest OS on a client host OS for training purposes, or to do some specific task that wasn't supported on the host OS, but there was substantial overhead from a performance standpoint, and let's face it, the average user was never going to be satisfied with all the complexity and effort of moving between host and guest. Ever notice how it always seemed to be IT people using a virtualized guest OS for some constructive end? Improvements in technology (e.g. dual core, Intel VT) have meant substantial mitigation of the performance concerns, and the competition to deliver more and more capabilities and transparency in software hypervisors is creating a virtual arms race for the virtual desktop. It is amazing to see how far we've come when when you can run apps in two different operating systems simultaneously as they float side by side on the same desktop, allow cross-registration of applications, and share file systems, task bars, paste buffers, etc., etc.

Here's where you get that cake. Rather than continuing to evolve that tightly-coupled fat client architecture you've built a career around (so when are you planning to upgrade to Vista?) or continuing to tell your users that mobility is overrated while you shift client support costs to the network and data center with your antiquated thin client strategy, let's think outside the box for a minute.

Virtualization is about abstraction, and there are several layers where you can exploit abstraction using existing virtualization technologies and products. The most obvious one is between the guest OS and the host OS or hypervisor. This abstraction layer may, for example, allow you to change your client hardware procurement or provisioning model. Even a decision made to leave those business processes alone can be made confident in the knowledge that changing that decision later doesn't require a complete redesign of your client solutions. Some companies are even thinking about discontinuing the practice of providing laptops to mobile workers, opting instead to give them an annual stipend to purchase their own systems with their own OEM support contracts and a host OS they can do with as they please.

Virtualizing the workspace, even if that remains a tightly-coupled OS and application solution stack for the time being, makes that workspace transportable across devices, easier to recover, even potentially resident on a thumb drive. Because the user has a host OS to horse around with, you can finally lock down that work environment like you've always wanted. And, now you can provide a variety of workspaces through virtualization, including productivity and collaboration, engineering, manufacturing/shop floor control, etc. Making the framework of your client more modular means greater agility for your business, and you can finally begin looking at the workspaces you provide as true services.

And what about the tight integration of those applications? Another abstraction layer is between the applications and the guest OS. New and old capabilities and techniques can be employed to virtualize those applications, albeit not without some elbow grease within the greater IT organization to stop developing and/or deplolying proprietary or OS-dependent apps to the client. New IT policies that promote standards and provide guidance about the most appropriate forms of application virtualization and application delivery would be an excellent start. Writing applications on Java VM for example, or at least not using proprietary browser extentions in web apps would go a long way toward making applications available across workspaces and operating systems. Even for natively installed applications, adherence to standard data object types and document formats will provide at least the look and feel of virtualization which may be good enough in some cases. I don't have time or space here to get into the merits of Software as a Service (SaaS), but there is a clear paradigm shift occurring in the application delivery space that can support cross-platform "virtualization" of applications, and new technologies are even allowing for the caching of streamed applications that can run even when disconnected from the network!

Finally, and this may be the hardest abstraction layer of all, there is the holy grail of data virtualization. Imagine thinking about data as being associated with users rather than devices. Why are we still thinking in terms of client backups? I want my data to be available no matter what device I use to run my workspace. If I have a problem with my device or workspace, and a new workspace is provisioned, streamed, or otherwise made available to me, my data should be there as well, protected by some network service responsible for managing my data and serving it up to me no matter what device or workspace I may be using. I must admit that I haven't looked into the options in this area much yet, but I fear this is an area that lacks maturity from a client mobility perspective.

Naturally, there are significant manageability and security implications for this type of architecture. Hey, I never said this was easy! Many products are coming to market, however, to complement virtualization products to fill these needs. Figuring out how to solve these challenges is worth some time and effort. Client virtualization is not a fad; rather it is an evolutionary step forward that will provide IT and the businesses they support with newfound agility and competitive advantage in terms of lower integration costs, faster turnaround time, and improved user experience.