Trapped in a frame: Why leaders should avoid security framework traps

To some, New York City is a giant safety hazard. The largest city in the United States is home to more than 2 million linear feet of “sheds,” the safety scaffolding installed on more than 9,000 buildings that is supposed to prevent aged masonry and other building detritus from breaking loose and slamming into the sidewalk. Many of these sheds stay up for more than a year, and some never come down. 

New Yorkers have accepted sheds as a permanent architectural feature of the city, much like the looming shadows of skyscrapers. Few people probably remember that sheds are a relatively new requirement for the city whose lifetime spans four centuries. Following the death of a young woman in Manhattan from plummeting, aged masonry, New York City passed a law in 1980 requiring that building owners have regular facade safety inspections and install sidewalk sheds if they fail inspection to protect pedestrians.  

Yet now the original objective of sheds to address construction risk has been lost, replaced by the rote application of sheds to every project. Have a new building project over street level, then place the order for scaffolding. Check the box. Be compliant. Add more linear feet, and whatever you do, don’t ask questions.

Frameworks, like New York City’s sheds, have become an endemic part of the security landscape. They seem to be everywhere, and many security professionals consider them more theatrical than practical these days — an unfortunate situation since, when used correctly, frameworks can provide value. 

The initial objectives of frameworks have often been forgotten, their purposes lost within the structures and processes. Much like a construction project, if you are securing a new business, you go set up your scaffolding framework and begin to check the security control boxes. You aim for compliance. You don’t ask questions.

Before #notallframeworks starts trending, the Google Cybersecurity Action Team (GCAT) believes that it is time for business leaders to step back and reconsider what we are trying to achieve with all these frameworks. The IT industry should be clear on why security frameworks exist and how to best use them in our risk-reduction journey.

Frameworks are tools, not the end goal. Just as scaffolding should serve a specific safety and construction purpose and then be removed, security frameworks should provide structural support to building a security program by referencing external consensus and forcing consideration of a broad scope of controls. Frameworks can help build and maintain a sound organizational security posture, and can create a common language that other organizations, including customers and regulators, can understand when wanting to learn more about your organization’s security posture.

The real win here is stopping the attacker, not matching controls in a framework. Frameworks should not be confused with security strategy or security outcomes, no more than a Beaux Arts tower should be confused with the scaffolding surrounding it. 

Consider the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF). When CSF 1.0 was published in 2014, it aimed to provide guidance to operators of critical infrastructure. To get from version 1.0 to 1.1, more than 200 written comments were collected, and more than 1,200 participants provided feedback. 

Much of the value of the NIST CSF was in the revision process, which drove conversations across industry and government on what we should be doing to help address cyber risk. This drafting exercise created a national security conversation that helped make security professionals think more deeply about which standards should be considered essential and universally required.

Today’s NIST CSF 1.1 can help promote further discussions of best practices and risk management. The NIST CSF can not provide a recipe to produce perfect security — or even guarantee adequate security. It can help inform our thinking, but it isn’t a substitute for vital security work. What the NIST CSF and other frameworks can do, and do very well, is enable us through their structures to achieve better security outcomes.

Blindly following a framework, endlessly searching for a better one, or even confusing a framework tool for its outcomes can distract from understanding and addressing the true risks your organization faces. Does New York need all 2 million feet of scaffolding? Setting up scaffolding in situations where it’s clearly not needed is a cost with no benefit, where the objective of safely working is lost to the rote assembly of another shed. 

To be clear, security frameworks can be very helpful when used correctly. They are good for: 

Helping to create and understand risk management objectives by driving conversation and consensus.

Reinforcing and supporting an organization’s enumerated security goals.

Helping leaders think through and communicate what they want their organization’s to avoid doing – what qualifies as unnecessary “shed building”. 

Support intra-organizational communication regarding actions taken, why they were taken, and to how best to marshal resources for appropriate controls.

We believe a better way to think about and use frameworks is to focus on their original intention: Solving big-picture problems. Security is fundamentally about risk assessment and appropriate risk management. To accomplish those tasks, leaders must understand what needs to be protected and the context in which that protective work will take place. 

A framework can help us “frame the work” – to help assess the risks and make better control decisions, and ultimately to reduce the residual risk we face. Find a good tool, and put it to work. Let’s not confuse the helpful scaffolding of frameworks with the underlying structure of security risk management.

You can read more about GCAT’s security framework recommendations here.