GRC Engineering - Bringing GRC to a repository near you

GRC Engineering - Bringing GRC to a repository near you

Speakers: Varun Gurnaney

Conference: BSidesSF 2024

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

Overview

In this insightful talk at BSidesSF 2024, Varun Gurnaney, a security engineer, presented a compelling vision for GRC Engineering, an approach that seeks to bridge the historical chasm between Governance, Risk, and Compliance (GRC) functions and engineering teams. Gurnaney argues that traditional GRC processes are often manual, burdensome, and lead to significant friction with engineers, who are primarily focused on shipping product and fixing bugs. His core premise is that by applying engineering principles and automation to GRC, particularly compliance, organizations can streamline audits, improve security hygiene, and ultimately foster a more collaborative environment where engineers "hate compliance less."

The presentation delves into the inherent challenges faced by both compliance teams and engineering departments, highlighting how these often conflicting priorities lead to inefficiencies and compliance gaps. Gurnaney proposes GRC Engineering as a dedicated discipline, advocating for the development of code-based solutions—ranging from simple scripts to complex "audit engines"—to automate evidence collection, control validation, and reporting. This shift from manual, document-centric processes to automated, code-driven workflows promises to transform how organizations achieve and maintain compliance, making it a continuous, integrated part of the development lifecycle rather than a periodic, disruptive event.

Background

▶ Watch: Speaker's painful experience doing ISO vendor audits as a software engineer. (01:00)

The landscape of GRC, particularly compliance, is fraught with challenges that have historically created tension between security and engineering teams. Varun Gurnaney, drawing from his personal journey from software development to vendor security audits and then to application security roles at companies like Zendesk and Robinhood, experienced firsthand the "painful process" of traditional GRC. This experience motivated his pivot to solving GRC problems, driven by the observation that the market was validating automation in the compliance space through significant startup funding.

Gurnaney defines GRC broadly: Governance involves policies and procedures, Risk ensures business objectives are not hindered by security or business events, and Compliance focuses on adherence to laws and frameworks. For the purpose of this talk, he explicitly narrows his focus to security compliance, acknowledging that the principles discussed could apply to other compliance areas, such as the emerging field of AI compliance (e.g., ISO 401).

Security compliance, while often overlooked, plays a critical role in business operations. It is essential for sales, particularly for B2B SaaS companies selling to enterprises, as certifications like SOC 2 are often prerequisites. Compliance also helps mitigate financial risks by reducing potential fines associated with privacy frameworks like GDPR. Furthermore, it ensures adherence to industry standards such as ISO, PCI, NIST, and HIPAA. A significant challenge for compliance teams is the substantial overlap (60-70%) among these frameworks, each with unique nuances that require detailed Gap Assessments. For instance, FedRAMP emphasizes vulnerability management, while PCI focuses on CDE environment segmentation.

The compliance team acts as a program management function, interfacing with various departments—legal for GDPR, finance for SOX, the board for NIST CSF, and sales for SOC 2. They are tasked with gathering information and translating it into framework language, often without direct access or capability to retrieve the necessary data themselves. This leads to two primary workstreams: achieving compliance and supporting audits.

Achieving compliance for a new product, such as an SMS API endpoint, involves a multi-step process: a kickoff meeting with stakeholders (sales, engineering, leadership, product), a gap assessment against existing controls, remediation of identified gaps by engineering teams, testing, and finally, certification. This process inherently requires significant interaction with engineering.

The audit period, typically occurring every six months or annually, mirrors this interaction. It begins with a kickoff, a pre-assessment to anticipate auditor requests, the audit cycle itself where auditors request samples, validation, and finally, closing the audit. Again, engineering teams are heavily involved in the pre-assessment, sample provision, and validation phases.

From an engineering perspective, these interactions are highly disruptive. Engineers are incentivized to move fast, ship product, fix bugs, and scale systems. Security, while important, is often an "extra thing" on their plate, and compliance support is rarely tied to performance bonuses. This constant need to context switch when compliance requests come in leads to engineers disliking compliance. On the other hand, compliance teams face an ever-growing list of frameworks, a packed audit calendar, and the challenge of being "disliked" by engineering, which can lead to gatekeeping of information, reduced security hygiene, and ultimately, compliance gaps. This dynamic creates a significant culture problem that GRC Engineering aims to address.

