Data Breach Follow-Up - It's About Risk, Silly

In yesterday's post we examined the elements comprising the Commonwealth of Massachusetts's recently reported data breach that exposed a great deal of PII from an as-yet-unknown number of clients of their Unemployment Assistance department. While the anatomy of this breach and, moreso, the Commonwealth response to it, shows that lacking a solid risk-based security management structure can make or break how deeply a breach affects an organization. I focused on questions around the best - and some not-so-great - ways to respond to a data breach by having visibility into systems and controls to mitigate the extent of a breach, but there's a fundamental management philosophy that underlies all of these tactical defenses: an understanding of risk as the driver for security strategy.

In a recent guest article over at CIO, two NYU professors from the Stern School of Business raise the issue of management ownership of data breaches, business philosophies hampering that ownership, and the problem of big data. It's a meaty topic for sure, and while I understand why two members of the business faculty draw a line between business management and data stewardship, I see the problem as more fundamental than simply "the CISO needs a full time seat in the C-suite" (I'm paraphrasing.) While gaining the ear of the CEO is something IANS advocates as part of a "high performing security organization" in our research, the tenor of discussions in many organizations still center on "making IT a critical utility to do business." I don't think that's right. While the problems in security are largely-IT based and the solutions are most often implemented by IT or some related team, the issue at stake is risk; many firms have a poor understanding of it and still more have yet to adequately catalog its existence in various areas of the business. 

The CIO article makes a few points that I interpret as someone being focused on the idea of managing risk as the primary objective of information security:

• There is such a thing as "too much" data - Any organization seeking a competitive advantage in serving its customers must build and maintain a massive data store. In fact, even for a small business, being able to know who in my coffee shop bought what and when is critical to serving those customers - a reason that business data and resulting intelligence was at the heart of Monday's announcement by payment company Square. I use the credit card example since anyone with an inkling of security is loathe to retain any such data. In the case of Square, card data is not stored on client devices but customer purchase history is. The store of historic purchase data gets more valuable the longer businesses retain it. Should I discard my data after a year? A month? Two years? While this data is extremely valuable for the business, its compromise could be drastic for customers, allowing thieves to learn their daily habits and socially engineer private data from them. Still, the responsibility for safeguarding that data lies with the business. In short, I'd be hard pressed, for any business large or small, to say definitively what's "too much" data, but I can make a pretty clear case for what companies should retain and what they should not (e.g. payment card info vs. buying trends) and how it should be protected. The focus is not on how much data you have, it's how well you obscure and protect that data to protect your customer relationships, which is the element of risk in this equation.
• The CEO should "own" the data breach - Really? While I understand using the CEO as a figurehead, it is presumably not a necessary step unless the company has gotten to a point where its "CNN moment" is upon it and grand gestures need to be made in order to assuage public opinion. The CIO article uses Sony as an example of a CEO stepping in to mend fences after a breach, but I can't think of a situation of late that's been handled worse and in more need of a grand gesture than the Sony breach.  A properly empowered CISO should be the owner of immediate actions and associated communication in the event of a breach. The problem? Many organizations have not yet created or, more commonly, properly empowered the CISO to act independently in the company's best interest to avoid increased risk. If the organization is properly risk focused - we see this most often in compliance-heavy industries such as financial services - the CISO may even report directly into a Chief Risk Officer whose job it is to actively monitor and minimize risk exposure for the organization. At a minimum, being the lead architect of all risk assessments and associated protections puts the CISO in the position as best equipped to respond to and communicate a response plan for a breach. As mentioned in yesterday's post, breaches will happen, it's how the organization responds that matters. 
• Data leaks are akin to product defects: While an interesting analogy, looking at the compromise of customer data as something akin to bad brakes on a car is misguided. While the failing of brakes on a car can present far more dire circumstances, the activity leading up to the event is something actively involving the user. If the Epsilon breach taught us, as consumers, nothing else, it's how many businesses we connected with in the past that we'd forgotten about. I received notifications from companies that I honestly could not remember having dealt with, communicated to me at email addresses that haven't seen a new message in years. Data breaches act on the user, requiring no action or engagement on the user's part. In fact, you may have provided information to a vendor without even receiving services or goods in return and find that vendor has compromised your information with the end result providing endless frustration. I don't mean to paint the victims of defective product lightly, but the ability of data loss to "sneak up" on the user, to me, sets it apart. Also, here the idea that the CEO "owns" the communication around a product defect comes almost always after the coverage of said defect has made that response necessary.

Businesses have an increasing number of challenges - not to mention legislation - that they must take into account when dealing with users and handling their information. These rules change across markets, user segments, and industries and are a full-time occupation to track. Managing to compliance with these rules is a losing game of Whack-A-Mole: the larger risk equation, which is different for every business and never static, should be the goal rather than beating down individual regulatory issues or data incidents.

This is a major theme in our research this year and I'm interested in understanding how your business is coping with the challenge of the moving target of risk. Of course, if you haven't started thinking proactively about risk and are instead looking reactively at security, we can help.