@meparlez wrote:
Does anyone have any good experiences to share where you were successful at breaking down the Categorization step of the 800-37 RMF (step 1)? Or any advice on ways of explaining it in layman's terms?
Francisco,
A team I was on worked this very problem just over a year ago at a U.S. government department. Our team concluded that doing categorization "right" requires a multi-discipline team, and commitment from organization leadership that will ensure the needed people actually take part in the process.
Although aimed at government systems, I believe our lessons learned can be applied in other enterprises.
We used a core team of internal experts and external consultants (I was one of the consultants) to set up the process, then members of that core team led selected stakeholders for each system under review to carry out the categorization process.
First, you need to use not only SP 800-37, but also SP 800-60, Vols 1 & 2, Guide for Mapping Types of Information and Information Systems to Security Categories. In 800-60 you find usable definitions with amplifying discussions of each of the impact levels (Low, Moderate, High), that the stakeholder team will apply. SP 800-60 also provides an extensive set of information types to consider as you analyze each system.
Next, for each system under review, you need to identify the relevant stakeholders, and get both them and their bosses to commit to taking part in the process. That commitment must include taking part in at least two, possibly three, live meetings to walk through the actual categorization process. The stakeholders group should include at a minimum, the system owner (responsible for maintaining and funding the system), data owners (those with authority to define the data types), representative system users, and, if possible 2nd tier users, that is users of linked systems that pull data from or send data to the system under review.
We learned from a pilot study that the stakeholder team will need Just-In-Time training on the reasons and requirements for the RMF process (keep it short and focus on mandated approvals and funding impacts), the nature of the Confidentiality-Integrity-Availability (C-I-A) triad, and the meaning of each of the three impact levels (L/M/H). We developed worksheets, shared with the stakeholder team in advance, to walk through the process. We also learned that asking the stakeholders to independently complete the worksheet forms was not effective; we needed the real time live interaction of the stakeholders with the meeting moderators from the core team to really get the questions answered.
The master worksheet listed the complete set of information types from SP 800-60. Prior to tackling a specific system, the core team worked with an expert on the system to identify only the ones in that list likely to be in the system, but we left the full list visible. At the first meeting with the complete stakeholder team we reviewed the need for categorization, the nature of C-I-A, and the specific definitions for each of the three impact levels. We also described the two-dimensional use of the High Water Mark principal, in that it is used first within each security goal and only at the end might it be rolled up into a single value for the system.
We then walked the stakeholder team through the information types, having them confirm whether each likely type was present in the system, then applying the impact levels for each security goal to that information type. We intentionally did NOT ask them what the impact level as at this point. Doing so is guaranteed to give you "gut-feel" impact levels instead of defensible values based on the definitions.
Instead, the prompting questions were as follows:
Confidentiality: What would be the result if someone not authorized to see this data got to the information?
Integrity: What would be the result if authorized users got this data from the system but the data was not accurate?
Availability: What would be the result if authorized system users could not get to the information when they needed it?
Only after obtaining the potential results statements did we match those statements against the three impact level definitions and descriptions. We completed the results to impact level step immediately after the team confirmed the results statements in each case.
As we completed the table we recorded both the results summary and impact level justification based on the definitions for C, I, and A, on each data type. This gave us a fully auditable record of exactly how the system category was obtained. To save time, we implemented part of the high water mark principal in that once a security goal was shown with impact High, we no longer asked about that goal in the later data types. For completeness, it would be nice to have all three done for every data type, but your stakeholder team has been puled away from their primary jobs for this effort, and you want to get them back to their main jobs as quickly as possible..
The meetings do not have to be face-to-face, but must be real time together, not asynchronous. We repeatedly saw stakeholders bring up new, relevant information as they heard others in the meeting describe the results of loss of C, I, or A. Simple voice-only teleconference can work, but much better is to have shared screen view, with one of the moderators acting as scribe, marking up the worksheet for all to view. This includes recording the results statements and the impact justification statements as the work proceeds.
Finally, we resisted allowing the final High Water Mark step of rolling the three goals into a single system impact level. That is because in later stages of the RMF process, understanding how much protection is needed for confidentiality, integrity, and availability is necessary will drive the selection of controls to do so. This can be a big impact on overall costs of implementing the controls.
Biggest concern: buy-in by both the stakeholders and their bosses is absolutely essential. Otherwise, they will not take the time to go through this process, and will instead try to pencil whip the answers.
Secondary is that some system owners will try to push a HIGH impact level just to support how "important" their jobs are, but in the process cause significant unneeded expense in implementing overly restrictive security controls.
(c) 2019 D. Cragin Shelton
The above essay can also be found on my blog at
https://cragins.blogspot.com/2019/05/system-security-categorization-under.html
