Cyber Security Frameworks Demystified Part 15 - NIST SP 800-37

In this episode, we debate about the NIST SP 800-37, exploring how its Risk Management Framework helps organisations integrate security and privacy into every stage of a system’s lifecycle and whether its structured, risk-based approach is the most effective way to manage modern cyber threats in an increasingly complex digital environment. 

Duration: 0:22:24

Visit https://www.wecyberyou.com for more cyber security education, resources and awareness content like this. 

Thank you for listening. 
WeCyberYou! Team

Transcript

SPEAKER_00 0:00

Welcome to the debate. You are listening to the We Cyber You Unlocked podcast. And uh if you deploy a software system today, the security checklist you used yesterday is, well, it's already obsolete.

SPEAKER_02 0:13

Oh, entirely. It's ancient history by the time you hit production.

SPEAKER_00 0:16

Right. But what if the framework designed to save us from that static checklist is actually, you know, just a bigger, slower checklist in disguise?

SPEAKER_02 0:26

Aaron Ross Powell A massive bureaucratic one, yeah.

SPEAKER_00 0:29

Exactly. If you're tuning in, you have probably had a critical deployment paused for, I don't know, three weeks just to generate compliance artifacts for an authorization boundary that uh changed two days later.

SPEAKER_02 0:40

Aaron Powell Yeah, and that is the reality on the ground for like thousands of engineering teams right now. It's constant friction.

SPEAKER_00 0:47

Aaron Powell It really is. And that is the exact friction we are diving into today. We're looking closely at the NSSP 837 risk management framework, which uh most of us just call the RMF.

SPEAKER_02 1:01

Right. The RMF.

SPEAKER_00 1:03

So this is the foundational publication from the National Institute of Standards and Technology. It's the absolute backbone for how U.S. federal systems are secured. And you know, it has become a massive model adopted by private sectors globally.

SPEAKER_02 1:17

Yeah, it really set the standard.

SPEAKER_00 1:19

It did. And the core objective is shifting security away from a failed one-time static check and moving it toward a continuous, risk-based management approach. But uh looking at the reality of modern engineering, it forces a critical question.

SPEAKER_02 1:34

Aaron Powell The big one, really.

SPEAKER_00 1:36

Right. Does the comprehensive seven-step RMF truly foster continuous adaptive security, or does its structured, formal life cycle inadvertently create a heavy, bureaucratic process that limits agility in the face of rapid system changes?

SPEAKER_02 1:53

And I think that is the defining tension of modern security architecture right there.

SPEAKER_00 1:58

I agree. So I would argue that the RMF's structured life cycle is the ultimate blueprint for resilience, embedding security by design into every phase of a system's existence.

SPEAKER_02 2:10

And I will argue that the formal, sequential nature of the RMF steps risks bogging organizations down in process, potentially hindering the rapid adaptation required against constantly evolving threats.

SPEAKER_00 2:22

All right, let's get into it. So let's look at why this framework even exists in the first place. For decades, uh, our industry treated security as an event. Right, a box to check. Exactly. You would build a massive application, get it ready for production, and right before you flip the switch to go live, you handed it to a security team.

SPEAKER_02 2:41

Good luck, guys.

SPEAKER_00 2:42

Yeah, exactly. They ran a vulnerability scan, generated a list of flaws, you patched the worst of them, and then boom, you declare the system secure.

SPEAKER_02 2:51

Which is terrifying in hindsight.

SPEAKER_00 2:53

Truly. But NIST 800-37 recognizes that evaluating security only before deployment is a fundamentally broken model. It treats security as an ongoing life cycle. It forces an organization to build secure and resilient systems from the ground up, ensuring that risk visibility is the driving force of the entire operation, you know, from the moment you design the architecture until the day you decommission it.

SPEAKER_02 3:19

I hear that. I come at it from a different way, though I do want to establish some common ground immediately here. Sure. Static compliance is a dead end. The idea that you can evaluate a system's posture once and walk away is completely incompatible with today's threat landscape.

SPEAKER_00 3:35

100%.

SPEAKER_02 3:36

But where I fundamentally diverge is on the practical execution of NIST 800-37. The framework claims to be a continuous operational loop, but uh when you look at the mechanics of what it actually asks an organization to do, it is incredibly heavy.

