Comments: more on firing your MBA-less CSO

note that in the naked transaction thread
http://www.garlic.com/~lynn/subintegrity.html#payment

... the discussion was that there are hundreds and thousands of places that card transaction details might leak ... including (but not limited to) past studies that possibly seventy percent of such leakages involve *insiders*. given the enormous number of leakage points, the naked transaction thread discussed armoring the actual transaction so that any leaked information became useless to crooks (i.e. the "card transaction" details could fall into the wrong hands, but they would find the information useless) ... ala what was specified for the x9.59 financial transaction standard
http://www.garlic.com/~lynn/x959.html#x959

i.e. in the mid-90s the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments
http://www.garlic.com/~lynn/subpubkey.html#x959

as to the recent disastrous reader deployment references:
http://www.garlic.com/~lynn/aadsm27.htm#49 If your CSO lacks an MBA, fire one of you
http://www.garlic.com/~lynn/aadsm27.htm#50 If your CSO lacks an MBA, fire one of you

note that there have been a efforts that aren't particularly CSO-related ... just techies ... in relatively the same time frame as the disastrous card reader deployments ... there were also some magnificent other disastrous security attempts in portions of the financial market segment.

in about the same time frame as disastrous reader deployments, there were some number of "yes card" deployments ... some discussion here
http://www.garlic.com/~lynn/subintegrity.html#yescard
the "yes card" scenario should have been evident to anybody familiar with skimming attacks (dating back at least a decade or so earlier)

also leading up to time frame of the disastrous reader deployments, there were still some lingering belief in the "magical" properties of digital certificates and misc. related pilot projects that came in at the $50mil range. the certification authority industry were making all
sorts of offers to the financial community (for scale-up roll-out after the pilot stage), if the financial institution would register a public key for each account in the master file ... and then provide a certification authority a copy of that master file ... then each account record would be magically transposed into a digital certificate at only $100 a pop per annum. This appeared to be acceptable to the techy community, until executives of some of the larger institutions (i.e. 10million or more accounts) started tallying the annual payments to certification authorities and shutdown the projects.

this doesn't even need to take into the consideration that the digital certificates themselves would be redundant and superfluous ... posts about relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
and certificateless digital signatures
http://www.garlic.com/~lynn/subpubkey.html#certless

a combination of the disastrous reader deployments, the ridiculous (projected) costs of the digital certificate (scaleup) efforts, the "yes cards" and misc. other activities ... contributed to financial insitution risk managers and executives starting to seriously question
the competency of "techies" (not particularly a CSO or CSIO issue).

the aggregate effect was (also) significant damper on being able to deploy any reasonable authentication and security technologies.

misc. past posts discussing the $100/account/annum proposition (minimum cost to the financial industry $20b/annum assuming only a single account/person ... again independent of the issue of whether the digital certificates were redundant and superfluous)
http://www.garlic.com/~lynn/aepay10.htm#72 Invisible Ink, E-signatures slow to broadly catch on
http://www.garlic.com/~lynn/aadsm14.htm#29 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm16.htm#16 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
http://www.garlic.com/~lynn/aadsm18.htm#52 A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
http://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm23.htm#29 JIBC April 2006 - "Security Revisionism"
http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
http://www.garlic.com/~lynn/2005o.html#2 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
http://www.garlic.com/~lynn/2007h.html#27 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007l.html#9 John W. Backus, 82, Fortran developer, dies

Posted by Lynn Wheeler at July 30, 2007 08:14 PM

Ian,

Of course security doesn't have an ROI. It's a cost centre, not a profit generator.

http://blog.secrisk.net/2007/06/return-on-investment/

It's a cost of doing, and staying, in business, that's all. Of course, we can stretch semantics this way and that, trawl for figureheads that support our point of view and claim victory - not that anything like that was done in the near past - or we can just live with the fact that we're a cost centre.

Other parts of the business? You mean, such as marketing? Who, incidentally, also complain that 'the business' doesn't understand them. Is it only me that sees a pattern forming here? Now, I know about marketing's issues with 'the business' because that's an old professional flame. I bet you a magnum of Chimay that if you spoke to HR people, you would hear similar complaints about 'the business' not getting it.

So who, or what, is 'the business'? Maybe we should define that first. Then we should stop behaving like we hold answers to everything and start listening. Then we should open our eyes and see that we're not unique and that we share problems with about 80% of the company. Then maybe, slowly, we can start talking to other departments about working together.

In short, I agree, CISO should have an MBA. For its networking value, not anything else.

Posted by Saso at July 31, 2007 12:47 AM

Hey Saso, you're getting hung up on the labels "return" and "investment."

Ignore those for a moment. ROI, and its more useful cousins, NPV or CAPM, are *models*. They take inputs. They can be used for one thing and one thing alone, reliably (given some assumptions). That one thing is to compare expenditures on projects with components of risk.

Note how the model itself doesn't care at all whether we are talking about profit centers or cost centers. That's because it is a model of comparison, and to models of comparison, your labels are totally irrelevant.

In the terms you are talking about, there is no ROI in ROI. That's because you are assuming a "return" leads to profits. No such, the model doesn't do that.

Think of it as horizontal comparison between projects, *not* vertical causality from decision to profits. An investment in the profit center with a positive ROI/NPV does not result in profits, necessarily, as that can only been shown by later accounting results, and those are also subject to additional filtering that results in further labelling. Your reliance on profits being driven by profit centers is built on a pile of post-it notes. If you want to be precise, the only profits are what are paid out in dividends, and these are not reliably traceable backwards to distinctions such as cost-centers v. profit-centers.

Posted by Iang at July 31, 2007 08:42 AM

Hi Ian,

You are right, I am getting hung up on those two terms. I've seen a number of freshly minted MBA's using ROI and expected *return* on their *investment* visible in a single financial year. Two years at the most. Why? Because that's what they promised. When that didn't eventuate, subsequent similar projects were shelved, because they didn't "add to the bottom line".

I agree with you that ROI is a tool. A much maligned, abused, and misused tool. And it doesn't give itself freely to many parts of the company for the simple reason you give - GIGO. So if we know that the tool is abused, shouldn't we use something else?

I hear you that ROI, NPV, etc are models. Problem is that they are used for something they're not fit for.

Again, I'd say that security, or IT, management isn't the odd one out for being misunderstood by 'the business'. We just think it is because we don't spend enough time with other parts of the company. Which is something that you called out already.

Your points are all well taken, I'm just afraid we're at cross purposes. I call it the way I see it (abused), you talk about it the way it should be.

Posted by Saso at August 1, 2007 01:15 AM

That's definately a criticism against MBA people if they promoted ROI as being a model to predict returns in a serious sense. Although, it also says something about the organisation if they believed such charlatan logic :) but what else can an organisation do? It has to employ the best people it can, then ... listen to them. Skepticism for all titles should be practised widely.

The thing about NPV (and if you must, ROI) is that they are tools with limitations, but they are the only tools for the job at hand: comparing expenditures. Other than that we are left with gut feeling. Which I would suggest is not exactly a tool, albeit is an essential component, as we need at least our gut feeling to tell us when NPV is not doing the right thing for us.

Yes, I also agree that the other areas of the business might be a mess. Advertising suffers from GIGO, and marketing isn't that far behind .. HR has its own peculiar problem: people employ psych graduates to fill these positions and assume that makes sense. I don't think so, because the component of psych is too small to make a positive difference, but it can do harm.

Posted by Iang at August 1, 2007 10:47 AM
Post a comment









Remember personal info?






Hit Preview to see your comment.
MT::App::Comments=HASH(0x559a73228e20) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/Object.pm line 125.