CYBERSECURITY'S ORIGINAL SIN (Part 2/4)

---

3. The Economic Insecurity Model

The modern cybersecurity economy is not structured to eliminate insecurity. It is structured to manage it profitably.

Most software companies do not deliberately create insecure products. The problem is that products are routinely released while known classes of vulnerabilities and weak security designs still exist because the business pressure to ship, scale, and maintain market position is often stronger than the pressure to eliminate every foreseeable security problem before release. The cost of delaying a product launch is immediate and measurable to the vendor. The cost of future insecurity is delayed, probabilistic, and frequently transferred to the customer after the sale.

This dynamic is especially pronounced in dominant platforms with large market share, where customers face high switching costs and must absorb the operational burden of securing systems they did not design. In practice, organizations knowingly accept predictable security risks like weak authentication, poor logging, insecure defaults, and mature vulnerability classes such as SQL injection and cross-site scripting, because fully addressing them would slow development, increase cost, or disrupt compatibility. These are not obscure or newly discovered failure modes. They are among the oldest and most thoroughly documented vulnerability classes in modern computing.

Licensing agreements and EULA structures reinforce this model by transferring much of the operational and financial risk onto the customer, who is then expected to secure, monitor, patch, and recover systems whose underlying architecture they neither designed nor controlled. The result is not a conspiracy to preserve insecurity, but an economic structure that repeatedly rewards shipping over hardening. The industry’s history shows that meaningful security improvement is possible, for example, Microsoft’s Trustworthy Computing initiative after 2002 demonstrated that large-scale investment in secure engineering can materially improve outcomes. But even after two decades of improvement, the same vulnerability classes documented in the SANS Top 10 remain active exploitation paths today, suggesting not a failure of technical understanding but a continuing imbalance between the economic incentives to ship and the incentives to fully secure before release.

3.1 Security by MBA: The Incentive Engine

Security by MBA is the practitioner community’s term for the organizational process that repeatedly overrules secure engineering decisions in favor of schedule, market, and margin pressures. The security engineer identifies the defect: missing audit logging, shared credentials, excessive privilege, insecure defaults. The business side responds predictably: the certification does not require it, customers can configure around it, the release date cannot move, or the feature belongs in the enterprise tier.

The engineer was rarely wrong. They were overruled because organizational incentives rewarded the people who shipped faster and penalized the people who slowed releases for security. The persistence of the SANS Top 10 mistakes across twenty-five years reflects not ignorance, but systematic incentive alignment against secure design.

3.2 The Cybersecurity Industrial Complex

The modern cybersecurity ecosystem expanded into a multi-billion-dollar market whose growth became structurally tied to the persistence of operational insecurity. Every unpatched system created demand for patch management. Every phishing campaign created demand for awareness training. Every breach created demand for incident response, cyber insurance, and forensic consulting.

The industry evolved less like sanitation infrastructure designed to eliminate disease vectors and more like pharmaceutical management of chronic illness. Root-cause solutions threaten adjacent revenue streams. Symptom management scales profitably. This does not require conspiracy — it only requires incentives. Organizations optimize around the economic structures that reward them.

3.3 Security as a Premium Feature

Security capabilities were increasingly segmented into premium licensing tiers: advanced logging, privileged access management, MFA enforcement, and threat detection. This created a structural asymmetry: large enterprises could sometimes afford compensating controls; small and mid-size organizations often could not. The organizations least able to survive breaches were denied the tools most capable of preventing them.

The Storm-0558 incident demonstrated the consequence directly. Microsoft expanded default logging access only after public criticism from CISA and Congress revealed that affected organizations lacked access to the logs necessary to investigate the compromise. Basic audit capability had been withheld from base-tier products and sold separately. External pressure, not market forces, forced the feature out of the premium tier.

3.4 The Compliance Illusion

Compliance frameworks created procedural accountability without necessarily creating effective security. PCI-DSS, HIPAA, SOX, ISO 27001, and SOC 2 required organizations to demonstrate the presence of controls, not the effectiveness of those controls. A web application firewall satisfies a PCI audit whether or not the underlying application has SQL injection vulnerabilities. Annual security awareness training satisfies HIPAA whether or not employee behavior changes. Compensating controls became a recognized substitute for root-cause remediation.

Vendors benefited directly. Compliance requirements created mandatory procurement cycles: organizations had to buy something to satisfy the auditor. Whether the purchased product solved the underlying problem was not part of the audit criteria. The SANS Top 10 survived because compliance frameworks rarely required that root causes be eliminated — only that organizations demonstrate the presence of controls.

