The following note is raw research done around the idea of integrating (or extending) the OpenServiceBroker schema with OSCAL to better manage security control implementation and inheritance.
Pre-req context
What's OpenServiceBrokerThe OpenServiceBroker API is a standard for "binding" frontend applications to backend services within a Platform-as-a-Service. The model has been extended to include many IaaS providers using it to make their shared service offering available directly in/as a marketplace. The concept/standard evolved from cloud foundary ecosystem, as has been adopted by many large IaaS/PaaS providers.
What's OSCALOSCAL is a NIST standard aiming to create a machine readable schema/standard for security compliance framework implementation (e.g. NIST 800-53, SOC2, ISO-20017, CIS, etc, etc).
The goal of it is to provide the exchange format for vendor interoperability for security compliance accreditation and ongoing authorizations.
What's OpenServiceBroker & OSCAL together
The idea behind this research is to assess the feasibility and value/potential of coordinating an intergration of these standards.
User Story
As an application developer I want to deploy applications and manage/develop them for users needs. Security compliance is added work and often is not directly related to the system's actual security. Using a PaaS like Cloud.gov I want to inherit it's security controls, declare my response to their customer responsibilities in code deployable along side my application, and additionally address the custom/additional security controls of using a custom/3rd party backend service that I broker to. This custom backend therefore would need to declare its specific customer responsibilities for configuration and approved use (e.g. FTP-like storage, Database-as-a-service, Search-index-as-a-service IaaS service offering's specific tailoring/hardening).
Each of the examples below is one of either:
Application (that relies on/inherits from a PaaS's security controls)
Platform (that relies on/inherits from an IaaS's security controls)
Infrastructure (that relies on/inherits from itself)
This standard is THE standard federal security model for a new application
SaaS <- PaaS + Agency Procedures <- IaaS = ATO
Is important because they inherit each other's security model from the ground up. This inheritance is reflected in a concept commonly called a "Customer Responsibility Matrix (CRM)".
CRM is a term or art that has evolved out of the NIST 800-53/RMF framework. At its core is the idea that; I (provider) am telling you (customer) that I have implemented all these things for you to the degree I could/can - to the degree/extent I'm able to:
FULLY - Everything is fully implemented for you - you don't have to do anything more to implement this control besides using my standardizzed service (fully inherited).
PARTIALLY - We've done all-we-can to fully implement this protection - but you still need to take some action (e.g. enable a non-default setting or configure your service to not do this the wrong way). But here is what's left for you to ensure/do to fully implement.
NONE - Sorry we can't contribute to this or do anything for you here. You are on your own and/or this is an organizational control that you might inherit directly from compliance with your agencies policies and procedures?
Related to providing for an extendable schema for unique use cases - https://github.com/openservicebrokerapi/servicebroker/pull/670
OSCAL & Open Service Broker API
Pre-req context
What's
OpenServiceBrokerThe OpenServiceBroker API is a standard for "binding" frontend applications to backend services within a Platform-as-a-Service. The model has been extended to include many IaaS providers using it to make their shared service offering available directly in/as a marketplace. The concept/standard evolved from cloud foundary ecosystem, as has been adopted by many large IaaS/PaaS providers.What's
OSCALOSCAL is a NIST standard aiming to create a machine readable schema/standard for security compliance framework implementation (e.g. NIST 800-53, SOC2, ISO-20017, CIS, etc, etc).The goal of it is to provide the exchange format for vendor interoperability for security compliance accreditation and ongoing authorizations.
What's
OpenServiceBroker & OSCAL togetherThe idea behind this research is to assess the feasibility and value/potential of coordinating an intergration of these standards.User Story
As an application developer I want to deploy applications and manage/develop them for users needs. Security compliance is added work and often is not directly related to the system's actual security. Using a PaaS like Cloud.gov I want to inherit it's security controls, declare my response to their customer responsibilities in code deployable along side my application, and additionally address the custom/additional security controls of using a custom/3rd party backend service that I broker to. This custom backend therefore would need to declare its specific customer responsibilities for configuration and approved use (e.g. FTP-like storage, Database-as-a-service, Search-index-as-a-service IaaS service offering's specific tailoring/hardening).
Each of the examples below is one of either:
Is important because they inherit each other's security model from the ground up. This inheritance is reflected in a concept commonly called a "Customer Responsibility Matrix (CRM)".
CRM is a term or art that has evolved out of the NIST 800-53/RMF framework. At its core is the idea that; I (provider) am telling you (customer) that I have
implementedall these things for you to the degree I could/can - to the degree/extent I'm able to:fully inherited).