SPEAKER_00 3:52

You think it's too much overhead?

SPEAKER_02 3:53

Oh, absolutely. You are mandated to formally categorize your system, select from massive catalogs of controls, implement them, run exhaustive assessments, and then secure formal sign-off from senior leadership.

SPEAKER_00 4:07

Right, the authorization step.

SPEAKER_02 4:09

Yes. And my concern is that you inadvertently recreate that exact same old school checklist mentality, just scaled up to a massive bureaucratic level.

SPEAKER_00 4:19

I don't know if I'd call it a checklist.

SPEAKER_02 4:21

Well, in an era where we're defending against highly ephemeral cloud environments and, you know, automated attacks, these heavy mandatory requirements can severely slow down a team's ability to genuinely respond to a threat.

SPEAKER_00 4:34

Okay, I hear what you were saying, but I think you have to look at the actual engine driving the framework, which is the final phase.

SPEAKER_02 4:42

The continuous monitoring?

SPEAKER_00 4:44

Right. The continuous monitoring step. The framework explicitly does not just authorize a system and let it sit there gathering dust. True. It mandates the ongoing assessment of the security posture to detect changes, to find new vulnerabilities, and to update technical controls in near real time. In theory, yes. Well, that continuous oversight proves the framework is dynamic. It forces an organization to constantly reevaluate its environment so that the defenses adapt just as quickly as the threat landscape shifts.

SPEAKER_02 5:13

So you call it an engine, but let's look at what happens right before you turn that engine on. To even get to continuous monitoring, you have to pass through the authorization step. Yes. And this is where the agility you are talking about hits a massive concrete wall. The framework requires a senior official to review the entire risk posture and make a formal, documented to accept the residual risk before a system is legally considered safe to operate.

SPEAKER_00 5:44

Well, yeah, because somebody has to be accountable.

SPEAKER_02 5:46

Yes, accountability is necessary. I'm not arguing against that, but walk through the reality of a zero-day vulnerability with me. Okay. Your continuous monitoring detects a severe automated attack vector. The engineering team looks at it and realizes they need to fundamentally alter the system architecture.

SPEAKER_00 6:04

Right, a major change.

SPEAKER_02 6:05

Yeah. Maybe they need to spin up a completely new routing protocol or deploy radically different access controls. By definition, they are changing the risk posture of the system. Does that trigger a reauthorization? If leadership has to formally review and sign off on systemic architectural changes, how quickly can that organization adapt? I mean the formal sign-off bottleneck directly contradicts the goal of rapid adaptation. Your engineers are waiting for paperwork to clear while the adversary is already inside the network.

SPEAKER_00 6:39

Okay, I have to admit, I get lost in the weeds when we hit that specific translation layer between the engineering floor and the executive suite. It gets messy. It does. If I have a team dealing with an active, critical threat, how does the formal communication pathway not just become an immediate roadblock? Walk me through how you see that playing out practically.

SPEAKER_02 6:59

Practically? It plays out as paralysis.

SPEAKER_00 7:02

Wow. Paralysis.

SPEAKER_02 7:04

Seriously. What happens is the engineers know what technical fix needs to be deployed. But because the system is bound by the RMF, they cannot just push the fix.

SPEAKER_00 7:13

Because of the authorization boundary.

SPEAKER_02 7:16

Exactly. They have to generate documentation proving that the new fix does not violate the existing authorization boundary. They have to map the new fix to the specific NIST control families.

SPEAKER_00 7:26

Right.

SPEAKER_02 7:27

They are optimizing their time to create compliance artifacts so the executive can sign the paper rather than optimizing their time to actually hunt the threat.

SPEAKER_00 7:35

Wait, let's look at the reality of that for a second, though. The authorization step isn't designed to be a roadblock, it is an essential governance mechanism. A heavy one. Sure, but the framework actually allows for ongoing authorizations. Once you establish that initial heavy baseline authorization, the continuous monitoring gives leadership near real-time visibility through automated dashboards.

SPEAKER_01 7:59

Yeah, if they're set up correctly.

SPEAKER_00 8:01

Right. But if an engineering team makes a change that falls within the already accepted risk tolerance of the organization, it doesn't require a grinding halt in a completely new from scratch authorization. It just requires an update.

SPEAKER_01 8:15

But defining that tolerance.

