Dal 4 giugno, se si tenta di accedere a Pornhub, YouPorn o RedTube, sarà possibile visualizzare solo “Liberty Leading the People”, accompagnato da un testo del gruppo Aylo. Nel suo comunicato stampa, il colosso canadese dell’industria per adulti spiega di aver deciso di sospendere l’accesso ai suoi siti dalla Francia, in risposta all’entrata in vigore, il 9 giugno, della legge SREN e del doppio anonimato. Questo metodo di controllo dell’età dei visitatori, secondo l’azienda, mette a repentaglio la riservatezza dei suoi visitatori.

Quindi, inevitabilmente, questa decisione ha creato frustrazione tra i quasi 3,8 milioni di utenti di siti porno. Abbastanza da spingerli a cercare metodi di elusione per accedere alle loro piattaforme “intime”.

Fino al 1.000% in più di utenti francesi

Se scegli una VPN, non sarai il solo. Dal pomeriggio del 4 giugno, la maggior parte di questi servizi ha visto esplodere il numero di clienti francesi. Come logica conseguenza della scomparsa di un servizio ampiamente utilizzato in Francia, questo aumento ha raggiunto livelli impressionanti anche per ProtonVPN.

L’azienda ha condiviso uno screenshot delle sue statistiche, che mostra un aumento di oltre il 1.000% nella creazione di nuovi account.

Per la cronaca, ProtonVPN afferma addirittura che questa crescita supera quella registrata durante il blocco di TikTok negli Stati Uniti. Ciò evidenzia la reale portata dei siti per adulti nella vita quotidiana di molti francesi. NordVPN segnala un aumento del 170% delle registrazioni in Francia.

Questo sembra essere un fenomeno globale.

È legale utilizzare una VPN per accedere a Pornhub o YouPorn?

Tuttavia, rimane una domanda: è legale utilizzare una VPN per accedere a questi siti, che ora sono generalmente inaccessibili nel Paese?

La risposta è semplice: sì. L’uso delle reti private virtuali è legale in Francia e questi siti non sono inaccessibili a seguito di una decisione legale o amministrativa, ma piuttosto a seguito di una decisione interna specifica dell’azienda Aylo.

Infine, i gestori delle VPN si aspettano critiche, sottolineando che l’aumento delle registrazioni riguarda gli adulti francesi, poiché la procedura richiede l’accesso a una carta di credito.

NordVPN coglie anche l’occasione per esprimere un chiaro sostegno al gruppo Aylo, sottolineando che questo tipo di fenomeno è particolarmente visibile nei paesi “dove le libertà digitali sono minacciate”.

L'articolo Le VPN esplodono in Francia! Pornhub, YouPorn e RedTube bloccati? Ma solo da un Click! proviene da il blog della sicurezza informatica.

When [upir] saw that you could buy tire valve stem caps that read pressure electronically, he decided to roll his own Tire Pressure Monitoring System (TPMS) like the one found on modern cars. An ESP32 and an OLED display read the pressure values. He didn’t have a car tire on his workbench though, so he had to improvise there.

Of course, a real TPMS sensor goes inside the tire, but screwing them on the valve stem is much easier to deal with. The sensors use Bluetooth Low Energy and take tiny batteries. In theory, you’re supposed to connect to them to your phone, although two different apps failed to find the sensors. Even a BLE scanner app wouldn’t pick them up. Turns out — and this makes sense — the sensors don’t send data if there’s no pressure on them, so as not to run down the batteries. Putting pressure on them made them pop up on the scanner.

The scanner was able to read the advertisement and then correlate pressure to the data. He discovered that someone had already decoded standard TPMS BLE data, except the advertisements he found were significantly longer than his own. Eventually he was able to find a good reference.

The data includes a status byte, the battery voltage, the temperature, and pressure. Once you know the format, it is straightforward to read it and create your own display. Many people would have ended the video there, but [upir] goes into great detail — the video is nearly an hour long. If you want to duplicate the project, there’s plenty of info and a code repository, too.

If you need to read the regular RF TPMS sensors, grab a software-defined radio. Many of these sensors follow their own format though, so be prepared.

youtube.com/embed/P85tkCbQGo8?…

hackaday.com/2025/08/27/homebr…

I rappresentanti di Google hanno annunciato che dal 2026, solo le app di sviluppatori verificati potranno essere installate sui dispositivi Android certificati. Questa misura mira a contrastare malware e frodi finanziarie e riguarderà le app installate da fonti terze.

Il requisito si applicherà a tutti i “dispositivi Android certificati”, ovvero i dispositivi che eseguono Play Protect e hanno le app Google preinstallate.

Nel 2023, il Google Play Store ha introdotto requisiti simili e, secondo l’azienda, ciò ha portato a un netto calo di malware e frodi. Ora i requisiti saranno obbligatori per qualsiasi app, comprese quelle distribuite tramite app store di terze parti e tramite sideloading (quando l’utente scarica autonomamente il file APK sul dispositivo).

“Pensate a questo come a un controllo d’identità in aeroporto: verifica l’identità del viaggiatore, ma è un controllo separato dal controllo del suo bagaglio. Verificheremo l’identità dello sviluppatore, ma non il contenuto della sua app o la sua origine”, scrive l’azienda.

In questo modo, Google vuole combattere le “convincenti app false” e rendere più difficile il compito agli aggressori che iniziano a distribuire un altro malware poco dopo che Google ha rimosso quello precedente. Secondo una recente analisi, le fonti di terze parti da cui vengono installate le app tramite sideloading contengono 50 volte più malware rispetto alle app disponibili nel Google Play Store.

Allo stesso tempo, Google sottolinea che “gli sviluppatori manterranno la stessa libertà di distribuire le loro app direttamente agli utenti tramite fonti terze parti o di utilizzare qualsiasi app store preferiscano”. Per implementare la nuova iniziativa, verrà creata una Console per sviluppatori Android separata e semplificata soprattutto per quelli che distribuiscono le proprie app al di fuori del Google Play Store. Dopo aver verificato la loro identità, gli sviluppatori dovranno registrare il nome del pacchetto e le chiavi di firma per le loro app.

Chi distribuisce app tramite il Google Play Store “probabilmente è già conforme ai requisiti di verifica tramite l’attuale processo Play Console”, che richiede alle organizzazioni di fornire un numero DUNS (Data Universal Numbering System, un numero di identificazione univoco a nove cifre per le persone giuridiche). Il nuovo sistema di verifica inizierà i test a ottobre di quest’anno, con i primi sviluppatori Android che potranno accedervi. Il meccanismo sarà disponibile a tutti a partire da marzo 2026.

