June 21, 2016
Inside cybersecurity circles and in some IT and Policy forums we have been talking about developing a Risk Management Framework, or RMF, for many months. I am happy to announce we are ready to go!
A lot of hard work has gone into the development by Tom Callaci, Chris Spencer and Siggi Eckhardt of the Governance, Risk Management and Compliance Team within the Office of Cybersecurity. They have adapted the National Institute for Standards and Technology guidance to create a UW–Madison focused process and templates that are already in use as a pilot test for the common systems we support for the UW System, the Data Center that houses several large systems and laboratory IT support regulated under the Federal Information Systems Management Act, or FISMA. Jeff Endres is focused on how to adapt the RMF to the Purchase Card Industry systems.
What is the RMF and how does it work? It’s easy to think of the RMF as a series of defined steps where specific activities take place, all building toward a comprehensive view of risk for individual systems and networks. Here is a good picture of how we view the RMF:
Think of the framework as a life cycle layered on top of a Systems Development Life Cycle, or SDLC. Each step of the SDLC informs the RMF which generates an artifact that tells us something specific about the system itself or the risk that will result if the system is placed in our network.
Step 1 starts at the beginning of development – right after someone has that moment where they say “I need a system that does this!” Step 1 is where we determine the System Category which is based largely on the data the system will handle. After all, it is all about the data (shameless plug for Jason Fishbain and the Data Governance process).
Step 2 is where we determine which Security Controls Selection happens. At this step we determine how much security is required and help the developers understand what has to be built in to the system and what can be inherited from the environment it operates in.
Step 3 is the toughest part since here’s where the selected Security Controls are “baked in” to the system. Lots of good ideas are flowing at this point and the focus on data takes on special context since the system has to be functional as well as secure to move on to the next step.
Step 4 is where the Office of Cybersecurity or the local IT Security staff will assess the controls against specific points on a Security Controls Matrix and determine how well the controls protect the data. The Office of Cybersecurity has developed tools and artifacts that will help move the process along to produce a Risk Assessment Report. This report is reviewed by the assessment team and the developers before it move to the next step.
Step 5 is where the risk of operating the system is made formal. A review of the package and test results is performed and a formal Risk Assessment for Operations letter is produced. The letter, in the world that is perfectly round, would say “…the risk to operations and data is Low”, then recommend the responsible UW–Madison executive approve the system to operate. Since the earth is an oblate spheroid (flattened at the poles), the most likely outcome is “…the risk is Moderate (or High) but can be mitigated with additional controls applied (or corrected).” At this point the executive will make the call whether the risk is worth it.
The last step (Step 6 – Monitor and Mitigate) is to place the system in operation and continuously monitor the security controls using periodic inspection or tools that monitor and report security controls behavior. If the first five steps were effective, the system will operate the rest of its life in a known risk posture. Everyone is happy and the data is protected!
Again with that oblate spheroid thing – systems will evolve and environments will change so we will need to be flexible if Step 6 reveals vulnerabilities that cannot be addressed or if the system requires upgrades that change the original application of the security controls. It could be a simple as revisiting the control at Step 3 and checking the security control with a rapid return to Step 6. Or, it could mean the system owner needs to take a closer look at Step 2 and revise the system’s architecture and reassess in Step 4. Either way, the Office of Cybersecurity will assist and ensure the data is protected and the right levels of availability, integrity and confidentiality are available.
This is a culture change that requires communication at every step. There are ways to shorten the cycle as long as we communicate openly and provide or accept feedback openly. There is no secret in the fact that our systems are important and contain information that needs to be protected. At the same time, there are countless threats to systems and data that push us to create more secure systems.
The RMF is one part of the UW–Madison Cybersecurity Strategy that is focused on preventing bad things from happening to your data! The Office of Cybersecurity is committed to you and your systems being as secure as they need to be. Our vision statement says it best:
Embodying the Wisconsin Idea, we embrace the revolution of cybersecurity in higher education, becoming a leading provider of cybersecurity services to the university community. Our work should make a noticeable impact in securing important information and research data to the benefit of Wisconsin communities and beyond.
With that said, how about taking a moment to give me your feedback. Simple rules – be nice, be fair and be honest. Please e-mail your thoughts to security@wisc.edu and we will periodically post them with helpful answers.