Say "compliance" in a group of security practitioners, and you'll probably hear a lot of groans and complaints about "idiots with checklists" or "compliance isn't security."
As much as some might want to eliminate audits entirely and transition to a risk management framework (RMF)-only and checklist-free world, here's the reality: Mandates and regulations exist, and the only way to prove to auditors and regulators that your organization is meeting these mandates is to provide evidence that the requisite controls and policies are in place.
Spanning a variety of environments
Today, those controls and policies -- among them risk-driven cloud compliance -- must span multiple environments. As a result, reporting activities have to be carefully coordinated -- a challenging task. The great news is that security practitioners can improve outcomes for both security and compliance by using a framework that combines risk management and policy. The strategy can be crosswalked through all parts of an organization's digital real estate -- from work-from-home endpoints to on-premises systems.
Risk-driven compliance relies on RMFs to enable organizations to make customized decisions. A checklist might ask for a specific control -- such as scanning for vulnerabilities every quarter -- while a risk-driven approach, by contrast, concentrates on setting a risk target that is expressed via policy. With policy in place, an organization can select the best process and control to meet the objective. For some companies, quarterly scans might not be enough. In those cases, based on their risk analyses, these organizations might call for more frequent or even continuous scanning.
Merging disparate demands
Now comes the tricky part. When assessors come to certify an organization meets standards -- say, System and Organization Controls 2 (SOC 2), HIPAA, PCI DSS or whichever regulation the organization is required to meet -- they invariably ask for evidence that a given policy is being implemented. When they do, the organization needs to justify its control decisions, particularly if they do not align perfectly with the regulatory standard being measured against.
Consider pre-engagement vetting and security review. Due to the increased focus on supply chain security, many businesses want their partners to prove their security policies are satisfactory. For some, a SOC 2 certification is enough proof. But others might want a Standardized Information Gathering (SIG) questionnaire -- one that clearly states the organization's policies -- to be completed. This can create a time burden on the teams required to provide input to -- or manage/oversee -- the response. It also can lead to a policy mismatch when one team adjusts wording in the response to better meet the needs of the requestor.
The end result? In practice, combining a risk-driven approach with an RMF can become a messy jumble of inconsistent policies across a series of assessments, SIG responses and internal tracking mechanisms, including risk registers; governance, risk management and compliance (GRC) systems; and spreadsheets.
Crosswalking cloud policies and controls
Next, consider something simple like a risk-driven requirement that all cloud-based root and superuser accounts be protected using multifactor authentication (MFA). It's not uncommon for companies to use all the major cloud providers, which means assessors and partners require that organizations meet the Center for Internet Security (CIS) benchmarks for each of them.
Here's a quick illustration of the CIS wording from an example company, mapped to both the terminology of the CIS control and the individual cloud provider's. Note that there are some subtle but important differences. AWS, for example, uses the word root rather than admin, while Microsoft Azure uses the term privileged users. Google Cloud Platform (GCP) and AWS have two different settings for MFA. For AWS, recommendation 1.5 calls for MFA for the root user, while 1.6, applicable to a more conservative Level 2 profile, requires hardware-based MFA. GCP is similar: Recommendation 1.2 stipulates MFA for all nonservice accounts, including privileged accounts, while 1.3 requires enhanced two-factor authentication -- security key enforcement -- rather than generic MFA.
Aligning these various recommendations depends on a number of factors, among them the platforms in use and the security models deployed. If a respondent edits the terms of a corporate policy to satisfy the specifics of a SIG questionnaire -- or provides audit responses to match a specific CIS or other benchmark control -- a mismatch is created. But, if an organization has created a crosswalk table like the one above, any potential mismatches can be quickly identified.
To address potential risk-driven cloud compliance inconsistencies, consider building linked spreadsheets that pull from an authoritative policy source. Many GRC and policy management/automation tools contain features to organize information within a crosswalk reference table that highlights any potential inconsistencies that may arise. Rather than cutting and pasting data from a policy document directly into the crosswalk, link the content so that, when the policy document changes, the wording within the crosswalk map changes as well.
Finally, in the control implementation section, provide wording that accommodates all the salient information that a respondent to an assessor or SIG participant may need. In the above example, that second column could read: "MFA is required for remote/cloud admin access. 'Admin access' includes root in AWS and privileged users in Azure; for GCP, MFA is set across all interactive (nonservice account) users. In GCP and AWS, MFA is implemented via hardware options."
By crosswalking controls via mapping documentation and linking the policy elements back to a fundamental policy, companies can ensure compliance even as they employ a risk-driven approach.