Security fundamentals: Policy compliance

Most security practitioners and experts alike agree that establishing foundational security controls will give agencies the biggest security bang for their buck. So where should IT managers focus their efforts in order to ensure a strong foundation of security? As we have examined in parts one and two of this series, there are four key fundamentals at the heart of every effective security foundation: log management, file integrity monitoring, policy compliance and vulnerability management. Here, in part three of this series, we address policy compliance.

There is no compliance without audit

Policy compliance is a broad term and can refer to any kind of policy, from internal standards to regulatory requirements. All policy compliance processes have one thing in common, however: an audit. Without an audit process of some kind, there’s no mechanism for assessing compliance. Fundamentally, policy compliance isn’t about the utility or value of what’s actually implemented; it’s about the process of assessment.

The policies themselves are selected for their value, which might include avoidance of fines, increased security or availability of budget. It is, however, entirely possible to implement all the required controls and capabilities yet remain non-compliant through an inability to measure.

Confusing controls with compliance

In order to discuss policy compliance coherently, it’s worthwhile to understand three characteristics of compliance tools or capabilities:  

Provides - Tools that directly provide a required control fall into this category. If an agency has a requirement for vulnerability assessment, the VA tool provides that control. The same would be true for log management, change detection or secure remote access. If the requirement is the square hole, this is the square peg that fits into it.

Validates - Some tools are specifically designed to measure whether another control is in place and configured correctly. These tools validate a control, but they don’t provide it directly. In many cases, validation is done manually with a spreadsheet, but opportunities for automation are often available. Validation generally results in a report in the auditor’s hands.

Supports - There are definitely cases where a tool or capability doesn’t fulfill all the requirements of a required control but makes the use of that control substantially easier or more effective. Log management is the Swiss army knife of the security toolset and a good example of a supporting control. If agencies that are required  to limit access to a specific set of users, a log management tool can’t restrict access, but it can identify events where an unapproved user takes an action. In other words, it supports the control, but doesn’t provide or validate it. Another example is a VA tool that provides asset discovery. The data is useful in a variety of other controls but doesn’t necessarily fulfill them.

Using this terminology -- provides, validates, supports -- can make conversations about compliance much clearer. Selection of a tool that provides a control doesn’t necessarily guarantee validation, so it’s important to ask how that control will be validated. At the same time, a powerful tool might not provide or validate, so a discussion around how it supports other controls should be had. It’s important to avoid confusing the controls themselves with their validation. Both are required for compliance. 

Getting value from policy compliance

The implemented controls themselves are intended to deliver value aligned with their purpose. Policy compliance itself is designed to validate that those controls are in place. How do agencies get value from policy compliance tools? It’s all about the audit.… Well, mostly about the audit.

Policy compliance tools should be focused on validation and justification for an auditor. Any new policy compliance tool should reduce the time spent preparing for audits by collecting data and delivering it in a usable format. In many cases, that’s a report, but it might also include the ability to extract specific data as an auditor requests it. Use previous audits as a guide to determine how the tool might help, and be suspicious of tools that actually make audits harder to pass.

The second way that agencies can get value from policy compliance is as a budget driver. It’s notoriously difficult to demonstrate a return on investment for security because the outcomes are difficult to predict. Policy compliance is designed to pair a risk with a predictable outcome, usually a fine or other punitive measure. By creating a specific outcome, a compliance standard creates the environment in which budget can be effectively allocated.

That predictable outcome can also be used to secure budget for tools and capabilities that have benefits beyond the specific policy. Don’t be afraid to use compliance to justify budget.