Let’s take a few minutes and discuss something near and dear to all of our hearts. Auditing. If you just cringed like a vampire being tossed a tanning light, you’re not alone. What I’d like to take some time to discuss is how having an audit policy can make your audit review a little less cringe-worthy.
Let me preface our discussion and say that I am not a fan of policy for policy’s sake. I have walked into too many places and seen 300, 400-page Cybersecurity SOPs. Audit policies that are hundreds of pages long. There’s a company called i-assure that capitalizes on this. I’m sure that they are great RMF consultants and deliver great products. This is not what we are looking for. Keep it simple. Keep it short. Remember our lenses, “Why do we do what we do” and “What’s in it for me”. There is no benefit to you (or me) by having a policy that is hundreds of pages long.
I abhor monolithic policies that are more than about 5 pages long. The biggest reason is that I don’t want to read it. (Remember, what’s in this for me) The other is that I’m pretty sure that if your policy is more than 6 pages you aren’t reading it either. You do not need a cover sheet, change page sheet, signature page, and all the other happy horse cr- there’s a lot of stuff that you do not need in your policy template. I know there is someone out there thinking, what does it matter? Here’s where it matters. It’s more pages for you to keep up to date. It’s more pages for you to search through to find what you need when you need it. Keep it simple. Keep it concise.
Have a Policy
First things first. Let’s talk about what you are doing. Seriously, when it comes to your audit policy what is it that you are doing? Let’s put a finer point on this idea. Do you know what you are auditing? Do you know what events you are looking for and why? Remember, the answer “because I have to” isn’t any better than “it’s in the JSIG”. The JSIG has a great list in AU-2 of events that your system should be capable of auditing. Yes. It says capable of auditing. That doesn’t mean that you have to audit all of these items. Coordinate this with your SCA of course. It also doesn’t mean that you need to review a report of all of these items every week.
Determines that the information system is capable of auditing the following events:
JSIG AU-2.a
Over time, the events that organizations believe should be audited may change.
JSIG AU-2(3) Supplemental Guidance
Take a few minutes and write out what is important from an auditing standpoint. Please keep this in mind. Your audit policy should be specific to your information system; write it with your system in mind. What logs are you looking at? What events are you looking for? What is important to your location or on your system? Are unusual logon hours something that is really applicable to you? Does everyone generally come in and depart at the same time? Is your system a WAN that crosses multiple time zones so there really are not any unusual times for users to log in? What’s normal and what’s weird? If you say that you are looking for users logging in when they are out of the office or on leave, how is your auditor receiving THAT information on a reliable basis? Is there a service account that is used by your admins that doesn’t have any way of seeing who actually did the work? Your system may have a robust DAC/RBAC implementation based on user groups. Does membership in all of those groups matter or is there a group or two that matters more than the others? Whatever that ends up being, document it.
The natural follow on to this. It is incumbent upon you to review your audit policy and make sure that because life has happened in your information system you do not need to change the events that you audit. If you find that you do need to make a change, then do some of that ConMon stuff, Mav, and update your audit policy to reflect those changes.
As silly as it sounds, identify what tool or tools you use to review your weekly audits. Maybe another way to think of this policy is your CONOPS for auditing. Just like you should have a CONOPS developed for your system in Step 1 to make all the rest of the Steps easier have an audit policy. Who reviews the audit logs? By role, don’t say George or Jennifer that is just more work to keep the policy up to date. Is there another organization that they have to coordinate with as part of their weekly audit review? When anomalies occur who do they notify? Consider capturing the contact information in an addendum that can be easily and quickly updated without having to staff the policy through fifteen people. When they complete the review, what artifact is created or updated? Again, don’t write War and Peace, KISS.
Know What You Are Doing
This should be pretty simple and self-explanatory, but it is missed all the time. Know what you are doing. If your audit policy says that the Network Auditor is going to use the Audit Master 3000 to review logs. Guess what. You need to make sure that your Network Auditor knows how to use the Audit Master 3000. I would also say that their knowledge should extend past logging in and clicking the Report button. They should have enough knowledge and training in the specific tool to investigate events. Maybe that includes running another query, creating a new report, or even adjusting an existing one. Whatever the particulars are of the audit reduction tool that you utilize. Seriously, though. How effective a weekly audit review can we expect a person to complete if they do not know what they are doing? Not very. We kinda owe it to them to train them.
Know Who You Are Doing It To
A little bit of a broken record if you know me, but we need to know what systems we are auditing. I mean. You know what you are going to audit. I know what you are going to audit. Does your audit reduction tool know what you want to audit? Are you sure and would you like to be sure? This is a case when I miss the days when Cybersecurity was still called Information Assurance. It dovetails nicely into what an instructor said in a class one time. “The only way you get assurance is by testing.” The only way to be assured that your ART is auditing what you think you want it to audit is by testing it. Usually, when we talk about this and auditing I’m telling you to treat your ART like your ex; it will lie to you every chance it gets. You know what I’m saying.
The JSIG tells us how our systems should be capable of auditing; what we have to have Success and Failure set on. Our Audit policy should tell us what we are auditing. Where specifically do we have Object Access Success auditing enabled, for example. What file is so important that we have to know who opened it, maybe even the why behind that decision. After all, that would make it easier for us to periodically review and update our audit policy to make sure it is still relevant. Look at me getting ahead of ourselves. Knowing what we are auditing also makes it possible for us to generate reports and create dashboards so the information that we need to know about regularly is at our fingertips.
You may be asking yourself what this has to do with testing; everything. Just like you should be periodically checking that all of your clients or systems are correctly registered, you should test that your auditing is set up correctly. Object Access Success and Failures. Purposefully try it. Try to access the files and folders that you should and those you should not. First off, did your test work as it should have. Secondly, did you get the results you expected in your audit log? If it were me, I would keep a copy of those tests and results. You now know what the system, alerts, pop-ups, notifications, whatever look like when “X” occurs. Great stuff to help fill out your Privileged User Guide. You can also re-use your tests later as part of your security authorization testing after changes have been made to your system as part of your Configuration Management plan, or part of your Continuous Monitoring. Again, what I would ask you to consider. You do you.
Don’t Go It Alone
Ok. I’ll admit. This is a bit of a stretch to include talking about why you want to have an Audit Reduction Tool when we have been talking about your audit policy. Honestly, though. Auditing stinks. Don’t do it by yourself. Seriously, get an Audit Reduction Tool. The JSIG says the following about an Audit Reduction.
Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. Audit reduction and report generation capabilities do not always emanate from the same information system or from the same organizational entities conducting auditing activities. Audit reduction capability can include, for example, modern data mining techniques with advanced data filters to identify anomalous behavior in audit records. The report generation capability provided by the information system can generate customizable reports. Time ordering of audit records can be a significant issue if the granularity of the timestamp in the record is insufficient.
JSIG AU-7
If your Audit Reduction Tool is a script or four that runs preformatted ausearch commands, I hate to break it to you. You do not have an audit reduction tool. Windows Event Viewer is not an audit reduction tool. Neither of these is “more meaningful” for the poor schmuck reviewing audit logs. (If you happen to be the schmuck stuck reviewing the logs, please know that I mean the term schmuck in the original Gaelic as a term of endearment.) If the tool that you use to help perform your audit analysis does not make your life better, you need a better tool. Information systems are more complex than they have ever been. We have less time in our days than we’ve had before. The adversary and the threats that they pose are more significant than at any other point in time. The good news is that all of this is only going to get worse in the future. That’s why it is important to have an Audit Reduction Tool that supports your audit policy.
We’ve talked before about how the IT system should implement the policy and not vice versa. Here is a case in point. You’ve done all this hard work to identify what you are auditing and why it is important. The tool that you select should support or implement that policy. Don’t chicken out and dumb down your audit policy because your existing tool cannot do everything that you need. Maybe there are some workarounds that you can do until such a time you can look for a new tool.
What should you see in an Audit Reduction Tool? There should be a report generation capability, some kind of a summary. I would expect to see things like alerts to notify you when specific behavior that you care about occurs. If there are multiple components involved, something that can help you build a timeline of what occurred. Take a long look through the supplemental guidance in the JSIG for AU-7 and its enhancements. The point remains. Do not try to audit your systems without some help.
Hopefully, all of this blathering on auditing and how a policy *gasp* can help you have been, well helpful to you. If not, we probably need to talk. If it has been, you probably need to talk with your SCA. Matter of fact, you should talk with your SCA anyways. I’m sure that they have their own opinions on auditing and audit policy that they would love to share with you.
It Depends 