How to get sufficient funding for your security program (without having a major incident)

Published: 2013-08-14
Last Updated: 2013-08-15 01:37:16 UTC
by Johannes Ullrich (Version: 1)
6 comment(s)

This is a "guest diary" submitted by Russell Eubanks. We will gladly forward any responses or please use our comment/forum section to comment publically. Russell is currently enrolled in the SANS Masters Program.

The primary reason your security program is struggling is not your lack of funding. You must find a better excuse than not having the budget you are convinced you need in order for your security program to succeed. Do not blame poor security on poor funding. Blame bad security on the REAL reason you have bad security. I hope to encourage you to take a new look at what you are doing and determine if it is working. If not, I encourage you to make a change by using the tools and capabilities you currently have to help tell an accurate story of your security program - with much needed and overdue metrics.

Every person can improve their overall security posture by clearly articulating the current state of their security program. Think creatively and start somewhere. Do not just sit by and wish for a bucket of money to magically appear. It will not. What can you do today to make your world better without spending any money? With some thoughtful effort, you can begin to measure and monitor key metrics that will help articulate your story and highlight the needs that exist in your security program.

When you do start recording and distributing your metrics, make sure they are delivered on a consistent schedule. Consider tracking it yourself for several weeks to make sure trends can be identified before it is distributed to others. Consider what this metric will demonstrate not only now, but also three months from now. You do not want to be stuck with something that does not resonate with your audience or even worse, provides no value at all.

Do not hide behind the security details of your message. Ask yourself why would someone who is not the CISO care about what is being communicated? How would you expect them to use this information? Start planning now for your response ahead of being asked. Think about what you want the recipient to do with this information and be prepared with some scenarios of how you will respond they ask for your plan. Never brief an executive without a plan.

Develop and rehearse your message in advance. Look for opportunities to share your message with others during the course of your day. Every day. Practice delivering your "elevator pitch" to make sure you are comfortable with the delivery and timing of the content. Ask your non security friends if your message is clear and can be easily understood. Often those who are not as close to the message can provide much more objective feedback. Resist the urge to tell every single thing you know at your first meeting. Give enough compelling facts that the recipient wants to know more, in a manner in which they can understand (without having to be a security professional). 

I recognize this behavior every time I see it because I used to be guilty of the very same thing. I am certain that I was the worst offender. It takes no effort to sit by and complain. That only serves to make things worse. It takes commitment to conquer the problem. Unfortunately, only a few do that very well. Change your paradigm from why will no one listen to me to what is my plan to communicate the current situation in an effective manner. Have you found yourself guilty of admiring the problem? Do you stop working on problems when you realize that it is going to be simply too hard? Think beyond the current state and look to how things could be with focused effort. 

Do not ask for everything at once. Seek an initial investment in your security program and demonstrate with metrics the value of that investment. Show how you have been a good steward with the initial investment and can be trusted with incremental investments. Be open, honest and transparent about the use of the resources. Pay particular attention to schedule, scope and budget. The people you are asking for financial support sure will.

The primary reason your security program is failing is not your lack of funding. Start developing your plan today. Maybe the executives say that they think there must not be a problem, since they are not hearing from you. By using the data you already have, start to use it to tell your story about the current state of your security program. This information, properly communicated can become the catalyst for increased awareness and funding.

Here are a few ideas to get you started:

  • Monitor the percentage of systems sending their logs as compared to the total number of log sources in use
  • Monitor the percentage of blocked traffic on the firewall versus what that was permitted
  • Monitor the percentage of changes that occur outside the approved change control process
  • Monitor the percentage of findings on your risk register that have remain unchanged over the last quarter


What metrics have you found to be useful when communicating the needs and the effectiveness of your security program?

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords:
6 comment(s)

Comments

Agreed! Well, mostly. :-) I'm a big fan of performance monitoring for the same reason - it's often hard to explain to a non-technical person who controls the purse strings that you really do need to upgrade that server sometime soon without several months of performance stats turned into pretty graphs they can easily understand. The same holds true for security. One needs some way to quantify and demonstrate the risks of inaction to the people who have to pay for the solution. They're usually cost/benefit/risk sorta folks and your proposal needs to be cast in those sorts of terms if you want any chance of them understanding and approving it.

