From Scapegoat to Savior: The Risk Manager Story

Even in the toughest times, winners will invariably emerge. With the way expectations are changing regarding corporate controls and disclosure, risk management professionals (whose lack of influence was seen as a substantial cause of our current state of affairs to begin with) will likely be among the first beneficiaries of our new outlook on business.

Forrester customer inquiries seem to have taken a step back when it comes to risk management. While there are still plenty of incoming technology and vendor selection questions, there has been a noticeable spike in calls about fundamental issues, such as how to build and organize risk management programs. Knowledge and experience in risk management basics is in high demand.

Last week, the New York Times emphasized this demand by highlighting the current value of graduate degrees or certification related to risk management. The article explains:

“Among the hot areas now are positions related to minimizing risk, as firms try to mitigate the chances of another financial crisis. Risk in general is a relatively new focus, and the openings range from business, credit and operational risk to product and technology risk.”

Bank Technology News printed a more in-depth article about the rise of the risk management profession earlier this month, stating:

“...strategic soul-searching is going on in bank boardrooms and executive suites, but it's the chief risk officers that must carry out the emerging marching orders to accurately assess all forms of risk, and ensure that risk posture is in line with the institution's appetite.”

The article goes on to say that this added responsibility will also tear open some of the covers risk managers could previously use to avoid blame that might come their way. With increased budget and influence, it’s much harder to claim ignorance or innocence when things go wrong.

 In any case, much will be expected of risk managers in the immediate future, and I’m eager to see the professional step up and take on more of the spotlight.

What's In a Name? Announcing Truth in Labeling

A few days ago, my colleague Chris McClean asked the excellent question, "Is Risk Management Compatible with ERM?" I saw the headline come across my RSS reader and I thought, "Cool! I'd love to read what Chris thinks about enterprise rights management," a technology that I cover as part of my data security coverage. I'd advise you to read his post, which is excellent.

As you may know from Chris' post, the ERM Chris was referring to was actually Enterprise Risk Management, a way of estimating and managing security risks -- not Enterprise Rights Management. All of which led me to wonder, should we rename the data security category I was thinking of? I concluded that we should.

Enterprise rights management, loosely defined, refers to products that allow enterprises to enforce confidentiality and need-to-know restrictions on documents. Sample products in this category include Microsoft's Rights Management Services (RMS), Liquid Machines ERM, and Adobe LiveCycle. Most of these products use the acronym ERM explicitly in their marketing materials. Needless to say, it has nothing to do with enterprise risk management. Ah, the difference four letters makes!

Here's the thing, though. The reason "my" ERM is called ERM is to distinguish it from digital rights management (DRM), a largely discredited technology used to enforce publisher's rights on consumer music and video files. The upscaling of DRM to ERM, to me, is a little silly. The acronym arose from the desire to take an arguably confusing three-letter acronym (TLA) and adapt it to enterprise use, with the results being an even more confusing TLA. And it raises questions. Whose "rights" are being enforced? The "enterprise's," sure, but what does that mean? The issue here is much closer to a privileges, entitlements, and authorization issue, not "rights." Nobody will call the lawyers because someone's "enterprise rights" were violated. Surely we can apply a little more precision to the term we use to describe technologies meant to enforce access rights on documents?

And what do you know? The authors of the Orange Book have already got a term that approximates what this whole area is: labeling. The Orange Book dates from the early 1980s and is formally known as the US Department of Defense's Trusted Computer System Evaluation Criteria. The data labeling term is used in the Common Criteria also. It's a standard term in government and intelligence circles, but not seen as often in the commercial sphere.

Here's what the Orange Book says about data labeling: "Access control labels must be associated with objects. In order to control access to information stored in a computer, according to the rules of a mandatory security policy, it must be possible to mark every object with a label that reliably identifies the object's sensitivity level (e.g., classification), and/or the modes of access accorded those subjects who may potentially access the object." Sounds just like what what ERM is doing, no?

So, here's what Forrester will do in our future coverage. The ERM (enterprise rights management) acronym will vanish, except as a "bridge" term to jog memories. In the future, we will practice "truth in labeling" and call this ERM thing data labeling. 

