In the previous article in this series, I wrote about the key pillars of an information security program and the types of controls that support them. In this article, I want to speak to the way that information security leadership thinks about those central supporting ideas, and what that means for decision-making. (We will explore the actual controls, their relationship to risk, and ways they can reduce that risk in another article).
In my day-to-day activities as an Information Security Officer, I am frequently called upon to assess the risks involved in projects and processes. Let’s define “risk”. I tend to defer to the NIST Computer Security Resource Center on such things. “Risk” is:
“A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.”
We have already defined risk as a function of probability and severity of impact in a previous article. However, risk can also be viewed in a more concrete way. If conditions do not expose a vulnerability to exploit, then it represents no actual risk. So we can also define risk as the combination of vulnerability and the ability of someone to exploit that vulnerability:
Risk = vulnerability x threat.
This is a traditional approach to assessing risk related to computer applications, but applies equally well across most risk considerations. The key point here is that to think like a CISO, you have to view everything from the perspective of perceived risk. Is the risk considerable or small? Is the risk likely to be realized? How bad would it be should this risk be realized? These considerations will allow you to accomplish three important CISO functions:
- Determine how much attention and effort this risk deserves
- Prioritize your efforts at addressing your list of risks
- Explain to senior management what the risk represents, why you do or do not feel it needs to be addressed, and at what cost (both for addressing and not addressing it)
Looking at these points, we can make another key observation about thinking like a CISO:
A CISO must think strategically. It’s helpful to have a tactical background and that may certainly inform your decisions, but the CISO has to keep the security strategy first and foremost in mind.
Thinking strategically allows the CISO to keep a clear view of the business' goals and keeps the security strategy aligned with the business strategy. When you speak to your CEO or COO regarding security priorities and needs, you will undoubtedly be asked how your plans will support or elevate the business overall. Your thinking should always include those considerations.
Another aspect that I personally feel is vital to being an effective CISO and thinking like one is to view security as a business enabler. The purpose of security is to protect the company, its data, and business processes from being exploited, and to prevent that data from falling into the wrong hands. However, it is critical to avoid the natural tendency to avoid all risks all of the time. It is often said that no computer is safe unless it’s removed from all networks. Of course, it loses a lot of its utility if there is no network connectivity. Email, for example, becomes considerably less effective on an isolated system. So we accept the risk of a potential break-in and mitigate that risk with regular software updates, malware protection, limited services running, and careful control of the use of privileged access.
The CISO needs to consider security with the mindset of “how can the risk be made acceptable and the company continues to run securely, but efficiently?” Sometimes, when asked to approve a security exception or some new process fraught with risk, “no” is the best answer, but the CISO must not start from no. I find it’s best to ask the question, “How can I make this happen for the team?” and then talk myself out of it should there just be too much risk.
Remember, there will always be guardrails within the security program that simply can’t be crossed. Things, like not running anti-malware protections on a user endpoint connected to the Internet, or running an operating system that does not get security updates regularly simply, won’t ever be acceptable within my security practice, but I still want to support the team’s efforts where and when I can. In fact, I want security to be completely effective, but as near invisible as I can make it in terms of the tools and processes supporting daily operations. I do want the team to be thinking about security and thinking like a CISO all the time, I just don’t want the machinations of the security program to be hurdles the team has to jump over all day long.
So to think like a CISO, you need to look at the task at hand and the processes and policies that guide the completion of the task. Consider how performing or completing this task will expose the company to any new risk, both in the performance of the task and the state of the business once it is completed. Does the performance of this work increase the attack surface available to the bad guys while we are doing it? Once the task is completed, will the work product add to our risk profile? If either of these questions receives a “yes,” then think about what the worst outcome might be and how likely that outcome is. Now you know the risk involved. Can we mitigate this risk somehow? Maybe network access controls can be increased, or the process could be performed with a less privileged user profile. If so, assess the costs (in dollars, time, process complication, and long-term support for process or product) and determine if risk warrants the costs. You have four ways to address it:
- Risk avoidance
- Risk mitigation
- Risk transfer
- Risk acceptance
Risk avoidance involves actively assessing the proposed activity to see if the source of risk can be removed. Perhaps there’s another way to achieve the end result that doesn’t involve this particular risk. Perhaps you can augment the proposed method to eliminate the activity that introduces the risk. Consider all the possibilities that might remove the risky aspects of the plan and act on them. Risk avoidance is not a passive process, as much as it might sound that way.
Mitigation involves looking for tools, processes, policies, or activities that can lessen the likelihood of the undesired outcome. This harkens back to controls that support the pillars of the security program. Can we augment them? Can we shore them up with additional policies, augmented processes, or tools that more directly address the risk we are facing? If so, is the cost in alignment with the actual risk? Remember, we can make that computer a lot safer by taking it off the network, but is it still an efficient and useful tool?
Risk transfer is the act of making someone else “responsible” for the undesired outcome related to the risk. Cyber insurance is the typical approach to this. If the damage from a ransomware attack is likely to be six million dollars, then get insurance against that and now the risk is transferred to the insurance company. There are other tools such as agreements related to indemnification or waivers of responsibility that can also transfer the risk out of the company’s purview.
The final option available is to just accept the risk. Perhaps it’s just extremely unlikely to occur or the advantages of the process or work product outweigh the possible bad consequences. It might be reasonable to simply say that the risk is acceptable and we’ll just defend against it as best as we can (recall the computer/network example above). There’s nothing wrong with that approach provided we have assessed the risk and associated costs, and made an informed decision.
Related to risk, there is one more aspect of thinking like a CISO that needs consideration. If we decide to choose risk mitigation or risk transfer, it is very important that we consider any residual risk that remains after we undertake those steps. It’s fairly rare to actually push the risk level to zero, so there’s likely some degree of risk to be considered. All we can do is decide whether or not it’s at an acceptable level.
We should note it (in fact we should track it) and understand there is still some chance of an undesirable result. For example, we may have purchased cyber insurance which protects us from the associated costs of a ransomware attack, but there could still be reputational damage to the firm. We should consider what actions we might need to undertake and what the associated costs might be and prepare the company to address them.
Finally, the CISO must always consider corporate culture when making decisions related to controlling risk. Many larger corporations have very stringent security controls and policies. Because their workforce is so large and ever-changing, some feel that the only way to keep employee risks at acceptable levels is to tightly control their mobile devices, carefully monitor traffic, and severely limit end-user privileges. There is nothing wrong with this approach. The firm may face devastating financial losses for even a single, simple mistake by an employee. Some firms, on the other hand, choose to depend on the savvy of their employees to eliminate mistakes and minimize risk. Through training and sound hiring practices, these firms prefer to avoid the potential “Big Brother” aspects of heavily controlled security practices and allow their workers more freedom to work efficiently with less monitoring and greater privileges. There’s nothing wrong with this approach either, provided you hire high-performers and keep them well trained and informed. Of course, there is middle ground between these two approaches and each firm will choose the mix of policies, processes, and controls that best meets its needs and those of the people it prefers to hire.
So, to think like a CISO, we need to consider the risks that confront the company’s information security. How might the data be compromised, (recall the CIA triad from the first article), and what would the costs be related to that compromise? Once a risk is identified, we choose one of our four ways of addressing risks to implement that decision. We should be regularly reassessing any remaining risk and tracking that, thinking about the consequences of our decisions and if we should revisit any of them. Risk management is a continuous process focused on minimizing, not necessarily eliminating, all risk. Consider how decisions around risk affect the company overall and whether the decisions being made align with the company’s business strategy and culture. Definitely look at the risk-related decisions and how they can actually help enable the business to deliver for its customers while still keeping their data safe.