However, the problem isn't *only* about the getting the message across to management either. When management lets anyone who complains about the new policies skirt them because they're "inconvenient"... (shrug) There's not much one can do besides look for other solutions to propose and wait for the next big event to remind them without saying "I told ya so" which never goes over well. :-) In the end, it's often management's decision whether or not to approve a new security policy (or pay for whatever it requires) and back you up, or take the risk of not doing so. It's up to us to honestly inform them of the risks/rewards either way they go so they're making an informed decision.

What's frustrating is when the people charged with making those decisions ignore your advice (regardless of what stats you have to back it up) and figure they know better than you because they're "technical"... after all their VCRs don't flash 12:00 anymore and they setup their own WiFi at home so they must be "technical", right? (sigh)
Part of the problem is showing benefit each step of the way. Let me make an analogy with construction -- like building a storage building.

You first must purchase land to put it on. The need to store stuff indoors is not satisfied a bit by that step. Assuming you get approval to do it anyway, then next step is to grade the land and put in drainage, utilities, etc. You may claim that this increases the value of the investment, but by itself it also fails to provide any direct benefit. Again, assume you get approval anyway. The next step is to dig the foundation. Still no direct benefit for storing goods inside. Next is pour the foundation. Still no benefit. Then pour the slab. Still no benefit; you still cannot store a single thing indoors despite all the money you have spent. Your project is probably in jeopardy of being cancelled.

Next step is put up the walls. Well, now at least, you can claim that you have secured an area. Then we put on the roof. Wow! With the roof, you have protection from the rain. You probably should have put on the roof first, so you could show benefit the very first step. The the walls would add security, etc. You get the picture. Obviously (to management, who is *NOT* technical) you went about the whole thing backwards!

The problem with showing benefit each step is that you either have many more steps, increasing overall cost, or you never get done at all. You need to show the *WHOLE* plan, from start to finish, with schedule and budget, and show how you will track it (retain a certified project management consultant?) and get approval on the whole deal up front. That is the cheapest and fastest way to go, and if management doesn't understand that, then quit and go to work somewhere that they do.

Also, cut them some slack: they may choose to not implement your project for reasons that are never made clear to you. It might not be your fault. The may have another project that is outside of your discipline that is more important, and they do not have the budget for both. You may never know what that other project is, especially in a BIG company.
[quote=comment#27026]Also, cut them some slack: they may choose to not implement your project for reasons that are never made clear to you. It might not be your fault. The may have another project that is outside of your discipline that is more important, and they do not have the budget for both. You may never know what that other project is, especially in a BIG company.[/quote]

Absolutely. The bottom line is it's their decision to make (and they're wrestling with other problems totally unrelated to IT) and it's our (IT's) responsibility to help them make informed decisions - to let them know what risks and costs would be. I've usually been able to get security-related projects approved (though not always immediately - budget/time constraints 'n alla that - grin) but I've also worked in IT long enough that I've run across management that's convinced they know better than anyone in IT until events proved them wrong - oddly enough, this was usually at small companies, not big ones.

Anyway the point I was making was just that sometimes the best you can do is to inform Management, as best as you can, what the risk/rewards and costs/benefits of various choices are and not to take it personally if the answer to your proposal is "No" or "Not this quarter". :-)
I totally agree that my job is to make sure that management is aware of and understands the risk. A proposed solution is secondary. While it may be what I really want to accomplish, my job responsibility is primarily to make them aware.

Should management choose not to take my recommedations, I do my very best to not take that personally. (I will readily admit that sometimes I am more successful at this than others!) I try to focus on the fact that I have done my job to the best of my abilities and with the best interest of the company in mind. If I can say that I've done this, more often than not, that is enough for me.

I find it best to draw on management's experience to present the matter in a way that they can really understand. If management came up through physical security, I'll draw a parallel. If they came up through credit, I'll draw a parallel. Often I will step outside of their professional life and use daily life issues to do so.
"Do you leave your doors open or lock your house?"
"Even though you have an alarm, is it wise to leave the door unlocked?" etc.
Matt,

Great point about not making it personal. I have fallen into that trap before a few times.

Russell Eubanks
Great point - other projects can certainly get priority even when we have done everything "right".

Russell Eubanks

Diary Archives