Key Findings

▶ Watch: The core problem: Engineers dislike compliance due to context switching and e... (10:00)

Varun Gurnaney's presentation highlights several critical findings regarding the state of GRC and its interaction with engineering:

1. The Cultural Divide: A fundamental problem exists where engineers "hate compliance less" due to the disruptive, manual, and often unrewarding nature of compliance requests. This leads to context switching, perceived extra work, and a lack of motivation to support GRC initiatives.
2. Compliance Team Overload: Compliance teams are overwhelmed by the sheer number of overlapping frameworks, a continuous cycle of audits, and the necessity to act as program managers to gather information from disparate parts of the organization. They lack direct access to the data needed for validation.
3. Information Gatekeeping and Reduced Hygiene: The friction between compliance and engineering can result in engineers withholding or delaying information, leading to reduced security hygiene and the creation of compliance gaps.
4. Limitations of Vendor Tools: While many compliance automation startups offer valuable solutions, they are primarily effective for smaller, cloud-native, SaaS-only organizations with standardized infrastructure and tooling. They often fall short for large enterprises with custom tooling, on-prem deployments, diverse infrastructure components, or complex, multi-team environments. For these larger entities, vendor tools can sometimes devolve into "glorified ticketing systems."
5. The Need for an Engineering Approach: The core finding is that GRC problems, particularly in compliance, can and should be solved with engineering methodologies. This involves building code-based solutions to automate evidence collection, control validation, and reporting, thereby reducing manual effort and improving accuracy.
6. GRC Engineering as a Dedicated Function: Gurnaney proposes GRC Engineering as a distinct discipline or function. This can involve upskilling compliance personnel with basic scripting or, more effectively, hiring software engineers who are passionate about solving compliance problems. The goal is to minimize direct interface between compliance and engineering teams for audit support.

These findings collectively underscore the necessity for a paradigm shift in how GRC is approached, moving from a manual, reactive, and often adversarial process to an automated, proactive, and integrated engineering discipline.

Technical Deep Dive

▶ Watch: Compliance enablement: baking compliance into infrastructure, e.g., Kubernete... (14:00)

GRC Engineering, as proposed by Varun Gurnaney, is an engineering-focused discipline aimed at reducing the friction between compliance and engineering teams by automating GRC processes. The core philosophy revolves around building code-based solutions rather than relying on spreadsheets or manual interactions. Gurnaney outlines two main ways to build within this discipline: supporting the compliance team directly or supporting the product and engineering teams. This is achieved through either Audit Tooling or Compliance Enablement. While the talk focuses primarily on Audit Tooling, Gurnaney briefly explains Compliance Enablement.

Compliance Enablement involves baking compliance requirements directly into the infrastructure. For example, in a Kubernetes deployment, a small tool could be written by an engineer to consume data from the Cube API server or Cube audit logs. This data would then be processed and pushed into audit-friendly reports, such as PDF files or spreadsheets. This approach requires engineers with the specific skills to integrate with various infrastructure components (Kubernetes, Spinnaker, GitHub) and build custom tooling to extract compliance-relevant information. It's about making compliance a native part of the system's operation.

The main focus of the talk, however, is Audit Tooling, which directly assists the compliance team by building systems that pull data from various sources and prepare audit-ready artifacts. Gurnaney categorizes Audit Tooling into two modes: Easy Mode and Hard Mode.

Easy Mode: Quick Value Proposition

The Easy Mode is designed for demonstrating quick value and gaining organizational buy-in for GRC Engineering. It involves identifying a specific control that is time-consuming to operate or validate and writing a basic script to automate it. Gurnaney suggests simple Python scripts, potentially as short as 15 lines, which can be developed quickly, even with the help of tools like ChatGPT.

A practical example provided is vulnerability management SLA checks. Historically, compliance teams would manually ask engineers to pull tickets and perform checks against SLAs in spreadsheets. With Easy Mode, a simple script can be written to:

