SIEM Resourcing or How Much the Friggin’ Thing Would REALLY Cost Me?

One of the ugliest, painfulest, saddest issues with SIEM is resourcing. Yes, that SIEM appliance might set us back $75,000 in hard earned security budget dollars, but how much more will we have to spend in the next 3 years deploying, integrating, using, tuning, cursing, expanding the thing? How much manpower will the new operational procedures (example) cost us? And if we actually build a SOC or “a virtual SOC”, how much will we have to spend on an ongoing basis to get the value and benefits? In fact, how much will the coffee cost if we have to work 20 hours in a row recovering that crashed SIEM database partition?

These and other questions are super-important for every SIEM and log management project. And the time has come for me to reveal my secret knowledge of SIEM resourcing. OK, that’s a joke – it is not a secret, just a bunch of things that are often unpleasant for many SIEM buyers, users and sellers to hear.

So:

NEWSFLASH! SIEM costs money. “Free” SIEM (example) costs money too, BTW. Let’s try to delve into what those costs are. I will be not-quite-scientific in regards to real “hard money” costs (e.g. software license purchasing) and “soft costs” costs (e.g. staff time costs), but I will try to clearly mark each kind of SIEM cost below.

First, assumptions and limitations:

• This is NOT “SOC staffing” , but simply “running a SIEM” staffing. SOC implies more processes and more tasks and a broader mission.
• Assumes in-sourced, traditional “buy and run” SIEM; outsourced, co-managed/co-sourced cost model would look different.

Here is the rough cost model for some of the most common SIEM cost categories:

1. Initial “hard” costs 
   1. SIEM license costs: base price +per user, per node, per EPS, per CPU (and per CPU core), etc costs – however your favorite vendor charges
   2. For software SIEM, also hardware, OS, database costs for as many servers as you need
   3. If any, mandatory 3rd party software license costs (occasionally, agents, reporting tools, etc)
   4. If chosen, vendor or consultant deployment services costs. If not chosen, staff time for deployment will pop out in soft costs below!
   5. Vendor training or 3rd party training on logs, log management,  SIEM, etc
   6. Additional external storage (in most cases)
2. SIEM ongoing, operating “hard” costs
   1. Various SIEM vendor services: support (typically mandatory), ongoing professional services costs
   2. Personnel to operate a SIEM: from part of FTE (very small scale, few use cases for a SIEM) to 1 FTE (small appliance deployments) to many FTEs of various roles (+much more for SOC staffing if live monitoring is implemented). 0 FTE for SIEM = SIEM project FAIL with 100.00% probability.
3. Periodic or occasional “hard” costs
   1. Various SIEM vendor services: professional services, custom development work for device integration (some of these may go into soft costs if done internally – for advanced organization or those experienced with SIEM already)
   2. Periodic staff training on SIEM operation and tuning
   3. Specialty staffing: DBA, sysadmins, node sysadmins, in-house developers for custom connectors, Crystal Reports administrator (yuck!), etc – some of these might go into “soft” costs if “poaching” existing personnel time
   4. Deployment expansion costs: same as initial costs, but for additional systems, software, hardware, etc as you grow; these sneak up really fast if SIEM is licensed using many dimensions such as user+CPU+node+server+something else.
   5. External storage expansion costs – yes, you will buy more storage if your volume grows, and log retention time stays the same (e.g. 1 year for PCI DSS)

On the other hand, here are some of the “soft” costs, such as time expenditures by existing resources:

1. Initial “soft” costs 
   1. Deployment time for the SIEM project – allocate more time if deploying purely using internal personnel, not vendor or consultant
   2. Log source configuration and integration – this will likely take way more than simply installing the tool. This is what makes SIEM deployment projects go for months in complex, distributed organizations with many silos.
   3. Initial tuning, content creation  and adapting the tool to your environment  (however lightweight it may be)
   4. Training and other staff time costs to jumpstart the operation (Congratulations! You bought ta SIEM. Now you need to operate it…)
