GRC is Ripe for a Revolution

A look at why Governance, Risk and Compliance lives in the dark ages and how it can be fixed

Throughout my 20+ year cybersecurity career, I’ve worked in various functions and roles. Much of that work has been in highly regulated environments (e.g., the U.S. Department of Defense (DoD), U.S. Federal civilian agencies, and commercial equivalents with large compliance requirements, so compliance has often been a focal point of my work, both in “technical” and non-technical roles.

This involves dealing with compliance frameworks such as NIST’s Risk Management Framework (RMF), FedRAMP, 800-171, CMMC, SOC2, HIPAA, and others (we love our acronyms in cyber, which I will discuss below).

I’ve done all this while enabling organizations of various shapes and sizes to pursue secure digital transformations, including mobile, cloud, SaaS, DevOps, agile, and AI.

While we’ve seen enterprises undergo a massive transformation from the widespread use of mobile devices and applications, cloud, Kubernetes, containers, microservices, APIs, CI/CD pipelines, and automation, the way compliance is done has largely remained stagnant.

We’ve also seen a big push in compliance, easily one of the largest drivers of security in the ecosystem. This is driven by changes with the SEC, liability, board awareness, and a slew of regulatory changes in the EU in particular.

We all know WHY compliance is critical, but the HOW compliance gets done is still an antiquated relic of past eras in software and digital technology.

---

---

Interested in sponsoring an issue of Resilient Cyber?

This includes reaching over 45,000 subscribers, ranging from Developers, Engineers, Architects, CISO’s/Security Leaders and Business Executives

Reach out below!

---

Problems & Opportunities

So, let’s walk through some of the problems and opportunities in GRC that make it ripe for a revolution to bring it into the Cloud-native, API-centric DevSecOps age and address the impedance mismatch that GRC has with modern software development.

Static Documentation

While we’ve watched the industry shift to dynamic, ephemeral environments such as Kubernetes, containers, Infrastructure-as-Code (IaC), and Cloud, where infrastructure and applications are programmatically defined, deployed, and managed, GRC still largely lives in static documentation such as Word Excel, and PDFs.

Anyone who has had to manage a system inventory in a modern cloud-native dynamic environment knows static methods don’t scale, and the same goes for environment compliance. In fact, Sysdig’s latest "Cloud-Native Security and Usage Report” found that 60% of all containers live for one minute or less. How can static documents possibly define and capture the compliance of an environment that moves in minutes while static documents move in months?

Worse, these documents are primarily still written and read by humans, at a time when GenAI’s and LLM’s can generate comprehensive documentation in minutes, and modern systems are communicating machine-to-machine via APIs and soon agentic workflows.

Yet, GRC still sends static handwritten documents with out-of-date irrelevant information rather than letting machines communicate the status and details of a system, environment, and associated compliance posture.

Whether these expansive static documents are truly reflective of the system they describe and its associated controls is irrelevant. As long as we check the box that we have “insert whatever document is needed for compliance,” we’re good; we’ve met the requirement and can store it away somewhere not to be referenced again until the next audit.

There have been promising rising alternatives, such as NIST’s Open Security Control Assessment Language (OSCAL), which promises to provide automated control-based assessments in machine-readable formats, as opposed to hand-jammed static documents that get stored somewhere and forgotten about until the next audit or assessment.

It’s worth noting that OSCAL has struggled with widespread adoption and implementation and may not be on the path to long-term success. Still, we can collectively agree on the future of compliance documentation, and artifacts should be in a form that machines can natively ingest, interpret, analyze, and report on.

Additionally, and not to drag the AI hype cycle into this, but with the advent of modern frontier models and LLMs, we can now generate comprehensive plain language compliance artifacts with text or multi-model LLM prompting based on specifics about the organization. This breaks from the days of tediously typing out verbose compliance artifacts that are irrelevant soon after they are written.

Security Control Inheritance & Reciprocity

A core part of compliance is meeting security controls. However, in modern software development, an overwhelming number of applications and systems are built atop hyper-scale CSPs, all of which have met many compliance frameworks and security controls.

This creates a situation where individual applications and, more broadly, organizations can and should inherit large percentages of security controls from their respective regulatory compliance framework requirements rather than needing to meet the controls themselves and/or explain duplicatively to assessors and auditors why they do not need to meet a said control because the CSP is already providing it as an inheritable control.

Cloud has a Shared Responsibility Model, which most of us are familiar with. In that model, controls are generally in three buckets: those fully met by the CSP, those shared between the CSP and the customer, and those left to the customer. The first of the trio should be something auditors, and assessors aren’t wasting time on or making organizations toil on.

Additionally, there should be some level of reciprocity among the compliance frameworks, as I will discuss below in the framework sprawl section of the article. If each framework has control (or many) that are materially the same, the individual organization shouldn’t need to reassert and meet said control again and instead should be able to lean into reciprocity among the frameworks, which can be done by cross-walking control compliance from one framework to the next.

Snapshot-in-Time Assessments

Another significant problem with GRC is that assessments and audits are nothing more than snapshot-in-time assessments of a system and organization’s compliance posture at the time of the assessment/audit.

I’m a father of 5.

This is akin to checking if my kids' room is clean and then naively assuming it is clean until I check again. In the world of compliance, this often occurs in length cyclical time phases, such as every 30 days, 60 days, 90 days, and often even annually.

This approach to cybersecurity is naive at best and disingenuous at worst.

Attackers don’t just probe and attempt to exploit systems once a month or a quarter a year; the environments they exploit are dynamic, constantly changing, and evolving.

Pretending this approach is some sort of assurance around risk is laughable.

We do all of this and call it “Continuous Monitoring” despite the fact that it is not continuous, making it a misnomer and far from actual monitoring, as we will discuss below as well.

It’s even more ridiculous when we can utilize CSP native services via APIs and automation to evaluate the compliance posture of systems and environments in near real-time.

Another problematic aspect here is while software has shifted to agile, iterative software development and delivery, with an ever-increasing velocity with the rise of AI-driven development, security has rallied around feel-good phrases such as “shift left” and “DevSecOps”, which sound good and signal virtue but in practice amount to running a bunch of noisy security scans (e.g., SAST, SCA, DAST, IaC, Container et. al) in CI/CD pipelines and dumping expansive endless spreadsheets of “findings” onto Development and Engineering teams and erecting “security gates” on teams before they can deploy to production, all while calling ourselves business enablers.

In the end, we’re business disruptors, perpetuating our longstanding reputation as the “office of no”, dragging development velocity to a grind, and just pissing off the very same peers we hope to build rapport and relationships with.

For a deeper dive into this topic, see my article “Shift Left is Starting to Rust" and my conversation on the same topic with my friends Tyler Shields and James Berthoty.

System Sampling

Due to the manual burdensome nature and methodology with which GRC has been conducted historically, it commonly involves system sampling. Rather than comprehensively looking at the full collective system, application, and software inventory of an environment and enterprise, auditors, assessors, and internal security teams generally select a sub-section of the overall inventory (e.g., sample) to assess compliance with frameworks and requirements.

Again, to previous points, this is foolish, knowing that attackers don’t just target a subset of systems, vulnerabilities, or attack vectors, and the assessment and posture of a subset of systems is not indicative of the compliance posture of an entire enterprise organization.

Leveraging APIs and context-driven runtime visibility of production environments allows for a much more comprehensive and holistic approach to audits and assessments than in the past.

Questionnaires & Self Attestations

Security questionnaires are the bane of every security practitioner and product vendor's existence, yet a trend still perpetuates today.

You know, those lengthy documents with tens and often hundreds of obscure, opaque inquiries about an organization's security posture, policies, processes, internal requirements, compliance adherence, and more.

Not only are these questionnaire exercises miserable, but they are far from reflective of an organization's actual security and compliance posture. They are frequently duplicative and need to be answered customer after customer, which is why we’re seeing the rise of Trust Centers, with T Mobile having an excellent example.

You can see their compliance with various industry frameworks, access documents relevant to audit reports and certifications, gather details about security grades from scans, insurance information, and much more, such as data about their broad deployment of phishing-resistant YubiKeys and bug bounty program.

This not only saves T Mobile from answering these questions across its countless customers and partners but also saves customers countless hours from manually requesting and reviewing this information.

Another significant challenge is that of self-attestations. While 3rd party assessed models of security (e.g., FedRAMP, for example) can be cumbersome, costly, and time-consuming, the alternative is self-attestation, or in other words, just taking the word of the vendor, rather than having a third-party assess and attest to their compliance. This is problematic because vendors are incentivized to be, let’s say, less than fully forthcoming when it comes to their security and compliance posture when deals, customers, growth, and revenue are on the line.

For an example of self-attestation gone wrong, see the DoD’s 800-171 compliance model, where Defense Industrial Base (DIB) vendors could self-attest to comply with NIST 800-171. This was followed by several highly impactful security incidents, both from a national security and economic perspective, as the sensitive intellectual property was pilfered from DoD DIB vendors such as weapons, R&D, and more by nation states such as China, often against organizations who claimed to have controls in place which we’re clearly not. This led to the Cybersecurity Maturity Model Certification (CMMC), which involves 3rd party assessments rather than self-attestations.

Framework Sprawl with a Side of Alphabet Soup

NIST CSF, RMF, ISO 27001, SOC2, PCI DSS, HIPAA, FedRAMP, GDPR, COBIT, DORA, CRA, CIS.. okay, I’ll stop there.

You would be wrong if you thought I was making an alphabet soup. I just listed some of the industry’s primary compliance frameworks by acronym. We have a framework sprawl problem, and it is only getting worse (thanks in part to our friends in the EU as they continue their path to become a “regulatory superpower”).

Vendors and organizations have to navigate a complex maze of compliance frameworks and requirements, which are often duplicative, contradictory, costly, time-consuming, and even idiotic, albeit well-intentioned.

The problem has become so severe that the U.S. Office of the National Cyber Director (ONCD) released an RFI for “Regulatory Harmonization” to address it.

Some of the key findings from that RFI are summarized below:

Organizations spend significant time and resources navigating this compliance complexity. This isn’t just the perspective of a single company; the RFI respondents included over 1,750 corporations and 65,000 individual members across large companies down to SMBs. ONCD received over 2,000 pages of comments in response to the RFI.

This is one area I think the current and previous U.S. presidential administrations could find common ground, with the current administration releasing an executive order (EO) focused on “Unleashing Prosperity Through Deregulation”.

Legacy GRC Platforms

Behind all the work of compliance frameworks, security controls, audits, assessments, authorizations, and more, the GRC systems store artifacts, scan results, compliance postures, and data to help organizations assess and assert their compliance.

The problem is that the majority of organizations still utilize legacy GRC platforms built decades ago. These platforms are bloated document repositories with little automation, API integrations, custom configurations, comprehensive dashboards and reports, and other key features to enable compliance at the speed of modern software design and development.

There are some shining stars out there looking to disrupt the status quo, such as Drata, Vanta, and others, but they are still not heavily adopted in large, complex organizations that are wedded to the antiquated GRC platforms of previous eras, such as RSA Archer, CSAM, eMASS and a slew of other relics that continue to function as analog platforms in a digital world.

The modern alternatives offer key features such as automated compliance, (real) continuous monitoring, streamlined vendor management, questionnaire automation, robust trust centers, comprehensive product integrations, and enhancements via AI, all with expansive coverage in terms of compliance frameworks.

These features are fundamental to enable much of what I discussed in the various sections of the article above and need to be adopted more broadly to enable a systemic fundamental shift in how GRC is conducted.

Workforce

While we have focused a lot of technologies such as cloud, APIs, CI/CD pipelines and automation throughout the article, no conversation of cybersecurity is complete with the most critical pillar of the People, Process & Technology triad, which is the workforce.

Due to much of the problems discussed above, a large portion of the workforce has been left behind, with little to no understanding of cloud, APIs, automation, DevOps, agile software delivery, Kubernetes, containerization, microservices and increasingly, AI, all of the very technologies they are allegedly supposed to “secure” and assess for compliance.

We need a workforce with a fundamental foundation in the technologies they are governing, assessing, auditing, and hoping to secure. The challenge is that until the way compliance is conducted is changed, they are unlikely to find themselves with the bandwidth to dig in and learn and develop, which also requires an active investment in the workforce by the employers and industry organizations they associate with as well (e.g. ISC2, ISACA, etc.)

There are aspects of the community waking up to this reality and advocating for the same concepts and changes I am discussing here, such as the GRC Engineering group, who even lay out a “GRC Engineering Manifesto”.

They are unfortunately an outlier, not the norm, of the GRC community at-large.

Closing Thoughts

Now, none of this is to tear down the value of compliance. In fact, I think compliance singularly does more to drive security than any other factor in the entire industry, as I laid out in my article “Compliance Does Equal Security - Just Not the Elimination of Risk”.

That said, the how we do compliance is fundamentally broken, in many ways, as I laid out above, and is why security gets the reputation of being theater.

If we want to bemoan the phrase “compliance doesn’t equal security”, then it is time for us to quit participating in performative arts, and bring GRC out of the dark ages.