I will continue to read Chris' blog posts, of course, and I hope you will too. Best of all, he'll have the ERM TLA all to himself!

 

[posted by Andrew Jaquith]

Is IT Risk Management Compatible With ERM?

Every month or so, news events (attacks on government sites, massive privacy breaches, etc.) provide a ‘wake-up call’... a proof point used by vendors and practitioners alike that protecting our national and corporate information assets has never been more critical. On occasion we even see these incidents yield promises of action, for example the anticipated appointment of a US Cybersecurity Czar, which my colleague Khalid Kark discusses here. 

But in spite of these warnings, my conversations with enterprise risk and IT risk professionals still reveal many disconnects, including that IT risks are not measured consistently with other enterprise risks. In addition, many IT risk professionals do not see their biggest risks showing up on the corporate risk register.

One problem is that traditional enterprise risk management (ERM) metrics such as likelihood and impact, do not fit neatly with common IT risk metrics such as system criticality and vulnerability. Even at the Federal level, the Office of Management and Budget recommends moving from compliance-based metrics to security- and vulnerability-based metrics. This will be progress if implemented, but it’s still a long way from measuring actual risk exposure.

I have seen more progress by IT professionals using ERM methodologies in the private sector, and I’ll be highlighting some of the best examples at our Security Forum in September. Although most organizations are a long way from a fully integrated enterprise risk management program, the ability to paint a big picture of risk exposure has clear benefits. I think measuring IT risks in the same way as financial, legal, or environmental risks is ultimately the best way to demonstrate how serious they are, and is an important step in earning due consideration at the enterprise level.

DLP Wave Getting Started: How You Can Help

Hi everybody! Long time, no post.

It’s an exciting time here at Forrester. I’m pleased to say that we are getting ready to kick off the next Forrester Wave on Data Leak Prevention. We won’t be kicking it off formally for another few weeks, but because the lead times on these publications are extremely long, it makes sense to start firing up the jets now.

One thing we will be doing this year is getting Forrester clients, members of the security community, and readers of this blog involved in the process. We want you to help us shape our evaluation criteria! We’re looking for some good ideas that will make our DLP Wave more transparent, better suited to real-world scenarios, and more relevant to enterprise planners who need to select a DLP product.

Definitions

But first, let’s define what we mean when we say “DLP.” Data leak prevention products detect and optionally prevent violations to corporate polices regarding the use, storage, and transmission of sensitive information, which includes:

• Financial information, such as cardholder data or bank details 
• Non-public personal information, such as government identifiers 
• Personal health information (PHI) 
• “Intellectual property,” such as earnings forecasts, product plans, legal documents, or confidential data

Protected channels include e-mail, HTTP, FTP, file shares, copy and print, USB/portable media, databases, and IM. Unlike access control technologies, DLP is content-aware. Forrester regards endpoint device control technologies as complementary to, but distinct from, data leak prevention. (But this may change.)

Evaluation criteria

In last year’s DLP Wave, we evaluated products using the following top-level criteria:

• Current offering (Y-axis): Solution breadth and technology; data-in-motion features (network); data-at-rest features (discovery); data-in-use features (desktop or host); unified management; policy management; administration; forensics; integration; customer references 
• Strategy (X-axis): Company vision and product strategy; go-to-market; pricing and cost
• Market presence (size of bubble): installed base; revenues  

Each of these individual criteria, in turn, contained additional criteria — 56 in total.

This year, we are considering making some major changes to the current offering (Y-axis) criteria in particular. Here are possible changes we are considering:

• Default weights that reflect the features customers are actually using. Practically speaking, this will probably cause us to underweight desktop DLP features, because these have not been rolled out as widely as network features. (As with all Waves, of course, clients are free to adjust weightings for each criterion as they see fit.)
• Scenario-based criteria instead of “feature-based.” Buckets like DIU, DIM, DAR are a bit broad, and architectural “checkbox” features (“do you have a network appliance?”) are not helpful. Criteria that reflects a specific business problem (“how well do you address the problem where someone e-mails a spreadsheet with bulk PII in it?”) are better.
• Stronger emphasis on understanding success in the field. Customer success (or lack thereof) should be given much more weight by default. We will want to know about time-to-value, scalability, and operational/staff workloads. 
• Strong emphasis on criteria for using DLP outside the IT Security group. If you’ve read my report Data-Centric Security Requires Devolution, Not a Revolution, you know that my basic premise for success is that business units need to own the security of their data. That’s true with DLP, too. As such, we will likely include new criteria that places a premium on delegated policy management and operations. If DLP is just a “security group thing,” it will fail.

