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.
Comments
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.
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.
Berkey Filters
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.
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
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
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." :)