Compliance (GRC) engineering is promising
It's time to modernize compliance
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
Someone in my network recently showed me this “manifesto” for GRC engineering, and I found it pretty interesting. For those who know me, I rarely find these security manifestos interesting because they either are marketing a product or complain about a problem without identifying the root cause. But, this isn’t that. It does a good job of describing the core problems and some guiding principles and values going forward.
I’ve written extensively in this newsletter about how having more engineering in security is key to staying ahead of attackers and reducing our threat surface, especially as more companies are adopting technology as a key part of their operations.
However, I’ve mostly focused on engineering-specific fields, such as infrastructure security, IT security, and application security. I haven’t talked as much about compliance and how engineering might help that. I’ve talked about removing compliance requirements, such as security reviews and developer security education. I am intrigued about applying engineering to compliance, and I think GRC engineering has promise. The website doesn’t provide much about potential solutions, and based on the problems and principles, I wanted to propose some.
Some problems with Legacy GRC/compliance
This is a good list of, what they describe as, “fundamental” problems. I would highly encourage people to read through each bullet point and corresponding explanation. They aren’t long, and I like how they give examples of particular situations where the current compliance requirement is outdated and how it doesn’t account for more modern security techniques that actually improve security posture. Here are just some samples, which I found particularly insightful.
For example: endlessly advocating for the “industry standard” practice of removing users’ local administrator access and implementing deny-by-default application allowlisting to protect against malware, while ignoring the obvious reality that these legacy approaches to endpoint and identity security controls would undermine organizations’ ability to innovate and thus would never be tolerated. This results in missed opportunities to explore alternative controls that are much likelier to be successfully implemented in an organization, such as decentralized peer reviewed application allowlisting and self-service just-in-time access (JITA) privilege escalation (here's an example of this for Windows).
This might work well for a company that is primarily on-premise and has a corporate perimeter. Also, it’s not clear this substantially reduces risk, but it definitely reduces productivity as users constantly have to request local admin access. The suggested alternative controls, peer-reviewed application allowlisting, and self-service JITA, are definitely shown to be better. They reduce risk without increasing friction too much. They represent the type of security that allows an organization to take calculated risks rather than being very rigid in its requirements.
Here’s another one:
For example: SOC 2 Type II audits are notorious for being inherently open ended “tests” of an organization's controls. In cases where a low cost audit provider is used, it can be akin to a student writing both the questions and answer key for an exam, providing that to the teacher, and the teacher grading their answers accordingly. Organizations have long been incentivized to pass their audits with no findings so as to not disrupt sales. Audit providers have been incentivized to be “flexible” to ensure their customers are happily provided a passing audit and keep giving them their business. Vendor due diligence teams are pressured to approve vendors and accept industry standard audit results without much, if any, additional scrutiny, treating it as a “rigorous” examination of an organization’s controls. New GRC automation products merely speed up this perversely incentivized cycle without creating stronger incentives to improve controls beyond checkbox compliance.
It feels that security certifications are now just checkboxes for sales rather than actually providing meaningful security. I’m sure that every organization that has experienced a breach had a “clean” SOC2, ISO, and HITRUST. The original purpose and spirit are lost. Originally, it was to get an independent audit of security controls so that a company buying a particular vendor could trust the security controls. Now, they are just checklists to ensure they pass the outdated vendor security review. In my mind, SOC2 doesn’t show security, or rather, it doesn’t necessarily show a positive security signal. But, SOC2 doesn’t require too much effort to obtain and “pass.” Not doing it will likely be perceived as a negative signal. If you’re not willing to spend the effort to do a simple certification like SOC2, how much effort are you actually putting into your security program? Similarly, if there is a breach, how capable is the vendor/company of responding?
The page has some good values, and my guess is that they are using these values and principles as the basis for their current and future projects. What it lacks are some concrete suggestions. I do like the idea of using engineering principles in compliance, but some basics need to change first in order to create the space for more progress.
We need to fix the current system or, at the very least, figure out what to do with the status quo before making more drastic changes. Here are some suggestions:
Suggestion 1: Modernize security certifications like SOC2
Currently, many of the requirements in SOC2 are outdated. For example, there’s a long list of requirements about datacenters that most companies ignore because they are in the cloud. Similarly, there are requirements, such as file integrity monitoring (FIM), which are just checkboxes, but it’s clear that they have outlived their usefulness — most cloud customers just have this in their cloud security toolset as part of a checkbox but not as a meaningful way to improve security.
Although auditors are becoming more flexible in adapting the controls to various environments, the controls themselves are outdated. Auditors are still constrained by outdated controls, and the audit might not provide useful information about the company’s security posture. They need to be changed to account for SaaS and cloud, especially for companies.
Suggestion 2: Eliminate security certifications
A more drastic suggestion is that we get rid of these security certifications altogether. This might be easier than we imagine. Most security certifications nowadays are used for sales and risk management. However, it’s an endless cycle. Compliance requires that security does third-party risk management, and in order to do third-party risk management properly, you need compliance and security certifications. If we stop requiring security certifications for third-party risk management and/or stop requiring third-party risk management for security certifications, we can break this loop.
Many times, this is performative as it’s unlikely a company will choose not to use a brand name product, like AWS or Snowflake because of a security issue. Whenever security surfaces risks, it’s likely the procuring party will take on these risks because they need the software. This doesn’t make the risk go away, but it just shifts the responsibility of the risk rather than trying to mitigate it. This just creates overhead rather than making any meaningful progress on security.
Finally, these security certifications represent a test period, but they only show the security controls at the time of audit. Many companies don’t do them on a regular enough cadence and will have to issue bridge letters to let them know that their “expired” security certification is still valid. However, it doesn’t show at the current moment what security controls are in place. This made sense when software releases and changes were sparse, but now it happens on a more regular cadence
We need another way to evaluate the security of a vendor in a simple way, which leads to my next suggestion.
Suggestion 3: Rely more on continuous testing and trust pages
Many of these new compliance vendors, such as Vanta and SecureFrame, help with meeting compliance requirements and make it easier for auditors to gather evidence. They are focused on ensuring the “checkboxes” and controls for frameworks like SOC2 are met rather than creating ones. However, they allow for custom controls though rarely do the users of Vanta and SecureFrame want to create them. These vendors have slim versions of trust pages. Similarly, there are dedicated trust page vendors, such as SafeBase. All these trust pages show in real-time whether a certain security control is in place.
I do think these are definitely more useful because they aren’t static reports, but they continuously show whether controls are being met. They are integrated with the appropriate SaaS tools and definitely make sense for more cloud-first companies that are regularly making changes. The current state of trust pages isn’t enough though because they don’t contain all the relevant information and integrations. There is an opportunity for companies like Vanta to be “continuous auditors” and be trusted to make independent judgments on whether certain controls are met based on the information they get from the integrations. This can be powerful and enable companies to see how security controls change over time for a vendor rather than just seeing a “yearly snapshot” of security posture. This suggestion will also reduce the amount of operational work that security teams must do for the audit.
Takeaway
The way we build software has changed, and that means the way we do compliance has to change. I do like the idea of adding more engineering principles into compliance, but instead of being a “waterfall” model like what most security certifications are like now. Whether it be continuous monitoring of controls or another method, we need to revamp the way we do security compliance so that it is perceived as more than just a sales tool.