The IBM Cost of a Data Breach Report has tracked and quantified breach costs to operators annually since 2005 covering 6,485 breach events across 600 organizations per year. In twenty years of data, IBM has never measured a cost category called “software vendor cost.” The report’s four cost categories are detection and escalation, notification, post-breach response, and lost business. All accrue to the organization that deployed the software, not the organization that designed it. The compliance frameworks operators deploy address operator conduct, not vendor design decisions. The IBM model reflects the EULA cost allocation precisely: every dollar in the $4.44 million global average breach cost (2025) was borne by the breached organization. The software vendor whose product was breached bore nothing. That is not an oversight in IBM’s cost model. It is an accurate description of the accountability structure this series documents.

3.4a The Cost the EULA Transferred: Five Documented Cases

The economic imbalance created by EULA liability shields is not theoretical. Five of the most significant data security incidents between 2013 and 2020 document the cost allocation in precise financial terms. In each case, a vendor or data custodian failed to implement security measures that the SANS Top 10 Internet Threats had identified as essential since 2000. In each case, the EULA disclaimed vendor liability. In each case, the downstream cost was borne primarily by victims, regulators, and the public. In four of the five cases, the software vendor whose design decisions created the exploitable conditions paid nothing.

The ratio of customer and public cost to software vendor cost in the SolarWinds case is the starkest illustration. SolarWinds shipped an Orion platform software update containing malware to 18,000 customers. Those customers installed it because they trusted SolarWinds’ update mechanism. The estimated downstream cost across the customer base is approximately $100 billion. SolarWinds’ EULA disclaimed liability for damages caused by the software. The vendor who shipped the compromised update bore approximately one-fifteenth of one percent of the total downstream cost. The remaining 99.9% was externalized to the customers who received the update.

The Equifax case is analytically important for a different reason. Equifax is a data custodian, not a software vendor. The $575M settlement was paid by the organization that failed to patch a known vulnerability. The Apache Struts open-source component whose unpatched vulnerability was the attack vector, SANS Mistake 2, unpatched known vulnerabilities, documented as critical since 2000 was supplied by a software vendor whose license disclaimed liability. The FTC’s own complaint stated that Equifax was alerted to the Apache Struts vulnerability in March 2017 and did not patch it for four months. Despite its privacy policy stating it implemented “reasonable physical, technical and procedural safeguards,” Equifax had failed to implement the most basic of them. The software vendor whose unpatched component enabled the breach of 147 million Americans paid nothing. This is the EULA imbalance one layer removed: the data custodian absorbed the regulatory cost while the software vendor who shipped the vulnerable component remained entirely insulated.

The Capital One case adds a third layer. Amazon Web Services was named as a defendant since its cloud configuration tools were implicated in the breach and was released from all claims as part of the $190M settlement paid entirely by Capital One. The software and infrastructure vendor whose misconfigured systems enabled the breach of 98 million customers bore zero cost. Capital One, the organization that deployed AWS and trusted its security model, bore the entire $270M. The EULA chain from AWS to Capital One to 98 million customers transferred cost sequentially away from the party that designed the system and toward the parties who used and were harmed by it.

The pattern across all five cases is identical: a known SANS vulnerability class, a EULA disclaimer, and a cost allocation that placed the burden on victims rather than vendors. The total documented cost to victims, regulators, and the public across these five incidents exceeds $100 billion. The total cost to software vendors whose design decisions created the exploitable conditions is zero. That is not a coincidence. It is the EULA liability shield operating exactly as designed.

A sixth data point reinforces the pattern at scale. The IBM Cost of a Data Breach Report 2025 based on 600 organizations breached between March 2024 and February 2025, identified phishing as the most common initial attack vector at 16% of all breaches, averaging $4.8 million per incident. Supply chain compromise was second at 15%, averaging $4.91 million. Compromised credentials were third. These three vectors correspond directly to SANS Mistakes 7, 2, and 1 from the year 2000 document. IBM does not use the SANS taxonomy. It arrived at the same failure classes independently, twenty-five years later, through empirical analysis of 600 current breach events. The SANS 2000 list is not an outdated document. It is the current IBM attack vector report with different labels.

3.5 The One SANS Item That Moved