SPEAKER_00 8:17

The framework provides a structured vocabulary to communicate that new threat to leadership rapidly, so the risk-based decision is made with actual data rather than sheer panic.

SPEAKER_01 8:27

I agree, data is better than panic.

SPEAKER_00 8:30

Exactly. Without that structured governance, engineers are just cowboys making unilateral decisions that could accidentally expose the entire enterprise.

SPEAKER_02 8:39

I see your point, but that authorization bottleneck isn't just about security controls anymore. The moment this framework forced privacy into the exact same life cycle, the scope of what leadership has to sign off on absolutely exploded.

SPEAKER_00 8:55

Oh, privacy. I actually view that integration as one of the most vital upgrades to the modern framework.

SPEAKER_02 9:01

Really?

SPEAKER_00 9:02

Absolutely. Mist 837, unified cybersecurity risk management and privacy risk management into a single cohesive engine.

SPEAKER_02 9:11

Cohesive, maybe, but massive.

SPEAKER_00 9:14

Well, we are no longer living in a world where protecting organizational servers and protecting an individual's personal data are handled by two different departments who never talk to each other.

SPEAKER_02 9:23

That's true. Silos are bad. Right.

SPEAKER_00 9:25

By integrating them, the RMF ensures that systems are designed to protect both simultaneously. It engineers privacy directly into the architecture, right alongside the firewalls and encryption protocols.

SPEAKER_02 9:35

Conceptually, unifying them sounds wonderful. It makes for a great slide in a boardroom presentation.

SPEAKER_00 9:42

Okay, a little snarky, but fair.

SPEAKER_02 9:45

But operationally, it is incredibly cumbersome. Let's look at how this mechanism actually works early in the life cycle. Before you even select your defenses, you have to categorize your system based on its potential impact on confidentiality, integrity, and availability.

SPEAKER_00 10:01

The classic CIA triad. You look at the system and determine if the impact of a breach in any of those three areas would be low, moderate, or high.

SPEAKER_02 10:10

Right. And in the past, you were mostly evaluating the impact of unauthorized access, but now add comprehensive privacy assessments into that exact same matrix.

SPEAKER_00 10:20

Which is necessary.

SPEAKER_02 10:21

Yes. But you aren't just evaluating if data might be stolen by a hacker. You are evaluating the privacy implications of the organization legitimately processing that data in the first place.

SPEAKER_00 10:32

Your controls. Which usually means pulling from the NIST SP 853 catalog.

SPEAKER_02 10:38

Exactly. And let's explain the mechanism there for a second. NIST 853 is basically the master menu of every possible security and privacy defense. Ranging from physical locks on server room doors to complex cryptographic key management. Right. And NIST 837 is the engine that dictates when and how you order from that menu. I like that analogy. Thanks. But because your system is now categorized with both deep security and deep privacy impacts, selecting the appropriate controls becomes a dense, paralyzing undertaking. Paralyzing is a strong word. You are selecting hundreds of highly specific operational, technical, and management controls. You have to document exactly how each one addresses both cyber risk and privacy risk. Right. If you are trying to push a fast-paced hybrid cloud deployment, trying to map out and document this massive matrix of controls can stall a project for months before a single line of code is ever pushed to production.

SPEAKER_00 11:37

I see the friction there. Mapping 500 distinct controls in a spreadsheet while your development team is eager to spend up new infrastructure sounds like a heavy administrative burden. It's brutal. But here's the mechanism that prevents that from being a wasted effort. Why do we rigorously analyze and map those controls? To pass the audit. No, because failing to do so results in catastrophic systemic breaches. If you don't map out exactly how user data is handled, a single misconfigured cloud bucket exposes millions of people.

SPEAKER_02 12:11

Sure. Misconfigurations are bad.

SPEAKER_00 12:14

Let's look at a concrete real-world application to show how this adaptability actually functions.

SPEAKER_02 12:20

Please show me how that actually works, though. Take a cloud deployment. How does heavy categorization not instantly derail a rapid rollout?

SPEAKER_00 12:29

Okay. Imagine an organization launching a heavily distributed cloud system that processes financial data.

SPEAKER_02 12:36

Okay, high stakes.

SPEAKER_00 12:37

