GRC Engineering Club: Week 2 of 6

Making rules executable in AWS

Last week, I started my GRC Engineering Club journey by building NIST 800-53 controls into Terraform. Creating the control is only part of the job.

Now we need to prove that the control actually works.

Week 2 introduced me to Rego, a declarative policy language used by Open Policy Agent (OPA). Rego can evaluate structured data, such as infrastructure-as-code files and configuration data, to determine whether it meets defined policies.

This was my first time working with Rego. Having some experience with Python and other programming languages made parts of it easier to pick up, but the bigger lesson for me was not really about learning another language. It was about turning a compliance requirement into something that can actually be tested.

From Control to Executable Policy

For this challenge, the Rego policies evaluate the Terraform plan created during Week 1.

We are testing three NIST 800-53 controls:

Control	Policy	Denies when
SC-28 — Protection of Information at Rest	sc28_encryption_aws.rego	An aws_s3_bucket does not have a matching server-side encryption configuration
AC-3 — Access Enforcement	ac3_no_public_aws.rego	The public access block is missing, or any of its four flags is not set to true
CM-6 — Configuration Settings	cm6_required_tags_aws.rego	A taggable resource is missing Project, Environment, ManagedBy, or ComplianceScope

The policies are tested using Conftest, which evaluates the Terraform configuration against the Rego policies. I tested both a compliant and non-compliant Terraform plan to see the response.

For example, we can intentionally remove encryption from the configuration to verify that the SC-28 policy catches the violation.

A control existing in Terraform does not automatically prove that the control is effective. The test gives us evidence that the policy behaves as expected when something is configured incorrectly.

Where Governance Comes In

This is where the conversation moves beyond the technical control and into governance.

The technology can tell us that a resource violated a policy. Governance determines what happens next.

• Does the deployment stop?

• Who owns remediation?

• Who has the authority to approve an exception?

• How long can that exception remain open?

• What evidence is retained showing why the decision was made?

Policy-as-code can help organizations consistently enforce risk decisions, but the organization still needs to define ownership, escalation paths, exception processes, and accountability.

That's where leadership comes in.

Leadership ultimately determines which controls are mandatory, where exceptions are allowed, what level of risk is acceptable, and who has the authority to make those decisions.

What This Could Look Like Operationally

These checks do not have to live as a manual compliance exercise. They SHOULD become part of the development and deployment process.

A policy check could run:

• when infrastructure code changes;

• before a resource is deployed;

• as part of a CI/CD pipeline;

• on a scheduled basis;

• as part of continuous compliance monitoring; or, dare I say it,

• a Gold disk (OG's don't come for me, lol)

Instead of discovering later that a resource was deployed without encryption, required tags, or public access protections, the organization can identify the issue earlier. The resource owner can then correct the configuration or, if there is a legitimate business reason for the exception, follow the organization's risk acceptance process. That moves compliance much closer to the actual work.

You can see my Week 2 work, including the Rego policies and test evidence, in my GitHub repository.

I'm curious how others are handling the governance side of policy-as-code, especially exception management and ownership. Send a DM and let's chat!