Risk management is a part of cybersecurity that many professionals either love or despise. Now, this is not without reason, and that stems from the tired, yet accurate, stereotypes that have plagued the Risk Management Framework (RMF) for years. These stereotypes include the reality of endless paperwork, the cost of “extremely time-consuming” processes, and the resulting burden of “immediately outdated and inaccurate information.” The evolution of this methodology has been notoriously slow and ineffective, a problem that can only be fixed by motivated cyber engineers who aren’t afraid of a challenge.
Who Am I?
Before tackling OSCAL (Open Security Control Assessment Language), you’re probably wondering, “Who is this guy and why is he doing this?” Hello, my name is Carl Markowski, and I am an Associate Cyber Engineer at Dark Wolf Solutions with just under half a decade of experience in the industry. I am a United States Marine Corps veteran, having served as a Data System Administrator with 1st Battalion 7th Marines (Oohrah to any Marines reading this!). I also recently graduated from the University of Colorado, Colorado Springs with a bachelor’s degree in Computer Science.
Ever since serving as a system administrator, I have been fascinated with cybersecurity. This led me to pursue a career with two simple guiding hopes: One, make a genuine difference in the industry; and Two, be a forever student. These two guiding principles are the “Why” to this journey and will help fuel my desire to break through the inevitable roadblocks in this journey.
The Challenge: OSCAL’s Paradox
As I started my career here at Dark Wolf Solutions, I was quickly introduced to the daily reality of the RMF, hearing all the horror stories. Luckily, senior professionals introduced me to the promise of OSCAL. I dove right into the deep end, stunned to learn that OSCAL has been around for quite some time, yet there are not many widespread implementations within the industry—not as many as you would expect for being over four years old. I asked myself the same question you probably have: “Is there something wrong with OSCAL?” Well we will find out together throughout this process.
My Public Commitment
The reality is that implementing this tool is not as straightforward and easy as we would all like. It demands time, skill, and a deep architectural understanding. But as many wise and experienced people say, “If it’s easy, it’s probably not worthwhile.” I have never been one to take the easy route either and am excited to tackle this challenge with you by my side.
So here we go. This series, “My Personal Level Up: Cracking the Code of OSCAL’s Technical Architecture,” is my public commitment to master this complex language and document every challenge, breakthrough, and practical application along the way. Follow along with me as I take this journey to learn all things OSCAL.
OSCAL Baseline: Current State of Knowledge
Admittedly, I have been working with OSCAL for about two months now, and I feel it would be beneficial to share my existing knowledge to lay the foundation for this series.
OSCAL is a machine-readable data standardization framework used to structure and exchange control data applicable to the NIST 800-53 control list (and other baselines). This framework is logically split into three main layers that come together to provide an encompassing view of a system’s current compliance status:
Control Layer
Catalog Model: This is the master list of security controls published by NIST. Along with the control definitions, the Catalog includes parameters, assessment objectives, and other foundational information for each control.
Profile Model: This file contains only the specific control IDs, baselines, and overlays applicable to a system. It allows a system to choose exactly what controls will be assessed.
**Side Note: From the Catalog Model and the Profile Model, you generate a Resolved Profile. This is the cross-referenced result of taking the chosen control IDs and gathering all the information from the Catalog Model that pertains to them. There are some tools that perform this operation, most notably from NIST themselves is the NIST CLI tool.**
Implementation Layer
- Component Model (CDEF):
This model is a list of tools and capabilities that the system uses to implement controls. For example, if a system uses a SIEM (Security Information and Event Management) tool, we create a Component Definition for that tool and apply it to any control it answers for in the SSP. We will explore how this concept is crucial to creating a “living” SSP later in the series. - System Security Plan (SSP) Model:
The SSP Model is the culmination of the prior three models. It contains system information, points of contact, responsible roles, and, most importantly, the control implementations. Think of your traditional paper SSP, now in a nice, machine-readable format that can be used in scripts and updated on the fly via traceable data references.
Assessment Layer
This is where my current knowledge base thins out and needs to be further established. The Assessment Layer is made up of the Assessment Plan Model, Assessment Results Model, and Plan of Actions and Milestones (POA&M) Model. These models seem self-explanatory, but that is not a reliable way to gain knowledge. So, exploring these models and how they tie into the remaining models is part of the goals moving forward.
Moving Forward
As mentioned, the first step and goal as I continue this journey is to understand and explore the implementation of the Assessment Layer.
- This will include reading documentation and dissecting examples to completely understand the Assessment Plan Model, Assessment Results Model, and the POA&M Model.
- Following my deep dive into the Assessment Layer, I will create my own practical examples of each model. I will share these later on to provide an example for those that are visual learners (like myself) and to give an encompassing view of what is discussed on paper and how it is actually put into practice.
As I move forward and begin tackling these next steps, we will be working towards integrating OSCAL with tools to gather live system configurations. OSCAL delivers all these models and layers in three different machine-readable formats: JSON, XML, and YAML. These formats make it “easier” to integrate with tools and other systems to gather those different control implementations and security configurations.
Thank you for joining me in this journey. I couldn’t be more excited to share my victories and defeats with you. I look forward to seeing you in the next one!
References and Resources:
NIST OSCAL Guidance
https://pages.nist.gov/OSCAL/learn/
NIST CLI Github