darkreading.com
Robert Lemos, Contributing Writer
August 22, 2025
Some insurers look to limit payouts to companies that don't remediate serious vulnerabilities in a timely manner. Unsurprisingly, most companies don't like those restrictions.
Cyber insurers are testing out new ways to hold policyholders accountable for outdated security, limiting payouts when policyholders fall prey to attacks that use older vulnerabilities or take advantage of holes in the organizations' defenses.
Potential risk-limiting approaches include a sliding scale of accountability — and payouts — based on an unpatched vulnerability's half-life, or whether a company failed to fix a critical vulnerability within a certain number of days, according to a blog post penned by cyber insurer Coalition, which does not support such approaches. Dubbed CVE exclusions, after the Common Vulnerabilities and Exposures (CVE) system widely used to assign identifiers to software security issues, the tactic is not yet widely adopted, and most examples are from insurers outside the US, the firm stated.
The limits could start showing up in companies' policies, however, if demand for cyber insurance continues to grow, creating a seller's market, says John Coletti, head of cyber underwriting at Coalition
"While we will not name names, there are specific examples of this occurring within the industry," he says. "A company should be highly skeptical of buying a policy with a CVE exclusion."
Cyber-insurance firms are struggling to find different ways to limit their vulnerability to large breaches and campaigns that hit a large number of policyholders. Following NotPetya, when companies used business insurance to cover disruptions to operations, efforts to deny payouts based on warlike-act exclusion clauses largely failed but led to enhanced wording in subsequent policies. Increasingly, cyber-insurance firms used data from policyholders or gleaned from cybersecurity assessments, or information from their own managed security services offerings to better determine risk.
Blame the Victim?
Yet requiring all companies to manage major vulnerabilities is a tall order. Currently, the software industry is on track to disclose more than 46,000 vulnerabilities in 2025, up from nearly 40,000 in 2024, according to the National Vulnerability Database (NVD). Of those, likely 30% would be considered of high or critical severity, typically defined as a Common Vulnerability Scoring System (CVSS) score of 8.0 or higher.
cyberscoop.com
article By
Tim Starks
August 27, 2025
Google says it is starting a cyber “disruption unit,” a development that arrives in a potentially shifting U.S. landscape toward more offensive-oriented approaches in cyberspace.
But the contours of that larger shift are still unclear, and whether or to what extent it’s even possible. While there’s some momentum in policymaking and industry circles to put a greater emphasis on more aggressive strategies and tactics to respond to cyberattacks, there are also major barriers.
Sandra Joyce, vice president of Google Threat Intelligence Group, said at a conference Tuesday that more details of the disruption unit would be forthcoming in future months, but the company was looking for “legal and ethical disruption” options as part of the unit’s work.
“What we’re doing in the Google Threat Intelligence Group is intelligence-led proactive identification of opportunities where we can actually take down some type of campaign or operation,” she said at the Center for Cybersecurity Policy and Law event, where she called for partners in the project. “We have to get from a reactive position to a proactive one … if we’re going to make a difference right now.”
The boundaries in the cyber domain between actions considered “cyber offense” and those meant to deter cyberattacks are often unclear. The tradeoff between “active defense” vs. “hacking back” is a common dividing line. On the less aggressive end, “active defense” can include tactics like setting up honeypots designed to lure and trick attackers. At the more extreme end, “hacking back” would typically involve actions that attempt to deliberately destroy an attacker’s systems or networks. Disruption operations might fall between the two, like Microsoft taking down botnet infrastructure in court or the Justice Department seizing stolen cryptocurrency from hackers.
Trump administration officials and some in Congress have been advocating for the U.S. government to go on offense in cyberspace, saying that foreign hackers and criminals aren’t suffering sufficient consequences. Much-criticized legislation to authorize private sector “hacking back” has long stalled in Congress, but some have recently pushed a version of the idea where the president would give “letters of marque” like those for early-U.S. sea privateers to companies authorizing them to legally conduct offensive cyber operations currently forbidden under U.S. law.
The private sector has some catching up to do if there’s to be a worthy field of firms able to focus on offense, experts say.
John Keefe, a former National Security Council official from 2022 to 2024 and National Security Agency official before that, said there had been government talks about a “narrow” letters of marque approach “with the private sector companies that we thought had the capabilities.” The concept was centered on ransomware, Russia and rules of the road for those companies to operate. “It wasn’t going to be the Wild West,” said Keefe, now founder of Ex Astris Scientia, speaking like others in this story at Tuesday’s conference.
The companies with an emphasis on offense largely have only one customer — and that’s governments, said Joe McCaffrey, chief information security officer at defense tech company Anduril Industries. “It’s a really tough business to be in,” he said. “If you develop an exploit, you get to sell to one person legally, and then it gets burned, and you’re back again.”
By their nature, offensive cyber operations in the federal government are already very time- and manpower-intensive, said Brandon Wales, a former top official at the Cybersecurity and Infrastructure Security Agency and now vice president of cybersecurity at SentinelOne. Private sector companies could make their mark by innovating ways to speed up and expand the number of those operations, he said.
Overall, among the options of companies that could do more offensive work, the “industry doesn’t exist yet, but I think it’s coming,” said Andrew McClure, managing director at Forgepoint Capital.
Certainly Congress would have to clarify what companies are able to do legally as well, Wales said.
But that’s just the industry side. There’s plenty more to weigh when stepping up offense.
“However we start, we need to make sure that we are having the ability to measure impact,” said Megan Stifel, chief strategy officer for the Institute for Security and Technology. “Is this working? How do we know?”
If there was a consensus at the conference it’s that the United States — be it the government or private sector — needs to do more to deter adversaries in cyberspace by going after them more in cyberspace.
One knock on that idea has been that the United States can least afford to get into a cyber shooting match, since it’s more reliant on tech than other nations and an escalation would hurt the U.S. the most by presenting more vulnerable targets for enemies. But Dmitri Alperovitch, chairman of the Silverado Policy Accelerator, said that idea was wrong for a couple reasons, among them that other nations have become just as reliant on tech, too.
And “the very idea that in this current bleak state of affairs, engaging in cyber offense is escalatory, I propose to you, is laughable,” he said. “After all, what are our adversaries going to escalate to in response? Ransom more of our hospitals, penetrate more of our water and electric utilities, steal even more of our IP and financial assets?”
Alperovitch continued: “Not only is engaging in thoughtful and careful cyber offense not escalatory, but not doing so is.”
news.sophos.com Written by Sophos Counter Threat Unit Research Team
August 26, 2025
This approach represents an evolution from threat actors abusing remote monitoring and management tools
In August 2025, Counter Threat Unit™ (CTU) researchers investigated an intrusion that involved deployment of the legitimate open-source Velociraptor digital forensics and incident response (DFIR) tool. In this incident, the threat actor used the tool to download and execute Visual Studio Code with the likely intention of creating a tunnel to an attacker-controlled command and control (C2) server. Enabling the tunnel option in Visual Studio Code triggered a Taegis™ alert, as this option can allow both remote access and remote code execution and has been abused by multiple threat groups in the past.
The threat actor used the Windows msiexec utility to download an installer (v2.msi) from a Cloudflare Workers domain (files[.]qaubctgg[.]workers[.]dev). This location appears to be a staging folder for attacker tools, including the Cloudflare tunneling tool and the Radmin remote administration tool. This file installed Velociraptor, which is configured to communicate with C2 server velo[.]qaubctgg[.]workers[.]dev. The attacker then used an encoded PowerShell command to download Visual Studio Code (code.exe) from the same staging folder and executed it with the tunnel option enabled. The threat actor installed code.exe as a service and redirected the output to a log file. They then used the msiexec Windows utility again to download additional malware (sc.msi) from the workers[.]dev folder (see Figure 1).
Velociraptor creating Visual Studio Code tunnel
Figure 1: Process tree showing Velociraptor creating Visual Studio Code tunnel.
The Visual Studio Code tunneling activity triggered a Taegis alert that prompted a Sophos investigation. The analysts provided mitigation advice that enabled the customer to quickly implement remediations such as isolating the affected host, which prevented the attacker from achieving their objectives. Analysis suggests that the malicious activity would likely have led to ransomware deployment.
Threat actors often abuse remote monitoring and management (RMM) tools. In some instances, they leverage preexisting tools on the targeted systems. In others, they deploy the tools during the attack. The Velociraptor incident reveals attackers pivoting to using incident response tools to gain a foothold in a network and minimize the amount of malware they deploy.
Organizations should monitor for and investigate unauthorized use of Velociraptor and treat observations of this tradecraft as a precursor to ransomware. Implementing an endpoint detection and response system, monitoring for unexpected tools and suspicious behaviors, and following best practices for securing systems and generating backups can mitigate the ransomware threat. The impact of an attack is greatly reduced if it is caught prior to ransomware deployment.
The following Sophos protections detect activity related to this threat:
Troj/Agent-BLMR
Troj/BatDl-PL
Troj/Mdrop-KDK
To mitigate exposure to this malware, CTU™ researchers recommend that organizations use available controls to review and restrict access using the indicators listed in Table 1. The domains may contain malicious content, so consider the risks before opening them in a browser.
Indicator Type Context
files[.]qaubctgg[.]workers[.]dev Domain name Hosted tools used in August 2025 Velociraptor campaign
velo[.]qaubctgg[.]workers[.]dev Domain name C2 server used in August 2025 Velociraptor campaign
Table 1: Indicators for this threat.
openssh.com - OpenSSH supports a number of cryptographic key agreement algorithms considered to be safe against attacks from quantum computers. We recommend that all SSH connections use these algorithms.
OpenSSH has offered post-quantum key agreement (KexAlgorithms) by default since release 9.0 (April 2022), initially via the sntrup761x25519-sha512 algorithm. More recently, in OpenSSH 9.9, we have added a second post-quantum key agreement mlkem768x25519-sha256 and it was made the new default scheme in OpenSSH 10.0 (April 2025).
To encourage migration to these stronger algorithms, OpenSSH 10.1 will warn the user when a non post-quantum key agreement scheme is selected, with the following message:
WARNING: connection is not using a post-quantum key exchange algorithm.
This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
This warning is displayed by default but may be disabled via the WarnWeakCrypto option in ssh_config(5).
Background
A quantum computer (QC) is a device capable of performing computations with information encoded as quantum states. Such a device could quickly solve particular problems that are intractable for existing "classical" computers.
The mathematics that underpin a number of cryptographic algorithms are among the problems that quantum computers are believed to be able to effectively solve. This means that a sufficiently-powerful quantum computer (a.k.a a "cryptographically-relevant" quantum computer) will be able to break them. Most affected is the cryptography used for key agreement and digital signatures, both of which play important roles in SSH.
Fortunately, quantum computers of sufficient power to break cryptography have not been invented yet. Estimates for when a cryptographically-relevant quantum computer will arrive, based on the rate of progress in the field, range from 5-20 years, with many observers expecting them to arrive in the mid-2030s.
The entire privacy of an SSH connection depends on cryptographic key agreement. If an attacker can break the key agreement then they are able to decrypt and view the entire session. The attacker need not perform this attack in real time; they may collect encrypted SSH sessions now and then decrypt them later once they have access to a quantum computer. This is referred to as a "store now, decrypt later" attack (also as "harvest now, decrypt later").
Fortunately, improved "post-quantum" cryptographic algorithms have been devised that rely on different underlying mathematical problems that are understood to not be attackable by a quantum computer.
OpenSSH has supported post-quantum key agreement to prevent "store now, decrypt later" attacks for several years and it has been the default since OpenSSH-9.0, released in 2022.
FAQ
I received a warning from ssh that directed me to this page. What should I do?
As mentioned above, OpenSSH 10.1 started warning users when connections use cryptography that is not safe against quantum computers. If you received such a warning, it means that the server you connected to did not offer one of the two post-quantum key agreement algorithms that are being standardised for the SSH protocol: mlkem768x25519-sha256 and sntrup761x25519-sha512
The ideal solution is to update the server to use an SSH implementation that supports at least one of these. OpenSSH versions 9.0 and greater support sntrup761x25519-sha512 and versions 9.9 and greater support mlkem768x25519-sha256. If your server is already running one of these versions, then check whether the KexAlgorithms option has disabled their use.
If you are unable to update the server and/or you prefer to accept the risk of continuing to use quantum-unsafe cryptography then the warning may be silenced via the WarnWeakCrypto option in ssh_config(5). We recommend doing this selectively, for example:
Match host unsafe.example.com
WarnWeakCrypto no
Quantum computers don't exist yet, why go to all this trouble?
Because of the "store now, decrypt later" attack mentioned above. Traffic sent today is at risk of decryption unless post-quantum key agreement is used.
What about signature algorithms? You said they were at risk too
Yes, most currently-used signature algorithms (including RSA and ECDSA) can be broken by a quantum computer. However, there is no risk to existing traffic in this situation (i.e. there is no analogous "store now, decrypt later"). The only urgency for signature algorithms is ensuring that all classical signature keys are retired in advance of cryptographically-relevant computers becoming a reality. OpenSSH will add support for post-quantum signature algorithms in the future.
I don't believe we'll ever get quantum computers. This is a waste of time
Some people consider the task of scaling existing quantum computers up to the point where they can tackle cryptographic problems to be practically insurmountable. This is a possibility. However, it appears that most of the barriers to a cryptographically-relevant quantum computer are engineering challenges rather than underlying physics.
If we're right about quantum computers being practical, then we will have protected vast quantities of user data. If we're wrong about it, then all we'll have done is moved to cryptographic algorithms with stronger mathematical underpinnings.
These post-quantum algorithms are new. Are we sure they aren't broken?
We're wary of this too. Though post-quantum key agreement algorithms have received a lot of concerted cryptographic attention over the last few years, it's possible that new attacks might be found.
To defend against this happening we have selected post-quantum algorithms with good safety margins. This means that even if they turn out to be weaker than expected they are still likely to be strong enough to be considered fit for purpose.
Additionally, all the post-quantum algorithms implemented by OpenSSH are "hybrids" that combine a post-quantum algorithm with a classical algorithm. For example mlkem768x25519-sha256 combines ML-KEM, a post-quantum key agreement scheme, with ECDH/x25519, a classical key agreement algorithm that was formerly OpenSSH's preferred default. This ensures that the combined, hybrid algorithm is no worse than the previous best classical algorithm, even if the post-quantum algorithm turns out to be completely broken by future cryptanalysis.
incyber.org Marie De Freminville
26.08.25
La directive NIS2 (Network and Information Security 2), adoptée par l'Union européenne, devait être transposée par chaque État membre de l’UE en droit national, au plus tard en octobre 2024, avec des processus et plannings de transposition spécifiques à chaque pays.
Compte-tenu de l’augmentation des menaces cyber, elle impose des normes plus strictes en matière de cybersécurité, de gestion des risques, et de réaction aux incidents, que la directive NIS, datant de 2016.
Cette nouvelle directive élargit les attentes et le champ d’application. Elle a pour objectif d’anticiper les nouvelles formes d’attaques, de passer d’une approche réactive à une stratégie proactive, et de mettre en place une collaboration étendue, pour l’ensemble de l’écosystème, afin d’assurer la résilience des infrastructures critiques.
Son champ d’application est plus large et s’étend aux entités considérées comme essentielles ou importantes (ex. : énergie, transport, santé, infrastructures numériques, administration publique, etc.). Pour plus de détails, consulter https://monespacenis2.cyber.gouv.fr/directive/.
NIS2 n’est pas directement applicable en Suisse. Néanmoins, une entreprise suisse, est concernée, notamment si elle fait partie de la chaîne d’approvisionnement critique d’entreprises de l’Union européenne soumises à NIS2. Par exemple en tant que fournisseur de services numériques, ou infrastructures critiques transfrontalières, ou si elle opère au sein de l’Union européenne, à travers une filiale, qui rentre dans le périmètre de NIS2 (champ d’application mentionné ci-dessus).
Au-delà de la stricte conformité, le respect des standards européens dans le domaine numérique constitue un pilier de la confiance entre les entreprises suisses et leurs partenaires ou clients européens, et l’application de ces standards renforcera la sécurité des entités suisses qui s’y conformeront.
Les principales questions à se poser:
Mon entreprise a-t-elle une filiale, succursale, ou entité juridique dans un pays de l’UE ?
Mon entreprise fournit-elle des services à des clients situés dans l’UE (entreprises, États, infrastructures critiques) ?
Mon entreprise héberge-t-elle, traite-t-elle ou transporte-t-elle des données de citoyens européens ?
Mon entreprise opère-t-elle dans un secteur “essentiel” ( énergie, santé, banques, transport, infrastructures numériques, eau, espace, administration publique) ou important (agroalimentaire, services numériques, recherche, chimie, déchets, fabrication critique)?
Si l’entreprise suisse répond à l’un de ces critères, ou si le contrat qui la lie à son client contient des obligations de conformité à NIS2, elle doit s’assurer que son dispositif de cybersécurité comprend notamment:
Un CISO ou responsable cybersécurité clairement identifié,
Une politique de cybersécurité formelle, validée par la direction,
Une procédure de gestion des incidents (notification ≤ 24h),
Des analyses de risques réguliers, des audits et tests, visant à s’assurer de la solidité du dispositif,
Des formations à la cybersécurité pour administrateurs et dirigeants.
Dans le secteur financier, les institutions bancaires ayant une filiale / succursale dans l’UE ou agissant en tant que sous-traitant ou partenaire de banques/acteurs européens devront mettre en place:
Une gouvernance de la cybersécurité au niveau du conseil d’administration, nommer un responsable cybersécurité (CISO) au niveau exécutif, réviser la stratégie de cybersécurité, mettre en place un comité de sécurité informatique.
Une cartographie et une gestion des risques liés à la sécurité des systèmes d’information : identifier les actifs essentiels au fonctionnement de la banque, inclure la chaîne d’approvisionnement, les fournisseurs IT et interconnexions.
Des procédures de notification d’incidents dans des délais très courts (24 heures), et un plan de réponse aux incidents cyber.
Des audits de conformité, et un tableau de bord (suivi des indicateurs de sécurité et des exigences NIS2).
Une vérification de la maturité des fournisseurs de services bancaires numériques, IT, cloud, etc. dans le domaine de la cybersécurité, c’est-à-dire leur imposer le respect des standards NIS2.
Un programme de sensibilisation et formation pour les collaborateurs, les dirigeants et le conseil d’administration.
Une mise à jour des contrats avec les fournisseurs IT, et une vérification des niveaux de sécurité des sous-traitants.
Le secteur bancaire est déjà très réglementé : la FINMA (autorité des marchés financiers en Suisse) impose des exigences strictes via ses circulaires, comme 2018/3 « Outsourcing » et 2023/1 « Gestion des risques informatiques », fondées sur le risque et la proportionnalité.
Les initiatives de la Confédération (NCSC) s’inscrivent aussi dans une logique de rapprochement avec les standards européens.
Autres entités essentielles du secteur financier, les IMF (Infrastructures de Marchés Financiers) : plateformes de négociation (bourses, MTF- Multi Trading Facilities, OTF- Organised Trading Facilities, systèmes de cotation), chambres de compensation (CCP), dépositaires centraux de titres (CSD), systèmes de règlement, fournisseurs d’indicateurs de référence critiques, opérateurs de données de marché réglementés.
En Suisse, ces entités incluent des acteurs comme SIX Group, SIX x-clear, SIX SIS, ou Swiss Interbank Clearing (SIC), qui gèrent des systèmes critiques nationaux, mais aussi interconnectés avec l’UE.
Bien que la Suisse ne soit pas soumise directement à NIS2, ses IMF opèrent à l’international, en particulier dans l’UE et traitent des données financières critiques, souvent partagées avec des contreparties européennes.
Bien qu’elles soient déjà soumises à des réglementations rigoureuses, comme LFIN, LBVM, Règlement sur l’infrastructure des marchés financiers, directives FINMA, standards ISO 27001/22301, etc., les IMF suisses devront démontrer leur conformité équivalente aux exigences NIS2, même de façon contractuelle ou opérationnelle.
Dans le secteur de la santé, les hôpitaux et cliniques, les laboratoires, les fournisseurs de soins critiques, les entreprises technologiques médicales (eHealth, MedTech, télémédecine) et les prestataires IT (cloud santé, DMP, plateformes de données médicales) collaborant avec l’UE, sont considérés comme entités essentielles (Annexe I de NIS2).
Comme dans l’industrie bancaire, les entreprises de ce secteur ont de nouvelles obligations et doivent être en mesure de produire les documents suivants:
Politique cybersécurité Santé (avec exigences NIS2),
Analyse de risques IT / DMP / IoMT,
Procédure de notification d’incidents,
Registre de conformité / tableau de bord,
Rapports d’audit / plans de remédiation,
Attestations de sensibilisation / format.
Dans le secteur de l’énergie, les opérateurs de réseaux, les producteurs, les fournisseurs, et les prestataires techniques (ex : SCADA: système de supervision industrielle, OT : operational technology, cloud industriel) doivent se conformer à NIS2, dans la mesure où ils doivent répondre aux attentes de partenaires européens et autorités européennes, avec un objectif de renforcer la résilience des infrastructures critiques.
Par ailleurs, les entreprises de ce secteur doivent anticiper l’évolution du droit suisse (LSI, OICN, etc.), qui doit converger avec NIS2, par le biais de l’Ordonnance sur la protection des infrastructures critiques (OICN) et les directives de l’OFEN et du NCSC.
Les particularités du secteur de l’énergie sont les suivantes:
Inclure l’OT, la production, les fournisseurs et la télégestion dans la politique de sécurité
Créer un comité cybersécurité interdisciplinaire avec les représentants IT, OT, opérations, conformité,
Cartographier les systèmes critiques : supervision automatisée, contrôle distribué, réseaux de distribution, postes haute tension, infrastructures partagées avec l’UE
Renforcer les mesures de sécurité sur les systèmes informatiques industriels (notamment séparation des environnements et contrôle des accès), détecter les incidents, mettre en place un plan de continuité d’activité / reprise des activités, revoir les contrats des fournisseurs IT avec une clause de conformité NIS2.
Former les administrateurs et dirigeants, mais aussi les opérateurs industriels et informatiques.
Dans le secteur des transports, la directive NIS2 couvre toutes les formes de transport critiques: aérien (compagnies aériennes, gestionnaires d’aéroports, contrôle aérien), ferroviaire (opérateurs ferroviaires, gestionnaires d’infrastructures, services d’aiguillage), maritime (ports, transporteurs maritimes, systèmes de navigation, opérateurs de fret), et routier (sociétés d’autoroutes, gestion du trafic, plateformes logistiques essentielles (moins prioritaire mais possible selon les pays membres)
La Suisse étant étroitement interconnectée avec les réseaux européens, est partie prenante d’accords transfrontaliers (ex : transport ferroviaire européen, sécurité aérienne avec l’EASA, corridors logistiques). Elle est soumise à ses propres cadres de cybersécurité (p. ex. OICN, LSI, exigences de l’Office fédéral des transports – OFT) et ses entreprises de transport sont donc fortement incitées à s’aligner volontairement sur NIS2, et notamment à sécuriser les systèmes industriels (isolation, segmentation réseau, surveillance des SCADA), identifierindemtifier les systèmes interconnectés avec l’UE.
Enfin, les infrastructures numériques suisses sont étroitement interconnectées à celles de l’UE ( interconnexion Internet, transit IP, cloud européens, réseaux transfrontaliers), elles sont susceptibles d’héberger ou transporter des données européennes (dans le cas d’acteurs cloud ou de services numériques globaux).
Elles sont soumises à la Loi sur la sécurité de l’information (LSI), la Loi sur les télécommunications (LTC), et aux recommandations du NCSC et du SEFRI.qui sont un pilier central de la directive NIS2.
Les fournisseurs d’infrastructure numérique suisses (fournisseurs de services DNS, registres de noms de domaine, services cloud critiques, data centers critiques, réseaux de diffusion de contenu, points d’échange Internet ) opérant en Europe ou servant des clients européens doivent démontrer un niveau de sécurité équivalent à celui exigé par NIS2, souvent via des audits, certifications ou clauses contractuelles.
Elles doivent donc cartographier les clients/services exposés à l’UE, renforcer détection, résilience, surveillance, définir des procédures claires, audits, documentation, contrôler leurs sous-traitants et leur conformitéconformiter à NIS2 (clause à introduire à leurs contrats).
En conclusion, bien que la Suisse impose à ses entreprises des réglementations dans le domaine des risques cyber, les attentes et le champ d’application ne sont pas exactement les mêmes que dans la directive NIS2.
Il est donc important de vérifier, pour les entreprises suisses qui entrent dans le champ d’application NIS2, et qui opèrent avec l’UE, quelles actions mener pour renforcer le dispositif de cybersécurité, indispensable pour maintenir des relations de confiance avec les clients et partenaires, et pour répondre à leurs exigences règlementaires.
www.usine-digitale.fr Alice Vitard
26 août 2025
Dans le cadre du Cyber Solidarity Act, l'Agence de l'Union européenne pour la cybersécurité se voit confier la gestion de la réserve européenne de cybersécurité. Grâce à une enveloppe de 36 millions d'euros, elle est chargée de sélectionner et de coordonner des prestataires capables d'intervenir en cas d'incidents de grande ampleur.
La Commission européenne et l'Agence de l'Union européenne pour la cybersécurité (European Union Agency for Cybersecurity, ENISA) ont annoncé le 26 août avoir signé un accord de contribution qui confie à l'Enisa l'administration et le fonctionnement de la réserve européenne de cybersécurité. Une enveloppe de 36 millions d'euros sur trois ans lui a ainsi été attribuée.
Répondre aux incidents à grande échelle
Cette réserve est prévue à l'article 14 du Cyber Solidarity Act, texte adopté en 2024 pour doter l'Union de moyens renforcés pour détecter, préparer et répondre aux cyberattaques à grande échelle. Elle doit permettre à l'UE de disposer de capacités communes de réponse aux incidents majeurs.
En pratique, la réserve est conçue comme un mécanisme de soutien mobilisable en cas d'incident transfrontalier significatif. Il s'appuie sur un réseau de prestataires de services managés de confiance, pré-sélectionnés via des appels d'offres publics. Ces prestataires peuvent intervenir pour contenir une attaque, assurer une continuité de service ou encore accompagner la reprise après incident.
A noter que le dispositif inclut une clause de flexibilité. En effet, si les services pré-engagés ne sont pas utilisés pour des réponses à incident, ils pourront être convertis en services de préparation (tests de sécurité, exercices de crise et audit de résilience).
La réserve ouverte à un panel d'acteurs
Dans le détail, la réserve sera ouverte aux secteurs critiques définis par la directive NIS 2, aux institutions, agences et organes de l'UE. Sous certaines conditions, les pays tiers associés au programme "Europe numérique" pourront également y avoir accès.
L'Enisa se voit confier quatre missions : lancer et gérer les marchés publics pour sélectionner les prestataires, évaluer les demandes d'assistance provenant des Etats membres, transmettre les demandes de pays tiers à la Commission européenne pour validation ainsi que de suivre et contrôler l'exécution des services fournis par les prestataires de services.
L'accord de contribution prévoit un financement de 36 millions d'euros sur trois ans. Ces fonds s'ajoutent au budget annuel de 26,9 millions d'euros. Ils sont alignés sur la durée de mise à disposition des services. Leur utilisation est contrôlée par l'exécutif européen.
Combler le manque de réponse coordonnée
En mutualisant les ressources, la réserve européenne a pour objectif de combler une lacune de longue date : l'absence d'une capacité de réponse coordonnée aux attaques de grande ampleur. Dans ce cadre, le Cyber Solidarity Act prévoit également le déploiement de SOC transfrontaliers ainsi que des financements européens spécifiques pour soutenir la montée en capacité des Etats membres en matière de sécurité informatique.
therecord.media Alexander Martin
August 27th, 2025
A suspected ransomware attack on a Swedish software provider is believed to have impacted around 200 of the country’s municipal governments.
A suspected ransomware attack on Miljödata, a Swedish software provider used for managing sick leave and similar HR reports, is believed to have impacted around 200 of the country’s municipal governments.
The attack was detected on Saturday, according to the company’s chief executive Erik Hallén. The attackers are attempting to extort Miljödata, police told local newspaper BLT.
Swedish Minister for Civil Defence Carl-Oskar Bohlin wrote in a short update on social media: “The scope of the incident has not yet been clarified, and it is too early to determine the actual consequences.”
Hallén told Swedish press agency TT that around 200 municipalities and regions were affected by the incident. Sweden has 290 municipalities and 21 regions.
Several regional governments have confirmed using Miljödata systems to handle employee data, including “for example, medical certificates, rehabilitation plans, work-related injuries, and more,” according to the local government of the island of Gotland.
Hallén reportedly said Miljödata was “working very intensively with external experts to investigate what happened, what and who was affected, and to restore system functionality.”
“The government is receiving ongoing information about the incident and is in close contact with the relevant authorities,” Bohlin, the civil defense minister, said.
“CERT-SE, which has the task of supporting Swedish society in handling and preventing IT security incidents, has offered advice and support to both the company in question and the affected customers,” the minister added. “The national cybersecurity center is coordinating the measures of the relevant authorities. A police investigation is also underway.”
He stressed the incident underscored the need for high levels of cybersecurity throughout society, and said the Swedish government planned to present a new cybersecurity bill to the Swedish parliament in the near future “that will impose increased requirements on a wide range of actors.”
https://hackread.com
by
Deeba Ahmed
August 28, 2025
A supply chain attack called “s1ngularity” on Nx versions 20.9.0-21.8.0 stole thousands of macOS developer credentials with the help of AI tools.
Asophisticated cyberattack, dubbed the “s1ngularity” attack, has compromised Nx, a popular build platform widely used by software developers. The attack, which began on August 26, 2025, is a supply chain attack, a type of security breach where hackers sneak malicious code into a widely used piece of software, which then infects all the people who use it.
The attack was designed to steal a wide variety of sensitive data, including GitHub tokens, npm authentication keys, and SSH private keys. These credentials are essentially digital keys that provide access to a user’s accounts and systems.
The malicious software also went a step further, targeting API keys for popular AI tools like Gemini, Claude, and Q, demonstrating a new focus on emerging technologies. In addition to stealing data, the attackers installed a destructive payload that modified users’ terminal startup files, causing their terminal sessions to crash.
GitGuardian’s analysis shared with Hackread.com revealed some surprising details about the attack and its victims. The firm found that 85% of the infected systems were running macOS, highlighting the attack’s particular impact on the developer community, which frequently uses Apple computers.
In a curious turn, GitGuardian found that of the hundreds of systems where AI tools were targeted, many of the AI clients unexpectedly resisted the malicious requests. They either outright refused to run the commands or gave responses suggesting they knew they were being asked to do something wrong, showing a potential, though unintentional, new layer of security.
The stolen credentials were not only valuable but also widespread. GitGuardian’s monitoring platform, which tracks public GitHub activity, discovered 1,346 repositories used by the attackers to store stolen data.
To avoid detection, the attackers double-encoded the stolen data before uploading it. This number is far higher than the ten publicly visible repositories, as GitHub was quickly working to delete the rest. An analysis of these repositories revealed 2,349 distinct secrets, with over 1,000 still valid and working at the time of the report. The most common secrets were for GitHub and popular AI platforms.
For anyone who used the malicious Nx versions 20.9.0 through 21.8.0, the most crucial step is to immediately assume that their credentials have been exposed. GitGuardian has created a free service called HasMySecretLeaked that allows developers to check for compromised credentials without ever revealing their actual keys.
This attack reminds us that simply deleting a compromised file is not enough; the actual secret keys and tokens must be revoked and rotated to prevent further access by the attackers.
www.swissinfo.ch August 28, 2025 -
Swiss health groups found national cyber-security centre to warn against cyber attacks.
The cantonal hospital authorities of Ticino and Graubünden are among the founders of the Healthcare Cyber Security Centre (H-CSC).
The premise is that “hospitals are tempting targets for cybercriminals, since they handle large quantities of sensitive data,” said H-CSC as it was officially established in Thurgau.
The initiative in Ticino was also joined by the Gruppo ospedaliero Moncucco, which brings together the Moncucco clinics in Lugano and Santa Chiara in Locarno, and a Graubünden foundation made up of health care associations, including the Thusis hospital.
Founding members also include the university hospitals of Basel, Bern and Zurich, but not in Geneva and Lausanne.
French-speaking institutions are clearly under-represented – the Fribourg and Valais hospitals are the only members from this region. But H-CSC is set to grow. “Membership of the association will be open from 1 September 2025 to all hospitals with a public service mandate”.
The H-CSC project was launched last year on the recommendation of the Federal Office for Cyber Security. The aim of the association is to offer tailor-made security services for hospitals in the field of cyber security.
The H-CSC (https://www.h-csc.ch/) will serve as a platform to promote knowledge exchange and collaboration between hospitals, expand existing competencies and create synergies that will “sustainably strengthen their ability to prevent, detect and contain cyber incidents”, the association’s website states.
Such incidents can “severely compromise the functioning (of hospitals), causing the postponement of surgeries, encryption and/or disclosure of sensitive patient data, or the inoperability of medical devices.”