1. Define SLAs as integers (e.g., sla_critical = 7, sla_high = 14).
2. Implement a check_sla function that compares the vulnerability's due date with the current date and time.

This script automates the validation, providing immediate value by eliminating manual effort and reducing interaction with engineering for this specific task.

Hard Mode: The Audit Engine

The Hard Mode involves building a comprehensive Audit Engine, a backend service designed to handle the entire audit heavy lifting. This is a more significant undertaking, typically for organizations with a higher level of GRC maturity. For the Audit Engine to be successful, two foundational elements are crucial:

1. A comprehensive list of all controls.
2. A comprehensive list of all applications that these controls depend on.

Requirements for the Audit Engine

Gurnaney outlines several key requirements for building the Audit Engine:

1. Controls Interface: An interface to store all controls or a mechanism to pull them from an existing GRC tool. This centralizes control definitions.
2. Scope Tracking Interface (Scope DB): A way to track all in-scope items for various frameworks (e.g., ISO, SOC 2, PCI, HIPAA). This database would store details like audit start/end dates and sampling details (potentially in a JSON blob).
3. Control-to-Application Mapping (Chex DB): A system to map controls to the specific applications they apply to. For instance, an HR application might have connectors to this database, indicating which controls it satisfies. Gurnaney emphasizes that GRC engineers would build these "CRUD applications" (Create, Read, Update, Delete) to manage these mappings, as GRC personnel are not expected to write code.
4. Serializer: Given that multiple systems might be involved for a single control area (e.g., five different vulnerability scanners acquired over time), a serializer is essential. This component accommodates complexity by providing a common way to pull data from diverse sources and transform it into a standardized schema.

• Vulnerability Management Serializer Example: Different engineering teams might use various vulnerability scanners. The serializer would abstract these differences, pulling data from each scanner and presenting it in a unified format for the middleware.
• Access Management Serializer Example: For access management, data from systems like GitHub, Kubernetes logging, Spinnaker, or Salesforce CRM would be serialized into a common dictionary schema. This schema would define fields like user and access_list, ensuring consistency regardless of the source system.

1. Integration Middleware: This component is responsible for chaining different applications or data sources together to satisfy the requirements of a particular control. It acts as the orchestrator between the serialized data and the audit engine's logic.
2. Audit Triggering and Continuous Compliance: The engine needs a mechanism to trigger audits on demand and to support continuous compliance. Gurnaney humorously notes that "continuous compliance is a nice buzzword" but essentially boils down to a "for loop" or a "cron job" that runs checks periodically (e.g., every Monday at 10 AM).

System Design of the Audit Engine

Gurnaney presents a conceptual system design for the Audit Engine, illustrating how these components interact:

• Controls Home: This central component interacts with the Scope DB (for audit scope details) and the Chex DB (for control-to-application mappings).
• Serializers: These sit between the various source systems (e.g., vulnerability scanners, GitHub, K8s logs) and the Integration Middleware. They normalize data into a consistent schema.
• Integration Middleware: This component receives the serialized data and applies the logic to chain different applications or data points to validate controls.
• Audit Engine Core: This is the central processing unit that orchestrates the audit process, leveraging data from the middleware, Scope DB, and Chex DB.
• API Server: Handles all incoming traffic and requests to the Audit Engine.
• Web Interface: Provides a user interface for compliance teams and senior leadership. This UI allows users to trigger audits, view continuous compliance status, check metrics, and monitor overall compliance posture.
• Worker: A dedicated compute and data store component responsible for generating and storing audit reports.

This comprehensive system design allows the Audit Engine to perform the heavy lifting of compliance, minimizing manual intervention and direct requests to engineering teams.

Demo / Proof of Concept

▶ Watch: Limitations of vendor tools for large enterprises with custom tooling or on-p... (16:00)

While no live code demonstration was performed, Varun Gurnaney presented a detailed conceptual system design for the Audit Engine, effectively serving as a proof of concept for how GRC Engineering can be implemented. The design illustrates the flow of data and processes, showcasing how the engine operates in two distinct modes: Audit Period Mode and Continuous Compliance Mode.

