Rehearsal is Over: Moving GRC Engineering from Theory into Practice

Rehearsal is Over: Moving GRC Engineering from Theory into Practice

Speakers: Branden Rosenlieb, Security and Technology Director, University of North Carolina; Founder, Enclave Cyber Advisors

Conference: BSides SF

YouTube: https://www.youtube.com/watch?v=-cQ76vdQzVc

Overview

In "Rehearsal is Over: Moving GRC Engineering from Theory into Practice," Branden Rosenlieb delivers a compelling argument for transforming traditional Governance, Risk, and Compliance (GRC) functions into a modern, engineering-driven discipline. The talk addresses the critical challenge faced by organizations today: the inability of manual, static GRC processes to keep pace with rapid technological change, increasing regulatory demands, and the accelerating speed of business operations. Rosenlieb posits that by adopting principles from product development and DevOps, GRC can evolve from a perceived blocker into a strategic business enabler.

This presentation is particularly relevant for security professionals, GRC practitioners, and organizational leaders seeking to enhance their compliance posture, reduce operational overhead, and integrate security into the software development lifecycle more effectively. Rosenlieb highlights how an engineering approach to GRC, emphasizing automation, continuous monitoring, and iterative improvement, can lead to "continuous readiness" rather than the chaotic, point-in-time snapshots often associated with traditional audit cycles. The talk provides practical, open-source examples and a conceptual framework for implementing these changes, making a strong case for why GRC engineering is not just an aspiration but a necessity for modern organizations.

Background

▶ Watch: Introduction to the talk and speaker Branden Rosenlieb (0:00)

The current state of GRC, as described by Rosenlieb, is characterized by several significant shortcomings that impede organizational agility and security effectiveness. Traditional GRC methodologies are largely manual, relying heavily on human effort, spreadsheets, and document-centric processes. This approach is inherently unscalable and struggles to keep pace with the velocity of modern enterprises, especially those with thousands of employees or rapidly evolving technology stacks. For smaller businesses and startups, the cost and inefficiency of manual GRC are often prohibitive.

A core issue is the reliance on static products, tools, or processes that, once established, resist change. This creates a rigid framework ill-suited for dynamic environments. Furthermore, GRC often operates on cyclical audits, typically once a year, providing only a "singular snapshot" of the environment. This point-in-time assessment leads to significant stress and "chaos during audit periods," consuming valuable engineering bandwidth for evidence gathering, data flow explanations, and report generation. The culmination of these issues is often described as "spreadsheet hell," where version control problems, tedium, and manual data entry dominate the compliance landscape.

Rosenlieb advocates for a fundamental shift away from this audit-cycle thinking towards a GRC engineering mindset, inspired by product organizations and iterative system design. This involves:

• Iterative System Design: Approaching GRC as a continuously improving system rather than a static product.
• Dynamically Updating Requirements: Moving beyond annual framework updates to systems that can adapt to changing regulatory landscapes and multiple compliance frameworks simultaneously.
• Continuously Refreshing Artifact Repos: Shifting from a mad rush for evidence during audits to automated, ongoing collection of artifacts.
• Feedback Loops: Designing processes where changes in one area propagate to others, and each process feeds into the next, reducing isolation and improving efficiency.

This shift aims to transform GRC from a perceived "blocker" into an "enabler," directly contributing to organizational metrics like sales enablement and faster go-to-market timings, especially as clients increasingly demand SOC 2 reports and other certifications for third-party risk assessment.

Key Findings

▶ Watch: Analyzing the challenges of traditional GRC processes (2:20)

The talk's key findings revolve around the imperative for organizations to transition to a GRC engineering model to achieve continuous readiness and make GRC a strategic asset. Rosenlieb identifies that this shift is "necessary to keep pace with speed and scale" and move beyond mere "checkbox compliance" to a system that delivers "actual impact on like your real-world security."

The core practical contributions and findings presented are:

