July 24, 2007

If your CSO lacks an MBA, fire one of you

Thinking a bit about the theme of security v. management [1,2, 3], here is today's thesis:

The CSO should have an MBA.

As a requirement! Necessary (but maybe not sufficient) for the Chief Security Officer job.

That being a slightly contentious issue, as most of y'all CSOs out there don't have an MBA, the onus is on me now to prove it, or swallow humble pie. Well, this is the blog for being years ahead of the trends, so let's get on with it then.

Consider some factors.

  1. No understanding. Frequently heard are the brickbats that accuse managers of doing stupid things. See if you can find a non-security guy doing or saying something sensible! It's quite simple for us to state why this happens: non-security people don't understand what the security guys are talking about.
  2. No Voice. It's been grudgingly accepted for some years now that security people are not listened to. In the sense that your chief security dude can rabbit about any threat or any project and get nowhere.
  3. Failure. It is a no-brainer that today's security field is a mess. Windows botnets, Linux attack platforms, spam and phishing, MITBs, unholy virus company alliances... these things run rampant and we can't do much about them. Worse, those that predicted it were ignored, those that sold stuff did well, those that rode the wave from flavour to favour did best. We now have a permanent and industrialised degree of fraud that belongs to the security industry, in place, which Lynn suggests in comments is better than drugs. Oh happy day, full employment for the CSO.

Maybe, 1 and 2 are opposite sides to the same coin, and spending that coin got us to 3. Which brings us to this point: we can pretty much assume that there is a huge gulf of understanding between the security world and the business world.

In order to fix all this, we have to generate understanding.

(Either that, or switch off the systems. Now, the security guys sometimes say exactly that, but the business guys don't listen, so we're back to looking at the real problem.)

Assume then the basic failure is one of understanding. We can do one of several things: train all the managers in security, train all the security people in business, or put in the middle a liaison who knows both security and business.

Let's kill the two easy options: Managers by definition know a little of everything, enough to be dangerous, and do not get trained up much in anything except whatever their original skill was. And for your average manager, those days of early skill training are over.

The second easy option is training the security people. But, that's a hopeless task. Firstly, where they come from, they have little background in business (generally, from IT. Worse is cryptography, better is military, for business exposure at least.). Secondly, it's a full-time job keeping up with just security, let alone learning stuff about business. The reverse difficulty could apply to managers, option 1 above.

Which leaves option #3: the liaison. Now, we can pretty easily see by process of elimination that the liaison has to be the CSO. So the question reduces to: what does the CSO need to be a successful liaison between security and business?

He needs the full capability to talk to the managers, and the security people. The latter means he *is* a security person, because by the law of guruism, to gain the respect of the gurus, you have to be one of them. The former means he *is* a manager.

But we need to go one step further. Because security cuts across all areas of the business in the way that HR, marketing, auditing, customer support does ... and transport, printing, sales, cleaning do not ... then the security honcho needs to understand a lot more of the business areas than the average manager does.

See the difference? Because security is against an aggressive attacker, because attacks can occur anywhere, the problems are broad and complex, and because the solutions strike across all areas, then .... if our CSO hasn't the skills to talk each manager, at her level, on her turf, not his, then he's lost.

There are only two ways that I can think of to get the knowledge to be able to talk at the same level as all of the other managers: Either you go fast-track, which means being shoved from department to department, 1-2 years each one, or you can pick it up in a condensed package called an Masters of Business Administration. The former is done, but it takes decades of time in either a very large corporation or the military. Scratch that as an option, as it also means our CSO won't be up to scratch as a security person. Hence, we are left with one option:

The CSO needs an MBA.

QED.

(Which will still cost you minimum one year; full time MBAs are generally 10 to 22 months, part time ones are up to 36 months ... but that's implementation details).

(Addendum, for scoring easy points against the above logic, Disclosure: I have an MBA :-) ) If you want to read more of the devil's advocacy, try:

Posted by iang at July 24, 2007 11:25 AM | TrackBack
Comments

Hi Ian,

lots of possible comments here, but due to limited time, just a short one.

