How to Ease the Pain of Cybersecurity Compliance Audits

Organizations of all sizes face several audits every year, whether Payment Card Industry (PCI) audits, SSAE18 Service Organization Control (SOC) audits, Federal Information Security Management Act (FISMA) audits or International Organization for Standardization (ISO) 2700x audits. And many will soon find EU General Data Protection Regulation (GDPR) audits a part of their ongoing reality.

Look, let’s face it: Most cybersecurity compliance audits are not very much fun. Having been on both sides of the auditing table at different times in the past, I can tell you that there are ways to make it go more smoothly than it often does – but it does take some work to get there. Let’s look at some of the things that contribute to an effective compliance audit and how those things map back to your operational processes.

It Begins in the Mind …

Almost all our maladies in life, as well as our successes and accomplishments, begin in the mind. And it is important to be able to see that compliance auditing is not an evil process or activity – simply one that is intended to ensure that things are going as you claim they are. Yes, we have all seen bad compliance practices – those that focus on meeting a checklist without providing real value ­– but we’re here to discuss how it looks when it works.

Start with the understanding that cybersecurity compliance programs are a helpful verification of adherence to policy and technical controls that are meant to reduce or mitigate risk. If we look at things from this perspective, we will begin to see how we can be more prepared for audits.

Compliance Checks

Depending on the requirements your organization is trying to adhere to, there will be a set of control families that stipulate – or provide a framework for – how the organization and its staff need to operate. These controls vary by regulation or standard, but at the heart they cover the following areas:

For all of the above, there are policy controls and technical controls.

A policy that says that passwords should be long, complex and changed at regular intervals can be supported by technology that prevents passwords from being short, too simple or kept for too long between changes.

Not every policy control can have technology enforcement. For example, it is impossible to enforce a policy that says that users cannot use the same password on every system they access, because those systems have no way of verifying what password was used elsewhere.

Documentation

Both policy controls and technology controls should be well documented. This is somewhat inherent with a policy control (though not with technical controls), but even here organizations often miss the mark.

A policy defines what should be happening (or avoided) from a goal, intent or purpose standpoint, and documentation of that is typically not a problem. But how these things are actually accomplished by all relevant parties should be captured in a set of procedures, and that’s often not done.

Back to our password example: If passwords need to have minimum lengths and maximum ages, there are likely four or five ways to accomplish this goal depending on what application or system is being used in an organization. The process for implementing this technical control needs to be clearly documented, such that it can be easily checked.

So, while policy controls define what we say we do, and technical controls outline how we use technology to enforce policy, procedures map out the actual steps that are taken by some party (usually defined by role) that make the technical controls effective.

Review Processes

But wait! There’s more!

Every compliance program should include another element, one that is often overlooked by organizations in the busyness of day-to-day operations.

Operational security must be reviewed periodically. There is no real success in set-it-and-forget-it. This means that the organization needs to have a periodic review process whereby the effectiveness of various policy and technical controls are evaluated. This gives the organization an opportunity to determine if the controls are doing their job or need to be changed in some way. This review also helps prepare an organization for an external audit.

A good review process needs to be performed and documented. If your company has a quarterly process to check that all its administrative users are in the right groups and have the appropriate access to critical systems, that process needs to be tracked and documented – and signed off on by someone.

The documentation should be consistently maintained in whatever system your organization has selected, such as an incident tracking system, your intranet portal, your internal or cloud document management system, etc.

This is one of the biggest failure areas in an audit: things that we say we do, but can’t prove we do, or can only prove inconsistently.

An inconsistent compliance program is worse than no compliance at all. In many ways, it is better to be doing 10 things, and all of them well, than to be able to discuss 25 things that you sorta, mostly, occasionally do … to some degree.

Summing It All Up

Making cybersecurity compliance audits less painful requires that we talk the talk and walk the talk. We need to be sure that we are taking the time, day by day, to implement policy controls, technical controls, procedures, documentation and scheduled reviews.

If you want to make an audit a pleasant experience, then make it more fun for the auditor. Happy auditors are really wonderful people to work with. More than that, if you are doing what is necessary to make your auditor happy, it is likely that you are doing what is necessary to effectively manage risk for your organization. That’s where the real value lies.

Looking for an awesome, no-nonsense technical conference for IT pros, developers and DevOps? IT/Dev Connections kicks off in Dallas in 2018!