How to Pass Every Audit - Policies & Standards

Audit
Written By Andrew Alaniz

Credibility

I have directly led the response to numerous federal regulator exams (which can last three months or more) covering cloud, vulnerability management, network security, and resiliency. I have also led the response to dozens of internal audits across cloud, DLP, endpoint security, and incident response. I have managed relationships with state examiners, federal examiners, and FHFA, and have supported many additional audits and exams.

I have built programs in nearly every aspect of cybersecurity and many in technology, including incident response, endpoint security, cloud security, network security, risk management, data loss, resiliency, security architecture, and more.

Having been through this process many times, I have seen many ways to properly prepare and manage an audit, and I have seen many ways not to.

Where to Start

Every audit, whether internal, SOX, regulatory, or otherwise, begins with your defined policies and standards. A program's ability to properly define and write policies and standards is crucial to its ability to operate freely within an organization and minimize being bogged down in corporate red tape.

The response to this is often: "It doesn't matter how I write the policy or standard, there is so much red tape in my organization that I can never get to my actual job." This is a very real scenario for many cybersecurity teams. I've lived it. It is also what we signed up for by taking a job at a large corporation. Instead of acting surprised, we need to expect it. So then what?

Then come the policies and standards. Many people loathe this topic because it is not pretty and it is not fun. But if you are responsible for any aspect of a program, your success hinges on your ability to do this well.

The next pushback I often hear is: "We are required to comply with [framework or control catalog] and I have no way around it." This is also simply not true. Every framework I have ever worked with (NIST CSF, ISO27001, and others) allows for scope definition, exception processes, and documented explanation, full stop. But if a policy stops at "this program must comply with NIST 800-53," you have your back against the wall. There is no exception process, no object or scope definition, and no out-of-scope definition.

Where We Go Wrong

The first mistake is conflating standards, policies, control catalogs, and frameworks. We need to clearly distinguish between them, and especially between a control catalog and a framework. A control catalog is not designed to measure compliance. It exists to provide a menu of potential controls for potential risks.

Cybersecurity Governance Hierarchy
Governance & security documentation hierarchy Framework Organizes your entire security program (e.g. NIST CSF, ISO 27001, COBIT) Answers: "How should we think about and structure security?" Policy Management's statement of intent and required behavior (e.g. Acceptable Use Policy) Answers: "What are the rules and who is responsible?" Standard Specific, mandatory requirements that enforce the policy (e.g. NIST 800-53, PCI DSS) Answers: "What specifically must be done to comply with the policy?" Control catalog Library of specific security controls to implement (e.g. NIST 800-53 control list, CIS Controls) Answers: "What exact safeguards should we put in place?" Operational risk tracking — sits alongside the above, not in the hierarchy Risk register Living inventory of identified risks, likelihood, impact, and remediation status Answers: "What risks do we know about and what are we doing about them?"

It rarely makes sense for a program to adopt multiple frameworks to organize around, as it creates conflict and makes audit responses more painful. It is possible to be audited against a framework you have not defined as your own, but it is usually straightforward to explain why and provide appropriate answers. In our case we will use NIST CSF (my preference).

Take MFA as an example. NIST CSF does not define anything specific about MFA, but it does state that access controls should exist: Protect → Identity Management & Access Control (PR.AA).

If we simply say "all users must use MFA," we are backing ourselves into a corner again. What about IAM roles in AWS? What about service accounts? What about Kerberos, machine identities, or API keys? This is exactly where an auditor gets you. "You say all users need MFA, but I see that your service accounts don't use MFA." It can seem petty, and sometimes it is, but there is a better way to set yourself up for success. It just requires writing your policy and standard statements in a way that works for you.

If the policy states that all human users (employees, contractors, and third parties) must use MFA for access, then the standard can get more specific. We can bring in a couple of control catalogs to help, because NIST 800-63 was not designed to account for non-human identity types, and I find that CIS Controls apply well in cloud environments but not as well on-premises. For identity, we will specify that CIS Controls apply in cloud and NIST 800-63 applies on-premises.

Within each control catalog, we then select the controls that are applicable. We do not necessarily need to explain every exclusion or why we didn’t use every control in the standard itself, but we need to be able to. We will also note clearly that this standard applies specifically to human identities. Remember the control’s purpose is to move the needle from the inherent risk to the residual risk in line with a risk appetite, and that rarely requires all of the controls in a catalog.

This sets us up to answer quickly and confidently how and why we protect access for human users and just as importantly, it gives us a defensible boundary when an auditor starts asking about everything else.

MFA Governance Hierarchy
Governance hierarchy — MFA policy example Framework — NIST Cybersecurity Framework (CSF) Organizes the security program around: Govern, Identify, Protect, Detect, Respond, Recover MFA sits under Protect > Identity Management & Access Control (PR.AA) Policy — Identity & Access Management Policy Scope: All employees, contractors, and third parties must implement MFA for direct access associated with their human identities. Separate requirements are defined for non-human identities. Standard — identity authentication requirements Mandatory requirements that operationalize the policy, segmented by identity type NIST SP 800-63 Human identities — AAL2/AAL3 MFA requirements CIS Controls (v8) Cloud identities — Control 6: Access control management Control catalog — specific MFA safeguards Discrete controls selected to implement the standard NIST 800-53: IA-2, IA-5 Identification, authentication, token management CIS 6.3, 6.4, 6.5 MFA enforcement, privileged access, cloud IAM Note: non-human identities — cloud-based IAM controls Separate controls and requirements apply (e.g. service accounts, workload identities, API keys) Operational risk tracking — sits alongside the hierarchy, not within it Risk register — MFA risk tracking Tracks: MFA gaps by population, exceptions granted, legacy systems out of scope, third-party compliance status, open findings from exams or audits Answers: "Where are we not compliant and what is the residual risk?"

Overall Design of a Policy and Standard

The simplest answer is that a policy covers the what and a standard covers the how. In your policy, keep it high level and define where it applies, who it applies to, and why it is necessary. In your standard, describe how the requirement is implemented, how it is measured, where it does not apply, and how exceptions are managed.

Summary

A large cybersecurity program will inevitably produce a large number of documents to cover all of this. But balancing detail with clarity goes a long way toward ensuring your program can operate transparently and respond to an audit with minimal disruption to day-to-day work.

Andrew Alaniz https://www.alaniz.io
Previous

How to Pass Every Audit - Scope
Next

How to Pass Every Audit - A Practitioner's Guide