Under the RF, they start by categorizing it as high impact. During the selection phase, they don't just blindly copy and paste the entire NIST 800-53 catalog. They'd better not. Right. The framework is heavily tailored. They choose strong controls specifically mapped to cloud architecture, things like rigorous identity and access management, zero trust network policies, and automated monitoring agents. They implement those controls, run an assessment to verify the encryption is actually working, authorize the system, and enter continuous monitoring. This proves the RMF isn't a rigid one-size-fits-all strait jacket.

SPEAKER_02 13:16

It still sounds pretty rigid.

SPEAKER_00 13:18

No. It is a highly flexible process that adapts to the specific technology you are using. In fact, it operates beautifully within the broader global ecosystem of standards. How so? It leans directly on ISO 31000 for the overarching organizational risk mindset. It aligns seamlessly with ISO 27001, which establishes the overarching security management system.

SPEAKER_02 13:40

Okay. Yes. The ISO alignment is there.

SPEAKER_00 13:44

NIST 837 acts as the operational machinery to execute those high-level philosophies on the ground level. It takes the theory of risk and translates it into an actionable life cycle.

SPEAKER_02 13:56

I agree that it aligns elegantly in theory. The way it maps to the ISO standards creates a beautiful conceptual architecture.

SPEAKER_00 14:04

Thank you.

SPEAKER_02 14:05

But, and this is a big but. The cloud example you just gave highlights the exact opposite of agility. Using a rigid execution of the RMF on a modern cloud environment is like trying to map the exact location of every drop of water in a flowing river.

SPEAKER_00 14:20

That's a bit dramatic.

SPEAKER_02 14:21

By the time leadership signs off on your map, the water has already moved.

SPEAKER_00 14:26

Because the infrastructure is ephemeral.

SPEAKER_02 14:28

Exactly. Think about the operational reality of the assessment phase you just mentioned. The framework demands that you test and evaluate controls to identify gaps before authorization.

SPEAKER_01 14:37

Right.

SPEAKER_02 14:37

In a globally distributed cloud infrastructure, you might be using Kubernetes clusters where application containers are spun up and destroyed automatically based on network traffic.

SPEAKER_01 14:49

Sure.

SPEAKER_02 14:50

They might exist for five minutes. How do you manually assess and document the effectiveness of encryption in transit or role-based access controls across thousands of ephemeral containers that didn't exist an hour ago and won't exist an hour from now?

SPEAKER_00 15:03

Well, you automate the assessment. You build the continuous monitoring agents directly into the deployment pipeline so that every time a container spins up, it inherits the pre-authorized security controls.

SPEAKER_02 15:14

Which is incredibly difficult to do while satisfying the strict documentation requirements of the framework.

SPEAKER_00 15:20

It's hard, but it's not impossible.

SPEAKER_02 15:22

The source material notes that this framework is widely adopted in regulated sectors and claims to be adaptable to different industries. But I genuinely question if this heavy operational lifecycle is truly viable for non-federal entities who need absolute speed to market.

SPEAKER_00 15:39

Speed to market shouldn't mean rushing without security.

SPEAKER_02 15:42

No, but when an advanced persistent threat is aggressively probing your external perimeter, spending weeks in the assessment phase to rigorously document the effectiveness of hundreds of controls across a shifting hybrid infrastructure might mean you are perfectly secure on paper, but completely outpaced by the adversary in reality. You are trading operational agility for bureaucratic thoroughness.

SPEAKER_00 16:05

But if you don't map the river, you drown. Wow. I'm serious. I would argue that true operational agility is impossible without that thoroughness. If an organization does not know exactly what their system boundaries are, what specific controls are protecting the data, and whether those controls actually function as intended, they are not being agile when a threat hits. They're just moving fast and breaking things. Exactly. They are just panicking.

SPEAKER_02 16:30

There is a difference between understanding your architecture and being buried by it, though.

SPEAKER_00 16:35

But the structure of NIST 837 gives you the baseline understanding required to move fast. It forces you to define roles, responsibilities, and governance right at the very beginning in the preparation step.

SPEAKER_02 16:47

Yeah, the prep step is good.

SPEAKER_00 16:49

It forces you to answer the hard questions before the system goes live. So when that advanced, persistent threat does probe your perimeter, your engineering team isn't wasting critical hours wondering who has the authority to change the firewall rules. True. Or arguing over whether a specific database contains high-impact privacy data. They already know. The RMF creates a system that stays secure over time because it forces the organization to maintain a constant, structured awareness of its own architecture.

