Technical and decision debts
Technical debt is a fairly well-known concept in software engineering. It refers to the increasing cost of making changes in a software while specific issues remain unaddressed. Such issues can be overcomplicated, redundant or undocumented pieces of code, reliance on outdated or unmaintained components, use of obsolete technologies etc.
Decision debt is a more recent approach (at least to me) used to highlight the consequences of wrong or delayed decisions in addressing critical issues.
While those concepts are applicable to many fields, we will focus on CyberSecurity and see how of these debts are intrinsically linked, what is their impact for your infrastructure (aside of the obvious one: you will be breached) and how they can possibly be addressed.
Technical debt lifecycle
Where it starts
The technical debt cannot be null. Indeed, fast development of new technologies (both on offensive and defensive side) inevitably makes part of the security infrastructure "theoretically" obsolete. It doesn't necessarily mean that you are exposed and that you will be breached in the coming 24 hours. But it means that sooner or later the topic will have to be addressed.
This is where your debt counter starts.
Where it grows
This debt increases when new components are plugged into the existing infrastructure without a consistent plan for proper integration. By integration I mean this new component as a part of a global defense strategy. A technology that will enrich the prevention mechanisms already in place, not just another layer of security that will hopefully block the bad guys next time. It also implies consolidation in a unified management system, centralized collection of security events, and appropriate location in the infrastructure.
That's the technical part. On top of it, we must think of properly training the production teams on the product, and the security operations on the underlying technologies as well as on the associated security events that will be raised. Last, but not least, technical and operational documentation must be updated.
Properly executed, integration of new technology will lower the debt. On the contrary, it will bring confusion, increase complexity and eventually lower the ability to properly evaluate the security posture. In a few words: it will increase the debt.
Where it gets really expensive
The real impact is the belief that more recent technologies can substitute to those that were not deployed, thus erasing (part of) the technical debt.
One of the most relevant examples is that of sandboxing in the field of malware prevention. Sandboxing has been the first technology to consistently improve the capability to detect ransomware. Its adoption has been fast and quite massive. However, machine learning appeared shortly after in endpoint protection mechanisms, and EDR became the hype right after. Consequently, most of those who didn't yet deployed sandbox in their infrastructure skipped this step and immediately moved to EDR. Although EDR is a mandatory piece of technology to have in an infrastructure, it doesn't compensate the sandboxing.
And as new technologies pop-up (DevSecOps, XDR, deceptors, etc.) the sandbox debt remains and grows.
Decision debts
A vicious circle
Making wrong decision is a common thing, and there are few usual causes: knowledge gap, emergency, fear and hype. However, the real concern is not making mistakes, we all do, but not fixing them. Lack of feedback, misunderstanding of the mete and bounds, inaccurate evaluation of the consequences, not to mention human factors such as ego and political context, are the most common culprits.
In CyberSecurity failing to identify and fix a wrong decision usually leads to a breach. And the later it happens the more difficult it is to look back and review months or years of security design. It is then easier to find a shortcut and blame prevention technologies which have proved to be inefficient. This is the first step of a headlong rush in the wrong direction. An initial erroneous decision leading to more mistakes.
You just initiated your decision debt counter, and its increasing fast.
Altering the entire paradigm
Back to the sandboxing example. We stated that "Although EDR is a mandatory piece of technology to have in an infrastructure, it doesn't compensate the sandboxing". Time to elaborate. After training, machine-learning models accuracy should not be over 90%. Above this (symbolic but still globally consistent) value, the model is prone to overfitting and error rate (both false-positive and false-negative) increase dramatically. Combined with deterministic engines (signatures), behavioral analysis and dynamic analysis (sandboxes), it definitely provides a valuable additional layer of prevention. Alone it will misclassify 10% of its inputs.
So, you didn't deploy this sandbox, and directly leaped to this new bullet-proof machine-learning-powered EDR technology. Fine ? Not really. That was a wrong decision, and in the light of the previous explanation we clearly understand why security got breached. Another option is simply to blame EDR and machine-learning for their inefficiency and try to find another alternative, stockpiling the decision debt.
More globally, if we consider the current decision debt, we realize that it mostly affects prevention components (behavioral analysis, sandboxing, host and network-based IPS, etc.) with the consequence of increased security incidents, obviously due to gaps in the prevention strategy. The main impact is the loss of trust in the capability to detect and prevent breaches, and an irrational focus on post-intrusion reaction capabilities, grouped under the SecOps label. SIEM, SOAR, XDR, IR, Threat Intelligence are the escape gates out of the leaky-as-sieve defenses problem. Instead of filling the gaps in the defense we implicitly accept that it will be breached and focus almost entirely on reaction.
Don't get me wrong, proper SecOps is mandatory but it has to be a balance between prevention and reaction.
Closing the loop
Focusing on monitoring and reaction is usually a good short-term decision. At least, it highlights lack of integration and may be a good opportunity to address part of the initial technical debt. However, if the defenses are not properly set the SOC team will quickly be overflowed by loads of events to analyze. The less the defenses are efficient the more events and pressure the analysts will have to deal with. Triaging and reporting a "block" event is almost instantaneous. Correlating events, performing deep analysis of suspicious processes or email, or evaluating a traffic anomaly takes hours, if not days.
SOC teams' fatigue is not a myth, and the root cause is mostly a combination of technical and decision debts.
AI arrived just on time(-to-market). LLM-powered SOC components help automate most of the common security analysts' tasks, and they are very efficient. AI can provide powerful guidance in complex investigation, generate automated reports, correlate events, and recommend reaction based on collected events from any security system. No one with a little bit of experience can seriously discuss the huge advance provided by AI to SecOps.
As long as it is fed by data, such as dynamic analysis from sandboxes... Then the miracle fades away.
Conclusion
Technical debt is and will be. Technology moves fast, and the time needed to understand new concepts, design and plan proper integration, then select and deploy new components feeds this debt.
However, it can remain low as long as it is not weighted by a decision debt, which is much more difficult to get rid of. Overreaction to incidents, scapegoats, lack of knowledge and poor or biased feedback are the main factors leading to this type of debt. Easy to say, much harder to address. But at some point, it will have to be done.
You cannot escape death and taxes. Neither can you escape your technical and decision debts.
Epilog
Proofreading this article, I wondered if I didn't insist too much on this sandbox thing. Yes, it is a good example, but it remains just an example. Host and network-based IPS/IDS, honeypots and decoys, system hardening, micro-segmentation, browser isolation, external devices management, RASP, DNS filtering and many other defense technologies are often left aside, slowly but surely nurturing the debts.