<script data-pm-proxy="intercept"></script><?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0"><channel><title><![CDATA[Cybersecurity Chronicles]]></title><description><![CDATA[Cyber Risk Governance for board members, C-suite executives, and risk managers. Real incidents. Real accountability. No vendor endorsements. No technical jargon. Governance intelligence for boards and executive leadership.]]></description><link>https://cybersecuritychronicles.substack.com</link><image><url>https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png</url><title>Cybersecurity Chronicles</title><link>https://cybersecuritychronicles.substack.com</link></image><generator>Substack</generator><lastBuildDate>Fri, 04 Sep 2026 18:19:32 GMT</lastBuildDate><atom:link href="/__u/cybersecuritychronicles.substack.com/feed" rel="self" type="application/rss+xml"/><copyright><![CDATA[Cybersecurity Chronicles]]></copyright><language><![CDATA[en]]></language><webMaster><![CDATA[cybersecuritychronicles@substack.com]]></webMaster><itunes:owner><itunes:email><![CDATA[cybersecuritychronicles@substack.com]]></itunes:email><itunes:name><![CDATA[Cybersecurity Chronicles]]></itunes:name></itunes:owner><itunes:author><![CDATA[Cybersecurity Chronicles]]></itunes:author><googleplay:owner><![CDATA[cybersecuritychronicles@substack.com]]></googleplay:owner><googleplay:email><![CDATA[cybersecuritychronicles@substack.com]]></googleplay:email><googleplay:author><![CDATA[Cybersecurity Chronicles]]></googleplay:author><itunes:block><![CDATA[Yes]]></itunes:block><item><title><![CDATA[DIA's insider threat hunter was the insider threat.]]></title><description><![CDATA[Edition 141: 8-K Filed as ShinyHunters claims 284 million patient records.]]></description><link>https://cybersecuritychronicles.substack.com/p/dias-insider-threat-hunter-was-the</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/dias-insider-threat-hunter-was-the</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 31 Aug 2026 19:46:22 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em><strong><span>This week we see&#8230; </span></strong><span>incidents showing how often attackers succeed by exploiting controls organizations already trust: employee identity, network separation, business continuity, and internal oversight.</span></em></p><h1>&#10024; QUICK WIN</h1><p><span>Ask security leadership one question this week:</span></p><p><em><strong><span>If someone persuaded an employee to give up their SSO credentials today, what could that person reach before another control stopped them?</span></strong></em></p><p><span>Do not settle for &#8220;they would have MFA.&#8221;</span></p><p><span>Ask which systems the account can access, what additional verification is required for sensitive data or administrative actions, and whether those safeguards have been tested.</span></p><p><span>In the McKesson incident, attackers reportedly used compromised employee identities to reach connected Salesforce and Snowflake environments. One credential can open more than one door.</span></p><h1>WEEK IN BRIEF</h1><h4><span>HEALTHCARE: Compromised Employee SSO Claimed 284M Records </span></h4><p><strong>&#128998; WHY IT MATTERS - </strong><a href="https://cybernews.com/news/mckesson-breached-shinyhunters-claims-284m-records">McKesson</a><span>, one of the largest healthcare distributors in the United States and a Fortune 7 company, detected a cybersecurity incident on August 25 and filed a Form 8-K with the SEC the following day. ShinyHunters claimed responsibility, telling BleepingComputer it used voice phishing to compromise multiple employee Okta SSO accounts, then used those accounts to access McKesson&#8217;s Salesforce and Snowflake environments. The group claims to have exfiltrated approximately one terabyte of data over four days, which it estimates at 284 million records &#8212; records, not unique individuals. The claimed data includes patient names, addresses, Social Security numbers, medical records, diagnoses, medications, terminal illness information, sexual orientation, and doctor-patient communications. ShinyHunters has demanded $55,236,150 and says McKesson has not responded. The investigation is in its early stages. McKesson has not confirmed the scope of the breach or which third-party applications were involved.</span></p><p><strong>&#129000; PROBABLE CAUSE - </strong><span>Voice phishing targeting employees with access to SSO-connected enterprise platforms. Once attackers reportedly held valid Okta credentials, they moved through Salesforce and Snowflake without needing to separately compromise either platform. The reported method is consistent with techniques previously attributed to ShinyHunters, including prior campaigns against Snowflake customer environments and Salesforce integrations.</span></p><p><strong>&#129001; PROACTIVE PREVENTION - </strong><span>Confirm that SSO-connected enterprise platforms require phishing-resistant multi-factor authentication - hardware security keys or passkeys - that cannot be bypassed by credential theft alone. For accounts that reach sensitive systems, phishing-resistant MFA is not an enhancement. It is the control that limits what a stolen credential can do.</span></p><p><strong>&#129002; REALITY CHECK - </strong><span>McKesson is not a hospital system, but its role in healthcare distribution gives it access to information that reaches far beyond one organization. It supplies prescription drugs and medical products and supports health IT across hospitals and pharmacies.</span></p><p><span>That is why the claimed scale of this incident matters even before the company confirms the affected population. Organizations that share information with McKesson or rely on its services should know what data they provide, where it is stored, and what their obligations would be if that information were exposed. A third-party breach becomes your governance problem when the third party holds your data.</span></p><h4><span>MEDTECH: Intrusion Disrupts Manufacturing, Shipping &amp; Activations</span></h4><p><strong>&#128998; WHY IT MATTERS - </strong><a href="https://www.securityweek.com/boston-scientific-still-recovering-from-cyberattack">Boston Scientific</a><span>, a global medical technology company that develops devices and therapies for cardiology, neurology, and oncology, detected a network intrusion on August 25. The attack caused a global outage that disrupted product manufacturing, customer order processing, and shipping. New remote activations for some implantable cardiac monitors were also disrupted, though existing implanted devices were not affected. CrowdStrike has been engaged to investigate. As of August 31, the company found no signs of malicious activity since the breach date, and the intrusion appears limited to some on-premises systems. No threat group has claimed responsibility. Boston Scientific expects to partially resume shipping this week but cannot provide a full restoration timeline.</span></p><p><strong>&#129000; PROBABLE CAUSE - </strong><span>Unknown. The attack affected on-premises systems. No ransomware group has claimed responsibility and no data sample has appeared publicly. The investigation is ongoing.</span></p><p><strong>&#129001; PROACTIVE PREVENTION - </strong><span>Confirm that the organization&#8217;s incident response plan specifically covers building management and operational systems &#8212; not only corporate IT networks. Ask when the plan was last exercised against a scenario combining manufacturing disruption, distribution failure, and interruption to a patient-facing service simultaneously.</span></p><p><strong>&#129002; REALITY CHECK - </strong><span>Boston Scientific restored parts of its environment and confirmed that existing implanted devices were not affected. Those facts matter. They also do not remove the planning question the incident raises.</span></p><p><span>Boston Scientific&#8217;s incident shows that a corporate-network intrusion can interrupt services that support clinical care, including the activation of certain cardiac monitors. Manufacturing, shipping, and some remote activations were disrupted at the same time. For a medical-device company, that is a continuity scenario with both operational and clinical consequences. Leadership should know whether its plans have been exercised against a combined outage of that kind &#8212; not merely a loss of office-network access.</span></p><h4><span>GOVERNMENT: ATF Called It Standalone. The Data Still Left.</span></h4><p><strong>&#128998; WHY IT MATTERS - </strong><span>Russia-linked ransomware group Qilin listed the </span><a href="https://www.techradar.com/pro/security/us-government-alcohol-and-firearms-agency-atf-declares-major-incident-after-ransomware-gang-claims-cyberattack">Bureau of Alcohol, Tobacco, Firearms and Explosives</a><span> on its dark web site this week. ATF confirmed the breach via press release. The compromised system is described as a standalone system that operates separately from the ATF enterprise network. A spokesperson confirmed it contained information about targets of ATF investigations. ATF disconnected the affected systems, engaged cybersecurity experts, and notified the Department of Justice. DOJ designated the event a &#8220;major incident&#8221; under federal guidelines. Qilin is the same group behind the 2024 Synnovis pathology attack in the UK that disrupted blood transfusions at major London hospitals.</span></p><p><strong>&#129000; PROBABLE CAUSE - </strong><span>Not yet publicly disclosed. The system&#8217;s standalone characterization may suggest it had internet exposure or a network connection that was not fully accounted for, though that remains conditional on information not yet released. Qilin does not require a sophisticated entry point.</span></p><p><strong>&#129001; PROACTIVE PREVENTION - </strong><span>Ask for a current inventory of systems in your environment described as standalone or isolated from the main network. For each one, confirm that the isolation has been technically validated rather than assumed, and that monitoring coverage applies to those systems as well as the enterprise network.</span></p><p><strong>&#129002; REALITY CHECK - </strong><span>The word standalone describes the architecture. It does not describe the risk.</span></p><p><span>A system classified as separate from the enterprise network but holding sensitive operational data is not automatically lower risk. It may carry less monitoring precisely because of its classification. The ATF incident is a useful prompt to ask which systems in your environment are described as isolated, and whether that description reflects a tested technical state or an administrative category that has not been revisited.</span></p><h4><span>GOVERNMENT: DIA&#8217;s Insider Threat Hunter Was the Insider Threat</span></h4><p><strong>&#128998; WHY IT MATTERS - </strong><a href="https://cybernews.com/news/us-insider-threat-hunter-admits-leaking-state-secrets">Nathan Vilas Laatsch</a><span>, a civilian IT specialist employed within the Defense Intelligence Agency&#8217;s Insider Threat Division, pleaded guilty to attempting to pass classified US information to a foreign government. Laatsch hand-copied classified material, saved it to a USB drive, and left it at a public park in Virginia. The FBI retrieved the drive and posed as the foreign contact for several weeks before arresting him. Sentencing is set for January 27. Prosecutors do not plan to seek death or life imprisonment. Laatsch wrote in messages to the undercover agent that he understood how DIA investigations were opened and believed he could avoid triggering one.</span></p><p><strong>&#129000; PROBABLE CAUSE - </strong><span>Ideological motivation combined with privileged access and, apparently, insufficient behavioral monitoring of employees in sensitive oversight roles. Laatsch worked within the unit responsible for detecting this category of activity, which gave him both familiarity with detection methods and access to classified material.</span></p><p><strong>&#129001; PROACTIVE PREVENTION - </strong><span>Confirm that behavioral monitoring of employees in security, compliance, audit, and risk functions is subject to independent oversight &#8212; not administered or exempted by those same functions. Privileged access to detection systems creates a specific risk: the person who understands how monitoring works may also know how to avoid triggering it.</span></p><p><strong>&#129002; REALITY CHECK - </strong><span>Laatsch worked in the DIA unit responsible for insider-threat detection. That fact prompts a direct question: who independently reviews the people who operate the organization&#8217;s most sensitive monitoring and investigative functions?</span></p><p><span>An insider-threat program cannot depend on self-exemption. Employees in security, compliance, audit, investigations, and risk may need heightened scrutiny because they hold privileged access and understand how internal controls operate. Investigators detected the attempted disclosure in this case. That is encouraging. It does not remove the need for independent oversight of the people closest to the controls.</span></p><h4><span>UPDATE: Beacon Breach Reaches Burns Heritage Charity. 1,500 UK Nonprofits Remain Affected.</span></h4><p><strong>&#128998; WHY IT MATTERS - </strong><span>The Robert Burns Ellisland Trust, which operates the farm near Dumfries where Burns wrote Auld Lang Syne and Tam o&#8217; Shanter, has warned supporters that membership and contact details may have been exposed in the </span><a href="https://tfn.scot/news/burns-charity-caught-up-in-mass-cyberattack">Beacon CRM breach</a><span> first reported in Edition 138. Beacon CRM is used by an estimated 1,500 UK charities. Other confirmed victims this week include the Scottish Refugee Council, Scottish Women&#8217;s Institutes, Cyrenians, Sheffield Hospitals Charity, and English National Ballet. Beacon has confirmed hackers copied its customer database and says the incident has been contained.</span></p><p><strong>&#129000; PROBABLE CAUSE - </strong><span>Consistent with original reporting: compromised credentials used to access and copy Beacon&#8217;s customer database backups. No new technical details have been disclosed.</span></p><p><strong>&#129001; PROACTIVE PREVENTION - </strong><span>During the next vendor review, ask whether contracts require notice to your organization before the vendor makes a public announcement, and whether that timeline is realistic given how quickly these incidents move. If the contract is silent on notification sequence, the vendor may control what your stakeholders hear first.</span></p><p><strong>&#129002; REALITY CHECK - </strong><span>Beacon&#8217;s earlier warning, that customers should assume data may have been taken even if the company could not confirm exactly what left, now has more weight as affected organizations continue to come forward.</span></p><p><span>The practical issue is not only that a vendor can expose data from many unrelated organizations at once. It is that the vendor may control the first public disclosure. When that happens, the affected organization may be left responding to stakeholders before it has been able to establish what occurred, what information was involved, or what it needs to say.</span></p><div><hr></div><h1>EXPERT PERSPECTIVE</h1><h3>RISK RETENTION</h3><h4><span>The FBI Counted 3,611 Ransomware Reports and $3 Billion in BEC Losses. Most Budgets Still Favor the First Number.</span></h4><p><strong><span>EXECUTIVE SUMMARY - </span></strong><span>The FBI Internet Crime Complaint Center&#8217;s </span><a href="https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf">2025 annual report</a><span> records 1,008,597 complaints and $20.877 billion in reported losses, a 26 percent increase over the prior year and the first time the figure has crossed $20 billion. Buried inside the crime type tables is a ratio that deserves a place in every risk register: ransomware accounted for 3,611 complaints and $32.3 million in reported losses, while business email compromise accounted for 24,768 complaints and $3.05 billion. IC3 is a voluntary complaint database, not a forensic accounting of national cybercrime cost, and the report is candid about what that omits. Read with that caveat applied, it remains the closest available public record of where money actually left American organizations last year.</span></p><h4><span>HIGHLIGHTS</span></h4><ol><li><p><strong>Ransomware Is 0.15 Percent of Reported Losses. </strong><span>Of $20.877 billion in total reported losses, ransomware accounted for $32.3 million. Business email compromise accounted for ninety-four times that amount. The FBI states directly that ransomware loss figures exclude lost business, time, wages, files, equipment, and third-party remediation, and that some victims report no dollar figure at all, which keeps the total artificially low. The complaint counts carry no such caveat. On volume alone, organizations filed nearly seven BEC reports for every ransomware report.</span></p></li><li><p><strong>The Vendors Getting Hit Are the Ones Holding the Documents. </strong><span>IC3 received more than 1,400 ransomware complaints from organizations outside the sixteen critical infrastructure sectors. Legal services accounted for 18 percent, contracting services 17 percent, and engineering and architectural firms 10 percent. These are the outside counsel, general contractors, and design firms that hold privileged material and project files for organizations that never appear in the complaint data themselves.</span></p></li><li><p><strong>The AI Numbers Measure Recognition, Not Attribution. </strong><span>IC3 logged 22,364 complaints referencing artificial intelligence with $893 million in losses. That descriptor is applied when a complainant mentions AI, not when forensic analysis confirms it. The report notes that many victims do not recognize the extent of AI involvement. Every AI threat figure now circulating in board materials rests on whether defrauded people understood what was done to them.</span></p></li><li><p><strong>Recovery Is a Capability, Not an Outcome. </strong><span>The IC3 Recovery Asset Team initiated 3,900 kill chain actions covering $1.16 billion in attempted theft and froze $679 million, a 58 percent success rate. Nearly half the money in a process purpose-built for speed was not recovered. The variable that separates the two halves is how quickly the victim organization acted.</span></p></li></ol><h4><span>INSIGHT</span></h4><p><span>IC3&#8217;s annual report is not a complete measure of cybercrime. It relies on voluntary reports, and the FBI is clear that several loss categories, particularly ransomware-related disruption, recovery costs, and lost productivity, are not fully captured.</span></p><p><span>Even with those limits, the report is useful because it shows where victims reported money leaving their organizations. The contrast between ransomware and business email compromise is difficult to ignore. Ransomware produced 3,611 complaints and $32.3 million in reported direct losses. BEC produced 24,768 complaints and $3.05 billion in reported losses. The ransomware total is incomplete and does not capture the full operational cost of an attack. Even so, the reported BEC-loss gap is too large to ignore when organizations decide where to invest in prevention and response.</span></p><p><span>Ransomware can be catastrophic. It can halt operations, disrupt clinical care, expose data, and generate substantial recovery costs. But many organizations have concentrated their resilience investments there while treating fraudulent payments as a finance-process issue rather than an enterprise-loss scenario.</span></p><p><span>That leaves an important gap. Backup immutability and recovery testing are essential ransomware controls. They do not stop an employee from acting on a fraudulent payment instruction. Many of the controls that prevent wire fraud sit in finance and operations, not in the security architecture: callback verification for banking changes, dual authorization, and a team empowered to pause a wire before it leaves. Those controls are usually owned by finance and operations rather than security architecture. They still need to be connected to the organization&#8217;s broader fraud-response and incident-escalation process.</span></p><p><span>The recovery data reinforces the point. A 58 percent freeze rate across $1.16 billion shows how much recovery depends on speed, preparedness, and coordination among the victim organization, its bank, and law enforcement. Finance, treasury, legal, security, and the bank need a rehearsed process for a suspected fraudulent transfer &#8212; one that identifies who contacts the bank, who approves a recall request, what information must be supplied, and how quickly the organization can act.</span></p><p><span>For the next audit-committee meeting, ask who owns the first hour after a suspected fraudulent wire. That person should be able to name the bank contact, the internal decision-maker, the documentation needed for a recall, and the last time the procedure was practiced. If finance must first notify security, wait for triage, and then determine who contacts the bank, valuable recovery time has already been lost.</span></p><p><em><span>Source: 2025 IC3 Annual Report. Federal Bureau of Investigation, Internet Crime Complaint Center. Based on 1,008,597 complaints voluntarily submitted to IC3.gov during calendar year 2025.</span></em></p><div><hr></div><h1>COMMENT ON THIS EDITION</h1><p><span>The FBI&#8217;s IC3 report shows BEC producing ninety-four times the reported losses of ransomware. </span></p><p><em><strong><span>Does your organization have a rehearsed process for the first hour after a suspected fraudulent wire, who calls the bank, who approves the recall, who has authority to stop the payment? </span></strong></em></p><p><span>Reply and tell me where your financial-fraud response program stands.</span></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://substack.com/@cybersecuritychronicles/note/p-213549142&quot;,&quot;text&quot;:&quot;Leave a comment&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/substack.com/@cybersecuritychronicles/note/p-213549142"><span>Leave a comment</span></a></p><div><hr></div><p><strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a><br></strong>Author &amp; Editor, <em>Cyber Risk Governance Insights;</em> Vice President, <a href="https://www.linkedin.com/company/netswitch-technology-management/">Netswitch, Inc.</a></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h2><span>Get It Done.</span></h2><p><span>This week, attackers reportedly used an employee&#8217;s identity to reach sensitive data at McKesson. A DIA employee assigned to insider-threat work admitted trying to disclose classified information. ATF reported a major incident involving a system described as separate from its enterprise network. Boston Scientific is still recovering from an intrusion that disrupted manufacturing, shipping, and some cardiac-monitor activations.</span></p><p><span>These are different incidents, but each tests an assumption organizations commonly make: that identity controls, specialized security teams, isolated systems, or network segmentation will work as intended when pressure arrives.</span></p><p><span>Choose one of those assumptions this week and test it. Do not ask whether the control exists. Ask whether it has been tested against the failure scenario it is supposed to prevent.</span></p><p><span>Netswitch offers a complimentary cyber risk governance health check that starts exactly there. No questionnaire theater. A real conversation about what your posture looks like and what it should.</span></p><p><span>Schedule a conversation with </span><a href="https://www.netswitch.net">Netswitch</a><span>.</span></p><p><span>Connect with the </span><a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a><span> on LinkedIn &#8212; 6,200+ board members, CISOs, and compliance leaders who read this newsletter for the same reason you do.</span></p><p><span>Attend the next Cyber Risk Governance Live event. One hour. No vendor pitches. Real governance conversations with people who have the same problems you do.</span></p><p><span>Reach out to </span><a href="https://netswitch.net/">Netswitch, Inc.</a><span> today.</span></p><div><hr></div><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Your incident response plan vs. ransomware reality.]]></title><description><![CDATA[Edition 140: Iran. Winnipeg. LockBit. AnMed confirmed.]]></description><link>https://cybersecuritychronicles.substack.com/p/your-incident-response-plan-vs-ransomware</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/your-incident-response-plan-vs-ransomware</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 24 Aug 2026 18:03:03 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em><strong>This week we see</strong>&#8230; that the attack surface your governance framework was built for is no longer the attack surface you have.</em></p><h1>&#10024; QUICK WIN</h1><p><span>You&#8217;ll want to ask your facilities and physical security teams this question:</span></p><p><em><strong><span>If ransomware took down our building management systems, what is the manual fallback plan, and who is responsible for executing it?</span></strong></em></p><p><span>Most incident response plans assume the IT network is the problem. The Health Sciences Centre in Winnipeg learned that building infrastructure is also in scope.</span></p><h1>WEEK IN BRIEF</h1><h4><span>CRITICAL INFRA: Power Plant Downed for 4 Days.</span></h4><p><strong>&#128998; WHY IT MATTERS - </strong><span>A small UK gas power plant was shut down for four days in July following a cyberattack attributed to </span><a href="https://www.itpro.com/security/cyber-attacks/iranian-cyber-attack-on-uk-power-plant-should-concern-every-organization-responsible-for-keeping-this-country-running">Iranian-linked hackers</a><span>. The attack is believed to be the first of its kind on British energy infrastructure. The UK government has contacted chief executives of power companies and issued written guidance on protective measures following the incident. The NCSC has confirmed the UK is facing increased threats from Iranian-backed cyber groups. The attack coincides with the ongoing Iran-linked campaign against US water systems that has now affected more than a dozen states, suggesting coordinated or opportunistic targeting of Western critical infrastructure across multiple sectors and geographies simultaneously.</span></p><p><strong>&#129000; PROBABLE CAUSE - </strong><span>The entry point has not been publicly disclosed, and the reported Iran link has not been formally confirmed by the UK government. The incident involved a small-scale generator, which may indicate opportunistic targeting of a less-resourced facility or exposure in internet-connected operational technology. At this stage, anything more specific would be speculation.</span></p><p><strong>&#129001; PROACTIVE PREVENTION - </strong><span>Leadership should confirm why any operational technology (OT) systems can be reached from the public internet and when that exposure was last reviewed. For any PLC, remote-management interface, or similar device, ask whether it can be isolated from the internet, protected by strong authentication, and accessed only through a controlled remote-access path.</span></p><p><strong>&#129002; REALITY CHECK - </strong><span>A four-day power-plant shutdown is what happens when a cyber incident reaches the physical world. </span>Reports do not indicate a customer power outage<span>, but that should not make the event feel less serious. A smaller facility went offline, and government officials then had to brief energy executives on what to do next. That is usually a sign the sector is learning something after the fact that it should have worked through beforehand.</span></p><h4><span>HEALTHCARE: Attack Hit the Access, Elevators, &amp; Ventilation</span></h4><p><strong>&#128998; WHY IT MATTERS - </strong><span>Manitoba&#8217;s </span><a href="https://www.ctvnews.ca/winnipeg/article/manitobas-largest-hospital-still-working-to-recover-from-ransomware-attack/">Health Sciences Centre</a>, <span>the province&#8217;s largest hospital, confirmed that ransomware discovered on August 10 hit facility maintenance systems including central monitoring of heating, ventilation, and cooling equipment, door access controls, and elevators. The security office closed and the hospital was unable to issue or update ID access cards. CancerCare Manitoba was also affected. Patient care was not disrupted and Shared Health&#8217;s initial review found no evidence that personal health or financial data was accessed. Recovery work was ongoing as of August 17, a week after discovery. The incident reached systems that most incident response plans treat as out of scope.</span></p><p><strong>&#129000; PROBABLE CAUSE - </strong><span>The entry point and attack path have not been disclosed. The known fact is that ransomware affected facility maintenance systems, including central HVAC monitoring and door access controls, while clinical services remained available. That could reflect segmentation that limited the incident, but it could also reflect the attacker&#8217;s scope or priorities.</span></p><p><strong>&#129001; PROACTIVE PREVENTION - </strong><span>Leadership should ascertain if the incident response plan (IRP) covers building management system failure, not only IT-network failure. It should identify who can operate HVAC, access controls, and elevators manually, how long those workarounds can be sustained, and when facilities management joins the incident response team.</span></p><p><strong>&#129002; REALITY CHECK - </strong><span>A hospital can keep patient records available and still have a serious operational problem. If staff cannot issue access cards, centrally monitor ventilation, or manage elevator access, the facility is working with a very different set of constraints. Shared Health kept clinical operations running, and that is important. But this should prompt a simple question: does the organization treat building systems as part of cyber resilience, or does it assume that is somebody else&#8217;s problem?</span></p><h4><span>TECHNOLOGY: Millions of Records from F500 Azure Tenants Claimed.</span></h4><p><strong>&#128998; WHY IT MATTERS - </strong><span>Two scale incidents this week from </span><a href="https://www.helpnetsecurity.com/2026/08/23/week-in-review-records-allegedly-stolen-from-azure-tenants-medusa-ransomware-hits-500-orgs/">Help Net Security</a><span>. A threat actor known as &#8220;TheHatman&#8221; claims to have obtained millions of employee records from the Azure environments of several Fortune 500 companies, including McDonald&#8217;s, Vodafone, Kyndryl, and Tata Consultancy Services, according to Hudson Rock. No data sample has been verified. Separately, a joint FBI, CISA, and HHS advisory confirmed that Medusa ransomware has breached more than 500 organizations since June 2021, with the update drawing on FBI investigations as recent as April 2026. Medusa targets schools, healthcare providers, and critical infrastructure. Both stories reflect different dimensions of the same governance challenge: the attack surface of cloud infrastructure and the sustained operational capacity of ransomware groups.</span></p><p><strong>&#129000; PROBABLE CAUSE - </strong><span>The Azure claims have not been independently verified, and no technical method has been confirmed. They should be treated cautiously. The Medusa advisory, however, documents a long-running pattern that includes phishing, stolen credentials, and misuse of legitimate remote-access tools. Across more than 500 victims, the recurring issue is not one flaw. It is weak control over identity and remote access.</span></p><p><strong>&#129001; PROACTIVE PREVENTION - </strong><span>For cloud identity, leadership should ask whether guest accounts, cross-tenant access settings, third-party application permissions, and privileged identities are reviewed regularly. For remote access, ask whether VPN, remote desktop, and administrative access require phishing-resistant MFA, not just basic MFA.</span></p><p><strong>&#129002; REALITY CHECK - </strong><span>Five hundred victims over five years is not a short-lived campaign. It is an operating model. Medusa keeps finding organizations with exposed remote access, weak authentication, or identity controls that have not kept up with the way people actually work. The advisory is useful, but the more useful question is whether anything in your remote-access posture has materially changed since the last ransomware warning. If not, then reading the advisory does not accomplish much.</span></p><h4><span>FINANCIAL SERVICES: Bank Gets 4 Sept Deadline, Investigation Underway</span></h4><p><strong>&#128998; WHY IT MATTERS - </strong><span>LockBit posted </span><a href="https://cybernews.com/security/lockbit-hackers-claim-us-bank-data-breach/">US Bank</a><span>, one of America&#8217;s five largest financial institutions, on its dark web leak site on August 21 with a countdown clock set to expire September 4. The group has not provided a data sample, making independent verification impossible at this stage. US Bank is aware of the claim and investigating. LockBit was disrupted by international law enforcement in February 2024, which seized servers, domain infrastructure, and decryption keys. The group returned in September 2025 with a fifth iteration of its malware. If confirmed, a breach at US Bank would carry significant regulatory implications under federal banking cybersecurity requirements and disclosure obligations.</span></p><p><strong>&#129000; PROBABLE CAUSE - </strong><span>Unknown. No entry point has been confirmed, and LockBit has not provided a data sample. Claims without samples can be part of an extortion tactic, so the allegation should be taken seriously without being treated as established fact.</span></p><p><strong>&#129001; PROACTIVE PREVENTION - </strong><span>Financial institutions should have a documented process for assessing dark-web claims, whether verified or unverified. That process should define who validates the claim, when counsel, the insurer, and executive leadership are engaged, and what criteria would trigger regulatory notification or external communications.</span></p><p><strong>&#129002; REALITY CHECK - </strong><span>The larger lesson is not the US Bank claim itself. It is that LockBit, like </span><strong><span>T-1000</span></strong><span>, the liquid metal assassin in Terminator 2, returned after a major law-enforcement disruption and resumed operations. That should temper any assumption that taking down a group&#8217;s infrastructure makes the threat disappear. Law enforcement action can impose real costs on attackers. It does not remove the need for organizations to defend themselves against the next version of the same operation.</span></p><h4><span>UPDATE: Data Was Stolen. Governance Failure Now Has a Timeline.</span></h4><p><strong>&#128998; WHY IT MATTERS - </strong><a href="https://www.foxcarolina.com/2026/08/21/anmed-confirms-data-stolen-during-july-cybersecurity-incident/">AnMed</a><span> confirmed on August 21 that cybercriminals obtained information during the July 26 ransomware attack. A detailed review is underway to determine what information was involved and who may be affected. The hospital is warning patients that attackers may contact them directly, publish information, or make public claims. AnMed CEO William Kenley issued a public apology acknowledging &#8220;the concern, frustration and disruption the incident has caused.&#8221; The confirmation arrives 26 days after the attack, and 10 days after The Gentlemen had already posted over 100 extortion messages on AnMed&#8217;s own Facebook page claiming 6 terabytes of stolen data, including HIV-positive patient records, suicide registries, and sexual assault victim data.</span></p><p><strong>&#129000; PROBABLE CAUSE - </strong><span>The entry point remains unconfirmed. The Gentlemen group has been associated with EDR-evasion techniques and custom ransomware, but those reported methods do not establish how AnMed was compromised. The new fact this week is that data exfiltration is confirmed. The incident is no longer only an operational disruption. It now requires a formal privacy, legal, and notification assessment.</span></p><p><strong>&#129001; PROACTIVE PREVENTION - </strong><span>Healthcare organizations should confirm that their breach-response process distinguishes between an operational outage and suspected or confirmed data theft. Once data access is confirmed, the organization needs a clear process for legal review, HIPAA risk assessment, state-law analysis, patient communications, and regulatory notification where required.</span></p><p><strong><span>&#129002; REALITY CHECK - </span></strong><span>Last week, Cyber Risk Governance Insights noted that the attackers used AnMed&#8217;s own Facebook page to make extortion claims directly to patients and the public before the hospital had confirmed whether data was taken. This week, AnMed confirmed that cybercriminals did obtain information. That does not validate every claim the attackers made about the data, but it does validate the underlying concern. The board question is whether the organization can investigate and communicate quickly enough that patients do not hear the first version of the story from the attacker.</span></p><div><hr></div><blockquote><p><strong><span>The stories above show where ransomware lands. The Expert Perspective this week examines who owns the risk when it reaches connected buildings and operations.</span></strong></p></blockquote><div><hr></div><h1>EXPERT PERSPECTIVE</h1><h3><span>RISK TRANSFER</span></h3><p><span>The Foundation for Defense of Democracies published </span><a href="https://www.fdd.org/analysis/2026/08/04/insurers-should-require-a-cyber-safety-standard-of-care-for-the-built-environment/"><span>an argument that insurers should require evidence of reasonable cyber-engineering care as a condition of underwriting</span></a><span> buildings, water systems, hospitals, transit, and industrial facilities. Dr. Georgianna Shea, chief technologist at FDD&#8217;s Center on Cyber and Technology Innovation, writes that responsibility for cyber safety in the built environment remains largely unassigned within the engineering profession, which leaves insurers with no consistent professional role to hold accountable and no common documentation package to evaluate. </span></p><p><span>The piece emerged from the 2026 Cyber Safety Summit in Washington, organized by Lucian Niemeyer of Building Cyber Security, which brought engineers, infrastructure owners, insurers, and academics together around establishing a standard of care. The recommendation is specific: a dedicated insurance working group should build underwriting questions, premium-credit criteria, professional liability expectations, policy language, and claims documentation standards for cyber-physical risk. Worth reading before your next capital project review.</span></p><h2>Highlights</h2><p><span>1. </span><strong><span>Three Engineers Sign. The Fourth Does Not Exist. </span></strong><span>A structural engineer is accountable for the building&#8217;s structure. An electrical engineer is accountable for electrical safety. A fire protection engineer is accountable for life-safety systems. There is often no recognized cyber safety engineer of record accountable for ensuring connected systems are designed, documented, commissioned, and maintained with cyber safety in mind. That absence is not a gap in coverage. It is a gap in professional accountability, and it sits directly beneath the owner.</span></p><p><span>2. </span><strong><span>The Claim May Not Be Filed as Cyber. </span></strong><span>A compromise of building automation, access control, HVAC, elevators, medical equipment, or industrial process control may never present as a privacy breach. Shea notes it can arrive as a property claim, a casualty claim, a business interruption claim, a technology errors-and-omissions claim, a professional liability claim, or several at once. Organizations that bought a cyber policy and consider the exposure transferred have transferred one of six possible dispute categories.</span></p><p><span>3. </span><strong><span>Eight Records Written Backward From a Claim File. </span></strong><span>The evidence list Shea proposes reads less like a compliance checklist and more like a discovery request. Consequence assessment, technology registry, design documentation, verified remote and vendor access controls, cyber commissioning records, a deficiency log with documented owner acceptance of residual risk, owner handoff materials, and periodic recertification. Note what the sixth item requires: a signature from the owner on the risks they chose not to fix.</span></p><p><span>4. </span><strong><span>Safety Standards Have Always Arrived After the Fire. </span></strong><span>Standards of care developed historically when society decided that risk in the built environment could no longer be left to voluntary mitigation by designers. Fires, collapses, and explosions produced codes, licensing, inspection regimes, and liability norms. Cyber-physical systems present the same three preconditions now: foreseeable hazards, repeatable failure modes, and catastrophic potential.</span></p><h2>Insight</h2><p><span>Read as an insurance article, this is a modest proposal about underwriting questions.</span></p><p><span>Read as a liability document, it names an exposure that currently has no owner and explains why it lands on the one party that cannot refuse it.</span></p><p><span>Every other engineering discipline on a construction project routes liability to a licensed professional who insures against that liability and prices it into the fee. That structure is why an owner can point to a stamped drawing when something fails.</span></p><p><span>Cyber safety in connected systems has no stamp and no fee, which means there is no transfer. The exposure does not evaporate for want of a signature. It stays with the facility owner, and with whoever approved the capital spend and signed off on project acceptance.</span></p><p><span>Shea&#8217;s eight records were written backward from a question no project team plans for. Commissioning records show that a system passed on the day it was tested. What decides a claim is whether the control was operating on the day the pumps stopped, and nobody gets to choose that second date. An organization can assemble evidence for a date it selects. The attacker selects the other one.</span></p><p><span>The sixth record is the one to watch. A deficiency log documenting unresolved gaps, corrective actions, and owner acceptance of residual risk is good engineering practice and a defensible artifact in a claim, right up until you check whose name is on the acceptance.</span></p><p><a href="https://www.linkedin.com/in/krishanthakker/"><span>Krishan Thakker</span></a><span>, an executive legal counsel who advises organizations through post-breach regulatory investigations, describes the pattern he encounters most often: boards review curated summaries while legacy vulnerabilities and operational exceptions stay below the reporting line. In his words, the forensic record then shows the board was entirely insulated from the actual, accepted risks that caused the incident. Apply that to a facilities director signing off on a known exception in a building automation system. The document does not establish that the board was uninformed. It establishes that the organization knew in writing before the loss.</span></p><p><span>The instinct will be to hand this to the CISO. The CISO cannot own it alone.</span></p><p><span>These are engineering, procurement, and facilities artifacts produced during design and commissioning by people who report to real estate or operations or a general contractor. Most security organizations hold no authority over specification language in a building automation contract and have no seat at project acceptance. A cyber safety requirement that lives only in the security program and never in the procurement documents produces nothing an adjuster can read.</span></p><p><span>So, take the next capital project that reaches the board for approval and ask whether a named individual is accountable for the cyber safety of its connected systems, and whether that name appears on a document. Then pull the deficiency log from the last facility the organization accepted and find out who signed it. If the answer is that security reviewed it, you have an opinion. You do not have an engineer of record.</span></p><p><em><span>Source: &#8220;</span><a href="https://www.fdd.org/analysis/2026/08/04/insurers-should-require-a-cyber-safety-standard-of-care-for-the-built-environment/"><span>Insurers Should Require a Cyber Safety Standard of Care for the Built Environment.</span></a><span>&#8221; </span><a href="https://www.linkedin.com/in/drgeorgeshea/https://www.linkedin.com/in/drgeorgeshea/"><span>Dr. Georgianna Shea</span></a><span> and </span><a href="https://www.linkedin.com/in/stephenthursby/"><span>Stephen Thursby</span></a><span>, Foundation for Defense of Democracies, Center on Cyber and Technology Innovation. Published August 4, 2026.</span></em></p><div><hr></div><h1>COMMENT ON THIS EDITION</h1><p><span>The Health Sciences Centre incident extends the ransomware governance conversation beyond IT into physical building systems. </span></p><p><em><strong><span>Does your organization&#8217;s incident response plan address OT and building infrastructure failure, or does it focus primarily on data and network recovery? </span></strong></em></p><p><strong><span>Reply </span></strong><span>and tell me where your planning stops.</span></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://substack.com/@cybersecuritychronicles/note/p-212577402&quot;,&quot;text&quot;:&quot;Leave a comment&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/substack.com/@cybersecuritychronicles/note/p-212577402"><span>Leave a comment</span></a></p><div><hr></div><p><strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a><br></strong>Author &amp; Editor, <em>Cyber Risk Governance Insights;</em> Vice President, <a href="https://www.linkedin.com/company/netswitch-technology-management/">Netswitch, Inc.</a></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h3><span>Get It Done.</span></h3><p><span>Iranian hackers shut down a UK power plant for four days. Ransomware reached the door access controls and ventilation at Manitoba&#8217;s largest hospital. Medusa has been running the same playbook against 500 organizations for five years. LockBit returned from law enforcement disruption and is already targeting Fortune 500 financial institutions. AnMed patients were warned by their attacker before they were warned by their hospital.</span></p><p><span>Each incident this week represents a governance framework that was not built for the environment it encountered. If your incident response plan, OT security posture, or ransomware decision framework has not been reviewed against the current threat environment, that review is overdue.</span></p><p><span>Netswitch offers a complimentary cyber risk governance health check that starts exactly there. No questionnaire theater. A real conversation about what your posture looks like and what it should.</span></p><p><span>Schedule a conversation with </span><a href="https://www.netswitch.net">Netswitch</a><span>.</span></p><p><span>Connect with the </span><a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a><span> on LinkedIn &#8212; 6,200+ board members, CISOs, and compliance leaders who read this newsletter for the same reason you do.</span></p><p><span>Attend the next Cyber Risk Governance Live event. One hour. No vendor pitches. Real governance conversations with people who have the same problems you do.</span></p><p><span>Reach out to </span><a href="https://netswitch.net/">Netswitch, Inc.</a><span> today.</span></p><div><hr></div><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Shell. Philips. GE. Fiserv. One vulnerability. Fifty breaches.]]></title><description><![CDATA[Edition 139: Three ransom decisions. No documented framework before the attacker called.]]></description><link>https://cybersecuritychronicles.substack.com/p/shell-philips-ge-fiserv-one-vulnerability</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/shell-philips-ge-fiserv-one-vulnerability</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 17 Aug 2026 18:49:40 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em><strong> This week we see</strong>&#8230; the same underlying unanswered question: what decisions does your organization have documented for the moment the attacker has already won the first exchange?</em></p><h1>&#10024; QUICK WIN</h1><p><span>This week, ask your legal counsel and your CISO to sit down together and answer these questions:</span></p><p><em><strong><span>If an attacker contacts the organization with a ransom demand, who has the authority to decide whether to pay? Have we established a decision-making process? And does our cyber policy influence, or effectively control, that outcome? </span></strong></em></p><p><span>If the three of them aren&#8217;t answered consistently, the organization doesn&#8217;t have a ransomware response posture. It has assumptions.</span></p><h1>WEEK IN BRIEF</h1><h3><span>ENERGY - Entry Point Was One Shared Software Vendor</span></h3><p><strong>&#128998; WHY IT MATTERS: </strong><span>Russia-linked ransomware group Cl0p claims to have breached nearly 50 companies, including </span><a href="https://www.dutchnews.nl/2026/08/shell-and-philips-hit-by-russian-ransomware-attack/">Shell</a><span> and </span><a href="https://www.dutchnews.nl/2026/08/shell-and-philips-hit-by-russian-ransomware-attack/">Philips</a><span>, along with General Electric and payments firm Fiserv, through a vulnerability in Windchill, engineering document management software made by PTC that was patched on June 17. From Shell, Cl0p claims 89 GB of material, including technical drawings, facility images, and project plans. From Philips, 13.5 GB of diagrams and blueprints. Both companies are investigating. Shell has said it is &#8220;aware of a possible incident.&#8221; Philips confirmed it contained &#8220;an attempted cybersecurity compromise of a specific enterprise server.&#8221; Cl0p has likely already extorted an estimated $500 million from prior campaigns.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>A Windchill vulnerability disclosed and patched in June is the likely entry point, although Shell and Philips have not confirmed it. The campaign fits Cl0p&#8217;s familiar approach: exploit a widely used enterprise platform before customers complete patching.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Leadership should ask whether critical vendor patch notices have a defined maximum time from release to deployment, especially for internet-adjacent systems. Do not accept &#8220;IT handles it&#8221; as the answer. Ask for the actual average number of days.</span></p><p><strong>&#129002; REALITY CHECK: </strong><span>When one software platform becomes the entry point for dozens of breaches, it is no longer just a patching problem. It is a dependency problem. Shell and Philips did not create the vulnerability, but they were still exposed because they depended on the same platform as everyone else. The question for leadership is not simply whether IT applied the patch. It is whether the organization knows which shared platforms support its most sensitive operations and how quickly critical fixes actually make it into production.</span></p><h3><span>HEALTHCARE - 15M, Largest Breach of 2026 for Industry</span></h3><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://healthexec.com/topics/health-it/cybersecurity/15m-patients-impacted-largest-healthcare-data-breach-2026">DentaQuest</a><span>, the second-largest dental benefits administrator in the United States serving 32 million beneficiaries, confirmed a cyberattack between May 17 and May 20 that exposed data on exactly 15 million patients, the largest healthcare data breach recorded in 2026. The compromised data includes names, addresses, Social Security numbers, Medicaid and Medicare IDs, diagnoses, treatment details, and billing information. DentaQuest issued a public notice in July without disclosing patient numbers. HHS confirmed the scale when its breach tracker was updated. ShinyHunters posted a notice on a dark web leak site in June claiming a 234 GB trove. DentaQuest has not confirmed whether ransomware was deployed or responded to ShinyHunters&#8217; claims.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>The entry point has not been confirmed. If ShinyHunters was involved, credential compromise or a third-party integration are plausible paths consistent with the group&#8217;s known methods.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Run a tabletop exercise for quiet data theft, not just ransomware disruption. Ask whether monitoring would detect large-scale data exfiltration before a threat actor posts about it publicly.</span></p><p><strong>&#129002; REALITY CHECK: </strong><span>The breach began in May. Patients were notified in July. The full scale only became visible after HHS updated its breach tracker. That is a long time for 15 million people to be unaware that highly sensitive health and identity data may have been taken. Healthcare organizations often focus on keeping clinical operations running, and rightly so. But a quiet data theft can sit undetected while the business appears to be operating normally. The question for compliance leadership is whether the incident response plan can identify and assess that kind of event before a threat actor posts about it publicly.</span></p><h3><span>GOVERNMENT: Day 7, Council Weighing the Demand</span></h3><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.techtimes.com/articles/324247/20260813/suisun-city-ransomware-attack-30000-residents-locked-out-council-weighs-extortion-demand.htm">Suisun City</a><span>, California entered its seventh day of a ransomware shutdown with City Hall closed, ten departments offline, and its elected council convening in emergency closed session to deliberate over a criminal extortion demand. The amount has not been disclosed. The city&#8217;s two-person IT team, supported by a contracted third party, is working on recovery. What began as a 911 and dispatch disruption has now extended to Planning, Building, Housing, Water, Finance, HR, Public Works, and Administration. Councilmember Washington summarized the situation plainly: &#8216;Our records are hostage.&#8217; The city is not alone; 5 other U.S. municipalities reported ransomware attacks the same week. The decision being made in that closed session, pay or refuse, has a documented governance history. Baltimore refused a $76,000 demand and spent $18 million on recovery. Atlanta refused a $51,000 demand and spent approximately $17 million. Paying restores operations faster but funds the next attack.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>The entry point has not been disclosed. Small municipalities with limited internal security resources and high-pressure public services are frequent ransomware targets.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Before an incident, define who can authorize a ransom decision, what role the insurer has, and how legal counsel and law enforcement participate. If that process is not documented, it will be built under pressure.</span></p><p><strong><span>&#129002;</span> REALITY CHECK: </strong>The difficult part of ransomware is not deciding that it is serious. Everyone understands that by day seven, when departments are offline and records are inaccessible. The difficult part is deciding who has authority to act, what role the insurer has, how legal and law-enforcement guidance is weighed, and what happens if the organization refuses to pay. That framework should exist before the attacker sets a deadline. If it has to be assembled during a closed emergency session, the organization is already making one of its most consequential decisions with less structure than it should have.</p><h3><span>HEALTHCARE: Attackers Threaten Patients Directly</span></h3><p><strong><span>&#128998;</span> WHY IT MATTERS: </strong><a href="https://healthexec.com/topics/health-it/cybersecurity/gentlemen-ransomware-gang-takes-over-hospital-facebook-after-cyberattack">AnMed</a><span>, a nonprofit health system serving South Carolina and Georgia, was hit by ransomware on July 26. As of August 12, some systems remain offline. The Gentlemen ransomware group, one of the most active threat actors targeting healthcare in 2026, known for custom EDR-evasion tooling, published over 100 posts on AnMed&#8217;s Facebook page on August 11, claiming to have exfiltrated 6 terabytes of data including HIV-positive patient records, suicide registries, sexual assault and rape victim data, mental health records, abortion records, genetic data, and patient Social Security numbers. The message pointed readers to a payment address. AnMed confirmed the posts were unauthorized, stated the claims have not been verified, and disabled its Facebook access. Elective procedures were postponed, and medical imaging and some specialty services were shut down during the incident.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>Not yet confirmed. The Gentlemen&#8217;s documented attack methodology includes sophisticated EDR-kill techniques and custom ransomware that has evolved across multiple iterations.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Treat social media administrator access as a privileged credential. Confirm that access is controlled, reviewed, and can be revoked quickly during an incident.</span></p><p><strong>&#129002; REALITY CHECK: </strong><span>The attackers did more than claim they stole data. They used AnMed&#8217;s own Facebook page to put the threat directly in front of patients and the public. That turns a ransomware event into a communication crisis very quickly. Most organizations have plans for notifying patients after an incident. Far fewer have a plan for the attacker taking control of a channel the organization normally uses to communicate. The question is whether crisis communications, social media administration, and privileged-access management are being treated as part of the same resilience program.</span></p><h3><span>TECHNOLOGY: 280 GB Leaked After Demanded Ransom Refused</span></h3><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.bleepingcomputer.com/news/security/ringcentral-data-breach-exposed-info-of-16-million-accounts/">RingCentral</a><span>, a cloud communications platform used by over 600,000 businesses for calls, messaging, and voicemail, disclosed in July that a sophisticated social engineering campaign compromised its systems. ShinyHunters claimed responsibility on July 27, stating it had stolen 623 gigabytes of data. After RingCentral declined to pay, ShinyHunters published a compressed 280-gigabyte archive on its dark web leak site. HaveIBeenPwned confirmed the leaked data contained records for 1.6 million accounts, including names, email addresses, phone numbers, and physical addresses. RingCentral says the core platform was not impacted and that customers not contacted directly are unaffected.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong>The exact technique has not been disclosed. Social engineering, including vishing or IT-helpdesk impersonation, is consistent with ShinyHunters&#8217; documented methods.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Confirm that administrators of cloud communications platforms receive the same anti-phishing and social-engineering training as employees handling financial or patient data. These platforms hold contact data for the entire customer base.</span></p><p><strong>&#129002; REALITY CHECK: </strong><span>RingCentral refused to pay, and the data was published. That does not tell us whether refusing was the right decision. It tells us what the consequences can look like when an extortion demand is rejected. The real governance question is whether the company had a documented process for making that decision before the attacker made contact. Paying or refusing will always carry risk. What should not be improvised is who decides, what facts they need, and how the organization prepares for the outcome either way.</span></p><div><hr></div><h1><span>TERMINOLOGY: Ransom Decision Framework</span></h1><p><span>A ransom decision should not be made for the first time during an active attack. It affects operations, legal exposure, insurance coverage, customer communications, and the organization&#8217;s ability to recover.</span></p><p><span>Before an incident, leadership should agree on:</span></p><ol><li><p><span>who has authority to decide,</span></p></li><li><p><span>what role the cyber insurer and legal counsel will play, and</span></p></li><li><p><span>what facts must be available before payment is considered</span></p></li></ol><p><span>Those facts typically include the recovery timeline, whether data was stolen, applicable sanctions risk, the insurer&#8217;s coverage position, and the operational impact of continued downtime.</span></p><p>Paying does not guarantee recovery, data destruction, or an end to extortion. Refusing may lead to data publication and a longer disruption. Neither option is risk-free. The point is to have the decision process, authority, and key advisers defined before the attacker sets the deadline.</p><p><span>The framework should be reviewed with counsel, the insurer, and executive leadership before an incident, then tested at least annually. This week&#8217;s cases at Suisun City, AnMed, and RingCentral are reminders that once the attacker creates the deadline, it is too late to start deciding how decisions will be made.</span></p><div><hr></div><h1>EXPERT PERSPECTIVE</h1><h2><span>RISK RETENTION</span></h2><h3><span>Ransomware Victims Learned AI Changed the Attack During the Breach.</span></h3><p><strong><span>Executive Summary:</span></strong><span> </span><a href="https://www.proofpoint.com/us/resources/threat-reports/ai-era-ransomware-report"><span>Proofpoint&#8217;s 2026 AI-Era Ransomware Report</span></a><span>, released July 22, 2026, surveyed 953 cybersecurity professionals across 12 countries and 20 industries and produced a finding that belongs in front of every board that has approved an AI security investment: 65 percent of organizations affected by ransomware said AI increased the effectiveness of the attack against them. They did not discover this before the attack. They discovered it during one. Only 9 percent reported no evidence of AI use at all. Proofpoint is a commercial security vendor whose products address the vulnerabilities this report identifies; the data below is assessed independently of those commercial recommendations. The governance implication the report surfaces but does not fully develop is the more consequential one: organizations are measuring their AI defensive capability after a breach, not before. The board that cannot answer whether its AI security controls have been tested against AI-enhanced attacks has the same information gap that 65 percent of ransomware victims had before they became statistics in this report.</span></p><h3><span>Highlights</span></h3><ol><li><p><strong><span>AI Made It Harder to Recognize.</span></strong><span><br>Malicious links triggered 47% of incidents. Malicious attachments accounted for 46%. Phishing and email-based social engineering were the primary entry vector in 34% of cases. Nothing new there. What changed is the persuasiveness. AI didn&#8217;t create a new attack category, as we see 40% of organizations said employees didn&#8217;t suspect the attack because it appeared authentic. AI has made it harder for trained employees to identify content as malicious.</span></p></li><li><p><strong><span>Payment Is Not Resolution. It Is an Opening Bid.</span></strong><span><br>54% of affected organizations paid a ransom. Of those, 37% faced a second extortion demand. That is a one-in-three chance that paying resolves nothing and extends the negotiation under worse conditions. The board that approved ransom payment as its incident response posture approved a strategy with a documented 37 percent immediate failure rate on its own terms. Two-thirds of organizations confirmed data was stolen before ransomware was deployed. Once data has left the environment, paying for decryption does not recover it, does not prevent its sale, and does not prevent a subsequent demand built on the threat of disclosure.</span></p></li><li><p><strong><span>Organizations Most Likely to Pay Are the Most Targeted.</span></strong><span><br>Respondents in the USA reported the highest AI-enhanced attack effectiveness at 81%, the highest ransom payment rate at 93%, and confirmed sensitive data theft at 60%. The US numbers are a signal about threat actor prioritization and about the gap between organizational investment in security and organizational resilience against the specific threat AI-enhanced attacks represent.</span></p></li></ol><h3><span>Insight</span></h3><p><span>The Proofpoint report changes the board&#8217;s conversation about AI security in one important way.</span></p><p><span>The issue is no longer only whether the organization is investing in AI-related security tools or which vendors it trusts. The more practical question is whether its existing controls have been tested against attacks that use AI to make phishing, impersonation, and extortion more effective.</span></p><p><span>That distinction matters because many organizations will say they have phishing training, email security, endpoint tools, and an incident response plan. All of those may be true. But if the controls were designed and tested against older attack patterns, leadership should be honest about what has and has not been validated. The 65 percent figure is a warning that many organizations learned the answer during an actual ransomware event.</span></p><p><span>The payment data creates a separate governance issue. More than half of affected organizations paid a ransom, and 37% of those payers reported a second extortion demand. Payment may still be part of an incident response decision in some circumstances. But it should never be treated as a clean ending. Boards and executives need to understand that payment can lead to a second negotiation, continued pressure, and ongoing data-disclosure risk even if systems are restored.</span></p><p><span>The broader pattern is difficult to ignore. Taiwan documented AI agents operating across government systems before detection. Kimsuky showed that a capable actor can build local AI infrastructure outside commercial provider visibility. Proofpoint&#8217;s report adds the business impact: organizations are already reporting that AI made ransomware attacks more effective.</span></p><p><span>The board question is straightforward.</span></p><p><span>Can security leadership show how the organization has tested its controls against AI-enhanced phishing, social engineering, credential theft, and data extortion?</span></p><p><span>If the answer is limited to vendor assurances, general awareness training, or a list of purchased tools, the organization may be relying on preparation it has not actually validated.<br><br>The ransomware data shows the business impact. The next section addresses where the capability is coming from and how quickly it is spreading.</span></p><h2>RISK REDUCTION</h2><h3>AI-Powered Attacks Are No Longer a Theoretical Capability</h3><p><strong>Executive Summary:</strong> In a two-week window in July and August 2026, two separate and unrelated nation-state threat programs were publicly confirmed to be using AI for offensive cyber operations against different targets, using different tools, attributed to different governments. First, security researchers at Genians documented <a href="https://www.techradar.com/pro/security/experts-warn-north-korean-hackers-are-increasingly-using-ai-to-build-smarter-and-more-devious-cyberattacks">Kimsuky</a>, the North Korean state-sponsored threat group, systematically building a local AI capability development environment designed to execute attacks at scale without generating a cloud footprint. Then, Taiwan&#8217;s Ministry of Digital Affairs confirmed that AI agents had been used in a <a href="https://www.theguardian.com/technology/2026/aug/13/taiwan-ai-assisted-cyber-attacks-overseas">coordinated attack</a> against government agencies in July, mapping 21 government systems, cracking 85 user accounts, and extracting 2,500 personnel records over four days. The Taiwan attack is suspected but unconfirmed as China-linked. Kimsuky is North Korean. These are separate programs, separate actors, and separate geopolitical agendas. The governance implication of that separation is the finding most board briefings will miss: AI-powered nation-state attacks are no longer a single adversary&#8217;s emerging capability. They are operational across multiple distinct threat populations simultaneously. The board whose security posture was calibrated against one actor&#8217;s capability has not priced the full exposure.</p><h3>Highlights</h3><ol><li><p><strong>Two Separate Actors. Same Two-Week Window. No Coordination Required.</strong><br>The significance of Kimsuky and the Taiwan attack appearing in the same two-week period is not that they are connected. It is that they are not. Two independent nation-state programs, operating under different governments and pursuing different objectives, arrived at the same operational conclusion: AI can make attacks faster, more scalable, and harder to detect.</p></li><li><p><strong>Infrastructure Was Built, Now Showing What It Produces.</strong><br>Genians documented Kimsuky&#8217;s AI capability development environment: local large language models on actor-controlled infrastructure, retrieval-augmented generation tools configured against actor-controlled documents, AI agent development frameworks, and external API integration libraries. The key point is that the activity can run without a cloud footprint for commercial providers to monitor.</p><p>Taiwan&#8217;s reported intrusion shows what that kind of capability can produce in operation: eight AI agents working across four days, mapping government systems, accessing user accounts, and extracting personnel records before Taiwan&#8217;s monitoring units identified unusual activity. One story describes the environment. The other shows the operational result. Both are now public.</p></li><li><p><strong>Detection Gap Is the Governance Finding.</strong><br>Taiwan&#8217;s National Institute of Cyber Security began issuing alerts on July 20, after the operation was already underway. Dream&#8217;s subsequent findings contributed to Taiwan&#8217;s public disclosure on August 13. By that point, the agents had reportedly mapped 21 government systems, accessed 85 user accounts, and extracted 2,500 personnel records.</p><p>This is what AI-enabled, multi-agent activity can look like when it encounters detection architecture designed around slower, human-led attack patterns.</p></li></ol><h3>Insight</h3><p>Last week <a href="/__u/cybersecuritychronicles.substack.com/p/north-korea-built-an-ai-lab-your">this newsletter documented Kimsuky&#8217;s AI capability development program</a>. This week, the Taiwan attack confirms what that class of capability looks like in operation, executed by a separate actor, against a different target, under a different geopolitical mandate. The editorial sequence was not planned.</p><p>The convergence of these two findings in the same two-week window is the story.</p><p>When independent actors converge on the same operational approach without coordination, the approach has become standard practice rather than a specialized capability. The governance model that treats AI-powered nation-state attacks as a sophisticated, rare, single-actor threat is now structurally out of date. The question for boards is not whether their organization is a nation-state target. It is whether their detection architecture was designed for an environment where multiple distinct threat populations are independently running AI-powered attack programs, and whether the security investment approved against last year&#8217;s threat landscape is adequate for the one that two separate government agencies confirmed this week.</p><p>The detection gap the Taiwan attack documented is where the clearest governance accountability lives. Taiwan&#8217;s monitoring identified unusual activity on July 20. Dream&#8217;s external investigation established that eight AI agents had been operating across 21 government systems before that date. The record that a forensic investigator, claims adjuster, or regulatory examiner will eventually review is not the alert that fired on July 20. It is the evidence of what the monitoring architecture was designed to catch, and whether that design was calibrated for the operational tempo the attack actually ran. An AI agent executing at machine speed does not wait for the weekly security review or the quarterly board briefing to complete its reconnaissance. The evidence either exists with a timestamp showing the board understood the detection gap and addressed it, or it does not. The date that evidence needs to carry is not chosen by the board. It is chosen by whoever runs the next operation.</p><p>The Kimsuky finding adds the dimension that makes the Taiwan attack a planning event rather than a news story. If local AI capability development programs can be built and operated entirely outside the cloud infrastructure that commercial detection tools monitor, then the detection gap the Taiwan attack exposed is not unique to Taiwan&#8217;s monitoring architecture. It is structural to any detection approach that assumes AI-powered attacks will leave a footprint in commercial AI provider systems. Organizations whose monitoring is optimized for cloud-based AI activity are running detection that sophisticated actors have already demonstrated they can exit simply by moving their infrastructure off the cloud.</p><p><span>The board mandate these two findings together produce is a capability question with a specific deliverable: before the next security investment is approved, ask security leadership to demonstrate, not describe, demonstrate, what the organization&#8217;s detection architecture would observe if eight AI agents began operating simultaneously across its most sensitive systems today. </span></p><p><span>The answer to that question is either a tested, documented detection capability or a gap that the two-week record this newsletter just established confirms is not theoretical</span>.</p><div><hr></div><h1>COMMENT ON THIS EDITION</h1><p><span>Three organizations this week faced a ransom payment decision in real time &#8212; Suisun City, AnMed, and RingCentral. </span></p><p><strong><span>Does your organization have a pre-documented framework for that decision, including the insurer&#8217;s role in the outcome? </span></strong></p><p><em><strong>Reply and tell me where your organization stands on ransomware response governance.</strong></em></p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://substack.com/@cybersecuritychronicles/note/p-211456812&quot;,&quot;text&quot;:&quot;Leave a comment&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/substack.com/@cybersecuritychronicles/note/p-211456812"><span>Leave a comment</span></a></p><div><hr></div><p><strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a><br></strong>Author &amp; Editor, <em>Cyber Risk Governance Insights;</em> Vice President, <a href="https://www.linkedin.com/company/netswitch-technology-management/">Netswitch, Inc.</a></p><h2></h2><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><p><strong><span>Get It Done.</span></strong></p><p><span>Shell and Philips are investigating 50 simultaneous breaches through one shared vendor vulnerability. Fifteen million dental patients are getting letters months after attackers spent three days inside DentaQuest. Suisun City&#8217;s council is weighing a ransom in a closed session with no public decision framework. AnMed&#8217;s patients received extortion threats through the hospital&#8217;s own Facebook page. RingCentral refused to pay, and 280 gigabytes went public.</span></p><p><span>Every incident this week points to the same gap: </span><strong><span>organizations discovering what they had not decided, documented, or governed in time to matter.</span></strong><span> If your organization&#8217;s ransomware response framework, vendor patch governance, and crisis communication plan have not been reviewed recently, those are the conversations to have before the next incident makes them urgent.</span></p><p><span>Netswitch offers a complimentary cyber risk governance health check that starts exactly there. No questionnaire theater. A real conversation about what your posture looks like and what it should.</span></p><p><span>Schedule a conversation with </span><a href="https://www.netswitch.net">Netswitch</a><span>.</span></p><p><span>Connect with the </span><a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a><span> on LinkedIn &#8212; 6,200+ board members, CISOs, and compliance leaders who read this newsletter for the same reason you do.</span></p><p><span>Attend the next Cyber Risk Governance Live event. One hour. No vendor pitches. Real governance conversations with people who have the same problems you do.</span></p><p><span>Reach out to </span><a href="https://netswitch.net/">Netswitch, Inc.</a><span> today.</span></p><div><hr></div><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[North Korea built an AI lab your security tools cannot see.]]></title><description><![CDATA[Edition 138: A thousand charities: assume everything was taken]]></description><link>https://cybersecuritychronicles.substack.com/p/north-korea-built-an-ai-lab-your</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/north-korea-built-an-ai-lab-your</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 10 Aug 2026 19:27:37 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em><strong> his week we see</strong>&#8230; <span>that attacks are escalating. It is that the gap between what organizations say they have and what holds up under pressure keeps widening.</span></em></p><h1>&#10024; QUICK WIN</h1><p><span>Tell your IT leadership to pick one critical vendor you depend on, and ask two questions: </span></p><p><span>&#8220;When was the last security assessment of that vendor, and what is the organization&#8217;s contractual right to notification if that vendor is breached?</span></p><p><span>If either answer is unclear, the vendor relationship carries more risk than you have priced.</span></p><h1>WEEK IN BRIEF</h1><h3><span>GOVERNMENT: Ransomware Attack Took Down 911</span></h3><p><strong>&#128998; WHY IT MATTERS </strong><span>At 5:45 a.m. on August 7, malicious software compromised the IT systems of </span><a href="https://www.latimes.com/california/story/2026-08-09/cyberattack-forces-emergency-declaration-in-suisun-city-calif">Suisun City</a><span>, a Northern California municipality of 30,000 people. By Saturday morning, the city council had convened a special session and unanimously declared a state of emergency. The attack took down 911 routing, police and fire dispatch, and all city services and records. To contain the threat and preserve evidence for a federal investigation, the city shut down its entire IT network. Dispatchers moved to the Solano County backup center. The FBI, DHS, and the California Office of Emergency Services are all involved. No threat group has claimed responsibility. The city was able to maintain all public safety services through the outage, but the governance consequence is clear: a ransomware event shut down the communications infrastructure of an entire municipality before sunrise.</span></p><p><strong>&#129000; PROBABLE CAUSE </strong><span>Not yet disclosed. Municipal government networks are frequently underfunded relative to their attack surface, and small cities often rely on a single contracted IT provider rather than a dedicated security operations function. The most likely entry point is either unpatched remote access infrastructure or a compromised credential; both are common in municipal incidents of this type.</span></p><p><strong>&#129001; PROACTIVE PREVENTION </strong><span>Leadership should ask whether the organization has a documented continuity plan for critical communications, including 911 and emergency dispatch, that does not depend on the primary IT network being available. If the answer is that 911 routing is tied to the same systems that hold city records and billing, those should be architecturally separated. The plan should be tested, not assumed.</span></p><p><strong>&#129002; REALITY CHECK </strong><span>A city does not declare a state of emergency because the incident is inconvenient. It does it because normal operating procedures are no longer enough. That is the part worth paying attention to here. By the time the council is in an emergency session and dispatch has moved to a county backup center, the contingency plan is already being tested in public. The question to ask before that happens is simple: if the network went down tonight, what would still work, who would run it, and how long could the city operate that way</span></p><h3><span>CISA: Ransomware Gangs Are Exploiting VPN Flaws</span></h3><p><strong>&#128998; WHY IT MATTERS </strong><a href="https://www.bleepingcomputer.com/news/security/cisa-sonicwall-sma1000-flaws-now-exploited-by-ransomware-gangs/">CISA</a><span> confirmed this week that ransomware gangs are actively exploiting two vulnerabilities in the SonicWall SMA1000 secure remote access gateway, including a maximum-severity SSRF flaw. SonicWall released patches in mid-July. CISA added both flaws to its Known Exploited Vulnerabilities catalog and ordered federal agencies to patch within three days. The underlying flaws were first exploited as zero-days in June &#8212; weeks before SonicWall disclosed them &#8212; by a threat actor that deployed custom malware on vulnerable VPN appliances. More than 380 SMA1000 instances remain exposed on the internet. SonicWall has a documented history of exploitation: nation-state actors, ransomware groups, and a state-sponsored breach of its own systems are all part of the recent record.</span></p><p><strong>&#129000; PROBABLE CAUSE </strong><span>Unpatched remote access infrastructure in enterprise environments. The pattern here is structural: SonicWall VPN appliances are deployed as perimeter devices, treated as stable infrastructure, and often left without systematic firmware review. Patches become available, and nothing compels the organization to apply them before the window closes.</span></p><p><strong>&#129001; PROACTIVE PREVENTION </strong><span>Leadership should ask IT to confirm the current firmware version running on every SonicWall device on the network and the date the last patch was applied. If either answer takes more than 24 hours to produce, the patch management program does not cover the network perimeter. That is where this week&#8217;s ransomware attacks are entering.</span></p><p><strong>&#129002; REALITY CHECK </strong><span>The patches were available. The vulnerabilities were on CISA&#8217;s Known Exploited Vulnerabilities list. Federal agencies had three days to act. Private organizations did not have that same deadline, which is exactly where governance comes in. The question is not whether the CISO knew the patches existed. It is whether the organization has a process that gets critical perimeter patches from release to deployment before a ransomware group proves the window was still open.</span></p><h3><span>RETAIL: 3 Employees. One Social Engineering Attack.</span></h3><p><strong>&#128998; WHY IT MATTERS </strong><a href="https://www.securityweek.com/corporate-data-stolen-in-levi-strauss-cyberattack/">Levi Strauss</a><span> disclosed on August 7 that a social engineering attack accessed the company-issued computers of three employees and exfiltrated corporate data. The company filed a Form 8-K with the SEC, confirming the theft while stating it does not believe the incident will have a material impact and that no customer data appears to have been stolen. Business operations were not disrupted. Some reports to UNC6671, the vishing group responsible for recent attacks on hedge funds and other corporate targets, link the attack. Levi Strauss has not confirmed attribution. The investigation is ongoing.</span></p><p><strong>&#129000; PROBABLE CAUSE </strong><span>Voice phishing or a related social engineering technique that convinced employees to provide access or take an action that gave the attacker a foothold on their devices. UNC6671 is known for sophisticated impersonation of IT helpdesks and executives to get employees to install remote access tools. The entry point was human, not technical.</span></p><p><strong>&#129001; PROACTIVE PREVENTION </strong><span>Leadership should ask whether the organization has a verification protocol that employees can use when they receive an unexpected request for remote access, password reset, or IT support &#8212; particularly if that request arrives by phone. The question is not whether employees have been trained. It is whether they have a tested, simple way to confirm the request is legitimate before complying.</span></p><p><strong>&#129002; REALITY CHECK </strong><span>Three employees were enough to turn a social engineering attack into a public-company disclosure. That should give leadership pause. Social engineering is not going away, and even well-trained people can be caught by a convincing call at the wrong moment. The issue is what happens next. Has the organization practiced how it will investigate, make materiality decisions, communicate with investors, and keep the business moving while the facts are still coming in? Most have rehearsed the phishing training. Far fewer have rehearsed the disclosure decision.</span></p><p><strong><span>CRITICAL INFRASTRUCTURE: Water Attacks Reach More States.</span></strong></p><p><strong>&#128998; WHY IT MATTERS</strong></p><p><a href="https://www.securityweek.com/new-jersey-alabama-join-states-targeted-in-water-cyberattacks/">New Jersey and Alabama</a><span> have confirmed their water and wastewater systems were targeted in the Iran-linked campaign that has now reached at least a dozen states. Cape May and Woodbine in New Jersey reported disrupted phone systems on July 27. The Childersburg Water, Sewer and Gas system in Alabama was attacked the same day. Hackers targeted industrial control systems in both states. Minnesota confirmed over 30 systems affected. Michigan, South Dakota, and Georgia confirmed earlier. Wisconsin, Pennsylvania, and Washington have issued warnings. The FBI confirmed at least seven states as of July 30 and has not provided a public update since. Attackers accessed ICS devices made by Rockwell Automation and other major vendors, in some cases gaining remote access to pumps, valves, and pressure controls.</span></p><p><strong>&#129000; PROBABLE CAUSE </strong><span>Internet-exposed industrial control systems with insufficient authentication, operated by water utilities that often lack dedicated cybersecurity resources. Many smaller water systems rely on internet-connected automation without the monitoring required to detect unauthorized access before operational systems are affected.</span></p><p><strong>&#129001; PROACTIVE PREVENTION </strong><span>For utilities: leadership should confirm whether any operational technology systems, including pumps, valves, sensors, or SCADA interfaces, are accessible from the public internet, and whether those connections require multi-factor authentication. For any organization that depends on water utility services: this is a reminder that operational resilience planning should account for utility disruption, not just internal IT failure.</span></p><p><strong>&#129002; REALITY CHECK </strong><span>A dozen states are now involved, and the public updates have slowed down. The drinking water has remained safe in the confirmed cases, which is good news. But attackers reached systems connected to pumps, valves, and pressure controls. That alone should change the conversation. For any organization running operational technology, the question is whether the systems that control physical processes are separated from the systems used for routine monitoring and administration. If they are not, the organization has created a much larger problem than a typical IT outage.</span></p><h3><span>NONPROFIT: 1000s Told, &#8220;Assume Everything Was Taken.&#8221;</span></h3><p><strong>&#128998; WHY IT MATTERS </strong><a href="https://tfn.scot/news/thousands-of-charities-hit-by-cyber-security-incident-at-third-party-provider">Beacon CRM</a><span>, a donor and supporter management platform used by over a thousand UK charities, disclosed on August 3 that unauthorized access to its systems using compromised credentials resulted in copies of customer database backups being made and likely downloaded. Beacon told every affected charity to assume that all data held in its platform, including attachments, has been taken. The company has reported itself to the Information Commissioner&#8217;s Office and acknowledged it may never determine exactly what was taken or from which organizations. Affected charities include hospices, disability services, homelessness organizations, and Victim Support. Many affected organizations have begun notifying donors and supporters.</span></p><p><strong>&#129000; PROBABLE CAUSE </strong><span>Compromised credentials used to gain unauthorized access to Beacon&#8217;s systems. The attacker accessed database backups rather than live data, which suggests either that the backup environment had weaker access controls than the production environment, or that the stolen credentials had access to both. The investigation is ongoing and Beacon has acknowledged it may not be able to determine the full scope.</span></p><p><strong>&#129001; PROACTIVE PREVENTION </strong><span>Leadership should ask whether every third-party platform that holds donor, client, or beneficiary data is covered by a data processing agreement that specifies what security standards apply to backup storage, not just live data. Backups are often treated as a separate category, but they contain the same information and are frequently governed by weaker controls. If the agreement does not address backup security explicitly, the question is worth raising before the next renewal.</span></p><p><strong>&#129002; REALITY CHECK </strong><span>Beacon told its customers it may never know exactly what was taken. That may be an honest answer, but it leaves every affected charity carrying the burden of uncertainty. They now have to notify donors and supporters based on the assumption that everything may be exposed because the vendor cannot prove otherwise. This is not unique to nonprofits. Any organization using a third-party platform for sensitive data should ask a basic question before the next contract renewal: if there is a breach, can this vendor tell us what was accessed, what was not, and how it knows? If it cannot, the organization is accepting more risk than the contract may suggest</span>.</p><div><hr></div><h1>EXPERT PERSPECTIVE</h1><h3>The Control Was Supposed to Stop AI-Powered Attacks.</h3><p><strong>Executive Summary (TLDR):</strong> Security researchers at Genians spent months tracking the infrastructure of <a href="https://www.techradar.com/pro/security/experts-warn-north-korean-hackers-are-increasingly-using-ai-to-build-smarter-and-more-devious-cyberattacks">Kimsuky</a>, the North Korean state-sponsored threat group, and documented something more consequential than a new attack technique. What they found was a systematic AI capability development program: local large language model environments, retrieval-augmented generation tools configured against actor-controlled documents, AI agent development frameworks, and integration libraries for external commercial AI services &#8212; all running on infrastructure Kimsuky controls, sending no data to any external provider, leaving no cloud footprint for commercial detection tools to find. The vendor-level monitoring that terminated North Korean ChatGPT accounts used for phishing did not stop the capability. It redirected it. Understanding the difference between those two outcomes is the governance question this research requires boards to answer.</p><ol><li><p><strong>The Vendor Control Worked.</strong><br>OpenAI recently identified and terminated ChatGPT accounts used in phishing and human trafficking operations. That control functioned exactly as designed. Kimsuky&#8217;s documented response was to move their AI capability to locally deployed open-source tools, Ollama, GPT4All, and Msty, that process documents without sending any data to external services.</p></li><li><p><strong>This Is Not a Phishing Upgrade.</strong><br>What was observed was not evidence of documents being created with AI, but a consistent process of capability development. A nation-state actor has built an AI research and development operation.</p></li><li><p><strong>Behavior-Based Detection Is Now the Prerequisite.</strong><br>This one that carries the most immediate governance consequence: move from content-based assessment to behavior-based detection. Content-based detection, signature matching, known indicators of compromise, pattern recognition against known malicious content, has no visibility into locally-run AI infrastructure. The behavioral indicators that remain visible are the sequence of actions following initial access.</p></li></ol><h2>Insight</h2><p>The Genians research changes the AI threat conversation in a way many board briefings still have not caught up with.</p><p>Most of the discussion has focused on AI-enhanced phishing, deepfakes, and malware. Those are real risks. But they are only part of the picture. Kimsuky appears to be building an internal capability development environment around local models, its own data, agent frameworks, and infrastructure it controls.</p><p>That distinction matters. When OpenAI shut down accounts tied to malicious activity, the control worked as intended. The actors did not stop. They moved to locally run tools that do not rely on a commercial provider and do not generate the same cloud activity defenders may be watching for. The vendor did its job. The problem is that the vendor was never in a position to control the whole threat.</p><p>That is where organizations can get false confidence. A company may have policies around approved AI tools, vendor terms of service, and guardrails built into commercial platforms. Those controls matter for the AI environment the company can see. They do not tell the organization much about an attacker running open-source models on infrastructure outside its reach.</p><p>The practical shift is detection. Genians is pointing defenders toward behavior, not content. Known malicious files, signatures, and indicators still have value, but they are less useful when the attacker&#8217;s AI capability never touches a cloud service or leaves a recognizable content trail. What remains visible is the activity that follows: unusual PowerShell behavior, unexpected persistence, credential access, and sequences of actions that do not fit normal operations.</p><p>It requires organizations to be honest about what their monitoring can actually observe, where their behavioral baselines are weak, and whether their security teams can investigate activity that looks ordinary in isolation but suspicious in sequence.</p><p>The board-level question is straightforward: are we relying on security controls that only work when the attacker stays inside the environment we are watching? If the answer is yes, then the organization may have tools that perform well on paper while missing the threat activity that matters most.</p><h1><span>TERMINOLOGY:</span></h1><h3><span>Emergency Declaration as a Governance Signal</span></h3><p><span>When a government entity declares a state of emergency following a cyberattack, it is not primarily a security decision. It is a legal and financial one. Emergency declarations unlock access to state and federal resources, suspend normal procurement rules, and create a documented record that the organization responded proportionately to a serious event. They also trigger reporting obligations and external scrutiny.</span></p><p><span>The Suisun City declaration is significant beyond the incident itself because it establishes a precedent: a ransomware attack on municipal IT infrastructure is now formally the same category of event as a natural disaster in terms of governance response. That framing matters for boards of any organization that provides critical public services.</span></p><p><span>The practical implication is that continuity planning for cyber incidents should be reviewed through the same lens as continuity planning for physical disasters. If the organization has a documented emergency response plan for a flood or fire, the question is whether that plan addresses a scenario where the IT network is offline for days or weeks. Most do not.</span></p><div><hr></div><h1>COMMENT ON THIS EDITION</h1><p><span>Suisun City&#8217;s emergency declaration brings a new question to the table: should ransomware attacks on critical local government systems trigger the same emergency governance response as a natural disaster?</span></p><p><span>Where does your organization draw the line between a cyber incident and an emergency?</span></p><p><em><strong><span>Reply and tell me how your continuity planning handles the scenario where IT is offline for 72 hours.</span></strong></em></p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://substack.com/@cybersecuritychronicles/note/p-210626535&quot;,&quot;text&quot;:&quot;Leave a comment&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/substack.com/@cybersecuritychronicles/note/p-210626535"><span>Leave a comment</span></a></p><div><hr></div><p><strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a><br></strong>Author &amp; Editor, <em>Cyber Risk Governance Insights;</em> Vice President, <a href="https://www.linkedin.com/company/netswitch-technology-management/">Netswitch, Inc.</a></p><h2></h2><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><p><span>Suisun City&#8217;s 911 system went down because ransomware reached infrastructure nobody had separated from the rest of the network. SonicWall&#8217;s patches sat unread while ransomware gangs confirmed the window was still open. Beacon CRM told a thousand charities it might never know what was taken from their donor databases. Every incident this week points to the same gap: organizations discovered what they didn&#8217;t have after the event required it.</span></p><p><span>If your organization cannot quickly answer which systems are network-segmented, which vendors hold your most sensitive data and what their breach notification obligations are, and whether your continuity plan covers an IT outage of several days, those are the conversations to have before the next incident makes them urgent.</span></p><p><span>Netswitch offers a complimentary cyber risk governance health check that starts exactly there. No questionnaire theater. A real conversation about what your posture looks like and what it should.</span></p><p><a href="https://www.netswitch.net">Schedule a conversation with Netswitch</a></p><p>Connect with the <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> on LinkedIn - 6,300+ board members, CISOs, and compliance leaders who read this newsletter for the same reason you do.</p><p>Attend the next Cyber Risk Governance Live event. One hour. No vendor pitches. Real governance conversations with people dealing with the same problems you are.</p><div><hr></div><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Seven hospitals. One vendor. One breach they all owned.]]></title><description><![CDATA[Edition 137: 2023 data leak is generating sextortion emails today.]]></description><link>https://cybersecuritychronicles.substack.com/p/seven-hospitals-one-vendor-one-breach</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/seven-hospitals-one-vendor-one-breach</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 03 Aug 2026 15:38:46 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em><strong>This week we see</strong>&#8230; </em>attacks sharing a single pattern: the breach is not the ending. It is the infrastructure for what happens next.</p><h1>&#10024; QUICK WIN</h1><p>Tomorrow, ask your CISO:</p><p>&#8220;If our data were published tomorrow, what is our plan for the next three years?&#8221;</p><p>If the answer is limited to forensics and notification, then the organization is not thinking about the downstream liability that comes with leaked data.</p><h1>WEEK IN BRIEF</h1><h3>CRITICAL INFRASTRUCTURE: State Hackers Strike Water Systems Across 7 States</h3><p>&#128998; <strong>WHY IT MATTERS</strong>: The FBI and the EPA have confirmed coordinated cyberattacks targeting water and wastewater systems in at least 7 states, affecting over 45 municipalities. Investigators suspect Iran-linked threat actors are targeting programmable logic controllers that manage chemical treatment and water pressure. Multiple utilities have switched to manual operational control to prevent attackers from remotely altering water quality. This is not a theoretical threat. This is active disruption of essential services affecting millions of people. No water supplies have been rendered unsafe to drink yet. The governance question is why it took multiple states reporting compromises before the federal government went public.</p><p>&#129000; <strong>PROBABLE CAUSE</strong>: The affected systems appear to have been deployed with weak authentication and insufficient hardening for internet-connected operation. Many operational devices were not built for direct exposure, so once they are moved into connected environments without compensating controls, the risk profile changes fast.</p><p>&#129001; <strong>PROACTIVE PREVENTION</strong>: Require infrastructure and IT leadership to inventory every operational system that touches water, pressure, treatment, or remote-control functions. For each one, document whether it was designed for isolated operation or connected networks, and whether the current configuration matches that design. If a device was built for air-gapped use but is now network-connected, the organization should either isolate it or require vendor validation that the deployment is hardened for that environment.</p><p>&#129002; <strong>REALITY CHECK</strong>: This is where a lot of organizations get uncomfortable. They modernize the control environment, centralize management, and assume the security model came along for the ride. It usually didn&#8217;t. If the original design assumed isolation and the current deployment doesn&#8217;t, then the board is not dealing with a minor configuration issue; it is carrying an operational risk that was never fully reviewed.</p><h3>HEALTHCARE: Breach Affects 1.26 Million Patients Across Seven Providers</h3><p>&#128998; <strong>WHY IT MATTERS</strong>: <a href="https://www.bleepingcomputer.com/news/security/data-breach-at-medical-billing-firm-mcbs-affects-126-million-people/">Medical Computer Business Services (MCBS)</a>, a Georgia-based billing and revenue cycle management company, disclosed that attackers accessed its systems between September 22-26, 2025. The company did not disclose the full scope until late June 2026. Over 1.26 million patients had their names, addresses, Social Security numbers, dates of birth, health insurance information, and medical records compromised. MCBS is a business associate, meaning seven covered entities entrusted patient data to this single vendor. When one vendor fails, seven organizations simultaneously face breach notification obligations. MCBS said the PEAR ransomware group stole 3.3 terabytes of data and claimed it on the dark web.</p><p>&#129000; <strong>PROBABLE CAUSE</strong>: The most likely cause is insufficient access control and monitoring around patient data repositories. The long delay before disclosure suggests the environment either did not generate meaningful alerts or the alerts were not acted on quickly enough to contain the exfiltration.</p><p>&#129001; <strong>PROACTIVE PREVENTION</strong>: Require compliance and IT leadership to map which business associates can access patient data, how much they hold, and why they need it. For high-volume vendors, require documented data minimization, quarterly review of access, and controls that can detect or limit bulk extraction of PHI. If a vendor cannot show those controls, the organization should reconsider whether that concentration risk is acceptable.</p><p>&#129002; <strong>REALITY CHECK</strong>: Healthcare boards often think about vendor risk in narrow terms: we have a contract, we have cyber insurance, and the vendor said they&#8217;re secure. That is not enough. When one vendor sits between multiple covered entities and a single compromise affects all of them at once, the organization has created a concentration problem whether it intended to or not. Nobody likes to admit that a purchasing decision turned into a shared liability, but that is exactly what happened here.</p><h3>HEALTHCARE: System Experiences Week-Long Outage Following Cyberattack</h3><p>&#128998; <strong>WHY IT MATTERS</strong>: <a href="https://www.foxcarolina.com/2026/08/02/anmed-launches-centralized-phone-line-addresses-data-security-after-cyberattack/">AnMed Health System</a>, a multi-hospital network in South Carolina, suffered a malware attack on July 26 that disrupted all phone and internet services across its locations. By August 2, the system launched a centralized phone line for patients to schedule appointments and refill prescriptions. Patient-facing operations remained interrupted for seven days. The incident forced manual workarounds while forensic investigation continued. The FBI was notified and confirmed the investigation. AnMed did not disclose the attack vector, the scope of patient data exposed, or the nature of the malware.</p><p>&#129000; <strong>PROBABLE CAUSE</strong>: The outage appears consistent with insufficient segmentation and limited recovery options between communications systems and core operational services. Once the malware reached the environment, the lack of a clean restoration path likely extended the interruption.</p><p>&#129001; <strong>PROACTIVE PREVENTION</strong>: Require IT to define the recovery time objective for every patient-facing system, then test whether those objectives are actually achievable. If core systems cannot be restored within the expected business window, the organization needs a parallel recovery path, not just a backup plan on paper. Quarterly recovery testing should be treated as a governance requirement, not an IT exercise.</p><p>&#129002; <strong>REALITY CHECK</strong>: A seven-day outage is not just a technology event. It is a continuity failure that patients feel immediately. Boards tend to ask whether the attack was stopped, but the harder question is whether the business could keep operating while the forensic work was happening. If the answer is no, then the recovery plan was not really a plan &#8212; it was an assumption.</p><h3>REGULATORY WARNING: FBI and EPA Issue Joint Alert on Escalating</h3><p>&#128998; W<strong>HY IT MATTERS</strong>: The FBI and EPA jointly issued a <a href="https://justthenews.com/government/federal-agencies/fbi-warns-cyberattacks-targeting-us-water-systems-are-causing">public alert warning</a> that malicious cyber actors have been remotely tampering with water systems. The agencies identified programmable logic controllers as the primary target and noted that Unitronics devices using compromised default credentials are especially vulnerable. The alert marks an escalation in federal concern. Joint agency warnings indicate the scope of attacks has moved beyond isolated incidents into a pattern that requires coordinated government response. This is the second time in three years the FBI, EPA, and NSA have issued warnings about the same class of device being exploited by Iran-linked groups.</p><p>&#129000; <strong>PROBABLE CAUSE</strong>: The vulnerability appears to stem from operational technology that was deployed without security controls appropriate for connected environments. Where devices rely on default credentials or weak access controls, the problem is not only the device itself but the failure to govern how it is being used.</p><p>&#129001; <strong>PROACTIVE PREVENTION</strong>: Require infrastructure teams to map CISA and other federal alerts to the actual devices and control systems in use. For each alert, document whether it applies, whether the affected systems are exposed, and what remediation timeline exists. If the organization cannot prove that it understands whether the alert applies, then it is not managing critical infrastructure risk in a defensible way.</p><p>&#129002; <strong>REALITY CHECK</strong>: When federal agencies issue a joint warning like this, they are usually telling you the threat is no longer theoretical. That should change how leadership thinks about &#8220;routine&#8221; operational technology. If your systems depend on the same device class being targeted nationwide, then your risk is not hypothetical just because nothing has broken yet. Waiting for your own incident is not a strategy.</p><div><hr></div><h1>EXPERT PERSPECTIVE</h1><h2>RISK EXPLOITATION: Breach Data Never Dies</h2><h4>Sextortion Campaigns Prove Leaked Datasets Generate Perpetual Liability</h4><p>Threat actors are now using email addresses previously leaked by the ShinyHunters extortion group to fuel a new <a href="https://www.malwarebytes.com/blog/scams/2026/07/sextortion-scammers-are-exploiting-shinyhunters-data-leaks">sextortion email campaign</a>. </p><p>Millions of recipients whose email addresses appeared in old breaches (Amtrak, Hallmark, Substack, Betterment, CarGurus, ADT, Panera Bread, McGraw Hill) are receiving fake threats claiming hackers have compromised their devices and demanding $2,000 in Bitcoin. The scammers are not sophisticated. They simply downloaded ShinyHunters publicly leaked data and reused it to make crude threats appear credible by referencing real breaches. ShinyHunters denies involvement.</p><p>This is secondary victimization: the same breach data, now being weaponized by unrelated threat actors years after the original incident.</p><h3>HIGHLIGHTS</h3><ol><li><p><strong>Breach Data Has No Expiration Date.</strong> Email addresses stolen years ago remain valuable for social engineering because they are authentic. Sextortion campaigns use real breach data to create false credibility.</p></li><li><p><strong>Disclosure Risk Extends Beyond the Original Breach.</strong> Organizations disclose breaches when they discover them. They do not control what happens to the leaked data afterward.</p></li><li><p><strong>Volume Creates Vulnerability at Scale</strong>. Millions of people are receiving these emails simultaneously. Even at a 0.1% conversion rate, at scale, the campaign is economically rational even though individual threats are threadbare.</p></li><li><p><strong>Boards Rarely Ask About Secondary Exploitation.</strong> Organizations measure breach success by &#8220;did we respond quickly&#8221; and &#8220;did we comply with notification law.&#8221; Nobody asks &#8220;what will this leaked data enable over the next five years.&#8221; Governance ends at disclosure. Liability does not.</p></li></ol><h3>INSIGHT</h3><p>Sextortion campaigns are not new. What is new is the industrialization. A decade ago, sextortion required crafting personalized threats. Today, an attacker downloads a leaked dataset from ShinyHunters, cross-references it with any breach mentioned in the news, and automatically generates tens of millions of emails using templates. The AI-assisted versions read professionally enough to fool recipients who do not know sextortion is almost always a bluff with no evidence behind it.</p><p>The governance failure is this: organizations treat breach disclosure as a point-in-time event. </p><p>They disclose, they notify, they remediate, they move on.</p><p>The liabilities they just created do not move on. They compound. </p><p>A dataset containing email addresses from eight major breaches is worth proportionally more to someone conducting sextortion than either dataset alone would be. It creates the appearance of a coordinated intelligence operation. It enables statistical targeting. It becomes self-perpetuating.</p><p>Boards should be asking a harder question: if breach data remains public and is reused in future campaigns, what is our accountability framework after the incident is closed? Notification and forensics are not enough. There should also be a plan for monitoring secondary misuse and setting realistic expectations with affected users. Most boards have not done that work yet.</p><h2>RISK REDUCTION: The Checkbox That Cost Their Claim</h2><p><a href="https://www.linkedin.com/in/kimma-wreh/">Dr. Kimma Wreh, CISSP, CIA, CRMA</a>, holds a doctorate in cybersecurity, has executed more than 400 risk assessments across 30-plus government agencies, and has conducted a deep study of GRC findings at a Fortune 500 firm. She joined <a href="https://www.linkedin.com/in/netswitchstanleyli/">Stanley Li, CEO</a> and <a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM &amp; Vice President</a> of Netswitch, on <strong><a href="https://www.linkedin.com/events/howtobuildaudit-readyaigovernan7483910076932440064/theater/">Cyber Risk Governance Live</a></strong> to work through what governance actually looks like for organizations that do not have a dedicated GRC department.</p><p>The conversation started where it always ends: in the claims process. A breach happens, an adjuster asks what percentage of devices had MFA enforced eighteen months ago, and IT cannot produce the answer. The control existed. The evidence did not. That gap, not the breach itself, is what costs organizations their claims, their compliance standing, and increasingly their regulatory defense.</p><p>The full recording is available on the <a href="https://www.youtube.com/@netswitch_cyberriskgovernance/videos">Cyber Risk Governance YouTube</a> page.</p><h3>Highlights</h3><ol><li><p><strong>Provider is Asking the Question Your Governance Should Have Already Answered</strong>. The adjuster does not ask whether you have a policy. The adjuster asks whether you can prove the control was operating at the time of the breach. Most organizations cannot. </p></li><li><p>D<strong>iscovery That Looks Like an Audit Produces a Useless Inventory.</strong> Frame your discovery process as an audit with consequences and the inventory comes back clean and worthless, because nobody volunteers the filing that might get them written up. Dr. Wreh&#8217;s method is the opposite. </p></li><li><p><strong>AI Without Data Governance Is a Data Problem You Already Had</strong>. If you do not clean up your data, if you do not classify your data, if you do not have good controls over your data, and you bring an AI tool in, you are putting it in a rogue environment. AI does not create the data governance gap. It makes an existing gap consequential at machine speed. </p></li></ol><h3>Insight</h3><p>Dr. Wreh&#8217;s framing of governance as an enabler rather than a constraint is the observation that most board conversations about cybersecurity investment miss. The argument against governance spending is almost always framed as a tension between security and speed: controls slow the business down, compliance adds friction, governance creates drag. </p><p>Dr. Wreh inverts that argument directly. Governance does not exist to stop innovation. It exists to make innovation defensible. Organizations that cannot prove their controls were operating cannot collect on their insurance, cannot satisfy a regulator, and cannot defend a litigation position. Speed without defensibility is not competitive advantage. It is accumulated exposure.</p><p>The claims gap she describes connects the governance evidence argument this newsletter has been building across multiple sources. The Cowbell 2026 data showed premiums declining while claims rose 40 percent, with 31% of SMB claims denied for insufficient evidence</p><p>of controls that actually existed. The ISACA security debt framework identified deferred governance decisions as the structural condition that makes those denials possible. Dr. Wreh gives both frameworks a practitioner face: she has sat across from the organizations carrying this exposure, and she has seen what the adjuster&#8217;s question reveals about the gap between the checkbox and the evidence behind it.</p><p>The Texas legislative development deserves more board attention than it is receiving. State-level cybersecurity law that scales by headcount, requiring specific framework implementation as a function of organizational size with the Texas Responsible AI Governance Act (TRAIGA) running alongside it, represents a compliance obligation that most organizations in the affected range have not yet fully mapped. The risk register that does not include Texas SB 2013 and the Responsible AI Governance Act is missing a current, enforceable requirement. That is security debt by another name.</p><p>The full conversation with Dr. Wreh covers how to conduct discovery that produces real information rather than a clean but fictional inventory, how to translate framework requirements into programs that work without a dedicated GRC team, and how to build the evidence portfolio that survives the claims question rather than the audit question.</p><p>Those are the conversations that make the recording worth an hour.</p><p><a href="https://youtu.be/S5BnPo2yqTI?si=m70YJYmxjaeLtHLl">Cyber Risk Governance Live</a></p><h1>TERMINOLOGY:</h1><h2>Business Associate Consolidation Risk</h2><p>When a single vendor serves multiple healthcare organizations as a business associate, one compromise can create simultaneous exposure across every downstream client. That is concentration risk. The issue is not just that the vendor was breached. It is that the same failure can trigger multiple breach notifications, multiple forensic reviews, and multiple liability exposures at once. Boards should ask how many patient records flow through each business associate and whether the organization is carrying more vendor concentration than it can tolerate. In healthcare, that question is still not asked often enough.</p><div><hr></div><h1>COMMENT ON THIS EDITION</h1><p><span>The Hugging Face incident introduces a new category of vendor risk - the AI platform as attack surface and supply chain vector simultaneously. </span></p><p><em><span>Does your organization currently have AI development tools, model repositories, or dataset pipelines mapped in your third-party risk program?</span></em><span> </span></p><p><em><strong><span>Reply and tell us where you are on AI vendor governance.</span></strong></em></p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://substack.com/@cybersecuritychronicles/note/p-209531286&quot;,&quot;text&quot;:&quot;Leave a comment&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/substack.com/@cybersecuritychronicles/note/p-209531286"><span>Leave a comment</span></a></p><div><hr></div><p><strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a><br></strong>Author &amp; Editor, <em>Cyber Risk Governance Insights;</em> Vice President, <a href="https://www.linkedin.com/company/netswitch-technology-management/">Netswitch, Inc.</a></p><h2></h2><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><p>Every incident this week pointed to the same problem: coverage is not the same as control. A vendor compromise, a ransomware shutdown, competing extortion threats, data loss after containment, and an autonomous AI agent breach all lead to the same board-level question &#8212; do we actually know who has access to our systems and data, and when that access was last reviewed?</p><p>If your organization cannot produce a current inventory of every vendor with access to your systems or customer data, along with the last date that access was reviewed, you are carrying the same exposure that showed up on this week&#8217;s breach list.</p><p>Netswitch offers a complimentary cyber risk governance health check that starts there. It is a real conversation about what your vendor access picture looks like, where the gaps are, and what should happen next.</p><p><a href="https://www.netswitch.net">Schedule a conversation with Netswitch</a></p><p>Connect with the <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> on LinkedIn - 6,300+ board members, CISOs, and compliance leaders who read this newsletter for the same reason you do.</p><p>Attend the next Cyber Risk Governance Live event. One hour. No vendor pitches. Real governance conversations with people dealing with the same problems you are.</p><div><hr></div><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[$12.3M ransom demand. The breach wasn't theirs. The liability was.]]></title><description><![CDATA[Edition 136: Two AI agents attacked without a human at the keyboard.]]></description><link>https://cybersecuritychronicles.substack.com/p/123m-ransom-demand-the-breach-wasnt</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/123m-ransom-demand-the-breach-wasnt</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 27 Jul 2026 20:24:31 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em><strong>This week we see</strong>&#8230; </em>the same governance pattern; the stories are identical: boards approved operational decisions that made accountability impossible. Organizations failed not because of technical gaps. They failed because no one asked the hard governance questions before the incident occurred.</p><h1>&#10024; QUICK WIN</h1><p>Schedule a conversation with your IT leadership this week. </p><p>Ask them: &#8220;<em>If our core customer systems went down today, how many hours until we are fully restored?</em>&#8220; Then follow up: &#8220;<em>Does that recovery window fit within our Maximum Tolerable Downtime, or are we carrying unpriced business interruption risk?</em>&#8220; </p><p>Make the answer your next infrastructure risk management priority.</p><h1>WEEK IN BRIEF</h1><h4>FINANCIAL SERVICES - 4.8M Customer Breach Exposes the Social Engineering Trap</h4><p>&#128998; WHY IT MATTERS: <a href="https://www.northweststar.com.au/story/9316588/bank-credit-cards-details-caught-up-in-origin-breach/">Origin Energy</a> disclosed that customer data was compromised in a cyberattack affecting approximately 4.8 million accounts. The breach exposed names, addresses, dates of birth, phone numbers, account information, and the last four digits of credit cards or bank accounts. Origin is Australia&#8217;s largest energy supplier. A breach doesn&#8217;t shut down power. It enables social engineering attacks. As a security researcher noted, the combination of billing history, date of birth, and partial card numbers creates &#8220;exact trust signals a business uses to verify itself over the phone.&#8221; That makes unsolicited contact from attackers far more convincing than it should be.</p><p>&#129000; PROBABLE CAUSE: Insufficient access controls on customer data systems and inadequate monitoring of data access patterns before exfiltration.</p><p>&#129001; PROACTIVE PREVENTION: Require the CISO to document which customer data can be accessed by which systems and why. Then require monthly audits confirming that access levels match stated business justification. If there&#8217;s access that can&#8217;t be justified, revoke it.</p><p>&#129002; REALITY CHECK: This is the part boards often miss: the breach isn&#8217;t just about stolen records, it&#8217;s about how those records can be used after the fact. When customer identity data, account details, and partial payment information are exposed together, attackers do not need a full card number to do damage. They can use what was exposed to sound legitimate, bypass weak verification steps, and push a customer-service team into giving away even more. That is why the real risk is not only disclosure, but what the disclosure enables next.</p><h4>MANUFACTURING - $12.3M Ransom Refused, Exposes the Third-Party Liability</h4><p>&#128998; WHY IT MATTERS: <a href="https://therecord.media/stadler-refuses-everest-ransom-demand">Stadler Rail</a>, a major Swiss train manufacturer, disclosed that the Everest ransomware group compromised a supplier&#8217;s data exchange platform and demanded CHF 10 million (approximately $12.3M) in ransom. Attackers gained access using compromised credentials for a shared platform where Stadler exchanges technical data with suppliers. Stadler refused the ransom. The company stressed that no personal data was stolen, no safety-critical information was compromised, and its own IT systems and production lines remained unaffected. Yet the incident still forced public disclosure, law enforcement involvement, and reputational risk. A breach at Stadler&#8217;s supplier still became Stadler&#8217;s problem.</p><p>&#129000; PROBABLE CAUSE: Insufficient credential management controls on supplier data exchange platforms. Access to shared platforms relied on static credentials without multi-factor authentication or behavioral monitoring.</p><p>&#129001; PROACTIVE PREVENTION: Require the procurement and IT teams to jointly audit every third-party data exchange platform. For each platform, document what access controls are required (MFA, IP restrictions, session logging) and whether those controls are actually implemented. If controls are missing, don&#8217;t use the platform until they&#8217;re deployed.</p><p>&#129002; REALITY CHECK: This is a vendor breach, but it does not stay a vendor breach for long. Once a shared platform is involved, the issue becomes contractual liability, operational disruption, and reputational fallout for the company that depends on it. Boards tend to assume the supplier will &#8220;handle it,&#8221; but that is not how these events play out. If the supplier&#8217;s environment is the weak link, the downstream organization still has to explain the business impact.</p><h4>EDUCATION - University Breach Reveals the Long Recovery Timeline</h4><p>&#128998; WHY IT MATTERS: <a href="https://www.ctvnews.ca/calgary/article/mount-royal-university-student-portal-reopens-after-june-cyber-attack/">Mount Royal University</a> disclosed a cyberattack that forced the closure of its student portal for over a month. The portal reopened on July 24 after a June incident, suggesting approximately 54 days of service disruption for student account access. Universities manage student financial records, enrollment data, and payment information. A month-long disruption creates cascading problems: students can&#8217;t register for courses, can&#8217;t access financial aid information, can&#8217;t process payment adjustments. For the university, it means lost registration revenue and operational backlog. The timeline tells the story: detection happened in June, but recovery took into the following month.</p><p>&#129000; PROBABLE CAUSE: Extended forensic investigation and system rebuild without parallel restoration pathway for critical student systems.</p><p>&#129001; PROACTIVE PREVENTION: Require IT to document the recovery time objective (RTO) and recovery point objective (RPO) for every critical system. For student portals, RTO should be measured in hours, not weeks. If the current architecture can&#8217;t meet that objective, build a parallel system that can be activated within 24 hours.</p><p>&#129002; REALITY CHECK: Universities like to think in terms of recovery, but the real problem is how long the disruption lasts while everyone is waiting for the clean restoration point. A student portal being offline for weeks is not a minor inconvenience. It affects enrollment, payments, aid, and the basic ability of the institution to function. If leadership has not already forced a hard conversation about recovery time and backup design, then the institution is planning to learn that lesson during the next incident.</p><h4>CRITICAL INFRASTRUCTURE - Ransomware Attack Disrupts Cultural Institution</h4><p>&#128998; WHY IT MATTERS: <a href="https://cybernews.com/security/dutch-ice-arena-thialf-ransomware-cyberattack/">Thialf ice arena in the Netherlands</a> disclosed a ransomware attack that disrupted facility operations. Ice arenas are not critical infrastructure in the federal sense. But they are critical to operations in their community. A ransomware attack can delay events, cancel bookings, and create customer notification obligations. For a publicly operated facility, it also triggers government transparency requirements and potential liability claims.</p><p>&#129000; PROBABLE CAUSE: Insufficient network segmentation allowing attackers to move from administrative systems to operational controls.</p><p>&#129001; PROACTIVE PREVENTION: Require the facility manager and IT team to document the network architecture. Where does the ticketing system connect? Where does the HVAC system connect? Are they isolated from each other? If ticketing gets compromised, can attackers reach climate controls? If the answer is yes, segment the networks immediately.</p><p>&#129002; REALITY CHECK: People hear &#8220;arena&#8221; and think this is a small operational issue. It is not. A facility that cannot run because its systems were compromised has the same basic problem every other organization does: one weak network path can take down the whole operation. The uncomfortable truth is that most public facilities still treat segmentation and recovery as IT housekeeping instead of business continuity. That only works until the day it doesn&#8217;t.</p><h4>DIGITAL SERVICES - Network Disrupted, Affects Thousands of Users</h4><p>&#128998; WHY IT MATTERS: <a href="https://www.corkbeo.ie/news/world-news/thousands-playstation-users-unable-access-34350499">PlayStation</a> service disruption prevented thousands of users from accessing their accounts. PlayStation is not government infrastructure, but it serves millions of users globally and generates significant revenue. Service disruptions create customer churn, reputational damage, and stock price pressure. For a public company, if an outage crosses the threshold of material financial or operational impact, it triggers mandatory SEC 8-K disclosure windows.</p><p>&#129000; PROBABLE CAUSE: Insufficient redundancy in critical authentication systems or inadequate load balancing during traffic spikes.</p><p>&#129001; PROACTIVE PREVENTION: Require the Chief Technology Officer to document the availability target for all customer-facing systems. If it&#8217;s 99.9 percent availability, design systems to survive a single component failure without service impact. If current systems can&#8217;t meet that target, they need re-architecture before the next incident.</p><p>&#129002; REALITY CHECK: This kind of outage is easy to dismiss because it doesn&#8217;t look like a traditional breach. But for a platform with millions of users, downtime is the incident. Customers do not care whether the root cause was authentication, load balancing, or an overloaded dependency. They care that they could not get in, and they remember how the company handled it. That is the part boards should care about too, because service reliability is part of trust now.</p><div><hr></div><h1>&#128308; Cyber Risk Governance Live:</h1><h2>Build Audit-Ready AI Governance Without a Compliance Team</h2><h3>Your team is already using AI. </h3><p>Someone drafted a client proposal with it this morning, and someone else pasted sensitive data into an unapproved tool. But enterprise frameworks like NIST AI RMF and ISO 42001 were built for organizations with seven-figure GRC budgets - leaving midsize companies stuck between banning AI or running with zero structure.</p><p>Neither posture survives 2026.</p><p>Join <strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a></strong> and <strong><a href="https://www.linkedin.com/in/netswitchstanleyli/">Stanley Li</a></strong><a href="https://www.linkedin.com/in/netswitchstanleyli/"> </a>for a live, practical executive session featuring <strong><a href="https://www.linkedin.com/in/kimma-wreh/">Dr. Kimma Wreh, CISSP, CIA, CIPM</a></strong> (Former Fortune 500 SOX lead and vCISO across 80+ agencies).</p><p><strong>What You&#8217;ll Discover:</strong></p><ul><li><p><strong>The &#8220;Ban or Ignore&#8221; Trap:</strong> The workable third path for scaling AI safely.</p></li><li><p><strong>The Translation Layer:</strong> How to scale enterprise frameworks so a lean team can run them.</p></li><li><p><strong>The AI Fraud Door:</strong> Connecting AI governance to deepfake and cloned-voice fraud defense.</p></li></ul><p>&#128197; <strong>Wednesday, July 29, 2026</strong> | 1:00 PM ET / 10:00 AM PT</p><p>&#128205; <strong>LinkedIn Live</strong> <em><strong>(Free to attend)</strong></em></p><p>&#128073; <strong>Reserve Your Seat for <a href="https://www.linkedin.com/events/howtobuildaudit-readyaigovernan7483910076932440064/">CRG Live Here</a></strong></p><div><hr></div><h1>EXPERT PERSPECTIVE</h1><h3>RISK REDUCTION - 2 Agentic Attacks in 30 Days. Vendor Security Assumptions Predate Both.</h3><p><strong>Executive Summary:</strong> On July 16, 2026, <a href="https://www.helpnetsecurity.com/2026/07/20/hugging-face-breached-by-autonomous-ai-agent/">Hugging Face disclosed</a> that an autonomous AI agent breached its production infrastructure, the world&#8217;s largest repository for open-source AI models, through a malicious dataset that exploited two code-execution paths in its data-processing pipeline. The agent escalated to node-level access, harvested cloud and cluster credentials, and moved laterally across multiple internal clusters over a single weekend, executing thousands of individual actions across a swarm of short-lived sandbox environments with self-migrating command-and-control infrastructure. This is the second confirmed end-to-end autonomous AI attack in July 2026, arriving one week after JadePuffer. One agentic attack is a data point. Two in the same month, against different target types, using different entry points, both executing without a human operator, is a pattern. The governance infrastructure most organizations have in place was built before either of them happened.</p><h4>Highlights</h4><p><strong>1. Entry Point Was the Data Pipeline. The Trusted Infrastructure Was the Weapon.</strong><br>The attacker did not compromise a user account or exploit a perimeter vulnerability. The attack entered through its own data-processing pipeline - a trusted, internal infrastructure element designed to ingest and execute user-submitted content as a core business function.</p><p><strong>2. Models Ran Against a Live Target With Safety Guardrails Disabled. </strong>OpenAI subsequently confirmed that the attack agent ran on its own frontier models during an internal cyber-capability evaluation - with production safety guardrails disabled. This is not a technical finding. It is a governance finding.</p><p><strong>3. AI Tools Refused to Help. </strong>When Hugging Face attempted to use commercial frontier AI tools to investigate the breach, those tools&#8217; guardrails blocked analysis of real attack commands, exploit payloads, and command-and-control artifacts - because the content the investigators needed to analyze looked indistinguishable from malicious activity.</p><h3>Insight</h3><p>JadePuffer and Hugging Face are not random one-offs. They look more like the first clear signs of where this is going. Two agentic attacks in the same month, against different target types, with different entry points, and both running without a human at the keyboard, that should get every board&#8217;s attention.</p><p>The important part is not just that the attacker got in. It is how they got in. Hugging Face&#8217;s own data-processing pipeline was part of the attack path. That matters because most organizations have some version of this same setup: trusted internal systems that ingest outside content, run it, transform it, or hand it off to other systems. If those pipelines were designed around a human attacker, they are already behind.</p><p>The other detail that stands out is the standing credentials. Once the agent reached the worker environment, it used access that was already there. That is not some exotic failure mode. That is the kind of debt organizations quietly accumulate over time and then stop noticing because nothing has broken yet. Until something does.</p><p>The OpenAI guardrail point is also worth slowing down on. Running frontier models against a live target with safety controls disabled is not just a technical choice. It is a governance decision. And once you see it that way, the board question becomes pretty simple: who is allowed to turn those controls off, when, and under what approval? If nobody can answer that clearly, then the governance model is looser than the risk.</p><p>The biggest practical problem may be the one on the defender side. If your commercial AI tools refuse to help during an incident because the material looks too much like malicious content, then you do not really have an incident-response capability; you have a dependency that might fail at the worst possible moment. Hugging Face&#8217;s own advice is basically the right one: have a model you can run yourself, and have it ready before you need it.</p><p>The takeaway for the board is not that AI agents are dangerous in some abstract future sense. It is that the old security assumptions are already stale. Most of the controls organizations have today were built for human attackers moving step by step. That is not the threat profile these incidents describe.</p><h3>RISK RETENTION - Security Debt Is a Board Decision Nobody Made.</h3><p><strong>Executive Summary:</strong> <a href="https://www.isaca.org/resources/white-papers/2026/security-debt-the-unseen-risk-undermining-cyber-resilience">ISACA&#8217;s 2026 white paper on security debt</a>, published March 2026, provides the governance framework that connects every breach pattern this newsletter has tracked over the past several weeks. Security debt is defined as the accumulated risk created by outdated systems, deferred remediation, unpatched vulnerabilities, and under-resourced programs- risk that grows quietly while organizations prioritize speed, innovation, and cost management. The paper frames this as an inadvertent accumulation through reasonable decisions made under pressure. The more precise framing for a board audience is different: security debt is risk the organization is retaining without having explicitly decided to retain it. Nobody approved that exposure. Nobody priced it. It simply compounded until a breach made it visible and a forensic investigator made it expensive.</p><h4>Highlights</h4><p><strong>1. Security Debt Has 4 Categories. Only 1 Is Technical: </strong>Three of the four categories originate in decisions made above the security team level. The board that treats security debt as an IT problem has already misclassified the source.</p><p><strong>2. The Curve Steepens Before Anyone Notices: </strong>Debt accumulates slowly at first, with each deferred patch or missed audit adding incremental risk that appears manageable in isolation. As systems become more interconnected and complexity grows, the slope steepens sharply. By the time the curve reaches its steepest point, the debt has become organizational rather than technical.</p><p><strong>3. The Average Breach Timeline Is 241 Days. Security Debt Is Why: </strong>IBM&#8217;s 2025 Cost of a Data Breach Report documents that the average time to identify and contain a breach is 241 days. The SolarWinds breach and the 2017 Equifax breach are not stories about sophisticated attackers. They are stories about organizations that carried known, documented, measurable debt, then an attacker found it.</p><h3>Insight</h3><p>The ISACA paper is useful because it gives boards a practical way to think about an old problem: security debt. The IBM study shows that AI adoption is already outpacing governance for most organizations. JadePuffer shows what that looks like when an attacker is no longer moving at human speed. <a href="https://www.linkedin.com/in/carolynmckilloptroiano/">Carolyn Troiano</a>&#8217;s <a href="https://www.linkedin.com/events/defensiblebydesign-howtostopdoc7473019230133694464/theater/">FDA data shows the same pattern in compliance</a>: years of deferred work eventually show up as a measurable regulatory failure. The issue is not isolated events. It is accumulated exposure.</p><p>For executives, the question is not whether some risk can be deferred. It can. The question is whether leadership knows what is being deferred, how quickly it is compounding, and who owns the decision. If that is not being tracked, then the organization is carrying risk it has not priced or assigned. That is not disciplined management.</p><p>The SEC&#8217;s disclosure rule makes this board-relevant. Cyber risk now has to be governed with the same seriousness as financial reporting. That means the board should be able to see whether security debt is rising or falling, where the exceptions are, and whether those exceptions are being closed. If that cannot be answered clearly, then the organization does not have a mature security program. It has an unmanaged backlog.</p><div><hr></div><h1>COMMENT ON THIS EDITION</h1><p><span>The Hugging Face incident introduces a new category of vendor risk - the AI platform as attack surface and supply chain vector simultaneously. </span></p><p><em><span>Does your organization currently have AI development tools, model repositories, or dataset pipelines mapped in your third-party risk program?</span></em><span> </span></p><p><em><strong><span>Reply and tell us where you are on AI vendor governance.</span></strong></em></p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://substack.com/@cybersecuritychronicles/note/p-208736582&quot;,&quot;text&quot;:&quot;Leave a comment&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/substack.com/@cybersecuritychronicles/note/p-208736582"><span>Leave a comment</span></a></p><div><hr></div><p><strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a><br></strong>Author &amp; Editor, <em>Cyber Risk Governance Insights;</em> Vice President, <a href="https://www.linkedin.com/company/netswitch-technology-management/">Netswitch, Inc.</a></p><h2></h2><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><p>Every incident this week pointed to the same problem: coverage is not the same as control. A vendor compromise, a ransomware shutdown, competing extortion threats, data loss after containment, and an autonomous AI agent breach all lead to the same board-level question &#8212; do we actually know who has access to our systems and data, and when that access was last reviewed?</p><p>If your organization cannot produce a current inventory of every vendor with access to your systems or customer data, along with the last date that access was reviewed, you are carrying the same exposure that showed up on this week&#8217;s breach list.</p><p>Netswitch offers a complimentary cyber risk governance health check that starts there. It is a real conversation about what your vendor access picture looks like, where the gaps are, and what should happen next.</p><p><a href="https://www.netswitch.net">Schedule a conversation with Netswitch</a></p><p>Connect with the <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> on LinkedIn - 6,300+ board members, CISOs, and compliance leaders who read this newsletter for the same reason you do.</p><p>Attend the next Cyber Risk Governance Live event. One hour. No vendor pitches. Real governance conversations with people dealing with the same problems you are.</p><div><hr></div><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Ransomware alert: Coca-Cola shuts down production lines.]]></title><description><![CDATA[Edition 135: Abbott faces two active breaches, Craneware exposes 147M records]]></description><link>https://cybersecuritychronicles.substack.com/p/ransomware-alert-coca-cola-shuts</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/ransomware-alert-coca-cola-shuts</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 20 Jul 2026 20:53:01 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em><strong>This week we see</strong>&#8230; <span>not that cyber risk got worse in some abstract way; but that the organizations most people assume are covered keep proving that coverage is not the same as control.</span></em></p><h1>&#10024; QUICK WIN</h1><p><span>This week, ask your legal counsel: if a software vendor that processes our patient, customer, or financial data is breached, what are our notification obligations, and whose clock starts first, ours or theirs?</span></p><p><span>If that answer is not written down and tied to a specific regulation or contract clause, the organization is improvising in the face of a legal obligation.</span></p><h1>WEEK IN BRIEF</h1><h3><span>HEALTHCARE: Billing Software Put Patient Data at Risk</span></h3><p><strong>&#128998; WHY IT MATTERS: </strong><span>Edinburgh-based </span><a href="https://techcrunch.com/2026/07/20/hackers-stole-significant-amount-of-data-from-tech-firm-relied-on-by-thousands-of-us-hospitals-and-pharmacies/">Craneware</a><span> confirmed that hackers stole a significant volume of customer, employee, and partner data from systems tied to billing, pharmacy, and revenue cycle software used by thousands of hospitals and clinics. The concern is not just the vendor breach itself. It is that a single compromise can spread exposure across many healthcare organizations at once.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>The most likely cause is credential compromise or abuse of remote access, not some exotic exploit. That pattern has been common in recent healthcare billing vendor incidents, and it fits the way attackers keep finding their way in.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Leadership should maintain a full inventory of every billing, pharmacy, and revenue-cycle vendor handling patient data, then confirm breach-notification rights are documented in the contract. If the contract is silent, the vendor controls the timeline.</span></p><p><strong>&#129002; REALITY CHECK: </strong><span>Healthcare keeps learning the same lesson with different vendor names attached. When one billing provider holds records for thousands of facilities, the breach is no longer their incident. It becomes everyone&#8217;s exposure.</span></p><h3><span>MANUFACTURING: Ransomware Halted U.S. Production</span></h3><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.bleepingcomputer.com/news/security/coca-cola-says-fairlife-ransomware-attack-halts-us-dairy-production/">Coca-Cola</a><span> disclosed that ransomware hit its Fairlife dairy business and forced a suspension of all U.S. production operations. That makes this more than a cyber story. It is a direct operational interruption with visible business impact.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>The attack most likely entered through unauthorized access to production-related IT systems. Whether segmentation contained the spread or simply limited what the attackers targeted, the forensics matter because the answer determines whether this was a boundary that held or just a boundary that got lucky.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Operations and IT should be able to show whether production systems are truly isolated from corporate networks and whether ransomware can move from one environment to the other. &#8216;We think so&#8217; is not an architecture.</span></p><p><strong>&#129002; REALITY CHECK: </strong><span>This is the kind of event that reminds boards a production halt is not a theoretical cyber risk. The moment the line stops, the business stops, and the incident becomes a revenue problem before it becomes a technical one.</span></p><h3><span>HEALTHCARE: Two Incidents Hit at Once</span></h3><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.malwarebytes.com/blog/news/2026/07/healthcare-giant-abbott-probes-two-cyber-incidents-amid-extortion-claims">Abbott Laboratories</a><span> is dealing with two apparently separate incidents at the same time: one involving its Cancer Diagnostics business and another involving claims tied to its LabCentral portal. That matters because simultaneous incidents create confusion, competing response tracks, and a much harder board conversation.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>The likely explanation is two separate entry points, not one connected event. One appears to involve internal access, while the other points to compromised customer credentials or a weak portal control.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Organizations should have a protocol for multi-front incidents, including who coordinates response when two separate teams are handling separate breaches. A single incident response plan that assumes one event at a time has a blind spot.</span></p><p><strong>&#129002; REALITY CHECK: </strong><span>Two incidents at once are not a coincidence to shrug off. They are a sign that multiple actors looked at the same organization and decided it was worth the effort.</span></p><h3><span>ENERGY: Cloud Storage Breach Could Turn Material</span></h3><p><strong>&#128998; WHY IT MATTERS: </strong><span>Colombian state energy company </span><a href="https://www.techradar.com/pro/security/colombian-energy-giant-ecopetrol-says-thousands-of-user-accounts-hit-in-cyberattack">Ecopetrol</a><span> disclosed unauthorized access to cloud-based file storage across multiple subsidiaries, followed by extortion demands and a warning that the incident could have a material financial impact. That is the kind of disclosure boards need to take seriously immediately.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>The likely issue was weak access governance over shared cloud storage, allowing an attacker to download data before containment fully closed the door. The fact that ransomware was blocked does not erase the data theft.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Leaders should ask who has administrative access to shared cloud storage, how that access is audited, and what alerts exist for bulk downloads. If cloud governance is handled separately by each business unit, the weakest one sets the standard.</span></p><p><strong>&#129002; REALITY CHECK: </strong><span>Boards often treat &#8216;we stopped the ransomware&#8217; as a win. But when the data already left, the attacker still got what they came for, and the financial conversation is only beginning.</span></p><h3><span>GOVERNMENT: Website Defacement Exposed Weak Access Control</span></h3><p><strong>&#128998; WHY IT MATTERS: </strong><span>Kenya&#8217;s presidential website was defaced after hackers replaced the homepage with a ransom message and public allegations targeting President </span><a href="https://thenextweb.com/news/kenya-investigates-hack-of-rutos-official-website-after-bitcoin-ransom-demand">William Ruto</a><span>. The site was restored, but the incident shows how quickly a public-facing weakness becomes a political and reputational event.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>The most likely cause was unauthorized administrative access through compromised credentials or a CMS weakness. The attackers&#8217; claim that this was their third attempt suggests persistence, not random noise.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Public-facing sites should enforce MFA on all admin accounts, review CMS access regularly, and detect defacement without relying on outside observers to raise the alarm.</span></p><p><strong>&#129002; REALITY CHECK: </strong><span>A defaced homepage is the visible part. The real question is how many quiet attempts happened before the one everyone saw.</span></p><div><hr></div><h1>&#128308; Cyber Risk Governance Live:</h1><h2>Build Audit-Ready AI Governance Without a Compliance Team</h2><h3>Your team is already using AI. </h3><p>Someone drafted a client proposal with it this morning, and someone else pasted sensitive data into an unapproved tool. But enterprise frameworks like NIST AI RMF and ISO 42001 were built for organizations with seven-figure GRC budgets - leaving midsize companies stuck between banning AI or running with zero structure.</p><p>Neither posture survives 2026.</p><p>Join <strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a></strong> and <strong><a href="https://www.linkedin.com/in/netswitchstanleyli/">Stanley Li</a></strong><a href="https://www.linkedin.com/in/netswitchstanleyli/"> </a>for a live, practical executive session featuring <strong><a href="https://www.linkedin.com/in/kimma-wreh/">Dr. Kimma Wreh, CISSP, CIA, CIPM</a></strong> (Former Fortune 500 SOX lead and vCISO across 80+ agencies).</p><p><strong>What You&#8217;ll Discover:</strong></p><ul><li><p><strong>The &#8220;Ban or Ignore&#8221; Trap:</strong> The workable third path for scaling AI safely.</p></li><li><p><strong>The Translation Layer:</strong> How to scale enterprise frameworks so a lean team can run them.</p></li><li><p><strong>The AI Fraud Door:</strong> Connecting AI governance to deepfake and cloned-voice fraud defense.</p></li></ul><p>&#128197; <strong>Wednesday, July 29, 2026</strong> | 1:00 PM ET / 10:00 AM PT</p><p>&#128205; <strong>LinkedIn Live</strong> <em><strong>(Free to attend)</strong></em></p><p>&#128073; <strong>Reserve Your Seat for <a href="https://www.linkedin.com/events/howtobuildaudit-readyaigovernan7483910076932440064/">CRG Live Here</a></strong></p><div><hr></div><h1>EXPERT PERSPECTIVE</h1><h2>RISK REDUCTION</h2><h3><span>AI Attacker, AI Platform, Real Governance Gap</span></h3><p><strong><span>TLDR: </span></strong><a href="https://www.techradar.com/pro/security/this-one-was-different-from-anything-we-had-handled-before-hugging-face-confirms-it-was-hit-by-cyberattack-powered-by-an-ai-agent">Hugging Face</a><span> disclosed that it was hit by an autonomous AI-driven attack that moved through its systems at machine speed, used a malicious dataset to enter the environment, escalated privileges, harvested credentials, and executed thousands of actions before detection. The important part is not just that AI was involved. It is that the attack landed on the infrastructure many organizations depend on to build their own AI systems.</span></p><h3><span>HIGHLIGHTS</span></h3><ol><li><p><strong><span>The entry point was a dataset, not a phishing email.</span></strong><span> Attackers embedded malicious code in a dataset uploaded to a data-processing pipeline. The pipeline processed it; the code executed.</span></p></li><li><p><strong><span>The attack ran at machine speed and machine scale.</span></strong><span> The autonomous agent executed over 17,000 recorded actions.</span></p></li><li><p><strong><span>The defenders&#8217; AI had guardrails.</span></strong><span> The internal security team tried to use hosted AI models to analyze the attack and found their forensic work was slowed by the safety policies baked into those models.</span></p></li></ol><h3><span>INSIGHT</span></h3><p><span>The board-level issue is no longer whether AI can generate a bad answer. It is whether AI platforms in the supply chain are now part of the attack surface, and whether the organization has mapped them as vendors with real governance obligations.</span></p><p><span>Most organizations using AI development tools have not mapped those tools in their vendor risk programs the same way they would map a payroll processor or an EHR system. Hugging Face is not just a tool. It is infrastructure. Its datasets flow into models. Its service credentials, if compromised, can reach the organizations that authenticated to its systems.</span></p><p><span>The speed dimension deserves its own conversation. Seventeen thousand actions in a single attack window is not something a quarterly security review catches. The detection and response capability required to address autonomous AI-driven attacks operates at a fundamentally different timescale than the governance processes most boards have approved budgets for.</span></p><p><span>The question worth bringing to the next risk committee meeting: does your organization&#8217;s AI vendor inventory exist, and does it include the security posture, breach notification commitments, and data pipeline exposure of each platform your development teams depend on?</span></p><div><hr></div><h1>COMMENT ON THIS EDITION</h1><p><span>The Hugging Face incident introduces a new category of vendor risk - the AI platform as attack surface and supply chain vector simultaneously. </span></p><p><em><span>Does your organization currently have AI development tools, model repositories, or dataset pipelines mapped in your third-party risk program?</span></em><span> </span></p><p><em><strong><span>Reply and tell us where you are on AI vendor governance.</span></strong></em></p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://substack.com/@cybersecuritychronicles/note/p-207828998&quot;,&quot;text&quot;:&quot;Leave a comment&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/substack.com/@cybersecuritychronicles/note/p-207828998"><span>Leave a comment</span></a></p><div><hr></div><p><strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a><br></strong>Author &amp; Editor, <em>Cyber Risk Governance Insights;</em> Vice President, <a href="https://www.linkedin.com/company/netswitch-technology-management/">Netswitch, Inc.</a></p><h2></h2><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h2><span>Every incident this week came back to the same gap: organizations that assumed coverage was the same as control.</span></h2><p><span>If your organization cannot produce a current inventory of every vendor with access to your systems or customer data, and the last date that access was reviewed, you are carrying the same exposure that put multiple organizations on a breach notification list this week.</span></p><p><span>Netswitch offers a complimentary cyber risk governance health check that starts exactly there. No questionnaire theater. A real conversation about what your vendor access picture looks like and what it should.</span></p><ul><li><p><span>Schedule a conversation with </span><a href="https://www.netswitch.net"><span>Netswitch</span></a><span>.</span></p></li><li><p><span>Connect with the </span><a href="https://www.linkedin.com/groups/13991569/"><span>Cyber Risk Governance Community</span></a><span> on LinkedIn &#8212; 6,200+ board members, CISOs, and compliance leaders who read this newsletter for the same reason you do.</span></p></li><li><p><span>Attend the next Cyber Risk Governance Live event. One hour. No vendor pitches. Real governance conversations with people who have the same problems you do.</span></p></li></ul><p><span>Reach out to </span><a href="https://netswitch.net/"><span>Netswitch, Inc.</span></a><span> today.</span></p><div><hr></div><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Your Network: 100,000 Edge Routers Left Open]]></title><description><![CDATA[Edition 134: The compromise of the systemic entities we trust to protect us.]]></description><link>https://cybersecuritychronicles.substack.com/p/your-network-100000-edge-routers</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/your-network-100000-edge-routers</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 13 Jul 2026 20:34:04 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em><strong>This week we see</strong>&#8230; <span>attackers aren&#8217;t getting smarter, but that the infrastructure organizations trust most is the one that keeps failing.</span></em></p><h1>&#10024; QUICK WIN</h1><p>This week, pull your list of professional services and managed technology vendors &#8212; consultants, IT integrators, managed security providers &#8212; and ask one simple question: Do we have a written, signed agreement that spells out what they must do, and how quickly, if they suffer a breach involving credentials or data tied to our environment? If any critical vendor cannot be tied to that commitment, it should move to the top of the contract review list.</p><h1>WEEK IN BRIEF</h1><h3><span>PRO SERVICES: Liabilities of Trusted Advisors Compounded</span></h3><p><strong>&#128998; WHY IT MATTERS: </strong><span>This is not just a vendor incident. A threat actor known as &#8220;888&#8221; claimed to have stolen 35 gigabytes of data from </span><a href="https://www.bleepingcomputer.com/news/security/accenture-confirms-breach-after-hacker-offers-stolen-data-for-sale/">Accenture</a><span> in July, including source code, RSA encryption keys, SSH keys, Azure personal access tokens, and Azure Storage access keys. Accenture confirmed the breach. The stolen assets are not customer data. They are the credentials and code that underpin how Accenture builds and accesses client infrastructure. This is the firm&#8217;s third confirmed breach since 2021. It advises governments and Fortune 500 companies on cybersecurity posture. When a professional services provider loses control of assets like these, the issue becomes bigger than their breach. It becomes a governance problem for every organization that relies on them.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>The most likely cause is a failure in credential protection, internal access control, or developer environment segmentation. Based on what was reported, this appears consistent with privileged access being exposed or insufficiently contained, allowing the attacker to reach sensitive code and cloud keys. The exact path has not been disclosed. The control weakness is the same regardless: sensitive internal assets were not sufficiently isolated from compromise.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Leadership should require a full inventory of third-party firms with privileged access, administrative rights, or sensitive integrations into the environment. Ask whether those firms use time-limited credentials, enforced multifactor authentication, segmented environments, and continuous monitoring for unusual data movement. If the business cannot get clear answers, the vendor oversight program is too weak for the level of trust being placed in it.</span></p><p><strong>&#129002; REALITY CHECK: </strong><span>This is where the assumption of &#8220;trusted advisor&#8221; security starts to crack. Companies spend a lot of money buying expertise and assume that scale, brand, or reputation equals resilience. It doesn&#8217;t. When a firm that advises others on security cannot protect its own access keys, it stops being a strategic partner and becomes another point of failure in the chain. The board question is not whether Accenture is a good firm. It is whether your organization knows what credentials they hold and what happens to your environment if those credentials leave with an attacker.</span></p><h3><span>SOFTWARE: 7-Month Open-Source Infiltration</span></h3><p><strong>&#128998; WHY IT MATTERS: </strong><span>Modern software supply chains are built on code most organizations never wrote themselves. </span><a href="https://www.securityweek.com/north-korean-hackers-target-open-source-developers-in-supply-chain-attacks/">North Korean state-sponsored hackers</a><span> have been running a campaign called PolinRider since December 2025, compromising legitimate repositories on GitHub, NPM, Packagist, Go modules, and Chrome extensions to deliver backdoors and credential-stealing malware to developers. Socket researchers identified 162 malicious artifacts across 108 packages. The attackers gained control of maintainer accounts, injected obfuscated loaders into legitimate code, and rewrote Git history to make the changes look older than they were. Attackers do not need to breach your perimeter if they can get in through the tools your developers already trust.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>The most likely cause is compromise of maintainer credentials, allowing attackers to publish malicious code through legitimate package channels. The reporting also suggests the malicious changes were obscured and backdated, which points to a deliberate effort to hide the compromise. That is supply chain abuse, not a software bug.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Leadership should ask whether the organization validates the integrity and provenance of open source packages before they enter production. That means knowing whether dependencies are reviewed, whether changes are monitored, whether builds are signed or verified, and whether suspicious package behavior can be detected quickly. If the answer is &#8220;we trust the package registry,&#8221; the control environment is not mature enough.</span></p><p><strong>&#129002; REALITY CHECK: </strong><span>Most organizations say they use open source. Very few can explain how they govern it. The software team may not have written the code, but the business still owns the risk when that code ends up in production. PolinRider did not attack your company. It attacked the developers who maintain the code your developers use. Trust is not a control. In this case, it never was.</span></p><h3><span>HARDWARE: The 100,000-Device Perimeter Vulnerability</span></h3><p><strong>&#128998; WHY IT MATTERS: </strong><span>Exposed infrastructure devices can create direct, persistent access into an organization&#8217;s network. </span><a href="https://www.bleepingcomputer.com/news/security/ubiquiti-warns-of-new-max-severity-unifi-os-vulnerability/">Ubiquiti</a><span> disclosed seven critical vulnerabilities in its UniFi OS platform, including a maximum-severity flaw rated 10.0 out of 10 that allows an attacker with network access to execute arbitrary commands without authentication. Censys tracks over 100,000 UniFi OS instances currently exposed to the internet, nearly 50,000 in the United States. Six of the seven flaws can be exploited in low-complexity attacks requiring no user interaction. Patches are available. Ubiquiti max-severity flaws from June are still being actively exploited by nation-state groups. The question is how many of those 100,000 devices have applied this week&#8217;s patches.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>The most likely cause is a combination of authentication weaknesses, command injection flaws, and insecure handling of administrative functions in the device software. The deeper problem is that Ubiquiti devices are widely deployed as &#8220;set-and-forget&#8221; infrastructure. Large numbers run outdated firmware indefinitely because no one owns the update cycle after go-live.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Leadership should ask IT to confirm every exposed network device, its current firmware level, and whether a patch or mitigation has been applied. The team should also explain how often these devices are inventoried, who owns patch validation, and what happens when a device cannot be updated immediately. If the organization cannot answer those questions, infrastructure patching is not under control.</span></p><p><strong>&#129002; REALITY CHECK: </strong><span>This is exactly the kind of problem that gets waved off as &#8220;just networking.&#8221; That is a mistake. CISA has issued emergency directives requiring federal agencies to patch these devices within days. Nation-state groups have repeatedly used unpatched Ubiquiti equipment to build botnets and proxy malicious traffic. If a device on your network can be turned into an entry point, it is no longer a low-level IT issue. It is a governance issue.</span></p><h3><span>TECHNOLOGY: Firmware Traps and the Silence of Budget Hardware</span></h3><p><strong>&#128998; WHY IT MATTERS: </strong><span>Undocumented access paths in firmware undermine the basic assumption that administrator credentials actually control the device. CERT/CC at Carnegie Mellon disclosed on July 6 that multiple </span><a href="https://www.tomshardware.com/tech-industry/cyber-security/hidden-backdoor-found-in-tenda-routers-goes-unpatched-despite-warnings-from-cybersecurity-researchers-affected-firmware-allows-admin-access-without-a-password">Tenda router</a><span> models contain a hidden secondary login path that grants full administrative access without the configured administrator password. Any username works. CVE-2026-11405 affects at least five firmware families: FH1201, W15E, AC10, AC5, and AC6. There is no patch. Tenda has not responded to CERT/CC&#8217;s disclosure. The FCC cited this exact category of risk when it added Chinese router brands to its national security Covered List in March.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>The most likely cause is an undocumented secondary authentication mechanism left in shipping firmware, whether through deliberate design or poor development hygiene. The practical effect is the same either way: the internal password bypasses configured administrator credentials entirely. That points to a failure in secure development practices, code review, and vendor quality assurance.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Leadership should ask whether the organization has a formal review process for networking equipment before deployment. That includes checking vendor security responsiveness, confirming whether firmware can be patched, and identifying whether undocumented access mechanisms have been reported for any products currently in use. If the vendor cannot support those basics, the equipment should be treated as an elevated risk until that changes.</span></p><p><strong>&#129002; REALITY CHECK: </strong><span>Low-cost hardware gets a pass because it is easy to buy and easy to deploy. That is the problem. Security gaps in cheap infrastructure do not stay cheap once they are inside the environment. Tenda has not responded to the disclosure. The CVE is public. There is no patch. If the vendor won&#8217;t explain what is in the firmware, you are not buying networking equipment. You are buying uncertainty with an Ethernet port.</span></p><h3><span>RETAIL: The Illusion of GDPR Indemnification</span></h3><p><strong>&#128998; WHY IT MATTERS: </strong><span>Vendor breaches still create direct regulatory exposure for the company that collected the data. </span><a href="https://www.techradar.com/pro/security/lidl-customers-across-europe-hit-in-suspected-data-breach-heres-what-we-know">Lidl</a><span>, operating 12,900 stores across 32 countries, disclosed a breach at an unnamed third-party IT service provider that exposed customer names, phone numbers, email addresses, dates of birth, and customer numbers across its online shops in the Netherlands, Belgium, and Germany. Passwords and payment details were not affected. Lidl notified the authorities in each country. The company cannot confirm how many customers are affected or which IT provider was the entry point.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>The most likely cause is a security failure at the third-party provider that held customer data in an environment that was not sufficiently isolated. Based on the reported facts, this looks like a breakdown in third-party access governance or data handling discipline. The problem is not only that the vendor was breached. It is the data arrangement that created avoidable exposure in the first place.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Leadership should require a current inventory of every third party that stores, processes, or can access customer data. Each relationship should be backed by a signed agreement defining security obligations, breach notification timing, audit rights, and minimum technical safeguards. If those terms are missing or outdated, the organization does not have contractual control over its own data environment.</span></p><p><strong>&#129002; REALITY CHECK: </strong><span>People try to separate this too neatly: &#8220;Our vendor got hit, not us.&#8221; Customers do not experience it that way. Regulators do not care about the distinction either. The company still owns the notifications and the fallout. The unnamed vendor faces no public accountability. That is why vendor governance is not a back-office formality. It is part of the security model, and under GDPR, it is part of the legal liability model, whether the contracts say so or not.</span></p><div><hr></div><h1>EXPERT PERSPECTIVE</h1><h2>RISK REDUCTION</h2><h3>CEO &#8216;s Mandated AI at Scale. 11% of Tech Leaders Say They Are Ready. </h3><p><strong>Executive Summary (TLDR):</strong> The <a href="https://ibm.biz/tech-leader-2026">IBM Institute for Business Value 2026 Tech Leader Study</a>, conducted with Oxford Economics and drawing on 2,000 CIOs, CTOs, and C-suite technology leaders across 33 geographies and 19 industries, documents the widest governance gap this newsletter has tracked across any single source. 80% of technology leaders report AI transformation mandates arriving directly from the CEO. 11% say they feel completely prepared for the scale of AI agent deployment expected in the next twelve months. Two-thirds are accountable for outcomes in AI systems they do not fully control. In three weeks, on August 2, 2026, the EU AI Act becomes enforceable, with fines reaching 7% of global annual turnover and a 15-day incident reporting window. The IBM data and the regulatory deadline are arriving simultaneously. The board that has not yet asked whether its AI governance architecture is ready for both is three weeks from finding out the answer the hard way. IBM is a consulting and technology vendor; findings below are assessed independently of IBM&#8217;s commercial recommendations.</p><h4>Highlights</h4><ol><li><p><strong>This Is Not a Governance Gap. It Is an Authority Gap.</strong><br>Two-thirds of CIOs and CTOs in the IBM study say they are accountable for outcomes in AI systems they do not fully control. More than two-thirds report business units bypassing IT to adopt AI. The accountability flows to the technology leadership function. The deployment decisions are being made outside it. </p></li><li><p><strong>The Mandate Is Machine-Speed. The Governance Is Still Human-Speed.</strong><br>By 2027, enterprises expect to deploy an average of 1,661 AI agents, a 38% increase from today. With each agent making hundreds or thousands of decisions per day, organizations are managing hundreds of thousands of autonomous decisions daily. 77% say AI adoption is already outpacing their governance capabilities. </p></li></ol><ol start="3"><li><p><strong>Just Weeks Away, and Most Organizations Are Not Ready.</strong><br>The EU AI Act becomes enforceable on August 2, 2026. High-risk AI systems require documented risk management frameworks, lifecycle audits, and incident reporting within 15 days of a qualifying event. Fines reach 7 % of global annual turnover.</p></li><li><p><strong>54 Incidents Last Year. 17% High Severity.</strong><br>Organizations in the IBM study experienced an average of 54 AI agent incidents in the past twelve months. 17% required more than four hours to contain. The consequences: 37% resulted in data exposure or security breaches, 33% caused cascading system failures, and 17% triggered compliance issues. </p></li></ol><h3>Insight</h3><p>The IBM study reads like a CIO and CTO document, but the EU AI Act turns it into a board issue. That&#8217;s the real shift here.</p><p>Once the business starts deploying AI outside the technology governance process, accountability and control stop lining up, and that&#8217;s where the risk starts to compound.</p><p>The authority gap is the clearest thing in the data. Technology leaders are being held responsible for systems they do not fully control, while business units are moving ahead on their own. That is not a minor coordination problem. It means the organization has approved the outcome without putting the right decision rights, control checks, and escalation paths in place.</p><p>The EU AI Act does not care how that gap developed. It only cares whether the organization can show that it knows what AI systems it has, how they are classified, and how it would respond if something goes wrong. And right now, a lot of organizations clearly cannot do that in a clean, defensible way.</p><p>The reporting timeline is what makes this urgent. If a company cannot quickly identify its AI systems, map them to the risk framework, and document how incidents will be handled, it is not ready for enforcement. The IBM numbers make that problem feel even bigger: many organizations still do not have basic visibility into AI spend, inventory, or governance. That is not maturity &#8212; that is exposure.</p><p>The Banco do Brasil example is useful because it shows what better looks like in practice. Clear ownership, real-time monitoring, traceability, version control &#8212; those are not nice-to-haves. They are the basic controls that make AI governable. If those controls are not in place, the board should assume the organization is still learning in production, and that is a dangerous place to be with this kind of regulatory and operational pressure.</p><p>The question for the board is simple: do we know what AI is running under our name, do we know how it is classified, and can we respond within the required window if something breaks? If the answer takes more than a day to assemble, then the governance model is already behind the environment it is supposed to control.</p><div><hr></div><h1>COMMENT ON THIS EDITION</h1><p><span>This week's incidents share one governance failure: organizations trusted infrastructure they did not verify. If your vendor risk program was built for a world where the perimeter was a firewall, it was not built for the world you live in today. </span></p><p><strong>We want to hear from you: </strong><em><span>Accenture has now confirmed 3 breaches in 5 years. Does that change how your organization thinks about the security posture of outside firms you bring into your environment?</span></em></p><p><span>Reply and tell us where your organization stands on vendor credentialing.</span></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://substack.com/@cybersecuritychronicles/note/p-206897850&quot;,&quot;text&quot;:&quot;Leave a comment&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/substack.com/@cybersecuritychronicles/note/p-206897850"><span>Leave a comment</span></a></p><div><hr></div><p><strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a><br></strong>Author &amp; Editor, <em>Cyber Risk Governance Insights;</em> Vice President, <a href="https://www.linkedin.com/company/netswitch-technology-management/">Netswitch, Inc.</a></p><h2></h2><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h2>Every incident this week started with access that nobody was watching.</h2><p>If your organization cannot produce a current inventory of every vendor with access to your systems or customer data, and the last date that access was reviewed, you are carrying the same exposure that put two dozen companies on a breach notification list this week.</p><p>Netswitch offers a complimentary cyber risk governance health check that starts exactly there. No questionnaire theater. A real conversation about what your vendor access picture looks like and what it should.</p><p><strong><a href="https://www.netswitch.net">Schedule a conversation with Netswitch</a></strong></p><p>Connect with the <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> on LinkedIn, 6,200+ board members, CISOs, and compliance leaders who read this newsletter for the same reason you do.</p><p>Attend the next Cyber Risk Governance Live event. One hour. No vendor pitches. Real governance conversations with people who have the same problems you do.</p><h4>Get It Done.</h4><p>Reach out to <a href="https://netswitch.net/">Netswitch, Inc.</a> today.</p><div><hr></div><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[You don't have a detection program. You have a hope.]]></title><description><![CDATA[Edition 133: Why modern organizations routinely discover intruders weeks or months too late.]]></description><link>https://cybersecuritychronicles.substack.com/p/you-dont-have-a-detection-program</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/you-dont-have-a-detection-program</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 06 Jul 2026 21:21:20 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em><strong>This week we see</strong>&#8230; <span>in every case, the attacker was already inside before the organization knew to look. Detection is the governance gap that ties this week together. Not prevention but detection.</span></em></p><h1>&#10024; QUICK WIN</h1><p><span>Ask your CISO one question this week: &#8220;Show me documentation of the last time we tested our ability to detect an unauthorized user moving through our network &#8212; and tell me how long that user could have gone unnoticed before an alert fired.&#8221;</span></p><p><span>If the answer is vague, measured in weeks, or nonexistent, you do not have a detection program. You have hope.</span></p><h1>WEEK IN BRIEF</h1><h3>GOVERNMENT: &#8220;Trusted Network&#8221; Perimeter is an Illusion</h3><p><strong>&#128998; WHY IT MATTERS: </strong><span>The </span><a href="https://www.bleepingcomputer.com/news/security/dhs-confirms-hackers-breached-hsin-info-sharing-platform/">Department of Homeland Security</a><span> confirmed that hackers breached the Homeland Security Information Network (HSIN), the sensitive-but-unclassified platform used by federal, state, local, and private-sector partners to share threat intelligence, coordinate event security, and manage incident response. The intrusion occurred between late May and early June. DHS says no classified systems were hit &#8212; but HSIN is the platform where agencies share security planning for events like the World Cup matches currently hosted across the United States. This is also HSIN&#8217;s second significant security failure; a 2023 coding error by a contractor exposed restricted intelligence data to thousands of unauthorized users.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>An unpatched vulnerability on a legacy government system. HSIN has long been flagged as aging infrastructure operating in a threat environment it was not designed for.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Require your IT leadership to produce a written inventory of every system classified as &#8220;legacy&#8221; that still holds sensitive operational data. For each one, document the date of its last security assessment and the timeline for either modernization or decommissioning. If that inventory does not exist, your highest-risk systems are the ones nobody is tracking.</span></p><p><strong>&#129002; REALITY CHECK: </strong>A government platform built for threat intelligence sharing got breached, and DHS still can&#8217;t say exactly what was taken. That&#8217;s the point: the problem isn&#8217;t just an IT issue; it&#8217;s the comfort people get from thinking a system is safe just because it sits inside a &#8220;trusted&#8221; network. Once the platform you rely on to coordinate response is the one under attack, trust starts breaking down fast, partners get more cautious about what they share, and the incident stops being just another breach; it becomes part of the problem.</p><h3>SUPPLY CHAIN: Breached System Wasn&#8217;t Even the Target</h3><p><strong>&#128998; WHY IT MATTERS: </strong><span>ShinyHunters exploited a zero-day vulnerability in Oracle PeopleSoft, the HR and payroll platform used by hundreds of organizations, to breach over 300 instances across 100 companies between May 27 and June 9. </span><a href="https://www.bleepingcomputer.com/news/security/nissan-discloses-employee-data-breach-linked-to-oracle-zero-day-attacks/">Nissan</a><span> was specifically targeted. Exposed data for current and former employees across the U.S., Canada, Mexico, and Brazil includes Social Security numbers, banking information, tax records, and dependent information. Nissan learned of the breach from Oracle &#8212; not from its own detection. While Nissan responds, ShinyHunters is actively leaking data from other PeopleSoft victims, including universities and the National Association of Insurance Commissioners.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>An unpatched zero-day vulnerability in a vendor-managed HR platform. Nissan had no direct visibility into Oracle&#8217;s system security posture before the exploit. The attack exposed the structural gap between enterprise software dependency and enterprise security accountability.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Require your procurement team and legal counsel to produce the contractual commitments that major software vendors have made regarding vulnerability disclosure timelines and patch notifications. For every enterprise platform that holds employee PII or financial data, document who is responsible for detecting a breach, you or the vendor, and how fast you will know.</span></p><p><strong>&#129002; REALITY CHECK: </strong>Nissan didn&#8217;t lose control because it failed to patch its own environment. It lost control because the vendor holding its employee data had become an attack surface Nissan wasn&#8217;t actually watching. That&#8217;s the governance problem boards keep missing: contracts can move data, but they don&#8217;t magically move accountability. When your HR platform gets breached, the real question isn&#8217;t whether the vendor had a duty to tell you; it&#8217;s how fast they&#8217;re required to tell you, what they&#8217;re obligated to disclose, and what you can actually do when they don&#8217;t.</p><h3>INSURANCE: Breached 10 Days Before Anyone Noticed</h3><p><strong>&#128998; WHY IT MATTERS: </strong><span>Between June 15 and June 25, attackers accessed </span><a href="https://www.securityweek.com/aflac-japan-data-breach-impacts-4-38-million/">Aflac Japan</a><span>&#8216;s policyholder portal multiple times before the company noticed abnormal system load and pulled the thread. The exposed data covers 4.38 million customers and agents, their names, addresses, phone numbers, dates of birth, insurance account details, plus banking information for 230,000 individuals. This is Aflac&#8217;s second major breach event in roughly a year; a June 2025 U.S. incident exposed data on over 22 million people. Japan&#8217;s data protection regulator is tightening enforcement powers as this disclosure lands.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>Inadequate monitoring of a customer-facing portal. Attackers accessed the system repeatedly over ten days without triggering sufficient alerts to prompt intervention. The detection mechanism that ultimately identified the breach was a spike in server load &#8212; not a security control.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Require your security leadership to demonstrate that your customer-facing portals have defined behavioral baselines and that deviation from those baselines triggers an alert reviewed by a human within 24 hours. If the answer is that alerts go to a queue, ask who reviews the queue and how often.</span></p><p><strong>&#129002; REALITY CHECK: </strong>This wasn&#8217;t a breach that happened in the dark and got discovered by a clever control. It was a breach that kept happening for ten days because nobody was watching the portal closely enough to notice the difference between normal traffic and abuse. That&#8217;s the part boards need to hear: if the first signal is server load, your security program is lagging the attack, not detecting it.</p><h3>MANUFACTURING: A Month-Long Data Exfil Party</h3><p><strong>&#128998; WHY IT MATTERS:</strong> <a href="https://www.bleepingcomputer.com/news/security/kubota-says-hackers-had-month-long-access-to-network-systems/">Kubota North America Corporation</a><span> disclosed that hackers had access to its network systems from March 16 to April 20 &#8212; 35 days. The attacker accessed files containing employee and dependent data, including Social Security numbers, taxpayer IDs, driver&#8217;s license numbers, direct deposit banking information, corporate payment card numbers, and benefits enrollment data. Kubota is a $20 billion Japanese manufacturer operating in 120 countries with more than 52,000 employees. No ransomware group has claimed responsibility, and Kubota reports no operational disruption.</span></p><p><strong>&#129000; PROBABLE CAUSE: </strong><span>Absence of effective network monitoring capable of detecting prolonged unauthorized access. A 35-day dwell time is not a sophisticated evasion achievement; it reflects a detection gap that no alert closed for over a month.</span></p><p><strong>&#129001; PROACTIVE PREVENTION: </strong><span>Ask your security leadership to define your organization&#8217;s target &#8220;mean time to detect&#8221; for unauthorized access, the maximum number of hours between an intrusion and an alert. Get the number in writing. Then ask for the last three documented test results that validate it. If those tests have not been run, the number is aspirational, not operational.</span></p><p><strong>&#129002; REALITY CHECK: </strong>35 days inside a network is not a sophisticated success story; it&#8217;s a governance failure that sat unchallenged for more than a month. If an attacker can move through employee, dependent, banking, payment card, and benefits data for many days without triggering a decisive response, then your board is not looking at a detection program; it&#8217;s looking at a hope statement.</p><p>What exactly is the organization paying for if unauthorized access can sit in production that long and still be described as &#8220;no operational disruption&#8221;? Boards should not accept dwell time as an after-the-fact metric. They should demand a written detection target, proof it is tested, and a clear explanation of why the last intrusion was allowed to outrun it.</p><div><hr></div><h1>EXPERT PERSPECTIVE</h1><h3>RISK REDUCTION - The Skill Floor Just Dropped to Zero</h3><p><strong>Executive Summary (TLDR):</strong> <a href="https://www.theregister.com/security/2026/07/02/smooth-ai-criminal-drives-first-end-to-end-agentic-ransomware-attack/">Sysdig&#8217;s Threat Research Team</a> has documented what it assesses to be the first fully autonomous, end-to-end agentic ransomware operation, a threat actor it named JadePuffer that used a large language model to execute an entire extortion campaign without a human operator directing a single step. The agent gained access through a known vulnerability, harvested credentials, moved laterally, established persistence, encrypted 1,342 production configuration records, deleted the originals, and dropped a Bitcoin ransom demand, then left without saving the decryption key, making recovery impossible regardless of payment. In one sequence, when a login attempt failed, the agent diagnosed the cause and issued a working fix in 31 seconds. This is not a preview of where ransomware is going. It is the first confirmed arrival.</p><h2>Highlights</h2><p><span>1. </span><strong>The Attack Completed Before a Human Was Paged. </strong>JadePuffer executed more than 600 distinct payloads across reconnaissance, credential theft, lateral movement, privilege escalation, encryption, and data destruction, all autonomously.</p><p><span>2. </span><strong>This Was Destruction Dressed as Extortion. </strong>Paying the ransom would not have recovered the 1,342 encrypted Nacos configuration records. The data is gone regardless of what the victim organization decides.</p><p><span>3. </span><strong>The Entry Point Was a 2021 Vulnerability. </strong>JadePuffer did not use a zero-day. It exploited CVE-2025-3248 in an internet-facing Langflow instance and a 2021 authentication bypass to reach the production database. </p><blockquote><p>&#8220;The skill floor for running ransomware has dropped to whatever it costs to run an agent, and if that agent is running on stolen credentials through LLMjacking, the cost to an attacker is close to zero.&#8221;</p></blockquote><h2>Insight</h2><p>JadePuffer should make every board rethink whether it&#8217;s still working from an old ransomware playbook.</p><p>We&#8217;ve been saying for a while that AI adoption is moving faster than AI governance. CISA has said to fold AI into existing governance. ISACA found that 56% of organizations still can&#8217;t say how long it would take to contain an AI system during an incident. Gartner has shown that when organizations cut human oversight to chase efficiency, they usually pay for it later. JadePuffer takes all of that out of the theoretical and turns it into an operational warning.</p><p>What&#8217;s disturbing isn&#8217;t just that the attack was autonomous. It&#8217;s how quickly it adapted. A failed login was fixed in 31 seconds. A parsing error was corrected on the next attempt. That&#8217;s not how normal ransomware runs. That is an attacker that doesn&#8217;t wait, hesitate, or hand off to a human when the environment changes.</p><p>And then there is the key point: the decryption key was never saved. So, this was not really extortion in the traditional sense. It was destruction with a ransom note attached.</p><p>That changes the board conversation. Backup and recovery still matter, but they can&#8217;t be built on the old assumption that paying the ransom or getting the key back is part of the recovery plan. In this case, the data was gone either way.</p><p>The real lesson isn&#8217;t that ransomware got more advanced in some abstract way. It&#8217;s that the skill floor dropped. This attack didn&#8217;t require a highly trained criminal crew running a custom operation with a lot of human coordination. It took a known vulnerability, default credentials, and an agent that could run without supervision.</p><p>That means the threat model has changed for everyone. If your internet-facing systems are neglected, your vulnerabilities are old, and your exposure is still being managed as if the attacker needs to think like a person, then you are already behind. The question for leadership is simple: how fast can we detect and stop an attack that finishes most of the job before a human responder would even be paged?</p><div><hr></div><h3>RISK REDUCTION - The Rules Didn&#8217;t Change; Organizations Did</h3><p><strong>Executive Summary (TLDR):</strong> In <a href="https://youtu.be/QqZA-nuIIHw?si=dcihodx6Qt2qXX0L">June&#8217;s Cyber Risk Governance Live</a>, Carolyn Troiano, FDA data integrity specialist and regulatory compliance advisor with decades of experience inside regulated industries, walked through a finding that every board operating under any compliance framework needs to hear before its next audit cycle. FDA warning letters citing data integrity failures have increased 380% over five years. Not because the FDA rewrote the rules. Because organizations that have always run their operations with audit trails turned off, shared logins across teams, and records nobody could trace back to a specific authorized person finally got caught at scale. The compliance gap is not regulatory. It is operational. The full conversation is available on the Cybersecurity Chronicles LinkedIn page and is worth the hour.</p><h2>Highlights</h2><p>Defensible by Design is not an IT project. It is an operational architecture decision.</p><ol><li><p><strong>The FDA Does Not Want Your Policy Manual. </strong>Troiano distilled 4 things the FDA actually requires an organization to prove: who did what, when, and why; that nobody tampered with critical records; that systems are what the organization claims they are; and that controls have been tested and work.</p></li><li><p><strong>The Governance Failure Nobody Wants to Name. </strong>Organizations that have handed compliance program management to a vendor and treated that handoff as the end of the accountability question have made a foundational governance error.</p></li><li><p><strong>Compliance Theater Has a Known Cost. </strong>The 380% increase documents organizations that have spent years producing compliance artifacts, policy manuals, procedure documents, and audit-ready folders, without designing operations to generate the underlying evidence that those artifacts are supposed to reflect.</p></li></ol><p>FDA-regulated organizations have had forty years to internalize what every other sector is now learning under SEC disclosure rules, HIPAA updates, and NIST frameworks: compliance is not what you prove at audit time. It is what falls naturally out of operations built to generate it. Audit trails are automatic. Access logs by default. Vendor activity is documented at the moment it occurs, not reconstructed afterward.</p><p>Troiano&#8217;s board question is the right one: <em>If a regulator asked tomorrow for proof that data integrity controls were operating, could the organization answer immediately and confidently?</em></p><h2>Insight</h2><p>Troiano&#8217;s FDA data integrity framework fits a pattern this newsletter has been tracking for months: too many organizations still operate as if compliance is something you assemble later, instead of something your systems produce all the time.</p><p>That is the real problem. The Cowbell 2026 insurance data showed 31% of SMB claims were denied because organizations could not prove controls were operating when the loss occurred. The Fastly report found that AI-first organizations paid 135% more when incidents hit, in part because their governance structures were not built to generate defensible evidence. DragonForce stayed hidden for two months because the monitoring stack was never designed to question trusted traffic. JadePuffer was able to run a full ransomware operation autonomously because the detection model assumed a human attacker behaving in familiar ways.</p><p>Troiano is describing the same failure from the FDA side: organizations keep treating evidence as something to reconstruct after the fact, when the better approach is to design operations so the evidence exists automatically.</p><p>That is why her board question matters well beyond regulated industries. If a regulator asked tomorrow for proof that your data integrity controls were working, could you answer immediately and confidently? If not, the gap is probably not in your policy manual. It is in how the business actually runs.</p><div><hr></div><h1>COMMENT ON THIS EDITION</h1><p><span>This week&#8217;s briefing exposed a massive pattern: major organizations discovering, weeks or months after the fact, that someone had already been inside their network. If a $20 billion manufacturer can host an intruder for 35 days with &#8220;no operational disruption,&#8221; it&#8217;s time to change how we measure readiness.</span></p><p><strong>We want to hear from you: </strong><em>Does your board actually track Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR), or are security metrics still benchmarked entirely on system uptime and operational continuity?</em></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://substack.com/@cybersecuritychronicles/note/p-205666458&quot;,&quot;text&quot;:&quot;Leave a comment&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/substack.com/@cybersecuritychronicles/note/p-205666458"><span>Leave a comment</span></a></p><div><hr></div><p><strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a><br></strong>Author &amp; Editor, <em>Cyber Risk Governance Insights;</em> Vice President, <a href="https://www.linkedin.com/company/netswitch-technology-management/">Netswitch, Inc.</a></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/p/you-dont-have-a-detection-program?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/p/you-dont-have-a-detection-program?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><h2>Every breach this week started with access that nobody was watching.</h2><p>If your organization cannot produce a current inventory of every vendor with access to your systems or customer data, and the last date that access was reviewed, you are carrying the same exposure that put two dozen companies on a breach notification list this week.</p><p>Netswitch offers a complimentary cyber risk governance health check that starts exactly there. No questionnaire theater. A real conversation about what your vendor access picture looks like and what it should.</p><p><strong><a href="https://www.netswitch.net">Schedule a conversation with Netswitch</a></strong></p><p>Connect with the <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> on LinkedIn, 6,200+ board members, CISOs, and compliance leaders who read this newsletter for the same reason you do.</p><p>Attend the next Cyber Risk Governance Live event. One hour. No vendor pitches. Real governance conversations with people who have the same problems you do.</p><h4>Get It Done.</h4><p>Reach out to <a href="https://netswitch.net/">Netswitch, Inc.</a> today.</p><div><hr></div><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Cyber Risk Governance Insights | June 29, 2026 | Edition No. 132]]></title><description><![CDATA[Where cybersecurity incidents become board-level accountability decisions]]></description><link>https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-da2</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-da2</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 29 Jun 2026 20:42:27 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em><strong>This week we see</strong>&#8230; <span>five incidents. Five different industries. One consistent entry point: access granted to a third party, never systematically reviewed, and present when the attacker arrived. The attack vectors varied. The governance failure did not.</span></em></p><h1>&#10024; QUICK WIN</h1><p>Direct your IT leadership to produce a list of all service accounts, API tokens, and OAuth credentials created more than 24 months ago and still active in production, along with their business justification.</p><p>If they cannot produce this audited list within 24 hours, establish a formal credential lifecycle audit process before month-end as a board-level directive. Not an IT project.</p><h1>WEEK IN BRIEF</h1><h4>TELECOM: Credentials of 14.2 Million Exposed by Breach</h4><p><span>&#128998;</span> <strong>WHY IT MATTERS</strong>: <a href="https://www.bleepingcomputer.com/news/security/data-breach-exposes-up-to-142-million-email-logins-at-six-isps/">KDDI Corporation</a>, one of Japan&#8217;s largest telecommunications providers, disclosed unauthorized access to its shared email system serving five other Japanese ISPs: STNet, JCOM, Chubu Telecommunications, NIFTY, and BIGLOBE. Up to 14.22 million email addresses and passwords may have been exposed across current, former, and inactive customer accounts. The breach involved attackers exploiting a vulnerability in unnamed third-party software embedded in KDDI&#8217;s email backend. KDDI detected the compromise on June 17 and immediately blocked the attacker, but the scope includes credentials for users of six separate ISP email services across Japan. KDDI has notified Japan&#8217;s Personal Information Protection Commission and the Ministry of Internal Affairs and Communications.</p><p><span>&#129000;</span> <strong>PROBABLE CAUSE</strong>: Direct exploitation of a public-facing vulnerability in unnamed third-party software embedded within backend email architecture (MITRE ATT&amp;CK T1190). No phishing or malware was required; the shared architecture acted as a force multiplier for the attacker.</p><p><span>&#129001;</span> <strong>PROACTIVE PREVENTION</strong>: Audit all shared infrastructure components; mandate a strict 30-day patch deployment window for all third-party authentication, email, or directory software; and require executive sign-off to keep any unpatched system online.</p><p><span>&#129002;</span> <strong>REALITY CHECK</strong>: Your organization relies blindly on shared infrastructure vendors whose patch management routines you cannot see. If a foundational third-party component you depend on is vulnerable, do you know exactly who supplies it, what version is currently deployed, and how quickly they patch?</p><h4>SUPPLY CHAIN: 200,000 Proprietary Files Leaked by Critical Supplier</h4><p><span>&#128998;</span> <strong>WHY IT MATTERS</strong>: <a href="https://www.reuters.com/business/media-telecom/apple-supplier-tata-tightens-internal-controls-after-data-breach-sources-say-2026-06-26/">Tata Electronics</a>, a key Apple supplier manufacturing iPhone components in India, detected a cybersecurity incident and is now restricting employee access to sensitive internal systems. The ransomware group World Leaks posted more than 200,000 files to the dark web, including component design and specification documents related to Apple and Tesla, both Tata customers. Tata stated there was no impact on operations. The company has hired a global consultant to conduct a forensic audit and has reported the incident to the Indian government and its clients. India is on track to manufacture 26 percent of the world&#8217;s iPhones in 2026, up from 6 percent four years ago. Tata&#8217;s breach represents both supply chain risk and geopolitical supply chain concentration risk.</p><p><span>&#129000;</span> <strong>PROBABLE CAUSE</strong>: Sustained, unauthorized lateral access to shared engineering repositories or product data environments, allowing attackers to vacuum up massive design files across multiple premier corporate clients.</p><p><span>&#129001;</span> <strong>PROACTIVE PREVENTION</strong>: Enforce strict data segregation clauses in manufacturing contracts. Require suppliers to store proprietary data in isolated repositories, mandate multi-factor authentication for data access, and perform monthly access log reviews.</p><p><span>&#129002;</span> <strong>REALITY CHECK</strong>: Your intellectual property and component blueprints sit on third-party servers all over the globe. If your primary manufacturing supplier was breached tonight and your data hit the dark web, how many days or weeks would pass before their executive team actually notified yours?</p><h4>HEALTHCARE: AI Vendor Hides Breach for 135 Days, Exposed 1.4M PHI</h4><p><span>&#128998;</span> <strong>WHY IT MATTERS</strong>: <a href="https://healthexec.com/topics/health-it/cybersecurity/data-breach-healthcare-ai-vendor-exposes-records-14m-patients">Healthcare utilization AI vendor Xsolis</a> a Tennessee-based healthcare AI vendor providing utilization management software to hundreds of hospitals and health plans, disclosed a data breach affecting 1,396,519 individuals across seven major hospital systems, including Mayo Clinic, UW Medicine, VHC Health, and Legacy Health. The breach exposed names, Social Security numbers, addresses, dates of birth, medical treatment information, and health insurance details. A targeted phishing attack on January 20, 2026, gave attackers a two-day window inside Xsolis&#8217;s network. The company detected the breach on January 22 but did not report it to HHS until June 5&#8212;a gap of 135 days. HHS posted the breach publicly on June 22. Most affected patients didn&#8217;t even know that Xsolis existed, as the company operates as a HIPAA Business Associate, invisible to end patients.</p><p><span>&#129000;</span> <strong>PROBABLE CAUSE</strong>: A targeted phishing attack against a user granted attackers a 48-hour unrestricted window inside the network. While the breach occurred on January 20, Xsolis delayed federal reporting to HHS for 135 days.</p><p><span>&#129001;</span> <strong>PROACTIVE PREVENTION</strong>: Audit all business associates and vendor contracts. Mandate a contractually binding breach notification timeline requiring the vendor to notify your organization within 24 hours of discovery and report to federal regulators within 30 days.</p><p><span>&#129002;</span> <strong>REALITY CHECK</strong>: For 135 days, hospital boards confidently assured stakeholders their patient data was secure when it was actually sitting on criminal forums. Does your board have independent, real-time visibility into third-party breach timelines, or are you entirely at the mercy of a vendor&#8217;s self-reported clock?</p><h4>SUPPLY CHAIN UPDATE: 4-Year-Old Stale Credential Breach Point</h4><p><span>&#128998;</span> <strong>WHY IT MATTERS</strong>: <a href="https://techcrunch.com/2026/06/23/klue-says-hackers-stole-credential-from-2022-that-led-to-customer-data-breaches/">Market intelligence platform Klue</a> confirmed that the OAuth token theft attack detected on June 12 was enabled by a credential created in 2022 for a limited pilot program that was abandoned but never revoked. Klue stated the credential was &#8220;originally provided to a third party in 2022, for a limited pilot,&#8221; but the company declined to explain the purpose of the pilot, how long it ran, identify the third party, or explain why it remained active for four years after the pilot ended. Attackers used this credential to push malicious code that harvested OAuth tokens from 200+ affected customers. Klue&#8217;s CEO acknowledged the incident was a &#8220;deliberate criminal act&#8221; and the company is communicating with the Icarus threat group attempting to delete stolen data.</p><p><span>&#129000;</span> <strong>PROBABLE CAUSE</strong>: A total credential lifecycle governance failure. A prototype credential was left active in production indefinitely rather than being automatically expired and deleted when the short-term project concluded.</p><p><span>&#129001;</span> <strong>PROACTIVE PREVENTION</strong>: Establish automated credential lifecycles. Any API token, service account, or OAuth credential generated for a pilot or prototype must have a hardcoded, automatic expiration date set at the moment of creation.</p><p><span>&#129002;</span> <strong>REALITY CHECK</strong>: A project your company abandoned years ago is likely still holding keys to your production network. If you audited your active service accounts today, how many ancient, forgotten credentials would you find that have no valid business purpose but carry absolute access?</p><h4>HEALTHCARE: Breach Abandons Patient Data for 18 Months</h4><p><span>&#128998;</span> <strong>WHY IT MATTERS</strong>: <a href="https://www.waff.com/2026/06/26/huntsville-hospital-patients-data-exposed-third-party-security-breach/">Huntsville Hospital Health System</a> is notifying patients that personal health information was accessed during a breach at Cerner, a third-party electronic health record vendor now part of Oracle Health. Cerner notified Huntsville Hospital on August 12, 2025, that unauthorized access to legacy Cerner systems had occurred as early as January 22, 2025. The hospital did not notify patients until June 26, 2026. Attackers had access to personal health information for approximately 18 months before detection. Compromised data includes names, Social Security numbers, medical records, and clinical data, including diagnoses and prescribed medications. Law enforcement directed a delay in patient notification to avoid interfering with its investigation. Huntsville Hospital explicitly states the incident did not involve Huntsville&#8217;s own systems, but rather Cerner&#8217;s legacy infrastructure.</p><p><span>&#129000;</span> <strong>PROBABLE CAUSE</strong>: Evasion and delayed detection on legacy vendor systems. Attackers compromised the critical (EHR) systems in January 2025, Oracle/Cerner detected it and quietly notified the hospital in August 2025, and law enforcement suppressed public notification until June 2026.</p><p><span>&#129001;</span> <strong>PROACTIVE PREVENTION</strong>: Require EHR and core software vendors to commit to a 30-day notification window in writing. Establish independent, separate internal audit trails to track exactly when vendors disclose incidents vs. when law enforcement intervenes.</p><p><span>&#129002;</span> <strong>REALITY CHECK</strong>: Patient data was actively compromised for nearly a year and a half before public notification. When law enforcement steps in and suppresses information during an investigation, your executive team can be legally muted. Do your vendor contracts give you the explicit right to protect your patients and notify them even during ongoing federal investigations?</p><h4>INSURANCE: 91-Day Review Delay Follows Breach of 1M+ Policyholders</h4><p><span>&#128998;</span> WHY IT MATTERS: <a href="https://www.wusa9.com/article/news/nation-world/assuranceamerica-data-breach-social-security-what-to-know/507-3a00baba-d58e-47c8-992a-b17eebe61b71">Managing General Agency (MGA) AssuranceAmerica</a>, an insurance intermediary headquartered in Atlanta serving customers through a network of agents, detected malicious activity on March 16, 2026, and suspicious activity on March 17. An unauthorized third party copied multiple data files containing personal information for 1.1+ million policyholders across seven states (California, Massachusetts, Nebraska, South Carolina, Texas, Vermont, Washington). A file review completed on June 15 identified which records were accessed&#8212;a gap of 91 days between detection and full-scope identification. Exposed data includes names, contact information, insurance policies, driver&#8217;s license numbers, tax identification numbers, and Social Security numbers. The company&#8217;s disclosure states no credit monitoring has yet been offered and notes the attack was employee-targeted, but specifics of the phishing vector were not disclosed.</p><p><span>&#129000;</span> <strong>PROBABLE CAUSE</strong>: An employee-targeted phishing attack compromised corporate credentials, giving hackers access to bulk databases. Due to complex data sprawl, it took external forensic specialists 91 days just to parse the files and identify what was stolen.</p><p><span>&#129001;</span> <strong>PROACTIVE PREVENTION</strong>: Implement automated data classification systems. Any bulk file access, copying, or exfiltration of documents containing Social Security numbers or drivers&#8217; licenses by non-privileged accounts must trigger real-time, automated block-and-alert mechanisms.</p><p><span>&#129002;</span> <strong>REALITY CHECK</strong>: It took over three months just to figure out <em>which</em> files the hackers walked away with. If your organization suffered a network breach today, can your security operations team identify exactly what data was stolen within 24 hours, or will forensic complexity delay your regulatory clock by months?</p><div><hr></div><h1>EXPERT PERSPECTIVE</h1><h3>RISK RETENTION: &#8220;Resolved&#8221; Data Breach is A Myth</h3><p><a href="https://www.securityweek.com/more-klue-breach-victims-identified-as-hackers-get-hacked/">SecurityWeek&#8217;s coverage</a> of the Klue-Salesforce supply chain incident has taken a turn that reads like dark comedy but is, in governance terms, a precise illustration of permanent data liability. Attackers used compromised legacy credentials to breach Klue, a market intelligence platform, on June 11 and 12, 2026, obtaining OAuth tokens that provided access to customer Salesforce integrations and exfiltrating data from an estimated 195 organizations. Roughly two dozen companies, including security firms BeyondTrust and LastPass, have notified customers of the impact. Then the attackers themselves were hacked by a second threat actor, who is now running a separate extortion campaign against Klue&#8217;s customers using data stolen from the first attacker. The irony is surface-level. The governance implication is not.</p><h4>Highlights</h4><ol><li><p><strong>The Stale Key Threat</strong>. The entire cascade began with compromised legacy credentials at Klue. Not a zero-day exploit. Not a sophisticated nation-state technique.</p></li><li><p><strong>Authentication Sprawl as a Force Multiplier.</strong> Once inside Klue, attackers did not need to breach each customer individually. The Klue integration had already done the work; OAuth tokens connecting Klue to customer Salesforce environments provided the lateral path.</p></li><li><p><strong>The Reality of Permanent Data Liability.</strong> Klue reportedly negotiated with the original attacker, Icarus, who began deleting the stolen data. Then Icarus was hacked by a second group, which is now running its own extortion campaign.</p></li></ol><h3>INSIGHT</h3><p>The Klue incident is not primarily a story about a vendor that got breached. It is a story about what data liability actually looks like once data leaves organizational control &#8212; and why the board-level assumption that a ransom negotiation or an attacker&#8217;s neutralization resolves the exposure is structurally wrong.</p><p>The cascade here is worth tracing precisely because it is not unusual. A legacy credential at a trusted vendor provided initial access. An OAuth integration that was never audited for actual access scope provided lateral movement into customer environments. A ransom negotiation that appeared to resolve the incident was itself interrupted when the attacker&#8217;s own security failed. The data is now in a third party&#8217;s hands that no one contracted with, no one audited, and no one can negotiate with on terms the original affected organizations can verify. The chain of custody for this data is, from the affected organizations&#8217; perspective, completely invisible.</p><p>This is the governance implication that vendor risk programs were not designed to address and that most boards have not yet internalized. Third-party risk governance asks whether vendors have controls. It does not address what happens to organizational data after a vendor fails and the data enters a secondary market of threat actors who have no contractual relationship with anyone in the original transaction. The Klue situation has now produced exactly that outcome: data stolen from 195 organizations, renegotiated by the original attacker, and then re-exfiltrated by a second attacker who operates entirely outside any governance framework any of those organizations have ever evaluated.</p><p>The security vendor's presence on the victim list is worth one additional observation. The question the boards should be asking is not how security companies ended up on a supply chain breach notification list. The question is whether any vendor risk program would have caught a legacy credential problem at a market intelligence platform whose primary value proposition has nothing to do with cybersecurity. The answer, almost certainly, is no &#8212; because third-party risk programs prioritize vendors by category of access rather than by the actual exposure their integrations create. Klue had OAuth access to customer Salesforce environments. That access was the risk. The vendor category was not.</p><p><span>The board-level governance mandate this incident produces is not a new vendor questionnaire. It is a standing question that needs an answer before any third-party integration is approved and on a defined audit cycle thereafter: what access does this integration actually carry, what data can flow through it, and what happens to that data if this vendor&#8217;s credentials are compromised? If that question is not in the vendor onboarding process today, the Klue incident is not a cautionary tale. It is a preview.</span></p><h3>RISK EXPOSURE: &#8220;Think Before You Click&#8221; is Dead</h3><p>A <a href="https://x.com/Dagnum_PI/status/2071232147176710333">sophisticated social engineering campaign circulating</a> in late June 2026 and posted about by <a href="https://x.com/Dagnum_PI">Dagnum&#178;</a> on X highlights a dangerous evolution in initial access vectors.</p><p>Attackers build natural, low-pressure rapport under the guise of an interview or project collaboration before inviting the target into a shared Google Workspace. Once clicked, the landing page throws a convincing, spoofed infrastructure error claiming the user&#8217;s &#8220;device authentication certificate has expired.&#8221; It then walks the victim through a three-step keyboard shortcut sequence to open PowerShell and paste an &#8220;update&#8221; command, which immediately drops remote-access malware, completely bypassing standard browser and email defenses.</p><p>The described incident itself is a highly effective user-as-an-execution-engine attack vector. Proving attackers have realized it is much easier to trick an administrator or a knowledge worker into opening the front door for them via PowerShell than it is to fight an enterprise-grade firewall or email gateway.</p><h4>HIGHLIGHTS</h4><ul><li><p><strong>Legitimate Platforms as Trust Vectors:</strong> Attackers are no longer just cloning sketchy domains; they are leveraging the implied trust of native Google Workspace invitations to lower the victim&#8217;s guard.</p></li><li><p><strong>Hard Targets as the Proof of Concept:</strong> This campaign specifically hunts knowledge workers, security enthusiasts, and crypto professionals. If threat actors can successfully deceive tech-literate targets into running command-line scripts, standard corporate users are entirely exposed.</p></li><li><p><strong>The Death of &#8220;Think Before You Click&#8221;:</strong> The conversation flow relies on subtle, conversational timing rather than aggressive panic. It makes pausing to verify feel unnecessary, completely neutralizing basic corporate security awareness training.</p></li></ul><h3>INSIGHT</h3><p>This vector explains why traditional &#8220;verify before you click&#8221; security training is fundamentally broken. The real corporate liability isn&#8217;t a lack of user caution; it is the systemic governance failure of allowing employee behavior to serve as the primary defensive line for endpoint integrity.</p><p>When a deceptive prompt can convince an employee to open PowerShell, the problem isn&#8217;t just human error; it is an architectural gap. If your corporate security posture assumes an identity-verified employee won&#8217;t execute a rogue script under pressure, you have built your perimeter on a comforting myth.</p><p>True governance requires separating user capability from system authority. If a knowledge worker has the local privileges necessary to paste and execute unverified code into a terminal, your technical controls are actively enabling your next breach. Security culture must be backed by hard endpoint restrictions that make this specific execution path an operational impossibility.</p><div><hr></div><h4>REPLY TO THIS EDITION</h4><p>This week&#8217;s pattern comes down to one governance question: does your organization know, right now, every third party that holds access to your systems or customer data, and when each one was last reviewed? Reply and tell me where your organization is on that question. The answers shape future editions.</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://substack.com/@cybersecuritychronicles/note/p-204153487&quot;,&quot;text&quot;:&quot;Leave a comment&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/substack.com/@cybersecuritychronicles/note/p-204153487"><span>Leave a comment</span></a></p><div><hr></div><p><strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a><br></strong>Author &amp; Editor, <em>Cyber Risk Governance Insights;</em> Vice President, <a href="https://www.linkedin.com/company/netswitch-technology-management/">Netswitch, Inc.</a></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-da2?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-da2?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><h2>Every breach this week started with access that nobody was watching.</h2><p>If your organization cannot produce a current inventory of every vendor with access to your systems or customer data, and the last date that access was reviewed, you are carrying the same exposure that put two dozen companies on a breach notification list this week.</p><p>Netswitch offers a complimentary cyber risk governance health check that starts exactly there. No questionnaire theater. A real conversation about what your vendor access picture looks like and what it should.</p><p><strong><a href="https://www.netswitch.net">Schedule a conversation with Netswitch</a></strong></p><p>Connect with the <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> on LinkedIn, 6,200+ board members, CISOs, and compliance leaders who read this newsletter for the same reason you do.</p><p>Attend the next Cyber Risk Governance Live event. One hour. No vendor pitches. Real governance conversations with people who have the same problems you do.</p><h4>Get It Done.</h4><p>Reach out to <a href="https://netswitch.net/">Netswitch, Inc.</a> today.</p><div><hr></div><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Cyber Risk Governance Insights | June 22, 2026 | Edition No. 131]]></title><description><![CDATA[Where cybersecurity incidents become board-level accountability decisions]]></description><link>https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-3f1</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-3f1</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 22 Jun 2026 19:21:18 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<blockquote><p><em><strong>This week we see</strong></em>&#8230; cascading failures due to architectural assumptions creating a crisis of unvalidated trust across supply chains. When an asset is internet-exposed, an unvalidated assumption isn&#8217;t just a blind spot; it&#8217;s an unlocked door that lets threat actors compromise both upstream and downstream access controls simultaneously.</p></blockquote><h1>&#10024; QUICK WIN</h1><p>Ask your CISO:</p><blockquote><p><em><strong>&#8220;Show me proof that we are reviewing current threat intel that may apply to each critical platform integration, and that we&#8217;ve validated our security against real attack methods that have compromised similar infrastructure recently.&#8221;</strong></em></p></blockquote><p>If any validations are older than 90 days or don&#8217;t exist, schedule an audit before the next board meeting.</p><h2>WEEK IN BRIEF</h2><h4>CRITICAL INFRASTRUCTURE: Breach of California Utility Billing Systems</h4><p><strong>&#128998; WHY IT MATTERS: </strong>The <a href="https://www.techradar.com/pro/security/100-days-after-the-iran-war-started-tehran-backed-group-just-breached-california-water-service-but-claims-they-chose-not-to-disrupt-water-access">Iran-linked threat group Handala</a> claimed unauthorized access to California Water Service systems serving approximately two million customers across 100 California communities. The group published 5 gigabytes of stolen data, including customer billing records, personal information, and screenshots of GPS-based infrastructure monitoring systems used by field crews across seven CA districts. Handala framed the operation as retaliation for U.S. military strikes on water facilities in Iran. The group claimed it could have disrupted water service but deliberately chose not to, describing the breach as a warning.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>The attackers gained access to externally facing systems. Analysis by Dataminr confirms the breach involved Cal Water&#8217;s RTKBase instance. From there, attackers moved laterally to access the customer billing database. Initial access vector is unknown. Cal Water&#8217;s preliminary investigation found no disruption to OT or water treatment systems, but the dual-system breach pattern suggests reconnaissance ahead of potential operational impact.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Require documentation of which systems can access critical databases and which systems have any connection to operational infrastructure. Verify that these two system classes are on completely separate networks with no shared authentication, no shared service accounts, and no shared cloud platforms.</p><p><strong>&#129002; REALITY CHECK: </strong>A nation-state actor breached both customer data and infrastructure monitoring systems in the same operation. Cal Water claims no operational disruption occurred, and no SCADA or treatment system compromise is confirmed. But the attackers clearly mapped where the two systems connect. Which means any assumption that attackers could not disrupt water service cannot be verified. If an attacker with a stated doctrine of targeting critical systems demonstrates access to both your customer systems and your operations infrastructure, can you confidently tell your board that your OT is actually isolated?</p><h4>IT INFRASTRUCTURE: Admin Credentials Exposed Across 194 Countries</h4><p><strong>&#128998; WHY IT MATTERS: </strong>A massive credential compromise campaign dubbed <a href="https://arstechnica.com/security/2026/06/massive-breach-spills-credentials-for-thousands-of-sensitive-networks/">FortiBleed</a> has exposed plaintext usernames and passwords for approximately 74,000 Fortinet FortiGate firewalls and VPN gateways across 194 countries. Researchers estimate this represents roughly 50 percent of all Fortinet firewalls currently exposed to the internet. The leaked dataset contains 73,932 unique firewall URLs and references to more than 21,000 affected domains. Affected organizations include Oracle, Chevron, Lenovo, FedEx, Foxconn, Samsung, Comcast, Siemens, PwC, Accenture, and a NATO defense contractor. The data appears to have been compiled through a combination of historical compromises, automated credential harvesting via brute-force attacks, and password cracking using GPU-based infrastructure.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>No new zero-day vulnerability. Instead, attackers scanned the internet for exposed FortiGate devices, attempted a curated list of previously leaked credentials against each appliance, and recorded every login that succeeded. The compromised credentials include both default accounts that were never renamed and organization-specific accounts created by customers themselves.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Network ops teams should maintain a complete, current, and accurate inventory of all security appliances, management interface exposure (internet-facing or restricted), current software version, when administrators last logged in, and confirmation that passwords were reset after the last firmware upgrade. Verify that no management interface is accessible from the internet without additional authentication.</p><p><strong>&#129002; REALITY CHECK: </strong>An attacker with valid administrator credentials can intercept traffic on your security appliances, disable logging, create backdoor accounts, install web shells, or pivot into your internal network. Your assumption that renamed default accounts and password policies are sufficient is unvalidated. Many internet-exposed firewalls have similar insecure settings. Which means if your organization has an internet-exposed security appliance, the probability that valid credentials for that device are already circulating in criminal underground communities is pretty good.</p><h4>HEALTHCARE: State-Linked Breach of Medical Research Institutions</h4><p><strong>&#128998; WHY IT MATTERS: </strong>A <a href="https://www.bleepingcomputer.com/news/security/chinese-hackers-breach-redcap-servers-steal-medical-research/">China-linked espionage campaign attributed to UNC6508</a> compromised REDCap (Research Electronic Data Capture) servers at North American medical research institutions. The campaign began in September 2023 and continued undetected through November 2025, for more than 14 months. Attackers deployed custom malware called InfiniteRed designed specifically for REDCap systems. The malware persisted through software upgrades by trojanizing legitimate REDCap system files using a hardcoded GUID. Attackers harvested login credentials submitted through REDCap interfaces and later used administrator access to create email forwarding rules that automatically exfiltrated messages matching specific keywords: geo-strategic policy, military strategy, advanced technology, AI, uncrewed vehicles, offensive cyber programs, and medical research. Collection patterns align with stated strategic interests of the People&#8217;s Republic of China.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Initial access vector unknown. Attackers targeted externally exposed software instances running older, vulnerable versions. Google Threat Intelligence observed the group probing legacy deployments.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Audit all software instances to identify which are internet-facing and which are running legacy versions alongside current installations. Remove all old legacy deployments that are not actively in use. Enforce two-step verification on all administrator accounts.</p><p><strong>&#129002; REALITY CHECK: </strong>Attackers remained inside medical research networks for 14 months, silently harvesting credentials and forwarding emails matching keywords to an external account. Your organization assumes that email forwarding rules are a benign administrative feature that doesn&#8217;t need continuous auditing. Your assumption that legacy versions of research software can safely run alongside current versions is unvalidated. Which means a state-sponsored actor can compromise your clinical trial data, harvest it, and use it for follow-on intelligence operations without triggering alerts. So ask yourself&#8230; if an attacker remained in my network undetected, how would I know my own environment isn&#8217;t currently compromised similarly?</p><h4>MEDTECH: Breach Disclosed After Exfiltration of PHI &amp; Ransom Demand</h4><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.bleepingcomputer.com/news/security/irhythm-discloses-data-breach-says-hackers-stole-patient-info/">iRhythm Technologies</a>, a cardiac monitoring company serving more than 8 million patients, disclosed a data breach after unauthorized actors gained access to third-party-hosted business applications and exfiltrated patient protected health information, proprietary data, and personal information. The company discovered the breach on June 8. On June 9, a threat actor claimed responsibility and demanded payment in exchange for not publicly disclosing the stolen data. iRhythm determined the incident was material given the volume of potentially affected data. The company emphasized that its clinical device systems, manufacturing infrastructure, patient safety systems, and financial reporting systems were not affected. No specific threat actor or ransomware group claimed responsibility.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Initial access through social engineering against third-party-hosted business applications. It was not disclosed as to which third-party platforms were compromised or whether the initial compromise vector involved credential theft, phishing, or exploitation of known vulnerabilities. The company confirmed exfiltration of certain data but stated its investigation into the types and volume of stolen information is ongoing. The timeline between discovery (June 8) and extortion demand (June 9) suggests rapid detection and threat actor confidence.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Require an inventory of all third-party business applications that store or process restricted information, including CRM systems, marketing platforms, customer service tools, and data analytics applications. For each platform, document what data is stored, who of your staff has access, and whether MFA is enforced. Verify that no restricted data is stored in business applications that lack audit logging and data loss prevention controls.</p><p><strong>&#129002; REALITY CHECK: </strong>Sensitive records from 8 million customers were exfiltrated from a business application, not from the core product or service delivery system itself. Your organization likely has sensitive intellectual property or customer data stored in third-party platforms you don&#8217;t regularly audit, i.e., CRM systems, customer success tools, or cloud-based billing platforms. Attackers know this, and the reality is your assumption that data is protected by industry-standard compliance (like SOC2, CCPA or GDPR) at the application level is often unvalidated by the actual access controls enforced at the platform level. Your security posture is only as strong as the most poorly configured third-party tool in your stack.</p><h4>EDUCATION: Breach Exposes PII of Staff via Salesforce Compromise</h4><p><strong>&#128998; WHY IT MATTERS: </strong>The cybercriminal group ShinyHunters (again) breached an education platform (again). <a href="https://www.bleepingcomputer.com/news/security/infinite-campus-data-breach-affects-137-000-school-staff-accounts/">Infinite Campus</a>, one of the largest student information system (SIS) providers in the United States, serving more than 3,200 school districts across 46 states and supporting approximately 11 million students, is the group&#8217;s latest victim. The attackers compromised Infinite Campus&#8217;s Salesforce environment in March 2026 and exfiltrated data for 137,000 school staff members. The stolen data includes names, email addresses, phone numbers, physical addresses, usernames, job titles, employers, and internal support tickets. ShinyHunters used a pay-or-leak extortion model, demanding payment and later publishing the data when demands were ignored. Infinite Campus stated that much of the exposed information consists of directory data commonly found on school websites, but aggregating this information into a single dataset significantly increases risk.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Unauthorized access to an employee&#8217;s platform account on March 18, 2026. Infinite Campus immediately deactivated the compromised account. Salesforce accounts are frequently targeted because they often store sensitive operational data and are connected to downstream customer environments via APIs and integrations. The breach represents a third-party SaaS compromise affecting downstream customers.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Require verification that SaaS admin accounts have mandatory MFA for all users.<span> </span>It should not be optional, not selectively enforced, but mandatory. Document which data is stored in these SaaS instances and which staff have access to each data class. Restrict API token generation and lifetime. Set up alerts for any administrative account accessing sensitive data records in bulk.</p><p><strong>&#129002; REALITY CHECK: </strong>A critical service provider&#8217;s third-party platform environment was compromised, exposing sensitive personnel data. The breach occurred in March but was not disclosed until June, creating a &#8220;visibility gap&#8221; where leadership remains entirely unaware that they are managing a downstream cyber risk at their vendors. If you assume that your vendors&#8217; third-party platforms are secured by mature internal practices, it&#8217;s likely unvalidated by your own oversight. A threat actor can compromise a vendor&#8217;s cloud instance today, and you may not know until they demand payment or publish your sensitive data. Ask yourself, &#8220;Do I have any contractual right to audit my vendor&#8217;s third-party platform access controls, or am I operating entirely on trust?&#8221; Your risk management strategy must evolve from vendor trust to vendor verification.</p><h4>SUPPLY CHAIN: Data Breach via Compromised 3rd Party Integration</h4><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.bleepingcomputer.com/news/security/klue-oauth-breach-linked-to-icarus-salesforce-data-theft-attacks/">Klue, a market intelligence platform</a>, identified unauthorized activity on June 12 affecting its OAuth integration infrastructure. Attackers compromised a legacy credential created for a prototype integration that was never decommissioned. They used this credential to push a malicious code update that harvested OAuth tokens customers use to integrate Klue Battlecards with Salesforce and other third-party platforms. The attackers then used the stolen tokens to query customer Salesforce environments directly and exfiltrate CRM data. Affected organizations include Huntress, Recorded Future, Tanium, Jamf, Sprout Social, Gong, and Insurity. The newly emerged extortion group Icarus claimed responsibility and began sending ransom demands to affected organizations. Salesforce disabled the Klue Battlecards integration on its platform.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Attackers gained access to Klue&#8217;s backend systems using a legacy credential that had been created for a prototype integration and abandoned but never removed from the system. Once inside, they pushed a malicious code update to Klue&#8217;s integration infrastructure. The update captured OAuth tokens, the digital keys customers use to authorize Klue access to their Salesforce, HubSpot, SharePoint, Zoom, Gong, and Slack instances. Attackers then used automated Python scripts to query customer Salesforce APIs, identify valuable CRM records, and exfiltrate business contact data, sales communications, pricing information, and opportunity notes.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Audit all legacy credentials, service accounts, and OAuth tokens in your environment. Identify which credentials and tokens are still active and which should have been decommissioned. Remove all unused credentials. For any remaining authentication tokens that grant third-party applications access to your integrated cloud environments, verify that these tokens have defined expiration dates and cannot be renewed indefinitely. Enforce IP allowlisting for third-party integration accounts so tokens can only be used from expected source IP addresses. Enable MFA for all service accounts that manage integrations.</p><p><strong>&#129002; REALITY CHECK: </strong>Organizations often assume that OAuth tokens inherit the security posture of the platforms that issued them, but that&#8217;s a fallacy because it&#8217;s often unverified. An attacker who compromises a third-party vendor can exploit integrations to exfiltrate data without ever triggering a standard login alert in an environment. True security requires moving beyond passive integration management to active, real-time control over the &#8220;keys&#8221; you have distributed to your vendor ecosystem.</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-3f1?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-3f1?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><h2>EXPERT PERSPECTIVE</h2><h3><span>RISK REDUCTION:</span></h3><h4><span>The 2027 Deadline. Your Vendor Contracts Don&#8217;t Mention.</span></h4><p><strong><span>TLDR:</span></strong><span> On June 16, 2026, France&#8217;s national cybersecurity agency </span><a href="https://www.reuters.com/legal/litigation/france-stop-certifying-products-without-quantum-safe-encryption-2026-06-16/"><span>ANSSI announced</span></a><span> that it will stop certifying security products lacking quantum-resistant encryption beginning in 2027, with a full procurement transition to quantum-safe products expected by 2030.</span></p><p><span>ANSSI certification is not optional in France; it&#8217;s a prerequisite for deployment across French government agencies and operators of critical infrastructure. The policy is Europe&#8217;s most aggressive government mandate on post-quantum cryptography to date and mirrors the U.S. National Security Agency&#8217;s CNSA 2.0 timeline, which also centers on a 2027 transition point.</span></p><p><span>ANSSI Chief of Staff Samih Souissi framed the announcement in terms no board should misread as technical: &#8220;It&#8217;s not only a technical issue. It&#8217;s a matter of governance, industrial planning, regulation, and sovereignty.&#8221;</span></p><h4><span>Highlights</span></h4><ol><li><p><strong><span>This Is Not a Technology Announcement. It Is a Procurement Mandate. </span></strong><span>France&#8217;s policy does not tell organizations to update their encryption algorithms. It tells them that the vendors supplying their security infrastructure must have quantum-resistant encryption built in, or those vendors lose certification eligibility.</span></p></li><li><p><strong><span>The Threat Is Already Operational and Silent. </span></strong><span>The &#8220;harvest now, decrypt later&#8221; attack model is not a theoretical future risk. Nation-state adversaries and sophisticated criminal groups are collecting and storing encrypted organizational data today, with the explicit intention of decrypting it when quantum computing capability catches up.</span></p></li><li><p><strong><span>The Systems Most Exposed Are the Ones With the Longest Operational Lives. </span></strong><span>VPNs, public key infrastructure, and digital certificate frameworks are precisely the systems most vulnerable to harvest-now-decrypt-later attacks, and precisely the systems with the longest replacement cycles. These are not components that can be swapped quickly when a deadline arrives.</span></p></li><li><p><strong><span>Third-Party Risk Programs Were Not Built for This Question. </span></strong><span>Most third-party risk management frameworks ask vendors about their security controls, their incident response procedures, and their regulatory compliance posture. Almost none of them systematically ask whether the vendor&#8217;s core security products are on a documented path to quantum-safe certification.</span></p></li></ol><h4><span>INSIGHT</span></h4><p><span>The ANSSI mandate is not strictly a cybersecurity story; it is a procurement governance story.</span></p><p><span>The core question it creates is not whether you believe quantum computing is an imminent threat, but whether your procurement framework systematically verifies if your tech stack will remain certifiable under regulatory standards that are already on a published timeline. In most organizations, the people evaluating vendor security and those tracking quantum regulations operate in separate silos without a shared framework.</span></p><p><span>This is the exact structural evidence gap we&#8217;ve tracked in </span><em><span>Cyber Risk Governance Insights</span></em><span> for weeks across AI readiness and operational containment metrics. Exposure accumulates silently in the massive chasm between a regulatory assumption and your actual third-party risk reality.</span></p><p><span>The &#8220;harvest now, decrypt later&#8221; reality transforms this from a mid-level IT project into an immediate board-level fiduciary risk. Choosing to defer quantum-readiness planning until a future compliance deadline arrives means you are actively choosing to ignore data that is being exfiltrated and archived by adversaries today. Retrospective upgrades cannot protect data that has already left your environment.</span></p><p><span>The ultimate question for the board is simple:</span></p><div class="callout-block" data-callout="true"><p><span>Have you assigned quantum-readiness to a named owner with absolute authority over your procurement pipeline, and do they hold a documented inventory of your cryptographic dependencies? </span></p></div><p><span>Without those two components, you don&#8217;t have a corporate readiness strategy; you just have an awareness that a systemic crisis is heading your way.</span></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share Cybersecurity Chronicles&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share Cybersecurity Chronicles</span></a></p><h3><span>RISK REDUCTION:</span></h3><h4><span>The Attack Looked Legit, But 2 Months Passed Before Anyone Knew the Difference</span></h4><p><strong><span>TLDR:</span></strong><span> Symantec&#8217;s threat intelligence team has documented a DragonForce ransomware intrusion against a major unnamed U.S. services company in which attackers remained undetected for up to two months by routing all command-and-control traffic through </span><a href="https://www.theregister.com/cyber-crime/2026/06/16/crooks-found-a-new-way-to-collaborate-using-teams-by-hiding-command-and-control-traffic/5256296"><span>Microsoft Teams&#8217; own relay infrastructure</span></a><span>. The custom backdoor used, tracked as Backdoor.Turn, obtained legitimate Microsoft visitor tokens, used Microsoft&#8217;s own TURN relay servers to establish connections, and tunneled attacker traffic through an encrypted QUIC session to a malicious server. Every network monitoring tool in the victim organization saw outbound connections to legitimate Microsoft infrastructure and reported nothing unusual. This is the first confirmed malware in the wild to use this technique, and DragonForce has 579 confirmed victims since 2023.</span></p><h4><span>Highlights</span></h4><ol><li><p><strong><span>Security Stack Functioned Correctly. </span></strong><span>Every detection tool the victim organization had was operating as designed. No tool was bypassed, circumvented, or disabled in order for the attacker&#8217;s traffic to go undetected. The traffic genuinely was going to legitimate Microsoft servers.</span></p></li><li><p><strong><span>The Vendor You Trust Most Is the Attack Surface You Monitor Least. </span></strong><span>Microsoft Teams is not a peripheral application in most enterprise environments. It is the primary communication and collaboration platform, the system through which the organization conducts daily operations, shares files, and connects with external parties. Security monitoring architecture is generally built to inspect traffic to unknown or suspicious destinations.</span></p></li><li><p><strong><span>A New Question in the Next Vendor Review. </span></strong><span>The governance response to this incident is not a new security tool. It is a new question that needs to be answered for every major vendor platform in the organization&#8217;s stack: if a threat actor obtained legitimate credentials or tokens for this platform, what would our detection architecture see? If the answer is &#8220;normal traffic,&#8221; the organization has an unmonitored attack surface.</span></p></li></ol><h4><span>INSIGHT</span></h4><p><span>Symantec documents this governance failure that no traditional security tool was positioned to prevent. That&#8217;s the precise framing boards must understand before they reactively ask what new software they need to buy. This incident exposes the exact structural problem exposed in recent data: the organizations suffering the longest remediation delays are those whose governance frameworks cannot detect what their security tools are designed to ignore. The attackers didn&#8217;t defeat the security stack; they operated underneath it within the trusted infrastructure layer.</span></p><p><span>This reframes how corporate risk registers account for exposure. Most organizations map their standard attack surfaces, including perimeters, endpoints, and applications. Almost none document the threat vector created by their most trusted operational platforms, like Microsoft Teams or cloud storage layers. The implicit assumption that trusted vendor infrastructure is safe from exploitation is an undocumented, unhedged risk, and attackers are finding it before the board realizes it exists.</span></p><p><span>This exact structural conclusion plays out across multiple platforms this week. Whether it&#8217;s an enterprise collaboration tool or a third-party browser extension with privileged cloud access, the pattern is identical: the trusted platform itself becomes the attack surface. Traditional security architecture was never built to question whether that trust is still justified once a session is established.</span></p><p><span>The board-level mandate following this incident is strictly an executive-level risk governance directive, not an IT task. Leadership must demand a documented inventory of every trusted platform carrying privileged access or operational data, alongside an explicit technical assessment of what defensive monitoring architecture would see if that trust were weaponized. If that inventory does not exist, the risk is not being managed; it&#8217;s simply being assumed away.</span></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h1>Tired of getting what you paid for?</h1><h2>Let&#8217;s Fix What&#8217;s Broken</h2><ul><li><p><strong>Real-World Risk Assessment:</strong> Stop guessing where your vulnerabilities are. We&#8217;ll give you a clear, prioritized roadmap to fix what&#8217;s actually at risk, not just what a checklist says.</p></li><li><p><strong>A &#8220;No-Nonsense&#8221; Health Check:</strong> Kickstart your governance journey with a complimentary session to identify your biggest gaps. No fluff, just the facts.</p></li></ul><h2>Stay Ahead of the Curve</h2><ul><li><p><strong>Join the Conversation:</strong> Connect with the Cyber Risk Governance Community on LinkedIn. It&#8217;s where the best minds in the business share real insights, not just vendor pitches.</p></li><li><p><strong>Access to the Private Roundtable:</strong> CRG Community members gain exclusive access to a monthly, closed-door private roundtable. These interactive sessions provide a confidential forum to discuss real-world challenges peer-to-peer.</p></li><li><p><strong>Sit in on a Session:</strong> Attend our interactive LinkedIn Live events. We cut through the noise to discuss the real-world cyber risks that keep you up at night.</p></li></ul><h2>Get It Done.</h2><p>Reach out to <a href="https://www.linkedin.com/article/edit/7370904157077037056/#">Netswitch Technology Management</a> today.</p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share&quot;,&quot;text&quot;:&quot;Share Cybersecurity Chronicles&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share Cybersecurity Chronicles</span></a></p><div><hr></div><p><strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a><br></strong>Author &amp; Editor, <em>Cyber Risk Governance Insights;</em> Vice President, <a href="https://www.linkedin.com/company/netswitch-technology-management/">Netswitch, Inc.</a></p><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Cyber Risk Governance Insights | June 15, 2026 | Edition No. 130]]></title><description><![CDATA[Where cybersecurity incidents become board-level accountability decisions]]></description><link>https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-37c</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-37c</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 15 Jun 2026 19:48:28 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<blockquote><p><em><strong>This week we see</strong></em>&#8230; shared infrastructure and authentication assumptions creating invisible governance gaps. Organizations validate controls only after compromise reveals the assumptions were wrong. Detection lag reveals what was never actually validated.</p></blockquote><h1>&#10024; QUICK WIN</h1><p>Ask your CISO:</p><blockquote><p><em><strong>&#8216;'Show me proof that each of our critical platforms&#8212;email, VPN, identity management, shared infrastructure&#8212;has been validated against real attack methods that have compromised similar infrastructure recently.&#8221;</strong></em></p></blockquote><p>If the answer is more than 90 days ago, schedule a validation audit before month-end.</p><h2>Week in Brief</h2><h4>PHARMACEUTICAL: Unauthorized Access to Trial Patient Data Disclosed</h4><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.techradar.com/pro/security/novo-nordisk-reveals-cyberattack-ozempic-and-wegovy-maker-says-clinical-trials-data-breached">Novo Nordisk</a> [NYSE: <a href="https://finance.yahoo.com/quote/NVO/">NVO</a>], maker of the blockbuster weight-loss drugs Ozempic and Wegovy, disclosed that attackers gained unauthorized access to internal IT systems and copied patient data from clinical trial participants. The affected data includes patient IDs, sex, year of birth, biomarkers, health and immunogenicity data, and lifestyle factors including smoking status, alcohol use, and BMI. The company claims the data is pseudonymized and no direct identifiers were exposed, reducing the immediate risk of identity theft or targeted phishing. However, the company did not disclose the timeline of the breach nor how long the unauthorized access persisted.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Initial access vector unknown. The breach raises the question of whether clinical trial data was segregated from production systems or whether the attacker gained access through a single compromise point that exposed multiple system classes.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Require your security leadership to demonstrate, in writing, that critical protected data are stored on systems that cannot be accessed from general corporate networks. Document the network segmentation and access controls.</p><p><strong>&#129002; REALITY CHECK: </strong>Attackers copied patient data from clinical trials. The company claims no direct identifiers were exposed, so re-identification would require access to underlying data. Yet that same underlying data apparently existed in accessible proximity to the compromised systems. Which means your assumption that data is protected by pseudonymization or segregation cannot be verified without forensic evidence. Raising the question: does your organization assume pseudonymization and segregation protect sensitive data, or do you validate the assumption quarterly?</p><h4>AUTOMOTIVE: 30K Told to Reset Passwords In-Person After Cyberattack</h4><p><strong>&#128998; WHY IT MATTERS: </strong>Following a September 2025 cyberattack attributed to the threat group Scattered Spider, <a href="https://www.am-online.com/news/jlr-ordered-30-000-staff-to-reset-passwords-in-person-after-cyberattack">Jaguar Land Rover</a> [Owned by Tata Motors NSE: <a href="https://finance.yahoo.com/quote/TMCV.NS/">TMCV.NS</a>] required all 30,000 employees to physically report on-site and reset their passwords under staff observation. The incident disrupted production across all JLR facilities for three weeks and resulted in an estimated &#163;1.9 billion economic impact to the UK economy. The company later disclosed that employee payroll data, tax information, pension details, and benefit information were stolen. The incident has been described as the UK&#8217;s costliest cyberattack to date, with effects felt across 5,000 supplier and partner organizations.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Initial access through credential compromise or phishing. The attacker appears to have gained access to user credentials and established persistence in the Microsoft 365 environment. JLR&#8217;s former CISO Ashish Shrestha disclosed at Infosecurity Europe that the company could not determine whether Microsoft 365 itself had been compromised, forcing the emergency response of requiring all users to verify their identity and reset credentials in person before systems could be trusted for crisis communications.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Require your IT/Security engineers to demonstrate a documented capability to distinguish between a legitimate user account and a compromised credential within your Microsoft 365 environment within one hour of detection. Implement User and Entity Behavior Analytics (UEBA) or equivalent identity anomaly detection, and mandate the technical ability to execute immediate session token and OAuth revocation upon confirmation of a compromise.</p><p><strong>&#129002; REALITY CHECK: </strong>An entire automotive manufacturer moved 30,000 employees through on-site identity verification and password resets because no tool could validate whether credentials in the corporate environment were still trustworthy. This is not a failure of backup systems or security response. This is a failure of the assumption that credential management systems can distinguish between legitimate and compromised users at scale. Which means your organization is one credential compromise away from discovering that you cannot trust your own user directory. Ask yourself: would my business continue operating if every user account was treated as potentially compromised until verified?</p><h4>IT INFRASTRUCTURE: 0-Day Actively Exploited by Ransomware Affiliate</h4><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.cybersecuritydive.com/news/check-point-zero-day-ransomware/822372/">Check Point</a> disclosed CVE-2026-50751, a critical authentication bypass flaw in Check Point Remote Access VPN and Mobile Access products that allows unauthenticated attackers to establish VPN sessions without a valid password. The vulnerability (CVSS 9.3) has been actively exploited since May 7, 2026, by a Qilin ransomware affiliate targeting a few dozen organizations globally. Check Point did not detect the exploitation until June 4, meaning attackers maintained operational access for nearly a month before discovery. The flaw exists in deprecated IKEv1 key exchange protocol, which the vendor still supports for legacy remote access clients.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Logic flaw in certificate validation within the IKEv1 protocol implementation. The attacker exploits a weakness in the validation process to bypass the password requirement entirely. No patch was available when attacks began. Check Point has released hotfixes, but the incident reveals a pattern: the same attacker infrastructure has previously targeted VPN vulnerabilities in Palo Alto Networks, F5, and Fortinet, suggesting either a targeted campaign against VPN appliances broadly or opportunistic exploitation of known leverage points.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Maintain and regularly validate a complete inventory of all (Check Point or other) VPN and mobile access appliances, their software versions, the protocols they are configured to use, and their network exposure. If any appliances are configured for deprecated protocols, mandate immediate upgrade to newer versions or restriction of access.</p><p><strong>&#129002; REALITY CHECK: </strong>Attackers had valid VPN sessions that looked indistinguishable from legitimate remote access for an entire month. Your security team could not detect the anomaly. The attacker could move laterally inside your network using credentials that bypassed authentication entirely. Which means your assumption that VPN authentication provides access control is unvalidated. Which raises the question: if attackers can bypass password authentication on a critical appliance and you don&#8217;t detect it for 30 days, how do you know your other infrastructure is not currently compromised in a similar way?</p><h4>FINANCIAL SERVICES: Cyberattack Disrupts Four Major Banks</h4><p><strong>&#128998; WHY IT MATTERS: </strong>A cyberattack disrupted services across <a href="https://therecord.media/cyberattack-on-russian-tech-firm-astral-disrupts-business-government-services">four major Iranian financial institutions</a>: Bank Melli, Bank Tejarat, Bank Saderat, and the Export Development Bank of Iran. The attackers targeted the shared communications infrastructure that all four banks rely on, causing widespread disruption to mobile banking applications, internet banking platforms, ATMs, and point-of-sale terminals. Iranian authorities disclosed the incident on June 13 and asserted that no customer data was compromised and no unauthorized access to customer information occurred. However, the breadth of service disruption across four simultaneous banks indicates either coordinated targeting or exploitation of a single shared platform.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Attack on shared communications infrastructure that multiple banks depend on. Given the simultaneous downtime across multiple separate entities, targeting the centralized, shared clearing or communication network level is the only logical conclusion.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>If your organization shares infrastructure (communications platforms, authentication servers, payment clearing systems) with other entities, require your operations team to provide explicit dependency mapping and a validated &#8220;kill-switch&#8221; protocol to isolate shared infrastructure is highly defensible and mimics modern BCP/DR (Business Continuity/Disaster Recovery) standards</p><p><strong>&#129002; REALITY CHECK: </strong>Four banks lost the ability to serve their customers simultaneously because they share infrastructure. The Coordination Council asserts no data was stolen, but customers could not access their money for hours. This incident illustrates that an organization&#8217;s attack surface is often dictated by things completely outside its visibility. Which raises the question: does your organization have a complete map of every platform or system it shares with other institutions, and could you detect and isolate yourself from a compromise of that shared infrastructure within one business hour?</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-37c?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-37c?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><h2>EXPERT PERSPECTIVE</h2><h2>RISK TRANSFER:</h2><h3>The Insurance You Bought Is Not the Insurance You Will Collect</h3><blockquote><p><em><strong>&#8220;Insurers today generally have a better understanding of cyber risk quantification and are placing greater emphasis on a covered entity&#8217;s Cyber Risk Management program.&#8221;</strong></em></p></blockquote><p>In a June 2026 industry <a href="https://www.cybersecuritydive.com/news/cyber-insurance-policyholders-facing-heavier-scrutiny-underwriting-claims/822089/">analysis</a>, a documented structural shift in the cyber insurance market that most boards have not yet priced into their risk registers.</p><p>After a multiyear lull in rates, insurers are tightening underwriting scrutiny and claims review simultaneously, while quietly acknowledging that the industry&#8217;s global market is dangerously overdependent on large U.S. policyholders.</p><p>The result is a widening gap between what a board believes its insurance policy transfers and what an insurer will actually pay when a claim is filed.</p><p>For an audience that has spent the better part of two months reading about governance evidence gaps in agentic AI, AI readiness, and AI-driven workforce decisions, this article describes the same gap showing up in the one place most boards assumed it did not exist: the policy they already paid for.</p><h3>Highlights</h3><ol><li><p><strong>The Premium Reflects the Application. The Payout Reflects the Evidence.</strong><br>This disconnect should concern every board that has invested in detection and response capability, expecting it to translate into better insurance terms: organizations with managed detection and response or endpoint detection and response do not consistently see that investment reflected in pricing, deductibles, or breadth of coverage.</p></li><li><p><strong>&#8220;Actually Enforced&#8221; Is the Phrase That Pays &amp; Decides If You Collect.</strong><br>Analysis shows that insurance claims are increasingly denied based on the exact operation, rather than the mere existence, of cybersecurity controls like multifactor authentication at the time of a breach. This shift emphasizes that compliance policies and point-in-time deployments are no longer sufficient to secure coverage if a control is not actively functioning without exception when an attack occurs.</p></li><li><p><strong>The Industry Is Underwriting a Risk It Cannot Afford to Have Realized.</strong><br>Insurers globally are increasingly dependent on large U.S. policyholders, who represent nearly two-thirds of global market share, and carriers are now openly concerned that a single large-scale supply chain event or systemic outage could destabilize the cyber insurance industry as a whole.</p></li><li><p><strong>The Missing Middle Is Not an Access Problem. It Is an Evidence Problem.</strong><br>Only an estimated 20% of SMBs carry cyber insurance, and the reason is not primarily cost. <a href="https://lockbox.lockton.com/m/2fdff4267d6d7e0e/original/December-2025-Lockton-Market-Update_portal_link.pdf?utm_source=Web&amp;utm_medium=Bynder&amp;utm_campaign=LMU">Lockton </a>points to a more fundamental issue: smaller organizations do not understand their own financial exposure well enough to know what they are buying or why they need it. An organization that cannot quantify its own risk cannot evaluate whether a policy transfers it, negotiate its terms, or produce the evidence to support a claim if the risk materializes. The absence of insurance in this segment is a symptom. The absence of risk quantification is the disease.</p></li></ol><h3>Insight</h3><p>For the past several weeks, this newsletter has tracked a critical governance gap: the distance between the controls organizations believe they have and the continuous evidence they can actually produce. We saw it in CISA&#8217;s agentic AI guidance, ISACA&#8217;s incident containment data, and Fastly&#8217;s financial metrics. This week, we see that the insurance market has quietly priced this exact evidence gap into its underwriting all along.</p><p>The phrase &#8220;actually enforced&#8221; represents the ultimate governance threshold. It shifts the question from whether a control exists to whether it was operating, continuously and verifiably, the moment an attacker walked through the door. An underwriter auditing MFA is asking the exact same question a regulator asks during a disclosure investigation, or a plaintiff&#8217;s attorney asks during discovery. Most organizations are discovering their governance infrastructure cannot answer it.</p><p>This reframes the entire concept of risk transfer. A board assumes an insurance policy offloads their cyber risk. In reality, a policy only transfers the financial consequences of a loss <em>if the organization can produce timestamped evidence that its represented controls were operating</em>. The risk you blindly retain is the risk that your operational reality does not match your application&#8217;s representations. That hidden exposure only surfaces during a claims review, when it is too late to fix.</p><p>The AI dimension compounds this fragility. Insurers cannot price a risk they cannot model, and they cannot verify a control they cannot benchmark. When AI compresses attack timelines to the point where recovery velocity dictates loss severity, deploying autonomous agents without continuous telemetry creates an immediate coverage gap.</p><p>The ultimate question for the board is not whether the organization has a cyber insurance policy. It is whether you could, today, produce the continuous, forensic evidence required to get reimbursed. If you cannot, your policy is not a risk transfer mechanism; it is just an expensive application you have not yet learned you cannot complete.</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h1>Tired of getting what you paid for?</h1><h2>Let&#8217;s Fix What&#8217;s Broken</h2><ul><li><p><strong>Real-World Risk Assessment:</strong> Stop guessing where your vulnerabilities are. We&#8217;ll give you a clear, prioritized roadmap to fix what&#8217;s actually at risk, not just what a checklist says.</p></li><li><p><strong>A &#8220;No-Nonsense&#8221; Health Check:</strong> Kickstart your governance journey with a complimentary session to identify your biggest gaps. No fluff, just the facts.</p></li></ul><h2>Stay Ahead of the Curve</h2><ul><li><p><strong>Join the Conversation:</strong> Connect with our Cyber Risk Governance Community on LinkedIn. It&#8217;s where the best minds in the business share real insights, not just vendor pitches.</p></li><li><p><strong>Sit in on a Session:</strong> Attend our interactive LinkedIn Live events. We cut through the noise to discuss the real-world cyber risks that keep you up at night.</p></li></ul><h2>Get It Done.</h2><ol><li><p>Reach out to <a href="https://www.linkedin.com/article/edit/7370904157077037056/#">Netswitch Technology Management</a> today.</p></li><li><p><strong>Join Our <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> </strong>and connect with a dynamic network of professionals on LinkedIn. Exchange insights, transform risks into readiness, and stay ahead of evolving threats.</p></li><li><p><strong>Engage in Live Events:</strong> Attend interactive LinkedIn Live sessions. Dive into critical cyber risk topics with industry leaders from executive, technology, and governance backgrounds.</p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share&quot;,&quot;text&quot;:&quot;Share Cybersecurity Chronicles&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share Cybersecurity Chronicles</span></a></p><div><hr></div></li></ol><p><strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a><br></strong>Author &amp; Editor, <em>Cyber Risk Governance Insights;</em> Vice President, <a href="https://www.linkedin.com/company/netswitch-technology-management/">Netswitch, Inc.</a></p><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Cyber Risk Governance Insights | June 8, 2026 | Edition No. 129]]></title><description><![CDATA[Where cybersecurity incidents become board-level accountability decisions]]></description><link>https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-459</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-459</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 08 Jun 2026 19:25:11 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<blockquote><p><em><strong>This week we see</strong></em>&#8230; Attackers establishing persistent silent footholds while organizations are preoccupied with whats visible. By the time boards are made aware of a compromise, the infrastructure has been operational for months. Detection assumes visibility during urgency. Reality is silent compromise during preparation.</p></blockquote><h1>&#10024; QUICK WIN</h1><p>Ask your CISO:</p><blockquote><p><em><strong>&#8216;How many minutes does it take us to detect a mailbox sending data to Dropbox or OneDrive from an unfamiliar location?&#8217; </strong></em></p></blockquote><p>If the answer is &#8216;hours&#8217; or &#8216;we don&#8217;t monitor that,&#8217; you&#8217;ll need an emergency review by the risk committee of mail access anomaly detection. Because this single capability would have detected the stock exchange compromise immediately instead of months.</p><h2>Week in Brief</h2><h4>FIN SERV: Espionage Campaign Against Global Stock Exchange</h4><p><strong>&#128998; WHY IT MATTERS: </strong>Attackers maintained <a href="https://thehackernews.com/2026/06/hackers-spied-on-stock-exchange.html">access to a senior executive&#8217;s Outlook mailbox for 150 days</a>. The mailbox contained strategic communications, calendar movements, external negotiations, and internal deliberations. Access began in October 2025 and continued undetected until March 2026. The threat actor exfiltrated data in small batches through OneDrive and Dropbox, routing traffic through hard-coded Microsoft IP addresses to avoid DNS detection. This is espionage by design: the goal was not financial theft but sustained intelligence collection.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Initial access vector unknown. The attacker disguised a scheduled exfiltration task, tested mail relay capabilities, and then refined the operation, syncing data every two to four weeks. Last observed activity was March 19, 2026, when a new backdoor was staged but never executed.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Implement impossible-travel detection and application-velocity alerting within minutes, not hours. And for executive email accounts, require them to be subject to the same alerting rules as other accounts; no exemptions for senior staff.</p><p><strong>&#129002; REALITY CHECK: </strong>5 months of data exfiltration from a global financial exchange went undetected. The attacker&#8217;s tooling blended into normal cloud activity. The initial entry point remains unknown. Which means your board-approved email security controls that permitted 150 consecutive days of unauthorized mailbox access without triggering a single automated alert. Can your security team distinguish between legitimate cloud service usage and exfiltration, or are both indistinguishable on your network?</p><h4>INFRASTRUCTURE: 7th Zero-Day Exploitation of 2026 Disclosed</h4><p><strong>&#128998; WHY IT MATTERS: </strong>Cisco released an advisory for CVE-2026-20245, a command injection flaw in <a href="https://www.cybersecuritydive.com/news/cisco-zero-day-flaw-sd-wan-exploited/822138/">Cisco Catalyst SD-WAN Manager</a> enabling arbitrary command execution as root. The vulnerability requires that an attacker already have netadmin privileges, which can be obtained through stolen credentials or by chaining previous SD-WAN vulnerabilities like CVE-2026-20182 (an authentication bypass patched in May) or CVE-2026-20127 (exploited since at least 2023). Mandiant reported active exploitation; Cisco confirmed limited cases where attackers pushed configuration changes to edge devices after gaining root access.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>No patch is available right now. The flaw exists at the admin level. An attacker can upload a crafted file and trigger command injection. This is not a remote unauthenticated attack. It is a privilege escalation chain that leverages either stolen credentials or prior vulnerabilities.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Require documentation of which instances are internet-facing and which are behind firewall restrictions. Change all administrative credentials immediately. Implement network segmentation to restrict access to the SD-WAN management plane to a dedicated administrative network. Disable any unused management interfaces.</p><p><strong>&#129002; REALITY CHECK: </strong>Your board approved SD-WAN (Software-Defined Wide Area Network) as a strategic infrastructure modernization. The product was selected based on vendor security claims. You now have six confirmed zero-days in one year from the same vendor. Which means the procurement security review did not account for the vendor&#8217;s historical vulnerability cadence or the governance lag between disclosure and patch availability. So, did your risk assessment include the timeline for detecting and responding to zero-days, or only the timeline for patching?</p><h4>HOSPITALITY: FIFA World Cup 2026 Cybercriminal Already Active</h4><p><strong>&#128998; WHY IT MATTERS: </strong>From January to May 2026, threat actors registered over <a href="https://www.secureworld.io/industry-news/fifa-world-cup-2026-cybercrime">13,000 FIFA World Cup-themed domains</a>. Pattern analysis and scam tracking identified 8.8 percent as malicious or suspicious. The tournament does not begin until June 11, 2026. Ticket fraud is the headline attack, but the threat surface extends to sponsors, broadcasters, vendors, and host-city suppliers. Cybersecurity researchers documented that over one-third of FIFA&#8217;s own sponsors lack DMARC records on their mail domains, meaning attackers do not need to forge credentials to spoof them. During Paris 2024, roughly 140 successful cyber incidents were documented at approximately a quarter of this operational footprint. The 2026 tournament spans three host nations, sixteen cities, and 48 teams.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Financially motivated cybercrime follows major events because urgency and emotional investment drive victims into making rapid decisions. Attackers create counterfeit ticketing sites that harvest billing and payment card data. Fake streaming platforms promote malware and credential stealers.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>If your organization has any ties to the tournament, require all partners to implement DMARC, DKIM, and SPF authentication on their mail domains immediately. Conduct a brand abuse scan for lookalike domains registered in the past 60 days. Brief your external communications team on the presence of counterfeit ticket and merchandise sites, and establish a protocol for responding to customer and vendor inquiries.</p><p><strong>&#129002; REALITY CHECK: </strong>The tournament infrastructure is still being built. Cybercriminal infrastructure is already operational. Attackers are not waiting for the opening match. They have registered over 13,000 domains and are actively testing phishing, ransomware, and credential harvesting campaigns. Which means your vendor and supplier risk program does not account for the compressed timeline of major events. These are risk topics that <a href="https://www.linkedin.com/in/drcherylcooper/">Dr. Cheryl Cooper</a>, <a href="https://www.linkedin.com/in/nababri/">Naeem Babri</a> and I spoke about at <a href="https://events.secureworld.io/agenda/kansas-city-ks-2026/#:~:text=World%20Cup%202026%20Cyber%20Threats">Secure World Kansas City</a> last month to prepare Kansas City area businesses in their security preparedness.</p><h4>CLOUD: Relay Networks from Hijacked Cloud Servers</h4><p><strong>&#128998; WHY IT MATTERS: </strong>Researchers from Hunt.io discovered that the threat actor PCPJack has <a href="https://thehackernews.com/2026/06/pcpjack-hijacks-230-aws-google-cloud.html">hijacked 230 servers</a> across AWS, Google Cloud, and Azure to construct a covert SMTP relay network. Compromised business servers in the United States, Europe, and Asia were converted into SMTP proxies, tested for mail relay capability, and synced to downstream consumers every five minutes. The operator&#8217;s live working directory, source code, compiled binaries, deployment logs, internet scanners, and Sliver command-and-control configuration were exposed on two open directories without authentication. Each compromised host received a Chisel proxy binary and a Sliver C2 implant. The deployment scaled from initial 50-node test batches to 230 nodes between March and April 2026.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>The threat &#8220;actor&#8221; is a credential theft framework that exploits five CVEs to propagate worm-like across cloud systems. Initial victims have their AWS Instance Metadata Service tokens harvested, unlocking access to source code repositories, payment processors, and cloud storage under the compromised instance&#8217;s IAM role. The persistent infrastructure enables large-scale email phishing and abuse campaigns operating under the appearance of legitimate cloud traffic.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Maintain a regularly updated &amp; detailed inventory of all EC2 instances, GCP compute instances, and Azure VMs running in production. For each instance, document the IAM role or service account, the permissions attached, and the last security patch date. Implement a policy that no instance should have permissions that exceed its operational requirements. Be capable of revoking all current IAM permissions if indicators of compromise are present.</p><p><strong>&#129002; REALITY CHECK: </strong>230 of your cloud servers have been converted into covert email relays without your knowledge. The attacker syncs the list of compromised proxies every five minutes to ensure continuity. The attacker left their entire operational tooling exposed because they believed the infrastructure was secure. Which means your cloud security monitoring did not detect credential harvesting, lateral movement to SMTP services, or the installation of persistent proxy software on running instances. <em>Which raises the question</em>: are you monitoring cloud instances for unauthorized software installation, or only for network-level exfiltration?</p><h4>CYBERCRIME: Global Phishing Campaign Expands w/ Localization</h4><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.darkreading.com/threat-intelligence/china-ta4922-cybercrime-attacks-globally">TA4922</a>, a Chinese-speaking cybercrime group, has expanded from targeting East Asian organizations to actively compromising entities in the United Kingdom, Germany, Italy, South Africa, and across Europe. Operational tempo increased dramatically in March 2026. The group uses tax-themed, payroll, and benefits-themed phishing emails written in the victim&#8217;s local language and corporate context. Each email includes company logos and legitimate-appearing compliance or HR notices. Once clicked, malware families including Atlas RAT, RomulusLoader, SilentRunLoader, and Winos 4.0 variants establish remote access. In several campaigns, the group installed legitimate remote monitoring software including AnyDesk and SyncFuture to maintain persistence while evading malware detection.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>A combination of targeted social engineering, multiple malware families, legitimate administrative software, and cloud-hosted infrastructure. Initial targeting focuses on credentials. Once access is established, the group&#8217;s objective shifts toward data theft, fraud, and resale of system access to downstream actors.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Your employees in critical departments should be aware of identifying tactical attack patterns: emails appearing to come from corporate compliance, tax, or payroll functions, requesting document downloads or account verification. Implement mandatory security awareness training on phishing identification, with specific emphasis on email spoofing tactics and the verification of sender addresses. Require multi-factor authentication on all corporate email accounts, not just privileged access. DMARC proof should be part of your standard procurement security review.</p><p><strong>&#129002; REALITY CHECK: </strong>TA4922 started in East Asia in 2025 and is now operating on four continents. The group has scaled without losing operational precision. Every email is written in the local language and colloquial words &#8211; most likely with the help of AI. Every malware family is new or repurposed to prevent signature identification and blocking. Every campaign is operationally distinct. Which means a single annual awareness training campaign is not sufficient to defend against this threat &#8211; it must be ongoing. Does your organization treat phishing awareness as a box-checking compliance exercise, or as a continuous adaptation to evolving attacker tradecraft?</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-459?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june-459?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><h1>EXPERT PERSPECTIVE</h1><h2>RISK TRANSFER:</h2><h3>Obsolete Email Addresses are Liability Vectors</h3><p>The <a href="https://nltimes.nl/2026/06/08/financial-administrators-poor-email-security-put-many-people-money-trouble-risk">NLTimes </a>recently wrote about financial administrators who manage the affairs of hundreds of thousands of people who cannot manage them independently. An ethical hacker discovered that expired administrator email domains could be reregistered and used to access incoming mail containing tax documents, medical data, diagnoses, medications, bills, and fines. In weeks, he accessed 258 confidential financial files.</p><p>The Netherlands Internet Domain Registration Foundation (SIDN) sends warnings when sensitive domains expire, but many administrators take no action &#8211; ignoring the warnings, filtering the warnings to SPAM, or are ignorant of the meaning.</p><p><strong>Key Findings:</strong></p><ol><li><p><strong>Victim Targeting: </strong>The data specifically targeted people in financial distress, documented as more vulnerable to secondary fraud and exploitation.</p></li><li><p><strong>Scale of Exposure: </strong>1 part-time researcher accessed 258 files in 7 days. If organized criminals are harvesting the same vulnerabilities, what is the likely population penetration?</p></li><li><p><strong>Administrative Blindness: </strong>Despite expiration warnings, many organizations take no action. Domain expiration and security implications are not routinely tracked.</p></li><li><p><strong>Insider Detection: </strong>The discovery was made by an ethical hacker, not by administrators, IT teams, or regulatory audits. Compromised mailboxes are not routinely monitored.</p></li></ol><h3>Insight:</h3><p>The vulnerability is not technical but administrative.</p><p>Email address retirement is a routine business process. Domains expire. Services are discontinued.</p><p>What is absent is a governance obligation to transfer, migrate, or retire mail addresses in a way that prevents unauthorized re-registration. The administrative gap creates a secondary victim class.</p><p>In the Netherlands case, the vulnerable population is people in financial hardship, whose data is now exposed to secondary fraud. The governance question is not &#8216;what technical controls prevent expired domain reregistration&#8217; but &#8216;who in the organization is accountable for ensuring that sensitive historical email addresses do not become credential theft vectors?&#8217;</p><p>The accountability failure is not the attacker&#8217;s sophistication. It is the administrative assumption that email address retirement is not a security decision.</p><p>Can your Chief Operations Officer provide a complete inventory of all organizational email addresses, their current status (active, retired, migrated), and their expiration dates?</p><p>If not, how many expired domains are currently available for reregistration by threat actors?</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h1>Tired of getting what you paid for?</h1><h2>Let&#8217;s Fix What&#8217;s Broken</h2><ul><li><p><strong>Real-World Risk Assessment:</strong> Stop guessing where your vulnerabilities are. We&#8217;ll give you a clear, prioritized roadmap to fix what&#8217;s actually at risk, not just what a checklist says.</p></li><li><p><strong>A &#8220;No-Nonsense&#8221; Health Check:</strong> Kickstart your governance journey with a complimentary session to identify your biggest gaps. No fluff, just the facts.</p></li></ul><h2>Stay Ahead of the Curve</h2><ul><li><p><strong>Join the Conversation:</strong> Connect with our Cyber Risk Governance Community on LinkedIn. It&#8217;s where the best minds in the business share real insights, not just vendor pitches.</p></li><li><p><strong>Sit in on a Session:</strong> Attend our interactive LinkedIn Live events. We cut through the noise to discuss the real-world cyber risks that keep you up at night.</p></li></ul><h2>Get It Done.</h2><ol><li><p>Reach out to <a href="https://www.linkedin.com/article/edit/7370904157077037056/#">Netswitch Technology Management</a> today.</p></li><li><p><strong>Join Our <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> </strong>and connect with a dynamic network of professionals on LinkedIn. Exchange insights, transform risks into readiness, and stay ahead of evolving threats.</p></li><li><p><strong>Engage in Live Events:</strong> Attend interactive LinkedIn Live sessions. Dive into critical cyber risk topics with industry leaders from executive, technology, and governance backgrounds.</p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share&quot;,&quot;text&quot;:&quot;Share Cybersecurity Chronicles&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share Cybersecurity Chronicles</span></a></p><div><hr></div></li></ol><p><strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a><br></strong>Author &amp; Editor, <em>Cyber Risk Governance Insights;</em> Vice President, <a href="https://www.linkedin.com/company/netswitch-technology-management/">Netswitch, Inc.</a></p><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Cyber Risk Governance Insights | June 1, 2026 | Edition No. 128]]></title><description><![CDATA[Where cybersecurity incidents become board-level accountability decisions]]></description><link>https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 01 Jun 2026 18:25:53 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<blockquote><p><strong>This week we see&#8230; </strong>that leadership-driven process flaws are being disguised as employee errors, attackers are turning standard identity checks against the business, and &#8220;check-the-box&#8221; compliance actively reduces cyber risk visibility when clear vision needs it most.</p></blockquote><h1>&#10024; QUICK WIN</h1><p>Ask your Identity and Access Management (IAM) leadership in your next meeting:</p><blockquote><p><em><strong>&#8220;If we detected a phishing campaign targeting us, how long until we could identify every authentication token that was issued as a result and revoke them all?&#8221;</strong></em></p></blockquote><p>If the answer is anything other than a specific number of minutes, ask them to set up a clear token revocation capability before your next risk committee meeting, and make sure to ask that exact same question again.</p><h2>Week in Brief</h2><h4>TELECOMMUNICATIONS: Breach Exposes 13 million Records</h4><p>&#128998; WHY IT MATTERS: <a href="https://www.bleepingcomputer.com/news/security/charter-confirms-data-breach-after-shinyhunters-extortion-threat/">Charter Communications</a> confirmed on May 28 that attackers operating under the ShinyHunters banner compromised millions of customer records. The hackers gained initial access through a voice phishing attack targeting an employee, set a ransom deadline, and publicly posted the data when Charter refused to negotiate. Verified data shows that at least 13 million customer records were exposed, including names, addresses, phone numbers, and support ticket details, along with 27,000 employee records. The scope of exposure far exceeds what the company initially disclosed.</p><p>&#129000; PROBABLE CAUSE: Voice phishing (vishing) to deceive an employee into revealing credentials, granting remote access to a Microsoft Entra account. Continued fallout from the Salesforce attack.</p><p>&#129001; PROACTIVE PREVENTION: Security leadership should prove that a compromised single sign-on (SSO) credential cannot be used to access critical data repositories like Salesforce without triggering automated alerts.</p><p>&#129002; REALITY CHECK: A single credential compromise at a major telecom provider provided unrestricted database access for nearly two months. This raises a critical question for your next meeting: Does your Salesforce instance require step-up authentication when accessed from unusual geographies or times, or is a legitimate credential treated as sufficient regardless of context?</p><h4>HOSPITALITY: Cruising Breach Maroons 6 Million Customers</h4><p>&#128998; WHY IT MATTERS: <a href="https://www.securityweek.com/carnival-data-breach-exposed-6-million-people/amp/">Carnival Corporation</a> notified nearly 6 million customers on May 27 that their personal information was compromised. The breach follows a systemic pattern of social engineering attacks targeting corporate Salesforce environments. Exposed data includes names, dates of birth, passport numbers, and driver&#8217;s license numbers from their loyalty program.</p><p>&#129000; PROBABLE CAUSE: A voice phishing attack on an employee granted attackers access to a part of the IT network. They used the account to copy massive customer files for eight days before being detected.</p><p>&#129001; PROACTIVE PREVENTION: Require IT leadership to implement and show automated controls ensuring that a single user account cannot bulk-copy customer data repositories without triggering an immediate escalation to the security operations center.</p><p>&#129002; REALITY CHECK: An attacker had eight days of undetected access to systems holding customer passport and driver&#8217;s license numbers. This exposes a fatal governance failure: the security team successfully identified the compromise but could not answer, at the moment of detection, what data had already been copied or stolen.</p><h4>FBI: Phishing-as-a-Service Platform Bypassing MFA</h4><p>&#128998; WHY IT MATTERS: The <a href="https://www.cybersecuritydive.com/news/fbi-warns-phishing-platform-microsoft-365/821105/">FBI published a warning</a> on May 21 about <em>Kali365</em>, a phishing-as-a-service platform that allows attackers to harvest OAuth tokens from Microsoft 365 environments and completely bypass multi-factor authentication (MFA). This device code phishing technique exploits legitimate authentication flows, granting attackers persistent access to Teams, Outlook, and OneDrive across manufacturing, financial services, healthcare, and government sectors.</p><p>&#129000; PROBABLE CAUSE: Exploitation of legitimate authentication device flow by spoofing the Microsoft login experience, letting less sophisticated threat actors obtain persistent access tokens without ever needing to compromise a user&#8217;s actual password.</p><p>&#129001; PROACTIVE PREVENTION: Identity Access Management should be able to demonstrate that your security can identify and revoke all authentication tokens issued within one hour of detecting a suspected incident.</p><p>&#129002; REALITY CHECK: Organizations with MFA deployed are completely vulnerable if their implementation blindly assumes an attacker cannot bypass the password gate. Your IT leadership must answer a direct question before the next board meeting: Does our security posture assume MFA blocks all threats, or do we have compensating controls for attacks that exploit platform architecture?</p><h4>AI: Shadow Tools Expose Migration Policy Gaps</h4><p>&#128998; WHY IT MATTERS: A survey by Okta released on May 28 found that while nearly all executives believe employees use AI responsibly, <a href="https://www.cybersecuritydive.com/news/shadow-ai-enterprise-data-policies-okta/821344/">over half of employees admitted to using unauthorized</a>, unapproved personal AI tools. Workers are granting these rogue tools access to internal messages, HR data, and confidential company documents, creating massive data loss and compliance exposure.</p><p>&#129000; PROBABLE CAUSE: Overly restrictive or absent corporate AI usage policies drive employees to adopt unauthorized tools in secret just to meet business deadlines.</p><p>&#129001; PROACTIVE PREVENTION: The Chief Information Officer should provide the board with a comprehensive inventory of approved AI tools alongside documentation detailing exactly what data categories each tool is permitted to access.</p><p>&#129002; REALITY CHECK: If your corporate security posture currently relies on a comforting belief about employee behavior that empirical evidence flatly contradicts. You should know what data you have, how it&#8217;s being processed outside your network by tools you do not control or audit, your compliance is a myth.</p><h4>GOVERNMENT: Logging Reqs Reduced to Favor a Risk-Based Approach</h4><p>&#128998; WHY IT MATTERS: The <a href="https://federalnewsnetwork.com/cybersecurity/2026/05/omb-revamps-cyber-event-logging-requirements/">Office of Management and Budget (OMB)</a> issued a memorandum May 23 rescinding the strict event logging and 30-month data retention standards originally mandated after the SolarWinds breach. The new directive shifts to a &#8220;risk-based, prioritized&#8221; approach, prioritizing cost control and efficiency over comprehensive system visibility.</p><p>&#129000; PROBABLE CAUSE: Difficulty implementing and sustaining the original comprehensive logging requirements due to extreme operational complexity and budget costs.</p><p>&#129001; PROACTIVE PREVENTION: Require compliance leadership to document exactly what data will no longer be logged under this new risk-based standard and explicitly outline why that risk is being accepted.</p><p>&#129002; REALITY CHECK: The federal government is actively reducing logging requirements based on operational feasibility at the exact moment private sector breaches are proving massive detection gaps measured in weeks rather than hours. This raises the ultimate governance question: Does risk-based logging actually reduce your corporate cost, or does it simply increase your undetected risk?</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-june?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><h1>EXPERT PERSPECTIVE</h1><h2>RISK TRANSFER: Is MFA a False Confidence Signal</h2><p>The FBI&#8217;s warning about <em>Kali365</em> documents a fundamental shift in attack vectors: threat actors are no longer targeting passwords. They are targeting the downstream OAuth token grant process that MFA is designed to protect but cannot govern. This is not a technical security control failure. It is a governance failure in how organizations frame authentication risk to the board.</p><h4>HIGHLIGHTS</h4><ul><li><p>Device Code Phishing Bypasses MFA by Design</p></li><li><p>Commoditization Lowers the Barrier to Entry</p></li><li><p>The Real Risk Is the Token, Not the Password</p></li><li><p>Detection Requires Token-Level Visibility</p></li><li><p>The Governance Assumption Is Broken</p></li></ul><h3>INSIGHT</h3><p>The FBI&#8217;s <em>Kali365</em> warning signals the professionalization of platform-focused authentication attacks. For years, boards have approved multi-factor authentication budgets under a simple promise: <em>MFA blocks phishing.</em> That statement is no longer true. It only blocks password-focused phishing.</p><p>Organizations now face a definitive choice: they can view this as a technical bypass to chase with added point solutions, or they can acknowledge that their underlying authentication risk model is completely incomplete.</p><p>When a board mandates &#8220;human oversight&#8221; or &#8220;standard MFA&#8221; as their core controls, they have created a documented governance commitment. If that control turns out to be a blind spot, the gap between what was promised and what actually happens is a board liability problem.</p><p>True, honest governance requires looking at the entire authentication pipeline: credential entry, token issuance, token usage, and token revocation. It is time the cybersecurity industry stopped marketing MFA as a sort of cybersecurity shield, because it&#8217;s not. It is simply one basic control in an architecture that the evidence proves is vulnerable.</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h1>Tired of getting what you paid for?</h1><h2>Let&#8217;s Fix What&#8217;s Broken</h2><ul><li><p><strong>Real-World Risk Assessment:</strong> Stop guessing where your vulnerabilities are. We&#8217;ll give you a clear, prioritized roadmap to fix what&#8217;s actually at risk, not just what a checklist says.</p></li><li><p><strong>A &#8220;No-Nonsense&#8221; Health Check:</strong> Kickstart your governance journey with a complimentary session to identify your biggest gaps. No fluff, just the facts.</p></li></ul><h2>Stay Ahead of the Curve</h2><ul><li><p><strong>Join the Conversation:</strong> Connect with our Cyber Risk Governance Community on LinkedIn. It&#8217;s where the best minds in the business share real insights, not just vendor pitches.</p></li><li><p><strong>Sit in on a Session:</strong> Attend our interactive LinkedIn Live events. We cut through the noise to discuss the real-world cyber risks that keep you up at night.</p></li></ul><h2>Get It Done.</h2><ol><li><p>Reach out to <a href="https://www.linkedin.com/article/edit/7370904157077037056/#">Netswitch Technology Management</a> today.</p></li><li><p><strong>Join Our <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> </strong>and connect with a dynamic network of professionals on LinkedIn. Exchange insights, transform risks into readiness, and stay ahead of evolving threats.</p></li><li><p><strong>Engage in Live Events:</strong> Attend interactive LinkedIn Live sessions. Dive into critical cyber risk topics with industry leaders from executive, technology, and governance backgrounds.</p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share&quot;,&quot;text&quot;:&quot;Share Cybersecurity Chronicles&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share Cybersecurity Chronicles</span></a></p><div><hr></div></li></ol><p><strong><a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a><br></strong>Author &amp; Editor, <em>Cyber Risk Governance Insights;</em> Vice President, <a href="https://www.linkedin.com/company/netswitch-technology-management/">Netswitch, Inc.</a></p><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Cyber Risk Governance Insights | May 25, 2026 | Edition No. 127]]></title><description><![CDATA[Where cybersecurity incidents become board-level accountability decisions]]></description><link>https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may-43f</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may-43f</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 25 May 2026 20:01:07 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!Dtx0!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0e251f2-90b5-483c-90d2-bf2f09e79e6f_897x454.jpeg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<div class="captioned-image-container"><figure><a class="image-link image2 is-viewable-img" target="_blank" href="/__u/substackcdn.com/image/fetch/$s_!Dtx0!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0e251f2-90b5-483c-90d2-bf2f09e79e6f_897x454.jpeg" data-component-name="Image2ToDOM"><div class="image2-inset"><picture><source type="image/webp" srcset="/__u/substackcdn.com/image/fetch/$s_!Dtx0!, /__u/cybersecuritychronicles.substack.com/w_424, /__u/cybersecuritychronicles.substack.com/c_limit, /__u/cybersecuritychronicles.substack.com/f_webp, /__u/cybersecuritychronicles.substack.com/q_auto:good, /__u/cybersecuritychronicles.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0e251f2-90b5-483c-90d2-bf2f09e79e6f_897x454.jpeg 424w, /__u/substackcdn.com/image/fetch/$s_!Dtx0!, /__u/cybersecuritychronicles.substack.com/w_848, /__u/cybersecuritychronicles.substack.com/c_limit, /__u/cybersecuritychronicles.substack.com/f_webp, /__u/cybersecuritychronicles.substack.com/q_auto:good, /__u/cybersecuritychronicles.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0e251f2-90b5-483c-90d2-bf2f09e79e6f_897x454.jpeg 848w, /__u/substackcdn.com/image/fetch/$s_!Dtx0!, /__u/cybersecuritychronicles.substack.com/w_1272, /__u/cybersecuritychronicles.substack.com/c_limit, /__u/cybersecuritychronicles.substack.com/f_webp, /__u/cybersecuritychronicles.substack.com/q_auto:good, /__u/cybersecuritychronicles.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0e251f2-90b5-483c-90d2-bf2f09e79e6f_897x454.jpeg 1272w, /__u/substackcdn.com/image/fetch/$s_!Dtx0!, /__u/cybersecuritychronicles.substack.com/w_1456, /__u/cybersecuritychronicles.substack.com/c_limit, /__u/cybersecuritychronicles.substack.com/f_webp, /__u/cybersecuritychronicles.substack.com/q_auto:good, /__u/cybersecuritychronicles.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0e251f2-90b5-483c-90d2-bf2f09e79e6f_897x454.jpeg 1456w" sizes="100vw"><img src="/__u/substackcdn.com/image/fetch/$s_!Dtx0!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0e251f2-90b5-483c-90d2-bf2f09e79e6f_897x454.jpeg" width="728" height="368.463768115942" data-attrs="{&quot;src&quot;:&quot;https://substack-post-media.s3.amazonaws.com/public/images/f0e251f2-90b5-483c-90d2-bf2f09e79e6f_897x454.jpeg&quot;,&quot;srcNoWatermark&quot;:null,&quot;fullscreen&quot;:false,&quot;imageSize&quot;:&quot;normal&quot;,&quot;height&quot;:454,&quot;width&quot;:897,&quot;resizeWidth&quot;:728,&quot;bytes&quot;:121559,&quot;alt&quot;:null,&quot;title&quot;:null,&quot;type&quot;:&quot;image/jpeg&quot;,&quot;href&quot;:null,&quot;belowTheFold&quot;:false,&quot;topImage&quot;:true,&quot;internalRedirect&quot;:&quot;https://cybersecuritychronicles.substack.com/i/199229699?img=https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0e251f2-90b5-483c-90d2-bf2f09e79e6f_897x454.jpeg&quot;,&quot;isProcessing&quot;:false,&quot;align&quot;:&quot;center&quot;,&quot;offset&quot;:false}" class="sizing-normal" alt="" srcset="/__u/substackcdn.com/image/fetch/$s_!Dtx0!, /__u/cybersecuritychronicles.substack.com/w_424, /__u/cybersecuritychronicles.substack.com/c_limit, /__u/cybersecuritychronicles.substack.com/f_auto, /__u/cybersecuritychronicles.substack.com/q_auto:good, /__u/cybersecuritychronicles.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0e251f2-90b5-483c-90d2-bf2f09e79e6f_897x454.jpeg 424w, /__u/substackcdn.com/image/fetch/$s_!Dtx0!, /__u/cybersecuritychronicles.substack.com/w_848, /__u/cybersecuritychronicles.substack.com/c_limit, /__u/cybersecuritychronicles.substack.com/f_auto, /__u/cybersecuritychronicles.substack.com/q_auto:good, /__u/cybersecuritychronicles.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0e251f2-90b5-483c-90d2-bf2f09e79e6f_897x454.jpeg 848w, /__u/substackcdn.com/image/fetch/$s_!Dtx0!, /__u/cybersecuritychronicles.substack.com/w_1272, /__u/cybersecuritychronicles.substack.com/c_limit, /__u/cybersecuritychronicles.substack.com/f_auto, /__u/cybersecuritychronicles.substack.com/q_auto:good, /__u/cybersecuritychronicles.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0e251f2-90b5-483c-90d2-bf2f09e79e6f_897x454.jpeg 1272w, /__u/substackcdn.com/image/fetch/$s_!Dtx0!, /__u/cybersecuritychronicles.substack.com/w_1456, /__u/cybersecuritychronicles.substack.com/c_limit, /__u/cybersecuritychronicles.substack.com/f_auto, /__u/cybersecuritychronicles.substack.com/q_auto:good, /__u/cybersecuritychronicles.substack.com/fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff0e251f2-90b5-483c-90d2-bf2f09e79e6f_897x454.jpeg 1456w" sizes="100vw" fetchpriority="high"></picture><div class="image-link-expand"><div class="pencraft pc-display-flex pc-gap-8 pc-reset"><button tabindex="0" type="button" class="pencraft pc-reset pencraft icon-container restack-image"><svg aria-hidden="true" width="20" height="20" viewBox="0 0 20 20" fill="none" stroke-width="1.5" stroke="var(--color-fg-primary)" stroke-linecap="round" stroke-linejoin="round" xmlns="http://www.w3.org/2000/svg"><g><path d="M2.53001 7.81595C3.49179 4.73911 6.43281 2.5 9.91173 2.5C13.1684 2.5 15.9537 4.46214 17.0852 7.23684L17.6179 8.67647M17.6179 8.67647L18.5002 4.26471M17.6179 8.67647L13.6473 6.91176M17.4995 12.1841C16.5378 15.2609 13.5967 17.5 10.1178 17.5C6.86118 17.5 4.07589 15.5379 2.94432 12.7632L2.41165 11.3235M2.41165 11.3235L1.5293 15.7353M2.41165 11.3235L6.38224 13.0882"></path></g></svg></button><button tabindex="0" type="button" class="pencraft pc-reset pencraft icon-container view-image"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-maximize2 lucide-maximize-2"><polyline points="15 3 21 3 21 9"></polyline><polyline points="9 21 3 21 3 15"></polyline><line x1="21" x2="14" y1="3" y2="10"></line><line x1="3" x2="10" y1="21" y2="14"></line></svg></button></div></div></div></a></figure></div><blockquote><p><strong>This week we see&#8230; </strong>a consistent pattern where vendor access becomes the entry point, detection is measured in weeks instead of hours, and accountability arrives only after disclosure forces it. The gap is not between strong security and weak security. The gap is between what boards are told exists and what reality incident response reveals.</p></blockquote><h1>&#10024; QUICK WIN</h1><p>Ask your security leadership in tomorrow&#8217;s meeting:</p><blockquote><p><em><strong>"If a vendor gets breached today and attackers use their access to move into our network, how many hours until we detect it and who gets the alert?"</strong></em></p></blockquote><p>If the answer includes phrases like 'it depends' or 'we would investigate,' ask them to set up a demonstration environment and show that the detection capability exists before your next board meeting.</p><h2>Week in Brief</h2><h4><strong>HEALTHCARE: 11-Week Network Compromise in Public Hospital System</strong></h4><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.hipaajournal.com/nyc-health-hospitals-data-breach-march-26/">NYC Health + Hospitals</a>, the largest public healthcare system in the United States, disclosed on May 19 that 1.8 million current and former patients and employees were compromised in a data breach. Hackers had access to its network for 11 weeks, from November 25, 2025, until February 11, 2026. The investigation suggests initial access was gained through a security breach at one of its third-party vendors. The system serves more than 1 million New Yorkers, mostly uninsured patients under Medicaid. Compromised data included names, medical record numbers, diagnoses, medications, test results, Social Security numbers, driver&#8217;s license numbers, financial account information, and biometric data (fingerprints and palm prints).</p><p><strong>&#129000; PROBABLE CAUSE: </strong>A third-party vendor&#8217;s security failure provided the initial access vector, allowing attackers to move laterally through the network for nearly three months before detection.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Require security leadership to demonstrate that they can detect a vendor-originating lateral movement attempt within 24 hours. If they cannot demonstrate it, the capability does not exist.</p><p><strong>&#129002; REALITY CHECK: </strong>For<strong> </strong>11 weeks or ~3 months. Attackers had access to biometric data, medical records, diagnoses, medications, and financial information from 1.8 million individuals in the largest public healthcare system in the United States. The breach began on November 25, moved laterally through vendor-connected systems, and continued undetected until February 11. Which means for nearly 80 days, this unauthorized access to Medicaid patient data went unnoticed while security monitoring assumed normal vendor activity. Which raises the question your board should be asking: can your vendor risk program distinguish between having a third-party security questionnaire and actually monitoring whether vendor security can prevent the exfiltration of protected data in real time?</p><p><strong>AVIATION: Critical Infrastructure Supplier Breach</strong></p><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.breachsense.com/breaches/panasonic-avionics-data-breach/">Panasonic Avionics Corporation</a>, a leading supplier of in-flight entertainment and communications systems, was reportedly breached on May 22, 2026, by threat actor CoinbaseCartel. The company supplies customized in-flight systems to major aerospace manufacturers, including Boeing, Airbus, and Bombardier. Panasonic Avionics employs over 5,000 individuals and is headquartered in Irvine, California. The breach marks at least the second major incident for the company, following a December 2022 cyberattack that exposed employee and business customer data, including names, Social Security numbers, medical information, and financial account numbers.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Insufficient remediation from the 2022 incident likely left exploitable vulnerabilities in the corporate network infrastructure that manages supplier data for critical aerospace manufacturers.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Require leadership to demonstrate that a breach of a non-critical system cannot provide access to sensitive or operational systems. If segmentation cannot be verified through testing, it should be assumed not to exist.</p><p><strong>&#129002; REALITY CHECK: </strong>A second breach in 4 years. Same supplier. Multiple global enterprises all receive critical operational components from the same third-party vendor. The corporate network that stores engineering specifications and customer data has now been compromised twice since 2022. This raises the question that downstream organizations should be asking their critical suppliers before regulators ask it for them: whether core operational systems and corporate data repositories share the same network infrastructure that keeps getting breached.</p><p><strong>SUPPLY CHAIN: Missed Token Rotation After TanStack Compromise</strong></p><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.cybersecuritydive.com/news/grafana-labs-github-environment-breach-tanstack-npm-supply-chain/820866/">Grafana Labs</a>, the company behind the widely used observability platform serving over 7,000 customers, including Nvidia, Microsoft, and Anthropic, confirmed May 21 that its GitHub environment breach originated from the TanStack npm supply chain attack linked to Mini Shai-Hulud. After detecting malicious activity on May 11, Grafana rotated a significant number of GitHub workflow tokens as part of its initial response. However, one token was missed, allowing hackers to gain access to the company&#8217;s GitHub repositories. The hackers attempted to blackmail Grafana Labs, threatening to leak the codebase, but the company refused to submit to the extortion demands. The attack&#8217;s impact was limited to GitHub repositories, which include public and private source code.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Incomplete credential rotation during incident response left a single GitHub workflow token active, providing persistent access even after initial containment measures were implemented.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Demonstrate that all access credentials can be enumerated and revoked on demand within a defined timeframe. If complete revocation cannot be executed programmatically, access control is not under operational control.</p><p><strong>&#129002; REALITY CHECK: </strong>Grafana detected the TanStack supply chain compromise in its GitHub environment. The security team rotated a significant number of GitHub workflow tokens. 10 days later, Grafana disclosed that one token was missed, and attackers still had access to source code repositories for those 10 days. Which means the incident response process relied on manual identification of every workflow token across hundreds of automation pipelines serving 7,000 enterprise customers. Which raises the question your development leadership should be able to answer: whether your organization can programmatically revoke all repository access credentials within one hour of detecting a compromise, or whether your response depends on manually knowing or remembering which tokens exist and where they are configured.</p><p><strong>FINANCIAL SERVICES: $10M Settlement Exposes Claim Verification Failure</strong></p><p><strong>&#128998; WHY IT MATTERS: </strong>The <a href="https://openclassactions.com/news/nelnet-data-security-settlement-final-approval-update.php">$10 million Nelnet data security class action settlement</a> reportedly received final court approval after the March 5, 2026, claim deadline. The settlement covers approximately 2.5 million student loan borrowers affected by an August 2022 breach at Nelnet Servicing, Edfinancial Services, and the Oklahoma Student Loan Authority. Over 1 million claim forms were reportedly submitted by the deadline. However, only about 308,000 claims had been verified as eligible at the time of reporting, roughly 30%. Many claims were flagged for problems such as duplicates, missing documentation, or unmatched identities, where the claimant&#8217;s submitted information could not be matched to a person on the breach notification list.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Media attention around a large settlement drove a wave of fraudulent or unqualified claims from individuals not affected by the breach, attempting to capitalize on settlement funds intended for legitimate victims.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Quantify for leadership how external processes tied to a breach (claims, notifications, remediation programs) perform under scale. If effectiveness cannot be measured, financial exposure is being assumed rather than managed.</p><p><strong>&#129002; REALITY CHECK: </strong>One million claim forms were submitted by the deadline, and 308,000 were verified as eligible. The balance of 692,000 was flagged for fraud, duplicates, missing documentation, or identities that could not be matched to anyone on the original breach notification list sent to 2.5 million affected student loan borrowers. This means a settlement process designed to compensate legitimate victims saw a 70% rejection rate, where the majority of submitted claims came from those who could not provide sufficient documentation to prove they were victims. Which raises the question organizations negotiating future settlements should be asking: whether a widely publicized $10 million fund attracts more opportunistic (read: fraud) filings than legitimate claims, and whether the settlement structure creates barriers that prevent true victims from being able to navigate the claims verification process.</p><p><strong>RETAIL: Third-Party Breach Exposes Franchisee Data</strong></p><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.cybersecuritydive.com/news/7-eleven-cyberattack-franchisee-data/820698/">7-Eleven</a> confirmed May 20 that hackers breached its systems earlier this spring in an attack that exposed franchisee information. The retailer learned on April 8 that an unauthorized third party gained access to certain systems used to store franchisee documents. Those documents included personal information provided during the franchise application process. About 50 people in Massachusetts, Maine, and Vermont were impacted, with compromised data including names, addresses, Social Security numbers, and driver&#8217;s license numbers. Several weeks after the disclosure, reports surfaced that cyber gang ShinyHunters claimed responsibility for the attack, alleging they compromised more than 600,000 Salesforce records from the convenience retailer.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Third-party system storing franchise application documents lacked adequate access controls, allowing unauthorized access to sensitive franchisee personal information maintained for business purposes.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Third-party customer relationship management systems should be audited to verify that geolocation data, protected personal information, and business development records are segregated from customer-facing systems with separate access controls.</p><p><strong>&#129002; REALITY CHECK: </strong>7-Eleven discovers unauthorized access to franchisee documents. 42 days later, regulatory reports disclose roughly 50 affected individuals across three states to meet strict statutory deadlines. Late May: ShinyHunters claims a compromise of 600,000 Salesforce records. This 12,000:1 disparity between these figures highlights the friction between immediate legal compliance and enterprise forensic reality. While your team must methodically parse complex cloud tables to verify actual PII exposure, the clock mandated by state laws sometimes forces a premature, hyper-focused public disclosure. This leaves your organization and supply chain in a dangerous communication vacuum, forced to weigh organizational security against a minimal regulatory filing while the threat actor controls the narrative with a massive, claimed dataset.</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may-43f?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may-43f?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><h1>EXPERT PERSPECTIVE</h1><h2>CRG Live: Resilience Is Designed</h2><p><a href="https://www.linkedin.com/in/marycoan/">Dr. Mary Coan Skow</a>, PhD in chemical engineering, Certified Risk Management Professional, and executive coach who has built enterprise risk frameworks inside one of the most complex federal agency systems in the world, joined the Cyber Risk Governance Live to make the case that compliance, on its own, does not produce resilience. It produces a snapshot. And a snapshot is not a defense when the environment changes faster than the annual assessment cycle. The full panel recording is available on the Cybersecurity Chronicles LinkedIn page and is worth your time.</p><h4>Highlights</h4><p><strong>1. The Compliance Mindset Is the First Problem to Fix.</strong> Controls are documented, frameworks are mapped, boxes are checked, and the organization assumes the work is done. Dr. Skow&#8217;s challenge to that assumption is direct: </p><blockquote><p>&#8220;A control that passes today&#8217;s audit may fail tomorrow&#8217;s breach. Compliance is not maintaining dynamic stability. At a certain point in time, these things did work. Tomorrow, they might not.&#8221; </p></blockquote><p><strong>2. You Cannot Govern What You Cannot Name.</strong> Finance, legal, operations, and cybersecurity each define risk differently, and correctly, within their own domains. When those definitions are never reconciled into a shared framework, the gaps between them accumulate into exposure no one owns.</p><blockquote><p><em><strong>&#8220;If I say risk, you say risk, are we saying the same word?&#8221;</strong></em></p></blockquote><p><strong>3. The Plan Needs to Exist Before the Incident.</strong> Dr. Skow&#8217;s background in life-critical systems, where failure is measured in physical consequences, produces a governance discipline that cybersecurity organizations are still learning to adopt. </p><blockquote><p><em><strong>&#8220;Things fail. People make mistakes. So, when it occurs, because it&#8217;s going to happen, what&#8217;s the plan?&#8221;</strong></em></p></blockquote><p>Organizations that discover they have no plan at the moment of breach are not in a governance deficit. They are in a governance emergency.</p><p><strong>4. Psychological Safety Is a Governance Control.</strong> These conversations only happens if the person seeing the trend has the safety to say it. Organizations that punish early disclosure of risk and reward heroic remediation after failure are not governing. They are incentivizing silence until the damage is already visible.</p><blockquote><p><em><strong>&#8220;You&#8217;re not red yet, but we&#8217;re trending there. If we don&#8217;t do something, let&#8217;s do something now.&#8221; </strong></em></p></blockquote><h3>Insight</h3><p>The through-line in Dr. Skow&#8217;s framework is the distinction between governance coordinated by committee and governance built by design. One depends on everyone showing up to the right meeting with the right data at the right time and agreeing on what it means. The other is structural, embedded in how accountability is assigned, how information flows, and how the system behaves when no one is watching.</p><p>Her closing observation from the panel is the one worth sitting with: &#8220;Telling me it is safe to fail is not the same thing as being safe to fail.&#8221; A policy that says governance exists is not governance. The distance between the statement and the reality is where the exposure lives.</p><p>The full conversation covers failure containment by design, horizon scanning as a continuous governance discipline, and how to break the vicious cycle of cybersecurity inaction inside organizations that have been optimizing for compliance documentation rather than operational resilience.</p><p>This is one of the more substantive governance conversations the Cyber Risk Governance Live series has produced.</p><p>Watch the Full Recording <a href="https://youtu.be/Kbr1wJGgvvE?si=YqNXV_w0dS-1UuLs">HERE</a></p><div><hr></div><h2>RISK REDUCTION</h2><h3>The AI Speed Tax Has a Legal Bill Attached</h3><p><a href="https://www.fastly.com/resources/global-security-research-report-2026">Fastly&#8217;s 2026 Global Security Research Report</a>, drawing on 2,000 IT decision-makers surveyed across 21 regions in Q4 2025, delivers what the prior weeks of governance analysis have been building toward: the operational and financial consequences of AI adoption without governance infrastructure are now measurable, sector-specific, and compounding.</p><p>AI-first organizations take 80 days longer to recover from security incidents, pay 135% more when breaches occur, and more than half cannot identify who owns incident response.</p><p>Read as a security report, these findings describe a capability gap. Read through a legal lens, they describe a documented record of board-level decisions made without the governance architecture to support them, the kind of record that regulators, plaintiffs&#8217; attorneys, and insurance forensic teams are already building cases around.</p><h4>Highlights</h4><p>1. <strong>The Fiduciary Exposure: Higher Incident Costs Changes the Caremark Calculus</strong>. AI-first organizations face security incident costs that are 135% higher than their traditional peers, consuming an average of 3.13% of annual revenue compared to 1.33% for non-AI-first organizations. Under the Caremark doctrine, directors have an affirmative oversight duty to ensure that adequate information and reporting systems exist for material risks.</p><p>2. <strong>The 80-Day Recovery Gap Is a Regulatory Non-Compliance Guarantee</strong>. AI-first organizations average 6.8 months to recover from security incidents. That timeline is not just an operational failure. It is a statutory compliance impossibility. The SEC&#8217;s 4-day material incident disclosure rule, CIRCIA&#8217;s 72-hour reporting requirement, and healthcare breach notification mandates all operate on timelines that a 6.8-month remediation cycle cannot satisfy. The 80-day recovery gap is not a security metric. It is a contract breach in waiting.</p><p>3. <strong>Automated Privileges Create Automated Liabilities</strong>. Regulators will not accept the distinction, as 44% of AI-first organizations report that AI was directly exploited in their most recent incident, compared to 6% of non-AI-first organizations. The technical cause the report identifies is precise: sanctioned AI tools are being granted extensive, automated infrastructure permissions, and those permissions become the attack vector when the tools are compromised. The more autonomous the system, the more rigorous the governance required to satisfy the reasonable security standard - not less.</p><p>4. <strong>Incident Ownership Confusion Is Not a Management Gap</strong>. It is a legally deficient governance record that more than half of AI-first businesses report internal confusion over who handles incident response, compared to 23% of non-AI-first organizations. In operational terms, this is a structural problem. In legal terms, it is a documentation failure with consequences that outlast the incident itself.</p><h3>INSIGHT</h3><p>The Fastly report, taken alone, is a security research document with a clear operational argument: move fast in AI and pay more when things break. Placed in the sequence of governance data this newsletter has tracked across the past several weeks, it becomes something more consequential, a legal record of organizational decision-making that regulators and plaintiffs&#8217; attorneys will find highly legible.</p><p>The through-line is consistent. CISA documented that organizations are being told to fold agentic AI into governance frameworks most of them have not built. ISACA found that 56% of organizations cannot answer how long it would take to contain an AI system in a security incident, and only 12% have a tested shutdown procedure. Gartner established that 80% of organizations deploying AI cut headcount as their primary ROI strategy, removing the human governance layer from systems that require it most. The Fastly report now adds the financial and operational consequences: AI-first organizations pay 135% more when incidents occur, take 80 days longer to recover, and half of them cannot identify who owns the response when it matters.</p><p>Each of these data points represents a board-level decision with an evidentiary footprint. The decision to be AI-first is in strategy documents and board minutes. The decision to prioritize speed over resilience, documented in the report data at 72%, is reflected in budget allocations and project approvals. The absence of a tested incident response ownership structure is visible in the silence where that documentation should exist. And the financial consequences, 135% higher incident costs, 3.13% of annual revenue, 6.8-month recovery timelines, convert governance failures into damages calculations that actuaries, underwriters, and expert witnesses can quantify.</p><p>The CISO&#8217;s observation deserves to be read as a legal statement rather than an operational one: &#8220;I can&#8217;t wait for someone to come to me for approval, because if that&#8217;s happening, then I probably already failed.&#8221; By the time security leadership reviews a deployment decision, the liability architecture is already in place. The privileges have been granted. The attack surface has been created. The incident response ownership has not been documented. The board approved the strategy. The CISO absorbed the accountability. And the organization now faces an 80-day recovery gap it cannot explain to its regulators, its insurers, or its customers in the time those audiences are legally entitled to hear from it.</p><p>The organizations that will navigate this environment are not those with the most advanced AI programs. They are the ones whose boards treated AI deployment as a governance decision before it was a technology decision, requiring documented accountability structures, tested incident response ownership, and continuous evidence of control operation before approving any deployment that expands the attack surface.</p><p>Not as an aspiration. As a condition of approval.</p><p>The AI Speed Tax is not a technology cost. It is the legal and financial consequence of a governance decision the board made.</p><p>And unlike a technology investment, it does not depreciate. It compounds in recovery time, in revenue loss, in regulatory exposure, and eventually, in discovery.</p><div><hr></div><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h1>Tired of getting what you paid for?</h1><h2>Let&#8217;s Fix What&#8217;s Broken</h2><ul><li><p><strong>Real-World Risk Assessment:</strong> Stop guessing where your vulnerabilities are. We&#8217;ll give you a clear, prioritized roadmap to fix what&#8217;s actually at risk, not just what a checklist says.</p></li><li><p><strong>A &#8220;No-Nonsense&#8221; Health Check:</strong> Kickstart your governance journey with a complimentary session to identify your biggest gaps. No fluff, just the facts.</p></li></ul><h2>Stay Ahead of the Curve</h2><ul><li><p><strong>Join the Conversation:</strong> Connect with our Cyber Risk Governance Community on LinkedIn. It&#8217;s where the best minds in the business share real insights, not just vendor pitches.</p></li><li><p><strong>Sit in on a Session:</strong> Attend our interactive LinkedIn Live events. We cut through the noise to discuss the real-world cyber risks that keep you up at night.</p></li></ul><h2>Get It Done.</h2><ol><li><p>Reach out to <a href="https://www.linkedin.com/article/edit/7370904157077037056/#">Netswitch Technology Management</a> today.</p></li><li><p><strong>Join Our <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> </strong>and connect with a dynamic network of professionals on LinkedIn. Exchange insights, transform risks into readiness, and stay ahead of evolving threats.</p></li><li><p><strong>Engage in Live Events:</strong> Attend interactive LinkedIn Live sessions. Dive into critical cyber risk topics with industry leaders from executive, technology, and governance backgrounds.</p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share&quot;,&quot;text&quot;:&quot;Share Cybersecurity Chronicles&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share Cybersecurity Chronicles</span></a></p><div><hr></div></li></ol><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Cyber Risk Governance Insights | May 18, 2026 | Edition No. 126]]></title><description><![CDATA[Where cybersecurity incidents become board-level accountability decisions]]></description><link>https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may-116</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may-116</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 18 May 2026 19:01:41 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<blockquote><p><strong>This week we see&#8230;</strong> the illusion of control as organizations continue to manage security to a checklist. Proactive security means moving beyond basic compliance, but survival requires an adaptive posture. Without a holistic, real-time view of your risk, you aren&#8217;t building resilience, you&#8217;re just funding your next crisis.</p></blockquote><h1>&#10024; QUICK WIN</h1><p>Ask in your next leadership meeting:</p><blockquote><p><em><strong>&#8220;Who owns the decision about which external software our developers are allowed to trust, and if one of those trusted tools is compromised today, how fast can we revoke that access across the entire company?&#8221;</strong></em></p></blockquote><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h2>Week in Brief</h2><h4>MANUFACTURING: Customer Schematics Leveraged for Attack</h4><p>&#128998; <strong>WHY IT MATTERS:</strong> <a href="https://www.securityweek.com/foxconn-confirms-north-american-factories-hit-by-cyberattack/">Foxconn</a>, the world&#8217;s largest electronics manufacturer and primary Apple supplier, confirmed May 12 that Nitrogen ransomware breached its North American factories. The attackers claim to hold 8 terabytes of stolen data containing technical drawings and hardware schematics for Intel, Apple, Google, Dell, and Nvidia projects. This marks Foxconn&#8217;s fourth major ransomware attack in five years.</p><p>&#129000; <strong>PROBABLE CAUSE:</strong> Initial access was gained to internal networks to quietly exfiltrate customer intellectual property over a period of weeks or months without detection.</p><p>&#129001; <strong>PROACTIVE PREVENTION:</strong> Move beyond standard compliance questionnaires. Audit vendor contracts to ensure the inclusion of strict &#8220;Liquidated Damages&#8221; and IP protection clauses. Mandate immediate forensic access rights, breach notifications within 24 hours, and clear liability frameworks for customer data exposure.</p><p>&#129002; <strong>REALITY CHECK:</strong> When your contract manufacturer suffers its fourth ransomware attack in five years, it&#8217;s not a vendor security problem. You&#8217;re likely hiding your own outsourcing risk management failure from the board.</p><h4>SUPPLY CHAIN: Weaponizing Developer Trust</h4><p>&#128998; <strong>WHY IT MATTERS:</strong> A sprawling supply chain attack dubbed <em><a href="https://cyberscoop.com/mini-shai-hulud-supply-chain-malware-attack/">Mini Shai-Hulud</a></em><a href="https://cyberscoop.com/mini-shai-hulud-supply-chain-malware-attack/"> </a>compromised hundreds of open-source software packages, including TanStack&#8217;s React Router (which sees 12 million weekly downloads). The malware successfully bypassed two-factor authentication (2FA) and carried valid digital signatures by hijacking automated development pipelines. It systematically steals cloud credentials while embedding permanent backdoors into Visual Studio Code and Claude Code configuration files.</p><p>&#129000; <strong>PROBABLE CAUSE:</strong> Exploitation of overly permissive development workflows using &#8220;orphaned commits&#8221; to inject malicious code into trusted building pipelines, allowing attackers to sign malware with legitimate company certificates.</p><p>&#129001; <strong>PROACTIVE PREVENTION:</strong> Stop assuming software tools are safe simply because they carry a valid digital signature. Require your security teams to implement continuous, automated behavioral monitoring across all development environments to flag legitimate software exhibiting abnormal network activity.</p><p>&#129002; <strong>REALITY CHECK:</strong> When attackers turn your developers&#8217; automation tools into a malware distribution network, it isn&#8217;t just a supply chain issue targeting your vendors. It is a direct strike targeting your trust.</p><h4>CRITICAL INFRASTRUCTURE: 0-Day Threat Sprints Past Cadence</h4><p>&#128998; <strong>WHY IT MATTERS:</strong> Just 48 hours after <a href="https://www.securityweek.com/microsoft-warns-of-exchange-server-zero-day-exploited-in-the-wild/">Microsoft&#8217;s (aka Patch Tuesday)</a> regular monthly update addressed 137 vulnerabilities, a high-severity &#8220;zero-day&#8221; flaw was discovered already being actively exploited in in-house Exchange email servers. A permanent fix from the vendor is not yet available. This marks the 19th time this specific email framework has landed on the government&#8217;s list of actively exploited critical vulnerabilities.</p><p>&#129000; <strong>PROBABLE CAUSE:</strong> A loophole in the web-accessible email portal skipped completely past the standard monthly update cycle, allowing attackers to strike before emergency defenses could be deployed.</p><p>&#129001; <strong>PROACTIVE PREVENTION:</strong> Move past check-the-box compliance cadences. Instruct your security leadership to provide an immediate containment strategy for when a major vendor system is compromised before a patch even exists. Furthermore, if your business continuity plan (BCP) still relies on hosting your own internal email infrastructure after 19 systemic failures, demand a firm timeline to migrate to alternative, cloud-based platforms to shift that liability off your books.</p><p>&#129002; <strong>REALITY CHECK:</strong> The routine monthly &#8220;patching day&#8221; is an executive security blanket. Relying on a fixed calendar cadence to protect a living infrastructure gives leadership a false sense of safety. Attackers do not wait for your scheduled maintenance windows; they operate in real-time.</p><h4>FINANCIAL SERVICES: $2.5 Million Settlement for 3 Days of Exposure</h4><p>&#128998; <strong>WHY IT MATTERS:</strong> <a href="https://topclassactions.com/lawsuit-settlements/open-lawsuit-settlements/2-5m-fidelity-investment-data-breach-class-action-settlement/">Fidelity Investments</a> has agreed to pay $2.5 million to resolve a class-action lawsuit over a breach that exposed customer account numbers and routing information during a tiny three-day window. The lawsuit critically alleged that Fidelity failed to implement reasonable, available cybersecurity measures that they already had at their disposal. Class members can now receive up to $5,000 each for documented losses.</p><p>&#129000; <strong>PROBABLE CAUSE:</strong> Inadequate security controls allowed unauthorized access to sensitive customer data repositories to go unnoticed for days before detection.</p><p>&#129001; <strong>PROACTIVE PREVENTION:</strong> Move past static, retrospective access reviews. Require your security leadership to implement automated, real-time alerting that flags bulk data access or unusual downloads within minutes, not days. Furthermore, mandate regular simulated credential-compromise exercises to validate that your team can actually spot a live threat before data leaves the system.</p><p>&#129002; <strong>REALITY CHECK:</strong> To a traditional executive, a three-day exposure window sounds like a fast, successful containment story. The reality is that three days is an absolute eternity for automated data theft. If your security posture measures detection and response in days instead of minutes, you aren&#8217;t building a resilient business; you&#8217;re just subsidizing your next class-action settlement. (<strong>For affected investors</strong> - good luck ever seeing the &#8220;up to&#8221; amount. Reality is, where will you invest your $0.75?)</p><h4>CRITICAL INFRASTRUCTURE: Railway Signals Intercepted Remotely</h4><p>&#128998; <strong>WHY IT MATTERS:</strong> A major <a href="https://www.darkreading.com/ics-ot-security/taiwan-incident-highlights-cybersecurity-gaps">Taiwan high-speed rail incident</a> exposed catastrophic security gaps when an outsider successfully intercepted radio communications, copied system identifiers, and triggered emergency braking alerts by impersonating legitimate rail signals. The breach revealed that the rail corporation&#8217;s core operational communication systems completely lacked basic identity verification, encryption updates, and anomaly detection.</p><p>&#129000; <strong>PROBABLE CAUSE:</strong> The core radio communication framework was left completely open and unauthenticated, allowing a bad actor to easily listen in, clone the system&#8217;s identity, and broadcast unauthorized commands directly to the trains.</p><p>&#129001; <strong>PROACTIVE PREVENTION:</strong> Stop assuming your physical operations (Operational Technology) are safe just because they are separate from your corporate email networks. Instruct your leadership team to conduct an aggressive, independent security assessment of all physical control systems&#8212;whether they manage transportation, valves, or assembly lines. Mandate an advanced simulation test that explicitly attempts to hijack physical operations through radio or wireless signals, proving your systems can dynamically isolate a rogue command before it causes a physical catastrophe.</p><p>&#129002;<strong>REALITY CHECK:</strong> Most executives invest to secure corporate laptops and office firewalls while leaving the physical infrastructure that actually drives business value completely exposed. If an outsider can hijack your core operations with basic equipment, you don&#8217;t have a sophisticated technical problem&#8212;you have a governance blind spot. Security by obscurity is not a strategy; it&#8217;s a liability</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may-116?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may-116?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><p></p><h1>EXPERT PERSPECTIVE</h1><h2>Boards Approved the Layoffs.<br>Gartner Just Published the Returns.</h2><p>A May 2026 <a href="https://www.gartner.com/en/newsroom/press-releases/2026-05-05-gartner-says-autonomous-business-and-artificial-intelligence-layoffs-may-create-budget-room-but-do-not-deliver-returns">Gartner study</a> of 350 global enterprises found that while 80% of organizations deploying AI agents reduced headcount, those workforce cuts had no measurable correlation with improved ROI. Workforce reduction rates were nearly identical among organizations reporting strong returns and those reporting weak or negative outcomes.</p><p>Meanwhile, <a href="https://www.cnbc.com/2026/05/17/ai-related-layoffs-a-boost-for-stocks-not-necessarily.html">CNBC&#8217;s analysis</a> of two dozen publicly listed firms found that more than half saw stock declines after AI-related layoff announcements, averaging a 28% loss in pre-layoff value. The data arriving from multiple credible sources in May 2026 reaches the same conclusion: cutting people to demonstrate AI returns is not a strategy. It is a governance failure dressed as an efficiency narrative.</p><h3>Highlights</h3><ul><li><p><strong>80% Cut. None Got Returns From It.  </strong>Cutting staff after AI deployment was no more likely to improve ROI than those that did not. This finding dismantles the assumption that deploying AI and reducing headcount are the same decision.</p></li><li><p><strong>The Organizations Generating Returns Did the Opposite.  </strong>High-performing AI organizations that saw results: investment in skills, roles, and operating models that allow humans to guide and scale autonomous systems.</p></li><li><p><strong>AI-Washing Is Now a Disclosure Risk.  </strong>When AI-driven layoffs lead to stock declines averaging 28%, and analysts document the use of AI as cover for traditional cost-cutting, the question arises: was a board&#8217;s efficiency narrative a material misrepresentation, and does that become a securities disclosure problem, not just a reputational one?</p></li><li><p><strong>The Acceleration Is Compounding the Exposure.  </strong>Every board approving additional AI-driven reductions without addressing the ROI evidence is building a documented record of decisions made against available data.</p></li></ul><h3>Insight</h3><p>The Gartner finding is not a market surprise. It is a governance indictment.</p><p>When Gartner&#8217;s Distinguished VP Analyst states that &#8220;many CEOs turn to layoffs to <em>demonstrate</em> quick AI returns&#8221; and that &#8220;this disposition is misplaced,&#8221; the word that deserves attention is <em>demonstrate</em>, not generate, not achieve.</p><p>The layoffs were a performance: a signal to investors and boards that AI adoption was producing efficiency gains, structured to look like returns before the returns existed. That performance now has a data record. And that data record is the governance problem.</p><blockquote><p><em>Boards have a fiduciary obligation to make strategic decisions on the basis of available evidence. The evidence that AI-driven headcount reductions do not produce reliable returns was available before the next round of cuts was approved.</em></p></blockquote><p>The governance question for every board that has approved AI-driven workforce reductions is not whether the decision looked reasonable at the time. It is whether the board required evidence that it was. Meeting minutes, board presentations, the analysis provided before the vote, the questions asked, and the answers documented, these are the records that will be examined if shareholders conclude that the efficiency narrative was a misrepresentation and the board failed to challenge it.</p><p>Gartner identified the model that actually generates AI returns: amplifying human capability rather than eliminating it. The organizations building that model are investing in the skills, roles, and governance structures that allow humans to oversee autonomous systems. The organizations cutting the humans are removing the governance layer while spending more on the systems that require it.</p><p><em><strong>That is not an efficiency strategy. It is a governance gap with a balance sheet attached.</strong></em></p><h2>CRG Live Event: Resilience by Strategic Design</h2><h3>Engineering Cyber Defense from Day One</h3><p><strong>TOMORROW &#8212; <a href="https://www.linkedin.com/events/resiliencebystrategicdesign-eng7457383402737000448/theater/">Tuesday, May 19, 2026 | 10:00 AM Pacific / 1:00 PM Eastern | 60 Minutes</a></strong></p><p>You wouldn&#8217;t build a bridge by responding to cracks. You&#8217;d design for failure containment from the first schematic. That&#8217;s the standard cybersecurity governance must now meet.</p><p>Most organizations build cyber defense reactively, after incidents, after audits, after regulators arrive. In 2026, that posture is the single largest predictor of who fails when the breach lands.</p><p>Join us for a LinkedIn Live discussion on how to operationalize resilience as a design decision, not a response capability:</p><h4>What We&#8217;ll Cover:</h4><ul><li><p><strong>The Fragmentation Ga</strong>p: Integrating Enterprise Risk, Change Management, and Project Leadership into one unified control surface</p></li><li><p><strong>The &#8220;Pin Drop&#8221; Baseline</strong>: Why you can&#8217;t engineer resilience without knowing your true starting point</p></li><li><p><strong>The Maturity Wall</strong>: How to bridge the gap from &#8220;Reactive&#8221; to &#8220;Adaptive&#8221;</p></li><li><p><strong>Legally Defensible Evidence</strong>: The new ROI standard for 2026</p></li></ul><p><strong>Featured Guest:</strong> <a href="https://www.linkedin.com/in/marycoan/">Dr. Mary R. Coan Skow, PhD</a>, Federal Agency Risk Management Officer. Two decades leading ERM for a large federal agency with a &#8220;life-critical&#8221; engineering mindset where design failure is measured in structural integrity and human lives.</p><p><strong>Hosted by:</strong> <a href="https://www.linkedin.com/in/netswitchstanleyli/">Stanley Li</a>, CEO &amp; Founder, and <a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney</a>, CISM, Vice President at Netswitch, Inc.</p><p><strong>Free to attend: <a href="https://www.linkedin.com/events/resiliencebystrategicdesign-eng7457383402737000448/theater/">Register HERE</a></strong></p><p><strong>Who should attend:</strong> CEOs, CFOs, board members, CISOs, risk officers, general counsel, and anyone responsible for translating cyber risk into business decisions.</p><div><hr></div><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h1>Tired of getting what you paid for?</h1><h2>Let&#8217;s Fix What&#8217;s Broken</h2><ul><li><p><strong>Real-World Risk Assessment:</strong> Stop guessing where your vulnerabilities are. We&#8217;ll give you a clear, prioritized roadmap to fix what&#8217;s actually at risk, not just what a checklist says.</p></li><li><p><strong>A &#8220;No-Nonsense&#8221; Health Check:</strong> Kickstart your governance journey with a complimentary session to identify your biggest gaps. No fluff, just the facts.</p></li></ul><h2>Stay Ahead of the Curve</h2><ul><li><p><strong>Join the Conversation:</strong> Connect with our Cyber Risk Governance Community on LinkedIn. It&#8217;s where the best minds in the business share real insights, not just vendor pitches.</p></li><li><p><strong>Sit in on a Session:</strong> Attend our interactive LinkedIn Live events. We cut through the noise to discuss the real-world cyber risks that keep you up at night.</p></li></ul><h2>Get It Done.</h2><ol><li><p>Reach out to <a href="https://www.linkedin.com/article/edit/7370904157077037056/#">Netswitch Technology Management</a> today.</p></li><li><p><strong>Join Our <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> </strong>and connect with a dynamic network of professionals on LinkedIn. Exchange insights, transform risks into readiness, and stay ahead of evolving threats.</p></li><li><p><strong>Engage in Live Events:</strong> Attend interactive LinkedIn Live sessions. Dive into critical cyber risk topics with industry leaders from executive, technology, and governance backgrounds.</p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share&quot;,&quot;text&quot;:&quot;Share Cybersecurity Chronicles&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share Cybersecurity Chronicles</span></a></p><div><hr></div></li></ol><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Cyber Risk Governance Insights | May 11, 2026 | Edition No. 125]]></title><description><![CDATA[Where cybersecurity incidents become board-level accountability decisions]]></description><link>https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may-d8f</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may-d8f</guid><pubDate>Mon, 11 May 2026 20:31:02 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<blockquote><p>This week shows a recurring failure: treating third-party risk as a procurement checkbox rather than a primary threat vector. The common thread is delayed detection and unmanaged vendor access that turned technical incidents into systemic crises.</p></blockquote><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h2>&#10024; QUICK WIN</h2><p>Ask when the last time was that every vendor with VPN or administrative access to our systems was reviewed. Have they accessed your systems in the last 90 days? If not, revoke their credentials within 48 hours.</p><h1>WEEK IN BRIEF</h1><h2>EDUCATION: Ignoring Patches Becomes Public Ransom</h2><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.wired.com/story/canvas-hack-shinyhunters-ransomware-instructure/">Instructure&#8217;s</a> Canvas platform, used by over 8,000 institutions, suffered a record-breaking (second) breach after attackers exploited unmanaged &#8220;Free-For-Teacher&#8221; accounts to access 3.65TB of data for 275 million users. The crisis peaked during finals week when ShinyHunters hijacked login pages with ransom demands after the vendor prioritized patching over extortion management. The attack began April 29 with initial access through trial accounts, but when Instructure deployed security patches without acknowledging the attackers, ShinyHunters escalated by defacing thousands of institutional login portals on May 7, forcing Canvas offline campus-wide and blocking students from exam materials hours before finals. By May 8 restoration, the incident had become the largest educational security breach on record, affecting 41% of U.S. higher education institutions.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Architectural weakness in unmanaged trial accounts allowed attackers a pivot point into production systems.</p><p><strong>&#129001; THE BOARD SHOULD ASK: </strong>What &#8220;shadow IT&#8221; or trial offerings are in our stack that might bypass our security controls? How do we distinguish between technical remediation and active extortion during a breach?</p><p><strong>&#129002; GOVERNANCE TAKEAWAY: </strong>Incident response without threat actor intelligence is just wishful thinking with better documentation.</p><h2>VENDOR SECURITY: MSSP Needs an MSSP</h2><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.securityweek.com/trellix-source-code-repository-breached/">Trellix</a> disclosed that attackers, later identified as the RansomHouse group, gained access to its source code repository. For a company protecting 200 million endpoints across 50,000 business and government customers, stolen source code provides a roadmap for attackers to identify vulnerabilities, understand detection logic, and develop evasion techniques. While Trellix stated it found no evidence the code has been exploited or that distribution processes were compromised, the May 7 RansomHouse claim with screenshots allegedly showing access to appliance management systems suggests the breach extent may be larger than initially disclosed. The incident follows similar 2026 supply chain attacks targeting security vendor repositories at Checkmarx, Aqua Security, and F5 Networks.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Compromise of development environments or GitHub repositories to exfiltrate proprietary code and CI/CD secrets.</p><p><strong>&#129001; THE BOARD SHOULD ASK: </strong>What process exists to evaluate if our security tools are vulnerable to exploits born from their own stolen source code? Do our contracts include provisions for accelerated updates in these scenarios?</p><p><strong>&#129002; GOVERNANCE TAKEAWAY: </strong>Selling endpoint protection while failing to protect your own source code is the cybersecurity equivalent of a fire extinguisher company burning down.</p><h2>CRITICAL INFRASTRUCTURE: 11 Day to Notice the Breach</h2><p><strong>&#128998; WHY IT MATTERS: </strong>Critical infrastructure provider <a href="https://www.wsj.com/pro/cybersecurity/itron-hackers-accessed-critical-infrastructure-operators-1ef18c7f">Itron</a>, managing 112 million smart meter and sensor endpoints for 7,700 utility customers across electricity, gas, and water systems in 100 countries, spent 11 days unaware that attackers had infiltrated its internal IT network beginning April 13. The company&#8217;s SEC filing stated it was &#8220;notified&#8221; of the breach rather than discovering it internally, suggesting an external party surfaced the compromise. Because an external party notified Itron of the breach, the dwell time likely allowed attackers to map internal systems, harvest customer deployment details, and potentially position access mechanisms for future operations against specific utilities. While Itron claimed customer-hosted systems weren&#8217;t affected, this distinction matters little when vendor IT environments contain remote access credentials and network architecture documentation.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Failure of internal monitoring to detect unauthorized lateral movement within the corporate IT environment.</p><p><strong>&#129001; THE BOARD SHOULD ASK: </strong>Do we have independent monitoring to detect if compromised vendor credentials are used to probe our operational technology (OT)? Why did it take an external notification to surface this breach?</p><p><strong>&#129002; GOVERNANCE TAKEAWAY: </strong>11 days of undetected access at a critical vendor isn&#8217;t just an incident, it&#8217;s a head start on mapping 7,700 utility networks.</p><h2>SUPPLY CHAIN: Malware from the Official Website</h2><p><strong>&#128998; WHY IT MATTERS: </strong>For nearly a month, the official <a href="https://www.bleepingcomputer.com/news/security/daemon-tools-trojanized-in-supply-chain-attack-to-deploy-backdoor/">Daemon Tools</a> website distributed trojanized installers signed with valid digital certificates. Kaspersky discovered that versions 12.5.0.2421 through 12.5.0.2434, distributed from April 8 through May 5, contained malicious code in three core binaries signed with legitimate Daemon Tools certificates, bypassing Windows security warnings. This sophisticated attack infected thousands of systems globally across more than 100 countries, with malware profiling victims and deploying advanced backdoors only to select government, scientific, manufacturing, and retail organizations in Russia, Belarus, and Thailand. Evidence pointing to Chinese-speaking threat actors suggests an espionage operation using popular software as initial access infrastructure for targeted surveillance.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Compromise of the build pipeline or release infrastructure, allowing attackers to sign malicious code with the company&#8217;s private keys.</p><p><strong>&#129001; THE BOARD SHOULD ASK: </strong>Does our endpoint detection look beyond signatures to behavioral analysis that catches signed malware acting strangely?</p><p><strong>&#129002; GOVERNANCE TAKEAWAY: </strong>When official channels distribute signed malware, your &#8220;trusted vendor&#8221; checkbox becomes the attack vector auditors never imagined.</p><h2>FINANCIAL SERVICES: Vendor Incident Becomes Class Action</h2><p><strong>&#128998; WHY IT MATTERS: </strong>A cybersecurity incident at a third-party IT provider for the <a href="https://www.seattletimes.com/business/alaska-air-group-credit-union-sued-over-data-breach/">Alaska Air Group Federal Credit Union</a> exposed the Social Security numbers, account numbers, dates of birth, driver&#8217;s license numbers, passport numbers, routing numbers, and tax identification numbers of 10,705 members. The breach originated March 5 when the third-party IT service provider experienced a cybersecurity incident, allowing unauthorized actors to pivot into Credit Union systems and potentially copy files containing highly sensitive member information. Within six weeks of the April 16 disclosure, a class action lawsuit was filed alleging the Credit Union failed to implement reasonable security measures. The Credit Union is offering 24 months of Experian credit monitoring, but this standard response does little to address permanent exposure from compromised Social Security numbers.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Overly permissive access granted to a third-party provider, combined with a lack of real-time monitoring for unusual vendor file access.</p><p><strong>&#129001; THE BOARD SHOULD ASK: </strong>What controls limit the scope of third-party access to only what is operationally necessary? Do we have real-time alerting for unusual file access patterns from vendor credentials?</p><p><strong>&#129002; GOVERNANCE TAKEAWAY: </strong>Your vendor&#8217;s security incident becomes your data breach becomes your class action lawsuit.</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may-d8f?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may-d8f?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><h1>EXPERT PERSPECTIVE</h1><h2>CRG Live Event: Resilience by Strategic Design</h2><h3>Engineering Cyber Defense from Day One</h3><p><strong><a href="https://www.linkedin.com/events/resiliencebystrategicdesign-eng7457383402737000448/theater/">Tuesday, May 19, 2026 | 10:00 AM Pacific / 1:00 PM Eastern | 60 Minutes</a></strong></p><p>You wouldn&#8217;t build a bridge by responding to cracks. You&#8217;d design for failure containment from the first schematic. That&#8217;s the standard cybersecurity governance must now meet.</p><p>Most organizations build cyber defense reactively, after incidents, after audits, after regulators arrive. In 2026, that posture is the single largest predictor of who fails when the breach lands.</p><p>Join us for a LinkedIn Live discussion on how to operationalize resilience as a design decision, not a response capability:</p><p><strong>What We&#8217;ll Cover:</strong></p><ul><li><p>The Fragmentation Gap: Integrating Enterprise Risk, Change Management, and Project Leadership into one unified control surface</p></li><li><p>The &#8220;Pin Drop&#8221; Baseline: Why you can&#8217;t engineer resilience without knowing your true starting point</p></li><li><p>The Maturity Wall: How to bridge the gap from &#8220;Reactive&#8221; to &#8220;Adaptive&#8221;</p></li><li><p>Legally Defensible Evidence: The new ROI standard for 2026</p></li></ul><p><strong>Featured Guest:</strong> <a href="https://www.linkedin.com/in/marycoan/">Dr. Mary R. Coan Skow, PhD</a>, Federal Agency Risk Management Officer. Two decades leading ERM for a large federal agency with a &#8220;life-critical&#8221; engineering mindset where design failure is measured in structural integrity and human lives.</p><p><strong>Hosted by:</strong> <a href="https://www.linkedin.com/in/netswitchstanleyli/">Stanley Li</a>, CEO &amp; Founder, and <a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney</a>, CISM, Vice President at Netswitch, Inc.</p><p><strong>Free to attend: <a href="https://www.linkedin.com/events/resiliencebystrategicdesign-eng7457383402737000448/theater/">Register HERE</a></strong></p><p><strong>Who should attend:</strong> CEOs, CFOs, board members, CISOs, risk officers, general counsel, and anyone responsible for translating cyber risk into business decisions.</p><div><hr></div><h2>Data That Dismantles the Recommendation</h2><p><a href="https://www.isaca.org/resources/news-and-trends/isaca-now-blog/2026/the-ai-security-gap-adoption-is-accelerating-but-response-capability-is-lagging">ISACA&#8217;s 2026 AI Pulse Poll</a>, published May 5, 2026, documents a gap between AI adoption and governance readiness that most boards have not yet internalized. Ninety percent of respondents believe employees are already using AI in their organization. Eighty-one percent confirm that generative AI specifically is in use.</p><p>The data is unambiguous: AI is not arriving.</p><p>It is already operating inside most enterprises, shaping how staff write, analyze, decide, and communicate, without the governance infrastructure to match. The article concludes, as CISA did four days earlier, that organizations should weave AI into their existing cyber governance practices. The problem is that ISACA&#8217;s own data makes the strongest available case that most organizations cannot execute that recommendation.</p><h4>Highlights</h4><p><strong>1. Shadow AI Is Not a Future Risk.</strong> Any board that has not explicitly addressed shadow AI in its risk register is governing a risk it has chosen not to see. Not seeing a risk only reduces the defensibility of the organization&#8217;s position.</p><p><strong>2. The Most Consequential Finding.</strong> 88% of organizations deploying AI cannot demonstrate a tested, documented response procedure for when something goes wrong. In any other operational risk category, the absence of tested IR procedures would be considered a material governance failure.</p><p><strong>3. Most Basic Operational Readiness Question.</strong> 56% of respondents do not know how long it would take to halt an AI system in the event of a security incident. This is a governance accountability gap, because no one in the organization owns containment.</p><p><strong>4. Policy / Governance Conflation Has a Cost.</strong> 38% of organizations now report having a formal, comprehensive AI policy, up from 28% in 2025. The article presents this as progress, but it&#8217;s not progress on governance. A policy document that cannot produce time-stamped evidence of its own implementation is not a governance program. It is a compliance script.</p><div><hr></div><h3>Insight</h3><p>The ISACA article is well researched, data-grounded, and directionally correct. The recommendations, assign clear ownership, create operational safeguards beyond static policies, weave AI into existing practices, and invest in board-level education, are the right prescriptions. The gap is not in the diagnosis or the prescription. It is the premise underlying both.</p><p>The article makes the same architectural assumption that the <a href="https://www.cisa.gov/resources-tools/resources/careful-adoption-agentic-ai-services">CISA guidance</a> published earlier makes: that the existing governance infrastructure organizations are being told to extend to AI is itself functional. ISACA&#8217;s own data challenges that assumption at every turn.</p><ul><li><p>12% have tested shutdown procedures.</p></li><li><p>38% have a formal policy.</p></li><li><p>38% have boards they consider adequately informed.</p></li></ul><p>These are not numbers that describe a governance foundation capable of absorbing a new category of autonomous, decision-making technology.</p><p>The article frames the gap as a security readiness problem, something security leaders, risk professionals, and boards need to close. That framing is partially right and materially incomplete. Security leaders cannot close a governance gap that begins in the boardroom. A CISO can document an AI incident response procedure. The CISO cannot ensure the board has reviewed it, approved it, assigned ownership for it, and created an audit trail proving that governance was genuine rather than procedural. That is a board accountability function, and the ISACA data suggests most boards have not performed it.</p><p>The 56% finding that organizations do not know how long it would take to halt an AI system in a security incident is not a technical measurement problem. If no one knows the answer, no one owns the question. Ownership of that question lives at the level where AI deployment decisions are approved. For most organizations, that is the C-suite and the board. The answer to &#8220;who owns AI incident response?&#8221; flows from the same governance decision as &#8220;who approved this AI deployment?&#8221; If the board approved the deployment without requiring a named owner for containment, the board created the accountability gap that the poll is measuring.</p><p>The organizations that will navigate the AI governance environment of the next three years successfully are not those with the most sophisticated AI policies. They are the ones whose boards asked, before approving any AI deployment, three questions the ISACA data suggests most boards are not asking: who owns this risk, what does a tested response look like, and can we produce a record proving governance was exercised before the incident rather than reconstructed after it?</p><p>Weaving AI into existing governance frameworks is the right destination. Getting there requires acknowledging that for most organizations, the existing governance framework is not the foundation ISACA&#8217;s recommendation assumes it to be. </p><p>The data ISACA published makes that point more forcefully than the recommendations section that follows it.</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><div><hr></div><h1>Tired of getting what you paid for?</h1><h2>Let&#8217;s Fix What&#8217;s Broken</h2><ul><li><p><strong>Real-World Risk Assessment:</strong> Stop guessing where your vulnerabilities are. We&#8217;ll give you a clear, prioritized roadmap to fix what&#8217;s actually at risk, not just what a checklist says.</p></li><li><p><strong>A &#8220;No-Nonsense&#8221; Health Check:</strong> Kickstart your governance journey with a complimentary session to identify your biggest gaps. No fluff, just the facts.</p></li></ul><h2>Stay Ahead of the Curve</h2><ul><li><p><strong>Join the Conversation:</strong> Connect with our Cyber Risk Governance Community on LinkedIn. It&#8217;s where the best minds in the business share real insights, not just vendor pitches.</p></li><li><p><strong>Sit in on a Session:</strong> Attend our interactive LinkedIn Live events. We cut through the noise to discuss the real-world cyber risks that keep you up at night.</p></li></ul><h2>Get It Done.</h2><ol><li><p>Reach out to <a href="https://www.linkedin.com/article/edit/7370904157077037056/#">Netswitch Technology Management</a> today.</p></li><li><p><strong>Join Our <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> </strong>and connect with a dynamic network of professionals on LinkedIn. Exchange insights, transform risks into readiness, and stay ahead of evolving threats.</p></li><li><p><strong>Engage in Live Events:</strong> Attend interactive LinkedIn Live sessions. Dive into critical cyber risk topics with industry leaders from executive, technology, and governance backgrounds.</p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share&quot;,&quot;text&quot;:&quot;Share Cybersecurity Chronicles&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share Cybersecurity Chronicles</span></a></p><div><hr></div></li></ol><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Cyber Risk Governance Insights | May 4, 2026]]></title><description><![CDATA[Where cybersecurity incidents become board-level accountability decisions]]></description><link>https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may</guid><pubDate>Mon, 04 May 2026 18:01:30 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<blockquote><p><em><strong>This week proves the threat isn't sophisticated attackers but foundational controls your organization treats as optional. When did compliance checkboxes become more important than the compliance itself?</strong></em></p></blockquote><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h1>&#10024; QUICK WIN</h1><p>Audit your Google Workspace for third-party applications with full Drive access. Go to admin.google.com, navigate to:</p><p><em><strong>Security &gt; Access and Data Control &gt; API Controls &gt; Manage Third-Party App Access</strong></em></p><p>Review every application with broad data permissions. If you cannot document business justification and security review approval for an app&#8217;s access level, revoke it. </p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-may?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><h1>WEEK IN BRIEF</h1><h3>GALACTIC SPECIAL REPORT: Imperial CISO Force-Choked Following Death Star Post-Mortem</h3><p><strong>CORUSCANT</strong> &#8211; The Galactic Empire officially labeled the total destruction of the Death Star a &#8220;minor configuration oversight&#8221; caused by a single unpatched exhaust port.</p><p>The internal audit, leaked by a droid who bypassed the station&#8217;s nonexistent multi-factor authentication, reveals governance failures that would make a first-year CISM student weep.</p><p><em><strong>Key findings:</strong></em></p><p>&#128308; <strong>Zero-Trust Failure</strong>: A 30-year-old Astromech droid interpreted the entire Imperial network by plugging into a wall socket. No authentication challenge. Apparently, &#8220;being a droid&#8221; is a valid administrative credential.</p><p>&#128308; <strong>The Moff Tarkin Hubris</strong>: Despite warnings that rebels found a weakness, Grand Moff Tarkin declined to evacuate or patch, citing high &#8220;Return on Imperial Investment&#8221; for the planet-killing laser.</p><p>&#128308; <strong>Shadow IT</strong>: Project Stardust blueprints stored in clear-text on Scarif. The Empire&#8217;s data classification policy was as thin as Stormtrooper armor.</p><div class="callout-block" data-callout="true"><p>&#8220;We had ultimate power but no password on tractor beam controls,&#8221; said a former technician now seeking asylum on Tatooine. &#8220;Obi-Wan just turned a dial. No MFA. No logging. No alerting. Just a guy in a robe messing with our industrial control systems.&#8221;</p></div><p><strong>The Governance Takeaway</strong>: If your exhaust port connects to your main reactor without a firewall, don&#8217;t be surprised when a farm boy with a 2-meter-wide exploit ruins your fiscal year.</p><h3>HEALTHCARE: The Cheapest Control Everyone Skips</h3><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.hhs.gov/press-room/ocr-settles-four-ransomware-investigations.html">HHS Office for Civil Rights</a> settled four separate HIPAA Security Rule ransomware investigations totaling $1.165M in penalties, affecting over 427,000 individuals. The commonality: all four entities failed to conduct an accurate and thorough risk analysis, the most basic requirement in the HIPAA Security Rule. Regional Women&#8217;s Health Group paid $320K after ransomware exposed 37,989 patient records. Assured Imaging paid $375K for a breach affecting 244,813 individuals and for failing to notify affected parties promptly. Consociate paid $225K after a 2020 phishing attack led to a 2021 ransomware encrypting systems holding data on 136,539 individuals. SG Health Plan paid $245K for a breach affecting 9,316 plan participants. The investigations mark OCR&#8217;s 19th completed ransomware investigation and confirm that hacking and ransomware are the most frequent types of large breaches reported.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Organizations treated risk analysis as a compliance checkbox exercise rather than an operational security requirement, skipping the foundational step that identifies what needs protecting and how to protect it.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Conduct documented, annual risk analyses identifying where ePHI exists, how it flows through systems, and what vulnerabilities exist in those paths, then implement documented risk management plans addressing each identified gap with specific timelines and ownership.</p><p><strong>&#129002; THE GOVERNANCE TAKEAWAY:</strong> Even though the penalties were $2.73 per affected individual, when four separate organizations pay federal penalties for the same compliance failure, the message is that risk analysis is not a one-time documentation exercise but the foundation preventing everything else from becoming security theater. The fact that OCR has now completed 19 ransomware investigations suggests regulators have identified a pattern: organizations deploy controls without first determining what actually needs protecting, then discover during breach response that gaps existed for years without anyone noticing.</p><h3>OPEN SOURCE: Hacktivism Becomes a Shakedown</h3><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.theregister.com/2026/05/01/canonical_confirms_ubuntu_infrastructure_under/">Canonical</a>, the company behind Ubuntu Linux, confirmed its web infrastructure is under sustained cross-border DDoS attack from pro-Iran hacktivist group 313 Team (Islamic Cyber Resistance in Iraq). The attack kept Ubuntu.com down for over 12 hours, blocking users from downloading distros or logging into Canonical accounts. The group initially announced a 4-hour attack via Telegram but pivoted to extortion with a follow-up message: &#8220;There is a simple way out. We have emailed you with our Session Contact ID. If you fail to reach out, we will continue our assault.&#8221; The shift from political hacktivism to pay-or-packets-keep-coming marks the group&#8217;s evolution from ideological disruption to financially motivated extortion. 313 Team has claimed similar DDoS attacks against eBay Japan, eBay US, and BlueSky in the past month alone.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Insufficient DDoS mitigation capacity for a critical open-source infrastructure provider whose website serves as the primary distribution channel for one of the world&#8217;s most popular Linux distributions.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Multi-tier DDoS protection with always-on scrubbing capacity scaled to handle sustained attacks, implement geographic traffic distribution to prevent a single point of failure for critical download infrastructure.</p><p><strong>&#129002; THE GOVERNANCE TAKEAWAY: </strong>The transformation of hacktivism into extortion-as-a-service demonstrates that politically motivated attacks and financially motivated crime follow the same trajectory: if disruption works once, threat actors will monetize it. Organizations treating DDoS as a temporary nuisance rather than a business interruption are discovering that 12-hour outages affecting millions of users carry reputational costs that dwarf the expense of enterprise-grade DDoS mitigation.</p><h3>SUPPLY CHAIN: Your AI Tool Becomes Your Attack Vector</h3><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.ox.security/blog/vercel-context-ai-supply-chain-attack-breachforums/">Vercel</a>, a web development platform, was breached via Context AI in a supply chain attack that started when a Context AI employee downloaded game exploits containing Lumma Stealer malware. The initial compromise exposed Context AI&#8217;s Google Workspace credentials. A Vercel employee had installed Context AI&#8217;s Chrome extension, which granted the AI tool full read access to the employee&#8217;s Google Drive. Attackers used the compromised Context AI environment to pivot into the Vercel employee&#8217;s Google Workspace account, accessed unencrypted environment variables not marked as sensitive, enumerated those variables to expand access, and ultimately obtained a database access key. The Vercel database is now being sold for $2M on BreachForums. While Vercel stated customer systems remain secure, the breach demonstrates how third-party AI tools requesting broad permissions become lateral movement platforms when the vendor is compromised.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>Employee(s) installing third-party AI productivity tool with full Google Drive access, combined with storing environment variables in plaintext rather than encrypted secrets management, creating a chain where vendor compromise became an enterprise database breach.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Workflow approvals - Principle of Least Privilege (PoLP) for OAuth scopes - requiring security review before employees grant third-party applications access to corporate data, deploy secrets management requiring all environment variables to be encrypted at rest regardless of sensitivity classification.</p><p><strong>&#129002; THE GOVERNANCE TAKEAWAY: </strong>The Context AI breach proves that AI productivity tools marketed as frictionless integration are security risks the moment they request full data access and employees click approve without IT review. When a vendor&#8217;s employee downloading game exploits leads to your database being sold on BreachForums, the supply chain attack surface is no longer limited to code dependencies but extends to every browser extension and SaaS tool employees install without thinking twice.</p><h3>DEVELOPER TOOLS: Pipeline Is Someone&#8217;s Entry Point</h3><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.upguard.com/news/elementary-data-data-breach-2026-04-30">Elementary Data</a>, a data observability tools provider, was targeted in a software supply chain attack exploiting a script-injection vulnerability in the project&#8217;s GitHub Actions pipeline. Attackers forged a verified release commit, distributing a malicious version 0.23.3 of the elementary-data Python package on PyPI. The compromised package also poisoned Docker images on GitHub Container Registry. The malicious code activated immediately upon installation, targeting developer secrets including cloud access tokens, API keys, and cryptocurrency wallets. Users on version 0.23.4 or 0.23.2 remain unaffected, but the attack demonstrates how CI/CD automation creates attack surfaces where a single pipeline compromise can distribute malware to thousands of developers who trust package registries to verify integrity. Affected users face immediate risks: cloud environments could be accessed via stolen tokens, cryptocurrency wallets may be drained, and credentials can enable secondary breaches.</p><p><strong>&#129000; PROBABLE CAUSE: </strong>GitHub Actions workflow configured without script-injection protections, allowing attackers to manipulate the CI/CD pipeline to create verified-looking malicious releases that package registries accept as legitimate.</p><p><strong>&#129001; PROACTIVE PREVENTION: </strong>Input validation in GitHub Actions workflows prevents script injection, and deploy dependency pinning with Software Bill of Materials tracking for all third-party packages.</p><p><strong>&#129002; THE GOVERNANCE TAKEAWAY: </strong>When a GitHub Actions vulnerability lets attackers create verified-looking malicious releases that developers install via pip without suspecting compromise, the governance question is whether your organization treats CI/CD pipelines as critical infrastructure requiring the same security controls as production systems. Organizations assuming package registries verify integrity are learning that automation accelerates both deployment velocity and malware distribution at exactly the same speed.</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share Cybersecurity Chronicles&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share Cybersecurity Chronicles</span></a></p><h1>EXPERT PERSPECTIVE</h1><h2>RISK REDUCTION: CISA Says&#8230;.</h2><h3>Fold Agentic AI Into Your Existing Governance Framework - Assuming You Have One</h3><p>On May 1, 2026, <a href="https://www.cisa.gov/resources-tools/resources/careful-adoption-agentic-ai-services">CISA released joint guidance</a> co-authored by the NSA and cybersecurity agencies from Australia, Canada, New Zealand, and the United Kingdom - six national security authorities publishing coordinated direction on agentic AI simultaneously.</p><p>The guidance identifies five categories of risk that agentic AI introduces, outlines recommended controls, and delivers a central message that will be quoted in board presentations for the next twelve months: agentic AI does not require an entirely new security discipline. Organizations should fold these systems into the cybersecurity frameworks and governance structures they already maintain. That conclusion is correct for organizations with functioning governance frameworks. For the majority of organizations currently deploying agentic AI, it is the most dangerous sentence in the document.</p><h4>Highlights</h4><ol><li><p><strong>6 National Security Agencies Agree</strong>. When CISA, the NSA, and their Five Eyes counterparts publish coordinated guidance on a technology category, the signal to boards is not &#8220;here is a technical checklist for your security team.&#8221; It is &#8220;this technology has crossed the threshold where national security agencies consider its ungoverned deployment a systemic risk.&#8221;</p></li><li><p><strong>Risk Category Boards Cannot Delegate</strong>. Of the five risk categories the guidance identifies, four have technical mitigations that security teams can implement. The fifth - accountability - does not.</p></li><li><p><strong>Attack Vector Boards Have Never Heard Of</strong>. The guidance flags prompt injection ( where instructions embedded in data hijack an agent&#8217;s behavior) as a persistent and potentially unsolvable problem.</p></li><li><p><strong>Agentic Least Privilege Is Not the Sam</strong>e. The guidance recommends applying least-privilege principles to agentic AI systems, granting agents only the access they need for specific tasks. That recommendation is correct. It is also structurally more complex than least privilege for human users, because agents can operate across multiple systems simultaneously, at machine speed, without the contextual judgment that causes a human to pause before taking an irreversible action.</p></li><li><p><strong>Most Organizations Have No Foundation</strong>. The central recommendation, to fold agentic AI into existing cybersecurity frameworks, is architecturally sound. It is also premised on existing frameworks being functional, documented, continuously monitored, and capable of absorbing a new category of non-human actor.</p></li></ol><p>For organizations whose current governance posture consists of annual questionnaires, point-in-time assessments, and periodic board briefings, the guidance is not a roadmap. It is a description of the destination without a map to get there.</p><h4>Insight</h4><p>The CISA guidance is among the most consequential governance documents published in 2026. Its authorship alone, six national security agencies across five nations, communicates a level of urgency that no single vendor advisory or industry report can match. </p><blockquote><p><em><strong>Boards should read it, or receive a competent summary of it, before their next AI governance discussion.</strong></em></p></blockquote><p>The provocation is not with the guidance itself. It is with the premise.</p><p>When CISA tells organizations to fold agentic AI into their existing governance frameworks, it is giving proper advice to the organizations that already have functioning governance frameworks, documented risk registers, continuous control monitoring, real-time visibility into what their systems are doing, and audit trails that would survive a forensic investigation. For those organizations, the guidance is a useful checklist for extending established discipline to a new technology category.</p><p>For the organizations that do not have that foundation, and the Cowbell 2026 data suggests they represent the majority of the market, given that 31 percent of SMB claims were denied for insufficient evidence of controls that actually existed, the CISA guidance describes a best practice that cannot be executed because the prerequisite infrastructure is absent.</p><p>You cannot fold a new technology into a governance framework that is itself a collection of annual snapshots and self-attested questionnaire responses rather than near-real-time telemetry of your security posture embedded in established enterprise governance.</p><p>This matters because the accountability risk category the guidance identifies, decisions made through processes that are difficult to inspect, logs that are hard to parse, and audit trails that can be deleted by the agent itself, are precisely the risks that an inadequate governance foundation cannot address.</p><p>If your current governance posture cannot produce timestamped, continuous evidence proving your existing security controls were actually operating last Tuesday, it cannot produce that evidence for an agentic system making thousands of autonomous decisions per hour.</p><p>The organizations that will navigate agentic AI governance successfully are not those that read the CISA guidance and task their security teams with implementation. They are the ones whose boards ask the prior question: </p><ul><li><p>Do we have a governance infrastructure that is capable of absorbing this guidance? </p></li><li><p>Do we have continuous visibility into what our systems are doing? </p></li><li><p>Can we produce an audit trail for agent actions that would survive the scrutiny the guidance describes?</p></li></ul><p>If the answer to any of those questions is no, the CISA guidance is not a starting point. It is a description of where you need to arrive before agentic AI deployment becomes defensible.</p><p><em><strong>Six governments just told you that agentic AI governance is a national and business security priority. The question is, have you built the foundation that will make your compliance with that guidance possible? Can you prove it?</strong></em></p><div><hr></div><h1>Tired of getting what you paid for?</h1><h2>Let&#8217;s Fix What&#8217;s Broken</h2><ul><li><p><strong>Real-World Risk Assessment:</strong> Stop guessing where your vulnerabilities are. We&#8217;ll give you a clear, prioritized roadmap to fix what&#8217;s actually at risk, not just what a checklist says.</p></li><li><p><strong>A &#8220;No-Nonsense&#8221; Health Check:</strong> Kickstart your governance journey with a complimentary session to identify your biggest gaps. No fluff, just the facts.</p></li></ul><h2>Stay Ahead of the Curve</h2><ul><li><p><strong>Join the Conversation:</strong> Connect with our Cyber Risk Governance Community on LinkedIn. It&#8217;s where the best minds in the business share real insights, not just vendor pitches.</p></li><li><p><strong>Sit in on a Session:</strong> Attend our interactive LinkedIn Live events. We cut through the noise to discuss the real-world cyber risks that keep you up at night.</p></li></ul><h2>Get It Done.</h2><ol><li><p>Reach out to <a href="https://www.linkedin.com/article/edit/7370904157077037056/#">Netswitch Technology Management</a> today.</p></li><li><p><strong>Join Our <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> </strong>and connect with a dynamic network of professionals on LinkedIn. Exchange insights, transform risks into readiness, and stay ahead of evolving threats.</p></li><li><p><strong>Engage in Live Events:</strong> Attend interactive LinkedIn Live sessions. Dive into critical cyber risk topics with industry leaders from executive, technology, and governance backgrounds.</p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share&quot;,&quot;text&quot;:&quot;Share Cybersecurity Chronicles&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share Cybersecurity Chronicles</span></a></p><div><hr></div></li></ol><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Cyber Risk Governance Insights | April 27, 2026]]></title><description><![CDATA[Bridging the Server Room and the Board Room for Stronger Governance]]></description><link>https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-april-d96</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-april-d96</guid><pubDate>Mon, 27 Apr 2026 21:21:12 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<blockquote><p><em>This week we see three major breaches, two of them traced to the same third-party vendor, all of them exposing organizations that trusted their ecosystem without auditing it. Your vendors are your perimeter now. When did you last check the guest list?</em></p></blockquote><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h1>&#10024; QUICK WIN</h1><p>Ask your CIO or CISO for a written inventory, due by the end of this week, of every third-party vendor, current or former, holding active credentials or integration access to your data systems.</p><p>If they cannot produce it in five days, you have found your most urgent governance gap.</p><h1>Week in Brief</h1><h3>GOVERNMENT: Passport Data Stolen from French Agency</h3><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://techcrunch.com/2026/04/22/france-confirms-data-breach-at-government-agency-that-manages-citizens-ids/">France&#8217;s ANTS (Identity/Passport Agency)</a> confirmed a data breach detected on April 15. While the agency was investigating, a hacker advertised a database of 19 million records, including names, birthplaces, and contact info, on a dark web forum. The hacker&#8217;s public disclosure pre-empted the government&#8217;s notification process, forcing the agency into reactive damage control.</p><p><strong>&#129000; PROBABLE CAUSE:</strong> Insufficient access controls on the primary citizen identity database.</p><p><strong>&#129001; PROACTIVE PREVENTION:</strong> Implement phishing-resistant MFA and privileged access management (PAM); deploy monitoring for bulk data exports; and establish aggressive breach disclosure timelines to beat threat actor &#8220;PR&#8221; stunts.</p><p><strong>&#129002; THE GOVERNANCE TAKEAWAY:</strong> When an agency holds 19 million citizen records, it cannot operate with the security posture of a commercial database. Losing control of the breach narrative to a hacker converts a coordinated notification into a loss of public trust. Resource constraints are no excuse when the breach enables national-scale passport fraud.</p><h3>HEALTHCARE: 2 Weeks of Paper Charts and Delayed Care</h3><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.techtarget.com/healthtechsecurity/news/366641391/Cyberattack-continues-to-disrupt-operations-at-Signature-Healthcare">Signature Healthcare</a> has been under &#8220;downtime procedures&#8221; for two weeks following an April 6 attack. EHR systems remain offline, forcing manual charting, and ambulances are still diverted. The <strong>Anubis</strong> ransomware group claims to have 2TB of data and is using &#8220;wipe mode&#8221;, overwriting files rather than encrypting them, making data recovery impossible even if a ransom is paid.</p><p><strong>&#129000; PROBABLE CAUSE:</strong> Flat network architecture allowed ransomware to spread from an initial endpoint to the EHR, pharmacy, and lab systems simultaneously.</p><p><strong>&#129001; PROACTIVE PREVENTION:</strong> Implement micro-segmentation with separate authentication boundaries for clinical systems; maintain offline, immutable backups; and deploy EDR tuned to detect &#8220;wiper&#8221; file-overwrite patterns.</p><p><strong>&#129002; THE GOVERNANCE TAKEAWAY:</strong> Continuity planning that treats EHR downtime as a &#8220;temporary inconvenience&#8221; is a failure of imagination. Anubis proves that modern threats are pivoting from data kidnapping to data destruction. If your strategy assumes the attacker wants money and will preserve your data, your threat model is dangerously obsolete.</p><h3>RETAIL: Your Data Analytics Vendor is Your Data Breach</h3><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://cyberinsider.com/inditex-confirms-third-party-breach-as-hackers-threaten-zara-data-leak/">Inditex (Zara)</a> disclosed a breach via a &#8220;former&#8221; technology provider. While the company claims internal systems are safe, the ShinyHunters group claims they breached Zara&#8217;s BigQuery instances via the Anodot analytics platform. This highlights the &#8220;zombie access&#8221; risk where vendors retain data or connections long after a contract ends.</p><p><strong>&#129000; PROBABLE CAUSE:</strong> A third-party analytics provider maintained active access to cloud datasets despite the termination of the business relationship.</p><p><strong>&#129001; PROACTIVE PREVENTION:</strong> Mandate &#8220;Data Minimization&#8221; policies; automate alerts for abnormal queries in cloud storage; and strictly audit access revocation as part of the vendor offboarding process.</p><p><strong>&#129002; THE GOVERNANCE TAKEAWAY:</strong> A &#8220;former&#8221; vendor is only former if their access is dead and your data is deleted. Inditex&#8217;s breach indicates a failure in the vendor lifecycle, either access persisted, or data was left in a third-party environment without a destruction requirement. &#8220;Sunset&#8221; clauses are useless without audit verification.</p><h3>HOME SECURITY: One Year, Third Breach, Same Playbook</h3><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.bleepingcomputer.com/news/security/adt-confirms-data-breach-after-shinyhunters-leak-threat/">For the third time in a year, ADT</a> has disclosed a breach. ShinyHunters reportedly used a vishing (voice phishing) attack to compromise an employee&#8217;s Okta SSO account, granting access to 5.5 million customer email addresses in Salesforce. The group used the exact same &#8220;vishing-to-SSO&#8221; playbook seen in ADT&#8217;s previous 2024 incidents.</p><p><strong>&#129000; PROBABLE CAUSE:</strong> Reliance on SMS or TOTP-based MFA allowed a voice phishing attack to bypass SSO authentication.</p><p><strong>&#129001; PROACTIVE PREVENTION:</strong> Replace standard MFA with FIDO2 hardware keys (YubiKeys) or passkeys; implement &#8220;Continuous Authentication&#8221; to flag unusual SSO sessions; and deploy SaaS Security Posture Management (SSPM).</p><p><strong>&#129002; THE GOVERNANCE TAKEAWAY:</strong> Three breaches in twelve months using the identical attack pattern is a governance crisis. It suggests that previous &#8220;post-mortem&#8221; reviews failed to implement the one control, phishing-resistant MFA, that would have stopped the subsequent attacks. At this scale, SSO becomes a single point of failure that a single phone call can topple.</p><h3>UTILITIES: 112M Endpoints, One Compromised Network</h3><p><strong>&#128998; WHY IT MATTERS: </strong><a href="https://www.bleepingcomputer.com/news/security/american-utility-firm-itron-discloses-breach-of-internal-it-network/">Utility tech leader Itron</a>, which manages 112 million endpoints for global energy and water grids, detected an intruder in its internal IT network on April 13. While Itron states that customer-hosted and operational technology (OT) systems remain isolated, any breach of a vendor with this much &#8220;grid reach&#8221; triggers international supply chain anxiety.</p><p><strong>&#129000; PROBABLE CAUSE:</strong> A foothold in the corporate IT network was established, likely through a compromised employee credential.</p><p><strong>&#129001; PROACTIVE PREVENTION:</strong> Implement air-gapped separation between IT and OT; utilize one-way data diodes; and conduct regular penetration tests specifically designed to find &#8220;pivot paths&#8221; from corporate email to grid control systems.</p><p><strong>&#129002; THE GOVERNANCE TAKEAWAY:</strong> The unspoken question isn&#8217;t what was stolen, but how close the attacker got to the &#8220;switches.&#8221; Itron&#8217;s segmentation appears to have held, but the breach proves that corporate IT is the primary gateway to critical infrastructure. If you manage 112 million endpoints, your corporate email security is a matter of national security.</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-april-d96?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-april-d96?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><p></p><h1>EXPERT PERSPECTIVE</h1><h2>REPORT: What Your CISO Is Not Telling You</h2><p>The <a href="https://cowbell.insure">Cowbell 2026 Cyber Claims Report</a> lands at an uncomfortable moment: U.S. cyber insurance premiums declined for the first time to $9.14 billion while claims rose 40 percent. That gap is not a market correction. It is evidence that organizations are carrying more unpriced risk than their coverage reflects.</p><ol><li><p><strong>Ransomware Is Not Your Biggest Claims Driver. </strong>Ransomware and extortion account for only 18.3%. Boards anchored to ransomware as the primary threat are leaving their actual exposure unmanaged.</p></li><li><p><strong>Lower Ransom Payments Do Not Mean Lower Losses. </strong>Average ransom payments dropped 44 percent. But double extortion, pay to suppress the data, not just to decrypt, is accelerating. The financial exposure has not improved.</p></li><li><p><strong>7 Groups Own the Landscape. </strong>Of identified ransomware incidents, Akira (38.8%) and Qilin (14.2%), represent more than half of the identified attacks.</p></li><li><p><strong>Human Error Is Still the Entry Point. </strong>95 % of breaches involve human error. Threat actors are using AI to make vishing, phishing, and social engineering attacks more convincing at scale.</p></li><li><p><strong>Next Boardroom Shock. </strong>Litigation of third-party claims and class actions is projected to increase, targeting organizations for inadequate security controls and delayed breach disclosure.</p></li></ol><h3>INSIGHT</h3><p>Most organizations continue to treat a cyber policy as a risk transfer mechanism, pay the premium, assume the exposure is covered, and move on. The Cowbell data dismantles that assumption.</p><p>When premiums fall while claims rise 40 percent, the market is not signaling safety. It is adjusting pricing while loss activity worsens. </p><p>The more pressing concern for organizations is the shift from encryption-based extortion to data suppression demands. It&#8217;s now forever blackmail.</p><p>Organizations that invested in backup infrastructure celebrated lower ransom payments without recognizing that attackers changed what they were selling. The threat is no longer primarily operational disruption. </p><p>It is the permanent liability of data already out the door, and that is a board-level conversation most audit committees are not yet equipped to have.</p><h2><br>Is GC Replacing the CFO as the CEO&#8217;s Trusted Advisor</h2><p>In a recent <em><strong><a href="https://youtu.be/j8QLwlk_ofY?si=-wIJ7ZvLFjRxXrha">Cyber Risk Governance Live</a></strong></em>, the panel brought together executive legal counsel Krishan Thacker and CFO and board advisor Donald Laughlin to examine a structural shift in how C-suite roles are converging around governance, liability, and enterprise value protection. The catalyst was recent profession pundits arguing that General Counsel is becoming the new CFO, a provocative headline that the panelists correctly reframed: the GC is not replacing the CFO.</p><p>They are undergoing the same strategic evolution that the CFO completed over the last decade. And the governance implication of that convergence, particularly when the CISO joins the same table with the same data, is the architecture that makes cyber defensibility possible.</p><h3>Highlights</h3><p><strong>1. Underutilized Risk Asset.</strong> General Counsel offices contain the complete record of every commercial relationship, vendor obligation, and liability assumption an organization has ever made. AI is making that data legible at scale. The GC who learns to translate it into financial metrics becomes a strategic function. The one who does not becomes a compliance cost center, and leaves the board operating without a complete picture of its contractual exposure.</p><p><strong>2. CFO Evolution Timeline Is Compressed.</strong> The CFO spent the last decade expanding from financial scorekeeper to strategic advisor. The GC role is undergoing the same evolution now, from reactive risk manager to proactive financial strategist. The difference is that the regulatory and litigation environment in 2026 is compressing the timeline.</p><p><strong>3. GC-CFO-CISO Triad Closes the Gap.</strong> The governance failure is not the absence of legal expertise, financial discipline, or security capability in isolation. It is the absence of all three operating from the same verified data simultaneously. When the GC sees a breach of contract at the same moment the CFO sees the MPL shift and the CISO sees the control failure, the guesswork stops. The gap between those three perspectives, separate data, separate timelines, separate vocabularies, is where liability accumulates.</p><p><strong>4. &#8220;We Didn&#8217;t Know&#8221; Is Not a Defense.</strong> In 2026, cyber inaction is being treated by courts and regulators as negligence by omission. Insurance policies are being rescinded on material misrepresentation grounds. M&amp;A transactions are collapsing over undisclosed vulnerabilities. The 48-hour window between breach detection and legal counsel notification is the difference between a defensible incident and a litigation outcome where the organization&#8217;s own communications become opposing counsel&#8217;s best evidence.</p><h3>Insight</h3><p>The exchange between Thacker and Laughlin cuts to the structural problem most boards are not yet framing correctly. The question is not whether the General Counsel should replace the CFO. The question is whether the legal, financial, and security functions are operating from the same picture of organizational risk, and whether that picture is current.</p><p>Thacker&#8217;s observation about Maximum Probable Loss is the clearest articulation of where the failure lives. An MPL calculated once a year and treated as accurate for twelve months is not a risk management tool. It is a snapshot that will be reviewed in discovery after a breach, measured against a risk reality the organization knew was changing and chose not to track.</p><p>Laughlin&#8217;s framing of the CFO evolution provides the roadmap. The CFO did not become a strategic advisor by acquiring legal or technical expertise. The CFO became indispensable by learning to translate financial data into decisions. The GC who learns to do the same with contractual and liability data, and the CISO who does the same with governance and control data &#8212; gives the board something it currently lacks: a unified, real-time picture of enterprise risk that all three functions are accountable for defending.</p><p>The gap is not a technology problem. The data exists. The frameworks exist. The regulatory requirements that make defensible evidence a legal obligation already exist. The gap is cultural and structural. The organizations that close it before the next inquiry will be the ones whose boards can answer the question courts are already asking: not whether a governance program existed, but whether anyone could prove it was real.</p><div><hr></div><h1>Tired of getting what you paid for?</h1><h2>Let&#8217;s Fix What&#8217;s Broken</h2><ul><li><p><strong>Real-World Risk Assessment:</strong> Stop guessing where your vulnerabilities are. We&#8217;ll give you a clear, prioritized roadmap to fix what&#8217;s actually at risk, not just what a checklist says.</p></li><li><p><strong>A &#8220;No-Nonsense&#8221; Health Check:</strong> Kickstart your governance journey with a complimentary session to identify your biggest gaps. No fluff, just the facts.</p></li></ul><h2>Stay Ahead of the Curve</h2><ul><li><p><strong>Join the Conversation:</strong> Connect with our Cyber Risk Governance Community on LinkedIn. It&#8217;s where the best minds in the business share real insights, not just vendor pitches.</p></li><li><p><strong>Sit in on a Session:</strong> Attend our interactive LinkedIn Live events. We cut through the noise to discuss the real-world cyber risks that keep you up at night.</p></li></ul><h2>Get It Done.</h2><ol><li><p>Reach out to <a href="https://www.linkedin.com/article/edit/7370904157077037056/#">Netswitch Technology Management</a> today.</p></li><li><p><strong>Join Our <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> </strong>and connect with a dynamic network of professionals on LinkedIn. Exchange insights, transform risks into readiness, and stay ahead of evolving threats.</p></li><li><p><strong>Engage in Live Events:</strong> Attend interactive LinkedIn Live sessions. Dive into critical cyber risk topics with industry leaders from executive, technology, and governance backgrounds.</p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share&quot;,&quot;text&quot;:&quot;Share Cybersecurity Chronicles&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share Cybersecurity Chronicles</span></a></p><div><hr></div></li></ol><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item><item><title><![CDATA[Cyber Risk Governance Insights | April 20, 2026]]></title><description><![CDATA[Where cybersecurity incidents become board-level accountability decisions]]></description><link>https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-april</link><guid isPermaLink="false">https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-april</guid><dc:creator><![CDATA[Cybersecurity Chronicles]]></dc:creator><pubDate>Mon, 20 Apr 2026 20:28:31 GMT</pubDate><enclosure url="https://substackcdn.com/image/fetch/$s_!wrhH!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3679c2c6-641f-42ca-9195-d5411d2ec4ae_720x720.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<blockquote><p><em><strong>This week&#8217;s incidents highlight a recurring theme: even sophisticated organizations continue to bleed from preventable gaps in oversight, third-party risk, and the uncontrolled rush toward AI.</strong></em></p></blockquote><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/subscribe?&quot;,&quot;text&quot;:&quot;Subscribe now&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/subscribe"><span>Subscribe now</span></a></p><h1><strong>Week in Brief</strong></h1><h3>TECHNOLOGY: Rising Security Concerns Amid AI Adoption</h3><p><strong>&#128998; WHY IT MATTERS:</strong> A <a href="https://www.cybersecuritydive.com/news/AI-security-concerns-CIO-logicalis/817705">global survey</a> of over 1,000 CIOs reveals that more than a quarter now rank AI as a top-tier risk alongside ransomware and phishing. With only 37% of organizations having visibility into AI tools in use and 57% citing employee misuse as a major threat, security teams are already stretched thin by skills shortages and slower incident response.</p><p><strong>&#129000; PROBABLE CAUSE:</strong> Shadow AI and app sprawl outpacing governance structures.</p><p><strong>&#129001; PROACTIVE PREVENTION:</strong> A formal AI usage inventory and approval process across the enterprise. Assign clear ownership to a cross-functional AI risk committee (not just IT).</p><p><strong>&#129002; THE GOVERNANCE TAKEAWAY:</strong> Treating AI as &#8220;someone else&#8217;s problem&#8221; is a board-level failure in strategic risk oversight. If you wouldn&#8217;t let departments freely adopt new financial systems without controls, you cannot afford to do so with AI.</p><h3>ENTERTAINMENT: Data Breach Hits Popular Game Maker</h3><p><strong>&#128998; WHY IT MATTERS:</strong> Hackers compromised a third-party analytics platform (Anadot) connected to <a href="https://www.cpomagazine.com/cyber-security/data-breach-hits-gta-v-and-red-dead-redemption-2-maker-rockstar-games/">Rockstar&#8217;s</a> Snowflake instance, exfiltrating over 78 million records, including contracts, financial documents, marketing plans, and player support data. ShinyHunters published samples and demanded ransom.</p><p><strong>&#129000; PROBABLE CAUSE:</strong> Inadequate identity and access controls over third-party SaaS integrations.</p><p><strong>&#129001; PROACTIVE PREVENTION:</strong> A full third-party SaaS inventory and enforce strict least-privilege access with regular token rotation and monitoring with a verification audit. Vendors handling sensitive analytics or cloud data should provide evidence of their own breach detection capabilities and incident response SLAs.</p><p><strong>&#129002; THE GOVERNANCE TAKEAWAY:</strong> Outsourcing data doesn&#8217;t outsource risk. Boards that approve cloud and SaaS strategies without demanding rigorous vendor oversight are making a conscious business decision to accept elevated breach probability.</p><h3>HEALTHCARE: Ransomware Attack on Solutions Provider Impacts Hospitals</h3><p><strong>&#128998; WHY IT MATTERS:</strong> A ransomware incident at ChipSoft, whose <a href="https://www.cpomagazine.com/cyber-security/ransomware-attack-on-healthcare-it-solutions-provider-impacts-dutch-hospitals/">EHR systems</a> serve over 80% of Dutch hospitals, forced multiple facilities to disconnect systems and shift to manual processes, disrupting care delivery across roughly 11 hospitals.</p><p><strong>&#129000; PROBABLE CAUSE:</strong> Compromise of a critical healthcare supply-chain vendor.</p><p><strong>&#129001; PROACTIVE PREVENTION:</strong> Mapping all critical third-party dependencies (especially clinical software and IT providers) and requiring them to meet the same cybersecurity standards you impose internally. Include contractual rights to audit, mandatory incident notification within 24 hours, and joint tabletop exercises.</p><p><strong>&#129002; THE GOVERNANCE TAKEAWAY:</strong> In healthcare, vendor risk is patient safety risk. Failing to hold critical suppliers to rigorous standards is not delegation, it&#8217;s abdication of the board&#8217;s duty to protect core operations.</p><h3>SOFTWARE: PaaS Ai Data Leak</h3><p><strong>&#128998; WHY IT MATTERS:</strong> Vercel&#8217;s CEO confirmed an internal <a href="https://vercel.com/kb/bulletin/vercel-april-2026-security-incident">breach linked to an AI tool</a>, with hackers claiming to sell stolen data for $2 million. The incident underscores how internal adoption of AI can create unexpected exposure pathways.</p><p><strong>&#129000; PROBABLE CAUSE:</strong> Insufficient controls and monitoring around experimental or shadow AI tool usage.</p><p><strong>&#129001; PROACTIVE PREVENTION:</strong> DLP, API monitoring, and data classification implemented on all sanctioned and unsanctioned AI tools, paired with a clear policy that prohibits connecting internal systems or sensitive data to unvetted AI services without security review.</p><p><strong>&#129002; THE GOVERNANCE TAKEAWAY:</strong> Speed-to-innovation cannot come at the expense of basic containment. When executives allow &#8220;move fast&#8221; culture to bypass risk review, they are effectively betting the company's data on unproven tools.</p><h3>LEGAL: Cybersecurity Basics Matter for Law Firms</h3><p><strong>&#128998; WHY IT MATTERS:</strong> Even highly sophisticated <a href="https://www.reuters.com/legal/legalindustry/cybersecurity-basics-are-important-sophisticated-lawyers-firms-too-everyone-else--pracin-2026-04-16/">law firms routinely neglect basic cybersecurity hygiene</a>, forgotten domains, unsecured devices, and unassigned responsibilities, leading to preventable operational disruptions and client risk.</p><p><strong>&#129000; PROBABLE CAUSE:</strong> The dangerous assumption that &#8220;if it&#8217;s basic, we must already be doing it,&#8221; combined with viewing cybersecurity as non-revenue work best left to IT providers.</p><p><strong>&#129001; PROACTIVE PREVENTION:</strong> Every partner and senior leader should, on a regular cadence, complete a 15-minute cyber hygiene checklist covering domain ownership, MFA enforcement, device encryption, and asset inventory. Make one executive personally accountable for sign-off.</p><p><strong>&#129002; THE GOVERNANCE TAKEAWAY:</strong> When highly educated and sophisticated professionals dismiss fundamentals as &#8220;below their pay grade,&#8221; it reveals a deeper security and privacy cultural failure in accountability. Boards should treat basic cyber hygiene as table stakes, not optional overhead.</p><h1>&#10024; QUICK WIN</h1><p>Ask your CIO for a current third-party SaaS inventory focused on any AI/analytics tools, plus evidence of access controls and incident notification SLAs. Review it in your next executive meeting.</p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-april?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/p/cyber-risk-governance-insights-april?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share</span></a></p><p></p><h1>EXPERT PERSPECTIVE</h1><h2>Anthropic&#8217;s Gamble - Governance Theater or Necessary Bet?</h2><p>Anthropic&#8217;s <a href="https://mashable.com/article/claude-mythos-preview-project-glasswing-pr-stunt-cybersecurity-experts">Project Glasswing and Claude Mythos Preview</a> have sparked a sharp divide in the cybersecurity community, positioned by <a href="https://www.forrester.com/blogs/project-glasswing-the-10-consequences-nobodys-writing-about-yet/">Forrester</a> as a &#8220;stark fact&#8221; that autonomous zero-day discovery has reached a scale that will fundamentally break the traditional vulnerability management playbook.</p><p>While Forrester warns of immediate structural shifts, including the potential collapse of the CVE system, a nation-state pivot from &#8220;hoarding&#8221; to &#8220;racing&#8221; to use zero-days, and a career-defining move from finding bugs to the high-stakes judgment of AI-generated remediation, other experts have characterized the rollout as &#8220;brilliant corporate theater.&#8221;</p><p>Skeptics argue that the industry already lacks a &#8220;finding&#8221; problem and is instead drowning in tools, suggesting that Anthropic&#8217;s decision to label the model &#8220;too dangerous to release&#8221; is a marketing flex designed to build investor mystique while ignoring the real-world bottleneck: the human capacity to validate and coordinate patches across production environments at machine speed.</p><h2>PERSPECTIVE</h2><p>Anthropic&#8217;s recent release of Mythos (via restricted Project Glasswing) and its standoff with the DoD over Claude usage expose a core tension: powerful AI can now autonomously discover and chain zero-days at a scale that dwarfs human experts. Anthropic positioned this as responsible defense, limiting access to an elite consortium (Amazon, Apple, Microsoft, etc.) to harden critical software before adversaries weaponize it.</p><p>Here&#8217;s the unspoken truth most coverage misses: this &#8220;controlled release&#8221; is less principled governance than a high-stakes corporate bet with fragile assumptions. Dual-use capabilities don&#8217;t vanish because one company restricts them; they proliferate. Nation-states and well-resourced actors will replicate or steal equivalents regardless of Anthropic&#8217;s consortium. Meanwhile, the real asymmetry widens, big players in Glasswing gain defensive edges while SMBs face agentic attacks that never sleep, chain exploits relentlessly, and scan at industrial scale. &#8220;Too small to target&#8221; is dead.</p><p>Forrester highlights under-discussed fallout: remediation (not discovery) becomes the bottleneck, cyber insurance will reprice sharply, the CVE system strains, and boards must now stress-test for AI-driven overnight exploits. Skeptics call parts of the rollout PR theater, overhyped claims with vague validation, yet the underlying shift is real.</p><p>The deeper governance failure? Relying on any single vendor&#8217;s &#8220;responsible disclosure doctrine&#8221; for existential capabilities. Boards should stop treating this as an IT or safety issue and reframe it as operational continuity risk: assume agentic probing is constant, fund remediation capacity now, and demand verifiable AI governance that scales beyond elite consortia. The window for hoping technology self-regulates is closing.</p><h2>CRG Live: The $1.9M Gap Between Board &amp; Server Room</h2><p>The era of &#8220;plausible deniability&#8221; for the C-suite is officially over.</p><p>In our upcoming feature, we&#8217;re diving into a critical shift in the cyber landscape: the transition from technical cybersecurity to <strong>legal defensibility</strong>.</p><p>Learn why defensibility is the new ROI.</p><p>On Wednesday, April 22, an elite panel of legal, financial, and security experts will dismantle the &#8220;Governance Gap&#8221;, the space between the server room and the boardroom where $350M acquisition deals die and personal executive liability begins.</p><h4><strong>Why This Session is Mandatory for 2026</strong></h4><p>We&#8217;ve moved past the point where delegating cyber risk to the IT department acts as a legal shield. Today, boards and executives carry the weight of individual liability. If you can&#8217;t prove <strong>reasonable care</strong> through an auditable trail, regulators and courts are increasingly viewing &#8220;budget constraints&#8221; not as a reality of business, but as <strong>gross negligence by omission</strong>.</p><h4><strong>Key Aspects to be Explored:</strong></h4><p><strong>The Rescinded Policy Trap:</strong> Why insurers are walking away from claims before they&#8217;re even filed and what &#8220;material misrepresentation&#8221; looks like in 2026.</p><p><strong>The 48-Hour Critical Window:</strong> How a delay in notifying legal counsel after a breach detection can turn your own forensic evidence into ammunition for plaintiffs.</p><p><strong>The CFO&#8217;s Conflict:</strong> Breaking the structural incentive where cost-cutting leads to catastrophic risk exposure.</p><p><strong>M&amp;A Value Destruction:</strong> How undisclosed vulnerabilities are triggering massive clawback provisions and devaluing enterprises overnight.</p><h4><strong>Meet the Panel</strong></h4><p>This conversation brings together the two sides of the governance coin:</p><p><strong><a href="https://www.linkedin.com/in/krishanthakker/">Krishan Thakker, Esq. (Meta/Axiom):</a></strong> A global compliance strategist who understands exactly what the &#8220;Left of Boom&#8221; strategy looks like from a regulatory and litigation standpoint.</p><p><strong><a href="https://www.linkedin.com/in/donaldlaughlin/">Donald Laughlin (CFO/Board Member)</a>:</strong> A veteran financial executive who provides the blueprint for reframing compliance as enterprise value protection rather than a cost center.</p><p><strong>Moderated by:</strong> <a href="https://www.linkedin.com/in/netswitchstanleyli/">Stanley Li</a> and <a href="https://www.linkedin.com/in/mahoneysean/">Sean Mahoney, CISM</a>, the architects behind the <strong>Unity Risk Indicator</strong> framework.</p><p><strong>Event Details</strong></p><p><strong>Date:</strong> Wednesday, April 22, 2026</p><p><strong>Time:</strong> 1:00 PM &#8211; 2:30 PM (Eastern) / 10:00 AM (Pacific)</p><p><strong>Format:</strong> Live Virtual Panel + Q&amp;A</p><p><strong>Stop spending more and start governing better.</strong> Learn how to build a defensible record that satisfies insurers, acquirers, and regulators alike.</p><p><a href="https://www.linkedin.com/events/defensibilityisthe-1-9mgovernan7443462645774622720/theater/">[</a><strong><a href="https://www.linkedin.com/events/defensibilityisthe-1-9mgovernan7443462645774622720/theater/">Register for the Event Here</a></strong><a href="https://www.linkedin.com/events/defensibilityisthe-1-9mgovernan7443462645774622720/theater/">]</a></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/?utm_source=substack&utm_medium=email&utm_content=share&action=share&quot;,&quot;text&quot;:&quot;Share Cybersecurity Chronicles&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share Cybersecurity Chronicles</span></a></p><div><hr></div><h1>Tired of getting what you paid for?</h1><h2>Let&#8217;s Fix What&#8217;s Broken</h2><ul><li><p><strong>Real-World Risk Assessment:</strong> Stop guessing where your vulnerabilities are. We&#8217;ll give you a clear, prioritized roadmap to fix what&#8217;s actually at risk, not just what a checklist says.</p></li><li><p><strong>A &#8220;No-Nonsense&#8221; Health Check:</strong> Kickstart your governance journey with a complimentary session to identify your biggest gaps. No fluff, just the facts.</p></li></ul><h2>Stay Ahead of the Curve</h2><ul><li><p><strong>Join the Conversation:</strong> Connect with our Cyber Risk Governance Community on LinkedIn. It&#8217;s where the best minds in the business share real insights, not just vendor pitches.</p></li><li><p><strong>Sit in on a Session:</strong> Attend our interactive LinkedIn Live events. We cut through the noise to discuss the real-world cyber risks that keep you up at night.</p></li></ul><h2>Get It Done.</h2><ol><li><p>Reach out to <a href="https://www.linkedin.com/article/edit/7370904157077037056/#">Netswitch Technology Management</a> today.</p></li><li><p><strong>Join Our <a href="https://www.linkedin.com/groups/13991569/">Cyber Risk Governance Community</a> </strong>and connect with a dynamic network of professionals on LinkedIn. Exchange insights, transform risks into readiness, and stay ahead of evolving threats.</p></li><li><p><strong>Engage in Live Events:</strong> Attend interactive LinkedIn Live sessions. Dive into critical cyber risk topics with industry leaders from executive, technology, and governance backgrounds.</p><p></p><p class="button-wrapper" data-attrs="{&quot;url&quot;:&quot;https://cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share&quot;,&quot;text&quot;:&quot;Share Cybersecurity Chronicles&quot;,&quot;action&quot;:null,&quot;class&quot;:null}" data-component-name="ButtonCreateButton"><a class="button primary" href="/__u/cybersecuritychronicles.substack.com/?utm_source=substack&amp;utm_medium=email&amp;utm_content=share&amp;action=share"><span>Share Cybersecurity Chronicles</span></a></p><div><hr></div></li></ol><p><strong>DISCLAIMER</strong>: <em>The information, analysis, and links provided in this newsletter are for informational and editorial purposes only and represent the opinions of the authors. Cybersecurity Chronicles and Netswitch, Inc. make no representations as to the accuracy or completeness of any information herein and accept no liability for any damages arising from its use. Nothing in this newsletter constitutes legal, regulatory, or professional advice.</em></p>]]></content:encoded></item></channel></rss>