The core of the demonstration was a system diagram outlining the interactions between various components:

1. Controls Home: The central repository for control definitions.
2. Scope DB: Stores details about the scope of various audits (e.g., ISO, SOC 2, PCI, HIPAA), including sampling details in a JSON blob, and audit start/end dates.
3. Chex DB: Maps controls to specific applications and their connectors (e.g., an HR application's connection details).
4. Serializers: These components normalize data from diverse source systems (e.g., multiple vulnerability scanners, GitHub, Kubernetes logging) into a common, predefined schema. Gurnaney provided examples of how a vulnerability management serializer would unify scanner outputs and how an access management serializer would standardize user and access list data from different platforms.
5. Integration Middleware: This layer connects the serialized data from various applications to the Audit Engine, chaining together information required for a specific control.
6. Audit Engine: The core logic that processes the data, performs validations, and orchestrates the audit workflow.
7. API Server: An interface to handle all traffic and requests to the engine.
8. Web Interface: A crucial UI for compliance teams and leadership. This interface allows users to:

• Trigger audits on demand.
• Monitor continuous compliance status.
• View status checks and metrics that leadership values.

1. Worker: A dedicated component for generating and storing audit reports, ensuring that report generation doesn't impact the performance of other parts of the engine.

Gurnaney then elaborated on the two operational modes of the Audit Engine:

• Audit Period Mode: This mode is designed for scheduled audits. A user would trigger a single audit through the web interface. The engine would then sequentially:

1. Pull sampling details from the Scope DB.
2. Pull relevant data from various integrations (via the Integration Middleware and Serializers).
3. Perform the audit validation based on the collected data and control definitions.
4. Generate the necessary reports via the Worker.

A key benefit highlighted is the ability to resample if anything fails. Instead of having to reach out to engineering teams, set up meetings, and "piss them off," the compliance team can simply trigger a resample directly through the web interface, as it's just a new arrow in the automated workflow.

• Continuous Compliance Mode: Described as a "buzzword" that is "essentially just a for loop" or a "cron job," this mode involves the Audit Engine running checks continuously or at regular intervals (e.g., "every Monday 10 a.m."). By simply "moving the arrow around" in the system design, the same components can be leveraged to provide ongoing assurance. This proactive approach significantly reduces anxiety for compliance teams, as they have real-time visibility into their compliance posture and are always prepared for an audit.

The conceptual design effectively demonstrated how a well-architected GRC Engineering solution can automate complex compliance workflows, reduce manual effort, and improve the relationship between compliance and engineering by minimizing disruptive requests.

Defensive Implications

▶ Watch: Technical detail of the audit engine: using serializers to normalize data fro... (22:00)

The insights from GRC Engineering offer several critical defensive implications for organizations looking to improve their security posture and compliance efficiency:

1. Acknowledge and Address the Cultural Problem: The first step for any organization is to recognize the inherent friction between traditional GRC processes and engineering teams. This cultural divide leads to inefficiencies, information gatekeeping, and potential security gaps. Adopting a GRC Engineering mindset can foster a more collaborative environment.
2. Invest in GRC Engineering as a Dedicated Function: Organizations, especially large enterprises with complex, custom environments, should consider establishing a dedicated GRC Engineering team or function. This involves either upskilling existing compliance personnel with basic scripting knowledge or, more effectively, hiring software engineers who are motivated to solve compliance problems through code. This specialized function can act as a bridge, translating compliance needs into automated solutions.
3. Start with "Easy Wins" to Build Momentum: For organizations new to GRC Engineering, beginning with "Easy Mode" audit tooling is crucial. Identifying high-friction, time-consuming manual controls and automating them with simple scripts (e.g., vulnerability management SLA checks) can quickly demonstrate value, gain buy-in from leadership, and build confidence within the organization.
4. Strategic Use of Vendor Tools: Defenders should understand when commercial GRC automation tools are appropriate. They are highly effective for smaller, cloud-first, SaaS-only companies with standardized infrastructure. However, for large enterprises with on-prem deployments, custom tooling, or diverse infrastructure components, these tools may not suffice and could become "glorified ticketing systems." In such cases, internal GRC Engineering becomes a necessity.
5. Prioritize Data Standardization and Serialization: A key defensive strategy is to define and implement standardized schemas for compliance-relevant data across all systems. The concept of serializers and integration middleware is vital here. By normalizing data from disparate sources (e.g., multiple vulnerability scanners, various access management systems) into a consistent format, organizations can ensure accurate and efficient aggregation for audit purposes.
6. Implement Continuous Compliance: Moving beyond periodic audits to a continuous compliance model is a significant defensive upgrade. By automating checks to run regularly (e.g., daily or weekly via cron jobs), organizations can maintain an always-on view of their compliance posture. This proactive approach helps identify and remediate issues much faster, reducing the risk of non-compliance and improving overall security hygiene. It also significantly reduces "audit anxiety" for compliance teams.
7. Build an Audit Engine for Scale: For large, complex organizations, investing in building a custom Audit Engine is a robust defensive measure. This backend service centralizes control management, scope tracking, application mapping, and automates the entire audit workflow. It empowers compliance teams to trigger audits, resample data, and generate reports without direct, disruptive interaction with engineering, thereby freeing engineers to focus on product development.
8. Leverage Existing Infrastructure for Compliance Data: Defenders should explore how existing infrastructure components (e.g., Kubernetes API server, audit logs, Version Control systems for commits/PRs) can be tapped for compliance evidence. Building compliance enablement tooling that integrates directly with these systems can provide a rich source of audit-ready data.
9. Consider a Compliance Data Lake for Future AI Integration: While Gurnaney notes that AI for compliance is not yet mature for most organizations, building a "compliance data lake" by centralizing audit data through the Audit Engine lays the groundwork for future AI-driven insights and automation, which could further enhance defensive capabilities.

By embracing GRC Engineering, organizations can transform compliance from a reactive, burdensome overhead into a proactive, integrated, and efficient component of their overall security strategy.

Key Takeaways

• GRC Engineering Addresses a Critical Cultural Divide: The traditional, manual approach to compliance creates significant friction between compliance teams and engineering, leading to inefficiencies, context switching for engineers, and potential security gaps. GRC Engineering aims to bridge this gap by automating compliance processes.
• Automation is Key to Overcoming Compliance Challenges: Compliance teams are overwhelmed by numerous overlapping frameworks and continuous audit demands. Applying engineering principles and building code-based solutions, from simple scripts to complex systems, can significantly reduce manual effort and improve accuracy.
• Vendor Tools Have Specific Use Cases and Limitations: While many commercial GRC automation tools are excellent for smaller, cloud-native organizations with standardized infrastructure, they often fall short for large enterprises with custom tooling, on-prem deployments, or diverse engineering environments.
• The Audit Engine is a Scalable Solution for Complex Environments: For larger organizations, building a custom "Audit Engine" – a backend service that centralizes controls, tracks scope, maps applications, and automates evidence collection and reporting – provides a robust and scalable solution for continuous compliance.
• Data Standardization and Serialization are Foundational: To effectively automate compliance across diverse systems, it is crucial to define common schemas and implement "serializers" that normalize data from various sources (e.g., vulnerability scanners, access logs) into a consistent format for the Audit Engine.
• Continuous Compliance is Achievable and Beneficial: By implementing automated checks that run regularly (e.g., via cron jobs), organizations can move from periodic audits to continuous compliance, providing real-time visibility into their posture, reducing audit anxiety, and enabling faster remediation of issues.

About the Speaker(s)

Varun Gurnaney is a security engineer based in San Francisco. His technology journey began with writing iOS and Android applications during his undergraduate studies. His first professional experience involved conducting vendor security audits, a process he found "painful." This experience led him to pursue a master's degree in the US, after which he worked in application security (AppSec) roles at companies such as Zendesk and Robinhood. During this time, he observed the growing market validation for compliance automation, which inspired him to pivot his career towards solving GRC problems. His stated goal is to help engineers "hate compliance less," a mission he actively pursues through his work and presentations like this one.