1. Automation of Evidence Collection: Demonstrating how simple scripts can automate the gathering of critical configuration data from cloud environments, eliminating manual effort and providing continuous, up-to-date evidence.
2. Proactive Policy Enforcement and Risk Scoring: Introducing a policy engine that can evaluate infrastructure-as-code changes against defined policies, assign risk scores, and automatically flag or block non-compliant modifications, particularly for sensitive areas like Identity and Access Management (IAM).
3. AI-Augmented GRC Analysis and Cross-Walking: Showcasing an AI agent capable of acting as a "virtual GRC analyst," providing contextual information on controls, assessing the impact of proposed changes across multiple frameworks (e.g., ISO 27001 and FedRAMP Moderate), and recommending remediation actions.
4. Integrated GRC Process Loop: Presenting a conceptual architecture that stitches these automated tools together, creating a feedback loop where a failed policy check automatically triggers evidence collection and AI analysis, culminating in a human-reviewed ticket with pre-compiled information and recommendations. This significantly reduces human intervention, improves accountability, and generates a continuous audit trail.
5. Reframing GRC as a Business Enabler: Emphasizing that by reducing friction, enabling sales, and directly contributing to the bottom line, GRC can gain stronger organizational support and resources, moving it away from being a "drag" or "blocker."

These findings collectively illustrate a tangible path for organizations to implement GRC engineering, leveraging open-source tools and a DevOps mentality to build a more agile, effective, and continuously compliant security posture.

Technical Deep Dive

▶ Watch: Introducing the shift to GRC engineering principles (4:10)

Rosenlieb illustrates the principles of GRC engineering through three distinct open-source examples, culminating in an integrated process loop. These tools, while simple individually, demonstrate the power of automation and integration.

The first example is the AWS Audit Playbook, a Python project designed for gathering evidence from AWS environments. It leverages the Boto3 library, AWS's SDK for Python, to programmatically interact with AWS services. This playbook automates the collection of configuration data for common services such as S3 (storage), RDS (relational databases), and IAM (Identity and Access Management), as well as logging information from CloudTrail. The collected data is then saved in JSON format, which is highly interoperable and machine-readable, contrasting sharply with traditional manual evidence collection. Rosenlieb provides code snippets showing how to instantiate a Boto3 client, list S3 buckets, retrieve their encryption configurations, and check their public access settings, all saved as JSON outputs. This automation forms the foundation for continuous evidence collection.

Next, Rosenlieb introduces Open Policy Agent (OPA), a more extensive open-source policy engine. OPA allows users to define policies using a high-level declarative language called Rego, which is syntactically similar to YAML. OPA is designed to be integrated across an entire tech stack, including applications, APIs, Kubernetes, and infrastructure-as-code tools like Terraform. It creates comprehensive audit trails, logging the input received, the policy checked, and OPA's decision (pass or fail). A practical example is provided using Terraform:

1. A developer generates Terraform code (HCL) from an AWS environment, including an IAM password policy.
2. Later, this password policy is inadvertently or maliciously removed from the Terraform HCL.
3. During the standard Terraform deployment process (init, plan), an additional step is introduced to convert the TF plan to JSON. This JSON output, representing the proposed infrastructure changes, is then ingested by OPA.
4. OPA executes policies written in Rego. In the example, OPA is configured to assign weights and scores to changes based on their impact, comparing them against a defined risk tolerance. Critically, the policy also includes a rule to automatically fail any change that "touches IAM," regardless of its risk score, due to the sensitive nature of IAM configurations.
5. When OPA processes the TFplan.json, it detects the removal of the IAM password policy, flags it as an IAM-related change, and outputs a JSON result indicating false (failed policy).

This granular control allows organizations to enforce security policies pre-deployment, preventing non-compliant infrastructure from being provisioned. OPA's flexibility means policies can be highly fine-tuned, even checking details like the age of the user account making the change.

The third technical component is an AI Coding GRC Plugin, an open-source coding agent developed by Mario Lenado. This plugin supports both Cloud Code and Open Code environments and can act as a "virtual GRC analyst." It references over 72 files covering 15 GRC frameworks, including major ones like NIST, SOC 2, and GDPR. The plugin can perform various tasks beyond simple code analysis, such as document reviews (e.g., generating system security plans (SSPs) for FedRAMP), generating tabletop exercises, and answering GRC-related questions contextually based on an organization's codebase or even in a blank environment.

Rosenlieb demonstrates its use following the OPA failure:

1. Using a /grc control lookup slash command, the user queries the agent for details on ISO 27001 controls related to "password policy." The agent returns the relevant control, implementation requirements, related controls, and evidence artifacts, serving as a quick refresher.
2. A conversational query, "A new Terraform pull request removed that resource which holds the password policy. Does this create any issues?", elicits a direct answer: "Yes, removing that would create a gap with that same control." It then offers options (block or accept risk) and notes that accepting the risk would jeopardize ISO 27001 certification, recommending updating the PR.
3. Finally, to address multi-framework compliance, the user asks if the change impacts FedRAMP Moderate. The agent confirms an issue with FedRAMP Moderate controls IE5 and IIE51, showcasing its ability to perform cross-walking between frameworks and explain the implications.