The first question is, what is the typical education of a CSO and what are the topics of his studies? From what I see out there when looking at the arising generation of CSO's the typical education is a university study to get a Master of Science in the field of applied IT security. Does't sound to bad until we look into the topics: that's about 80% cryptography, 10% OS security, 5% legal issues and 5% rest. Nice for doing the technical part of the job, but understanding business needs and being able to talk to the company managers? Not at all! Adding an MBA on his education list? Sure, that's a possibility. But will he get a better job or a higher payment by doing this? Unlikely, as the managers do not understand the need for it. So is it likely he will spend this additional 2 years? I think it isn't. So rather than suggesting an MBA addon, I would suggest that universities should open their eyes and accept that those M.Sc. are going in the CSO field and need some management crash course. Leave 10% crypto out and add management in it and life would be way easier.

If we look at large enterprises, the situation is completely different. Their CSO is usually a guy who worked in a management position in an IT area for years, than added some more security knowledge to take the step for besoming CSO. Those guys have the management knowledge they know how to address security topics to the management. But: you cannot get such a guy out of university and there aren't enough of those guys available on the free market to fulfill the current demand. So let's stick on (1).

Regards
Jens

Posted by: Jens Paul at July 25, 2007 08:23 AM

It makes perfect sense.

But then, I have an MBA too.

Seriously now, everybody has a guru filter, not just the tech folks. It's just that the business manager's guru filter involves a different language. An MBA is a simple first-order test, helpful but not sufficient. Survival and some credibility-building experiences come next.

Posted by: Liudvikas Bukys at July 25, 2007 09:25 AM

Agreed. I'm not an MBA, tho I do have 1/3 of one (hadda quit for financial reasons). I've also run my own business for few years. And worked both sides of the business service desk. Probably the most useful skill I've had is the ability to make and describe risk decisions that encompass the technical threat and the business implications. It buys me a lot of traction for both the geeks and the suits.

Posted by: planetheidi at July 25, 2007 01:02 PM

"security" isn't just limited to things like defenses and countermeasures against attacks and fraud ... security supposedly includes things like assurance, availability, correctness, etc.

there was a recent thread in mainframe discussion about the general issue of "quality" (and quite a bit of it is the related costs).
http://www.garlic.com/~lynn/2007n.html#76 PSI MIPS
http://www.garlic.com/~lynn/2007n.html#77 PSI MIPS
http://www.garlic.com/~lynn/2007n.html#79 PSI MIPS

i've mentioned before that we were called in to consult with small client/server startup that wanted to do financial transactions on their server (frequently now referred to as electronic commerce) misc. past references
http://www.garlic.com/~lynn/subnetwork.html#payments

the startup had this technology they called SSL that they wanted to use in conjunction with the financial transactions. some misc. past references
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
and some comments about general state of domain name certification and related PKI operation
http://www.garlic.com/~lynn/subpubkey.html#catch22

however, as noted in the referenced thread (somewhat on general quality issues and related costs) ... a lot of what we did related to server financial transactions drew on having earlier done ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

which included some very detailed vulnerability studies (which were not limited to just attack & fraud defenses and countermeasures)

Posted by: Lynn Wheeler at July 26, 2007 07:18 PM

re:
http://www.garlic.com/~lynn/aadsm27.htm#47 If your CSO lacks an MBA, fire one of you

the previous post and references allude to higher quality
implementations costing more ... and frequently there have been
direction to go for lowering costs without a whole lot of attention to
what happens to the costs (and security, integrity, assurance, etc).

there was also a passing reference to mainframe operation having some
feature/function that actually lower the total cost of achieving
higher quality implementations.

the other place that this shows up in has to do with the effects that
some of the tools and building blocks have on overall quality,
security, integrity, assurance, etc.

for instance in these posts mentioning buffer overflow (and associated
exploits/vulnerabilities)
http://www.garlic.com/~lynn/subintegrity.html#overflow

... there is a repeated assertion that a lot of it is due to the use
of C programming language ... that implementations done in some other
languages have drastically lower occurance of overflow-related
exploits/vulnerabilities. for instance, these posts reference a
security evaluation of multics (implemented in pli) that found no
overflow exploits/vulnerabilities
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation

also, these posts mention initial mainframe tcp/ip product being
implemented in pascal/vs ... which also had no buffer overflow
exploits/vulnerabilities (that i know of). however there were
performance issues in the initial implementation ... however i had
done the rfc 1044 implementation which achieved about 25 times the
thruput in about 1/20th-1/30th the pathlength (around three orders of
magnitude improvement)
http://www.garlic.com/~lynn/subnetwork.html#1044

another reference to attempting to improve the assurance/integrity of
the building blocks is having done a one week JAD looking at what
could be done in Taligent infrastructure to significantly improve the
quality of the resulting applications (taligent was an object oriented
programming environment ... somewhat an outgrowth of apple's attempt
at an object oriented operating system, pink)
http://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005b.html#40 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#38 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration

the original references have passing mention of it frequently taking
4-10 times the original application implementation effort to support
business critical application. somewhat related is common observation
that doing a "2167A" implementation takes ten times the effort as what
it frequently takes to do many common implementations. similar to the
taligent JAD, we looked at what software infrastructure changes would
be necessary to reduce the cost of 2167A implementation from ten times
to only two times. a few past posts mentioning 2167A:
http://www.garlic.com/~lynn/2001i.html#55 Computer security: The Future
http://www.garlic.com/~lynn/2002e.html#70 Computers in Science Fiction
http://www.garlic.com/~lynn/2004q.html#1 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
http://www.garlic.com/~lynn/2006.html#37 The new High Assurance SSL Certificates
http://www.garlic.com/~lynn/2006q.html#40 Was FORTRAN buggy?

for other random drift ... reference to giving keynote at
nasa high dependability computing consortium workshop:
http://www.hdcc.cs.cmu.edu/may01/index.html

Posted by: Lynn Wheeler at July 27, 2007 07:45 AM

> Hey Lynn,
> What is JAD?
>
> What's a 2167A :)

joint application development .... sort of a high-powered design session ... frequently have a person specialized in facilitating meetings/results running a jad ... wiki reference: http://en.wikipedia.org/wiki/Joint_application_development

....

here is picture of various processes ... including 2167A ... and somewhat how they are related: http://www.stsc.hill.af.mil/crosstalk/1997/09/frameworks.asp

more detail http://www2.umassd.edu/SWPI/DOD/MIL-STD-2167A/DOD2167A.html

wiki reference http://en.wikipedia.org/wiki/DOD-STD-2167A

Posted by: Lynn at July 27, 2007 08:52 AM

re:
http://www.garlic.com/~lynn/aadsm27.htm#47 If your CSO lacks an MBA, fire one of you
http://www.garlic.com/~lynn/aadsm27.htm#48 If your CSO lacks an MBA, fire one of you

long ago and far away, shortly after graduation and going to work for a large computer vendor ... they hired a new CSO ... who had come from a fairly high ranking gov. position.

This was back in the days before there was much computer security and large corporations frequently hired former gov. employees who's background were various kinds of physical security; actually this continues to frequently happen and then they might have a separate CSIO position

For whatever reason, I got assigned to run around with the new CSO for several months ... imparting some information about electronic kind of security and having a little physical security details rub off.

Posted by: Lynn Wheeler at July 27, 2007 01:25 PM

i wrote:
> Hey Lynn,
> What is JAD?
>
> What's a 2167A :)

joint application development .... sort of a high-powered design
session ... frequently have a person specialized in facilitating
meetings/results running a jad ... wiki reference:
http://en.wikipedia.org/wiki/Joint_application_development

....

here is picture of various processes ... including 2167A ... and
somewhat how they are related:
http://www.stsc.hill.af.mil/crosstalk/1997/09/frameworks.asp

more detail
http://www2.umassd.edu/SWPI/DOD/MIL-STD-2167A/DOD2167A.html

wiki reference
http://en.wikipedia.org/wiki/DOD-STD-2167A

... snip ...

re:
http://www.garlic.com/~lynn/aadsm27.htm#47 If your CSO lacks an MBA, fire one of you
http://www.garlic.com/~lynn/aadsm27.htm#48 If your CSO lacks an MBA, fire one of you
http://www.garlic.com/~lynn/aadsm27.htm#49 If your CSO lacks an MBA, fire one of you