Il requisito di verifica entrerà in vigore per la prima volta a settembre 2026 in Brasile, Indonesia, Singapore e Thailandia. Google spiega che questi Paesi sono “particolarmente colpiti da queste forme di app fraudolente”. Successivamente, nel 2027, la verifica degli sviluppatori inizierà ad essere applicata a livello globale.

L'articolo Dal 2026 basta app “fantasma”: Android accetterà solo sviluppatori verificati proviene da il blog della sicurezza informatica.

La rete governativa del Nevada è rimasta paralizzata dopo un incidente avvenuto nelle prime ore del mattino del 24 agosto. L’attacco ha reso inoperativa l’infrastruttura IT dello Stato e costretto la maggior parte degli uffici a chiudere al pubblico. Restano operativi solo i servizi essenziali e i dipendenti coinvolti in processi critici.

L’ufficio del governatore ha riferito che, da quando è stato rilevato l’incidente, gli specialisti hanno lavorato 24 ore su 24 per ripristinare il servizio.

Sono stati utilizzati percorsi temporanei e soluzioni alternative per mantenere l’accesso a diverse risorse. Allo stesso tempo, le autorità sottolineano che l’obiettivo principale non è la velocità di ripristino dei servizi, ma la loro sicurezza. Prima del riavvio, tutti i sistemi vengono testati e ne viene confermato il corretto funzionamento.

Please see the memo related to the August 24 network security incident below. pic.twitter.com/PvXcSpO63G
— Governor Lombardo Press Office (@Lombardo_Press) August 25, 2025

Eì stato riportato che i cittadini devono prepararsi a eventuali disagi: i siti web e le linee telefoniche delle agenzie governative potrebbero rispondere con ritardo o rimanere non disponibili.

Tuttavia, le chiamate di emergenza tramite il 911 funzionano normalmente. Le autorità sottolineano che i problemi riguardano solo le infrastrutture governative e non interessano la connessione Internet domestica o le reti mobili dei residenti.

Al momento, gli uffici rimangono chiusi.

Mentre le indagini proseguono, le autorità affermano che non ci sono segnali di fuga di dati personali.

Tuttavia, si ricorda ai residenti i rischi di frode: devono diffidare di chiamate, messaggi o lettere che richiedono password e dati. I rappresentanti del governo sottolineano che i servizi ufficiali non richiederanno tali informazioni via e-mail o telefono.

Le autorità statali stanno coordinando le loro azioni con le strutture federali e locali. Tutte le notifiche ufficiali sul processo di recupero vengono pubblicate centralmente per impedire la diffusione di informazioni non confermate.

L'articolo Un devastante Attacco informatico paralizza la rete governativa del Nevada proviene da il blog della sicurezza informatica.

Dichiarazione di Marco Perduca

A proposito della distribuzione di centinaia di pipette per l’uso di crack nella città di Bologna, l’Associazione Luca Coscioni si congratula con l’assessora Madrid e l’amministrazione per “aver finalmente dimostrato cosa significhi applicare, cioè rispettare, quanto di livello essenziale di assistenza c’è nelle politiche di riduzione del danno. Politiche che pure riconosciute da 8 anni come Lea rarissimamente vengono messe in atto nella loro complessità, va dato quindi atto a Bologna di aver predisposto una serie di servizi alle persone che fanno uso di sostanze illecite per aiutarle nelle difficoltà reali e potenziali che tale uso può comportare.

Non si tratta quindi di condonare o istigare l’uso si tratta di affrontare laicamente una realtà facendo tesoro di quando da decenni viene chiamato riduzione del danno e che l’Italia continua non solo a non applicare ma anche a disconoscere in sede di Nazioni unite. Auspichiamo che quanto prima anche altre città facciano sì che Bologna non sia l’eccezione ma la conferma di una regola”.

L’Associazione Luca Coscioni con Forum Droghe, Antigone, CNCA la CGIL e decine di altre organizzazioni ha convocato una contro conferenza sulle droghe dal 6 all’8 novembre prossimi a Roma. La tre giorni vuole contrapporre a quanto il governo Meloni adotterà ufficialemte in materia di dipendenze proprio in quei giorni a Roma, un “piano” di riforme e politiche alternative su cui la società civile italiana è impegnata da decenni per ridurre i danni e i rischi del proibizionismo e legalizzare le sostanze psicoattive oggi illecite.

L'articolo Pipe Crack Bologna, Perduca: “la riduzione del danno si fa così” proviene da Associazione Luca Coscioni.

more here: instagram.com/p/DN0iMNCWNpU

#genocide #zionism #israhell #izrahell #Gaza #Palestine #privacy #datamining #datacontrol #facialrecognition #ai #control #apartheid #ethniccleansing #google #googlecomplicity

Il rivenditore francese Auchan ha informato centinaia di migliaia di clienti che i loro dati personali sono stati rubati a seguito di un attacco hacker.

Nelle notifiche inviate agli utenti la scorsa settimana, l’azienda ha affermato che la violazione ha interessato nomi, indirizzi e-mail, numeri di telefono e numeri di carte fedeltà, ma ha sottolineato che non sono state compromesse informazioni bancarie, password o PIN.

“La informiamo che Auchan è stata vittima di un attacco informatico. Questo attacco ha comportato l’accesso non autorizzato ad alcuni dati personali associati al suo account del programma fedeltà”, si legge nell’avviso.

Auchan afferma di aver adottato tutte le misure necessarie per localizzare l’attacco e migliorare la sicurezza dei propri sistemi, e di aver informato le forze dell’ordine e le autorità di regolamentazione dell’incidente.

L’azienda consiglia ai clienti interessati di prestare attenzione a potenziali casi di phishing e frode, poiché gli aggressori potrebbero tentare di utilizzare informazioni rubate.

Il rivenditore ha dichiarato ai media francesi che l’incidente ha colpito “centinaia di migliaia di clienti”. Tuttavia, l’azienda non ha specificato come si sia verificata esattamente la fuga di dati, chi ci fosse dietro l’attacco informatico o se l’incidente fosse collegato a un’estorsione.

L'articolo Fuga di dati Auchan: centinaia di migliaia di clienti colpiti da un attacco hacker proviene da il blog della sicurezza informatica.