2. SIEM ongoing, operating “soft” costs
   1. Report review and other ongoing monitoring tasks – from 24/7 to daily to weekly
   2. Alert response and escalation; SIEM implies correlation and automated alerting
   3. Other “using SIEM” tasks such as reviewing the dashboards
   4. Uptime maintenance tasks i.e. caring for your SIEM as well as storage – backups, updates, minor troubleshooting, etc
3. Periodic or occasional “soft” costs
   1. SIEM rule tuning, reports creation, dashboard customization, new log source integration, other ongoing SIEM tasks
   2. Periodic training and related staff time costs
   3. Expansion: same as initial soft costs

As was suggested by a discussion on SIEMusers.org (shhh…the site is not ready for launch yet), it is useful to separate soft costs  that are mandatory FOR SIEM operation from those which commonly arise FROM SIEM operation. The most obvious example is incident response due to increased awareness of network and system activities, delivered by your SIEM.

”Soft” costs that commonly result from SIEM:

1. Added cost of incident response: more incidents are likely to be detected
2. Resulting incident remediation costs and even cost of new technologies deployed for preventing the discovered issues
3. Other department personnel time for dealing with issues revealed by SIEM – the soft costs do leak out of the security department to IT and even beyond (legal, HR, etc).

Anything big I missed that you experienced? BTW, in my experience, I have seen the total cost of a SIEM project (hard + soft) range from 10% of SIEM license costs (for shelfware SIEM “deployments”) to a mind-boggling 20x of license cost.

P.S. Finally, if you want to really annoy Anton, mention “SIEM ROI.” If you do that, I will send you to Gal Shpantser for a mandatory “why he avoids SIEM!” class

Possibly related posts:

• Log Management Tool Selection Checklist Out!
• "So, What Should I Want?" or How NOT to Pick a SIEM-III?
• On Choosing SIEM
• I Want to Buy Correlation” or How NOT to Pick a SIEM?
• The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?
• Logging, Log Management and Log Review Maturity
• Log Management + SIEM = ?
• On SIEM Complexity
• SIEM Bloggables: SIEM Use Cases
• Whitepaper with detailed SIEM use cases (using a particular SIEM as an example)
• Log Management / SIEM Users: "Minimalist" vs "Analyst"
• All posts labeled SIEM

Fun Reading on Security and Compliance #12

Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security AND Compliance." Here is an issue #11, dated Feb 20th, 2009 (read past ones here). I admit that some stuff has been sitting in my “2blog queue” for way too long, but you know what? If it is relevant after a few weeks of “cooling down,” it is even more worth reading :-)

