Written by Immaculate Tact:
I don’t pretend to cover new ground here, but RMF is as good a starting place as any. Every exploit eventually meets an equally adequate or better control. The nature of the beast requires that we find competent means of mitigating both the potential and impact of an identified risk. For this purpose, NIST standards have been developed to meet a security in depth strategy that provides a layered defense against both external and internal threats. This tool is the Risk Management Framework (RMF).
Risk Management Framework (RMF)
RMF is a risk-based approach to security, which factors in all the variables of a system to determine what types of controls are necessary, and what specific risks exist on that system. This means factoring in hardware, software, network topography and the impact that a potential threat would have if it were actualized. RMF also considers the security triad and balances the needs and functionality of a systems with the real-world impact of a successful attack.
Risk Management Framework (RMF) is the solution we utilize to identify our weaknesses and establish a culture of continuous security improvement. The benefit of RMF is that it is dynamic and scalable in nature, and provides the opportunity for practitioners to assess actual risk and justify real-world security controls, rather than rely on “check in the box” solutions that try to cover all possible scenarios, many of which may not fit the environment they attempt to protect. You ultimately want to tailor the solution to fit the problem, rather than throw everything you have at the wall and hope it sticks.
RMF is implemented in a step-based approach which factors in essential system activities, business processes, and organizational requirements. RMF is not a one-time solution, nor is it a one-time evolution. RMF requires several iterations which gradually improve the security of a system and follows a six-step process:
- Categorize Information Systems: This step outlines the process for identifying and documenting system configuration, operational requirements, and network boundaries. This means drawing a system boundary (where the system network terminates, as well as all of the networked devices within the scope of the system), and documenting all of the software required to operate the system. This also includes every significant piece of software on the system, including the library it is written in (.net, java, etc). We must have a holistic view of the system, and this requires good, accurate documentation. Once we have a complete understanding of the system, we can then start to compile effective controls.
- Select security controls: Step 1 identifies our complete environment; step 2 aims to determine the security controls for that environment. Each system and its related environment are unique, so naturally a unique set of controls must be implemented to meet the needs of the system. There are no specific set of conditions to meet the requirements of step 2 in the RMF process, so it is up to stake holders and decision makers to identify appropriate controls based on industry standards and practices for the applicable system variables. These variables include operating systems, software, network devices, and peripheral system devices. It is at this step that we submit our RMF package to the validating team, which typically consist of a system engineer and information assurance specialist. This group is responsible for identifying which controls should be implemented and what additional system information needs to be addressed.
- Implementation: Once an organization has identified the appropriate set of security controls, it is imperative that the controls are implemented properly. Security controls can be compensating in nature (indirect controls that don’t directly mitigate the risk, but mitigate through alternative factors), but ultimately must be designed to reduce risk to the target system in a way that is objective and measurable (NIST 800-30). Security controls fall under three categories: Technical, Administrative, and Physical. Technical controls are those that we use to harden a system directly such as configuring registry keys, modifying group policy objects, or logging and auditing. Administrative controls are typically organizational policies and procedures such as duty rotations, data handling requirements, or restricting login access to specific working hours. Finally, physical controls are those that control physical access to organization assets, such as CCTV, man-traps, or security badging. A combination of these controls is termed “defense-in-depth”, or the “castle approach” which aims to weave a combination of these controls into a multi-layered defense strategy.
- Assess: From a continuous improvement perspective, applied security controls must be monitored and assessed for their efficacy and ability to effectively reduce risk to the system. If controls implemented in step 3 do not provide the desired outcome in respect to the system requirements (network topography, software, hardware capability) then a supplemental security plan must be established that address weaknesses in the security plan. This may involve additional technical, administrative, or physical controls. Step 4 is done on a regular basis, and requires testing and evaluation personnel to perform penetration testing, software analysis, and other techniques to verify that the controls have the intended effect.
- Authorize: The authorization to accept (place into production) an information system ultimately rests with the key decision-making stakeholders and is based on the factual evidence provided in steps 1-4, as well as the organization’s risk acceptance level. Depending on the system and its capability, decision makers may lower or increase the level of accepted risk. All systems are unique, which mean the level of acceptable risk varies as well. Once a system meets the threshold for acceptable risk, a Plan of Action & Milestone document is created which provides outstanding security control information for personnel to work and mitigate over time to improve the security posture of the system. No system is inherently secure from risk, and as such it is paramount that an authorized system continues to meet evolving security goals to retain an authorized status. The POAM (Plan of Action & Milestone) document provides evidence of the system’s efforts to adhere to these evolving goals.
- Monitor: Continuous monitoring provides programs the ability to stay ahead of evolving risks and tailor the system to meet changing security requirements, as well as document improvements to the system’s security posture as outline in the POAM. Step 6 provides continual status updates on current system configuration in order to retain authorization to operate status. This means monitoring emerging threats identified by trust-worthy sources, manning a real-time security operations center, and active system monitoring through SIEM or similar technologies. As with security controls, there is no single “correct” method or solution to monitoring; stakeholders and subject matter experts should identify several monitoring tools and processes that meet the requirements of the system, the budget, and the potential impact should that system become compromised.
Using this process, we can implement standard baseline security controls that are effective and unique to the system, determine real-world risk to that system, and evaluate long-term security measures that focus on individual risk factors rather than a homogenized “one-control-fix-all” answer. This approach enables us to remove controls that aren’t effective and replace them with ones that better fit the need of the system without compromising the overall security posture of the system. Most importantly, it allows us to tailor our defensive to our potential risk.