Suppose someone came to talk to you and said, “I need your help. I have a Raspberry Pi-based robot and I want to develop a custom Android app to control it.” If you are like me, you’ll think about having to get the Android developer tools updated, and you’ll wonder if you remember exactly how to sign a manifest. Not an appealing thought. Sure, you can buy things off the shelf that make it easier, but then it isn’t custom, and you have to accept how it works. But it turns out that for simple things, you can use an old Google Labs project that is, surprisingly, still active and works well: MIT’s App Inventor — which, unfortunately, should have the acronym AI, but I’ll just call it Inventor to avoid confusion.

What’s Inventor? It lives in your browser. You lay out a fake phone screen using drag and drop, much like you’d use QT Designer or Visual Basic. You can switch views and attach actions using a block language sort of like Scratch. You can debug in an emulator or on your live phone wirelessly. Then, when you are ready, you can drop an APK file ready for people to download. Do you prefer an iPhone? There’s some support for it, although that’s not as mature. In particular, it appears that you can’t easily share an iPhone app with others.

Is it perfect? No, there are some quirks. But it works well and, with a little patience, can make amazingly good apps. Are they as efficient as some handcrafted masterpiece? Probably not. Does it matter? Probably not. I think it gets a bad rep because of the colorful blocks. Surely it’s made for kids. Well, honestly, it is. But it does a fine job, and just like TinkerCad or Lego, it is simple enough for kids, but you can use it to do some pretty amazing things.

How Fast?

How fast is it to create a simple Android app? Once you get used to it, it is very fast, and there are plenty of tutorials. Just for fun, I wrote a little custom web browser for my favorite website. It is hard to tell from the image, but there are several components present. The web browser at the bottom is obvious, and there are three oval buttons. The Hackaday logo is also clickable (it takes you home). What you can’t see is that there is a screen component you get by default. In there is a vertical layout that stacks the toolbar with the web browser. Then the toolbar itself is a horizontal layout (colored yellow, as you can see).

The black bar at the bottom and the very top bar are parts of the fake phone, although you can also pick a fake monitor or tablet if you want more space to work.

What you can’t see is that there are two more hidden components. There’s a clock. If you are on the home page for an hour, the app refreshes the page. There’s also a share component that the share button will use. You can see three views of the app below. There are three views: a design view where you visually build the interface, a block view where you create code, and the final result running on a real phone.

Code

Putting all that on the screen took just a few minutes. Sure, I played with the fonts and colors, but just to get the basic layout took well under five minutes. But what about the code? That’s simple, too, as you can see.

The drab boxes are for control structures like event handlers and if/then blocks. Purple boxes are for subroutine calls, and you can define your own subroutines, although that wasn’t needed here. The green blocks are properties, like the browser’s URL. You can try it yourself if you want.

Rather than turn this into a full-blown Inventor tutorial, check out any of the amazingly good tutorials on the YouTube channel, like the one below.

youtube.com/embed/eSvtXWpZ6os?…

Half the Story

Earlier, I mentioned that your friend wants a robot controller to talk to a Raspberry Pi. I was surprised at how hard this turned out to be, but it wasn’t Inventor’s fault. There are three obvious choices: the system can make web requests, or it can connect via Bluetooth. It can also work with a serial port.

I made the mistake of deciding to use Bluetooth serial using the Bluetooth client component. From Inventor’s point of view, this is easy, if not very sophisticated. But the Linux side turned out to be a pain.

There was a time when Bluez, the Linux Bluetooth stack, had a fairly easy way to create a fake serial port that talked over Bluetooth. There are numerous examples of this circulating on the Internet. But they decided that wasn’t good for some reason and deprecated it. Modern Linux doesn’t like all that and expects you to create a dbus program that can receive bus messages from the Bluetooth stack.

To Be Fair…

Ok, in all fairness, you can reload the Bluetooth stack with a compatibility flag — at least for now — and it will still work the old way. But you know they’ll eventually turn that off, so I decided I should do it the right way. Instead of fighting it, though, I found some code on GitHub that created a simple client or server for SPP (the serial port profile). I stripped it down to just work as a server, and then bolted out a separate function bt_main() where you can just write code that works with streams. That way, all the hocus pocus — and there is a lot of it — stays out of your way.

You can find my changes to the original code, also on GitHub. Look at the spp_bridge.c file, and you’ll see it is a lot of messy bits to interact with Bluez via dbus. It registers a Profile1 interface and forks a worker process for each incoming connection. The worker runs the user-defined bt_main() function, which will normally override. The worker reads from the Bluetooth socket and writes to your code via a normal FILE *. You can send data back the same way.

Here’s the default bt_main function:
<div>
<pre>int bt_main(int argc, char *argv[], FILE *in, FILE *out) {
// Default demo: echo lines, prefixing with "ECHO: "
fprintf(stderr,"[bt_main] Default echo mode.\n");
setvbuf(out,NULL,_IOLBF,0);
charbuf[1024];
while(fgets(buf,sizeof(buf),in)){
fprintf(stderr,"[bt_main] RX: %s",buf);
fprintf(out,"ECHO: %s",buf);
fflush(out);
}
fprintf(stderr,"[bt_main] Input closed. Exiting.\n");
return0;
}</pre>

In retrospect, it might have been better to just use the compatibility flag on the Bluez server to restore the old behavior. At least, for as long as it lasts. This involves finding where your system launches the Bluez service (probably in a systemd service, these days) and adding a -c to the command line. There may be a newer version of rfcomm that supports the latest Bluez setup, too, but KDE Neon didn’t have it.

On the other hand, this does work. The bt_main function is easy to write and lets you focus on solving your problem rather than how to set up and tear down the Bluetooth connection.

Next Time

Next time, I’ll show you a more interesting bt_main along with an Android app that sends and receives data with a custom server. You could use this as the basis of, for example, a custom macropad or an Android app to control a robot.

Sabato 20 e domenica 21 settembre 2025 in Prato della Valle a Padova è in programma la quarta edizione dell’evento dedicato alla prevenzione gratuita della salute, realizzato dalla testata giornalistica Dì Salute, in collaborazione con il Comune di Padova.

All’interno dell’iniziativa, la Cellula Coscioni Vicenza Padova organizza l’incontro “DAT e altri strumenti per il proprio fine vita”. L’appuntamento è per domenica 21 settembre alle ore 16.00 presso lo stand 29, in Prato della Valle, Prato della Valle, 35141 Padova PD.

L'articolo A Padova un incontro sul fine vita promosso dalla Cellula Coscioni Vicenza Padova proviene da Associazione Luca Coscioni.

