Has the number of security issues you deal with on a routine basis ever made you feel a bit like Atlas carrying the world on your shoulders? I can’t tell you the number of conversations I’ve had with discontented security practitioners who lament to me the woes of trying to speak with management about the latest Heartbleed or Spectre/Meltdown vulnerabilities and ‘management just doesn’t understand’. Even worse, when management inevitably turns a blind eye to the issue, the security practitioner worries that they’ll be searching for a new job if the vulnerability is ever exploited. As the Information Security Program Owner at National Instruments for over eight years, I frequently find myself offering up the following bit of advice to my compatriots who are struggling with what to do in this situation.
When I first started the security program at National Instruments, I had these same feelings of anxiety. The tools that I was using to scan our networks, systems, and applications were coming up with vulnerabilities left and right, but there were few things that I had the ability to fix. I had to go to another team, explain what had been found, and then I had to somehow try and convince them that they needed to fix it. In some cases they humored me, but in many cases the result was that my vulnerabilities were just another bug that they’d get to when they had time. The weight of all of these unmitigated issues was crushing me. I knew that if I didn’t find a better way to do things, then I wouldn’t last long in that role.
I quickly came to realize that my role as a security practitioner never was to fix the vulnerabilities that I found. That was the function of the application administrators. Nor could I control the resources and roadmaps which determine the prioritizations of the various mitigations. That role belongs to members of the business. My primary function as a security practitioner was to assist in identifying the issues, advise on how to mitigate them, and ensure that the right stakeholders are aware and educated so that they could make the most informed decision possible for the business. In short, my role was that of a risk manager and my job was to drive visibility and accountability of the risks the organization is accepting to the stakeholders who are accepting them.
To formalize the processes around my newly found risk management role, I did quite a bit of research around what others were doing. Eventually, I stumbled across the NIST SP 800-30, a Risk Management Guide for Information Technology Systems. I’ll admit that it wasn’t the most titillating document I’ve ever read, but the content really helped to solidify what our risk management process needed to look like.
To start with, I needed a way to track all of the risks that we were collecting through various assessment processes in our environment. This system, typically referred to as a risk registry, would become the aggregation of risks found in our organization through vulnerability assessment, auditing, interviews, vendor notifications and many other sources. In order to be successful, I needed a system that everyone could access quickly and come across a risk in their environment and a system that allowed them to enter a minimal amount of data about the risk so that they could get right back into what they were doing when they identified the risk. I would then use that information to later populate the details myself or to schedule time on their calendar to fill me in. My system also needed a way for me to understand the prioritization, or risk level, of the risks I was capturing.
Once the risk had been recorded, I needed a way to track how we were going to handle the risk. Possible options ranged from accepting the risk because the likelihood and impact were within what we considered to be a tolerable range to planning some sort of mitigation for the risk. I needed a way to understand the level of effort involved so we could balance those costs against the risk level.
If my ultimate goal was to drive visibility and accountability up the chain of management, my last step was to have a process for who would perform a review of the risks. I decided to use a combination of the team a risk is assigned to and the risk score. Since risk management is designed to be a cyclical process with risks re-evaluated on a routine basis, I also used the score to determine how often the risk would be reviewed.
Most of the organizations I speak with these days about risk management start out using complicated formulas on excel spreadsheets, but there are tools called ‘Governance Risk and Compliance’ (GRC) that can help you with this endeavor. There range options from open source tools like ‘SimpleRisk’ to more expensive options like ‘Archer’. It depends on how complicated you need your workflows to be and how many resources you can afford to spend to run the program.
I started this discussion with the person telling me that ‘management just doesn’t understand’. The fact of the matter is that management doesn’t understand because they weren’t speaking the same language. Your business understands risk because they use it every day to make calculated decisions about the investments it is making. Risk is the language of business and shifting the focus of your conversations to risk will ensure that everyone is on the same page and that you are not only viewed by management as an excellent communicator, but also a stellar security professional helping to guide the organization in proper risk management. Not only that, but you will sleep better at night after shedding that weight off your shoulders and placing it back on the solid risk management foundation on which it belongs.
