When you hear the word audit and consider how it pertains to your security strategy, most organizations think of auditing as something you do once a year or when a problem arises. But just how should auditing be an integral part of your security strategy? In fact, for most security plans, auditing is a critical missing piece – one that’s needed throughout the security lifecycle to make your life easier both when you’re audited and even when you’re not.
Where Does Auditing Fit In?
In order to figure out where auditing should play a part in your security strategy, let’s start by defining what should be audited as part of a security plan. To do this, look first at how security is implemented in its most simple form and work backwards to auditing’s role in your strategy.
Security can be viewed in three simple steps – assess, assign, audit. (Now, don’t jump ahead thinking “ok, ok – so the audit part is at the end.” As you’ll see, auditing will play a part every step of the way.)
As you think about the three steps, the first thing you do as part of implementing your security strategy is to assess the current state of security: What permissions are in place? Who has elevated rights? Who is able to access the resources in question? And so on. Once you complete your assessment, you need to make some new security assignments – additions, deletions, and modifications – to ensure the system is properly locked down. Lastly, you audit the usage of the environment being secured to make sure you’ve properly implemented the security.
If you see something out of place – for example, a user that shouldn’t be utilizing a resource or system – you’ll go back and start the process again by assessing what rights are in place in order to determine how they gained access, followed by an assignment that fixes the issue, and then another audit of use to ensure the security is now correct.
So, Assess. Assign. Audit. (repeat) Got it? Good.
What Should You Audit?
Based on where you are in the process, you’ll be auditing different aspects of your security. Like the three steps, break down what you need to audit into three simple groups:
· The State of Your Security – The assessment step requires an understanding of more than just who has permissions to a critical system or resource. To truly have a handle on the state of your security, it requires visibility into who currently has rights to manipulate those permissions, as well as who had permissions or administrative rights historically. Think about this all too common scenario for a moment – someone who previously had permissions to sensitive data gave another user rights to access that data. Once accessed, the permissions were removed. If all you audit is today’s permissions and administrative rights, you will never know the true state of your security.
This is a tough one to address. It’s easy enough to pull the current state of security – you could even use the default administrative tools for the resource in question and take screenshots of the current security settings (not that this is an advocated methodology – this is simply to point out that there is no excuse for not auditing the current state of security). It’s the historical security that is going to be a problem. Without a solution in place that takes some kind of snapshots or backups of your security, you’re going to miss out on states of security in between your audits.
· The Changes You Do and Don’t Know About – The assignment step requires it’s own auditing as well. The example above demonstrates that auditing the changes made to your most critical systems is crucial to maintaining your security strategy. (We’d all like to think we know about every change, but even you have made changes in the past week that no one else in your IT department knows about, right?) You need to audit every change made not only to the resources you want to protect, but to the systems that provide access to those resources. As an example, you would want to audit changes to a payroll database, but also changes to your Directory Service, whose groupings of user accounts provide access to the database in the first place. And if you really want to get detailed, you’d be auditing the changes to any group that has access to modify the membership of the group with access to the database. And so on and so on…
While auditing the state of your security is somewhat an ex post facto activity, auditing changes should be an ongoing exercise. This means, at a minimum, you should be looking at security logs that identify changes. Event Log Management (ELM) and Security Information Event Management (SIEM) solutions that can notify you of changes can help here. If you’re more serious, utilizing solutions focused on auditing changes is a better choice.
· Access to Your Most Critical Systems and Data – This was the most obvious of the three, probably because the step is named auditing in the first place. Remember, here your focus is to audit the use of the permissions – who is accessing patient records, who is copying files from a server to a USB stick, who is reading or writing to your customer database. In the spirit of the three security steps, this would be done to identify use cases where the security you thought you implemented doesn’t match up with the use you’re seeing. Auditing access is both a reactive and proactive activity. The proactive part detects points where you’ll restart the assess, assign, audit process looking for how someone got improper permissions. The reactive part identifies potential security breaches that may have already occurred. So it’s important to make this as real-time as is possible so you can either react to breaches or quickly lock down a gap in your security.
Many systems provide logging of access, allowing you to utilize the same ELM and SIEM solutions. The challenge will be consolidating seemingly related log entries into intelligent individual actions. Depending on the logs you’re using, a single activity can constitute a number of log entries larger than one. Solutions focused on auditing access also exist and may provide the intelligent parsing of log data required to make this part of your auditing plan more productive and effective.
So, Does It?
Now that we’ve spent some time labeling parts of your security strategy that require auditing and defining the auditing that needs to take place, the question needs to be asked once again.
Does Auditing have a Role In Your Security Strategy?
Using the definitions above, your answer is likely, “No.”
Remember, security isn’t static – it’s ever changing by, potentially, a lot of people in your organization. There is a lot to security that requires on-going auditing to ensure you have a handle, no matter what is changing and by whom. By taking advantage of auditing as a central part of your security strategy, you’ll more easily be able to tell if you’re truly secure.