Libertà di scegliere – Dialogo sulle Disposizioni Anticipate di Trattamento (DAT)
Parco Milcovich – Casetta Zebrina, Padova
Giovedì 11 settembre 2025 – ore 18:30

Cosa sono le Disposizioni Anticipate di Trattamento e perché è importante conoscerle e redigerle?
La Cellula Vicenza-Padova terrà un incontro pubblico di approfondimento e confronto sul tema delle DAT – uno strumento fondamentale per tutelare il proprio diritto all’autodeterminazione nella fase finale della vita.

A guidare la discussione saranno Marta Perrone, Diego Silvestri e Domenico Farano, attivisti della Cellula Coscioni Vicenza-Padova.

Ingresso libero – Iniziativa ospitata presso Casetta Zebrina, nel Parco Milcovich, con ingresso da Via Jacopo da Montagnana.

Evento promosso dalla Cellula Coscioni Vicenza-Padova, in collaborazione con Casetta Zebrina.

L'articolo A Padova l’evento “Libertà di scegliere – dialogo sulle Disposizioni Anticipate di Trattamento” proviene da Associazione Luca Coscioni.

Vulnerability registrations in Q2 2025 proved to be quite dynamic. Vulnerabilities that were published impact the security of nearly every computer subsystem: UEFI, drivers, operating systems, browsers, as well as user and web applications. Based on our analysis, threat actors continue to leverage vulnerabilities in real-world attacks as a means of gaining access to user systems, just like in previous periods.

This report also describes known vulnerabilities used with popular C2 frameworks during the first half of 2025.

Statistics on registered vulnerabilities

This section contains statistics on assigned CVE IDs. The data is taken from cve.org.

Let’s look at the number of CVEs registered each month over the last five years.

Total vulnerabilities published each month from 2021 to 2025 (download)

This chart shows the total volume of vulnerabilities that go through the publication process. The number of registered vulnerabilities is clearly growing year-on-year, both as a total and for each individual month. For example, around 2,600 vulnerabilities were registered as of the beginning of 2024, whereas in January 2025, the figure exceeded 4,000. This upward trend was observed every month except May 2025. However, it’s worth noting that the registry may include vulnerabilities with identifiers from previous years; for instance, a vulnerability labeled CVE-2024-N might be published in 2025.

We also examined the number of vulnerabilities assigned a “Critical” severity level (CVSS > 8.9) during the same period.

Total number of critical vulnerabilities published each month from 2021 to 2025 (download)

The data for the first two quarters of 2025 shows a significant increase when compared to previous years. Unfortunately, it’s impossible to definitively state that the total number of registered critical vulnerabilities is growing, as some security issues aren’t assigned a CVSS score. However, we’re seeing that critical vulnerabilities are increasingly receiving detailed descriptions and publications – something that should benefit the overall state of software security.

Exploitation statistics

This section presents statistics on vulnerability exploitation for Q2 2025. The data draws on open sources and our telemetry.

Windows and Linux vulnerability exploitation

In Q2 2025, as before, the most common exploits targeted vulnerable Microsoft Office products that contained unpatched security flaws.

Kaspersky solutions detected the most exploits on the Windows platform for the following vulnerabilities:

• CVE-2018-0802: a remote code execution vulnerability in the Equation Editor component
• CVE-2017-11882: another remote code execution vulnerability, also affecting Equation Editor
• CVE-2017-0199: a vulnerability in Microsoft Office and WordPad allowing an attacker to gain control over the system

These vulnerabilities are traditionally exploited by threat actors more often than others, as we’ve detailed in previous reports. These are followed by equally popular issues in WinRAR and exploits for stealing NetNTLM credentials in the Windows operating system:

• CVE-2023-38831: a vulnerability in WinRAR involving improper handling of files within archive contents
• CVE-2025-24071: a Windows File Explorer vulnerability that allows for the retrieval of NetNTLM credentials when opening specific file types (.library-ms)
• CVE-2024-35250: a vulnerability in the ks.sys driver that allows arbitrary code execution

Dynamics of the number of Windows users encountering exploits, Q1 2024 — Q2 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download)

All of the vulnerabilities listed above can be used for both initial access to vulnerable systems and privilege escalation. We recommend promptly installing updates for the relevant software.

For the Linux operating system, exploits for the following vulnerabilities were detected most frequently:

• CVE-2022-0847, also known as Dirty Pipe: a widespread vulnerability that allows privilege escalation and enables attackers to take control of running applications
• CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation
• CVE-2021-22555: a heap overflow vulnerability in the Netfilter kernel subsystem. The widespread exploitation of this vulnerability is due to the fact that it employs popular memory modification techniques: manipulating msg_msg primitives, which leads to a Use-After-Free security flaw.

Dynamics of the number of Linux users encountering exploits, Q1 2024 — Q2 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download)

It’s critically important to install security patches for the Linux operating system, as it’s attracting more and more attention from threat actors each year – primarily due to the growing number of user devices running Linux.

Most common published exploits

In Q2 2025, we observed that the distribution of published exploits by software type continued the trends from last year. Exploits targeting operating system vulnerabilities continue to predominate over those targeting other software types that we track as part of our monitoring of public research, news, and PoCs.

Distribution of published exploits by platform, Q1 2025 (download)

Distribution of published exploits by platform, Q2 2025 (download)

In Q2, no public information about new exploits for Microsoft Office systems appeared.

Vulnerability exploitation in APT attacks

We analyzed data on vulnerabilities that were exploited in APT attacks during Q2 2025. The following rankings are informed by our telemetry, research, and open-source data.

TOP 10 vulnerabilities exploited in APT attacks, Q2 2025 (download)

The Q2 TOP 10 list primarily draws from the large number of incidents described in public sources. It includes both new security issues exploited in zero-day attacks and vulnerabilities that have been known for quite some time. The most frequently exploited vulnerable software includes remote access and document editing tools, as well as logging subsystems. Interestingly, low-code/no-code development tools were at the top of the list, and a vulnerability in a framework for creating AI-powered applications appeared in the TOP 10. This suggests that the evolution of software development technology is attracting the attention of attackers who exploit vulnerabilities in new and increasingly popular tools. It’s also noteworthy that the web vulnerabilities were found not in AI-generated code but in the code that supported the AI framework itself.

Judging by the vulnerabilities identified, the attackers’ primary goals were to gain system access and escalate privileges.

C2 frameworks

In this section, we’ll look at the most popular C2 frameworks used by threat actors and analyze the vulnerabilities whose exploits interacted with C2 agents in APT attacks.

