Am I Doing Threat and Vulnerability Management Right?

Cybersecurity, as a practice within organizations, has existed for decades. Larger (or government) organizations have had dedicated cybersecurity functions in place since at least the ‘90s. By the early 2000s, organizations were appointing CISOs, and by the end of that decade over 85% of large organizations had a CISO, and by 2017, over 85% of ALL organizations have appointed a CISO.

The average tenure of a CISO is between 24 and 48 months, so they say and they say.

Given the short tenure despite the 30-year history of the practice, it follows that the majority of CISOs are working with a number of security investments, priorities, and existing programs that have been established long before their arrival.

In my personal experience, I was involved with two large organizations that had elements of this – the State of Colorado, and the Department of Energy.

At the DoE, I was fortunate enough to join the program as it was being built. There was a charter that outlined what we were doing, and a plan that said where we were going. It was a reasonably well-put together program, but it didn’t really drill down to the “why” we were doing what we were doing. Some years into my time there, we hired a third party to perform a business impact assessment to help us validate our disaster recovery planning and overall IT strategy. The results that came back stunned us at first, but ultimately made complete sense. The study found that our occupational safety training system – not our communications system, not our radiometric assay and telemetry systems – was the single most important system on the plant site. Our security program barely acknowledged the existence of it, and here it was, smack-dab in the executive summary of this (quite expensive and very thorough) study. Who’da thunk?

Similarly, at the State of Colorado, I helped build a program that would establish a cybersecurity governance framework across all state agencies. While that sounds great on the surface, it ultimately required agencies to implement certain minimum sets of security controls within their environment but without really understanding the unique mission each agency played, and the importance of each.

In both organizations, the security program was built on “best practices.” The programs were based on frameworks of controls that “the industry” had generally accepted. They weren’t ineffective, but there wasn’t a lot of prioritization given to the efforts. We were doing stuff – and in fact, good stuff – in support of the organization. Yet, I’d lie awake in bed at night, wondering, “Am I doing it right?”

Sometimes my mind travels back to those halcyon “days of my youth” and I daydream. Imagining if I could go back and do it all over again, what would I do? (Cue the slow zoom, unfocused camera, and pan up to the skies…)

I’d start with identifying what was important to the organization. And by this, I don’t mean systems, applications, or other technological constructs. I’d start by aligning with the business priorities, and identifying the mission and the characteristics of how that mission was accomplished. What were the near- and long-term objectives of the business, and what obstacles and threats stood in the way of achieving them?

From there, I’d examine how IT operated in support of the business priorities. How did technology support the mission, and what were the plans to adapt to the objectives? What key systems, applications and operating environments were critical to achieving those objectives?

Then I’d examine the proverbial Threat Landscape. Given the characterization of the business – what industry, what niche was it filling, and what was their true value proposition – what type of threat actors would target this company? What were the most common tactics and attack vectors used by these threats? What specific threats has this company experienced, historically?

Once I had identified the most likely threats that could compromise technology resources and impede the business’ ability to achieve its objectives, then what? I’d work out how well we could defend against these kinds of attacks. I’d overlay the investment centers with the security program, to find what threats appeared to be mitigated and which did not, based on the controls implemented. The outcome of that would be a representation of where I had invested in protecting the business, and where I had not. And surely there will be many shades of gray in the midst of that.

That final product? If you think it sounds a lot like a risk assessment, you’d be pretty close. That’s an organizational threat model. It’s focused on tech yet aligns with the business. The focus of this organizational threat model, however, is about demonstrating the threat capabilities of both our anticipated attackers and our defenders. It can be used to test our strengths and evaluate our weaknesses. Perhaps we’re not as strong as we think – and maybe our weaknesses are immaterial, as they can’t practically be exploited. Leverage this to prioritize the development of a threat and vulnerability management program around the results of the evaluation, and Bob’s your uncle.

… And here’s the shameless plug. Our recently announced Threat Modeling and Attack Simulation service is exactly this. By establishing an operational threat model on which we base our evaluation and testing, we can help your organization align your security program with business priorities, and then assess how well you’re prepared to defend against the threats to those critical functions.