1. An instant classic “The Security Laugh Metric” by Ben: “The laugh metric indicates a manager's lack of understanding of risk when presented with a security issue. For example, when a reasonable security recommendation is followed by a loud laugh, expect that the manager is probably only mildly aware of their security risks.”
2. PHPbb “0wnage” – a fun read. Main content, some fun comments and password analysis. BTW, “password” is still a king of passwords :-) “In any event, "cocacola" appears to be more popular than "pepsi" among those who choose passwords.”
3. Ben’s “instant classic” – “Are You Addicted to Information Insecurity?” Fave quote: “While smokers' actions are driven by cravings for nicotine despite the health hazards, information technology's actions are driven by users' desire for easy access to data, usability, and quick deployment, with a disregard for confidentiality, integrity and availability of that data. These organizations typically know the risk of giving short shrift to security (many have even been bitten by data breaches and malware outbreaks), yet continue with their insecure ways despite clear evidence of its hazards.”
4. UK “infected hospitals” (here and here) is kinda disturbing. Would you prefer your surgical equipment crashed by a Windows Update OR by a worm, huh? Fave idiotic quote: “Mytob, which also goes under the name MyDoom, was introduced "accidentally" into the network with "no malicious intent," the report concluded without providing details.” This whole situation remind me of Dave Rice’s “Geekonomics” -  a clear route to clinical paranoia…
5. “Thinking Strategically about Information Security Metrics” we all know that metrics=fun, pretty much.
6. From the “not good” dept: “Kaspersky breach exposes sensitive database, says hacker."  What can I say? SQL injection works! :-(  “A security lapse at Kaspersky has exposed a wealth of proprietary information about the anti-virus provider's products and customers, according to a blogger, who posted screen shots and other details that appeared to substantiate the claims.”
7. “Why doesn’t the security industry like regulatory compliance?” is pure gold. But then again, what do you expect from Mike “PCI DSS is my license plate” Dahn? :-)
8. Mike Rothman on “Selling Fear,” a must read. Yes, FUD is alive and well (and useful at time for both infosec pros and vendors) - “Why not remind the customer they could get hit by a bus? Of course, I hope not - but it could happen.”
9. Fun reflections on why a security startup died are here. Quote: “Whoever heads sales must be highly proficient in motivating sales people and ensuring that sales efforts are always on track. This person is in my mind the most valuable person in a software company.”  and “Ensure that you have a sufficient nucleus of highly proficient developers and quality assurance staff. ” Material like this makes perfect “reading between the lines?” :-)
10. ATM theft case here (“Largest Coordinated ATM Rip-off Ever Nets $9+ Million in 30 Minutes”) via Mike R: “… in reading James Heary's analysis of the event, my blood ran cold. This folks is the future of crime. It's kind of a "clicks and mortar" approach to crime.”
11. Mike Fratto kicks some ROI butt in “ROI Is Not A Good Justification For Security;” some sore vendor ass tries to argue and Mike beats him up :-)  Time for a 3rd ROI war to commence?
12. Discussion of “full-auto” patching is baaaaaack: “Should Microsoft Take You out of the Patching Question?” Fun quote: “I have no business making your patch decisions for you and neither does Microsoft. It's your job. And if your decision not to rush the MS08-067 patch resulted in a Conficker outbreak in your enterprise, well you and whoever else is responsible deserve to suffer the consequences. It's not Microsoft's fault; they made a patch available and told you how serious the matter was.”   I think we ARE ready for full-auto patching in SOME products.
13. Laura’s musing on FISMA are here: “An agency could have exceptional security in place, but if the security mechanisms, controls, policies, and procedures are not well documented, or incorrectly documented, there is a good chance the agency could receive an F. Keeping that in mind, an agency that receives an F could possibly even have better security than an agency that receives a C or a B. If you have mediocre security in place, but you document the security controls, policies, procedures, and contingency plans at least well enough […], it is altogether conceivable that you could receive a better grade than an agency that has nothing documented, but has sound technical security controls in place.” Fun!
14. Love or hate survey, here is one more: “Latest Javelin Research Shows Identity Fraud Increased 22 Percent, Affecting Nearly Ten Million Americans: But Consumer Costs Fell Sharply by 31 Percent”
15. Gunnar Peterson sadly reflects in “Why Start Now?” that time to revisit old security models is NOT now, but 9 years ago :-) And flashes his now-legendary “firewalls+SSL” chart…

Special compliance section:

1. First, “PCI Experts Around Every Corner,“ a fun read.
2. Martin on “Evaluating the cost of PCI” has some fun links to think about: “When I was a security manager, I loved PCI because it gave me a really good reason to spend the money on the technologies I knew needed to be in place.” Another good one from him is “Are credit cards worth the risk?” with this useful reminder “Realistically, the option of ignoring PCI is there, but it’s something that is almost guaranteed to bite you eventually, not to mention the ethics and morality of a security professional ignoring security compliance.”
3. “pci actually never fails” argues with some of the points made  in previous PCI writing.
4. A very nice intro to PCI DSS 1.2 is “PCI DSS v1.2 in a Nutshell”
5. Thanks for reminding us that “The true intent of PCI compliance is NOT to pass an audit.” It kinda belongs in the Heartland saga (1,2,3,4), but I am not, NOT, NOT doing “On Heartland V.” Quote: “If PCI DSS requirements are implemented according to their true intent—improve security to reduce risk of compromise—we should seldom hear about massive breaches and data compromise from organizations that passed their PCI DSS audit.”
   

Enjoy!