SPEAKER_02 17:21

Awareness is critical. I absolutely agree with that. Right. But you know, the framework heavily implies that rigorous documentation and formal checkpoints are the primary indicators of security. I wouldn't say primary. Well, they take up most of the time. My concern remains that a team can follow all seven steps flawlessly, achieve their formal authorization, continuously monitor their automated logs, and still fail to adapt quickly enough to a novel attack.

SPEAKER_00 17:49

Because of the culture?

SPEAKER_02 17:50

Yes. Because their internal culture has become fundamentally oriented around satisfying the process rather than hunting the actual threat. When maintaining risk visibility becomes synonymous with generating compliance artifacts for an auditor, the organization has lost the plot.

SPEAKER_00 18:06

I think that is a massive risk with any formalized framework. Absolutely. But it is a misapplication of the tool, not a flaw in its design. I don't know if you can separate the two so easily. While the RMF is explicitly written as a risk-based approach, not a compliance-based checklist. If an organization is just generating artifacts to keep the auditors happy, they are failing the core objective of the framework themselves. The entire goal is risk-driven decision making.

SPEAKER_02 18:35

But the mechanism of the framework inherently encourages the creation of those artifacts. When a senior leader needs to sign off and accept risk, they naturally demand documentation. Of course they do. They demand concrete proof from the assessment phase. The engineers, recognizing this dynamic, optimize their daily workflow to create that proof. It is human nature operating within a heavy bureaucratic structure.

SPEAKER_00 19:00

Yet without demanding that proof, leadership is flying blind. They are accepting risk on behalf of the entire organization, its shareholders, and its users without any empirical evidence that the system is actually defended.

SPEAKER_02 19:14

I know it's a brutal catch-22.

SPEAKER_00 19:17

It really is. The tension we are circling around here is the fundamental challenge of modern cybersecurity engineering. How do we move fast without breaking things, especially when the things we might break hold highly sensitive personal privacy data and critical organizational assets?

SPEAKER_02 19:34

Man, if you figure out the definitive answer to that, you will revolutionize the industry overnight.

SPEAKER_00 19:40

Ha, I'll let you know when I do.

SPEAKER_02 19:42

We are constantly trying to balance the need to push rapid technical innovation with the absolute necessity of rigorous structural defense.

SPEAKER_00 19:51

Very true. Well, as we bring our discussion to a close, it is clear that we are looking at two very different sides of a highly complex coin.

SPEAKER_02 20:00

Yeah, no easy answers here.

SPEAKER_00 20:02

Nope, but I stand by the position that NIST 837 is an indispensable blueprint. It successfully forces organizations away from the deeply flawed model of one-time security checks.

SPEAKER_01 20:15

Mm-hmm.

SPEAKER_00 20:16

By embedding security by design through a comprehensive life cycle, it creates systems that are not only secure at their launch, but remain highly resilient over time. The integration of privacy and security, combined with the mandate for continuous monitoring, provides a level of architectural visibility that, frankly, unstructured approaches simply cannot match.

SPEAKER_02 20:37

And I maintain that while the framework's overarching goals of continuous, adaptive, and risk-driven security are absolutely vital to survive today's threat landscape, we must be highly wary of its practical weight. Fair enough. Absolutely.

SPEAKER_00 21:26

The old model of evaluating a system's security only before deployment is a failed paradigm. No modern organization can survive treating security as a static event.

SPEAKER_02 21:36

On that, we are in total agreement. The threat actors are continuously adapting their offensive capabilities, and you know, our defensive postures must be equally dynamic. Spot on. If you enjoyed exploring the deep mechanics of these frameworks with us and diving into the real world friction of security architecture, please make sure to follow the channel so you never miss a discussion.

SPEAKER_00 22:00

I highly encourage you to visit weCyberU.com for more deep dives, engineering insights, and content like this.

SPEAKER_02 22:07

Yes, definitely check it out.

SPEAKER_00 22:08

As you evaluate your own deployment pipelines this week, ask yourself are you building a structure designed simply to pass an auditor's inspection, or are you cultivating an adaptable ecosystem designed to survive the storm? Thank you for listening.