As consultants, we tread a razor-thin line between emotion and logic. On one side, we have to deal with our client’s understandable human responses to a variety of complex issues. On the other, we have to deal with the hard realities of limited resources, limited time, and ever-expanding scope requirements. Although this balancing act defines a large amount of our work, it becomes particularly apparent in security consulting. One of my first jobs forced me to confront this issue head on.

Scope creep
Early in my career, I took a job as a part-time UNIX administrator at a local school. Three months into the job, my boss asked me to make a presentation at a parent guidance board meeting. The parents wanted to know what technology security procedures we were taking to protect their children’s education. I slapped some slides together and called it a presentation.

At the meeting, I talked about the joys of e-mail, how we blocked specific gopher sites, and file storage. I outlined the simple security hierarchy used for file system access. After fifteen minutes of technical jargon, the parent’s eyes glazed over. Half-an-hour after that one mother raised her hand. She asked that bombshell of a question: “Is it true you can get pornography on the Internet?”

That launched the meeting into a host of questions that reappear every time someone brings up information security. Would the school (company, nonprofit, etc.) be liable for use? Could someone hack in? What if unauthorized users gained access to a system on the network? Should we physically or logically separate the two? Could we control the e-mail users sent? How long should we archive it? Should we check though archives for illegitimate activity? How could we protect the users’ privacy?

Panic started to set in. They sensed the complex dangers they faced, yet could not come to grips with them. By the end of the meeting, they tasked me to create a very complex security system. A month later, I locked the system down so hard that no one could use it without passing through three layers of security.

Assessing danger: threat vs. risk
Much later, I realized that this experience represented my first professional exposure to a conflict and understood how it shaped my career. At the time, I worried about the technical and procedural aspects of resolving the “security need.” Later, I explored the ramifications of a proper security procedure. Eventually, I saw the basic conflict at the heart of the issue: the determination of risk rather than threat.

We feel threatened. Threat appears as we move though our lives. We pick up these feelings from news, from thinking about problems that might arise, and even from talking to other people. As human beings, we use whatever means is at our disposal to deal with threats.

We also assess risk. In order to do so, we must first define the threats that loom around us. We then come to grips with their probability and potential impact. Based on this assessment, we then formulate strategies (procedural or technical) to deal with them.

Risks have two basic values: probability and potential impact. These values combine to create the risk’s severity, the reasoned measure of how much danger a risk presents. Probability measures the likelihood of the risk’s occurrence throughout the life of the project. I personally use a percentage chance; other consultants I know prefer to measure probability in terms of likelihood-per-given-day (i.e., strict probability based on a logarithmic scale). Potential impact measures the damage a risk inflicts should it occur. As with priority, we generally concern ourselves with actual dollar impacts rather than secondary effects.

Calculating risk
In order to calculate risk severity, first clearly define the risk. For instance, assign both the probability and the potential impact a number between 1 and 5. Then, multiply the two together to create a severity rating. High severity risks need immediate attention.

Clearly defining the risk can be trickier than it sounds. Many times, we start risk assessments facing vague, half-formed threats. In order to get to the heart of the issue, we must carefully examine the reality behind the threat using questions and reflective listening. Only after we establish exactly what event the client fears can we start to assign values.

Once we move on to assigning values, I find the following scale helpful in infrastructure security engagements. Other scales are more useful for other kinds of work (i.e., quality assurance or software development):

  • Probability: Rated 1 to 5. This measures the likelihood that a particular risk will actually occur (thereby becoming an actionable event). Assign 1 point for every increment of 20 percent chance of occurrence. So, risk with a 60 percent chance of occurrence has a value of 3. Use your best professional judgment to determine probability. Experience and in depth research need to guide your decisions, not knee-jerk reactions to the feeling of threat.
  • Potential Impact: Rated 1 to 5. Events that result in negligible impact (i.e., loss of a redundant system that holds historical data) receive a 1. Events creating modest but significant impact rate 2 to 3. Events that could have a massive impact on the business (i.e., loss of a day’s revenue or exposure to substantial litigation) rate 4. Events that completely shut the business down (i.e., loss of outstanding order data) rate 5.

For example, a defined risk with a probability of 1 (>20 percent chance of occurrence) and a potential impact of 5 (business-stopping impact) receives a risk severity of 5. The crippling nature of the potential impact means that we need to analyze this further; but, the likelihood of it occurring indicates that we have some breathing room to deal with higher severity issues.

It does not matter what scales you use or whether you add or multiply the results. The importance of the technique lies in consistently analyzing the threats around us. So long as you use the same method within a particular engagement, you achieve a positive result.

Dealing with both sides of the equation
In the above example, I suggested that we should “deal” with a low severity risk. Why? I just spent an entire article arguing that we must use severity to respond to risks. Although absolutely true in a logical sense, as consultants, we do not only deal with logic. We also deal with the emotions associated with our work. Often, clients feel threatened by the high potential impact risks, even if we objectively know that they are more likely to suffer higher probability, less disastrous events. For example, I have one client who obsesses about external intrusions. He spends hundreds of thousands of dollars on security audits and software. Meanwhile, his internal order processing system goes down at least once a week, costing his company thousands of dollars every hour. The threat of a high impact event keeps his mind off of the risks he runs every day.

As consultants, we need to work with our clients to address that feeling of threat. We can help them though it, partially by putting effort into addressing the fear and partially by helping them understand the difference between threat and risk. Once we move into risk-based analysis, many clients find that their fears slowly recede.