Replies: 4 comments
-
@gregelin - You are listing the following "common controls" which are not controls ...
|
Beta Was this translation helpful? Give feedback.
-
A quick clarification first. Agency Policies might not be a system (with SSP) per se. These could be defined as a components of type=”policy” in a component definition. One per policy. You could also group them as a single component, but the more granular component per policy is better. The following is a way to do the math for the “Simple Site System” SSP, which would have the following component considerations:
The following are my assumptions about the referenced OSCAL documentation.
OSCAL Component DefinitionAgency Policy Component Definition
OSCAL System Security PlansEnterprise Data Center SystemThe "Enterprise Data Center System" will have at minimum the following components.
Enterprise Logging Service SystemThe "Enterprise Logging Service System" will have at minimum the following components.
If this is hosted in the "Enterprise Data Center System", then an OSCAL "leveraged-authorization" object can be used to point to the "Enterprise Data Center System" SSP and individual components can be defined to reference the "rhel-8-paas" or "vmware" software components provided by this common control provider. I omitted this for simplicity sake. Enterprise Authentication Service SystemThe "Enterprise Authentication Service System" will have at minimum the following components.
If this is hosted in the "Enterprise Data Center System", then an OSCAL "leveraged-authorization" object can be used to point to the "Enterprise Data Center System" SSP and individual components can be defined to reference the "rhel-8-paas" or "vmware" software components provided by this common control provider. I omitted this for simplicity sake. Simple Site SystemThe "Simple Site System" will define OSCAL "leveraged-authorization" objects for the following common control provider systems.
The "Simple Site System" will have at minimum the following components.
The "Simple Site System" could also reference the following components (in their respective systems) if any controls are exported/inherited for/from these components. I wasn’t sure if this was the case or not. These components could originally be defined in component definition(s) as well, which could be referenced at the point of initial use in the common control systems.
Answers to the Questions
So by my count you would have 9 (or maybe 12) components depending on the considerations above.
I indicated this above relative to each component.
There is not enough information in the scenario you provided to answer this. To some extent the answer depends on the quality of the vendor statements and their applicability to the risk appetite of the organization maintaining these information systems. OSCAL does not impose any limitations here. Vendor statements in component definitions can be reused to the extent that the organization maintaining these systems wants to. Vendor statements may be used wholesale, modified, or replaced on a case-by-case basis.
This is not something that OSCAL is opinionated about. This is an organizational decision. Organizations should consider the appropriate guidelines. OSCAL is not and will not be prescriptive here. OSCAL simply provides a place to document the organizational decisions. Where OSCAL can help with the ATO process is by defining where and how control implementation details are inherited (using the leveraged-authorization object), which can be used by an authorizing official (and their delegates) in deciding to issue an ATO. This view of inheritance helps them understand what controls and risks are addressed by the combined solution and what due diligence has been done by others in the systems their systems are inheriting from.
This can be built, at least partially. There is no control implementation narrative included here, so this would need to be stubbed out to make valid OSCAL SSPs. I'll let this discussion continue for a bit. Maybe someone will volunteer to build the examples. |
Beta Was this translation helpful? Give feedback.
-
@david-waltermire-nist - this is a great guidance for the problem stated.
They can be treated as separate systems that are ATOed separately and which provide common controls implementations to other systems. You can think of OKTA a system on its own that has controls implemented (IA included) to secure access to the OKTA's data, the identities and the credentials managed. The IA controls provided to other systems are not the same instances of the controls implemented to secure OKTA (they are not inherited in the sense that if you get authenticated to access OKTA-system you also get authenticated to access other systems for which OKTA provides ID-as-a-Service. For example admins managing OKTA might need multi factors authentication, but OKTA could just provide password-based authentication to other systems. There are controls like physical security controls that are inherited by all systems residing in that facility because once the facility is locked, the control is applicable through inheritance to the systems located there. OSCAL facilitates the representation of the information but neither OSCAL not the RMF teams are imposing on organizations or system owners how to compose or decompose their systems and networks to perform a proper assessment or to ConMon the system. The only rule I recall from the RMF 800-37 rev2 is that everything that it is brought into the authorization boundary of a system must be assessed and authorization as part of that system. So if splunk becomes part of each system it is monitoring, it has to be assessed that it is securely managing data collected with every system it becomes part of, triggering redundant assessment work. If it is treated as a separate system that provides monitoring controls to other systems, only the implementation of the controls provided to other systems need to be assessed during system's assessment, and the ATO of the splunk system is used in the process of assessing the risk and authorizing the system using the controls provided by splunk. |
Beta Was this translation helpful? Give feedback.
-
Similar to the Splunk example used above would be Active Directory.
|
Beta Was this translation helpful? Give feedback.
-
About
My hope for OSCAL:
IT Systems can reuse components to go from Vendor to Assessments reusing as much information as possible, especially control implementation statements.
My fear for OSCAL:
Divergent definitions for components results limit us to today’s status quo reuse only of common controls unique to each organization that cannot be decomposed into specific technologies.
For discussion:
What can we say/agree about the components and reuse of the respective control implementation statements of the below Simple Example Site? (Questions follow example's description.)
Simple Example Site IT System
The “Simple Example Site” (SES or “SimpleSite”) IT System consisting of a Django web site running on a single virtual host using the RHEL 8 at a federal agency which has defined it’s FISMA-related IT policies and provides a couple core common controls for authentication and logging.
Common Controls
Software
Questions
How many components are in the system?
What are the types of components in the System?
To what degree can control implementation statements provided by the vendor be reused?
What are the ATO/assessment boundaries relevant to the system?
What would be the OSCAL representing the system?
If the answers to any of the above are, “It depends,” then what is the criteria that determines different resulting answers (e.g., what decisions is the agency making that determines a different “correct” variation)?
Feel free to weigh in on any or all of these questions or share another observation.
Beta Was this translation helpful? Give feedback.
All reactions