response-to-responses-incentive-plans-for

Posted by:

admin 15 years, 11 months ago

My recent (assumption laden and simplistic) post on incentive plans for an information security team was picked up by Adam and subsequently poked at by mordaxus and then piled on by Mike Rothman.

Here are some of the comments from Adam's post:

• Crap that's a nice observation. I wish I'd made it.
• I haven't read his post in full, so the artful inclusion of "if you agree with..." is an elegant fudge
• The fallacy of this whole argument is that "average" losses cannot be applied to any particular incident. Losses are dominated by outliers. ALE is information security's spherical cow.

First, thanks! Second, come on! You can read the post! Third, I don't buy that you should not prepare for the average loss just because there are outliers. If you do so, are you less likely to get hit by an outlier? I think so. It is like saying I don't need to save for retirement because I might win the lottery.

Here are my thoughts on Mordaxus's post:

Adam quoted some interesting thinking about infosec incentives. However, I'm not sure it's that simple.

First, thanks for the link love ;). (Makes me think, was the OP read...?)

Jan Willemson published a paper, "On the Gordon & Loeb Model for Information Security Investment." In it, Willemson directly challenges the 37% number. ....(abstract removed)...So here's the first problem -- that it may behoove one to spend more than 37%.

Now, I have not had a chance to read Jan Willemson paper, "On the Gordon & Loeb Model for Information Security Investment.", so I won't comment on that for now. However, mordaxus misses the point. Just choose a higher spending rate. Maybe you could even adjust it over time.

If there is a 2% chance that any of my employees will lose a laptop, there's a 40% chance that a laptop has personal data on it, and I have 10,000 employees, then I expect to have 200 employees lose laptops, and 80 of them are going to cause me a problem. That's bad. It is only another matter to take the Ponemon $182/name number and multiply that by the number of names, and I have a dollar figure. To me, the right way to solve this problem is to put some sort of disk encryption on those laptops. Just (heh, just) deploy that and Alice is your auntie. No incentive plan needed. As a last problem, do I really want to deal with an incentive plan? Incentive plans have evil senses of humor.

Mordaxus is confusing tactics (encryption) with incentives. The important thing to do here is to incent your people to want to care that the personal data is protected. Second, people already have incentives, you just aren't managing them. For a blog that whines incessantly about breaches of personal information, you would think they could see that some institutions needs better incentives.

If we also assume 100 people in the security department, if they come to my conclusion -- encrypt those laptops -- they will see $100 in their own pocket for every $1 they save on the software.

Not sure I follow the math. The total payout can't be more than the total savings. Some portion of the total savings would then be split amongst the team. But, the point is to have a balance in incentives. I suggested using smoothing and pooling to balance short term savings with long term goals. There are other ways to do it too. (Now I'm really starting to wonder if the post was read...)

It also creates in incentive to ignore breaches. If you're an admin looking over logs at a major university, and you think you see a breach, but aren't sure -- what do you do? Very likely, it's hope it isn't a breach, not investigate further. And how are you going to feel when the bonus you were counting on sublimates when Bob over there finds a breach two weeks before the end of the year. Thanks, Bob. Couldn't you have at least waited until January?

True enough! But: How does having a clearly defined and managed incentive plan differ from not having one? Is Bob more or less incented to disclose breaches now? Failure to disclose is against the law (often), so there is an incentive. It is managed by the state. Failure to disclose a breach should be grounds for dismissal. Suffering a breach despite having your best efforts should not. Conflicts will occur no matter what, at least try to manage them. You could have different incentives for different teams/people. An incentive plan does not operate in a vacuum. Employees are still managed, they get reviews, etc. It is just a tool. (Outsourcing log monitoring might help. Everyone hates outsourcers already. :)

Creating a system where the security team is not looking at security, but how little they spend is not good for security, nor is it good for the company.

That is clearly not what I suggested. I suggested a managed balance. I once pitched a company on switching from tokens to WiKID, which would have saved over $500,000 in token costs and potentially close to $2,000,000 in password reset costs. The response from the security guru: "I really like you solution, but we're not paid to save money." Where is the balance? That team only faced risk by switching and the shareholders suffered.

Security that liberates people is a cost on the security end, but a benefit somewhere else.

Information security creates value by decreasing the weighted average cost of capital (more here and and here). (Question: Are all the breaches at Universities and government agencies because they are target rich, or because their cost of capital is not affected by their behavior?)

Always, always beware when you set up incentives. People will act according to the incentive.

People always, always have incentives, so you are better off managing them.

As for Rothman:

I have a fundamental issue with the idea of capping information security expenses to about 1/3 of the expected loss. Now I haven't read Gordon & Loeb's book, so maybe there is a reason it's 37% and not 50%.

Your reading assignment is clear :).

• Tags:
• Security and Economics

Share on Twitter Share on Facebook

• ← Can the WiKID Server and/or Token be embedded?
• on-the-short-tenure-of-cisos-and-low-frequency →