Continuing on the list of seven, next up is risk and investment prioritization. Apologies in advance, this post is a bit lengthy.
The majority of my IT career centers around risk prioritization and I was lucky enough to lead and create this service in two great enterprises, consult with many more.
Let's start with the position statement: IT security risk and investment prioritization is a two part process to 1. prioritize IT security risks to improve treatment decisions and 2. determine the optimal investments to manage risk to an acceptable level. It's better than nothing to minimize reacting to the latest news article or trend. It's also better to be wrong and have a feedback loop to improve over time.
Couple points before I get into the process. Below I'll use our Risk Communicator application to demonstrate. By all means you don't have to use our application. I did this for years with spreadsheets and presentations. It just takes more time to get your team and stakeholders to buy into the process and a longer time to produce visually compelling outputs to support your story.
Keys to Success
Recall our goal is to prioritize risks to identify and justify where we need to invest to manage risk. This post doesn't focus on the tactical exercise of conducting risk assessments across your business e.g. inventory assets, conduct threat models, surveys, pen test, etc. This process uses your evidence as inputs to communicate your estimates. Don't start it without facts and expert optinion to back up your position, for example:
Evidence from your pen testing, monitoring, response, and GRC processes (surveys, policy exceptions, posture reports, audits, etc.)
Evidence from peers and relevant verticals. See if you can leverage the reports from Trustwave or Verizon. Verizon's Alex Hutton has a great presentation on their work here.
News reports of real evidence. Finding facts is tricky but take advantage of all real data, ref my hot iron post.
Find your Zoom
The next key is to think backward from your final deliverable. What level of detail will the CxO or equivalent decision maker want to see? Each investment you propose should have drivers defined at the level for non-IT folks to understand the outcome of the investment. Each risk must be backed with facts or estimates based on expert opinion. If you don't have sufficient evidence, do a pen test, audit, investigate, whatever is needed to improve the decision.
I mean, "collaborate" with your IT peers. Odds are you'll be making control judgments on a service someone else owns. You may be recommending projects someone else will manage or be affected by e.g. what do mean no personal WAPs on the network! It can generate stress so build the relationships, buy beverages to facilitate agreements before the prioritization process ends. If you don't agree with the accountable owners, the below process will help remove some emotion from the debate and help get to the right business decision.
Taking time to plan is difficult during busy times. However a little planning definitely helps the budgeting process, especially when you need time to find or organize your business case.
Now that you have everything scheduled and your management's support, who does what?
This is an iterative process of really fun debate among SMEs. I miss these debates and almost want to be back in a corp group right now. The key is to understand roles. Fevered debate needs to happen. Voices must be heard, evidence needs to be organized. However when the time comes to make a decision, the lead should step up and make the call. Pick your model to facilitate
I won't go into our risk model in the post. It's important to standardize on a model to improve consistency across assessors and communicators.
Once risks are prioritized, it's time to propose mitigation options. Here's a great new school post to guide your thinking. In addition to scope and cost information, I sometimes prepared a visual to show what happens if you don't get the requested resources. Have you ever heard, "what if we only spend half that?" Perfectly fine result, as long as the stakeholders understand the effect of their decision.
After you scope, cost, and estimate the pace of risk reduction, it's time to socialize, I mean collaborate. An investment recommendation with only the Security team's input is probably in trouble. Please reach out to stakeholders and represent their voice in your recommendation. At a minimum you should ask questions around IT's capability to manage, project execution risk, feelings, and any business unit support (or opposition). In my experience almost all of Security's recommendations were influenced by outside stakeholders. Embrace this fact, ask the questions, and represent their voice. This is part of the "what's acceptable risk to the business" process. Note that Risk Communicator enables you to change the overall Business Value of the investment based on these external inputs. Your risk statement doesn't change, but the importance to the business may.
Note Risk Communicator also overlays some decision outcomes to foreshadow your recommendation.
Rubber, Meet Road
Now you're all set. You've prioritized and justified your investments. The goal of the budgeting process is to invest the right amount for the business at the right time. Thus, security projects may be cut. If you're prepared, you're ready to take the emotion out of the decision process. No FUD is required because you have the data to communicate the outcomes. If the decision makers don't want to fund something, no problem. Here's the risk they're accepting. You'll continue to track it and escalate if something changes. After all, you have three choices:
Invest the requested amount, which may mean you need more resources.
Reduce scope and cost of budgeted projects.
Shuffle or cut projects to fit your budget.
This can also be an iterative process. Be prepared to re-zoom, re-scope, and re-prioritize your story. This can be a time sink but it's an important part of the job. Sometimes politics override technical reality. No worries for the relevant CISO who embraces the business discussion.
This is simply a tool to help the business understand the risks they're accepting vs. mitigating. Good stuff.
I recognize and welcome the fact there's many ways to skin this cat. The important part is the process of IT Security being relevant to the business, in context of the business. Before I end, a few more words about accountability. I just noticed the screen shot above shows all the risks nicely going down to acceptable levels. Apologies but this rarely happens. When you re-start this process, you don't start all father Christmas. You need to show your progress and come clean how accurate your predictions were. This is much easier to do with a data driven tool like the above but it's possible in a spreadsheet. In a future post I'll show you how Risk Communicator enables you to trend your actual and expected risk reduction. It's simply a plot showing progress over time. However it's a powerful tool to measure and hold yourself accountable. It's even better to communicate your accuracy to maintain credibility. The networking team has their availability stats over time. You should communicate your enterprise risk posture and reduction over time as well. Note we'll cover metrics related to the above when we get to scorecards.