Who we will invite

In general, the number of vendors we can cover in a Forrester Wave is governed by two factors: the number of important market participants, and amount of capacity we have to analyze those participants. Frankly, Waves are very laborious, and the more vendors we have, the longer it takes. 

This year, we will be stingy about the number of vendors we invite. The magic number I have in my head, at the moment, is 8 vendors. That’s not many, but then again, one theme we hear consistently from our clients is that when they want a “short list,” they want a short list. Moreover, in recessionary economic climates most customers retreat to quality vendors with established track records, rather than little vendors nobody’s heard of.

Thus, we will likely invite mostly household names to the Wave. Symantec, for example, is far and away the market leader by revenue in DLP, and at the top of the list in terms of volume inquiries we get on DLP vendor selection. So we will invite them. But I’d love to hear about other DLP vendors you’d like to see us invite. But to be candid: the small upstart vendor from Lower Slobovia who’s got a flashy feature “that nobody else has” is unlikely to make the cut unless we can verify that their revenues are significant. Last year, by the way, we evaluated 11 vendors: Code Green Networks, InfoWatch, McAfee, Orchestria, Reconnex, RSA Security, Trend Micro, Verdasys, Vericept, Websense, and Workshare. The landscape has changed considerably since then.

Timeline

We’re looking to send out preliminary invitations to participate to a dozen or so vendors next week. We will spend a month drafting (and re-drafting, and eventually finalizing) evaluation criteria in the month of May. Formal kickoff will begin in June, with strategy briefings, demos, desk research, and the like going throughout the summer. If all goes well, we’ll then do fact-checking and get the Wave finalized in the third quarter. That’s if everything goes well. 

For people reading this post, the most important part of the timeline is now: your active participation will be most valued from today through the end of May.

How you can help

I'd love to hear the ideas you have to make our DLP Wave the best one we’ve ever done. For your consideration, here are some questions to spark discussion:

• What are the most important criteria for you, when selecting a DLP product? 
• What business problems are the most important ones for you? What scenarios must we address in our criteria?
• Which vendors would you like to see us evaluate?
• If you’ve already selected or deployed a DLP product, what did you wish you’d known before buying — and how can we help uncover those qualities in our evaluation? 

Please post replies to this blog — I’d like to keep the dialog transparent and free-flowing.

Thanks for reading! I look forward to seeing your comments and ideas. I'll post updates as we go.

— Andrew

Data Toxicology

As most Forrester customers know, data security has rocketed to the top of the list of CISO priorities for 2009, even considering the down economy. Our Business Data Services group has published some excellent quantitative research on this subject, which we've summarized in report form for Forrester customers. I refer you to Jonathan Penn's excellent The State of Enterprise Security 2008 to 2009 for more details. But for those of you who want the sound bite, 90% of CISOs said that data security was either "important" or "very important" on their proirity lists for this year. That trumped disaster recovery, identity and access management and regulatory compliance.

The elevation in importance of data security has, in turn, spurred interest in several security product categories, notable data leak prevention (DLP). According to the survey data I just cited, about 38% of enterprise customers have DLP implemented already. Another 21% are planning to implement it this year. That's an amazing expected uptick in adoption considering the overall state of the security market (flat or slightly up). And of course, if you are a DLP vendor, this is very good news indeed.

Digging deeper, though, what's been most interesting in the dozens of customer calls I've had since January 1 has been the amazing consistency of much of the interest. We are clearly getting past the Early Adopter stage of adoption, and are now well into Early Majority. I'd say about 2/3 of the enterprise customer inquiries I've fielded have been around product selection: Who are the leading vendors? Is the incumbent vendor who provides my anti-virus software a good choice for DLP also? What are the most important qualities in selecting a DLP product?