Watch Ma .. A Blog Fight!

Always a suckler for a good blog fight! A subject is a bit dumb (“Is security a cost center?”), but still, this one is fun to watch:

1. McAfee, who should know better, starts it: “Is information security compliance really a cost center?” - “No. Absolutely and unequivocally not. I am drawing the line in the sand.” Read the rest here, even though it gets t sound pretty darn stupid at times (example: “ … makes it obvious that it is better and more efficient to be compliant as a business” – uhu… go tell it to all the small businesses trying to avoid PCI DSS)
2. First, Hoff kicks them in the balls (in their comments, no less): “If security compliance isn’t a cost center, are you then suggesting it’s a profit generator? So on the balance sheet it shows up as a revenue generator or profit center?”
3. Next, enlightened-not-insane Mike Rothman dropkicks them in “Compliance is SO a cost center” – “OMG. I figured a big company like McAfee would have a drug testing policy, but evidently not. I want some of what this guy is on” and even “A "Compliance Driven Company" is the next Heartland or TJX”, “CEOs don't care about security or compliance” and – fun! – “And even better, they don't want to spend money on avoiding either of those cases because it's not going to happen to them. Seriously. They see the headlines, they ask some questions about whether they are "secure," the CSO lies to them, and they go back to their mahogany conference room and check on the sales numbers.” He then ends with “Like I said, Little Red needs to check what's in this guy's water bottle. It ain't water.“
4. Finally, Pete runs, jumps in the air and lands on the McAfee guy ("Security Insights Draws Security Incite"): “It is entirely misleading to suggest that "information security compliance" is NOT a cost center. That smacks of a misunderstanding of exactly what a cost center is.” He then again jumps and lands with “I have a HUGE problem with this statement: "...a good business leader needs no justification to do to the right thing." It is so laced with b.s. that the cows are lining up in the barn waiting their turn.”

Enjoy! This whole thing makes me so want to kick them too, but I think there is a law against kicking the dead horse or something :-)

Also, this sooo reminds me of the ROI wars last year.

I will add to it, if this grows.

Fun Reading on Security and Compliance #10

Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security AND Compliance." Here is an issue #10, dated December 8th, 2008 (read past ones here). I admit that some stuff has been sitting in my “2blog queue” for way too long, but you know what? If it is relevant after a few weeks of “cooling down,” it is even more worth reading :-)

1. “SOA Security in Real Life” – if you have to read up on SOA security, you really MUST do it at Gunnar ‘s site :-) Fabulous quote: “Infosec is spending waaayyyy too much time and money protecting garages and not enough protecting assets.”
2. Bad? Buahahaha. “When it comes to offensive information security, we ain't seen nothing yet,” opines Dave Aitel (he is probably right :-()
3. Are you “secure” ONLY because you didn’t let your auditor see your FAIL? The ugliest “security by obscurity” revealed. A quote: “Can a company be at the forefront of security and still maintain a cost/profit/edge over the rest of their market?”
4. SaaS security fun: “You versus SaaS: Who can secure your data?”, “Cloud Providers Are Better At Securing Your Data Than You Are...”,
5. Mike Rothman vs eBay fraudsters, an epic battle (a spoiler: Mike wins :-))
6. “Myth or truism? Security experts judge conventional wisdom“ – it is from NetworkWorld, but it not that bad, actually :-)  It does contain some peculiar bits of “weirdom:”  “Q: Regulatory compliance is a good measure of security.  A: Lacey: Yes, it is. I have always found a direct correlation between the number of controls implemented and the level of incidents and vulnerability. Selby: (laughter)” This one is fun though: “There are lots of ways to measure security ROI, all of them flawed.” Guys, care for another ROI mudfight? :-)
7. Fun insight from Gartner on ‘security as insurance’: “Is Information Security Spending At All Like Insurance Spending?” (picked via Mike R here)
8. Does your business depend on intellectual property (IP)? Duh, isn’t [almost] everybody’s?  Well, “Intellectual Property: Develop or Steal” reminds us that if your competitors decide that stealing is cheaper  than developing a particular IP, then steal it they will (well, maybe in US most won’t, but in some other countries most definitely will…)
9. I am sure everybody read Rich’s “Don't Fight the Future. No????!!!! GO-READ-NOW! Yes, it is that good!
10. “Finally, “On the difficulties of event correlation”: “You wouldn’t know it by the number of vendors and products on the market, but event management and log correlation is really, really hard.” – it also describes it as “woefully inaccurate” and “stunningly misleading in some cases.”

