I’ve been fortunate enough to have been involved with open standards and open source communities for most of my career, and I couldn’t be more excited to continue that tradition with Easy Dynamics. I’d like to give a little bit of background on my journey thus far, then give my take on our recent announcement around the Open Security Controls Assessment Language (OSCAL).
How Did I/We Get Here?
Like many others in the 90s, I was hand-crafting HTML pages before creation tools matured to the point of producing acceptable source, which required a solid understanding of the HTML standard and closely following its rapid changes. My participation in open source then primarily involved answering questions on forums for a few tools. Now of course, just about everyone benefits from this standard on a daily basis.
In the early 2000s, I drove the adoption of Asterisk as the open source PBX for a small organization, leveraging Session Initiation Protocol (SIP) and IAX standards and contributing to Asterisk itself and other projects in that ecosystem. The shift to open VoIP technologies and the availability of open source implementations was a major turning point for the industry, enabling organizations to reduce infrastructure costs and provide easier support for remote working.
As I became more involved with software development around image research and categorization, the Dublin Core Metadata Initiative and the International Press Telecommunications Council (IPTC) Photo Metadata Standard were critical, leading me to contribute to and create several open source projects that supported those standards, including Apache Tika, and I was able to present at a few of IPTC’s conferences. These open standards enabled interoperability, from cameras to stock agencies, to end-consumers, and drives the description and credit information you use in photo-related apps today.
My product development responsibilities then shifted towards more complex intellectual property rights and licensing of creative content, where I embraced the Open Digital Rights Language (ODRL) standard, participating in their workgroups and presenting at conferences, building applications, and giving feedback on the specification. IPTC also later based their RightsML standard on ODRL. While not as commonplace as some of the previous standards mentioned, these specifications are critical to helping organizations convey rights data across systems.
When the need for integration with multiple Digital Asset Management systems arose, I investigated several relevant standards, but ultimately chose to move forward with Content Management Interoperability Services (CMIS), and during my time at Alfresco, a company founded on open source, I also helped form the CMIS4DAM technical committee in the OASIS standards body. The broad adoption of the CMIS specification enables a single code base to interact with dozens of CMIS-supporting applications for a wide range of horizontal use cases.
With increased attention on Identity in more modern software architectures and environments, particularly around authentication and authorization of microservices against a centralized Identity Provider (IdP), there was a need to support the well-known Security Assertion Markup Language 2.0 (SAML) standard and the newer (at the time) OAuth 2 and OpenID Connect (OIDC) standards. In-depth knowledge of those specifications was pivotal in understanding the nuances of vendor implementations and for the release of a downstream open source IdP implementation. That work certainly continues at Easy Dynamics, where modern Identity solutions are one of our core strengths. We’ve joined the OpenID Foundation, have participated in the iGov working group, and have contributed to open source IdP initiatives. Core Identity standards like OIDC have been widely adopted and implemented by nearly every modern application or service that involves authentication and authorization, enabling secure integrations that meet compliance and assurance levels when configured and deployed correctly.
What’s This About Compliance?
While I had previously been exposed to compliance processes for government agencies and regulated organizations from a software vendor perspective, it wasn’t until I joined Easy Dynamics that I began to truly understand the impact those activities have on authorizing a system for live, production environment.
It became apparent that while NIST’s Risk Management Framework (RMF) and 800-53 security and privacy controls, the Federal Information Security Modernization Act (FISMA), and the FedRAMP Authority to Operate (ATO) process were well thought out and necessary, the implementation of it in practice did not meet the needs of everyone involved in a sustainable way.
The numerous compliance documentation tasks related to creating a System Security Plan (SSP) are often addressed only after development is complete and done so in huge Word documents or spreadsheets transferred between system implementers and assessors for manual review. Representing the inheritance of controls implemented by leveraged systems like those offered by Cloud Service Providers (CSP) can make the process even more cumbersome.
While there are several Governance, Risk, and Compliance (GRC) tools that help on the compliance documentation side, their access is usually limited to a handful of individuals, often have a suboptimal user experience, and the output is typically still in those legacy formats.
There Must Be a Better Way
What if, instead of Word documents or spreadsheets, we could express artifacts like SSPs in a machine-readable format that could enable automation of some of the process?
What if CSPs could define the control implementations of their leveraged components in that machine-readable format and facilitate explicit inheritance in SSPs?
What if we could grow an ecosystem of tools for creating, manipulating, and validating compliance artifacts around that machine-readable format?
What if that machine-readable format was produced and governed by a reputable standards body already intimately involved in compliance?
After hearing that NIST was working on the Open Security Controls Assessment Language (OSCAL) my eyes widened as I leaned in for a closer look. The same organization that created the RMF and 800-53 controls was defining the representation of control catalogs, baseline profiles, components, SSPs, assessment plans, etc., in machine-readable XML, JSON, and YAML formats. It held the promise of modernizing the entire ATO process.
As I’ve done with most open standards in the past, I started following the community, attending their open meetings, getting a sense for their roadmap and direction, submitting issues and pull requests, observing the level of participation from vendors, all to determine the likelihood of the effort being a long-term success.
It was clear that the core OSCAL team was experienced, talented, and driven to solve this problem, and not just for FISMA and FedRAMP, but other compliance frameworks in the future as well. The 2021 OSCAL Workshop reaffirmed the community’s potential, with vendors, CSPs, and agencies expressing interest and showing progress to date.
Let’s Do This!
There was no doubt that Easy Dynamics’ client services work would benefit from OSCAL someday, but it was such an exciting project and at the right point in its maturity where we felt we could materially contribute and wanted to get more directly involved.
While there were several transformations, validation, and other back-end tools around OSCAL, there didn’t seem to be much focus on user interfaces. We began development of a library of re-usable React components that provide a direct view into OSCAL data elements in JSON format which can be assembled into pages to render catalogs, profiles, components, and SSPs.
We’ve released the React library and the resulting viewer app as an open source project. So, if you’re building an OSCAL-related React application you can drop those components into your code today. Not everything in the OSCAL models is currently represented by the components, and the user experience primarily targets the example OSCAL content available from NIST and FedRamp, but as an open source project, we encourage the contribution of additional features and fixes.
Although the OSCAL models are incredibly comprehensive, they seem to be still somewhat document-centric because they are essentially the machine-readable equivalent of the previous Word and spreadsheet artifacts. We wanted to start the conversation around how systems might want to interact with and manipulate those models and the relationships within them, programmatically through a REST API interface. For example, suppose the user of a client application is trying to associate an already defined individual with an existing SSP. That client application shouldn’t be required to download the entire SSP and re-upload to insert that one entry. There should be a REST endpoint that facilitates the simple action of adding a party to an SSP.
We’ve released a proposed start to an OSCAL REST API definition as another open source project. This consists of an OpenAPI specification that describes how systems might manipulate catalogs, profiles, components, and SSPs. We’re hoping that the OSCAL community will start to evaluate what’s there and begin creating issues and pull requests to further develop the specification so that vendors can begin to implement against it, enabling even greater interoperability of OSCAL tools.
Our plans don’t stop there. We’re continuing development on other OSCAL-related projects, primarily focused on the control and implementation OSCAL layers, and hope to release at least some of those as open source projects in the future.
We want to thank everyone who has helped to make the OSCAL community what it is today, and would like to encourage you to join in!
Update 03/18/2022
We presented at NIST’s 3rd OSCAL Workshop and released two more open source projects. Read more and watch the recording at DevSecComp(liance)Ops with OSCAL.