As an analyst, these are the kinds of questions I expect to hear at this stage of adoption. But what's most striking are the questions I have not heard. Here's what nobody seems to be asking about:

• What can I do to persuade my boss?
• How do I justify the investment?

You might be asking yourself, Why is this? How come the usual justification questions aren't coming up for this particular purchase decision?  Based on my conversations with clients, the answer to this is clear: may enterprises are living in mortal fear of suffering from a toxic data spill. Put simply, certain types of customer information have become highly toxic. The most commonly cited toxic data are:

• Customer names and addresses, when combined with one or more of the following: 
• Government identifiers (taxpayer ID, SSN) 
• Health care identifiers
• Bank account details 
• Cardholder data (number, expiration date)  

Just like asbestos, these data types have become toxic when airborne. Why? Because they have monetary value. Robust black markets have arisen to acquire, buy, sell and barter customer information at "market prices," particularly credit cards. We don't track this kind of thing, but I'd refer you to some of the research done by Symantec and others if you want to know what "street prices" these data types are fetching.

Of course, if the toxic data problem related solely to black-market selling, that alone would not explain the interest in DLP. And here's where the second driver kicks in: the mushrooming number of state and federal statutes and regulations around data breach disclosure. PCI is a key driver too: although it isn't a statute per se, it is a contractual agreement that many enterprises are subject to.

These two issues -- increased toxicity of customer data, and mandates designed to protect that toxic data -- are the primary reason DLP is taking off. About 80% of the time, enterprises evaluating DLP are doing it because of toxic data problem. They are not doing it primarily because of the fear of leaking more ethereal forms of intellectual property, like product plans or sales forecasts. Yes, we do hear that IP protection is driving some interest. It's just not the primary driver -- at least not amongst the mainstream adopters who are now kicking the tires and exploring their options.

In future posts and in my written research, I'll examine the follow-on phases of DLP adoption: that is, what do you do once you have it? How do you use DLP successfully within organizations? Based on the conversations I've been having with customers, we are already seeing some very sharp and distinct trends with successful adopters. Stay tuned!

This week in history - volcanos, hurricanes, and the risk of Black Swans

Pouring over endless details of risks, regulations, taxonomies, and technologies can sometimes give us a narrow view of the world, so it seems worthwhile to take a minute to mark the 125th anniversary of the cataclysmic eruption of Krakatoa this week. For those of us that want to think big but can’t remember that far back, this week is also the 3rd anniversary of Hurricane Katrina’s devastating sweep across a wide stretch of the US Gulf Coast.

By now, I expect that most of you have read or are familiar with the 2007 book, The Black Swan, by Nassim Nicholas Taleb, which argues that these kinds of unpredictable, outlying occurrences are the ones that really shape businesses, countries, economies, and people. Taleb argues that although these “Black Swan” events are almost completely unforeseeable, we mistakenly try to explain the circumstances at the time and make predictions about similar events in the future.

In my ERM work with clients, and especially in the context of research I’ve been doing with my colleague Stephanie Balaouras on business continuity and resiliency, questions come up about how to plan for catastrophes... and they’re good questions. Were the CardSystems or TJX data breaches foreseeable? What about the Societe General debacle or the 2004 Indian Ocean tsunami? What’s next? Should these types of events be included in our risk assessments?

We’d like to get your opinion on these and other risks that may be on the very edge of the statistical tail. At what point do they belong in your risk register?

Of course, it’s possible to define mitigating controls for crises, disasters, or incidents without knowing for sure what they’re going to look like. That’s one of the hallmarks of a good crisis management plan. And that’s an important point, because trying to predict the next unforeseeable event can be a real challenge sometimes.

Power Outages Are A Major Risk That Most Companies Overlook

TechCrunchIT reported today that a Rackspace data center went down for several hours during the evening due to a power grid failure. Because Rackspace is a managed service provider (MSP), the downtime affected several businesses hosted in the data center.

When companies think of disaster recovery and downtime, they typically think of catastrophic events such as hurricanes, tornadoes, and earthquakes. What companies don't realize is that the most common cause of downtime is power failures. In a joint study by Forrester Research and The Disaster Recovery Journal of 250 disaster recovery decision-makers and influencers, 42% of respondents indicated that a power failure was the cause of their most significant disaster declaration or major business disruption.

