A New Way to SSP: The Component Definition Approach to Defining Controls

A New Way to SSP: The Component Definition Approach to Defining Controls

Guest Post by Johann Dettweiler, CISO, stackArmor

Imagine a world where the “say nothing” narrative implementation statements, rampant across the landscape of System Security Plans (SSPs), get replaced by a definitive, understanding of system state to determine the implementation status of controls. For those of us that have languished with the “old way” of writing SSPs, we dare not imagine that promised land. However, with the introduction of the Open Security Controls Assessment Language (OSCAL), there is promise of a light in the darkness, a sip to a desert wanderer, a cool breeze in hell – I present to you – Component Definitions (CDEFs)!

“Cue “Thus Spake Zarathustra” – BUM… bum… BUMMMMM… BUM, bum, BUMMMMM!”

Alright, admittedly that may have been a little bit over dramatic, but if you’ve ever experienced reading or writing an SSP, suffice to say the process “ain’t perfect”.

The Problem with Traditional Implementation Statements

They just aren’t that good. There…I said it. Utilizing a narrative approach to describe technically complex implementations of mostly narrative security controls is fraught with challenges and shortcomings. A few areas that come to mind:

• Subjectivity: These statements often end up being generalized, ambiguous, or filled with “fluff” that often doesn’t really get to the “spirit” of why the security control exists. What does it do!?
• Limited Usefulness for Assessors: Traditional narratives might leave assessors searching for concrete evidence about the state of the system. They often need more direct insights, which are diluted by narrative prose. How do I test it!?
• Technical Limitations – The “writers” of an SSP, often, are not the implementers of the controls. This requires a layer of “translation” that often ends up in important details being inadvertently left out or glossed over. What does it mean!?

And let’s not forget the most egregious fault of today’s implementation statements: Time-Intensive

To a fault – for everyone involved. The authors need to come up with new and creatively abstract ways to talk about Role-based access control for 30 different controls. Assessors must sort through the chaff and interpret it into something meaningful that can be used to test the system. All these words equal lost time and resources.

The Component Definition Approach

In short, this approach is about getting to the “state” of the system—what’s actually there that makes the security controls work. Imagine an SSP where, by component title alone, an assessor can quickly understand the technologies, processes, and techniques used to implement each control. Suddenly, we’ve cut down on the guesswork, the assumptions, and the painful slog through “just words.” Now, we’re dealing with a structured, component-based map that they can use to quickly validate the true implementation of security controls.

• What It Is: The CDEF approach maps controls directly to the actual components—servers, IAM policies, monitoring configurations, whatever they may be—that perform each function. Each “component” then stands as a mini-blueprint showing what security measures are actively protecting the system.

In a CDEF approach, the system gets broken down into its component parts, with each part tied directly to specific control functions. A component might be a concrete item like an IAM role or a Next-Gen Firewall, or it could be a process like Vulnerability Management. Each component addresses specific controls or a series of controls, and when documented this way, an SSP reader can quickly and accurately understand the actual state of the system.

Key benefits to this approach are:

• Accurate Representation – CDEFs draw direct line to the state of the system at the control requirement level of granularity.
• Speed of Assessment – Assessors can quickly understand the “components” that need to be validated and what configurations they should be focusing on to test the implementation of controls.
• Automated Validation – component configurations can be automated to demonstrate control implementation. Instead of explaining IAM configurations to an auditor, an automated report that associates all groups to their assigned privileges can be used to validate least privilege.
• Efficiency in Updates: updates and significant changes become as easy as tweaking the relevant component, keeping the SSP current without having to spend hours using “Find and Replace” every time a piece of software is updated.

Challenges of the Component Definition Approach

When it comes to actual security practices, clarity and accuracy are critical. The CDEF approach aligns far better with how systems are structured and assessed in the real world. Vague narratives are replaced with precise documentation. Each control requirement is represented by a component or set of components utilized to implement the requirement, and assessors can follow the SSP like a blueprint.

However, while the CDEF approach is a vast improvement, it’s not without its challenges—particularly in deciding how granular each component should be. This is something that we’re currently working through as we being to adopt the CDEF approach. Defining components too granularly can lead to the documentation becoming overly complex; defeating the purpose of the approach. Conversely, too little granularity and the approach loses its clarity, value, and ability to automate.

There likely isn’t a “right” or “wrong” answer to this challenge, it’s more of a “I guess we’ll finding out”. OSCAL is incredibly new and very much in its infancy when it comes to being adopted. Given the novelty of the CDEF approach, push-back from assessors and authorizers that are seeing this new way of doing things for the first time is anticipated and welcomed. When writing CDEFs, approaching it with an “iterative” mindset is critical to maintain purpose (and sanity).

Tips and Tricks

For organizations interested in adopting the CDEF approach, here are some practical steps to get started:

1. Define Key Components: Identify the main security components in your system, such as identity management, logging mechanisms, and access controls, and determine how each one maps to specific security controls.
   1. Keep granularity in mind – components need to address control requirements, however, if you find yourself creating a new component for every control requirement, you’ve gone too granular.
2. Create a Reusable Baseline: Consider reuse across projects. When defining components think about the ability to leverage that component across systems, networks, and/or departments.
   1. The goal should be to create a ‘database’ of components that can be leveraged across projects.
3. Utilize Automated Tools: OSCAL is great, but it, by its very nature, is meant to be read by machines. Writing directly in JSON or SAML is never a good time.
   1. Automated OSCAL creation tools can help teams focus on the “meat” of the work and remove some of that abstraction that is inherently introduced by machine-readable content.

Conclusion: Shaping the Future of SSP Documentation

The CDEF approach is more than just a new way to document SSPs—it represents a shift toward making security documentation more representative of the actual system state. The closer we come to representing the system state, the closer we can move towards true compliance and authorization automation.

For organizations, adopting CDEF means transparency, responsiveness, and a much-needed break from the traditional SSP drudgery. As OSCAL continues to mature and be adopted by more assessors and authorizers, this structured approach will prove invaluable for staying compliant, proactively managing system security, and truly automating the assessment and authorization process. So, let’s embrace CDEF and build a future where SSPs represent not just another box to check.