Logs

This bit more esoteric a topic than what we’ve talked about in the past, but our two lenses ring true on this topic more than most. “Why do we do what we do” and “You should receive a benefit from every requirement in the JSIG” for those of you just joining us. Let’s pick a couple of logs to talk about today with those two lenses in mind. The requirements are pretty straight forward, cut and dried.

Maintenance Logs

MA-2 is about as wide a control as you can get.

Includes date and time of maintenance, name of the individual performing the maintenance, name of escort (if necessary), a description of the type of maintenance performed, and a list of equipment removed or replaced (including identification numbers, if applicable) in organizational maintenance records.

JSIG MA-2.f

Date/Time, Who, Description, Escort (If necessary), and replaced parts. Since we’re talking about the JSIG, we should add in the retention requirements. Life of the System plus one year after decommissioning. It doesn’t get any easier than that. So, what is there to talk about. First off, there are a metric ton of different ways to setup a maintenance log that all meet this requirement. I bet we could discuss 100 and still come up with 100 more if we though about it.

Let’s go back to our two lenses. The JSIG talks about how vulnerable systems are during maintenance. Especially, if uncleared folks are the ones doing the maintenance. Hence the requirement includes the escort. Really, though. Think this one through. If you are bringing someone from the outside to replace a part or fix something that you can not do in house, is having an escort going to make a difference? I mean, if the escort was knowledgeable enough to know what the uncleared technician is doing, then why aren’t they doing it? Sure, you could go back to invalidating warranties and what not, but really?

Don’t fool ourselves. You’re not going to attempt to rebuild a system and use the maintenance log to inflict all of the changes on the newly restored system after the last backup or patch or whatever. I’ve seen your maintenance log. One, you can barely read the chicken scratch, short handed notes and abbreviations that are in it. Two, you’re going to have to prove that you can.

I’m not going to say that either of these reasons of why are wrong. They’re not, but don’t try and convince me that is what you are trying to do <insert McKayla Maroney face>. Let’s shoot for some things that are achievable.

There is an old IT adage that 20% of our systems cause 80% of our problems. If only we had a way to identify those 20% troublemakers. Maybe these are the ones that we replace if we get some end of year funds or if our PM has allocated some budget to upgrade our IT. Where should we start? I’d look here.

Maybe you are able to bring another SysAdmin on board. It might be nice to look at where your system has the most problems and bring in a person with experience in that? I’m not saying that you don’t already know what talents and experience you’d like your new person to have. What I’m saying is that you can back up that desire with data when you are talking to your PM. Along the same line, but closer to home, maybe you can expose some places where you need training. Maybe a place to look for a new automated tool to implement. One of the things that we look for on inspections is how your disparate Cybersecurity policies and procedures interact and support the other. Configuration Management and Maintenance go hand in hand. Heck, you could even use it as fodder for your end of year review. You get the idea.

Regardless of how you want to use your maintenance log, it has to be structured in a way that you can use it. Does a Green Log Book meet the requirements, assuming it has the appropriate detail in MA-2.f, sure? Is it useful? Probably not. It’s going to sit in someone’s desk or next to a PC and the “Why do we do what we do” is because we have to.

Maybe in order to make your maintenance log useful for you, you have to collect more information than just the couple of things above. That’s cool. Just be careful that you don’t make an administrative burden on yourself. Don’t make life harder than it needs to be. Don’t collect information that you won’t use; that’s busy work and a waste of time. When it comes inspection time, you know your SCA is going to see that you have not been collecting the information that you said you would. Here’s the great thing. You have a Continuous Monitoring plan. Periodically, you should be reviewing your maintenance log and what you capture in it. Make sure it is still appropriate for your system. Crazy I know.

Audit Review Log

The weekly audit review is the bane of our existence. I’ve been doing this a long time. We have never caught a spy with a weekly audit review. Closest we’ve come is an ISSO discovered a huge spike in number of pages printed after hours. The insuring investigation found a user that was preparing for a Congressional Briefing. Congress likes the hard copy. Everything was above board. Fantastic catch, though. I wholeheartedly applaud their efforts.

These reviews shall be documented in either an electronic or manual log.

JSIG AU-6

