How #Russia exposes… Russia’s own lies, episode 524. Yesterday, Russian media reported on an attack by Ukrainian drones on a café in Khorly in the occupied #Kherson region, where allegedly ‘24 civilians celebrating the New Year’ were killed.

The case was soon commented on by… Russian humanitarian volunteer Sania Denisova. And she knows what she is talking about, because for many months she has been appealing to Putin about the abuses of the Russian army… in that very Khorly.

According to her past publications, the town is 100% controlled by the army, which is looting the homes of residents, most of whom have been forced to leave. Those who remain are intimidated and stay at home. If anyone was celebrating in that café, it was certainly not civilians, Denisova concludes.

The tragedy that occurred in Khorly, Kherson Oblast, was to be expected. I wrote about this in detail earlier — about the system of raiding, intimidation and complete lawlessness that the former and current ‘owners’ of the village had established there.

I spoke about this in August, shared the information at a forum in September and reiterated it in Moscow in December. The outcome was predictable: it could not end well. Therefore, reading about the tragedy now, I do not believe that the local residents were celebrating anything during those days. They were surviving it.

But the complete lack of response and control on the part of the security forces is a lesson that must be learned. It is high time for the security forces to pay close attention to what is happening in Khorly.

While people are being driven out of their homes in Khorly, while fear and lawlessness reign there, what kind of celebration can we talk about?

I won’t translate all the screenshots as their purpose is primarily to archive Denisova’s posts which may soon disappear. Her original post is still available here in Russian: t.me/ssaniaworld/3733

66 anni e ancora imbattibile: come il COBOL domina silenziosamente il mondo bancario

Mentre il settore dibatte su quale rete neurale sia la “più intelligente” e quale framework sia il “più moderno”, tecnologie vecchie di decenni continuano a turbinare silenziosamente sotto la superficie del settore bancario.

Quest’anno, COBOL ha compiuto 66 anni e continua a supportare attività mission-critical: elaborazione delle fatture, gestione delle reti bancomat, compensazione delle carte di credito e liquidazione batch notturna. Dove COBOL risiede, si trovano tipicamente anche i mainframe: in banche, compagnie assicurative, sistemi governativi e grandi sistemi di contabilità e magazzino.

Ciò ha portato a una semplice domanda: quali tecnologie funzioneranno probabilmente tra 50 anni e oltre, anche se tutto intorno a noi cambiasse più volte? È importante considerare che il Cobol è cambiato nel tempo: l’attuale standard COBOL 2023 assomiglia poco alle prime versioni del linguaggio che Grace Hopper ha contribuito a creare, e i mainframe moderni hanno fatto molta strada dai primi sistemi IBM 701 e IBM/360. Ma la continuità rimane; sono le implementazioni a cambiare, non il percorso di sviluppo in sé.

Tra i linguaggi di programmazione, il C, che ha più di mezzo secolo, è un candidato promettente per la longevità. Pur avendo i suoi problemi di sicurezza , rimane estremamente valido in termini di velocità e versatilità: il C può essere utilizzato praticamente su qualsiasi architettura e in qualsiasi attività di basso livello.

Mentre si parla di Rust che sta gradualmente sostituendo il C nella programmazione di sistema, vale la pena ricordare che Rust è già arrivato su Linux, ma i principali punti di forza del C – velocità e portabilità – non sono scomparsi.

Un altro pilastro “indistruttibile” è SQL. È integrato in tutti i principali DBMS relazionali, accumulando enormi quantità di logica di business, stored procedure e query, rendendo praticamente impossibile sostituirli tutti in una volta. JavaScript e TypeScript sono una storia simile: sono spesso criticati e derisi, ma la piattaforma web si basa sulla compatibilità, il che significa che il linguaggio del browser rimarrà rilevante finché il web stesso sopravviverà.

Un livello separato di tecnologie longeve è associato non ai linguaggi, ma agli ecosistemi. Linux esisterà ancora nel 2100 e Git rimarrà lo strumento di sviluppo di base per molto tempo a venire. Sorprendentemente, accanto a loro ci sono gli editor “eterni” vi ed Emacs, così come Bash, che ha superato molti concorrenti e, per inerzia, continua a essere lo strumento standard in molti scenari.

Tra le soluzioni infrastrutturali più recenti, ma già consolidate, vale la pena sottolineare Kubernetes . Ha ricevuto la sua giusta dose di critiche, ma oggi è lo standard de facto per l’orchestrazione dei container cloud e il fondamento dell’approccio “cloud-native”, quindi l’inerzia del mercato è dalla sua parte. Nel mondo applicativo, Photoshop ha alte probabilità di rimanere valido: anche con alternative, l’ecosistema e le abitudini dei professionisti spesso prevalgono sulle argomentazioni ideologiche.

