Home > Uncategorized > TJX and the Problem of Opportunity Cost

TJX and the Problem of Opportunity Cost

When blogging earlier about the aftermath of the TJX breach, I was reminded of something that happened to me years ago that expanded my perspective in understanding the true cost of information security.  I managed a department that included security engineers who operated the global Kerberos based authentication system for the firm.  One day at about 10 AM the system went down around the world.  Sessions already logged in were unaffected but no one could log on anywhere on the planet.  This is a fairly major outage and potentially a career limiting one.  After about 45 minutes, we were able to restore service and began accounting for the impact from this potentially catastrophic outage.  This was a large Wall Street investment bank and as it turned out the most profoundly affected unit included foreign currency futures traders. Had the outage occurred earlier in the day, it would have been much broader and more impactful.  We determined that approximately 75 users around the world were affected by their inability to log onto the system. Armed with this information, I went hat in hand to the managing director in charge of this futures trading unit. This is a person who makes about $20 million a year (somewhat more than I made that year 🙂 ).  He opened the meeting by saying “Jim, this is a very serious outage and we can’t overestimate the impact of such a service problem on the firm.”  I told him I understood this very well and my objective was to try to quantify in dollar terms the actual amount of financial impact that came from this particular outage. We might use this calculation in a variety of ways such as computing the return on investment from an HA cluster or other architectural approach to avoid a global outage in the future.

The managing director reiterated how serious an outage it was and when I pressed him for precise dollar estimates, he said “that morning, when foreign currency traders couldn’t logon they were unable to make certain bets in the marketplace. However, had they been able to make bets, they probably would’ve made the wrong ones given what happened later in the trading day. Therefore, we actually made money from the outage.”  I must’ve blinked my lack of understanding because he went on to say “that’s right, had my people been able to logon they would have made the wrong bets and lost money for the bank.”

It’s kind of hard to build this into the computation of the impact of an outage on the economic success of the firm.  When we made our own economic estimates later, we simply ignored this incident because including a positive number would have implied that it is possible to make money from having a system outage which cannot be a feasible financial outcome upon which a high-availability system can be based.  We did, however, try to calculate how much the outage might have cost had it come two and a half hours earlier and that was a big number…

This illustrates several problems with the computation of business impact of an adverse incident.  Even though statistically there is the possibility that an outage will produce a positive outcome, we ignore those.  By rights we should include them as just as statistically significant as the negative outcomes but our job is to provide protection against the negative outcomes, not the lucky ones.

Justification for information security is heavily biased on “soft dollars”. Attacks that weren’t successful, outages that didn’t happen, confidence that was improved and lower overhead from improved security interfaces are all quantified based on soft dollars. However, soft dollars don’t put food on the table or money into the shareholders’ pockets.  In fact, we always assume that the firm has something useful to do with the money we’d like to spend on information security if for some reason we didn’t need to spend that money.  This is what is behind the concept of “internal rate of return.”   If TJX had not experienced their breach, what would they have done with the extra earnings they made in 2007 and 2008 after all those customers did not desert them and all of those fines and penalties did not need to be paid?  Maybe TJX would have wasted that money on inventory or new stores that would have proved disastrous once the mortgage meltdown and the credit crunch reached their climax. The point is, you have to assume that the money you’d like to invest in security (or any other project for that matter) is precious and would otherwise be put to good use. The way to represent this in an ROI spreadsheet model is to use a middling return on invested capital rather than basing the hurdle rate on the most successful outcomes seen for other projects.  By using a middle range threshold, you build in the chance that some investments will go bad and not pay off.  In business school, the joke was that when you asked the professor about the hurdle rate, the answer was that it was a very complex calculation and unique for each different firm or industry, in short, “10%.”

TJX spent tens of millions of dollars on fines, penalties and damages resulting from its breach of more than 40 million credit card numbers in 2007.  In addition, it spent a lot more money upgrading its security infrastructure and may in fact have overpaid for those investments because they were made under some duress and perhaps lacked the full architectural thoughtfulness that might have attended less pressure filled in investments.  Assuming that excellent security would’ve prevented the breach, one would also have to build in as a benefit to security investments the lost margins, legal fees, and perhaps other softer opportunity costs to add to the total benefit stemming from avoiding a devastating information breach.  The stockholders might even like to get some of that stock price back as well.

TJX did not spend the money to have excellent security and instead suffered a breach.  We do not know if that decision was based upon an underestimate of the actual costs – including the soft dollar costs — of having a breach or real and pressing investments demanded elsewhere in the business that upstaged security.

There are two important lessons for security leaders and architects from this. The first is that there’s always something else to do with the money when considering making security investments. That consideration is more complex when one considers that oftentimes security is part of the overall IT organization and therefore might not substitute for investments made elsewhere in the firm but for investments in other technologies within IT. During the budgeting and planning process — or during a mid-year reallocation — it’s useful to consider the next project on the list and make certain that the opportunity cost from not investing in that project is appropriately figured into the security investment.

The second lesson is that the more you can drive benefits from the soft dollar side of the equation to the hard dollar side (real revenues, margins, or committed cost savings) the more clear-cut the investment decision becomes. This is not to say ignore or otherwise treat soft dollar benefits as trivial — this would be a mistake especially when such benefits can be quite substantial — but it does focus attention on the challenge of actually capturing the benefits after an investment in security infrastructure.  When they are all soft benefits, capturing and documenting financial success is a difficult exercise that can breed cynicism and distrust within the organization when not done well.  When two projects under consideration have equal benefits but one is all soft dollar benefits and the other is hard dollar benefits, the hard dollars or higher revenues or committed cost reductions will trump soft dollars every time.  Employees who can measure their own value to the organization by the  generated profits from their transactions in any given day or month want to see all of the promised benefits from new security infrastructure captured.

We can all think of projects that never reached their full potential.  The PKI implementation that never reached full roll-out.  The voice-activated password self-service tool that nobody uses.  The data from the IDS system that is not aggregated.  Etc.  These are all projects that were justified on substantial soft-dollar benefits and it is likely had untold opportunity costs beyond their out-of-pocket implementation costs.  If the opportunity costs had been included, would we have tried harder to capture the benefits?

Know your opportunity costs. These include the financial costs that we’ve discussed as well as the costs of having people devoted to your project versus other security or non-security priorities. Understanding the depth and character of opportunity costs can significantly improve your ability to justify and win approval for information security projects.  It can also galvanize the organization to drive the project successfully and capture the full measure of benefits.

Categories: Uncategorized Tags:
  1. No comments yet.
  1. No trackbacks yet.
You must be logged in to post a comment.