The Frustration with Frameworks

Over the past decade, cybersecurity standards and regulation have ramped up significantly. Due to technology innovation and accessibility, the cyber attack surface has expanded, and alongside it, plentiful examples of real-world attacks — and repercussions. 

When looking at all the laws and guidance  — both passed and proposed — it’s easy to see how convoluted security management is and how much ground there is to cover. But just looking at the requirements with which security teams have to comply can be dizzying. How realistic is it to expect that organizations can achieve full compliance … with every relevant regulation and every leading practice?

The last decade has given us some whopper breaches: Yahoo!, Facebook, LinkedIn, Marriott, Colonial Pipeline, Equifax, several notable government agencies … and these are only examples of “mega” breaches. There are plenty more attacks to reference, if you’re so inclined. Given all the parameters and potential for harm, security teams worldwide struggle to protect and defend their IT estates. Digital transformation and ever-changing workplace configurations require constant architectural revisions, thereby increasing the likelihood that something will get missed. Some vulnerability(ies) will be created or exposed, putting the organization at risk.

This is where and why industry organizations and regulators have stepped in. We've all watched breaches play out in the media (and among the “armchair quarterbacks") and thought, “What does my own organization need to do so we’re not the next attack victim?” 

If you’re lucky enough to work in a well-oiled security organization, you may have documented and practiced processes, an adequate number of staff members, and even reliable tooling to help in these efforts. However, even the biggest and best-funded organizations can struggle with today’s threat landscape. Not because they don’t know what they’re doing, but because there’s so much to do. All the time. 

The reality of regulation

Regulations are written and passed to provide minimum viable security standards deemed acceptable for entities operating in today’s digital and highly-interconnected society. While cybersecurity professionals often refer to regulation and compliance as “the lowest bar” for security or a “checkbox” activity, they provide a baseline upon which companies are free to build. No one has ever said, “Stop here,” in reference to a security program built based on regulatory guidance. Just because you have to build a foundation first, there’s no reason you can’t also build a first, second, or even third floor.

The reality is, though, that many companies are only able to build their security programs to the minimum level due to numerous constraints: limited staff, budget, support, and time; skills gaps; network complexity; organizational in-fighting; inadequate tooling; and so much more. As a result, the security incidents keep on coming. For many security pros, it feels like no matter what they do, they’re being reactive.

Regulators want to change that — and hold businesses and government agencies to higher standards in an effort to protect consumers, stakeholders, and investors. Thus, over the years, as the cyber attack surface has continued to grow, and as attackers have become stronger and more savvy, an increase in regulations have been passed, and organizations have had to grapple with more and more requirements. 

Industry influencers 

As for guidance published by industry standards organizations, the aim is to go above and beyond regulation — to provide an as-thorough-as-possible list of controls and to-dos that companies can follow, theoretically covering all the obvious bases of a potential attack path. In some ways, these frameworks act as a blueprint for a security program to follow: Here are the most likely ways attackers can exploit your environment. Here are the controls you can affect to reduce the probability of exploit. This is what you need to watch out for first, second, third.

Seems easy enough. In theory. 

In their initial versions, popular frameworks including the NIST Cybersecurity Framework (NIST CSF), CIS Controls, or Cyber Essentials were comparatively simplistic. Over time, though, they have evolved into massive lists of rules and recommendations, accompanied (sometimes) by how organizations could get to the right level of security for that particular control (which may vary depending on the level to which your particular organization would like to architect security. For example, whether you are aiming for a low, medium, or high standard).

To give you some perspective on the progression of guidance and regulation, the NIST CSF V.1.0, published in 2014, included under 100 categories across the five functions (identify, protect, detect, respond, recover). Framework V1.1, published in 2018, expanded and grew into 22 categories across the five core functions, with 98 subcategories (security controls). 

Today, NIST is undertaking its journey toward 2.0. In the meantime, however, the organization has published additional types of cybersecurity frameworks and guidance, NIST Special Publication 800-53 chief among them. It is widely considered one of the most comprehensive and relevant frameworks for today’s operational environment. Rev.5, published last year, includes 20 control families and 1,050+ controls. Yup, more than 1,050 controls if your organization wants to be at the highest level of security protection recommended by the National Institute of Standards and Technology.

A cybersecurity headache

I don’t just know this from reading their website, although that would have been much more pleasant. Instead, this Reformed Analyst undertook a two month long project to map not only the Axonius core product for cybersecurity asset management to NIST 800-53 “high impact” baseline, but also to compare it to a Canadian framework, the “IT and security risk management” approach, ITSG-33. 

Listing and mapping each control was painstaking. And I wasn’t even really doing anything. I wasn’t positively impacting security whatsoever. I was simply putting together a list of what someone else might do. If I were a practitioner sitting in a SOC or a NOC, I would have to implement and/or tune controls, if my organization decided they want to follow this standard.

And what about those pesky regulations? Many of the new and proposed laws are based on industry guidance. Instead of reinventing the wheel, regulators rely on the best-available guidance, working with experts at standards organizations, to create laws that have some chance of being executable and maintainable. 

What does it all mean?

If you thought you were going to come here today to receive some sort of guidance in navigating the regulatory or framework landscape, I am sorry. This isn’t one of those posts. Usually my newsletter articles strive to impart some semblance of wisdom from my many years in security, working with some of the best practitioners and pundits in the field. Today, though, you’re getting pure empathy. 

As mentioned at the beginning of this rant — there is so much ground to cover in security that it is impossible to cover it all. I could be the eternal pessimist here (we all know plenty of those) and say that cybersecurity is a losing battle.

Or we could look at it this way: The cyber attack surface is huge. We can’t protect all of it to a level of 100%. We can, however, take a risk-based approach and accept that, with operations, there is risk. The question is: what’s your acceptable level of risk, and what can you do to incrementally decrease that risk over time? What are the tools you can use? Which controls can you tune? How can you improve upon your processes and policies, day after day, year after year? What training can you supply to your staff to ensure they have the most knowledge that helps them handle today’s threat landscape? What obstacles can you move out of their way so they can do their jobs better?

It’s this high level of thinking — maybe, strategy? — that you can take because we have such thorough frameworks on which to depend for guidance. There isn’t a lot left out of NIST SP 800-53 (again, trust me…1,500 rows multiplied by 6 columns…), and it was created with the industry’s feedback (i.e., real practitioners, not proselytizing rule-makers).

Will it be painful to implement NIST SP 800-53, or another similar framework, and comply with regulations that seem so checkbox-y? Yes, especially if you’re starting from scratch. But you don’t really have to start from scratch because the guidance is good. Even the regulation is starting to look more sensible. So while you might be frustrated with every piece of guidance you’re told to follow, be glad (like I was when I was finished) that it exists and that it can provide you with reliable and time-tested steps that will make your job (and life) easier along the path to attack surface reduction.