Special “PCI DSS is fun!” compliance section:

1. REALLY insightful post from BeastOrBudda: “PCI DSS Compliance Projects - The road to nowhere….” I do disagree with a few pointers there (e.g. that “all PCI projects are security projects” – I think NOT enough of the PCI projects are security/risk management projects!); otherwise, it is golden. A quote: “If anything, PCI DSS has demonstrated that across the world, very few organisations have ever taken security seriously.”
2. “International Challenges in PCI Security” from CSO Magazine.
3. A VERY interesting discussion on PCI “in the cloud”, MUST read “Please Help Me: I Need a QSA To Assess PCI/DSS Compliance In the Cloud...” and then MUST read “PCI Compliance in the Cloud: Get it in writing!” and then MUST read “Cloud computing security and PCI.” Also, MUST read the discussions for these; it is actually not as esoteric as it seems (albeit, pretty darn esoteric still :-))  When you are done, read this too.
4. “Do someone know who is responsible for checking the merchants self-assessment questionnaires from the PCI-DSS program?”  He-he, uh, no :-) [this means “nobody apart from your acquiring bank, in most case”] Fave quote: “If you mark an SAQ as 100% compliant and have signed it off yourselves, the acquirer will not do any further checks.“ :-(
5. Actually fun: PCI word cloud. Notice the big word in the center? VERIFY!
6. This almost beat the “fire extinguisher–as– firewall” story: “One day he received a deduction from his deposits in the amount of $130 for “PCI compliance”.  He called up his gateway and found out it was an automatic charge for an online form he had to fill out.  He filled out the form and it turned out he failed compliance.  Why?  Because when asked “do you have a bonded company take your backup tapes off-site” he said “No” because it did not apply to his business.  So he called the gateway back and they said to “Fill out YES to every question so you can pass.””
7. Dave Taylor’s “Are Your Stores Worth Stealing From?“  BTW, I am amazed that so few people know about the PCI Knowledge Base at KnowPCI.com. There is some really useful stuff on PCI.
8. Another time, another smart guy reminds everybody “Beware PCI DSS Compliant solution vendors.”  Scammers are out there though. A good quote: ”The purpose of PCI DSS is to reduce risk. Risk can be reduced by reducing complexity. Increasing complexity increases risk.” If you don’t heed this advice, I got a PCI-compliant bridge to sell you!
9. While we are on the subject, more noise and PCI and virtualization (nowadays, I guess, no paper that a) fails to mention Hoff and b) mentions virtualization has any credibility :-))
10. Old news, but an important reminder: “QA for QSAs” is finally here. If you are a shady QSA, hopefully the council will find you and kick your ass. Or, “arse”, if you are in Europe :-)

Enjoy!

Second ROI War

Another day, another security ROI blogwar.

• "Schneier on Security ROI": "It's a good idea in theory, but it's mostly bunk in practice." and "The term just doesn't make sense in this context."
• Richards adds to it: "Schneier Agrees: Security ROI is "Mostly Bunk""
• "Security ROI - The debate continues": "ROI ... reared its ugly head."
• "FOI, Failure of Investment": "Not that you asked, but IMHO: ROI and TCO are SWAG at best. And, they are rarely at their best." The secret weapon of ROI war - FOI - is thus unleashed!
• "Yet more evidence: your CISO needs an MBA" - a very good view of ROI as "comparison tool", nothing else.
• "Can you get ROI from reduced costs?" - a key missing piece for "ROI puzzle", so-called 'return in the form of savings' is finally (!?) clarified by Pete Lindstrom.
  
