Supporting the Decision Process
Jack Freund inspired this post with his “Executives are Not Stupid” post. I have climbed out of that geek-trap of thinking that decision makers were idiots. I’ve learned that, to Jack’s point, they generally are not idiots and to the contrary are usually more skilled and successful at decision making than the average person. But the science of making decisions is not restricted to a solo effort. I want to break down the decision process and point out where different roles may fit in. If someone in a technical role feels that decisions are poor, they should be aware of where they fit into the decision process and what influence they had (or didn’t have) on the decision. Once they realize that there is a process, however informal, they may begin to influence change by establishing themselves into the appropriate step, or even challenging decision makers on their process and helping them improve. Whether we know it or not, the goal of both business leaders and security wonks is to make good decisions.
Step 1: Establish a Frame
The first step is a critical step and often skipped over because people aren’t even aware that every decision has a frame. This initial step is to identify and communicate the context of the decision among those involved. Are we talking about DLP because data is leaking like a sieve? Is there a regulatory concern? Or is DLP “necessary” to give someone the illusion of progress? All those warrant DLP, but depending on the context we may have three completely different decisions.
Here’s an example, I recently was brought into a project to encrypt data in a database (which had me questioning the frame right away). I derailed the project completely by asking what problem they were trying to solve. Turns out the project to encrypt the data was initiated because the data was not encrypted now (seriously). The initial frame made the mistake of assuming encrypted data was a binary option, encrypted or not. By going back to establishing the context, we were able to better define the goal of the project and evaluate many other options that were not limited to encryption. The initial frame limited our options in our decision, and from a technical role I was able to influence the decision process by modifying the frame.
Step 2: Gather Data and Options
This is squarely were risk analysis lies. By discovering probabilities of events and related losses we can drive out a few options with associated costs and benefits. Other aspects of security programs have input in this step such as metrics, breach reports, vulnerability scans, audit findings, asset valuations and even expert opinion and intuition. It is the job of security professionals, to provide the options they see and data points that support those options. Not doing so can starve the decision maker of relevant information and cause decisions with even more uncertainty than they already have. It is the job of the decision maker to seek out expertise and to ask for data points thought to be relevant to be sure they have all options on the table. One interesting thing decision makers can do is starting asking for levels of confidence in data points, having that little extra question in there provides some really interesting context for the data being gathered. (forethought here as well: attempt to prepare for step 4 as options are discussed)
Step 3: Decide
I know this should be obvious, but the decision must be made. One thing I haven’t called out yet is all the biases and fallacies we as people are susceptible to. The best way to combat those are to become intimately familiar with them. Understand the difference between an availability bias and confirmation bias. Understand what the sunk-cost fallacy is. Being aware of those so that they may be identified in daily activities (and they come up daily). Because once you can identify them in reality you may be able to account for them in your decision process.
Step 4: Feedback
Just because the decision was made doesn’t mean the decision process is over. This fourth step is probably one of the most elusive steps and I struggle to find it in security. Once a decision is made, it is extremely beneficial to find out if it was a good decision, or if the decision had undesirable outcomes. We may go back and re-evaluate previous systems but rarely is that performed with previous decisions in mind, let alone with feedback to the decision makers. How can we know our DLP installation is meeting our goals? Was it the right decision to go with vendor A over B? Take a moment and think of feedback in recent decisions. Get much? If feedback was received it was probably all negative, but be sure to take it – not all failures were due to bad luck, sometimes we stink and owning that makes for better decisions in the future.
My point here is that decisions are complex, yet it is a skill that can be learned and improved on over time. There are many moving parts and each component in the decision process can cause unique problems if glossed over or skipped altogether. Keep in mind that these steps are scalable too. I’ve found myself standing downtown running through these steps in my head to decide on where to grab lunch. I’ve also thought through these steps to forecast and plan huge projects. The amount of time and effort in each step should be proportional to the girth of the decision.
Back to Jack’s point, if you are a technical person who thinks that some executive decision qualifies them as an card-carrying member of idiots-R-us. Take some time and think through what you know of their decision process. Were you able to provide quality data to them? What other data points did they consider? Do you have opportunity to gather and provide feedback on that decision down the road? Because like it or not, security decision making is a team effort and executives making routinely poor technical decisions may just need more active involvement and input from the technical staff.