Ransomware makes headlines, but the real threat is often misunderstood. It’s not a new mysterious malware or a clever exploit waiting to be found. Instead, it results from gaps in identity, accountability, and system connections. Through my decades of experience observing attacks, I’ve learned that ransomware succeeds not because of attacker’s brilliance, but because organizations treat their systems as separate parts instead of a connected system. When people, machines, networks, and third parties are loosely coordinated, and roles are unclear, ransomware slips through cracks like water flowing through unsealed pipes in a city. Seeing ransomware as a systems problem rather than just a tool problem is the first step to building effective defenses.
I have spent decades watching malware change its disguises while maintaining the same tactics. Names evolve. Payloads become more flashy. Ransomware is seen as some new top predator, but when you remove the branding and the fear, it’s still malware doing what malware always does. It gets in where it’s allowed, moves where it’s trusted, and succeeds where no one is clearly accountable. The only thing that makes ransomware different is its purpose. It isn’t there to spy or linger; it’s there to cause loud destruction that forces someone to pay.
I do not approach ransomware as a tool problem. I approach it the way an engineer looks at a failing bridge. I want to know where stress accumulates, where load paths were assumed rather than measured, and which bolts everyone assumed someone else had tightened. A company is not a single structure. It is a city of systems built over time, patched, repurposed, and occasionally abandoned. Ransomware does not attack buildings. It exploits the alleyways between them.
The metaphor I use is fire. Malware is fire. Ransomware is arson with a specific goal. You don’t stop fire by just buying a better extinguisher and hoping for the best. You stop it by removing fuel, separating rooms, enforcing building codes, and making sure someone is responsible for each area. Firefighters arrive after something has already gone wrong. Good architecture prevents a spark from turning into a disaster.
One of the hardest lessons I have learned and seen unfold more than once is that security teams will operate exactly within the limits they are given. When senior leaders declare that a certain system is out of scope or that a risk is knowingly accepted, that decision doesn’t stay neatly contained. I have seen organizations accept risk on favored platforms or politically sensitive systems, only to see ransomware enter there and spread far beyond the area that was supposedly isolated on paper. Audit scope and compliance boundaries may limit reporting and costs, but they do not stop malware. Ransomware does not recognize paperwork firewalls, executive exceptions, or carefully worded risk acceptance statements. It moves through trust and connectivity, not meeting minutes, and the damage rarely respects the lines drawn to make governance easier.
Everything begins with identity. Identity is the oxygen that ransomware needs to survive. When one identity represents many people, machines, or purposes, stolen credentials become a master key. Attackers don’t rely on clever exploits when trust is too high. One identity per person and one per system isn’t just a slogan: it’s a necessity. Each identity should have a specific purpose, exist for a limited time, and be removed cleanly when that purpose is fulfilled.
This only works when identity reflects reality rather than mythology. Human identities must be linked to systems that accurately track who is actually employed, who has changed roles, and who has left. When identity remains after employment ends, ransomware inherits a ghost workforce that never sleeps or complains. This isn’t a technical failure; it’s a failure to accept that access is based on employment, not a privilege granted forever.
I have sat in meetings where carefully crafted identity policies were not undone by engineers or security staff, but by senior HR leadership. The objections were familiar and often seemed reasonable on the surface: privacy concerns, a desire to keep IT out of certain systems, and promises that a major upgrade was coming soon, usually managed by a third party. In those moments, leadership reveals far more than any strategy document ever could. Either the organization is willing to resolve the problem fully, or it is maintained as it struggles to preserve silos and exceptions and accept the consequences. Identity doesn’t fail because the technology is lacking. It fails when leaders decide that some systems are too special to be governed.
Privilege is where many well-meaning programs fail. I assume credentials will leak. I assume people will reuse passwords, save them in files, or type them where someone can see. Designing security around perfect behavior is a fantasy. Privileged access must withstand human error, just like seat belts assume crashes will happen. Temporary access, session isolation, and visibility into actions matter far more than trusting who is doing it.
I have been criticized for insisting that privileged access management remain in place even if an engineer keeps passwords on a desktop. But that criticism misses the point. The goal isn’t to shame people for being human. It’s to ensure that when credentials are compromised, they don’t lead directly to disaster. If a stolen password can’t grant full administrative access or ongoing control, it creates friction for the attacker. Friction buys time. Time saves companies.
After witnessing it firsthand, I now believe my third parties are already compromised. That belief is not paranoia; it is justified. I saw the same outsourced engineer allow one ransomware actor into an environment, and then, days later, let a different ransomware actor in through the same access point. The vendor was inexpensive, which made them popular, but giving them keys to the privileged access system was essentially handing those keys to criminals. Removing that access required a loud and uncomfortable fight. Even after two separate ransomware incidents traced back to the same third party, senior leaders kept arguing about the impact of removing the vendor from their programs. At that point, the discussion stopped being about security or cost. It became a stark signal of which risks the organization was truly willing to accept.
Endpoints are another area where optimism often replaces realism. Many defenses assume the machine will continue to report honestly once compromised, but that assumption quickly fails in real-world scenarios. I want endpoint control that doesn’t rely on the endpoint behaving properly. If a system is lying to me, I still need the ability to isolate it, shut it down, or sever its access. Otherwise, detection just becomes a polite conversation with an attacker who has already moved on.
Networks warrant similar skepticism. Flat networks are essentially an open invitation to ransomware. Once inside, lateral movement becomes easy instead of difficult. Segmentation, especially deeper segmentation where justified by risk, functions like fire doors in a building. It doesn’t prevent the initial spark, but it prevents smoke from filling every room. When systems only communicate with what they truly need, ransomware cannot spread quietly and rapidly.
Ownership is a crucial but often overlooked control. Every system, application, and dataset requires a designated human owner, not a committee or mailing list, but an individual. Without ownership, systems tend to decay. They miss important patches, accumulate outdated access, and become hiding spots. Attackers are drawn to neglect, much like water finds cracks. Assigning ownership provides focus, and that focus can influence outcomes.
To support ownership, there must be an honest inventory. A configuration database that tells the truth is not bureaucracy; it is situational awareness. If you cannot say what exists, who owns it, and what it talks to, you are navigating in fog. Ransomware thrives in fog. Attackers map environments carefully because knowledge is power. Defenders should be able to answer the same questions faster and with more confidence.
Backups are often spoken about with reverence, as if their mere existence guarantees safety. In reality, many backups reside inside the same trust boundary as the systems they protect, making them hostages rather than lifeboats. Backups need to be isolated, safeguarded from deletion, and tested regularly. When restoration becomes routine, extortion loses its power.
Logging and telemetry serve as the organization’s memory. Without them, each incident becomes a stressful guessing game. Logs must be centralized, protected, and kept long enough to reconstruct events. This isn’t about monitoring people; it’s about understanding systems. When time is critical, clarity should come before speculation.
All of these controls form a chain, and like any chain, it breaks at its weakest link. The threat model I consider doesn’t involve genius adversaries wielding advanced tools. Instead, it involves patient criminals exploiting common lapses. Shared credentials. Forgotten servers. Excessive trust. Slow decision-making. Ransomware doesn’t require brilliance. It requires neglect.
This brings me to the back to the most common accusation I hear. That security would spend every dollar available if allowed. I reject that framing. Most of what I have described costs far less than a single serious incident. The real price is not financial. It is the loss of unchecked autonomy.
What often goes unspoken in cost discussions is that avoiding a systems-of-systems approach is not cheaper; it is quietly more expensive. When controls are added in isolation, organizations end up with tools like a garage filling with half-used equipment, each purchased to address a brief moment of anxiety and rarely removed once that fear subsides. Over time, this leads to overlapping coverage, blind spots between products, and a false sense of security that is actually riskier than having fewer, better-integrated controls. Executives tend to focus on the cost of adding new solutions while ignoring the operational burden and risk created by never integrating or removing outdated ones. Both integration and removal require effort. Although neither seems as exciting as deploying the next shiny tool, they are crucial for reducing risk. A collection of disconnected defenses does not constitute a system; it just creates noise, and ransomware is very effective at hiding in noise.
Executives often favor certain systems, such as legacy tools, special access paths, or informal arrangements that make work feel faster or more personal. A systems-of-systems approach reveals these arrangements. It requires that exceptions be identified, justified, and owned. Although this may feel like a loss, it is ultimately about gaining clarity.
Identity discipline eliminates the ability to operate invisibly. Privileged access controls diminish the comfort of unchecked power. Segmentation exposes dependencies that no one wanted to document. Ownership brings risk decisions into the open. These changes are seen as expensive because they redistribute control. Ransomware exploits the opposite situation, where control is spread out and responsibility is optional.
I have observed organizations argue passionately over prevention costs, only to write checks many times larger when under pressure. Ransoms. Downtime. Legal steps. Insurance disputes. Reputational harm. These expenses come without negotiation and all at once. The decision isn’t whether to pay but when and on whose terms. My view is shaped by repetition—across various industries and technologies—yet the story remains the same. Malware evolves, but the pattern of failure does not. An initial breach turns into lateral movement, privileges expand, backups fail, and decision-making slows. The organization painfully learns that systems do not fail in isolation.
A systems-of-systems approach accepts this reality. It treats the organization as a living structure whose parts depend on each other in meaningful ways under stress. It does not promise immunity; instead, it promises containment. It reduces the blast radius, shortens recovery time, and turns existential crises into challenging weeks rather than defining moments. Ransomware is malware with a specific purpose, which depends on trust, scale, and influence. If those dependencies break, the mission fails—not because the attacker lacks resources, but because the environment refuses to cooperate.
I do not sell products. I promote architecture, discipline, and honesty. These qualities are not glamorous. They don’t well-showcase in demos. They work because they reflect how systems truly behave and how people genuinely fail. The cost is sacrificing the comfort of exceptions. The benefit is resilience that endures when it really matters. Ultimately, this isn’t just about security as a department. It’s about shaping reality within the organization. You can choose to do so proactively, with foresight and some discomfort, or you can pay the price later in a panic when someone else sets the terms. Ransomware doesn’t care which path you take; it’s simply waiting.
About the Author