• This is also very relevant :-)

Overall, I love it when educated peoples' debate just falls waaaay down to the level of "I won't care what YOU call it as long as you don't care what I call it...." Yuck! :-)

All security ROI coverage is tagged here: http://delicious.com/anton18/ROI. The previous, "First ROI War", is summarized here.

ROI Jokes?

Yes, they ARE possible.

This also remind me of "ROI for compliance" stuff.

Instant Classic: A First Coffee Machine Hacked Remotely

s- what else can I add?

Hack my coffee -> security taken seriously; screw ROI.

OMG, Security ROI Comes Back - And It is Mad As Hell :-)

OK, not really mad :-) In fact, pretty intelligent :-) But a new salvo has been fired in a "great security ROI war." Counter-salvos have been fired as well :-)

The salvo is the paper called “The Fallacy of Information Security ROI” by Jon Pols ("ISSA Journal", February 2008) where Jon argues against the ROI for security (since there is no money earned by security, just saving which are NOT the same thing); Jon proposes "security as insurance" model which, in all honesty, I am not too comfortable with (since security doesn't "pay you back" after the breach).

ROI proponents "hit hard" in return: 'One is Jos Pols who, in his recent article “The Fallacy of Information Security ROI” in the February 2008 issue of the ISSA Journal (membership required to access link resource), claims that one cannot have a return where there is no income. .' They next bring back the "return in the form of savings" (which many disagree with ...): 'this is an overly restrictive view of the meaning of the word “income.” The avoidance of potential losses redounds to the bottom line, as does revenue, so that a cost saving is a return on an investment.' Read the whole pro-ROI counter-point here.

Previous "ROI War" is cataloged here. A new one is upon us? Unholster your handguns, charge the lasers, enrage your attack hamsters - hurraaaaaaaah!!!!! :-)

The Entire Security ROI Blood Trail

FYI, I am recording (for posterity?) the entire security ROI "blood trail" via del.icio.us here ...

ROI, ROSI, RROI and Harry Potter Tales

OK, let's step back a bit and review what was said in the latest installment of the Great ROI Saga ...

In response to Richard's post, I thought and said that: "So, let's see whether you can compute (and thus "have") a rate of return on buying a security product. Sorry, the economics answer will be a solid 'no.'"

Ken Belva then argued (using Dr Gordon as an information source) that: "those who argue that you can compute an ROI for information security investments are technically correct." However, he mentioned some minor "measurement problems."

Pete Lindsrom first opined that: "I really don't understand why people are so threatened by the notion of ROI in security. Why on earth should they care whether someone can leverage the concept in support of their security goals? [...] I would suggest that since you can reduce recurring costs with, say, a patch management solution, you are contributing to higher net income and therefore can get ROI." and then added a few fun pointers in his piece called "Ten Points about Security ROI and ROSI": "ROI in security typically comes by reducing your existing, known cost basis such that the net profit (in the broadest sense, of your organization) is higher. These are real costs that show up, or will show up in the case of anticipated ROI, in an organization's financial statements." He then adds his own firewood ....eh ... term to the fire: ROSI.

Iang on FC blog stated that: "The issue here is a simple one of negative numbers and the distinctions between absolute and relative calculations. [A.C. - huh?] [...] Calculating ROI is wrong, it should be NPV. If you are not using NPV then you're out of court, because so much of security investment is future-oriented. [...] Predicting the "savings" from a security investment is hard." Hopefully, somebody got that ...

Mike Murray first said that he hates ROI, mentioned a spherical horse on a vacuum :-) and then added: "How much does my business increase its net profit because I have purchased this technology/implemented this process/bought more toilet paper/hired this person/etc.? - Ask that question, and the debate about whether you call it ROI, IRR, Rate of Return, Cost Reduction, or any number of other things goes away."

Chris Hoff chimed in with a sensible: "It seems that the unofficial scoring has the majority of contributors to the debate suggesting that Security ROI does not exist...sort of. The qualification of the word "return" really seems to be the important lynchpin here as contribution (margin, profit, etc.) versus cost avoidance really is what sends people off the deep end." Also, he issues a pacifying line: "If they want ROI, then fine...define the "R" appropriately and move on." He then piles his own firewood ....eh ... term to the fire: RROI.

