Both security and compliance are all about establishing (and implementing) standards that ensure an environment where company assets and data is accessed and utilized properly. So if you were asked, “Do you think security and compliance really coexist?” you’d most likely think it a dumb question and say, “Of course.”

But what if we challenge that notion a bit -- not so much to explore if they can coexist, but whether they do.

Security is about access -- whether you can get to systems and data. Compliance is about behavior -- what you do with it once you get there. So to truly see security and compliance coexist, you need a way to tie the two together to get a full picture of what kind of access is available and who utilized that access.

For the purposes of this article, let’s focus on the access each IT person has and the work being done within critical systems to establish and maintain a secure environment. But let’s do so from the perspective of a compliance audit. Here there is a distinct secret to bridging the gap between security and compliance and some critical changes every organization should audit.

The Secret

It’s not until an actual audit that it becomes evident that security and compliance are not aligned. Why? Because of one simple issue -- documentation. During an audit, security pros are asked for proof that security has been maintained in a known state -- where a security pro is aware of the state of security at any given point in time. Without knowing who was given access, it’s pretty tough to tell whether the folks with access behaved themselves. And access can change quickly -- someone can have access to a resource today and have it removed tomorrow.

Take the reasonable auditor question of, “Who has been a member of the Domain Admins group within the last year?” (You can, of course, insert your own administrative group if you’re not using Active Directory.) It’s a reasonable question -- the auditor simply wants to know who has had access to make critical changes to security, affecting access to sensitive data. It’s at this point that the security pro realizes they haven’t documented every change made to this group and have no reasonable way to come up with an answer to the question, thus failing at least that part of the audit.

So the secret is simply documentation. As long as the configuration of and changes to security are documented, security aligns with compliance. Now the hard part – how do you document every change? Without third party solutions, it’s not an easy task, but it is as simple as documenting security changes -- but that does mean every change.

What Changes Should I Be Watching?

Every Change? That’s a daunting task and no IT or security pro really has the time. So let’s try to break down everything to something a little more manageable and look at the changes that will assist in meeting compliance objectives.

  1. Who’s in charge? – Remember, we’re talking about changes so it’s important to have a historical record of who has been added to groups or given direct access that gives someone rights to establish security for the rest of the organization. This includes first and foremost any directory service that serves as the basis for all other security. To properly meet an auditor’s needs, you’re going to need to know exactly who has administrative access and the duration during which each person has that access. Keep in mind this applies to directory services, databases, cloud-based systems -- basically any environment that either houses sensitive data or provides the basis for access to that environment.
  2. What are they doing? – Because we’re focusing on IT, knowing what those in charge are doing with their permissions is equally important. Many systems provide logging so you can see what actions are taken. Specifically, you’ll want to be able to see any change made that impacts security, when it occurred and by whom.
  3. What changed? – This is where the rubber meets the road. Your ability to provide this critical level of detail will determine whether you pass or fail an audit. You might be asking, “Isn’t this the same as the previous requirement?” But there's a difference. We’re talking about knowing what specifically was changed – the before and after values for a given change. Knowing that Fred modified the Database Administrators group membership only satisfies the first two requirements in this list. It’s when you know that Fred added Bob to this group that you can complete the audit detail required.

Let’s move this from an academic discussion to something a little more real world by talking about how possible is this really?

Most systems provide some kind of logging that will provide you some or all of the detail listed above. Given that there will, no doubt, be an overwhelming amount of log data, you’ll need to employ some kind of Event Log Management or SIEM solution at a minimum to consolidate your data into something more manageable. This, however, may only help with the first two of the three requirements listed above if the log data isn’t detailed enough. Ideally, employing a solution specifically focused on auditing changes will allow you to meet all three requirements and make answering your auditor’s questions a simple and efficient task.

Security and Compliance are simply looking at the infrastructure from two different sides of the story -- one looking forward (e.g., “what kind of access should I give Bob?”) and the other looking back (e.g., “Who gave Bob rights?”). It’s the documentation you maintain around the security changes you make that’s going to allow these two practices to live harmoniously. Keep track of those changes and you’ll be ready for an audit, no matter what they ask.