How would you reason with and work with the security paranoiac on your team?

Question

The question of how to balance pragmatism with an absolutist view of security has been discussed here already. But I need the answer to a concrete variant of that question.

You're the security expert hired to help an application team with the security problems of their app. One of the members of the team takes the "good enough just isn't good enough" approach, and wants to implement the perfect security system. He's already decided that the platform the product will run on is fundamentally insecure, and will repeat this assertion when there's anyone listening (and even when they'd rather not). Any proposed mitigation strategy is not good enough. He's not interested in identifying and reducing risks to the activity supported by the product; he's interested in absolute security. Sneaky ways out of the problem like the fact that the project has a finite budget and finite expected revenue will not fly: it needs to be done completely or it isn't worth doing.

Unfortunately, this person has the ear of the senior management team, so appealing to authority is not going to work. The project has stalled because discussions of the security requirements are just spinning around with no resolution. How would you move things on?

Answer 1

Consider the usual risk management statement:

Don't spend 1000$ to protect 100$

Now, it might just be a situation that the execs are not aware that what they want will cost 1000$; more likely that they just don't realize that they're only protecting 100$ worth.

If that is the case, you could consider trying to implement methodology that will provide some hard numbers, to replace the vague feeling of uneasiness that can accompany the fear of the big scary word "SECURITY".
If they want to be fiscally responsible, they should try to understand the actual costs, risks, and benefits. I would even try to have that discussion with them without using the word security, which just seems to be confusing and irritating them.

It is also likely that, since they dont understand it, they're worried about doing their due diligence, and/or can be held responsible (either personally or corporately) if anything goes wrong. They need to be shown how to do this effectively, and yet still be "good enough" - not to never be hacked, but to make it a fair tradeoff. Even if they do get hacked, they need plausible proof of having done their diligence, so as not to have their reputation damaged (or other similar fallouts).

I recommend using FAIR , which is a quantitative methodology for putting a price tag on specific risks.
Also see: "How do you compare risks...?"

Either way, this should enable you to change the conversation from the soft, prickly, uneasy feeling of "security", to a hard talk about costs, benefit, and money. Always bring it back to showing them the money.

---

Worst case, if nothing else works out, put together an expensive, phased, multi-year plan. Have it prioritize the important things, as you see them, and delay to later years the issues that you would have preferred to forgo.
In most orgs, the later stuff will never get done anyway. And even if it does, this way, you're still getting them to do the right stuff, and they're spending money on the feeling of security - which, sometimes, is important too.

Best part is, since it is in phases, you can build into the plan a re-adjustment step, between phases. Use this as a platform for a full security lifecycle... You can keep re-adjusting the unimportant phases as needed, to squeeze in other important bits.

Answer 2

Sometimes things must fail and this sounds like one of those times. As I read your situation you are in charge of securing a troubled project with both subordinates and superiors chasing down a rabbit hole of perfection. So this is in many ways a ‘lanes in the road’ issue. Senior management has chosen to be fascinated by unrealistic plans by your staff without working through you. That can be very frustrating at several levels.

Consider this a teaching moment and remember you will be here again (if the company does not tank over this). Let your staff know that you feel the team should speak with one voice. Let your bosses know they are headed off a cliff due in great part to skipping the decision chain. Have your best advice to leadership in hand and give it. If you cannot get them to listen then consider that is their prerogative not to change course as they are in fact your senior.

If this goes as you expect perhaps future decisions will be made in a more logical fashion. If not, the organization is doomed and you can do very little prevent further failure. Either way, the point is to assist where you can and understand the limits of your role and ability on issues that have been decided by your seniors in a manner with which you do not agree.

Answer 3

A business upside here is that if I am the security expert hired in, someone senior will have agreed my budget, and that already gives me some traction.

That aside, every security decision should really be based on a business risk decision and with the best will in the world IT should have little to do with that decision, aside from being able to detail the risks involved in various technical options and explain the implementation issues associated with decisions.

From that perspective I have always gone with an approach starting which goes from business strategy -> IT strategy -> Security strategy so where an organisation has a full risk register across all their assets (not just IT assets) the argument becomes:

• What is the qualified risk and impact of application X being exploited?
• What percentage of that figure do we want to budget for a solution?
• What solution is the best/most appropriate given that budget?

And the budget could be one-off costs, rolling resource costs etc - but either way it comes down to measuring the risk by the business and making the decision at business level.

---

In the real world, I have not had too many problems as the majority of companies do want to implement security cost effectively (or indeed, cheap) but in the odd organisation where IT were used to being very autonomous and powerful it has required some educating and a shift of culture.

In three instances I can think of, the security paranoiac did not adjust well and left rather than become more integrated with real world risk.

---

I think in the odd case where the board do believe the security paranoiac, the only real way round this would be to give examples of what other organisations their size and in the same industry are doing and help them compare figures.

Answer 4

How would you move things on?

Give him security work to do. Ask for a detailed whitepaper or trade study on platforms. Have him review CVEs for the type of application you are doing. Get him generating complexity metrics and running dynamic analysis tools. Make him happy by giving him the work he wants to do. Compartmentalize him with the work, and use the rest of the team to focus on your priorities. Make meetings he is invited to highly structured with an agenda, minutes, and limited open discussion. Do not exclude him or isolate him. He will notice that and may take antagonistic action, especially since he has management's ear. If you can't change his mind then dampen his effect.