Richard then summarized with: "I am only concerned with the Truth as well as we humans can perceive [A.C. - italic is mine here and above] it." But nobody else seemed to :-)

In other words, the above "discussion" tells me that one can use whatever term to call whatever thing nowadays: it is indeed a free enough country (nobody will stop you, no matter how stupid you will look while doing it!)

Overall, if you want to call an apple "an orange," I am not the one to stop you. If you insist on calling security savings or other financial benefits from security "ROI", I am not the one to stop you. Still, I would prefer (and will use ;-)) the term "fake ROI" since it is certainly not what the finance and economics books (and people) call Return on Investment...

Now, some of you may be wondering, what the title of the post has to do with its content. Alas, this is left as an exercise for the readers :-)

Technorati tags: security, ROI

More on ROI

This made me think of the following re-phrase of well-known joke:

Q: Can you fit 100 angels on the tip of a needle?
A: Man, this is sooooo hard! Those pesky "measurement problems" get in the way ...

More fun ROI stuff to come soon (of course!)

Security ROI Pile-Up!

So, another day, another security ROI fight. Let's first review what was said so far.

Richard said: "Digital security is not a line of business. No one practices security to make money. Security is not a productive endeavor; security risk is essentially a tax instantiated by the evil capabilities and intentions of threats. Because security is not a line of business, the performance incentives are not the same as a line of business. Security has no ROI; proper business initiatives do. Only security vendors make money from security." (in the past, he also said this: "There is no ROSI (return on security investment). There is simply cost avoidance. Due care is a concept I am more likely to embrace.") And also: "It's important to remember that there is no return on security investment. Security is a cost center that exists to prevent or reduce loss. It is not financially correct to believe you are "earning" a "return" by spending time and money to avoid a loss."

Ken countered: "My friend in the financial risk department read Richard’s statement that “Security does not have an ROI” and he laughed. He commented, “Just let some hackers change some numbers in a banks financial system and you’ll see that security has ROI.” That’s a finance guy talking, not an InfoSec guy."

David countered the above with: "It happens that I do agree that security can have an ROI, but the scenario given is not an example of that. It's an example of loss prevention and, to a certain extent, business enablement (to enable the bank to survive, which it really wouldn't if any Joe could log in and change account balances at will)."

Seeing all this stuff, Richard closed with: "The problem the "return on security investment" (ROSI) crowd has is they equate savings with return. The key principle to understand is that wealth preservation (saving) is not the same as wealth creation (return)."

However, before jumping in the fray, I figured I'd accost the economics talent I have available right in the comfort of my home :-) In the past, most of my stories of what some security folks think about computing ROI caused her to go into fits of unrestrained laughter...

First, unlike Wikipedia in the past, Britannica doesn't even have an entry for "return on investment" (and now, neither does Wikipedia - the links point to an entry about "rate of return". Along the same lines, "Principles of Corporate Finance" by Richard A Brealey, Stewart C Myers only mentions "book ROI" (in Chapter 12) as a very specific, narrowly-used term, which has little to do with this discussion. Rate of return, however, is mentioned as a performance measure of a business.

So, let's see whether you can compute (and thus "have") a rate of return on buying a security product. Sorry, the economics answer will be a solid "no." And, in fact, Richard's explanation fully passes the "test by an economics Ph.D." - indeed, security products save money, not earn money (obvious exception: security vendors) and thus there is no "return." The phrase "return in the form of savings," that I saw on some blog, caused my "in-house economist" to utter a completely unprintable word and then follow up with: "what an idiot! it is either return or savings!"

To take this further, when use of a security product is mandated by a law, all these "return rants" should stop: in this case, it becomes "sunk cost" (like license to do business, patents, etc which are never featured in return calculations).

