Thursday, May 21, 2009

Cheap IT Is Ultimately Expensive

I'm positive many of you are familiar with the idea that there are benefits to detecting software security defects early.

[Image reference: Software Security Engineering: A Guide for Project Managers.]

In other words, it is ultimately cheaper to design, code, sell, and support a more secure software product than a more insecure software product. Achieving this goal requires recognizing this advantage, investing in developers and processes that work, and dealing with exceptions (defects) as soon as possible through detection and response capabilities, even including customer-facing organizations (like PSIRTs).

I'm not aware of any studies supporting the following assertion, but I would be interested in feedback if you know any. I think it should be obvious that it's also cheaper to design, build, run, and support more secure computing assets than more insecure computing assets. In other words:

  • It is not cheaper to run legacy platforms, operating systems, and applications because "updates break things."

  • It is not cheaper to delay patching because of "business impact."

  • It is not cheaper to leave compromised systems operating within the enterprise because of the "productivity hit" taken when a system must be interrupted to enable security analysis.

  • It is not cheaper to try to manually identify and remove individual elements of malware and other persistence mechanisms, rather than rebuild from the ground up (and apply proper updates and configuration improvements to resist future compromise).

  • It is not cheaper to watch intellectual property escape the enterprise in order to prove that intruders are serious about stealing an organization's data.


Security doesn't make money; security is a loss prevention exercise. It's tough to justify security spending. However -- and these are the killers:

  • It's easy to show cost savings when experienced, professional system administrators are replaced by outsourced providers who are the lowest bidders.

  • It's easy to show the financial benefit of continuous availability of a revenue-producing system, or, conversely, easy to show the financial cost of downtime of a revenue-producing system.


Unfortunately, being seduced by those arguments ignores intrusion debt. One day the intrusion debt of poorly-run systems will be claimed by the intruders already inside the enterprise or those who are unleashed like an earthquake. Worse for you and me, the costs of dealing with the disaster are likely to be borne by the security team!

I thought of this vicious cycle when reading about The Sichuan earthquake in last week's Economist magazine:

In the days after the earthquake, senior officials vowed to investigate whether shoddy construction was to blame for the destruction of more than 7,000 classrooms in the disaster. But the issue was soon played down...

Mr Ai [investigating the disaster] says the refusal of central leaders to admit policy failures has exacerbated parents’ frustration. In the 1990s, he says, shoddy school buildings were erected across China because of the government’s drive to provide enough classrooms for all children to undergo nine years of compulsory education. Building costs were supposed to be shared by central and local authorities, but the latter often failed to chip in. This led to quality problems.


Ultimate, security is an IT problem, not a "security" problem. The faster asset owners realize this and be held responsible for the security of their systems, the less intrusion debt will mount and the greater the chance that enterprise assets will survive digital earthquakes. Cheap IT is ultimately expensive -- more expensive than proper investment in IT in the first place.


Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

10 comments:

Jose Luis said...

Excellent article, i liked it a lot. I think that what you say its true, cheaper is expensive.

LonerVamp said...

I don't know of any data either to support this, but I do agree that you're correct.

However, this is all based on the accepted assumption that an incident will occur. Not everyone seems to believe that, or at least their actions don't seem to be in line with it. Spending for security still seems to be the Gamble that an incident won't occur.

Keydet89 said...

...this is all based on the accepted assumption that an incident will occur.I'm not sure I agree that this is an assumption. Given the Verizon Security reports and others like them, as well as my own experience as an incident responder, a great number of incidents occur without the victim organization's knowledge, and they have to be told by an outside party...be it someone attacked from their site, a bank or Acquirer doing fraud analysis, etc.

You're correct about the gamble...I think the issue is that IT managers are faced with the certainty of a sales guy sitting in front of them with a purchase order, and they have to weigh that against the potential/perceived uncertainty of an incident actually occurring. The issue is that in most cases, the incidents have already occurred.

thomas said...

Not everyone seems to believe that, or at least their actions don't seem to be in line with it. Spending for security still seems to be the Gamble that an incident won't occur.
Berkey Filters

LonerVamp said...

@Richard
I think the post above this one is a spam you want to delete. Talk about insidious...taking part of an earlier comment!

@Keydet89
I think I poorly truncated my earlier comment. My point is that if an organization does not accept that an incident will occur, then it seems to always be in their best interesting to go the route that appears the cheapest, which worsens the security gamble for us. This would be like not assuming a category 5 hurricane will ever happen in location X, so location X opts to only build levees to withstand category 1-4.

Pete said...

@Richard -

You want ROI and/or ROSI...except you usually don't want ROI and/or ROSI. I recommend reading "How to Measure Anything" by Hubbard to get over your quantophobia. ;-)

Pete

Richard Bejtlich said...

Pete, when you can run a profitable (or heck, break-even) company that does nothing but security (but doesn't sell it as a service to external customers) then I'll recognize security as having ROI. Until then security remains a loss avoidance exercise that supports others who sell products and/or services to external customers.

Pete said...

@Richard -

Okay, if we simply don't use those terms are you onboard with the need to measure costs, risk, and losses (we must do this to determine how much was avoided)? And are you okay with using standard economic and risk management techniques to perform these measurements?

Note that you are doing this in a broad way, anyway, any time you assert that something is NOT CHEAPER...right? Doesn't it make sense to be clearer about the magnitude and extent by which you are making those assertions?

(Digressing back to your concerns about ROI, profit includes revenue and expenses. So if I hold revenue constant and reduce expenses, then my profit increases. So if a security solution reduces expenses, it increases profit. Voila!)

Pete

Richard Bejtlich said...

Pete, "measuring" risk is a joke. Measuring loss is mostly impossible. (Tell me how much you lose when a competitor steals your data to improve their products over the next 10 years.) Measuring cost is the exercise most likely to produce trustworthy results since you can track money leaving the company.

Measuring cost is what I refer to in this post. I'd love to measure loss but it's not going to yield real numbers. Measuring "risk" is a giant guess.

Regarding "ROI," I have a security program I'd like you to "invest" in. Just sent me a check for whatever amount you like. When I don't send you any money back maybe you'll see where I'm coming from regarding "ROI." :)

rduht said...
This comment has been removed by a blog administrator.