Authorization to Operate (ATO) in a day and on-going authorization are compliance nirvana. The ATO is the authorizing official’s statement that they accept the risk associated with the system running in production environments using live business data. The idea that all of the information necessary to make a risk decision is at hand and can be consumed by decision makers is what every compliance program is trying to achieve. The National Institute of Standards and Technology (NIST) provides guidance for the security of federal systems in NIST Special Publication 800-53 Revision 4, in the form of 261 recommended controls at the Moderate baseline. The Federal Risk and Authorization Program (FedRAMP), cloud security guidance, adds additional controls bringing the number up to 326. The goal of these documents is to help system owners reduce their risk exposure. Recurring Independent Verification and Validation (IV&V) efforts attempt to gather this risk information by assessing the methods used to meet the NIST and FedRAMP objectives but the time it takes for those assessments to run their course can be very cost prohibitive and prevent on time application delivery. The key then becomes surfacing the disparate data that is present in those systems to a more readily available presentation layer. Add to this the challenge of gathering that data in fluid environments that allow for flexible implementations, diverse infrastructures, and vast user experiences, while maintaining strict policy enforcement.
Consider NIST SP 800-53 Rev. 4 control SI-4. SI-4 states:
The organization: a. Monitors the information system to detect: 1. Attacks and indicators of potential attacks in accordance with [Assignment: organization-defined monitoring objectives]; and 2. Unauthorized local, network, and remote connections; b. Identifies unauthorized use of the information system through [Assignment: organization-defined techniques and methods]; c. Deploys monitoring devices: 1. Strategically within the information system to collect organization-determined essential information; and 2. At ad hoc locations within the system to track specific types of transactions of interest to the organization; d. Protects information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion; e. Heightens the level of information system monitoring activity whenever there is an indication of increased risk to organizational operations and assets, individuals, other organizations, or the Nation based on law enforcement information, intelligence information, or other credible sources of information; f. Obtains legal opinion with regard to information system monitoring activities in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations; and g. Provides [Assignment: organization-defined information system monitoring information] to [Assignment: organization-defined personnel or roles] [Selection (one or more): as needed; [Assignment: organization-defined frequency]].
SI-4 is challenging because it is often an inherited control; a high level control supplied to all systems by a control broker. This is the correct approach for this control, however it is often implemented at such a high level it loses its value. Attack indicators need to be so broad that every system fits the mold and therefore systems have a restriction on use that can hamper efforts and business objectives. Security is not a one size fits all solution. Which is why tools like Sysdig Secure, part of the Sysdig Secure DevOps Platform, become critical.
Utilizing policies that meet the needs of not just the business but the needs of the specific container can be world changing. Sysdig Secure and the included out of the box, and/or customer created rules allow the use of micro-policies which allows the monitoring of ephemeral containers and for the forensic analysis of the container’s activity.
It might seem like architecting a container specific security policy approach would be a management nightmare, but Sysdig Secure and the included rules makes it easy. Utilizing tags, an ever growing necessity, you can attach monitoring policies as part of the container deployment pipeline. This approach allows us to satisfy SI-4 objectives as it pertains to the container. A system security plan would simply state the use of Sysdig Secure as the monitoring solution and list the tags implemented for monitoring. The control provider would then be responsible for using or modifying the included Falco rules library, or creating rules the included Sysdig Secure rules editor for use and inheritance. For example:
Images from Sysdig Secure using the included Falco rules to detect and alert on a terminal shell in a container and Unexpected inbound connection source which align to NIST 800-53 Rev. 4 SI-4.
By treating the out-of-the-box rules included with Sysdig Secure DevOps Platform or custom created rules as part of the configuration management solution, container monitoring itself becomes part of the configuration management solution. As a result of achieving this automated monitoring and building from known images, compliance programs can begin to establish risk. Layer in Sysdig’s container baselining capability and organizations can establish known risk criteria before containers ever reach production. Using the capabilities in Sysdig and its focus on the container life-cycle, organizations can validate compliance and enforce policies during build and at run-time. Its flexibility allows the system to be rigid and flexible at the same time. Rigid in that it must adhere to predefined rules, but flexible in that those rules can be customized to fit the function of the container.
Utilizing the Sysdig Secure DevOps Platform, organizations are able to define their micro-policies, test these policies against runtime profiling, and deploy these policies for consumption. These micro-policies allow for a more nuanced approach and, instead of encumbering development and operations, support the flexibility necessary in modern architectures. Security teams working with the Sysdig solution benefit from policy development to policy monitoring and assessment.
An organization deciding to embrace this level of functionality and support would need to refocus efforts on developing policy at both the high-level and the very low level. NIST has information specific to containers under NIST SP 800-190. Sysdig has more information on helping organizations achieve compliance on NIST SP 800-190 application container security with Sysdig Secure.
See the original post on Sysdig blog here.