Moreover, one cannot compute a "rate of return" on something that will not be making money on its own. For example, a stock or bond sitting in your safe has a "rate of return," while your "investment" in a chair that enables you to work on your computer does not, even though it enables you to work.

Thus, here goes the SiteKey example? Any "rate of return" calculations here? Sorry, still "no". The reason is that providing security tokens for site access is not making money on it own, but only when combined with bank's core business i.e. banking. Imagine this bank will stop banking services and will just try to "sell SiteKey to access its web site," can they earn a return then? If "no", then the answer to the original question is still "no." "Enablement" is still not earning, at least, not in the economics/finance.

At the same time, I think this debate will be resolved thus: there is rate of return (definition from economics) and there is "ROI/rate of return" (hijacked definition that developed its own life and started to mean simply "usefulness" or "value proposition") There is "ROI" of security and there is no ROI of security...

Related posts:

ROI on Not Getting Your Ass Whooped

A Passing Comment on ROI of Security

ROI, FUD, Selling Security and Relevance

More on Security ROI or ROSI (rosy? :-))

ROI, FUD, Selling Security and Relevance

This whole thing started with MJR podcast #2 called "Codependence", continued by the squeals here :-) and then culminated by a thoughtful post here followed by just-as-thoughtful comments.

One of them says: "Security may never be a clear vision to mgmt beyond compliance, negligence, and regulations [AC: kinda compliance as well ...]" and further "if there is no benefit to the company other than as an insurance role, there is really not much hope beyond a CYA approach."

Well, so? :-) That is actually a lot! If security is made mandatory, all this ROI hoopla will subside. FUD will be gone. Other good things will happen (and some bad), but I would really not consider that scenario to be that bad at all ...

ROI on Not Getting Your Ass Whooped

So, what is the ROI on not jumping off a building? Do you, like, compute it before performing a "not jumping off a building act." Obviously, that is stupid.

Fine, let's try this one next - what is the ROI of not going to jail (and sharing a cell with whatever Bubba)? Well, most if not all people know that they must not go to jail, without doing an ROI computation, not even an ad-hoc one :-)

Then, why oh why, you are doing an ROI on compliance? If you have a well-defined regulation with a clear track record of pursuing its offenders, you don't just comply because whatever semi-intelligent "ROI computation" tells you to. You comply because you have to! You don't use a formula, you do it because you have no choice.

You can argue with the law and try to influence whatever lawmakers to make a new or a better one, but you follow it while it stands ...

A Passing Comment on ROI of Security

So, a colleague sent me this link ("3 Metrics To Gauge Security Spending") and I was meaning to think and blog about it (yes, in that order :-)). But then Mike Rothman opined that this guy is a dumbass in his blurb "3 ways not to gauge security spending". So, what's the story?

First, bear with me since I am still trying to build a coherent picture of security ROI for myself from all the diverse sources of info, some as smart as Pete Lindstrom :-) In general, I am leaning towards "there is no ROI for security; there are only cost savings" (which, as my in-house Ph.D. economist stated, are neither the same nor equivalent)

So, let's see, what is this guy suggesting: "If security spending exceeds 10%, your business architecture is probably poorly designed to cope with attackers." Huh? What's up with the magic number? So, 9.5% certifies you as OK? Sounds like an application of "all hard problems of the Universe have easy, clear and simple INCORRECT solutions" :-)

Further, "If the cost of your security investment is 200% or more of the value of employee downtime, you may be spending too much on security." Same problem - see above, bro.

Going down, "If you are experiencing a loss of 1% or more in productivity, review how you are protecting your information." No comment, really. Wait, one, actually: bullshit.

And, on top of the above, I just hate it when people proclaim something truly obvious as if it were some kind of news, so this guy definitely commits this crime: "The goal of total security is not achievable in complex systems that have millions of hardware and software vulnerability points." Wow, that's deep, good thinking here... NOT! :-)

So, I am with Mike on this one and he said it best: "These "metrics' will do nothing but waste your time, except maybe the gauging the cost of downtime one. I can only hope your CIO didn't read this drivel, because then you'll start to see this crap on your 2007 MBO's."