These three examples lay the groundwork for a robust, automated GRC engineering pipeline, moving away from manual checks to proactive, continuous policy enforcement and intelligent analysis.

Demo / Proof of Concept

▶ Watch: Iterative system design, dynamic requirements, and feedback loops (4:30)

The culmination of Rosenlieb's technical deep dive is a conceptual process loop that integrates the three open-source tools into a cohesive GRC engineering workflow. This loop represents a practical proof of concept for moving GRC from theory into practice, significantly reducing manual intervention and enabling continuous readiness.

The demonstration begins with a developer submitting a pull request (PR) that, in our hypothetical scenario, removes an IAM password policy from the Terraform code. This action immediately triggers the automated workflow:

1. Open Policy Agent (OPA) Execution: The proposed Terraform changes (converted to JSON from the TF plan) are fed into OPA. As previously detailed, OPA's policy is configured to automatically fail any changes impacting IAM, regardless of a general risk score. Consequently, OPA flags the PR as non-compliant and fails the policy check.

1. AWS Audit Script Trigger: Upon OPA's failure, an automated trigger initiates the AWS Audit Playbook script. This script runs to collect the current configuration of the AWS environment, specifically focusing on IAM and S3 bucket settings. This provides immediate, up-to-date contextual evidence of the existing state before the proposed change.

1. AI GRC Analyst Review: The collected evidence from the AWS script, along with the details of OPA's failure, are then fed into the AI Coding GRC Plugin (the "virtual analyst"). The analyst is instructed to review the failure against the organization's preferred framework, such as ISO 27001. The AI agent analyzes the change, correlates it with the relevant control (e.g., password policy requirements), and provides a detailed assessment. It confirms the gap, offers remediation options (block the change or accept the risk), and highlights the implications for certification. Furthermore, it performs a cross-walking analysis, informing the team that the change would also violate specific controls under FedRAMP Moderate (IE5 and IIE51), demonstrating its multi-framework awareness.

1. Human Review and Remediation: All this compiled information—OPA's failure, current AWS configuration, and the AI analyst's detailed assessment and recommendations—is packaged into a ticket (e.g., a JIRA or Linear ticket). This is the point where a human GRC analyst or engineer gets involved. The human reviews the comprehensive context provided by the automated tools. Based on the AI's recommendation to remove the IAM change and confirming the rest of the PR is acceptable, the human approves the modified PR.

1. Confirmation Loop: After the modified PR is deployed, the AWS Audit Playbook script is run again. This final step serves as a confirmation that the password policy (or any other critical configuration) remains unchanged and compliant post-deployment, closing the loop and providing continuous assurance.

This integrated cycle demonstrates several key benefits:

• Reduced Human Intervention: Most of the evidence gathering, policy checking, and initial analysis are automated, freeing up human resources for higher-level decision-making.
• Continuous Evidence Collection: Evidence is gathered dynamically and continuously, moving away from point-in-time audit rushes.
• Enhanced Accountability: A clear "paper trail" is generated for every change, policy check, and decision, improving auditability and accountability.
• Proactive Compliance: Issues are identified and addressed before deployment, preventing non-compliant configurations from reaching production.
• Cross-Functional Collaboration: The process facilitates better collaboration between engineering and GRC teams by providing clear, data-driven insights.

This proof of concept effectively illustrates how GRC engineering can transform compliance into an agile, integrated, and continuously improving function within the development lifecycle.

Defensive Implications

▶ Watch: GRC engineering: customer focus, automation, organizational metrics (6:00)

The adoption of GRC engineering carries profound defensive implications, fundamentally reshaping how organizations approach security and compliance. By embedding GRC principles directly into engineering workflows, defenders can move from reactive, audit-driven responses to a proactive, continuous security posture.

Firstly, embracing Systems Design Thinking means that security and compliance are considered from the outset of any project, rather than as an afterthought. This involves designing for automation opportunities early and planning for future scaling and iterations. Defenders should prioritize automating "right there answers" – easily verifiable controls like "is encryption at rest used?" or "is logging implemented?" – as quick wins to build momentum and demonstrate value. This shifts the focus from manual checks to codified, automated validation, ensuring consistent application of security controls.

Secondly, a DevOps mentality is crucial. GRC engineering acknowledges that security solutions and policy engines may not work perfectly on the first attempt. Defenders must embrace an iterative approach, expecting failures, learning from them, and continuously improving the automated processes. This means setting up feedback loops where failures trigger automated remediation or provide actionable insights for engineers, rather than just generating audit findings.

