By Kathryn M. Farrish, CISSP BAI Information Security
Security Control Inheritance is one of the most powerful tools available to facilitate the RMF process. Unfortunately, it is not always very well understood, and, as a result, is often misapplied.
CNSSI 4009 defines Security Control Inheritance as “a situation in which an information system or application receives protection from security controls (or portions of security controls) that are developed, implemented, and assessed, authorized, and monitored by entities other than those responsible for the system or application; entities either internal or external to the organization where the system or application resides.”
The classic example of inheritance involves a system that is hosted at a departmental or agency data center. Such a system will inherit numerous security controls from the data center, typically those involving physical security (door locks, guards), environmental security (fire protection, power, air conditioning) and network boundary defense (firewall, network intrusion detection). All of these controls are maintained by the data center and are included in the data center’s authorization (accreditation) boundary.
The big benefit of inheritance is that it eliminates redundant validation of compliance—the compliance of the “providing system” (data center) automatically inures to the benefit of the “receiving system” (hosted customer system).
In order for a system owner to claim inheritance of one or more controls from another system, the following three conditions must be met:
1. The control must be implemented and maintained outside the boundary of the “receiving system”
2. The “providing system” must have an Authorization to Operate (ATO)
3. The “providing system” must have a contractual obligation to provide the specified controls; this is typically in the form of a Memorandum of Agreement (MOA) or Service Level Agreement (SLA)
Some frequent misunderstandings of these “rules of thumb” are:
- Attempts to claim inheritance of controls that are implemented inside the receiving system’s boundary. For example, some data centers offer optional services such as patching and maintaining operating systems for their hosted customers. This would not be considered as inheritable since it is taking place within the receiving system’s boundary.
- Attempts to claim inheritance of controls from hosting providers that do not have ATO (e.g., commercial collocation sites). Government-sponsored programs such as FedRAMP have been established to enable commercial providers to obtain formal ATO so their customers can inherit from them.
- Attempts to claim inheritance when there is no clear-cut contractual obligation on the part of the “providing system”.
It is worth noting that inheritance can be a “two edged sword”—in the event the “providing system” is non-compliant on any of its inheritable controls, these risks are also carried by each “receiving system”.
System owners who utilize the eMASS tool can leverage functionality that allows them to identify and request inheritance from their “providing system”. Once such a request is accepted, the “receiving system’s” eMASS record is automatically linked to the “providing system”.
IT Dojo offers a comprehensive course on the transition from DIACAP to RMF. Please take a look at our RMF training courses here.