The partial progress on default credentials is instructive precisely because it is the exception. Default credential reform occurred only when three conditions aligned simultaneously: the harm became visible and undeniable; the victims were sympathetic and obviously not at fault; and regulatory pressure attached costs back to vendors. None of the nine remaining SANS items has met all three conditions simultaneously.

Mirai demonstrated that default credentials could no longer be dismissed as user error. Households had deployed devices exactly as vendors intended, yet those devices became part of one of the largest DDoS botnets in recorded history. The EULA defense collapsed under that narrative. Regulatory action followed: California’s SB-327 (2018), the UK PSTI Act, and NIST guidance created binding obligations the EULA could not override.

The EULA shield weakened only when the cost of insecurity became impossible to externalize. The SANS items that remain unfixed are those where the cost is still successfully shifted onto enterprises, SMBs, and individuals who lack the political leverage to force accountability.

The IBM 2025 data confirms this pattern with twenty years of healthcare evidence. Healthcare has been the most expensive industry for data breaches for twelve consecutive years, reaching $7.42 million per incident in 2025. Healthcare breaches take the longest to identify and contain; 279 days, more than five weeks longer than the global average. The healthcare sector cannot externalize the cost of breach the way enterprise software buyers sometimes can: the downstream harm involves patient records, clinical systems, and in OT-adjacent deployments, patient care itself. Twelve consecutive years at the top of IBM's cost table, all borne by healthcare organizations, is twelve years of documentation that the compliance frameworks operators deploy i.e., HIPAA, HITECH, SOC 2, ISO 27001, manage the exposure without eliminating the defect. The software vendors whose products are deployed in those healthcare environments are not in IBM's cost model.

3.6 Consumer OT and the Limits of Outsourced Risk

Consumer OT is the purest expression of the economic insecurity model because the victim has no capacity to compensate for insecure design. The household has no IT department, no security budget, no patch management capability, and no ability to redesign insecure architecture. Whatever the vendor ships becomes the security model.

The physical consequences are immediate and intimate. A smart lock installed by a domestic violence survivor for safety opens for someone it should not. A baby monitor accessed by an unauthorized actor speaks to a child in their room at night. A Ring camera streams footage of a family’s home to someone who was never supposed to see it. The victims are not abstractions in a forensic database. They are the people the vendor knew would buy the product, knew had no security capacity, and shipped to them anyway.

The monoculture risk compounds this. A single insecure design decision is not replicated across one facility or one enterprise deployment. It is replicated simultaneously across tens of millions of households running identical firmware with identical vulnerabilities. Mirai infected over 600,000 consumer IoT devices on the basis of a single class of error: default credentials the vendor shipped and the household had no meaningful ability to change. The cost of that decision was externalized not onto one organization with legal and technical capacity to respond, but onto millions of households with none.

Consumer OT liability increasingly resembles traditional product liability because consumers cannot reasonably mitigate the defects themselves. The legal theory is the same one applied to any consumer safety device sold to a buyer with no capacity to configure around a design defect. What distinguishes consumer OT is scale and victim class, not legal novelty.

The enterprise cybersecurity market normalized the outsourcing of digital risk to customers for decades because the consequences could usually be reframed as the customer’s responsibility to manage: breached records became failures to patch, fraud became failures to train users, and operational compromise became failures to configure systems correctly. The EULA shield reinforced this transfer by assigning the burden of insecurity to the organizations and individuals who purchased the product rather than the vendors who designed it.

Operational technology changes that equation. When insecure software can directly produce physical consequences, the customer can no longer plausibly absorb all responsibility for the outcome simply because they deployed the system. The more foreseeable and unavoidable the harm becomes, the harder it becomes to argue that the risk belongs entirely to the customer rather than the vendor that created the insecure architecture in the first place. Part 3 examines why OT environments create the first meaningful legal challenge to the outsourced-risk model.

Software vendors did not begin as villains. Early software systems were built before modern threat models, Internet-scale connectivity, and hostile-network assumptions fully existed. The problem emerged later, when the same vulnerability classes remained active and repeatedly exploited even after the industry understood the risks, documented the failure modes, and developed workable mitigation strategies. At that point, the persistence of those weaknesses became less a problem of ignorance and more a problem of incentives. The accountability structure surrounding software allowed vendors to continue shipping products with foreseeable security weaknesses while transferring most of the downstream cost onto customers. EULAs, patch-and-advisory models, shared responsibility frameworks, and compliance-centered governance all reinforced the idea that the customer was ultimately responsible for securing systems they did not design.

Continues in Part 3 of 4: