Security Controls within the ServiceBroker API model

[JJediny]

Related to providing for an extendable schema for unique use cases - #670

OSCAL & Open Service Broker API

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 OpenServiceBroker
The 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 OSCAL
OSCAL 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:

1. Application (that relies on/inherits from a PaaS's security controls)
2. Platform (that relies on/inherits from an IaaS's security controls)
3. 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:

1. 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).
2. 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.
3. 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?