A few months into one of my first IT jobs, I discovered a massive security vulnerability that could potentially allow an attacker to log into the network without having to provide any credentials. I tried explaining the situation to my boss, but she wasn’t having it.
At the time, I assumed that the reason why I had not been taken seriously was because I was a teenager and had very little IT experience. Later, however, I began to realize that, like any IT director, my boss was busy and I might not have done a very good job of explaining why she needed to prioritize this particular issue. After all, vulnerabilities are not all created equally. Some vulnerabilities are really obscure, and have almost no chance of ever being exploited. Other vulnerabilities, like the one that I had found, are so serious that they need to be addressed immediately.
As embarrassed as I am to admit this, the aforementioned security vulnerability remained in place for at least another year. I didn’t have the authority to fix it myself, and those who did have the authority had about a million other demands being made of their time. Eventually, I began to understand that the key to making things happen in the world of IT is to present the information in a way that makes the identified risk impossible to ignore. This is especially critical if you need funding.
Step 1: Prioritize the Risk
The key to getting the organization to address a security risk is to clearly demonstrate the risk’s seriousness as compared with competing priorities. One possible option is to list the top five or top 10 cyber security risks facing the organization, and then show where the newly identified risk ranks in comparison to the other risks. If you decide to use this approach, then you will need to be prepared to justify your assessment. One of the best ways of providing this justification is by coming up with a way of standardizing risks.
Here's an example:
Some of the non-IT work that I do requires me to periodically create risk assessment reports. In doing so, risks are evaluated based on the likelihood of an event occurring and on the consequences that could be expected if the event did occur. Figure 1 shows an excerpt from such a report.
Figure 1
This is an excerpt from a risk assessment report.
If you look at the chart above, you will see a gray number 1 in the green area of the chart. The number 1 indicates that this is the first risk to be presented. (The report that this was taken from identified a total of 11 risks.) The likelihood of an event happening as a result of that particular risk was only 1 on a scale of 1 to 5. The consequence of the event happening was given a rating of 2 out of 5. In other words, an event tied to this risk isn’t likely to happen, and, even if it did happen, the consequences wouldn’t be too bad. Because of the area of the chart in which the risk was plotted, this particular risk was deemed to be acceptable.
The important thing to understand about this chart is that it is designed to act as a way of standardizing risk assessments. Standardizing risks allows you to objectively identify which risks really need to be addressed. Of course, this means that the values used for the risk likelihood and consequences cannot be arbitrary. The reason why this particular risk received a consequence score of 2, for example, is that an event stemming from the risk is defined by OSHA as requiring first aid treatment.
Step 2: Have a Plan
It’s one thing to tell the powers that be that you have identified a significant security risk. It is quite another thing to have a plan for mitigating that risk. Even if you don’t yet have all of the answers, you must identify some next steps when presenting a security risk.
The nature of the risk mitigation plan will quite naturally vary depending on the vulnerability that has been identified. The plan might be something as simple as saying, “Since this vulnerability is so serious, I think we should apply the corresponding software patch more quickly than we normally would.” In other cases, the plan might be far more complex, and call for major architectural changes or large infrastructure purchases.
The key to successfully presenting a complex plan is to try to anticipate questions and objections, and to have an intelligent answer prepared ahead of time. If your solution involves purchasing a particular software product, for example, then be prepared to explain why that particular product is needed and why a less expensive, competing product would be inadequate.
Step 3: Show the Financial Impact
One way to really drive your point home is to identify the potential financial costs associated with delayed action. This might include anything from regulatory fines, to loss of customers, to costs related to data loss. Be sure to identify which systems could be compromised if the vulnerability were to be exploited, and what would be involved in returning to “business as usual” following such a breach.
Showing the financial impact of delayed action or inaction underscores the seriousness of the problem, and can also help to justify any costs involved in implementing your proposed solution. A detailed financial analysis also shows that you have done your homework, and it may give the powers that be a reason to take you seriously.
