Chaos, GRC and Detection — How these new Engineering Disciplines are changing the economics of security
- Anton Horn
- 19. Dez. 2025
- 9 Min. Lesezeit
DevOps has been a huge revolution in software engineering to increase throughput and reliability of software organizations.
DevSecOps has emerged out of that shift to properly integrate security into the software engineering process. In my view we partially missed the opportunity of going further than just integrating security into DevOps but also letting DevOps practices influence how security is done overall — technically and culturally.
So while we’re still trying to catch up with DevOps practices, some new contenders are coming into the space that are changing what can be achieved with security.
These practices are:
GRC Engineering
Detection Engineering
Chaos Engineering
Overview
While DevSecOps is a capability that, depending on interpretation, is covering a lot of different cybersecurity capabilities, it is definitely not covering security end-to-end. To fill these gaps, these new disciplines are changing the security landscape.
We have GRC Engineering, bringing excel-ridden GRC disciplines into the 21st century.
Then there is Detection Engineering, applying the learnings from DevOps to the Detection & Response space.
Finally, we have Chaos Engineering, breaking running systems to challenge and validate our response and recovery capabilities.
These new engineering disciplines are essentially extending the breadth and depth of DevSecOps to span the entirety of cybersecurity domains.
As you can see, the span of control goes much further than what is generally considered under DevSecOps.
In the following sections I will break down what each discipline entails, how it changes security outcomes and give a high-level overview of relevant tooling.
GRC Engineering
GRC Engineering is the most recent addition to this group while tackling some of the oldest problems of security.
The GRC Engineering Manifesto describes it as follows:
GRC Engineering is a step-change evolution in security governance, risk, and compliance (GRC)[…]. It’s more than just “GRC + writing code.” It’s a fundamental shift in how GRC is done, one that fully embraces an engineering mindset (broadly speaking), systems thinking and design thinking, and a customer-centric focus around how best to deliver GRC outcomes.
Governance Risk and Compliance (GRC) is sometimes considered an aggregation of all the non-technical processes that make up security. This generally includes among others
managing policy documents,
assessing risks,
responding to and translating audit requests,
and sometimes even cybersecurity strategy and budgeting.
While this can sound quite boring, GRC is a critical capability that not only ensures regulatory compliance is achieved (which can often be the primary motivator to spend money on security at all) it also makes sure there is some structure to how problems are managed in security.
The only problem is that GRC is still happening 90% in spreadsheets and traditional GRC tools, which creates significant toil in all organizations, most of all in regulated sectors which tend to have higher compliance obligations.
GRC Engineering is an emerging discipline that aims to bring Governance, Risk and Compliance to the 21st century. It’s doing that not necessarily with a whole host of tools but with applied principles — which include:
Increasing automation
Improving risk measurements
Continuous assurance
Systems-thinking and stakeholder-centric UX
How GRC Engineering Changes Security Outcomes
I believe there are two main benefits to GRC Engineering which are at first glance economic but ultimately lead to improved security outcomes and a better security culture:
Reduce cost of (continuous) compliance
Reduce toil (and headache) with stakeholders
The first and best argument to adopt GRC engineering is the fact that you can keep your organization compliant with internal and external regulations with a smaller budget.
Through increased automation and improved integrations across the GRC tool stack, you not only remove some of the chaos of GRC processes, you can also continuously monitor the compliance status against your relevant compliance requirements. Especially strong adoption of cloud technology allows for continuous analysis of compliance, as well as the automated creation of evidences.
The other, no less important, effect of GRC Engineering is that you reduce effort and toil for the stakeholders of your security program. By increasing transparency, GRC user experience and automation, the entire organization will simply spend less time on compliance work. In my view this will significantly increase buy-in from all stakeholders.
It has been my experience that people generally appreciate the necessity or importance of cybersecurity. What they don’t appreciate is wasting time with it.
In most organizations all business processes need to become increasingly leaner and more streamlined by leveraging automation.
Stakeholders being slowed down by cumbersome and manual GRC processes (understandably) frustrates them to no end. Accordingly, reducing that feeling of wasted time will get you more buy-in, as people only need to spend time on security for value-adding work and not by filling out spreadsheets or answering questions that are essentially already answered in your source code.
So while you overall spend less money, not just in security teams but also with all involved stakeholders, you additionally get to spend less time on cumbersome administrative tasks and instead focus on delivering the real value of GRC work.
Tooling
While there isn’t yet a GRC Engineering Magic Quadrant / Wave / Hype cycle, there are some tools in the “Compliance Automation” space that support quite a few GRC Engineering principles.
These tools focus primarily on making the road to compliance for ISO27001, SOC2, PCI DSS etc. easier, less painful and cheaper. I believe in some cases they weaken the value of these certification; however, many startups simply need these certifications to play in the enterprise market. Accordingly, to many there is no value in spending more money on them than they have to.
Some of the key players in this market are Drata, Scrut Automation, Scytale, Secureframe, Sprinto and Vanta(I just conducted an evaluation of these solutions for a startup, reach out to me if you’d like me to send that to you).
Next up, Detection Engineering — bringing DevOps to Detection & Response.
Detection Engineering
Detection Engineering is not quite as novel as these other disciplines and you’re probably thinking that detection engineering is what has always been going on — after all, SIEMs need engineers to set them up and administer them.
But Detection Engineering is not the same as just using technology in Detection & Response.
Detection Engineering includes a lot of different capabilities to move from a static and slow detection process to a more dynamic capability that can respond faster to threats. One of the most important differences to legacy approaches is the application of DevOps practices to detection efforts. This includes among others
Writing detection as code*
Managing detection rules in version control systems
Automated testing of detection rules
(*Writing detection as code does not necessarily mean only software engineers can write new detection rules, as I understand there are also several detection engineering UI-based tools that simply manage the created rules as code in the background)
Detection Engineering extends the capabilities of the traditional detection program to include things like:
Organizational design — e.g. by understanding the organizational threat model
Context awareness — e.g. by understanding the criticality of systems
Behavior focus — e.g. by not just focusing on static Indicators of Compromise but broader definitions of malicious behavior
Automation — e.g. by continuously validating detection rules
The point of this all is not to make Detection & Response more technically complex but rather to get better results. So how is it doing that?
How Detection Engineering Changes Security Outcomes
The biggest hurdle to an effective Detection & Response capability is alert fatigue. This is inflicted on SOC analysts by having to sift through hundreds or thousands of alerts to find that needle in the haystack.
So Detection Engineering is changing that paradigm through
Better automation — to deal with low fidelity alerts and move response activities forward with less manual intervention
Continuous improvement — by streamlining the process to tune alerts and remove recurring false positives
Higher fidelity alerts — by continuously testing and validating alerts, as well as integration of better data sources
And now AI Agents are making this even faster by taking over a lot of the Level 1 analyst work, such as sending emails back and forth or adding context from other data sources.
Ultimately this will mean that Detection & Response teams will be able to develop new detections faster, have higher confidence in these detections and continuously validate that the detections are still active.
From a cost optimization perspective this transformation will likely lead to fewer humans working in low-level SOC roles, while achieving better results for Detection & Response.
Tooling
The Detection & Response tooling space is a complicated mess. I couldn’t even begin to break it down in any reasonable amount of space here. Instead, let me refer you Francis Odum’s blog, for example the article “No Vendor Consolidation In The SOC”. He created this overview here:
Chaos Engineering
Chaos Engineering is an emerging technology discipline that is often vaguely understood as breaking things in production to see what happens.
A more accurate description would be that Chaos Engineering tests assumptions about the reliability of systems. Or to quote Jason Cahoon, wo co-wrote the original Chaos Engineering Book:
A system may be engineered to tolerate failure but until you explicitly test failure conditions at scale there is always a risk that expectation and reality will not line up.
Many of the modern implementations and tools for Chaos Engineering are primarily focusing on testing the reliability of cloud-native applications — for example through shutting down running containers to test if the system recovers automatically.
While this is beneficial and a great way to test assumptions, I believe Chaos Engineering is much more transformational and could also be described as Continuous Control Validation.
In essence, you can create “experiments” (this is what tests are called in Chaos Engineering) for any type of control. A few examples:
Control: Our security systems prevent and alert on cryptomining activityExperiment: Regularly and automatically deploy a container with a cryptominer
Control: All user accounts need to be disabled within 24 hours of employees leaving the organizationExperiment: Automatically generate an alert whenever that SLA has been breached by comparing data from the HR System with Active Directory
Control: All cloud services deployed are running in multiple data centers (“Availability Zones” in AWS-lingo)Experiment: Shut down resources in one availability zone
If you’re working in a regulated industry you may think “wait, this just sounds like 2nd line of defense control testing” — and that’s exactly what it is. It is the automation of your 2nd line work but not with the goal to make auditors happy but to actually improve security and reliability of your systems.
How Chaos Engineering Changes Security Outcomes
In many cases, security breaches do not happen because there was an obvious gap in the security capabilities of an organization. They happen because a control measure was assumed to be in place but not working as intended.
Validating that these controls are actually effective is not a benefit in itself but rather a process that increases your assurance that your environment is as secure as you believe it to be.
This is again the same benefit software engineering teams got out of the DevOps revolution: It’s not about cooler and more complex technology, it’s about having greater trust in your systems to adapt to change and unexpected behavior. This increases your ability to respond to changes in your market, organization and threat landscape.
Also here, the economic differentiator comes from the acceleration of change — the more frequently I can adjust my systems to changing circumstances, the easier it is for me to win against my competition (be it market competitors or threat actors).
Tooling
The Chaos Engineering solution landscape is currently focusing heavily on running experiments in cloud-native environments. While this is a great application, I strongly believe Chaos Engineering goes far beyond just testing the reliability of your cloud applications.
Some of the cloud-native focused Chaos Engineering tools include Netflix’ Chaos Monkey (one of the OG chaos tools and open source), AWS Fault Injection Simulator, Azure Chaos Studio and LitmusChaos (available as a free community edition).
The complexity with implementing Chaos Engineering is often closer tied to the availability and analysis of data regarding the state of your systems. If you have access to everything you need, you could can also run many chaos experiments with a few Python scripts.
This has been a high-level overview on these new security engineering disciplines and where I believe they significantly impact the economics of cybersecurity, not just through automation and better tooling but also through a cultural shift that requires more integration of security into other parts of the organization.
In my view, the most important concept that each of these disciplines is bringing into security is the automation of testing.
It’s what caused the incredible acceleration of software development through the DevOps revolution. It’s not the cloud technology alone, this is just an implementation of this underlying concept. It’s first and foremost the fact that I can reliably test everything in my environment to continuously validate my assumptions are correct.
In software development this is largely achieved through the CI/CD pipeline.
In GRC Engineering this is achieved by continuously validating my compliance status. In Detection Engineering this is achieved through testing my detection logic. In Chaos Engineering this is done through breaking things and checking that my assumptions about my recovery capabilities are correct.
The common thread here is the belief that I need to test my assumptions and not just assume they remain true because they were true once (or maybe never).
Automated testing is what drove the economic shift in software development — organizations could suddenly release software 1000x faster and therefore compete completely differently.
These new security engineering disciplines can achieve the same by increasing our ability to react to threats and regulatory changes 1000x faster and therefore outpace our adversaries.
If you want to dive deeper into these topics, there are a few resources, I highly recommend:
GRC Engineering:
Follow Ayoub Fandi on LinkedIn and the GRC Engineering Podcast
Read the GRC Engineering manifesto
Detection Engineering:
Follow Anton Chuvakin of Google Cloud on LinkedIn, Medium, and the Google Cloud Security Podcast
Read “Practical Threat Detection Engineering” by Megan Roddie
Chaos Engineering:
Follow Kelly Shortridge on LinkedIn and her blog
Read Kelly’s book “Security Chaos Engineering” or the summary on her blog
DevSecOps:
Read “Agile Application Security” by Laura Bell and “Alice and Bob learn about Application Security” by Tanya Janca
Kommentare