The chart below shows the frequency of known C2 framework usage in attacks on users during the first half of 2025, according to open sources.

TOP 13 C2 frameworks used by APT groups to compromise user systems in Q1–Q2 2025 (download)

The four most frequently used frameworks – Sliver, Metasploit, Havoc, and Brute Ratel C4 – can work with exploits “out of the box” because their agents provide a variety of post-compromise capabilities. These capabilities include reconnaissance, command execution, and maintaining C2 communication. It should be noted that the default implementation of Metasploit has built-in support for exploits that attackers use for initial access. The other three frameworks, in their standard configurations, only support privilege escalation and persistence exploits in a compromised system and require additional customization tailored to the attackers’ objectives. The remaining tools don’t work with exploits directly and were modified for specific exploits in real-world attacks. We can therefore conclude that attackers are increasingly customizing their C2 agents to automate malicious activities and hinder detection.

After reviewing open sources and analyzing malicious C2 agent samples that contained exploits, we found that the following vulnerabilities were used in APT attacks involving the C2 frameworks mentioned above:

• CVE-2025-31324: a vulnerability in SAP NetWeaver Visual Composer Metadata Uploader that allows for remote code execution and has a CVSS score of 10.0
• CVE-2024-1709: a vulnerability in ConnectWise ScreenConnect 23.9.7 that can lead to authentication bypass, also with a CVSS score of 10.0
• CVE-2024-31839: a cross-site scripting vulnerability in the CHAOS v5.0.1 remote administration tool, leading to privilege escalation
• CVE-2024-30850: an arbitrary code execution vulnerability in CHAOS v5.0.1 that allows for authentication bypass
• CVE-2025-33053: a vulnerability caused by improper handling of working directory parameters for LNK files in Windows, leading to remote code execution

Interestingly, most of the data about attacks on systems is lost by the time an investigation begins. However, the list of exploited vulnerabilities reveals various approaches to the vulnerability–C2 combination, offering insight into the attack’s progression and helping identify the initial access vector. By analyzing the exploited vulnerabilities, incident investigations can determine that, in some cases, attacks unfold immediately upon exploit execution, while in others, attackers first obtain credentials or system access and only then deploy command and control.

Interesting vulnerabilities

This section covers the most noteworthy vulnerabilities published in Q2 2025.

CVE-2025-32433: vulnerability in the SSH server, part of the Erlang/OTP framework

This remote code execution vulnerability can be considered quite straightforward. The attacker needs to send a command execution request, and the server will run it without performing any checks – even if the user is unauthenticated. The vulnerability occurs during the processing of messages transmitted via the SSH protocol when using packages for Erlang/OTP.

CVE-2025-6218: directory traversal vulnerability in WinRAR

This vulnerability is similar to the well-known CVE-2023-38831: both target WinRAR and can be exploited through user interaction with the GUI. Vulnerabilities involving archives aren’t new and are typically exploited in web applications, which often use archives as the primary format for data transfer. These archives are processed by web application libraries that may lack checks for extraction limits. Typical scenarios for exploiting such vulnerabilities include replacing standard operating system configurations and setting additional values to launch existing applications. This can lead to the execution of malicious commands, either with a delay or upon the next OS boot or application startup.

To exploit such vulnerabilities, attackers need to determine the location of the directory to modify, as each system has a unique file layout. Additionally, the process is complicated by the need to select the correct characters when specifying the extraction path. By using specific combinations of special characters, archive extraction outside of the working directory can bypass security mechanisms, which is the essence of CVE-2025-6218. A PoC for this vulnerability appeared rather quickly.

Hex dump of the PoC file for CVE-2025-6218

As seen in the file dump, the archive extraction path is altered not due to its complex structure, but by using a relative path without specifying a drive letter. As we mentioned above, a custom file organization on the system makes such an exploit unstable. This means attackers will have to use more sophisticated social engineering methods to attack a user.

CVE-2025-3052: insecure data access vulnerability in NVRAM, allowing bypass of UEFI signature checks

UEFI vulnerabilities almost always aim to disable the Secure Boot protocol, which is designed to protect the operating system’s boot process from rootkits and bootkits. CVE-2025-3052 is no exception.

Researchers were able to find a set of vulnerable UEFI applications in which a function located at offset 0xf7a0 uses the contents of a global non-volatile random-access memory (NVRAM) variable without validation. The vulnerable function incorrectly processes and can modify the data specified in the variable. This allows an attacker to overwrite Secure Boot settings and load any modules into the system – even those that are unsigned and haven’t been validated.

CVE-2025-49113: insecure deserialization vulnerability in Roundcube Webmail

This vulnerability highlights a classic software problem: the insecure handling of serialized objects. It can only be exploited after successful authentication, and the exploit is possible during an active user session. To carry out the attack, a malicious actor must first obtain a legitimate account and then use it to access the vulnerable code, which lies in the lack of validation for the _from parameter.

Post-authentication exploitation is quite simple: a serialized PHP object in text format is placed in the vulnerable parameter for the attack. It’s worth noting that an object injected in this way is easy to restore for subsequent analysis. For instance, in a PoC published online, the payload creates a file named “pwned” in /tmp.

Example of a payload published online

According to the researcher who discovered the vulnerability, the defective code had been used in the project for 10 years.

CVE-2025-1533: stack overflow vulnerability in the AsIO3.sys driver

This vulnerability was exploitable due to an error in the design of kernel pool parameters. When implementing access rights checks for the AsIO3.sys driver, developers incorrectly calculated the amount of memory needed to store the path to the file requesting access to the driver. If a path longer than 256 characters is created, the system will crash with a “blue screen of death” (BSOD). However, in modern versions of NTFS, the path length limit is not 256 but 32,767 characters. This vulnerability demonstrates the importance of a thorough study of documentation: it not only helps to clearly understand how a particular Windows subsystem operates but also impacts development efficiency.

Conclusion and advice

The number of vulnerabilities continues to grow in 2025. In Q2, we observed a positive trend in the registration of new CVE IDs. To protect systems, it’s critical to regularly prioritize the patching of known vulnerabilities and use software capable of mitigating post-exploitation damage. Furthermore, one way to address the consequences of exploitation is to find and neutralize C2 framework agents that attackers may use on a compromised system.

To secure infrastructure, it’s necessary to continuously monitor its state, particularly by ensuring thorough perimeter monitoring.

Special attention should be paid to endpoint protection. A reliable solution for detecting and blocking malware will ensure the security of corporate devices.

