How do We keep screwing this up?
Here’s the thing. Regardless of what ATO methodology you are trying to execute. I say it that way based upon a webinar I sat through recently. Folks are trying to repackage the RMF process with different names thinking they are solving problems in a novel approach to make a buck. Regardless of what ATO methodology you are trying to execute, there comes to a point where you hit big ol’ Step 6, Monitoring. We’re all bad at it.
As a DAO, I’ll be the first to admit that I’m terrible at it. Most of the time it’s difficult for me to keep up with the POA&Ms that I am sent every quarter. Let alone review the Continuous Monitoring (ConMon) reports that have been sent and decide if the system should continue to operate as part of a Continuous Authorization. For the past however many years, I’ve signed out 25 ATOs a year. Like clockwork. One year it was 24, but the next it was 26. You get the idea. So… every other week an ATO with my signature on it leaves my inbox. Rightly or wrongly, we do not have a good mechanism to manage the BOEs that are submitted to us like an eMASS or Xacta. <TANGENT> Not the time or place for that discussion. We had one many years ago, it went the way of the dodo for numerous reasons. </TANGENT>
To be completely honest, I do not know how long it would take to review the annual ConMon report because I’ve never gotten one to review. Point I’m trying to make here is that both of us have failed in our responsibilities regarding ConMon. I’ve said from the start that we would look at things that everyone has problems with. I think this qualifies.
Let’s take our first lens of Cybersecurity and ask ourselves this question. Why do we do ConMon? If you’re thinking, because we have to. There’s a Step in the RMF for it. I have to do it to keep my ATO.
Amazing, every word of what you just said… was wrong.
Luke Skywalker, Jedi Master
You should know better by now. “Because the book says…” is not the right answer. It doesn’t even qualify for an “It Depends”. ConMon is that part of the RMF that is supposed to correct a long held deficiency in Cybersecurity. Stop me if you’ve heard this one before. Once an ATO is issued, the body of evidence goes into a safe drawer and isn’t looked at for 3 years when the next ATO is needed. That’s why we do ConMon. To make sure things are still what we think they are. It forces us to take a step back and evaluate whether what we were doing is still the best way to do it. We do ConMon because life happens.
So, let’s take a very broad brush and define ConMon. The idea is that periodically, the ISSO or ISSM (you) would go the controls assigned to your system (SCTM) and verify and validate two things. One, that they were still appropriate for your system. Two, that the way they were implemented was still appropriate.
What’chu talkin’ ’bout, Willis?
Arnold Jackson
These sound kind of the same, so let me give you an example or three. Let’s say you have a network and there are 10 users on the network. Really small. Your account creation process could be pretty informal. You send an e-mail to the PSO asking them to verify that George has the appropriate clearance. You forward their response to the PM and ask what User Groups they should be in. Finally, you forward that e-mail to the SysAdmin to make the account. When the account is made you print or save that e-mail as evidence of the actions involved and go on with life. Nothing fancy or formal, but it does meet the requirements.
As life goes on, your network expands from 10 users to 15, to 20, to 25. Life has been good. Now that you have 25 users on the network. At some point, are you (or someone) going back and verifying that your policies and procedures still make sense or are appropriate for your environment. In this case, I would argue that the existing informal procedures are not sufficient. Time to add some rigor to it. Maybe add an account creation form to keep track of everything, or document it in a consistent manner. That is an example of verifying that the way you implement a control is still appropriate for your system.
Here’s the flip side to consider. When it comes to patching. Does anyone look at the time it takes to execute your patch management process from start to finish and look at the number of days on average it takes to execute? Is there a step in the process that slows the whole things down? Is there a place that the process can be changed to make it better?
Move along. Move along
Stormtrooper
One last example of ConMon to think about. When was the last time you went and looked for updated or new policies that need to be executed? I’m not just talking about a new revision of the JSIG or NIST 800-53, they are coming, by the way. Maybe a new Chairman of the Joint Chief’s directive. Guidance Memo from your AO function. Update to an OMB circular. Company IT policy. Something from someone that can impact your life, regarding your information system. Unfortunately, that’s also part of ConMon. the The -1s are controls too and we have to verify that we are still applying them correctly.
One thing that is missing from these examples is re-running STIG/SCAP checks on your systems. That’s for good reasons. Mainly, my thoughts on DISA STIGs. The settings that they propose are not always in line with the JSIG, which is the policy we are executing. I’m not going to jump down that rabbit hole right now. Re-running a set of STIGs against your system should be the easiest part of your day. It has to be the easiest part of ConMon. We’re not here for easy.
If we look at these three examples, we have: What’s Changed, What can be Better, and What’s New.
Here’s the worst part. We haven’t even gotten to the part where we talked about why ConMon is difficult. I worked with a guy back in the late 1900’s (doesn’t that sound like a really long ago (well, it pretty much was at this point)). He said something kind of off the cuff, but it stuck with me. It was something along the lines of “Everyone loves it when that magician is on stage and pulls the rabbit out of his hat. No one understands the work it takes to cram the rabbit into the hat to start with. That’s what we’re doing; shoving a rabbit into our hat. So when we are on stage with the lights on us in front of a crowd, we have a magic trick to perform.” Honestly, I’ve long forgotten his name. Heck, I’m sure that’s only a paraphrase of what he even said. The reason I bring it up is because it dovetails into the two lenses that we are looking at Cyber Security through: Why do we do what we do, and We should benefit from every requirement that we meet.
Let’s start with our magic hat. How can we cram those pesky rabbits into our hat so they will be there when we need them? Amazing enough, the answer is simple to say, but tougher to do. We cram the rabbit into our hat in the beginning.
When we started this particular journey together, we said that we would look at our problems with two lenses; Why do we do what we do and You should receive benefit from every requirement you implement. Nothing has changed. Some of you were probably even worried that it took that long for these two statements to come up.
Grab your hat, and let’s find a rabbit. Normally, it’s good to be me. This is one of those times where it’s really good to be you. When you are drafting, updating, writing your procedures; creating the format for your logs; basically figuring out how to manage your IS, do it with ConMon in mind. You own your destiny here.
Who is responsible for setting up how your maintenance log is formatted? I’ll give you a hint, it’s not me. You have the requirements in the JSIG where it lists what has to be in a maintenance log and how long you have to keep it, but the format you use is all up to you. You can keep a green book. That’s an approach. If you go down that path, find a way to make it useful for you. Wow. That sounds strangely familiar. Is it the most useful one. Heck, if you’re even asking yourself this question guess what. You’re doing ConMon.
Let me foot stomp that a touch. If you are taking the time to look at your processes and see if you can do it better. If you are looking to see how you can update your processes to make ConMon reporting easier, you are doing ConMon.
To make your life easier capture the things that you already do, and take credit for them. Has a user ever come up and asked for a file to be restored? That’s a test of your backup system. Take credit for it. That’s assuming that have a way to capture it or that you have a way to easily find it in your log.
If you want to “do” ConMon, you can build it into your processes from the start. Green books, Access databases, Excel spreadsheets. They’re all tools to use at your disposal. When you deploy a new system, do you run the STIG/SCAP tools against it? Probably. Do you keep a record of the initial score? Shove that rabbit into your hat.
Periodically, and I’d say no more than annually. Take a look at your SCTM. Chances are you tailored out some controls because they didn’t apply to your system. Hopefully, your SCTM is in a format that you can easily sort by the Implementation column and see what has been Tailored. Look and see if the reason why those controls were tailored out still applies.
We’ve said before that you should benefit from every control that you implement, right? That is the same under ConMon. When you are doing ConMon you should stand to gain something. Take a look at the work that you do; the number of systems that you ISSO. I get it. Most folks are not dedicated to a system. You may only have a day or half day a week to spend on any single system. Is that enough time to do the work that you need to?
Look at the work you have to and the resources you have to do it with, PM-3. Don’t just sit in a corner and wallow in despair. Talk with your PM. If they’re not helpful, engage your AO function. If your PM tries to get resources and isn’t successful. Engage your AO. They need to at least be aware. They may also be able to help you out.
Come on, Mav, do some of that pilot sh*t!
Goose
If you’re looking for help on things to track and how to track them. Lower your expectations before you take a look at PM-6, Information Security Measures of Performance, and the NIST SP 800-55. The 800-55 and this control text was likely written by a CIO. Meaning… they’re both pretty useless. They are compliance focused (number of users who committed their annual training, that’s the best that we can come up with) and contain few examples of things that actually effect Cybersecurity or make your life better.
Like always. If you have questions, comments, or snide remarks let me know.
It Depends 