it isn't just cso ... here is a number of posts discussing a major security failure in the financial industry. it was a bunch of techies that eventually spent truely huge amounts of money on attempted wide-spread deployments that met with disastrous results. the disastrous failures of the deployments resulted in a wide-spread opinion in the financial industry that hardware tokens (for authentication and security) weren't viable in the consumer market
segment.

the funny thing was that the seeds for the disastrous failures had been known in the financial industry for several years ... just in different parts of the organization i.e. for whatever reason, those responsible for the disastrous failures weren't able to draw on the institutional knowledge from earlier activities.

there is the old saying about those that don't study history are doomed to repeat the same mistakes.
http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
http://www.garlic.com/~lynn/2007n.html#60 Poll: oldest computer thing you still use
http://www.garlic.com/~lynn/2007n.html#63 Poll: oldest computer thing you still use
http://www.garlic.com/~lynn/2007n.html#65 Poll: oldest computer thing you still use
http://www.garlic.com/~lynn/2007n.html#66 Poll: oldest computer thing you still use
http://www.garlic.com/~lynn/2007n.html#75 Poll: oldest computer thing you still use
http://www.garlic.com/~lynn/2007n.html#78 Poll: oldest computer thing you still use

now while the direct costs of the disastrous deployments were significant, the 2nd order costs are quite a bit greater ... i.e. the dampening effect on deployment of effective authentication and security infrastructures leaves large open large vulnerabilities and threats
http://www.garlic.com/~lynn/aadsm27.htm#44 Threatwatch: how much to MITM, how quickly, how much lost
http://www.garlic.com/~lynn/aadsm27.htm#45 Threatwatch: how much to MITM, how quickly, how much lost
http://www.garlic.com/~lynn/aadsm27.htm#46 Threatwatch: how much to MITM, how quickly, how much lost


there may also be some x-over here with recent article on the success of failure
http://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/aadsm26.htm#59 On cleaning up the security mess: escaping the self-perpetuating trap of Fraud?

that with fundamental systemic flaws, industries can grow up that make a long-term business out of continuous fixing and patching ... aka like that systemic flaws found in the C language programming environment mentioned earlier in this thread:
http://www.garlic.com/~lynn/subintegrity.html#overflow

or the fundamental systemic flaws in the "naked transaction" paradigm
http://www.garlic.com/~lynn/subintegrity.html#payment

disclaimers:

... as mentioned earlier, we had done detailed vulnerability and threat analysis in the 80s, as part of doing ha/cmp product http://www.garlic.com/~lynn/subtopic.html#hacmp

the knowledge contributed quite a bit when we were called in to consult with small client/server startup that wanted to do payments on its server (they had this technology they called SSL, and the effort is now frequently referred to as electronic commerce)
http://www.garlic.com/~lynn/subnetwork.html#gateway

then in the mid-90s, the x9a10 financial standards working group had been given requirement to preserve the integrity of the financial infrastructure for all retail payments ... there were further detailed vulnerability and threat analysis (and we were able to also draw heavily on previous experience with ha/cmp and the original electronic commerce effort)
http://www.garlic.com/~lynn/x959.html#x959

it was in this period that we spent some amount of time on design of authentication hardware token with both extremely aggressive cost reduction and security improvement. it was some of the these other deployment disasters that also had downside impact on the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

we somewhat facetiously claimed that we were doing 2-3 order aggressive cost reduction on $500 mil-spec part ... while at the same time improving the security & integrity.

we also somewhat facetiously claimed that the per chip aggressive cost reduction and the work on person centric hardware token paradigm could represent an overall four order of magnitude cost reduction on an extensively deployed hardware token authentication infrastructure. misc. past posts mentioning institutional-centric hardware token paradigm vis-a-vis a person-centric hardware token paradigm
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
http://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging
http://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
http://www.garlic.com/~lynn/aadsm27.htm#23 Identity resurges as a debate topic
http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005p.html#6 Innovative password security
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
http://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
http://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?
http://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
http://www.garlic.com/~lynn/2007d.html#12 One Time Identification, a request for comments/testing
http://www.garlic.com/~lynn/2007l.html#8 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#9 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#43 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007m.html#27 nouns and adjectives
http://www.garlic.com/~lynn/2007m.html#31 nouns and adjectives

Posted by: Lynn Wheeler at July 28, 2007 01:54 PM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.