This post was originally published on Forbes
Many modern enterprises no longer operate in a highly centralized manner. Traditionally, cybersecurity in enterprise environments consisted of defining trust boundaries, placing controls over these boundaries, setting standards and policies for the safe and secure handling of data, enforcing said policies and scrutinizing any code/applications that were developed for flaws that may be exploited by adversaries — inside or out.
But now, as part of a decentralized model, optimizing for performance and independence, the kind of control and scrutiny that security organizations once had in the past is becoming irrelevant. This leaves the separate business operations within an enterprise free to choose their own implementation (and sometimes prioritization) of how they run their security.
If the CSO/CISO role was challenging before, now it is even more complex. We need to hold a delicate balance between enforcing some elements and providing guidance or general directions for most others.
As the parent company of multiple independently operated businesses, our approach at Cimpress is to emphasize a shared-security-responsibility model, where each business unit is not only responsible for choosing and operating its technical stack but also its security and risk management. As such, our security organization has two main tasks: providing clear and transparent metrics for security maturity and providing a means for measuring (really, this means quantifying) risk in a way that supports decision making around changing controls. We have chosen to utilize two well-known frameworks to achieve this.
For security maturity metrics, we chose NIST-CSF: the NIST Cybersecurity Framework. This framework provides a consistent and clear indication of security maturity across over 100 categories and subcategories of an organization’s defense capabilities. There are many approaches to using this framework, ranging from self-attested surveys to fully automated and continuously updating platforms. The technique is less of an issue than the ability to create a clear reflection of each business’ maturity levels and, of course, set a minimal or sought-after maturity level (again, this doesn’t have to exist across all the subcategories). This baselining allows businesses to better align themselves with existing policies (which are translated to the minimal required maturity levels) and map out their tactical security gaps.
For our risk measurements, we picked FAIR: Factor Analysis of Information Risk. FAIR is being used at the enterprise risk management (ERM) level and is combined with the rest of the ERM functions to assure relevancy and context for our business leaders. We do not deploy FAIR analysis across a broad range of scenarios; rather, we focus on the top three to five that each business identifies as the most relevant ones for themselves.
The goal of using the framework this way is to get immediate buy-in from business leaders while providing them with means of making informed decisions about their risks. After identifying the scenarios, we perform a FAIR-based analysis of the risk and come up with the results of the expected loss. Behind the scenes, we map the relevant controls to the already-identified security maturity measure.
Beyond providing a more realistic reflection of risk (while shying away from high/medium, red/green, etc. qualitative measures), we also create an immediate feedback loop. At this point, we’ve turned security and risk management into a business problem that’s more “easily†solved through financial measurements of recommended changes and their impact to previously expected losses.
If you are asking yourself, “Great, but where do I get started with this?” I would suggest to first define how a shared security responsibility model would look like in your organization. Where do you draw the line between the core responsibilities of the security organization, and where do you expect other parts of the business to own their share of security?
Once that’s defined, utilizing the different frameworks to facilitate this becomes more natural. We’ve used the NIST-CSF to provide metrics for everyone to gauge their maturity level and, based on the shared responsibility model, understand what areas need to improve. I’d suggest tailoring the use of the framework to your needs. In our specific implementation, we simplified the framework in terms of the number of maturity levels and provided focus on several specific subcategories that we defined as “basic security hygiene.”
Lastly, in order to prioritize these tasks of closing maturity level gaps, choose a risk model that works for you. In our case, it was FAIR, and even then we allowed ourselves to use it in a way that works for us rather than cover all our use cases and scenarios. This allowed us to stay more agile and have an easier adoption period where our businesses were getting used to the methodology and the framework.
At the end of the day, it’s about what works for your organization rather than about sticking to the letter of how a specific framework is structured. And of course, always make sure to build closed-loop feedback cycles in order to facilitate continuous improvement for how your security program works.
Leave a Reply