Since the transition to RMF these documents have been … well, pretty bad. I have gotten to the point where I flat out do not expect them to be submitted as part of the body of evidence (BOE). Which is sad, because how do you manage Risk as part of the Risk Management Framework, if you do not assess what risk there is in operating the information system? In the occasions when they have been submitted, I ignore them. I have yet to see, not even a decent RAR, but one that is worth printing on a piece of paper. So, if you’ve taken the time to write one; I’m not even going to pretend that I’m sorry.
What exactly are we talking about?
Just to be clear, I am talking about Tier 3 Risk Assessments. If you are a Cyber Security practitioner and still do not understand the idea of Tier 1 – 3 as part of the RMF process, shame on you. Tier 1 relates to the greater Organizational Level. Tier 2 is the Mission or Business process level. Tier 3 is the Information System. Each tier supports the one above it in order for the Organization to execute their mission. This is a critical distinction to understand. In other words, the RAR for the information system itself.
Why are they so bad?
Why am I saying directly that RARs as a whole are terrible? What makes them so bad? How can you write a RAR that is worth the time and effort for you to write and your DAO to read? That’s easy. RARs submitted are so generic; have little to nothing to do with the information system, they bring nothing to the discussion.
RARs are still stuck in I would say the JAFAN mentality of risk, but it is older than that. It dates back to the rainbow series. The risk that I have to worry about are natural disasters (earthquakes), users messing something up (intentionally as a hacker or unintentionally, as George accidentally deleting his PowerPoint), or environmental (a fire causing the sprinkler system to go off and fry a rack of servers). Sounds familiar.
It is the lack of specificity as it applies to the information system is what makes them so useless. Especially, when we ask why do we take the time to assess the risk to the system.
Why do we do what we do?
If you are about to say that the RMF, the JSIG, the 800-53, the CNSS 1253, a matchbook you found in the bathroom at the airport requires us to have one. Please don’t. Because the book says I need one is not the right answer. I will go so far as to say that is hardly ever the right answer. I know that this blog is even called “It Depends”, but this is not the answer or reason that we conduct a risk assessment.
I have often said that you should get benefit from every requirement in the JSIG. RA-3 is no different. I will go so far as to put it this way. If the RAR that you develop is a paper drill that you do not use, you are doing it wrong. I know that it seems like I am harping on this and there is a point. You see, one of the reasons we conduct a risk assessment is for the AO/DAO. I should be getting some benefit out of the RAR that you write and submit with your Body of Evidence. So, this is kind of all about me.
Risky Business
Before we go too much farther let’s first talk about Risk.
Assessing risk requires the careful analysis of threat and vulnerability information to determine the extent to which circumstances or events could adversely impact an organization and the likelihood that such circumstances or events will occur.
NIST 800-30
So, we need to identify a vulnerability in our system or vulnerabilities in our system as the case were. Determine if there is a threat to exploit it. Then we figure out the likelihood that could happen. This is going to seem like a strange place to go for information. We need to start with the Security Controls Traceability Matrix (SCTM). The SCTM captures all of the controls that we have implemented, but also the controls that we are not going to implement (Tailor Out) and the controls that we need time to implement (Planned).
If there is a control that we are going to implement, but have not gotten to because of reasons, we may have a risk to the information system. If we have done a good job on writing our SCTM they are even easy to find and pull out of the document. We just filter our SCTM on the Implementation column and only select the controls marked Planned. Yes, this is a large part of the reason your BOE gets rejected if you submit an SCTM that is in PDF or Word format. Leave it in the native Excel. Make life easier on everyone.
Let’s take an easy control to think this through and make it a little bit absurd. SA-22 deals with the usage of unsupported hardware and software. For the purposes of this discussion let’s say that SA-22 is planned for compliance because our system has Microsoft Office 2013 installed. It is on the POA&M, but due to the license costs involved we are planning on it taking 6 months to purchase licenses and install. An easy risk to capture in our RAR is that there are unpatched security vulnerabilities that a malicious user could take advantage of; a well-crafted Word 2013 file could contain an exploit that grants the user elevated privileges.
Before you start saying that there is no threat to this vulnerability because your network is isolated; not connected to the internet or anything else. You have media coming on and off it. Security patches and anti-virus updates, templates and documents from your Corporate network or your SCA. We know your SCA can’t be trusted. Over the years we have found that we are not as isolated as we think we are.
Another all time favorite of mine is SI-8 SPAM Protection. If we are going to tailor out this control, is this a vulnerability that can be exploited. It depends. If we are discussing a Classified system with no external connectivity to the internet, I would wager that I have bigger concerns if I get a Viagra ad in my e-mail, right?
Now these are pretty obvious and easy. Let’s take one that is not quite as straight forward. What if our information system does not meet all of the requirements of AU-2. That may not be a vulnerability as we are used to thinking about it. What potential risk do we have if we are not able to capture all of the audit data as required by the JSIG? Put another way, when there is an incident (notice when, not if) what is the impact to the Organization if the system does not have full auditing capability when the security incident is investigated. The likelihood of occurrence can be estimated based on the records of previous security incidents. Even a rudimentary analysis, looking at the number of previous incidents a year, graph them out for as long as you have the data. You should be able to see the trend (up or down), and guess as to how many you will have over the year or three year period.
Digression
Don’t tell me I’ve just blown your mind with using security incident information from your CPSO/PSO/GSSO to inform Cyber Security decisions. Even if I have, don’t tell me. Take credit for that one yourself. This is just information, metrics, whatever you want to call it. If you collect information in any manner, collect it in a way that you can make use of it. Just imagine how something as simple as a graph of the number of incidents a year could be used. It could be a tool to show the effectiveness of your security program. But I digress. We were talking about RARs.
Back to our Regularly Scheduled Programming
Section 2.4.3 of the NIST 800-30 gives examples of how the RAR can be used at about step of the RMF process. We’re going to look at two very specific times or ways to use the RAR.
You’ve built your SCTM and captured all of the controls that you are planning on implementing. You’ve even gone so far as to draft a Plan of Actions & Milestones (POA&M) for your Program Manager. I say draft a POA&M, because she is the one that is ultimately responsible for it and supposed to be the one that submits it the DAO. The RAR can be used by the PM to help them prioritize POA&M items. Cost is a factor on the POA&M, but the Risk to the system is also part of the conversation. This idea is a little abstract, so let’s flip it.
The RAR is loaded with information; information about the system, it’s vulnerabilities and risks. That’s assuming that it is worth the paper it’s printed on. Use the information about the vulnerabilities and risks when you have discussions with your PM. Maybe you are trying to get funding for an audit reduction tool, because your current audit solution does not meet the requirements of AU-2. Make the vulnerability and risk part of the discussion. Use the information from the RAR to put it in perspective for your PM. What are the vulnerabilities associated with running an incredibly old version of Microsoft Office? Bring that into the discussion. Now that you have a RAR that is specific to your system; that identifies specific vulnerabilities you have justification and supporting evidence for these discussions with your PM.
It’s All About Me
I know I’ve said numerous times that every requirement in the JSIG you should get some benefit from meeting it. You are also probably wondering why I chose RARs as a topic to pontificate on, so early in the process. There are a lot of different topics that I could have chosen. The question that you need to ask yourself isn’t if you feel lucky. But do you? The question is what benefit do I, your potential DAO or whomever your actual DAO may be, get out of you submitting a specific and well completed RAR?
Let’s go back to the NIST 800-30. Some places that your DAO cares about vulnerabilities in the system are found in Steps 2, 3, 4, 5, and 6. Crazy huh? When your DAO is reviewing your SCTM and you have controls that are identified as anything other than Implemented. This is Planned, Partial, or Tailored for those of you playing the home game. When your DAO issues you an ATO they are saying that the system as currently configured poses an acceptable level of risk to the mission, organization, or that it provides an adequate level of protection for the information processed. Having a document to reference what the risk associated with those controls that are not fully Implemented is an important aspect of that risk decision. In this case, we are kind of blending Steps 2 and 5 together. Controls are identified and selected in Step 2, but the authorization decision is actually made in Step 5.
During Step 6 when the information system is being monitored the RAR can impact the execution of the POA&M with prioritization of tasks. It can also be used when the annual ConMon report is submitted to your DAO. Hopefully, your POA&M shows that items have been closed out. Hopefully, your ConMon actions have shown that the selected controls and the way they have been implemented are still effective. Hopefully, the RAR has been kept up to date so that it reflects the current posture of the information system. I’ll quote the great American philosopher:
It’s not about you –
Dr, Phil McGraw
RARs are tough. There are a ton of different ways to conduct them. A litany of different assessment methodologies. Hopefully, this has at least given you a way to approach your RAR so that it is useful. Useful not only for you, but for me.
It Depends 