To prevent power failures, businesses must ensure that they have multiple diverse connections to the power grid as well as install backup power generators and uninterruptible power supplies (UPS) at the data center. But it's not enough to have these preventative measures in place, businesses must test the ability to switch over to backup power must at least twice year. And if your business has a recovery data center, it's best if the recovery data center is on a different power grid and is also equipped with backup power generation.

But despite all these measures, failures might still happen, in the case of the Rackspace power failure, the company successfully failed over to its backup power generators but some of its chillers did not start up correctly.

In North America, the risk of power failures is likely to remain high for the foreseeable future. According to a 2007 report by the North American Electric Reliability Corporation (NERC), long-term capacity margins are still inadequate and significant investment in transmission is still required.

So businesses must not only invest in preventative measures such as backup power generators, they must think about where they locate their data centers. You must avoid areas that have clearly identified congestion issues and focus on areas that have access to cheap and abundant power. And, don't take it for granted that your service provider has effectively managed the risk of power failures.

IT-GRC: Who is and who is not

A message for IT-GRC vendors:  I am constantly bombarded by vendors touting "I have an IT-GRC solution for you to look at!"  Since I cover the IT-GRC space, I naturally am interested. In many cases, my interest quickly turns to disdain after the vendor product demo.  Why?

Simply, most IT-GRC "vendors" are not IT-GRC vendors. An IT-GRC vendor, by our definition, automates the governance, risk, and compliance lifecycles to provide seamless integration and data sharing.  Most of the IT-GRC "vendors" I get briefed on automate IT controls, not IT-GRC lifecycles. For example, Brabeion automates policy management (a governance process), the testing of IT controls (a compliance process), and the assessment of IT risks (a risk process). Brabeion, therefore, is an IT-GRC vendor. Sun Microststems' identity and access management product automates access controls and NetIQ's SIEM product automates event monitoring controls.  Neither of these companies are IT-GRC vendors or have IT-GRC products.

So before marketing a product as an IT-GRC solution please make sure it actually is an IT-GRC solution and not a control automation solution.  This will go a long way to reducing the "noise" around the IT-GRC market space.

IT Risk Management

IT risk management is a nebulous topic at best. There are many different ideas as to what risk means and how it should to be applied within an IT organization. In an effort to bring some consistency and clarity to this discipline, Forrester is developing an IT risk management framework. Once developed, the framework will help IT organizations identify major risk areas, identify scenarios linking risks and controls, and establish a common risk language to clearly communicate with business leaders.

In order for the framework to have a solid risk-based foundation we will be using many of the principles of COSO. In particular, the framework will be based on event identification, risk assessment, risk response, and control activities. The IT context is established by utilizing the ITIL framework for IT service delivery. IT services are used to identify risk events. Scenarios are developed for each identified risk outlining the actions necessary to realize the risk. Controls are then mapped to each scenario to either prevent or detect the actions.

Since COSO and ITIL will be used to develop the framework, a common industry-agnostic set of key risk indicators can be established and bring some consistency and clarity to IT risk management.

Legislators to the rescue

One of the most substantial trends we expected to see in governance, risk, and compliance in 2008 is the tightening of regulations in response to major risk management failures. Yesterday, we saw a clear example of that, as the US Senate approved a bill that would nearly double the size of the Consumer Product Safety Commission, largely in response to the massive toy recalls that took place last year.

Also this week, the UK’s Medicines and Healthcare Products Regulatory Agency showed signs of cracking down on disclosure of drug trial results after problems persisted with certain anti-depressant drugs in relation to teenage suicide (even though criminal charges will not be filed).

The sub-prime issue may likely be the next major target for legislative changes, although most discussion seems to be focused on consumer protection at this point, not tighter control over lenders.

In all of these cases, it’s much easier to see in hindsight what companies could have done to avoid such legislative action.  However, I think a case can certainly be made for seriously supporting industry standards...for example, the general success of the PCI Data Security Standard seems to have diminished any strong push to curb data theft through tougher regulations.