Back to overview

    Cybersecurity Is Survival

    Howard Solomon's CSO Online piece says plainly what the industry thinks and rarely states: an organisation that still budgets security mainly as prevention is buying theatre. His most uncomfortable point lands squarely in the European scoping debate — companies work actively to avoid being seen as critical, because the label brings obligations and liability.

    Published by NEOSEC Redaktion
    nis2resilienzcisolieferkettedoracrakommentar
    Share

    "A company that collapses when prevention fails was never truly secure." — Howard Solomon, CSO Online

    Solomon opens on a contradiction the industry has been carrying for years. We have been saying for a long time that every organisation will eventually be breached. Fine — accept it. So why do so many organisations still budget, govern and rehearse as though the near-sole purpose of security were to stop the breach from happening?

    We tell the board that compromise is inevitable, then ask in the same breath for money to make the wall higher, thicker, smarter and more AI-enabled. And when the wall cracks, it turns out half the city has no food, no command structure, no working roads and nobody assigned to organise the response.

    Solomon is not arguing that prevention has stopped working. WAFs, MFA, patching discipline, hardening, segmentation, logging — all still necessary. His point is narrower and sharper: prevention no longer holds as the primary frame. The strategic question is not "can we stop the attack?" but "can the organisation keep functioning when the attack succeeds?"

    Why the argument lands differently in Europe

    Solomon writes from a US vantage point and sets both regulatory routes side by side without celebrating either.

    In Europe, resilience is becoming explicit legal obligation: DORA makes digital operational resilience binding for the financial sector, NIS2 widens the net of essential and important entities, and the Cyber Resilience Act pulls security into the whole lifecycle of products with digital elements. His dry summary: Europe, in its very European way, is saying you shall be resilient, and there shall be paperwork.

    The US route runs through disclosure, enforcement, sector rules and procurement pressure. The SEC wants material cyber risk visible to investors, CIRCIA aims to compel critical-infrastructure operators to report substantial incidents and ransom payments, CISA promotes Secure by Design pledges.

    In Germany, the European variant has landed:

    • NIS2 transposition (NIS2UmsuCG). More than 30,000 organisations fall in scope as important or essential entities. §30 requires risk management and supply-chain control; §38 places personal duties on executive management.
    • DORA. Operational resilience has been audit-relevant since January 2025. Threat-led penetration testing makes "tested incident response" concrete.
    • The Cyber Resilience Act. Suppliers to critical-infrastructure operators can no longer get by on "we patch when something turns up".

    The point that should sting in the boardroom

    Solomon's sharpest argument is not about technology but about incentives. "Critical infrastructure" is treated as though it were a natural category. It is not. It is political, legal, economic, operational — and above all fluid.

    Then comes the line worth repeating in Germany right now: companies actively work to avoid being seen as critical, because the label brings obligations, reporting duties, scrutiny, liability and expense. That is not cynicism; it is incentives doing what incentives do — rewarding ambiguity, punishing transparency, and giving everyone a reason to stay conveniently uncritical until the blast radius proves otherwise.

    Anyone who has sat through a NIS2 scoping discussion recognises the conversation. It is rarely about whether the organisation can meet the requirements. It is about whether it has to.

    The operative concept is therefore not critical infrastructure but critical dependency. A company may be insignificant to the state and indispensable to every customer that relies on it. A vendor can escape the label but not the blast radius. An unremarkable SaaS provider, identity layer, CI/CD platform, payment processor, LLM tool, MSP, open-source package or API gateway can be the point at which hundreds of organisations discover their continuity plan was a PDF bundled in optimism.

    This is why voluntary pledges are useful but insufficient. They create norms and language, but a pledge is not a control. Without evidence, enforcement, procurement consequences, customer pressure or liability it remains what Solomon calls policy theatre with potential. Better than silence. Nowhere near mandatory resilience.

    AI changes what "timely" means

    Solomon treats AI not as another asset to secure but as an accelerant poured across the whole problem. It lowers the attacker skill barrier and improves phishing, reconnaissance, exploit development, impersonation and fraud. At the same time it expands the internal attack surface: shadow AI, agents, data leakage, automated decisions, insecure integrations, and systems that can act without anyone fully understanding how far their permissions reach.

    The uncomfortable part is that defenders need AI too. Nobody is going to manually out-click machine-speed attacks with heroic analysts and good intentions. People still matter, but the role shifts from executing to deciding, validating and setting boundaries.

    His image for it is exact: if attackers move from discovery to exploitation faster than an organisation can convene a change advisory board, prevention-first chest-thumping has stopped being a security strategy.

    Application security as a resilience question

    AppSec has long been filed under prevention: find bugs, fix bugs, close exploit paths. Solomon's reframing is useful — preventive in method, resilient in strategic value. Secure-by-design systems fail less catastrophically. Sound supply-chain controls make recovery possible at all, because you know what you shipped, where it came from and whether you can trust it. Runtime visibility shows what is actually happening rather than what the architecture diagram claimed in calmer weather.

    The mature question is no longer only whether a vulnerability exists. It is how quickly the organisation can discover exposure, validate exploitability, prioritise business impact, reduce blast radius and prove the fix actually lowered risk.

    What resilience looks like in operation

    Solomon's list becomes concrete against local practice:

    1. Backup integrity beyond "we have backups". Is restoration rehearsed, and are the backups decoupled from the compromised identity provider? Most "Veeam is running" answers do not survive a serious restore test.
    2. Identity restoration. With the AD or Entra tenant compromised, the central question is not "how do we lock accounts?" but "how do we open controlled emergency access into an isolated rebuild environment?" Almost nobody has rehearsed that.
    3. Supplier fallback. §30 NIS2UmsuCG requires security obligations on suppliers, and contracts now generally carry them. What they rarely carry is what happens when the supplier fails. An exit plan with a 72-hour horizon is missing from most agreements.
    4. Crisis governance. Who decides, who communicates, who notifies the authority, who talks to the plant vendor, who has authority to shut something down before the whole environment becomes a crime scene with invoices?
    5. Knowing which services actually matter. Know the dependencies, isolate blast radius, restore from clean sources. And be able to distinguish which systems can be rebuilt cleanly from those held together by duct tape, vendor promises and one engineer everybody is quietly hoping will never retire.

    And the practice is not an annual tabletop where everyone nods politely and pretends Legal will respond in real time. It is serious: break assumptions, test recovery, challenge vendors. Incident response is an organisational muscle, not a binder.

    CISO accountability without CISO authority is theatre

    Demanding accountability from the security leader after the fire is easy. The harder question is whether that person had budget, authority, board access, engineering influence, procurement leverage and documented risk acceptance before the fire. If you want the CISO accountable for survival, the CISO has to be empowered to design for it. Otherwise accountability is staging — and the CISO is one person selected in advance to stand under the falling chandelier.

    The same holds for boards: funding prevention only and expecting resilience after failure is not governing cyber risk. It is buying denial.

    What remains

    Solomon's closing image beats any amount of castle romance: the wall is not the city, nor its citizens. If the city and its citizens cannot survive the wall falling, then perhaps the wall was never a viable strategy — just a waste of good iron.

    Cybersecurity as survivability is not a turn of phrase. It is the condition under which an organisation stays not merely compliant under NIS2 but operational when the incident lands. And the incident lands.