Beyond basic protection, corporate infrastructures need to implement a flexible and effective system that allows for the rapid installation of security patches, as well as the configuration and automation of patch management. It’s also important to constantly track active threats and proactively implement measures to strengthen security, including mitigating risks associated with vulnerabilities. Our Kaspersky Next product line helps to detect and analyze vulnerabilities in the infrastructure in a timely manner for companies of all sizes. Moreover, these modern comprehensive solutions also combine the collection and analysis of security event data from all sources, incident response scenarios, an up-to-date database of cyberattacks, and training programs to improve the level of employees’ cybersecurity awareness.

securelist.com/vulnerabilities…

Some readers may recall the Lynx-R1 headset — it was conceived as an Android virtual reality (VR) and mixed reality (MR) headset with built-in hand tracking, designed to be open where others were closed, allowing developers and users access to inner workings in defiance of walled gardens. It looked very promising, with features rivaling (or surpassing) those of its contemporaries.

Founder [Stan Larroque] recently announced that Lynx’s 6DoF SLAM (simultaneous location and mapping) solution has been released as open source. ORB-SLAM3 (GitHub repository) takes in camera images and outputs a 6DoF pose, and does so effectively in real-time. The repository contains some added details as well as a demo application that can run on the Lynx-R1 headset.
The unusual optics are memorable. (Hands-on Lynx-R1 by Antony Vitillo)
As a headset the Lynx-R1 had a number of intriguing elements. The unusual optics, the flip-up design, and built-in hand tracking were impressive for its time, as was the high-quality mixed reality pass-through. That last feature refers to the headset using its external cameras as inputs to let the user see the real world, but with the ability to have virtual elements displayed and apparently anchored to real-world locations. Doing this depends heavily on the headset being able to track its position in the real world with both high accuracy and low latency, and this is what ORB-SLAM3 provides.

A successful crowdfunding campaign for the Lynx-R1 in 2021 showed that a significant number of people were on board with what Lynx was offering, but developing brand new consumer hardware is a challenging road for many reasons unrelated to developing the actual thing. There was a hands-on at a trade show in 2021 and units were originally intended to ship out in 2022, but sadly that didn’t happen. Units still occasionally trickle out to backers and pre-orders according to the unofficial Discord, but it’s safe to say things didn’t really go as planned for the R1.

It remains a genuinely noteworthy piece of hardware, especially considering it was not a product of one of the tech giants. If we manage to get our hands on one of them, we’ll certainly give you a good look at it.

hackaday.com/2025/08/27/lynx-r…

Una vulnerabilità critica nella versione desktop di Docker per Windows e macOS ha consentito la compromissione di un sistema host tramite l’esecuzione di un contenitore dannoso, anche se era abilitata la protezione Enhanced Container Isolation (ECI).

Alla vulnerabilità è stato assegnato l’identificatoreCVE-2025-9074 (9,3 punti sulla scala CVSS) ed è un bug SSRF (server-side request forgery). Il problema è stato risolto nella versione 4.44.3.

“Un container dannoso in esecuzione in Docker Desktop potrebbe accedere al Docker Engine e avviare container aggiuntivi senza dover montare un socket Docker”, spiegano gli sviluppatori di Docker in un bollettino di sicurezza . “Ciò potrebbe portare ad accessi non autorizzati ai file utente sul sistema host. L’Enhanced Container Isolation (ECI) non protegge da questa vulnerabilità.”

Lo specialista della sicurezza Felix Boulet, che ha scoperto la vulnerabilità, ha affermato che era possibile contattare l’API Docker Engine senza autenticazione utilizzando l’indirizzo 192.168.65[.]7:2375/ dall’interno di qualsiasi container in esecuzione.

L’esperto ha dimostrato la creazione e l’avvio di un nuovo contenitore che associa l’unità C: di un host Windows al file system del contenitore utilizzando due richieste HTTP POST wget. L’exploit proof-of-concept di Boulet non richiede autorizzazioni per eseguire codice all’interno del contenitore.

Philippe Dugre, ingegnere DevSecOps presso Pvotal Technologies e progettista della sfida per la conferenza sulla sicurezza NorthSec, ha confermato che la vulnerabilità riguarda la versione desktop di Docker per Windows e macOS, ma non quella per Linux.

Secondo Dugre, la vulnerabilità è meno pericolosa su macOS grazie ai meccanismi di protezione del sistema operativo. Ad esempio, è stato in grado di creare un file nella directory home dell’utente Windows, ma questo non è possibile su macOS senza l’autorizzazione dell’utente.

“Su Windows, poiché Docker Engine funziona tramite WSL2, un aggressore può montare l’intero file system come root, leggere qualsiasi file e infine sovrascrivere una DLL di sistema per elevare i privilegi al livello root del sistema host”, scrive Dugre. “Tuttavia, su macOS, l’app Docker Desktop mantiene comunque un certo livello di isolamento e il tentativo di montare una directory utente richiede all’utente l’autorizzazione. Per impostazione predefinita, l’app non ha accesso al resto del file system e non viene eseguita con privilegi di root, quindi l’host è più sicuro rispetto a Windows.”

Il ricercatore ha osservato che anche su macOS sono possibili attività dannose, poiché l’aggressore ha il controllo completo sull’applicazione e sui container, il che comporta il rischio di creare backdoor o di modificare la configurazione senza autorizzazione.

L'articolo Vulnerabilità critica in Docker Desktop: compromissione sistema host proviene da il blog della sicurezza informatica.

Finalmente (detto metaforicamente), ci siamo arrivati. Gli esperti di ESET hanno segnalato il primo programma ransomware in cui l’intelligenza artificiale gioca un ruolo chiave.

Il nuovo campione è stato chiamato PromptLock. È scritto in Go e utilizza il modello locale gpt-oss:20b di OpenAI tramite l’interfaccia Ollama per generare script Lua dannosi in tempo reale.

Gli script vengono eseguiti direttamente sul dispositivo e consentono al programma di elencare i file sul disco, analizzarne il contenuto, scaricare i dati selezionati e crittografarli. Il codice funziona in egual modo su Windows, Linux e macOS, il che rende la minaccia multipiattaforma.

Secondo l’idea dell’autore, il malware non solo può copiare o crittografare le informazioni, ma anche distruggerle completamente, sebbene la funzionalità di distruzione non sia ancora stata implementata.

Nei prompt generati, i ricercatori hanno trovato un indirizzo di portafoglio Bitcoin associato all’identità di Satoshi Nakamoto, il che alimenta ulteriormente l’interesse per il campione.

L’algoritmo SPECK con una chiave a 128 bit viene utilizzato come meccanismo di crittografia dei file. Questa scelta indica la natura sperimentale dello sviluppo piuttosto che uno strumento pronto per attacchi su larga scala.

Gli esperti sottolineano che finora tutti gli indizi indicano un prototipo o una versione demo: le copie trovate per Windows e Linux sono state caricate su VirusTotal, ma non ci sono dati sulla distribuzione di massa.

Ciononostante, il fatto che venga utilizzato un modello generativo per creare dinamicamente codice dannoso rende la minaccia fondamentalmente nuova e degna dell’attenzione della comunità professionale.

ESET ha classificato il programma come Filecoder.PromptLock.A e sottolinea che, anche allo stato di concept, tali progetti aprono la strada all’emergere di una nuova generazione di ransomware.

L'articolo Arriva PromptLock. Il primo Ransomware con Intelligenza Artificiale per Windows e Linux proviene da il blog della sicurezza informatica.

ESET Research

2025-08-26 15:36:21

#ESETResearch has discovered the first known AI-powered ransomware, which we named #PromptLock. The PromptLock malware uses the gpt-oss:20b model from OpenAI locally via the Ollama API to generate malicious Lua scripts on the fly, which it then executes.
PromptLock leverages Lua scripts generated from hard-coded prompts to enumerate the local filesystem, inspect target files, exfiltrate selected data, and perform encryption. These Lua scripts are cross-platform compatible, functioning on #Windows, #Linux, and #macOS.
Based on the detected user files, the malware may exfiltrate data, encrypt it, or potentially destroy it. Although the destruction functionality appears to be not yet implemented. #Bitcoin address used in the prompt appears to belong to Bitcoin creator en.wikipedia.org/wiki/Satoshi_…
For its file encryption mechanism, the PromptLock ransomware utilizes the SPECK 128-bit encryption algorithm.
Although multiple indicators suggest the sample is a proof-of-concept (PoC) or work-in-progress rather than fully operational malware deployed in the wild, we believe it is our responsibility to inform the cybersecurity community about such developments.
The PromptLock ransomware is written in #Golang, and we have identified both Windows and Linux variants uploaded to VirusTotal. IoCs:
🚨 Filecoder.PromptLock.A
📄 24BF7B72F54AA5B93C6681B4F69E579A47D7C102
AD223FE2BB4563446AEE5227357BBFDC8ADA3797
BB8FB75285BCD151132A3287F2786D4D91DA58B8
F3F4C40C344695388E10CBF29DDB18EF3B61F7EF
639DBC9B365096D6347142FCAE64725BD9F73270
161CDCDB46FB8A348AEC609A86FF5823752065D2

pseudonym for the person or group who designed and developed Bitcoin

^{Contributors to Wikimedia projects (Wikimedia Foundation, Inc.)}

E’ stata condotta una campagna sofisticata per esfiltrare dati mirata alle istanze Salesforce delle aziende, la quale ha portato all’esposizione di informazioni sensibili di varie organizzazioni. Ciò è avvenuto attraverso token OAuth compromessi, associati all’applicazione di terze parti Salesloft Drift.

Il threat actor, identificato come UNC6395, ha raccolto credenziali e dati sensibili nel periodo compreso tra l’8 e il 18 agosto 2025. Questo ha dimostrato una notevole conoscenza delle procedure di sicurezza operative, in quanto sono state eseguite query SOQL su diversi oggetti Salesforce.

UNC6395 ha eseguito query SOQL (Salesforce Object Query Language) sistematiche per enumerare ed estrarre dati da oggetti Salesforce critici, tra cui casi, account, utenti e opportunità. La segnalazione arriva da Google Threat Intelligence Group che l’autore della minaccia ha utilizzato token di accesso OAuth compromessi e token di aggiornamento dall’applicazione Salesloft Drift per autenticarsi sulle istanze Salesforce di destinazione.

Salesloft ha affermato che l’aggressore ha preso di mira specificamente le chiavi di accesso AWS (identificatori AKIA), le password, le credenziali Snowflake e altri materiali di autenticazione sensibili archiviati nei campi personalizzati e negli oggetti standard di Salesforce.

UNC6395 sfruttava meccanismi di autenticazione OAuth legittimi per ottenere l’accesso non autorizzato, aggirando i controlli di sicurezza tradizionali e rendendo il rilevamento particolarmente difficile per le organizzazioni interessate.

Salesforce e Salesloft hanno risposto revocando tutti i token OAuth attivi associati all’applicazione Drift il 20 agosto 2025, interrompendo di fatto il vettore di attacco. L’analisi post-esfiltrazione ha rivelato che l’attore ha cercato nei dati estratti modelli corrispondenti ai formati delle credenziali, indicando un obiettivo primario della raccolta delle credenziali piuttosto che del tradizionale furto di dati.

Questo vettore di attacco sfrutta il framework di autorizzazione OAuth 2.0, il quale consente alle applicazioni di terze parti di accedere ai dati Salesforce senza esporre direttamente le credenziali dell’utente. L’attore ha dimostrato una certa sofisticatezza tecnica eseguendo query COUNT per valutare i volumi di dati prima dell’esfiltrazione:

L’applicazione Drift è stata successivamente rimossa da Salesforce AppExchange in attesa di una revisione completa della sicurezza

L'articolo Una campagna di UNC6395 mira all’esfiltrazione dei dati Salesforce tramite token OAuth compromessi proviene da il blog della sicurezza informatica.

Una sintesi essenziale del principio che si può estrarre dal provv. n. 271 del 29 aprile 2025 dell’Autorità Garante per la protezione dei dati personali potrebbe essere: no budget? non parti! Ovviamente con il trattamento, perché per andare in vacanza o in altri luoghi (che è bene non precisare) c’è sempre tempo.

Per capire meglio questo principio di carattere generale e la sua applicazione pratica, bisogna unzippare il provvedimento che inizia con un data breach e (spoiler!) si conclude con una sanzione di 30 mila euro “per la molteplice violazione degli artt. 5, par. 1, lett. f), e 32, par. 1, del Regolamento”.

Ovverosia, rispettivamente, il principio di integrità e riservatezza:

dati sono: (…) trattati in maniera da garantire un’adeguata sicurezza dei dati personali, compresa la protezione, mediante misure tecniche e organizzative adeguate, da trattamenti non autorizzati o illeciti e dalla perdita, dalla distruzione o dal danno accidentali.