Thirdly, customer alignment is key to making GRC an enabler, not a blocker. Defenders need to recognize developers, engineers, infrastructure teams, and project managers as internal "customers" of GRC. The goal is to reduce friction and interruptions, especially during critical periods like evidence gathering for audits. By providing automated tools and clear, integrated feedback, GRC can facilitate rather than hinder development. This involves being judicious about tool adoption, ensuring that each tool addresses a specific problem rather than simply "throwing tools at the problem."

Practical quick wins for defenders to build support for GRC engineering include:

• Automated user access reviews: Systematically identifying and flagging inappropriate or stale access, especially during onboarding/offboarding or team changes. This can leverage role-based access control (RBAC) principles to automatically flag inconsistencies.
• Automated configuration checks: Continuously validating cloud configurations (as demonstrated with the AWS Audit Playbook) against security baselines.
• Feeding data into trust centers: Automatically populating commercial compliance platforms with real-time compliance data, enhancing sales enablement and client trust. The interoperability of JSON-based tools with many trust centers makes this particularly efficient.

Crucially, defenders should start now, even if auditors are not yet fully prepared for a GRC engineering approach. While some auditors may still demand traditional formats (spreadsheets, PDFs), the investment in automation today will pay dividends. AI agents can act as a stop gap, converting JSON outputs into auditor-friendly formats. This proactive stance ensures readiness for future initiatives, such as the NIST FedRAMP 20x process, which aims to automate "about 80% of FedRAMP." By being ready when these larger initiatives mature, organizations can remove future steps rather than needing to build new processes from scratch.

Ultimately, GRC engineering empowers defenders to implement continuous evidence collection, continuous analysis, and continuous comparison against policies. This paradigm shift moves beyond mere "checkbox compliance" to an approach that delivers tangible, real-world security impact, directly contributing to the organization's resilience and bottom line.

Key Takeaways

• Shift to GRC Engineering is Imperative: Traditional GRC's manual, static, and cyclical nature cannot keep pace with modern business speed and scale. A shift to GRC engineering, adopting a product-oriented, iterative, and continuous approach, is necessary for achieving continuous readiness and real-world security impact.
• Automation is Key for Efficiency and Scale: Leveraging tools like the AWS Audit Playbook (Python, Boto3) for automated evidence collection, and Open Policy Agent (OPA) with Rego for proactive policy enforcement on infrastructure-as-code, drastically reduces manual effort and ensures consistent compliance.
• AI Augments GRC Analyst Capabilities: Open-source AI agents like the AI Coding GRC Plugin can act as "virtual GRC analysts," providing contextual control lookups, assessing the impact of changes across multiple frameworks (e.g., ISO 27001, FedRAMP Moderate), and recommending remediation, significantly improving analysis speed and accuracy.
• Integrated Workflows Drive Continuous Compliance: Connecting these automated tools into a cohesive feedback loop – where policy failures trigger evidence collection and AI analysis, culminating in human-reviewed tickets – creates a continuous, accountable, and proactive compliance pipeline, reducing human intervention and generating a comprehensive audit trail.
• GRC as a Business Enabler: By aligning with internal "customers" (developers, engineers) and focusing on reducing friction and providing quick wins (e.g., automated user access reviews, feeding trust centers), GRC can be reframed from a blocker to a value-add, directly contributing to sales enablement, market timing, and the organization's bottom line.
• Proactive Investment in the Future: Organizations should start implementing GRC engineering now, even if auditors aren't fully ready for automated inputs. This investment positions them for future initiatives like FedRAMP 20x and allows AI agents to bridge the gap by converting automated outputs into traditional formats, streamlining processes for tomorrow.

About the Speaker(s)

Branden Rosenlieb is a distinguished professional in the cybersecurity and technology space, serving as the Security and Technology Director at the University of North Carolina. In addition to his academic role, he is the founder of Enclave Cyber Advisors, demonstrating his entrepreneurial spirit and commitment to advancing cybersecurity practices. With over 11 years of experience spanning infrastructure security and GRC, Branden is particularly known for his ability to enhance organizations' cyber maturity while simultaneously helping them achieve their broader business goals. His expertise extends across highly regulated industries, including financial services, healthcare, and government, providing him with a deep understanding of complex compliance landscapes. Branden also dedicates his time to advisory work with startups, especially those navigating the early or mid-stages of their GRC journeys, where his insights can have the highest impact.