La parte più dolorosa del dibattito riguarda i formati di file. Una volta che un formato diventa uno standard industriale, persiste per anni e decenni, anche se esiste un sostituto più aperto e pratico. Esempi includono DOC e DOCX, che hanno soppiantato approcci più aperti, e PDF , apprezzato per il suo aspetto coerente dei documenti “ovunque e sempre”, ma che in pratica si scontra con una moltitudine di varianti e incompatibilità. Un esempio significativo proviene dall’industria musicale: dopo che un popolare standard di notazione proprietario è stato di fatto abbandonato, gli utenti hanno scoperto che migrare il lavoro accumulato verso altre soluzioni era estremamente difficile, e a volte impossibile, senza perdite.

La conclusione finale è semplice: gli standard aperti e il software open source hanno maggiori probabilità di sopravvivere per decenni, mentre le tecnologie legate a una singola azienda sono intrinsecamente fragili, anche se oggi sembrano “troppo grandi per fallire”.

L'articolo 66 anni e ancora imbattibile: come il COBOL domina silenziosamente il mondo bancario proviene da Red Hot Cyber.

Perché il DPO non può più essere un lupo solitario (e rischi di far fallire il GDPR)

Quando si parla della funzione del DPO è possibile escludere la possibilità di fare gioco di squadra, celebrando una sorte di one-person-band. Quando invece ci si trova a dover esercitare in modo sensato la funzione, allora è necessario ragionare su come fare gioco di squadra. Al di là dell’ovvia ricerca di sinergie con le ulteriori funzioni esterne o interne dell’organizzazione, è fondamentale infatti che venga garantita la capacità di svolgere i compiti attribuiti dall’art. 39 GDPR e, soprattutto, garantire la continuità della sorveglianza. Questo può comportare o lo stanziamento di risorse adeguato per coinvolgere altri professionisti o garantire alcuni collaboratori, o altrimenti la formazione di un team DPO.

Mentre il primo caso rientra nell’ambito dell’adeguatezza dello stanziamento di risorse che l’organizzazione deve fornire a supporto del DPO ai sensi dell’art. 38 par. 2 GDPR, nel secondo caso è invece chi si propone come DPO a dover fornire le evidenze necessarie a dimostrare la capacità di assolvere i propri compiti, come previsto dall’art. 37 par. 5 GDPR. Ovviamente, in entrambi i casi la responsabilità di adempiere agli obblighi previsti dal GDPR è e resta in capo all’organizzazione che deve comunque essere in grado di garantire l’effettività della funzione a partire dalla selezione e per tutto lo svolgimento dell’incarico.

Mentre la dotazione di risorse in termini di collaboratori a supporto del DPO è rimesso alla capacità dell’organizzazione di rispettare il GDPR e alla libertà di cui al principio di accountability, la formazione e conduzione del team DPO incontra necessariamente le regole proprie della funzione che vanno riferite più ad un “Office” che ad un singolo “Officer”.

Best practices per il team DPO.

La formazione del team DPO è presa in considerazione all’interno delle linee guida WP243 sui responsabili della protezione dei dati, indicando delle buone pratiche sia per favorire un’organizzazione trasparente e corretta sia per prevenire conflitti d’interesse. Ad esempio, è necessario non solo che ciascun componente del team possieda i requisiti per ricoprire l’incarico, ma che goda anche delle tutele previste dal GDPR fra cui principalmente quella dell’indipendenza funzionale prevista dall’art. 38 par. 3 GDPR.

Sul piano organizzativo, la ripartizione interna dei compiti è funzionale non solo per garantire l’efficienza del servizio ma anche per individuare un unico soggetto che faccia da referente per i vertici dell’organizzazione. Motivo per cui diventa opportuno dettagliare questo ambito all’interno del contratto di servizi (se esterno) o altrimenti nella descrizione del funzionamento dell’ufficio (se interno).

Quando il gioco di squadra è trasversale.

Ultimo ma non meno importante è l’aspetto invece del gioco di squadra fra DPO di diverse organizzazioni, il più delle volte nel rapporto titolare-responsabile (ma anche: fra contitolari, o titolari differenti). Poiché ciascun DPO svolge i propri compiti secondo un approccio risk-based nei confronti degli interessati, e gli interessati sono il comune denominatore dei trattamenti svolti fra questi soggetti differenti, è quanto mai opportuno – e invero, il più delle volte dimenticato – che si cooperi professionalmente in quanto si perseguono obiettivi se non proprio comuni quanto meno non divergenti: la garanzia della protezione dei dati personali degli interessati.

Questo comporta che nelle qualità personali espresse dallo svolgimento dei compiti sia riscontrabile anche quello spirito di leale collaborazione che invoca integrità e standard deontologici nel contribuire a dare efficace attuazione ai principi del GDPR e ai diritti degli interessati.

L'articolo Perché il DPO non può più essere un lupo solitario (e rischi di far fallire il GDPR) proviene da Red Hot Cyber.