The audit review log is even more nebulous than the maintenance log, as far as what it should capture. I’d like to take a moment and thank the JSIG for providing such clear and concise guidance on the weekly audit review. Before you start laughing. That quote is from the amplifying guidance in the JSIG for AU-6. The NIST 800-53 and CNSSI 1253 have even less information than that. Here is the beauty in such a statement. You have the freedom to make your audit review log, whatever you need it to be.

Your SCAs, your DAOs, your inspectors are not stupid people. When we see an MS Excel with nothing but dates and initials followed by NSTR (Nothing Significant To Report) you’re not fooling anyone. We’re going to ask you what you look for when you review the audit logs, you’ll say something dumb like users logging in at odd hours. We’ll pull open a pair of log entries from the last three weeks and see that your system clock has been off by 12 hours and you never noticed folks logging in at 6:00PM and thought it odd. No. Never happened. During an inspection. Oh, and this one time, at Inspector Camp, I went into eight different spaces and found eight different ISSOs with eight different examples just like that.

What I’m trying to say, is that if you are trying to show that you have been performing a review of your audits every week for the last 18 months or so, then put the detail in to show that. If you want to get something useful out of your weekly audit review, read on further.

The reason we have a weekly audit review log (besides we’re supposed to), is so that we have a singular place to see a pattern of behavior in our network or system activity. Humans are great at spotting patterns. That’s why the Department of Defense spends so much on camouflage; break up those patterns that make it easier to spot soldiers and equipment. If I were going to setup an audit review log, I would do the same thing. Capture enough data to get an idea of what normal looks like: number of pages printed, number of accounts locked out, or created, number of file access errors. Depending on your system and were it is at in the lifecycle the things you want to look at are different. Deploy a new SharePoint, maybe you look at SharePoint logins and Fileshare usage for a little bit. Have a system that no one uses, maybe it’s just as simple as number of users besides you who log in and what user group they are in. It doesn’t matter, try to define normal for your system.

Quick side note. Don’t just take the e-mailed reports from pick a tool and consider that your audit review log. Getting an e-mail is not evidence of your weekly audit review. Regardless of how you are reviewing the logs, you have to have some evidence that you did something with it; something that shows you actually reviewed the logs. It’s way to easy to get caught with your pants down. You know I’m going to take a look at the last month of two of those reports and you’ll get embarrassed real quick.

Back to our regularly scheduled programming.

So, how can you use your weekly audit review log? First off, you can do something with it. If you see George (no offense to George’s everywhere) do something that is captured in the audit logs, stop by and talk to George. Don’t send George and cold and heartless e-mail, stop by his desk or give him a call on the VTC. “Hey, I was reviewing the audit logs this week and saw you had a lot trouble logging in. Is everything OK with your system?” Yes, this takes time. Yes, it might not always be possible. When there isn’t a pandemic going on; take advantage of the opportunities you are given to have these personal interactions with your users.

For too long, Information Assurance, Computer Security, Cyber Security, whatever we are called this week, were viewed as the guys and gals that sit in a dark office and management threw us a Snickers bar occasionally. If you take the time to build the relationship with your user base, George is going to be more likely to come to you when he sees something hinky going on.

We are all stuck going through annual training (AT-2 for those of you playing the home game). Due to the permutations of the calendar, I took the Cyber Awareness challenge three times in the same calendar year. I feel your pain. Jeff, you need a new sweater vest. Next time, try this. When you get your two slides to brief, take the top 3 or 4 trends that you’ve seen during your audit review. Brief them. “This past year when I have been reviewing the audit logs, these are the top three things that I’ve seen.” Or “Historically, at this time of year, we see these types of issues…” Imagine what a shock it would be to see annual training that actually corresponded to the system that your users use.

The best part, though. This reinforces the idea with everyone that you are reviewing the logs and watch everything that they do. Obviously, don’t pick on or identify folks by name. That’s not cool. Use your weekly audit review to give you the fuel you need for your two or three slides every year. Bye, Tina.

Regardless of the type of log that we are talking about and however you choose to keep it. Take the time up front and structure it in a way that makes the information useful to you. If the log and the information it contains is not useful, then why are you doing it? If you have discovered that the way you are keeping your logs is not useful, great. Fix it. Execute your Continuous Monitoring process and make the change. I mean, that is what Continuous Monitoring is for, right?