e l’obbligo generale in capo a titolari e responsabili di predisporre misure di sicurezza adeguate al rischio:

Tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche, il titolare del trattamento e il responsabile del trattamento mettono in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio (…).

Come detto, il fatto che ha portato all’apertura dell’istruttoria è stato un evento di violazione dei dati personali, o data breach, che è stato notificato al Garante Privacy come prescritto dall’art. 33 GDPR e che è consistito in un attacco ransomware con esfiltrazione e pubblicazione dei dati.

In seguito alla richiesta di informazioni, contrariamente a quanto affermato all’interno delle difese, è stato però accertata la mancata adozione di misure adeguate a rilevare le violazioni dei dati personali nonostante l’adozione delle misure indicate come “standard” all’interno della Circolare AgID. Nello specifico, non era stata implementata un’attività di monitoraggio delle anomalie su accessi e operazioni, né un sistema di alert. Il tutto, motivato dalla carenza di personale e budget limitato.

Motivazioni che però non hanno superato le contestazioni del Garante Privacy.

L’unica certezza è che se c’è un data breach, qualcosa non ha funzionato.

Quando c’è una violazione di sicurezza, qualcosa non ha funzionato. Contrariamente a quanto prospettato all’interno delle difese, l’attacco “particolarmente sofisticato ed elusivo” in quanto l’esfiltrazione di dati è avvenuta progressivamente nel tempo in orario notturno e giorni festivi senza superare la soglia media di traffico, il Garante ha ritenuto invece che un sistema di alert avrebbe ben potuto consentire di rilevare questi eventi di sicurezza:

Tali meccanismi automatici, ove opportunamente configurati e presidiati, consentono, infatti, di rilevare eventi che, proprio per le particolari accortezze impiegate dagli attaccanti, possono sfuggire al controllo umano, mettendo in rilevo determinati eventi (es. traffico in orario notturno o in giorni festivi, in giorni in cui non sono previsti interventi di manutenzione programmati) ancorché non significativi sul piano statistico (es. traffico in linea con la soglia di traffico medio giornaliero).

Per quanto infatti in un’istruttoria ci possa essere il terribile pericolo di un post hoc ergo propter hoc, ovverosia assumere che un evento successivo (data breach) sia stato causato dal precedente (inadeguatezza delle misure di sicurezza), ciò che è al centro della scena sono gli aspetti di gestione. Partendo dal fatto innegabile che se c’è stata una violazione di sicurezza qualcosa non ha funzionato, l’istruttoria ricostruisce le responsabilità in concreto del titolare. Che in questi casi riguardano, ad esempio, l’analisi dei rischi e la predisposizione di misure di mitigazione. E no, nella maggior parte dei casi non si può parlare di eventi che siano assolutamente imprevedibili né inevitabili. Quei rari cigni neri della cybersecurity sono talmente autoevidenti da non richiedere alcuna spiegazione a riguardo. Semmai sono eventi indesiderati, soprattutto per gli interessati.

Fra i requisiti del GDPR c’è infatti la corretta gestione della sicurezza, per cui si deve tenere conto dello stato dell’arte e dei costi di attuazione. Attenzione, però: questo non significa poter diminuire in alcun modo il livello di sicurezza, ma al contrario impone un ragionamento continuo che comporti anche il verificare che le misure adottate siano efficaci nel mitigare i rischi derivanti dai trattamenti. Anzi: il parametro del costo rappresenta un fattore di cui tenere conto per selezionare misure alternative e di pari efficacia, in un’ottica di semplificazione e ottimizzazione. In alcun modo può essere una scusa o giustificare l’inazione, perché è responsabilità del titolare mettere a budget la sicurezza nella gestione complessiva dei costi.

Lo stato dell’arte, in quanto concetto intrinsecamente dinamico, segue i progressi tecnologici, richiamando così l’attenzione sull’essere informati su opportunità e rischi nonché sull’aggiornare le misure in modo tale che siano in grado di fronteggiare le minacce emergenti. Ovviamente, secondo le conoscenze e i mezzi disponibili sul mercato.

Questo significa che adottare alcune misure minime, come quelle AgID, può non essere sufficiente.

Come è accaduto in questo caso. Sia dal punto di vista della realtà dei fatti, che per quanto riguarda gli aspetti sanzionatori.

Le misure “a catalogo” non bastano.

In realtà le misure minime non sono mai bastate, neanche in vigenza del Codice Privacy e dell’art. 33 che contemplava delle misure minime, dal momento che comunque l’art. 31 prevedeva:

I dati personali oggetto di trattamento sono custoditi e controllati, anche in relazione alle conoscenze acquisite in base al progresso tecnico, alla natura dei dati e alle specifiche caratteristiche del trattamento, in modo da ridurre al minimo, mediante l’adozione di idonee e preventive misure di sicurezza, i rischi di distruzione o perdita, anche accidentale, dei dati stessi, di accesso non autorizzato o di trattamento non consentito o non conforme alle finalità della raccolta

Ciononostante, il catalogo delle misure indicate da AgID come di livello “standard” (Circolare n. 2/2017 del 18 aprile 2017, “misure minime di sicurezza ICT per le pubbliche amministrazioni”), pur adottate, rappresentano solo una soglia minima di adempimento a cui devono essere aggiunte, se del caso, misure ulteriori.

Insomma: sono misure necessarie ma non sufficienti a dimostrare una gestione adeguata della sicurezza. Quindi, da sole non garantiscono il rispetto degli obblighi di sicurezza dal momento che sono state scritte per fornire indicazioni di carattere generale e diffuso per assicurare un minimo livello di protezione nella maggior parte delle situazioni (con l’indicazione di individuarne di più specifiche e adatte a raggiungere gli obiettivi di sicurezza di ciascuna PA), peraltro risalenti allo stato dell’arte vigente al momento della loro emanazione: fanno infatti riferimento a criteri di controllo del 2015, non sono state aggiornate e hanno skippato alla grande quel piccolo cambio di scenario dovuto a pandemia e guerra ibrida.

Il Garante Privacy conferma così l’esigenza di svolgere un’analisi dei rischi ed aggiornarla, potendo ben prendere come riferimento delle misure “a catalogo” senza però indulgere troppo nella convinzione che possano essere scollegate dal contesto o realizzino un “sempre e per sempre”.

Altrimenti, sarà una favola senza lieto fine.

E non c’è scusa di budget che tenga.

L'articolo Garante Privacy: non si scherza sul budget per la sicurezza dei dati personali. proviene da il blog della sicurezza informatica.