Tag: Architettura degli elaboratori

Introduzione

Il presente articolo vuole fornire una panoramica strutturata dei fondamenti di informatica e reti di calcolatori, con un focus sull’applicazione pratica di tali conoscenze nel contesto della sicurezza informatica. Ciascuna sezione approfondisce un argomento chiave – dalla rappresentazione dei dati ai sistemi operativi, dalle basi di dati alle reti e protocolli – evidenziando i concetti teorici essenziali e collegandoli alle best practice per la prevenzione e gestione di incidenti informatici.

La trattazione è pensata per il responsabile della sicurezza informatica impegnato nella prevenzione e gestione di incidenti informatici.

Vengono inclusi esempi pratici, riferimenti a standard riconosciuti e citazioni da fonti autorevoli, il tutto organizzato in sezioni chiare per facilitare la consultazione e l’apprendimento.

Rappresentazione delle informazioni

Nella scienza dei calcolatori, rappresentare le informazioni significa tradurre qualsiasi tipo di dato (numeri, testo, immagini, audio, ecc.) in una forma binaria comprensibile e manipolabile dalle macchine digitali. In pratica, ogni informazione viene codificata come sequenze di bit (binary digits), ossia 0 e 1, che sono le unità elementari di dati. Un insieme di 8 bit forma un byte, che costituisce la minima unità indirizzabile di memoria. Usando sequenze di bit e byte, un computer può rappresentare qualsiasi tipo di contenuto: caratteri testuali, valori numerici, immagini, suoni, video, ecc. La conversione dei dati in sequenze di 0 e 1 prende il nome di codifica e risponde al requisito fondamentale per cui un computer elabora solo informazioni in formato binario.

Unità di misura e codifiche: poiché i bit da soli sarebbero poco maneggevoli, si utilizzano multipli come Kilobyte (KB), Megabyte (MB), Gigabyte (GB), tenendo presente che in informatica per ragioni storiche spesso 1 KB = 1024 byte (2^10) invece di 1000 (si parla più precisamente di Kibibyte). Sul versante delle codifiche, per rappresentare testi alfanumerici si impiegano sistemi standardizzati di mappatura tra numeri e caratteri. Uno dei più importanti è il codice ASCII, che associa a ogni simbolo (lettera, cifra, segno di punteggiatura, caratteri di controllo, ecc.) un valore numerico tra 0 e 127, rappresentabile con 7 bit. Ad esempio, il carattere ‘A’ in ASCII è codificato come 65 (in decimale), mentre ‘a’ è 97 e così via. Estensioni di ASCII utilizzano 8 bit (256 valori possibili) per supportare caratteri accentati e simboli aggiuntivi, sebbene queste estensioni non fossero unificate a livello internazionale. Oggi si utilizza ampiamente Unicode, un sistema di codifica che, nelle sue varianti come UTF-8 e UTF-16, può rappresentare decine di migliaia di caratteri (oltre i caratteri latini, anche alfabeti non latini, ideogrammi, emoji, ecc.). Unicode in UTF-8 è retro-compatibile con ASCII per i primi 128 valori e consente di codificare caratteri usando sequenze di 1-4 byte. Grazie a Unicode, applicazioni e sistemi possono gestire testi multilingue e simboli emoji in modo unificato.

Numeri e formati numerici: i numeri interi vengono rappresentati in binario utilizzando un certo numero di bit fissato (es. 32 bit o 64 bit). Per i numeri con segno (positivi/negativi) l’approccio più diffuso è la rappresentazione in complemento a due, in cui il bit più significativo indica il segno e l’operazione di inversione dei bit più aggiunta di 1 permette di ottenere il negativo di un valore.
Il complemento a due è lo schema standard adottato nei moderni calcolatori per i numeri interi con segno, poiché facilita la progettazione dei circuiti aritmetici (addizione e sottrazione possono essere eseguite con lo stesso circuito sommatorio). Ad esempio, con 8 bit si possono rappresentare gli interi da -128 a +127 in complemento a due. Per i numeri reali (con virgola decimale), si utilizza la rappresentazione in virgola mobile secondo lo standard IEEE 754, che definisce formati a 32 bit (precisione singola) e 64 bit (precisione doppia), tra gli altri. Questo standard specifica come suddividere i bit di un numero reale in segno, esponente e mantissa, permettendo di rappresentare un ampio intervallo di valori (inclusi zero, infiniti e valori NaN per indicare risultati non numerici). La conformità allo standard IEEE 754 garantisce che diversi processori e linguaggi interpretino i numeri in virgola mobile nello stesso modo, importante per la consistenza dei calcoli (ad esempio in crittografia o analisi scientifiche).

Rappresentazione di immagini, audio e altri dati: oltre a testo e numeri, i computer rappresentano anche dati multimediali in forma binaria. Un’immagine digitale ad esempio è modellata come una griglia di elementi chiamati pixel, ciascuno associato a valori binari che ne determinano il colore. In una immagine raster (bitmap), ogni pixel ha componenti di colore (ad esempio rosso, verde, blu in RGB) codificate tipicamente su 8 bit ciascuna, per un totale di 24 bit per pixel (True Color). Ciò significa che un singolo pixel può assumere circa 16,7 milioni di combinazioni di colore. Immagini con palette più ridotte possono usare meno bit per pixel (ad esempio 8 bit/pixel in modalità 256 colori). Allo stesso modo, un’immagine in bianco e nero può essere codificata con 1 bit per pixel (0 = bianco, 1 = nero), eventualmente con livelli di grigio se si usano più bit. Per i suoni, la rappresentazione avviene mediante campionamento: l’onda sonora analogica viene misurata (campionata) a intervalli regolari e ogni campione viene quantizzato in formato digitale (ad esempio, audio CD utilizza 44.100 campioni al secondo, ciascuno rappresentato da 16 bit per canale). Il risultato è una sequenza binaria che descrive l’andamento dell’audio nel tempo. Video e altri tipi di dati sono combinazioni o estensioni di questi principi (sequenze di immagini per il video, eventualmente compresse; flussi di campioni audio, ecc.), sempre riconducibili a stringhe di bit.

Implicazioni per la sicurezza informatica: la corretta comprensione della rappresentazione dei dati è fondamentale nella sicurezza informatica per diversi motivi. In primo luogo, molte vulnerabilità di basso livello (come buffer overflow o integer overflow) derivano da limiti nella rappresentazione binaria: ad esempio un intero a 32 bit ha un massimo e se un calcolo eccede quel massimo si verifica un overflow con possibili esiti imprevisti. Conoscere come i numeri sono codificati (complemento a due, IEEE 754 per i float, ecc.) aiuta a prevenire errori di programmazione sfruttabili da attaccanti. Inoltre, la rappresentazione binaria è alla base della crittografia: bit e byte vengono manipolati con operazioni booleane e aritmetiche per cifrare/decifrare informazioni. Un esperto di sicurezza deve conoscere, ad esempio, come lavorano gli algoritmi bit-a-bit e come interpretare dumps binari o esadecimali di file e pacchetti di rete durante un’analisi forense. Anche l’encoding dei caratteri è rilevante: attacchi come Unicode spoofing (ingannare sistemi di autenticazione usando caratteri Unicode simili a quelli latini) o bypass di filtri basati su codifiche differenti (ad esempio doppia codifica in attacchi XSS) sfruttano dettagli della rappresentazione dei testi. Infine, la capacità di tradurre rapidamente dati binari in forme comprensibili (come visualizzare un file eseguibile in esadecimale, o un indirizzo IP nella notazione dotted-decimal) è una competenza pratica quotidiana per chi gestisce incidenti: consente di identificare payload malevoli nascosti, firme di file e altri indicatori di compromissione.

Architettura degli elaboratori

Un elaboratore (computer) moderno si basa sul modello concettuale di architettura di von Neumann, che prevede la suddivisione in componenti fondamentali: una Unità Centrale di Elaborazione (CPU), una memoria centrale, dispositivi di input/output (I/O) e interconnessioni dette bus. In tale architettura, sia i dati che le istruzioni di un programma sono memorizzati nella medesima memoria e la CPU li preleva ed esegue sequenzialmente. Di seguito esaminiamo ciascun componente e le implicazioni relative alla sicurezza.

• CPU (Central Processing Unit): è il “cervello” del computer, responsabile dell’esecuzione delle istruzioni macchina. La CPU è internamente composta da un’unità di controllo (Control Unit, CU) che dirige l’esecuzione delle istruzioni, da un’unità aritmetico-logica (ALU) che effettua calcoli e operazioni logiche e da una serie di registri interni per l’immagazzinamento temporaneo di dati e indirizzi. La CPU esegue le istruzioni in un ciclo di fetch-decode-execute: preleva un’istruzione dalla memoria, la decodifica e la esegue, aggiornando eventualmente registri e memoria. Le istruzioni stesse costituiscono il cosiddetto linguaggio macchina specifico della famiglia di CPU in uso (ad esempio x86-64, ARMv8, etc.). La maggior parte delle CPU moderne supporta funzionalità come pipeling (esecuzione parallela sovrapposta di parti di istruzioni diverse) e multithreading (gestione di più flussi di istruzioni) per migliorare le prestazioni. Dal punto di vista della sicurezza, la CPU implementa meccanismi hardware essenziali, come i livelli di privilegio (es. modalità kernel vs user): le moderne CPU possono operare in almeno due modalità, in cui le istruzioni cosiddette privilegiate (che accedono a risorse critiche o configurazioni hardware) possono essere eseguite solo in modalità kernel (dove risiede il sistema operativo), ma non in modalità utente. Questo isolamento hardware garantisce che un programma in esecuzione applicativa non possa, ad esempio, modificare direttamente la memoria del kernel o interagire col dispositivo disco senza passare per il sistema operativo – prevenendo una vasta gamma di abusi. Tuttavia, sono noti attacchi (Meltdown, Spectre) che sfruttano caratteristiche delle CPU (esecuzione speculativa, branch prediction) per aggirare tali protezioni, sottolineando come l’architettura hardware sia anch’essa un fronte di sicurezza da curare.
• Memoria centrale: è il luogo in cui risiedono i programmi in esecuzione e i dati su cui operano. La memoria centrale (di solito RAM, Random Access Memory, volatile) contiene sia le istruzioni macchina caricate dal disco sia le strutture dati necessarie alle applicazioni. La caratteristica è l’accesso diretto rapido agli indirizzi di memoria (a differenza delle memorie di massa più lente). La memoria centrale memorizza sia i dati da elaborare (o già elaborati) sia le istruzioni eseguibili. Tipicamente è organizzata in una sequenza di celle indirizzabili (parole di memoria) tutte della stessa dimensione (es. 8 byte), ognuna identificata da un indirizzo numerico univoco. La memoria è spesso distinta in RAM (lettura/scrittura, volatile) e ROM/EPROM (Read-Only Memory, memorie non volatili contenenti ad esempio il firmware di bootstrap). Un aspetto cruciale dell’architettura è la gerarchia di memoria: piccole memorie velocissime (registri nella CPU, cache L1/L2/L3) mitigano la differenza di velocità tra CPU e RAM; più in basso vi sono memorie di massa (SSD, HDD) e archivi esterni. Ai fini della sicurezza, la gestione della memoria è un terreno fertile di vulnerabilità: buffer overflow (scrittura oltre i limiti di un buffer), use-afterfree (uso di memoria già deallocata) e memory corruption in genere sono alla radice di exploit. Negli ultimi decenni, sono stati introdotti contromisure hardware come il bit NX (No-eXecute, che marca le pagine di memoria dati come non eseguibili per prevenire l’iniezione di shellcode) e tecniche come ASLR (Address Space Layout Randomization, implementata a livello di sistema operativo ma dipendente dal supporto CPU per la segmentazione/paginazione) per rendere più difficile sfruttare i bug di memoria. Un responsabile alla sicurezza deve comprendere come funzionano queste protezioni hardware/memory e i limiti che possono avere, per esempio sapere che buffer overflow su architetture moderne possono essere mitigati ma non eliminati (es. return-oriented programming è nato proprio come tecnica per bypassare NX-bit e ASLR sfruttando frammenti di codice legittimo in memoria).
• Bus e dispositivi I/O: i vari componenti sono collegati da bus di sistema (insieme di linee di comunicazione). Esistono tipicamente bus separati o logici distinti per indirizzi, dati e controllo, che coordinano il flusso delle informazioni tra CPU, memoria e periferiche. Le periferiche di I/O (dispositivi di input/output come tastiera, mouse, schermo, disco, scheda di rete, ecc.) interagiscono col processore attraverso controller specifici collegati sul bus. Da una prospettiva di sicurezza, i dispositivi I/O possono rappresentare vettori di attacco se non gestiti correttamente: ad esempio, dispositivi esterni USB possono iniettare comandi (si pensi a Rubber Ducky che si presenta come tastiera HID); le schede di rete possono essere bersaglio di DMA attacks (accesso diretto alla memoria) se l’IOMMU non isola adeguatamente le periferiche. Inoltre, dal bus passano anche dati sensibili (ad esempio password digitate da tastiera o chiavi crittografiche in RAM) e attacchi di tipo side-channel hanno dimostrato che è possibile captare informazioni sul bus o analizzare i tempi di risposta del sistema per dedurre segreti.

Set di istruzioni e architetture: ogni CPU implementa un Instruction Set Architecture (ISA), l’insieme di istruzioni macchina che è in grado di eseguire. Architetture diverse (x86, ARM, MIPS, RISC-V, ecc.) hanno ISA differenti e anche modalità operative differenti (32-bit, 64-bit, little endian vs big endian nell’ordinamento dei byte in memoria, ecc.). Nello sviluppo di exploit o nella risposta a incidenti, è spesso necessario comprendere l’architettura bersaglio: ad esempio, malware scritto per ARM non girerà su un server x86 a meno di emulazione e viceversa. Inoltre, la sicurezza del software è strettamente legata all’architettura: un binario compilato per x86-64 con protezioni come stack canaries (canarini sullo stack) e Control Flow Guard sfrutta funzionalità specifiche dell’ISA e del compilatore; un analista deve sapere come riconoscerle ed eventualmente disattivarle in ambiente controllato per effettuare reverse engineering. Parimenti, alcune istruzioni privilegiate (come la gestione della tabella delle pagine di memoria) sono sfruttate nei rootkit in modalità kernel: conoscere il funzionamento interno della MMU (Memory Management Unit) e delle istruzioni correlate può aiutare a individuare manipolazioni malevole a basso livello.

In sintesi, l’architettura degli elaboratori fornisce il substrato hardware su cui operano i sistemi software. Un responsabile della sicurezza informatica deve padroneggiare almeno i concetti fondamentali (ciclo macchina, gestione memoria, modelli architetturali) per comprendere sia come prevenire incidenti (es. configurare correttamente protezioni hardware, scegliere architetture sicure per certi servizi critici) sia come analizzare incidenti avvenuti (es. dump di memoria, istruzioni eseguire da un malware, log di errori CPU come kernel panic o machine check exception). Inoltre, la cooperazione tra hardware e software in termini di sicurezza è sancita da standard e best practice: ad esempio, l’UEFI Secure Boot sfrutta funzionalità firmware/hardware per garantire che all’accensione vengano eseguiti solo bootloader firmati e tecnologie come TPM (Trusted Platform Module) offrono radici hardware di fiducia utilizzate dai sistemi operativi per funzionalità come BitLocker (crittografia disco) o l’attestazione di integrità. Tutti questi aspetti richiedono una conoscenza delle basi architetturali per essere implementati e gestiti con successo.

Sistemi operativi

Un sistema operativo (SO) è il software di base che funge da intermediario tra l’hardware del computer e i programmi applicativi, gestendo le risorse del sistema e fornendo servizi essenziali agli utenti e alle applicazioni. In altre parole, il sistema operativo è composto da vari componenti integrati (kernel, gestore dei processi, gestore della memoria, file system, driver di periferica, interfaccia utente, ecc.) che insieme assicurano il funzionamento coordinato del computer. Esempi comuni di sistemi operativi sono Windows, Linux, macOS per desktop/server e Android, iOS per dispositivi mobili. Di seguito analizziamo le principali funzioni di un SO, evidenziando la loro importanza nella sicurezza informatica.

• Gestione dei processi e multitasking: il sistema operativo consente di eseguire più programmi in (pseudo)parallelismo attraverso la gestione dei processi e dei thread. Un processo è un’istanza in esecuzione di un programma, con un proprio spazio di indirizzamento in memoria, mentre un thread è un flusso di esecuzione all’interno di un processo (i thread di uno stesso processo condividono memoria e risorse). Il kernel (nocciolo del sistema operativo) include uno scheduler che assegna la CPU ai vari processi/thread attivi, implementando politiche di scheduling (round-robin, priorità, ecc.) per garantire reattività e far avanzare tutti i carichi di lavoro. In ambito sicurezza, la corretta separazione dei processi è cruciale: il sistema operativo deve isolare gli spazi di memoria in modo che un processo non possa leggere/scrivere la memoria di un altro (violando la confidenzialità o integrità). Ciò è realizzato tramite l’MMU (unità di gestione memoria) e meccanismi come la traduzione di indirizzi (paginazione) che il SO controlla. Un attaccante spesso cerca di rompere questo isolamento (es. tramite local privilege escalation exploits che da un processo utente permettono di eseguire codice in contesto kernel). Pertanto, funzioni come il caricamento di moduli kernel firmati, l’implementazione di sandbox (che confinano processi potenzialmente pericolosi in ambienti limitati) e la gestione attenta delle API di interprocess communication (pipe, socket, shared memory) sono aspetti di sicurezza legati alla gestione dei processi.
• Gestione della memoria: il sistema operativo fornisce astrazioni di memoria ai processi, tipicamente sotto forma di memoria virtuale. Ogni processo vede uno spazio di indirizzi virtuali che il kernel mappa sulla memoria fisica reale, garantendo che processi diversi non interferiscano. Il gestore della memoria del SO si occupa di allocare e liberare memoria su richiesta dei programmi (tramite chiamate di sistema come malloc/free in C, o automaticamente tramite garbage collector in linguaggi gestiti), di swappare porzioni di memoria su disco se la RAM scarseggia (memoria virtuale paginata) e di proteggere regioni critiche (ad esempio lo spazio di indirizzi del kernel è reso non accessibile ai processi utente, solitamente). Tecniche come ASLR – Address Space Layout Randomization (randomizzazione dello spazio degli indirizzi) sono abilitate dal sistema operativo per rendere meno prevedibili gli indirizzi di librerie, stack e heap, mitigando gli exploit basati su buffer overflow. Il responsabile alla sicurezza deve conoscere queste tecniche e assicurarsi che siano abilitate (ad esempio, DEP/NX e ASLR attivi, stack guard pages, ecc.), nonché essere in grado di analizzare core dump o tracce di crash per capire se un incidente è dovuto a corruzione di memoria. Inoltre, la gestione della memoria comprende i permessi di accesso alle pagine (read/write/execute): un sistema operativo robusto segrega scrupolosamente codice ed esegue dati non eseguibili, sfruttando l’hardware (bit NX) e marcando anche regioni di memoria come non accessibili quando opportuno (es. mappe null pointer per catturare dereferenziazioni errate). Da un punto di vista offensivo, molti malware tentano di aggirare queste protezioni, ad esempio tramite Return-Oriented Programming (ROP) per eseguire codice malizioso pur in assenza di pagine eseguibili in user-space: analizzare un attacco del genere richiede padronanza di come il SO organizza la memoria di un processo.
• File system e gestione delle risorse persistenti: un altro compito cardine del sistema operativo è la gestione dei file system, ovvero l’organizzazione dei dati su memoria di massa (dischi, SSD) in file e directory, con meccanismi di autorizzazione (permessi di lettura/scrittura/esecuzione per utenti e gruppi) e di protezione. Per esempio, sistemi POSIX (Linux, UNIX) adottano permessi rwx e proprietà utente/gruppo, oltre a meccanismi più avanzati come ACL (Access Control List) o selinux context per definire in modo granulare chi può accedere a cosa. Un responsabile della sicurezza deve assicurarsi che le politiche di permesso siano configurate secondo il principio del privilegio minimo (ad esempio, file di configurazione critici accessibili solo all’utente di sistema appropriato, directory con dati sensibili non eseguibili, ecc.). Inoltre, il file system registra metadati come timestamp (utili nelle analisi forensi per capire la timeline di un incidente) e, in alcuni sistemi, supporta cifratura trasparente (es. BitLocker su NTFS, LUKS su ext4) per proteggere i dati a riposo. Il sistema operativo è anche responsabile della gestione delle periferiche tramite driver – piccoli moduli software che fungono da traduttori tra il kernel e l’hardware. Driver vulnerabili possono introdurre gravi falle di sicurezza (poiché eseguono in kernel mode), quindi l’OS e i suoi aggiornamenti vanno monitorati per patch critiche relative ai driver (come ad esempio stuxnet, che sfruttò un driver malevolo con firma digitale rubata). Il sistema operativo implementa anche politiche di controllo degli accessi non solo a file ma a tutte le risorse (dispositivi, porte di rete, chiamate di sistema sensibili). Ad esempio, su sistemi UNIX esiste la distinzione tra utente normale e superutente (root): solo quest’ultimo può eseguire certe operazioni (binding di socket su porte <1024, caricamento di moduli kernel, modifiche alle tabelle di routing, ecc.). Meccanismi di sudo o capabilities permettono di limitare o delegare privilegi in modo controllato. La corretta configurazione di questi meccanismi è spesso l’ultima linea di difesa per prevenire che un attacco su un servizio in esecuzione con utente limitato comprometta tutto il sistema.
• Interfaccia utente e modalità utente/kernel: il sistema operativo fornisce infine all’utente (e alle applicazioni) un’interfaccia per utilizzare il computer. Questa può essere una GUI (interfaccia grafica) con desktop, finestre e pulsanti, o una shell a riga di comando per lanciare comandi testuali. Indipendentemente dall’interfaccia, quando un’applicazione necessita di compiere operazioni privilegiate (es. accedere al disco, aprire una connessione di rete, allocare memoria), deve effettuare una chiamata di sistema (system call) al kernel. Le system call rappresentano il punto di controllo tra la modalità utente e la modalità kernel: l’OS espone una serie di servizi di sistema (come “open file”, “send packet”, “create process”) e gli unici modi per un programma di utente di ottenere questi servizi è invocare le relative chiamate, che comportano un trap in modalità privilegiata. Il sistema operativo verifica i parametri e i permessi ad ogni system call, garantendo che l’operazione sia lecita. Ad esempio, se un processo chiede di aprire un file, il kernel controlla che quel processo (identificato dal suo UID/GID di appartenenza) abbia i diritti necessari sul file. Questo meccanismo è fondamentale per la sicurezza: previene che un processo malevolo possa arbitrariamente manipolare risorse senza passare per controlli. D’altra parte, se esistono vulnerabilità nelle implementazioni delle system call (bug nel kernel), un attaccante potrebbe ottenere privilegi elevati – questi sono i famosi exploit local root che sfruttano race condition, buffer overflow o errori logici nel kernel. Un buon responsabile della sicurezza deve tenere i sistemi operativi aggiornati (patch management) proprio per correggere tali vulnerabilità non appena note.

In conclusione, il sistema operativo è il componente software più critico da un punto di vista di sicurezza, perché orchestra l’uso di tutte le risorse e applica le politiche di isolamento e controllo.
Le best practice come la separazione dei privilegi (account utente vs amministratore), la riduzione della superficie d’attacco (disabilitare servizi di sistema non necessari, rimuovere driver inutilizzati), l’uso di meccanismi di logging e monitoraggio (Syslog, Event Viewer) e l’applicazione tempestiva di aggiornamenti di sicurezza, sono tutti ambiti afferenti al sistema operativo. Inoltre, standard e linee guida come quelle di CIS (Center for Internet Security) forniscono benchmark di hardening specifici per i vari sistemi operativi (ad esempio, CIS Controls e CIS Benchmarks per Windows Server, Red Hat, etc.), che il responsabile dovrebbe adottare per assicurare una configurazione robusta delle macchine. Un sistema operativo correttamente configurato e mantenuto è in grado di prevenire la maggior parte degli incidenti informatici comuni (attacchi malware, escalation di privilegi, esfiltrazione di dati), o quantomeno di registrare eventi utili a rilevare tempestivamente attività anomale.

Basi di dati relazionali e NoSQL

Le basi di dati (database) sono infrastrutture fondamentali per archiviare, organizzare e recuperare grandi quantità di informazioni in modo efficiente. Esistono vari modelli di database; i più diffusi si dividono in database relazionali (SQL) e database NoSQL (non relazionali). In questa sezione esamineremo entrambi, delineando caratteristiche, differenze e rilevanza per la sicurezza.

Database relazionali (modello SQL)

Un database relazionale organizza i dati in tabelle composte da righe e colonne, secondo il modello introdotto da Edgar F. Codd negli anni ‘70. Ogni tabella rappresenta un’entità, ogni riga (o record) rappresenta un’istanza dell’entità e ogni colonna rappresenta un attributo (campo) del record. Ad esempio, potremmo avere una tabella Utenti con colonne ID, Nome, Email, Ruolo dove ciascuna riga è un utente specifico con i suoi dati e una tabella Accessi con colonne UtenteID, DataOra, Esito per tracciare i login: le due tabelle sarebbero collegate attraverso il campo UtenteID (chiave esterna nella tabella Accessi che rimanda alla chiave primaria ID nella tabella Utenti). Le relazioni tra tabelle (one-to-one, one-to-many, many-to-many) vengono realizzate tramite queste chiavi: chiave primaria (un identificatore unico per ogni riga di una tabella) e chiavi esterne (valori che collegano una riga a una riga in un’altra tabella). Il modello relazionale è accompagnato da un linguaggio standard di interrogazione e manipolazione dei dati: SQL (Structured Query Language), che permette di definire lo schema (DDL – Data Definition Language), inserire/modificare/cancellare dati (DML – Data Manipulation Language) e effettuare query di ricerca e aggregazione (con SELECT, JOIN tra tabelle, ecc.).

Caratteristiche chiave dei database relazionali sono le cosiddette proprietà ACID delle transazioni, fondamentali in ambiti critici (bancari, gestionali, etc.): Atomicità (ogni transazione è un’unità indivisibile, o tutti gli step vengono applicati o nessuno), Coerenza (la transazione porta il database da uno stato consistente a un altro, non viola vincoli di integrità ), Isolamento (transazioni concorrenti non interferiscono tra loro, i risultati sono come se fossero state eseguite in sequenza) e Durabilità (una volta completata con successo, un’operazione diventa persistente anche in caso di guasti successivi). I DB relazionali sono tipicamente gestiti da un RDBMS (Relational Database Management System) – ad esempio Oracle, Microsoft SQL Server, MySQL/MariaDB, PostgreSQL – che si occupa di implementare queste garanzie e ottimizzare l’accesso ai dati (attraverso indici, piani di esecuzione delle query, caching, etc.).

Rilevanza per la sicurezza: i database relazionali spesso custodiscono informazioni sensibili (dati personali, credenziali, registri di attività) e sono bersagli appetibili per gli attaccanti. Due aspetti fondamentali vanno considerati: la sicurezza interna del DB e le vulnerabilità delle applicazioni che lo utilizzano. Sul primo fronte, un RDBMS deve essere configurato con opportune misure di sicurezza: controlli di accesso robusti (account separati con privilegi minimi per le applicazioni, ruoli e privilegi SQL assegnati con granularità), cifratura dei dati a riposo (molti DB supportano tablespace criptati o cifratura trasparente delle colonne), audit e logging delle operazioni (tracciare chi ha eseguito cosa e quando, per individuare accessi sospetti) e hardening generale (disabilitare funzionalità non utilizzate, applicare patch di sicurezza del motore DB). Ad esempio, esistono standard come lo SQL Server Security Guide o linee guida CIS Benchmarks per MySQL/PostgreSQL che elencano best practice: dal forzare l’autenticazione con password complesse, all’abilitare la cifratura TLS nelle connessioni client-DB, fino a restringere l’uso di stored procedure o comandi pericolosi solo ad account fidati.

Sul secondo fronte, il rischio più noto è la SQL Injection, una tecnica d’attacco applicativa in cui input malevoli forniti a un’applicazione web (o altro software) finiscono per alterare l’istruzione SQL eseguita sul database. Se l’applicazione non “sanitizza” correttamente gli input (ad esempio non usando query parametrizzate/preparate), un attaccante può inserire frammenti di SQL arbitrario nelle query, ottenendo potenzialmente accesso o manipolazione non autorizzata dei dati. Un classico incidente è quando un campo di login viene usato direttamente in una query tipo SELECT * FROM utenti WHERE user='${utente}' AND pass='${password}' : fornendo come utente qualcosa come ' OR '1'='1' , la query diventa sempre vera permettendo bypass di autenticazione. Dal punto di vista di un responsabile alla sicurezza, mitigare le SQL injection è prioritario: significa formare gli sviluppatori all’uso di parametri bindati, ORMs, stored procedure sicure e al filtraggio/escape degli input in ultima istanza. In aggiunta, predisporre Web Application Firewall (WAF) con regole per intercettare pattern di SQL injection può aggiungere un livello di difesa. Un altro esempio di attacco è il privilege escalation interno al DB: se un account di applicazione con pochi privilegi riesce a eseguire un comando di sistema attraverso una funzionalità di SQL estesa (ad esempio le xp_cmdshell di SQL Server, se abilitate impropriamente, consentono di eseguire comandi sul sistema operativo), l’attaccante potrebbe passare dal database al pieno controllo del server. Ciò evidenzia l’importanza di limitare al minimo i privilegi degli account DB usati dalle applicazioni e di disabilitare funzionalità di estensione (come esecuzione di codice esterno) se non necessarie.

In termini di standard, normative come il GDPR richiedono protezione rigorosa dei dati personali spesso contenuti nei database, includendo principi di data protection by design (ad esempio minimizzazione dei dati raccolti, pseudonimizzazione). Standard industriali come il PCI-DSS per i dati di carte di credito impongono cifratura degli storage e segmentazione di rete per i sistemi di database, oltre a monitoraggio continuo degli accessi.

Database NoSQL (non relazionali)

Negli ultimi anni, accanto ai sistemi relazionali tradizionali, si sono diffusi i database NoSQL, termine che sta per “Not Only SQL” ad indicare database non basati sul modello relazionale e spesso privi di schema fisso. I database NoSQL abbracciano diverse categorie: database documentali (che memorizzano dati in documenti strutturati tipicamente in formato JSON/BSON, es. MongoDB, CouchDB), database a colonne distribuite (simili a tabelle sparse con colonne flessibili, es. Cassandra, HBase), database a chiave-valore (memorizzano coppie key-value senza struttura interna, es. Redis, Riak) e database a grafo (ottimizzati per rappresentare entità e relazioni complesse come nodi e archi, es. Neo4j). Questi sistemi rinunciano alle rigide tabelle relazionali in favore di una struttura dati più flessibile e spesso distribuita su cluster di macchine.

Nei database NoSQL, i dati vengono spesso memorizzati nel loro formato nativo o “denormalizzato”. Ad esempio, un documento JSON può contenere in un unico record tutte le informazioni di un utente, compresa una lista dei suoi ordini, evitando di fare JOIN tra tabelle separate come accadrebbe in un
modello relazionale. Questo porta vantaggi in termini di prestazioni e scalabilità su grandi volumi di dati o dati eterogenei: il sistema scala orizzontalmente, replicando e partizionando i dati su più nodi (sharding), ed è in grado di gestire variazioni di struttura tra diversi record (schema flessibile).

Tuttavia, spesso i database NoSQL sacrificano la coerenza immediata delle transazioni in favore della disponibilità e della partition tolerance, secondo i principi del teorema CAP. In ambienti distribuiti, garantire simultaneamente Coerenza, Disponibilità e Tolleranza alle partizioni è impossibile; molti database NoSQL scelgono di essere AP (available, partition-tolerant) sacrificando la consistenza forte: i dati possono essere eventualmente consistenti, ovvero gli aggiornamenti si propagano con tempo breve ma non istantaneo su tutte le repliche. In termini pratici, ciò significa che una lettura potrebbe restituire un dato lievemente obsoleto se appena modificato altrove, privilegiando però la reattività del sistema anche in caso di rete con latenze. Questo è spesso accettabile per scenari come social network (ad esempio, vedere per qualche secondo la vecchia foto profilo di un utente prima che arrivi la nuova non è critico), ma sarebbe inaccettabile in un’applicazione bancaria (dove i conti correnti richiedono consistenza forte). In compenso, le architetture NoSQL sono progettate per alta disponibilità e scalabilità: aggiungendo nodi al cluster, le performance di throughput aumentano linearmente in molti casi e la ridondanza dei dati su nodi multipli evita singoli punti di guasto.

Rilevanza per la sicurezza: i database NoSQL presentano sfide di sicurezza in parte analoghe a quelle dei relazionali, ma con alcune peculiarità. Innanzitutto, l’assenza di schema fisso significa che non ci sono vincoli intrinseci di tipo/forma dei dati: ciò può rendere più difficile validare l’input e più facile commettere errori logici (ad esempio, se un campo previsto come numero intero viene memorizzato come stringa in alcuni documenti, il comportamento dell’applicazione potrebbe essere imprevedibile).
Dal punto di vista degli attacchi, esistono varianti di injection anche per NoSQL – le cosiddette NoSQL Injection – dove input malevoli manipolano le query di ricerca su database non relazionali. Ad esempio, in MongoDB una query è spesso costruita passando un JSON di filtro: se un’applicazione web inserisce direttamente parametri utente in questo JSON senza controlli, un attaccante potrebbe aggiungere operatori come $gt (greater than) o $ne (not equal) per alterare la logica della query. Pur meno note delle SQL injection, vulnerabilità analoghe sono state riscontrate (ad es. su applicazioni con backend MongoDB, Redis injection sfruttando comandi craftati, ecc.).

In termini di controlli di accesso, alcuni database NoSQL nelle prime versioni erano pensati per funzionare in ambienti fidati e mancavano di robusti sistemi di autenticazione/autorizzazione. Ci sono stati casi clamorosi di database NoSQL esposti online senza password (es. istanze di MongoDB o Elasticsearch lasciate aperte) che hanno portato a massivi furti di dati o attacchi ransomware (dove gli attaccanti esfiltravano e cancellavano i dati chiedendo un riscatto). Dunque, una prima regola di sicurezza è assicurarsi che l’accesso di rete ai database sia segregato (solo dagli application server, non dal pubblico internet) e che i meccanismi di autenticazione siano attivi e con credenziali robuste.
Oggi i principali prodotti NoSQL (MongoDB, Cassandra, etc.) offrono meccanismi di autenticazione, cifratura in transito (SSL/TLS) e a riposo, controlli di autorizzazione basati su ruoli – ma sta ai configuratori abilitarli. In un contesto di sicurezza nazionale, dove si trattano dati sensibili, è imperativo che anche i database NoSQL rispettino standard di hardening: ad esempio, MongoDB Security Checklist suggerisce di abilitare l’autenticazione SCRAM-SHA, definire ruoli con minimo privilegio (lettura/scrittura su specifici database), usare IP binding solo su interfacce interne, abilitare auditing, ecc.

Dal punto di vista della consistenza dei dati, bisogna inoltre considerare la resilienza: in caso di incidenti (es. guasto di nodi, partizioni di rete), i database NoSQL possono entrare in stati degradati (consistenza ridotta) che, se non gestiti, potrebbero causare perdite o duplicazioni di dati. Un piano di sicurezza deve includere backup regolari anche per database NoSQL e test di ripristino, dato che la natura distribuita a volte complica le procedure di recovery (bisogna tenere conto di replica set, quorum di consenso per riottenere un primario in sistemi tipo MongoDB, etc.). Inoltre, la eventuale consistenza implica che nel monitoraggio degli incidenti bisogna tener conto di possibili discrepanze temporanee: ad esempio, analizzando i log di un sistema distribuito, un responsabile alla sicurezza deve sapere che l’ordine esatto delle operazioni potrebbe differire leggermente tra nodi – il che può complicare l’analisi forense e la ricostruzione esatta degli eventi. Strumenti specializzati per logging centralizzato (spesso basati essi stessi su stack NoSQL, come ELK – Elasticsearch, Logstash, Kibana) vanno configurati per correlare correttamente eventi multi-nodo.

Integrazione SQL/NoSQL e best practice: molte organizzazioni adottano architetture ibride dove convivono database relazionali per dati transazionali e database NoSQL per big data, analytics in tempo reale, cache in-memory, etc. Un coordinatore di sicurezza deve avere familiarità con entrambi e con le tecniche per proteggerli. Ad esempio, assicurarsi che i dati sensibili presenti in un cluster Hadoop/NoSQL siano cifrati (usando magari librerie come Google Tink o servizi KMS per gestire le chiavi) e segregati con tokenization o pseudonymization per minimizzare l’impatto di un breach. Allo stesso tempo, mantenere aggiornati i sistemi (le piattaforme NoSQL sono in continuo sviluppo, patch di sicurezza escono di frequente) e utilizzare strumenti di monitoraggio delle anomalie sulle query (Database Activity Monitoring) anche su NoSQL, dove possibile, per rilevare pattern inconsueti (es. un’esplosione di letture anomale alle 3 di notte da un certo IP potrebbe indicare un exfiltration in corso).

Riassumendo, la scelta tra database relazionali e NoSQL dipende dai requisiti di consistenza, scalabilità e struttura dei dati. Dal punto di vista della sicurezza, entrambi richiedono robuste misure di protezione, consapevoli delle rispettive architetture. I database relazionali brillano per maturità di strumenti di sicurezza integrati e transazioni ACID, mentre i NoSQL offrono flessibilità e prestazioni su scala, ma il professionista deve compensare eventuali mancanze (es. consistenza) a livello applicativo e prestare attenzione a configurazioni sicure che non sono sempre default. Conoscere standard come OWASP Top 10 (A03:2021 – Injection) per le injection o il NIST SP 800-123 (guide to general server security, applicabile anche ai server DB) aiuta a costruire un ambiente database – relazionale o no – robusto contro incidenti informatici.

Networking e principali protocolli di rete (TCP/IP, DNS, BGP)

Le reti di calcolatori permettono a sistemi differenti di comunicare e scambiarsi informazioni. La sicurezza informatica moderna è strettamente legata alle reti, poiché gran parte degli incidenti avviene attraverso connessioni di rete (attacchi remoti, malware che si propagano, esfiltrazioni di dati). In questa sezione esaminiamo i fondamenti del networking e tre protocolli chiave: la suite TCP/IP (base di Internet), il sistema dei nomi a dominio DNS e il protocollo di routing BGP. Comprendere questi protocolli è essenziale per prevenire e gestire incidenti che vanno dagli attacchi DDoS alla manipolazione del traffico internet.

Suite TCP/IP (Livelli di trasporto e rete)

TCP/IP non è un singolo protocollo ma una famiglia di protocolli organizzati in un modello di rete pratico (spesso semplificato in 4 livelli: Link, Internet, Trasporto, Applicazione) che corrisponde in parte al modello OSI (vedi sezione successiva). I due pilastri di questa suite sono il Protocollo IP (Internet Protocol) e il Protocollo TCP (Transmission Control Protocol), da cui prende nome.

• IP (Internet Protocol): IP opera al livello di rete ed è il protocollo fondamentale che si occupa di indirizzamento e instradamento dei pacchetti attraverso reti differenti. IP fornisce un servizio di consegna di pacchetti non affidabile e senza connessione: ciò significa che invia i pacchetti dal mittente al destinatario secondo le informazioni di routing, ma non garantisce né che arrivino (possono perdersi) né che arrivino in ordine. Ogni dispositivo collegato in rete ha almeno un indirizzo IP univoco (32 bit per IPv4, rappresentati come quattro numeri es. 192.168.10.5, oppure 128 bit per IPv6, rappresentati in esadecimale). IP provvede a incapsulare i dati in un pacchetto IP contenente header (con mittente, destinatario, TTL, ecc.) e payload (i dati da trasportare, ad esempio un segmento TCP). Il protocollo IP è progettato per collegare reti eterogenee: è un protocollo di interconnessione di reti (internetworking) di livello 3 OSI, nato per far comunicare sottoreti differenti unificandole in un’unica rete logica (da cui “Internet”). IP compie l’instradamento: i router analizzano l’indirizzo di destinazione IP di ciascun pacchetto e lo inoltrano verso il router successivo più vicino alla destinazione, sulla base di tabelle di routing. Gli algoritmi di routing (OSPF, BGP, ecc. visti più avanti per BGP) costruiscono queste tabelle. Sul piano sicurezza, IP di per sé non prevede autenticazione né confidenzialità: i pacchetti possono essere falsificati (IP spoofing) e letti da intermediari. Per ovviare a ciò esistono estensioni come IPsec (una suite per la cifratura e autenticazione a livello IP) usata in VPN sicure. Inoltre, la natura non affidabile di IP significa che spetta ai livelli superiori occuparsi di ritrasmissioni e controllo di flusso (è qui che interviene TCP). Va citato che IPv4 soffre di spazio di indirizzi limitato e problemi di sicurezza (frammentazione IP usata in certi attacchi DoS, ad esempio Teardrop attack), mentre IPv6 migliora alcuni aspetti (spazio vastissimo, meccanismi di autoconfigurazione) ma porta nuove considerazioni di sicurezza (ad esempio, la presenza obbligatoria di ICMPv6 e multicast di rete locale richiede filtri specifici per evitare scansioni e attacchi di discovery non autorizzati).
• TCP (Transmission Control Protocol): TCP opera a livello di trasporto e fornisce un canale di comunicazione affidabile e orientato alla connessione tra due host. In termini pratici, TCP si occupa di instaurare una connessione virtuale tra client e server (tramite la celebre stretta di mano 3-way handshake: SYN, SYN-ACK, ACK), di suddividere i dati da inviare in segmenti adeguati, di numerare i segmenti e ritrasmettere quelli non riconosciuti e di riordinare i segmenti al ricevente per presentare un flusso di byte continuo all’applicazione. Grazie a TCP, le applicazioni non devono preoccuparsi di perdita o disordine di pacchetti: TCP garantisce che i dati arrivino integri e nell’ordine corretto, o notifica un errore se la connessione si interrompe. Questo è essenziale per protocolli applicativi come HTTP, SMTP, FTP, in cui ricevere dati incompleti o scombinati equivarrebbe a corruzione dell’informazione. Tecnicamente, TCP identifica le connessioni tramite le porte: ogni segmento TCP ha una porta sorgente e una destinazione, permettendo a un singolo host di gestire più connessioni simultanee su porte diverse (es. 80 per HTTP, 443 per HTTPS, 25 per SMTP, ecc.). Dal punto di vista della sicurezza, il protocollo TCP è stato bersaglio di attacchi sin dai primordi di Internet. Un esempio classico è il TCP SYN flood: attaccando l’handshake di TCP, un aggressore invia una valanga di pacchetti SYN senza completare mai il 3° passo, lasciando il server con molte connessioni “mezze aperte” (in stato SYN_RECV) e esaurendo le risorse dedicate (la backlog queue). Ciò provoca un Denial of Service. Contromisure come SYN cookies o limiti sulla half-open queue aiutano a mitigare. Un altro attacco è il TCP reset (RST): inviando un pacchetto falsificato con bit RST si può forzare la chiusura di una connessione TCP esistente; se l’attaccante riesce a indovinare gli identificatori corretti (IP/porta e numero di sequenza), può interrompere comunicazioni di altri. Questo fu sfruttato in passato per bloccare traffico BGP (il cui trasporto è su TCP, vedi dopo) o per censura (come RST injection nel grande firewall cinese). Per integrità e confidenzialità, TCP da solo non offre nulla: la protezione dei dati deve avvenire a livello applicativo (ad es. TLS sopra TCP per cifrare la sessione). Tuttavia, dentro la suite TCP/IP esistono protocolli complementari come UDP (User Datagram Protocol, non affidabile e senza connessione, usato per streaming, DNS, etc.) che il responsabile sicurezza deve ugualmente conoscere: ad esempio, UDP è più soggetto a spoofing (essendo connectionless) e viene sfruttato in attacchi DDoS di riflessione/amplificazione (come DNS amplification, SSDP amplification), dunque vanno predisposti filtri (e.g. anti-spoofing con BCP 38, rate limiting su servizi UDP pubblici). In generale, la comprensione profonda di TCP/IP consente di analizzare i log di rete e i dump di pacchetto (es. con Wireshark) per rilevare attività sospette: sequenze anomale di flag TCP, tentativi su port scanning (che si evidenziano come connessioni SYN brevissime su molte porte), pacchetti malformati, etc. Standard come gli RFC (es. RFC 793 per TCP, RFC 791 per IP) definiscono il funzionamento lecito: molti attacchi inviano traffico che devia dallo standard (es. pacchetti con flag inconsuete come Xmas scan con FIN-PSH-URG) e sistemi IDS/IPS (Snort, Suricata, Zeek) sono in grado di rilevarlo se ben configurati.

In sintesi, TCP/IP è la colonna portante delle comunicazioni di rete. Un coordinatore di prevenzione incidenti deve: assicurare che le configurazioni di rete seguano le best practice (filtri su pacchetti ingressi/uscita, disabilitare protocolli legacy insicuri – es. Telnet, FTP – a favore di versioni cifrate – SSH, FTPS/SFTP), conoscere gli attacchi di rete comuni e le contromisure (firewall stateful per gestire SYN flood, IDS per rilevare scansioni e anomalie TCP/IP, IPsec per proteggere canali critici) e in caso di incidente saper leggere il traffico (analisi PCAP) per capire cosa è successo. Ad esempio, in un sospetto data breach, potrebbe trovarsi traffico TCP sulla porta 443 di volume insolitamente alto verso un IP esterno non riconosciuto: sapere che 443 è solitamente HTTPS e che l’esfiltrazione potrebbe avvenire cifrata fa sì che si debba guardare a meta-dati (SNI, quantità, pattern) e non al contenuto impossibile da decifrare senza la chiave. Allo stesso modo, la padronanza di TCP/IP è fondamentale per gestire incidenti come DDoS: riconoscere un flood TCP SYN o UDP, distinguere un traffico legittimo da uno malevolo in base a parametri di basso livello e interfacciarsi con ISP/CDN per attivare filtri o scrubbing.

DNS (Domain Name System)

DNS è il “servizio di nomi” di Internet, spesso paragonato a un “elenco telefonico” o a un servizio di rubrica per la rete globale. Il suo scopo principale è tradurre i nomi di dominio leggibili dagli umani (ad es. www.esempio.gov) nei corrispondenti indirizzi IP numerici che le macchine utilizzano per instradare il traffico. Senza DNS, dovremmo ricordare e digitare indirizzi come 93.184.216.34 per visitare un sito, cosa impraticabile su larga scala. Il DNS è dunque fondamentale per l’usabilità di Internet.

Il sistema DNS è gerarchico e distribuito. I nomi di dominio sono organizzati in una struttura ad albero rovesciato: al vertice ci sono i root server (indicati da un dominio radice vuoto, spesso rappresentato da un punto . ), subito sotto ci sono i domini di primo livello (TLD) come .com , .org , .it , .gov, ecc., poi i secondi livelli (es. esempio in esempio.gov ) e così via con possibili sottodomini aggiuntivi. L’operazione di risoluzione DNS consiste nel trovare l’indirizzo IP associato a un nome (risoluzione diretta) o viceversa trovare il nome dato un IP (risoluzione inversa). Quando un client (tipicamente tramite un resolver stub integrato nel sistema operativo) deve risolvere un nome, contatta un DNS resolver ricorsivo (spesso fornito dall’ISP o configurato manualmente come 8.8.8.8 di Google) il quale interroga a sua volta la gerarchia: parte dai root server (ce ne sono 13 indirizzi logici root disseminati globalmente) per sapere chi è autoritativo per il TLD richiesto, poi contatta il server autoritativo di quel TLD per sapere chi gestisce il dominio di secondo livello e così via fino ad ottenere dal server DNS autoritativo finale (gestito dal proprietario del dominio o dal suo provider) il record richiesto. Il DNS memorizza le risposte in cache per un certo periodo (TTL) per accelerare richieste future.

I record DNS più comuni includono: A/AAAA (indirizzo IPv4 o IPv6 associato a un nome), CNAME (nome canonico, alias verso un altro nome), MX (mail exchanger, indirizzo dei server di posta per il dominio), TXT (testo libero, usato anche per record SPF/DKIM nei contesti mail), SRV (service locator, utilizzato da alcuni protocolli), PTR (pointer per risoluzione inversa da IP a nome).

Minacce e sicurezza DNS: il DNS in origine è stato progettato senza meccanismi di autenticazione, il che l’ha reso vulnerabile a vari attacchi. Il più classico è il DNS cache poisoning: un attaccante induce un resolver a memorizzare una risposta falsa, cosicché gli utenti successivi vengano indirizzati all’IP sbagliato (ad esempio, credono di visitare bancopopolare.it ma in realtà il DNS avvelenato gli dà l’IP di un server dell’attaccante). Prima di correttivi, era possibile inviare risposte DNS fasulle con una certa facilità, approfittando del fatto che la porta UDP 53 e l’ID di transazione DNS erano prevedibili e non c’era verifica di origine. Ora i resolver usano porte effimere random e ID random a 16 bit, riducendo la fattibilità del poisoning, ma il rischio resta se l’attaccante può intralciare la comunicazione col vero server (ad es. tramite un man-in-the-middle). La risposta dell’industria è DNSSEC, un’estensione di sicurezza che aggiunge firme digitali alle risposte DNS: i domini firmati DNSSEC pubblicano chiavi pubbliche nei record DNSKEY e usano record RRSIG per firmare le mapping nome->IP. Un resolver con DNSSEC abilitato verifica che la firma sia valida e ancorata a una catena di fiducia (dal root in giù) evitando di accettare dati manomessi. DNSSEC, però, non è ancora ovunque adottato e introduce la
complessità della gestione chiavi/rollover.

Un altro problema di sicurezza DNS è il DNS tunneling: usando richieste DNS (che spesso sono permesse anche quando altro traffico è bloccato) per incapsulare dati arbitrari, degli attaccanti possono esfiltrare informazioni o comandare malware (comandi e controllo) attraverso query DNS apparentemente legittime. Ad esempio, un malware potrebbe fare query a sottodomini come <data>.esempio-attaccante.com, dove <data> è un blocco di dati rubati codificato in base32; il server DNS sotto il controllo dell’attaccante riceve queste query e decodifica i dati dal nome richiesto.
Dal punto di vista di un analista, è importante monitorare il traffico DNS verso domini insoliti o con nomi molto lunghi/strani, segnale tipico di tunneling o data exfiltration. Strumenti di sicurezza avanzata (DNS firewall, soluzioni di exfiltration detection) possono rilevare e bloccare questi abusi.

C’è poi il DNS hijacking o DNS spoofing: se un attaccante compromette un server DNS autoritativo o modifica i riferimenti (ad esempio alterando i record di un registrar DNS), può dirottare un dominio intero su altri IP. Questo è successo, ad esempio, in attacchi a provider DNS o in scenari di censura statale (dove i resolver ISP sono modificati per restituire IP “fake” per certi domini). Contromisure includono l’uso di registrar con protezioni robuste (2FA, lock) e monitoraggio continuo dei record DNS critici.

Best practice relative al DNS per un responsabile alla sicurezza includono: utilizzare resolver DNS ricorsivi sicuri (magari in-house o servizi con filtro malware), abilitare DNSSEC validation sui resolver interni per i propri utenti, implementare DNSSEC per i domini gestiti dall’organizzazione in modo da prevenire impersonificazioni, isolare e proteggere i server DNS autoritativi (pochi servizi devono contattarli, quindi regole firewall restrittive e monitoraggio). Inoltre, configurare correttamente i record per proteggere email e servizi (DNS è utilizzato in meccanismi di sicurezza come SPF, DKIM, DMARC per l’email authentication). Un altro aspetto è la privacy: le query DNS tradizionali sono in chiaro, quindi un attaccante che sniffa la rete vede tutti i nomi richiesti (che possono rivelare i siti visitati, ecc.). In risposta, si stanno diffondendo protocolli come DNS over HTTPS (DoH) o DNS over TLS (DoT) che cifrano il traffico DNS tra client e resolver. Questo migliora la riservatezza, ma pone sfide per i controlli aziendali (non si può più facilmente ispezionare il contenuto DNS). Un coordinatore dovrà quindi bilanciare privacy e capacità di monitoraggio, magari attivando DoT/DoH con server fidati ma anche usando sistemi di split-horizon DNS per risolvere internamente i nomi aziendali e avere visibilità.

BGP (Border Gateway Protocol)

BGP è il protocollo di routing globale che tiene unita Internet. Mentre protocolli come OSPF, EIGRP, IS-IS gestiscono il routing interno a una singola organizzazione o sistema autonomo (IGP – Interior Gateway Protocols), BGP è l’Exterior Gateway Protocol che connette tra loro i diversi Autonomous System (AS) – essenzialmente le reti di proprietà di fornitori di connettività (ISP, dorsali, grandi organizzazioni) identificate da un numero AS univoco. In parole semplici, BGP è il metodo con cui le reti annunciano ad altre reti quali prefissi IP possono raggiungere attraverso di loro, permettendo così di instradare pacchetti da un capo all’altro del mondo, passando per molte reti intermedie. BGP è dunque il “sistema di comunicazione tra router di confine” che consente a Internet di funzionare come un’unica grande rete. Senza BGP, i pacchetti oltre la propria rete locale non saprebbero dove andare.

Dal punto di vista tecnico, BGP è un protocollo di routing di tipo path-vector: ogni annuncio BGP informa su un prefisso IP raggiungibile e include l’AS-PATH, ovvero la sequenza di AS che bisogna attraversare per raggiungere quel prefisso. I router BGP (detti spesso Route Reflector o router di bordo) scambiano messaggi su connessioni TCP (porta 179). BGP è incrementale: invece di scambiare periodicamente l’intera tabella come alcuni IGP, dopo l’iniziale full routing table exchange, invia solo aggiornamenti quando cambia qualcosa (annuncio di nuova rotta o ritiro di una esistente). Questo lo rende scalabile per Internet dove esistono oltre 900k prefissi IPv4 annunciati. BGP permette politiche: ogni operatore può definire preferenze su quali rotte usare o annunciare (ad esempio preferire percorsi più corti in termini di AS-PATH, o quelli ricevuti da clienti su quelli ricevuti da provider per motivi economici).

Vulnerabilità e incidenti BGP: BGP si basa in gran parte sulla fiducia tra operatori e fino a tempi recenti non incorporava meccanismi crittografici robusti. Ciò lo rende vulnerabile al cosiddetto BGP hijacking: un AS malevolo (o mal configurato) può annunciare rotte per prefissi IP che non gli appartengono, deviando il traffico. Ad esempio, nel 2008 l’annuncio errato di una rotta per YouTube da parte di un ISP pakistano (nel tentativo di censurare YouTube localmente) propagò a livello globale, rendendo YouTube irraggiungibile per ore. In altri casi, attori malevoli hanno annunciato prefissi bancari o di criptovalute per intercettare dati. BGP hijack può portare a interruzione (se il traffico viene in un vicolo cieco) o Man-in-the-Middle (se il traffic hijacker lo inoltra verso la destinazione vera dopo averlo intercettato). Secondo analisi recenti, essendo BGP una tecnologia con ~35 anni di età, è “facile da manipolare per reinstradare il traffico Internet o addirittura isolare intere regioni”. Infatti, casi documentati mostrano come in situazioni geopolitiche (es. crisi Crimea/Ucraina), BGP sia stato usato intenzionalmente per deviare traffico di intere aree verso infrastrutture sotto controllo di governi, creando di fatto “frontiere digitali” coerenti con quelle militari.

Le contromisure emergenti sono: RPKI (Resource Public Key Infrastructure), un sistema di certificati digitali che associa prefissi IP e numeri AS a enti legittimi, permettendo ai router di verificare se un certo AS è autorizzato ad annunciare un certo prefisso. Implementare RPKI e filtri di validazione (droppare annunci BGP non validati) riduce i rischi di hijack accidentali e rende più difficile quelli malevoli (che richiederebbero compromissione dei certificati). Inoltre, buone pratiche come i filtri BCP 38 anti-spoofing e l’obbligo per gli ISP di filtrare annunci in ingresso da clienti che non corrispondono ai loro IP (route filtering) riducono la superficie di attacco. In ambito di sicurezza nazionale, è auspicabile una stretta collaborazione con gli operatori di rete per assicurare che tali misure siano adottate, dato che un attacco BGP può essere usato anche come vettore per isolare un paese o spostare traffico attraverso nodi di sorveglianza (si pensi a un hijack temporaneo che dirotta traffico europeo via AS in un altro continente per spiarlo, poi lo rilascia verso la destinazione – tattica rilevata in alcune analisi di routing).

Un altro rischio BGP è l’instabilità o errore di configurazione: BGP è complesso ed errori nelle politiche possono causare route leak (annuncio di rotte ricevute da un provider verso un altro provider quando non dovrebbe, saturando percorsi imprevisti) o flapping (rotte che oscillano ripetutamente su/giù causando overhead). Questi incidenti possono avere impatti collaterali di sicurezza: un route leak può congestionare link inattesi, rallentando comunicazioni critiche o firewall, oppure un flapping eccessivo potrebbe stressare i router fino a farli riavviare per carico (causando DoS su interi segmenti di rete).

Ruolo del responsabile della sicurezza su BGP: per un’organizzazione che potrebbe gestire proprie infrastrutture di rete, è cruciale avere visibilità BGP. Ciò include utilizzare servizi di monitoring (es. RouteViews, RIPE Atlas) che avvisino se i prefissi dell’organizzazione vengono annunciati da AS esterni (potenziale hijack in corso) o se route importanti spariscono. In caso di incidente BGP, il responsabile deve saper interfacciarsi con i Network Operator Groups e CERT/CSIRT di settore per coordinare una risposta (ad esempio, diffondere rapidamente la notizia di non accettare annunci da AS X, o contattare l’operatore responsabile dell’annuncio spurio).

Inoltre, la comprensione di BGP è importante per valutare la resilienza delle comunicazioni critiche: per servizi governativi essenziali, ci si può assicurare multihoming (connessione a più ISP con diverse rotte) e preferire percorsi che minimizzino passaggi in zone a rischio. Ad esempio, se un paese teme spionaggio, potrebbe voler monitorare se il suo traffico passa per AS di altri paesi non amici e magari accordarsi con gli ISP per restrizione di routing. Strumenti di tracciamento (traceroute a livello AS) aiutano a mappare i percorsi.

Riassumendo, BGP è un protocollo potente ma datato, core di Internet e allo stesso tempo punto debole sfruttabile. Lo sforzo collettivo di mettere in sicurezza BGP (attraverso RPKI, monitoring e cooperazione tra ISP) è in corso e i professionisti di sicurezza devono essere partecipi: conoscere gli incidenti storici, sostenere l’adozione di misure protettive e includere scenari di attacco BGP nei propri piani di rischio (specialmente in contesti di infrastrutture critiche dove un attacco di routing può significare blackout comunicativo).

Reti di elaboratori (Modello OSI)

• Livello 1: Fisico. Si occupa della trasmissione dei bit grezzi sul mezzo fisico di comunicazione. Definisce specifiche elettriche, meccaniche e funzionali per attivare, mantenere e disattivare collegamenti fisici. Ad esempio, stabilisce che forma d’onda e tensione rappresentano un “1” o uno “0”, il tipo di connettore e cavo (rame, fibra ottica), la modulazione usata in trasmissioni wireless, la sincronizzazione dei bit, etc.. Dispositivi tipici al livello fisico sono i repeater, gli hub Ethernet (che rigenerano il segnale su più porte) e i componenti come cavi, transceiver, antenne. Dal punto di vista della sicurezza, il livello fisico è spesso trascurato ma non privo di rischi: tapping su cavi (intercettazioni fisiche), interferenze elettromagnetiche intenzionali o accidentali e attacchi di jamming nel wireless (disturbo radio per negare il servizio) sono minacce di livello 1. Contromisure includono cablaggi schermati, monitoraggio di link (per rilevare disconnessioni o anomalie elettriche) e in ambienti critici l’uso di fibre ottiche (difficili da intercettare senza provocare perdite di segnale rilevabili).
• Livello 2: Collegamento Dati. Fornisce il trasferimento dei dati tra due nodi adiacenti (collegati dallo stesso mezzo fisico) in modo affidabile, strutturando i bit in frame e implementando controlli di errore e controllo di flusso su ciascun collegamento. Qui troviamo protocolli come Ethernet (IEEE 802.3) per le LAN cablate, Wi-Fi (IEEE 802.11) per le LAN wireless, PPP per collegamenti punto-punto, HDLC, ecc. Il livello 2 utilizza indirizzi fisici (MAC address per Ethernet) per identificare le schede di rete sorgenti e destinazione su un segmento. Funzioni chiave includono l’error detection (es. CRC per individuare frame corrotti e scartarli) e a volte l’error recovery (es. in collegamenti PPP può esserci ritrasmissione). Switch e bridge operano a questo livello, instradando frame in base agli indirizzi MAC e segmentando collision domains. Dal punto di vista sicurezza, il livello data link presenta minacce come MAC flooding (in cui un attaccante inonda lo switch di frame con MAC fittizi, saturando la CAM table e facendolo passare in modalità hub, favorendo sniffing), spoofing di MAC (un dispositivo assume l’identità MAC di un altro, magari per bypassare filtri MAC ACL o dirottare traffico destinato al legittimo) e attacchi specifici di tecnologie: ad esempio, ARP poisoning (avvelenamento cache ARP) sfrutta il protocollo di risoluzione indirizzi (tra livello 2 e 3) per associare un MAC dell’attaccante all’IP della vittima, di fatto intercettando il traffico locale. Strumenti come ettercap facilitano questo attacco, che può essere mitigato con tecniche come ARP statici o protocolli di sicurezza come DHCP Snooping e Dynamic ARP Inspection sugli switch gestiti. Sul Wi-Fi, il livello 2 è dove operano misure di cifratura come WPA2/WPA3: la protezione delle trame radio con cifre come AES-CCMP avviene qui. Dunque, la robustezza del livello 2 wireless (chiavi forti, autenticazione 802.1X con EAP, ecc.) è essenziale contro sniffing e accessi non autorizzati.
• Livello 3: Rete. È responsabile dell’instradamento (routing) dei pacchetti attraverso reti diverse, dal mittente finale al destinatario finale, potenzialmente passando per più nodi di commutazione (router). Il livello 3 introduce gli indirizzi logici (es. indirizzi IP) e si occupa di trovare percorsi e di gestire la congestione a livello di pacchetto. IP (Internet Protocol) è il protagonista (versione 4 e 6) a questo livello. Altri esempi includono protocolli legacy o specializzati come IPX, AppleTalk (quasi obsoleti) e protocolli di routing come ICMP potrebbe essere considerato tra 3 e 4 (di supporto al funzionamento di IP, es. con ping ed error message). I router operano al livello 3, guardando l’indirizzo di destinazione nei pacchetti IP e inoltrandoli secondo la routing table. La sicurezza a livello 3 coinvolge diversi aspetti: controllo degli accessi IP (liste di controllo accessi su router e firewall che permettono o bloccano traffico in base a IP sorgente/dest, protocollo e porta – benché la porta sia L4), protezione dell’integrità dei pacchetti (qui agisce ad esempio IPsec AH/ESP che aggiunge firma o cifratura a livello IP) e la robustezza contro attacchi di scansione e DoS basati su IP (ping of death, fragmentation attacks). Un amministratore deve implementare filtering appropriato (ad esempio: filtrare pacchetti in ingresso con IP sorgenti privati o palesemente spoofati – BCP 38, ingress filtering; bloccare protocolli non necessari come IPv6 se non in uso, o ICMP solo in modo controllato perché ICMP è utile per la diagnostica ma può essere abusato in tunneling o scansioni). Anche gli attacchi di tracciamento (es. traceroute abusato per mappare la rete) lavorano su livello 3/4 usando TTL manipolato; un SOC potrebbe rilevare e allertare se vede traceroute verso host interni, segno di ricognizione. In sintesi, il livello rete è dove si definiscono i confini della security perimeter: definire quali IP o segmenti possono comunicare, implementare segmentazione della rete (VLAN e routing intervlan con ACL) e applicare tecniche come network address translation (NAT) – che pur essendo nata per risparmiare IPv4, fornisce un effetto collaterale di mascheramento degli IP interni, aggiungendo oscurità verso l’esterno.
• Livello 4: Trasporto. Offre comunicazione end-to-end affidabile o non affidabile tra processi applicativi su host differenti. Due protocolli cardine qui sono TCP (orientato alla connessione, affidabile, con controllo di flusso) e UDP (datagrammi non connessi, non garantiti). Il livello trasporto identifica anche le porte (numeri che distinguono i flussi applicativi: es. porta 80 per HTTP su TCP, 53 per DNS su UDP, ecc.), permettendo la multiplexing di più conversazioni sulla stessa connessione di rete. Qui troviamo anche concetti come segmento (TCP segment) o datagramma (UDP). Dal punto di vista sicurezza, sul livello 4 agiscono molti controlli nei firewall stateful, che monitorano lo stato delle connessioni TCP e possono bloccare tentativi anomali (ad esempio pacchetti TCP non appartenenti ad alcuna connessione nota). Il port scanning è una tecnica di ricognizione di livello 4: un attaccante invia tentativi di connessione su varie porte per scoprire quali servizi sono attivi; strumenti come nmap variano i tipi di pacchetto (SYN scan, ACK scan, UDP scan) per inferire regole firewall e servizi. Un analista deve saper interpretare log come “Dropped packet from X to Y: TCP flags SYN” e capire che è uno scan. Inoltre, attacchi DDoS spesso si manifestano su questo livello: SYN flood (già descritto), o saturazione di porte specifiche (es. attacco a un server web saturando la porta 80 con richieste incomplete). Difese includono meccanismi antidos sui firewall e anche a livello di sistema operativo (stack TCP robusti con backlog di connessioni ampia, cookies, ecc.). I protocolli di trasporto hanno anche implicazioni su performance e perciò su rilevamento anomalie: es. un flusso TCP legittimo ha una certa sincronia tra pacchetti e ack; se un flusso esce dalle statistiche usuali (troppi RST, troppi ritrasmissioni) potrebbe indicare un problema o un attacco in corso di blocco. A livello trasporto si implementa anche la sicurezza delle sessioni in alcuni casi: per es., TLS (il protocollo usato per HTTPS) in realtà risiede sopra TCP (livello 5 OSI se consideriamo session/present, o direttamente come parte dell’applicazione), ma concettualmente fornisce sicurezza a ciò che il trasporto trasmette. In un contesto OSI, potremmo dire che l’inizio handshake TLS è livello 5 sessione (instaura un canale) e la cifratura/decifratura è presentazione (livello 6). Comunque, il responsabile di sicurezza deve sapere che firewall di nuova generazione possono operare fino al livello 7, ma spesso regole efficaci si definiscono su combinazioni di criteri L3/L4 (IP/porta) per bloccare accessi a servizi indesiderati o limitare provenienze.
• Livello 5: Sessione. Fornisce i meccanismi per controllare il dialogo tra due applicazioni, istituendo, gestendo e terminando sessioni di comunicazione. Una sessione è essenzialmente una comunicazione logica di lunga durata tra due entità, che può comprendere più scambi di dati. Funzioni tipiche del livello di sessione includono la gestione delle connessioni (apertura, autenticazione al livello di sessione, chiusura ordinata) e controllo del dialogo (chi può inviare in un dato momento, half-duplex vs full-duplex, sincronizzazione di checkpoint per riprendere trasferimenti interrotti). Nella pratica di Internet, il livello sessione non è molto distinto: protocolli come TLS/SSL possono essere visti come aggiungere una sessione sicura su TCP, o protocolli come NetBIOS session, RPC, PPTP ecc. definiscono sessioni sopra il trasporto. Dal punto di vista sicurezza, qui collochiamo concetti come autenticazione della sessione (per es., in TLS un client e server si autenticano e stabiliscono una sessione cifrata con ID di sessione), oppure gestione delle sessioni applicative (ad esempio i token di sessione HTTP per tenere traccia di un utente loggato su un sito – concettualmente livello 5/7). Le minacce includono il dirottamento di sessione (session hijacking), in cui un attaccante subentra in una sessione attiva rubando credenziali di sessione (es. cookie di autenticazione web non protetto) o per difetti del protocollo (un esempio storico: nel protocollo PPTP VPN c’erano weakness che permettevano di desincronizzare e prendere controllo della sessione). Un altro concetto di sessione è nel checkpointing: alcuni protocolli di trasferimento file lunghi implementano marker di sincronizzazione (per non ricominciare da capo se la sessione cade). Un attaccante potrebbe abusare del meccanismo di ripresa (resumption) se non ben protetto, per forzare trasferimenti incompleti o inserire dati. In contesti moderni, molti di questi dettagli sessione sono integrati nelle applicazioni (livello 7), quindi il livello 5 OSI è spesso citato in teoria più che implementato separatamente. Il coordinatore di sicurezza comunque deve assicurarsi che le sessioni, qualunque sia il contesto, siano protette: ad esempio, nelle applicazioni web la gestione sicura dei token di sessione (randomici, con scadenza, marcati HttpOnly e Secure se cookie) è cruciale per prevenire impersonificazione.
• Livello 6: Presentazione. Si occupa della sintassi e semantica dei dati scambiati tra applicazioni. In pratica, fornisce trasformazioni di dati che permettono a sistemi con convenzioni diverse di comunicare. Ciò include conversioni di formato (esempio: codifica dei caratteri – convertire testo Unicode in ASCII se il destinatario supporta solo quello), serializzazione di strutture complesse in un formato standard (tipo JSON, XML, ASN.1), compressione (per ridurre la mole di dati da trasmettere) e cifratura per garantire confidenzialità. Il livello di presentazione è quindi dove i dati grezzi dell’applicazione vengono preparati per la trasmissione e viceversa all’arrivo vengono rielaborati in forma utilizzabile dall’app. Un esempio concreto: in una connessione HTTPS, il contenuto HTTP vero e proprio viene cifrato a livello presentazione (TLS) e poi passato come flusso cifrato al livello trasporto (TCP) per l’invio. Nella sicurezza informatica, il livello 6 è cruciale perché è dove avvengono crittografia/decrittografia e codifiche. Ad esempio, molti attacchi web come XSS, SQLi, ecc., sfruttano mancate conversioni di formato (un input utente che andava interpretato solo come testo viene invece eseguito come codice). Una robusta “presentazione” in un’applicazione web significa escaping appropriato di caratteri speciali quando dati non fidati vengono inseriti in HTML, SQL, XML, ecc., per prevenire l’esecuzione indesiderata – in altri termini, difese come output encoding per XSS o query parametrizzate (che separano i dati dalla sintassi SQL) attengono a questo concetto. Dal punto di vista delle comunicazioni di rete, standard come TLS garantiscono che i dati in presentazione siano cifrati end-to-end: un responsabile deve assicurarsi che i servizi critici usino protocolli sicuri (es. preferire FTPS/SFTP a FTP in chiaro, HTTPS a HTTP, SSH a Telnet, ecc.) cosicché anche se il traffico viene intercettato a livello inferiore, risulti incomprensibile. Inoltre, il livello presentazione include la gestione di certificati digitali e formati di scambio: competenze in PKI e negoziazione di protocolli (quali ciphersuite TLS sono consentite, usi di TLS 1.3 vs deprecazione di SSLv3/TLS1.0 insicuri) rientrano tra quelle richieste a un esperto di sicurezza per garantire che i dati “presentati” in rete siano sempre protetti secondo lo stato dell’arte.
• Livello 7: Applicazione. È il livello più alto, quello con cui interagiscono direttamente le applicazioni software e, in ultima analisi, l’utente finale. Fornisce quindi i servizi di rete più vicini all’utilizzatore: protocolli di posta elettronica (SMTP per inviare, IMAP/POP3 per ricevere), web (HTTP/HTTPS), trasferimento file (FTP, SFTP), servizi directory (LDAP), accesso remoto (SSH, Telnet) e molti altri servizi specializzati (DNS stesso è considerato applicazione nel modello OSI, così come protocolli voce su IP come SIP/VoIP, etc.). Al livello applicazione si definiscono i formati dei messaggi di alto livello e le procedure di scambio specifiche di quello use case. Ad esempio, HTTP definisce come un client può richiedere una risorsa con un verbo (GET, POST, etc.) e come un server risponde con un codice di stato e eventuale contenuto; SMTP definisce i comandi per trasmettere email tra server; SSH definisce come incapsulare un terminale remoto sicuro. Dal punto di vista sicurezza, il livello applicazione è dove tipicamente risiedono le vulnerabilità logiche e di input più complesse: injection, buffer overflow applicativi, deserializzazione insicura, autenticazione debole, autorizzazioni errate e così via (molte delle categorie OWASP Top 10 per applicazioni web sono questioni di livello 7). Un responsabile per gli incidenti deve avere familiarità con i protocolli applicativi per riconoscere anomalie: es. traffico HTTP verso un server web che contiene comandi sospetti ( /admin/delete.php?id=1;DROP TABLE users) potrebbe indicare un attacco SQLi; oppure richieste LDAP malformate potrebbero segnalare un tentativo di exploit di Active Directory. Anche la modellazione delle minacce avviene in gran parte a livello applicazione: qui si chiede “cosa succede se un utente malintenzionato invia dati oltre i limiti?”, “cosa se effettua sequenze di API fuori ordine?”, etc. Ogni protocollo ha le sue particolarità: FTP ad esempio espone credenziali in chiaro se non è protetto e inoltre utilizza porte dinamiche (che i firewall devono gestire in modo speciale, con moduli helper, altrimenti può essere abusato per bypassare porte); SMTP può essere sfruttato per relay non autorizzati se non configurato bene (open relay) e per diffondere phishing/malware; HTTP è il veicolo di tantissimi attacchi, dai malware via download, al phishing via siti clone, fino alle exploit di librerie web.

Ai fini di prevenzione e gestione degli incidenti, è utile dotarsi di strumenti di Application Layer Security: WAF (Web Application Firewall) per analizzare il traffico HTTP e bloccare pattern malevoli noti (anche se non sostituisce il secure coding, è un utile layer difensivo), antivirus/antimalware gateway per controllare file trasferiti via protocolli applicativi (es. scanner SMTP per allegati email, o proxy HTTP con antimalware integrato) e sistemi di Data Loss Prevention (DLP) che analizzino il contenuto applicativo in uscita (es. per individuare stringhe che sembrano numeri di carta di credito o dati classificati e bloccarne l’esfiltrazione via email/web). Inoltre, la telemetria di livello 7 (log applicativi) è fondamentale in fase di risposta: i log di un server web (es. access log di Apache/Nginx) possono mostrare un pattern di exploit (decine di tentativi di accedere a wp-admin.php indicano un bot che cerca di violare WordPress), i log di un database possono mostrare query strane (tentativi di selezionare tabelle di sistema da un’app che non dovrebbe), i log di un server DNS possono indicare tunneling come detto. Un SOC ben organizzato correla eventi su più livelli: ad esempio, un alert IDS su un payload sospetto a livello 4+7 (un pacchetto TCP con dentro un comando SQL anomalo) incrociato con un log applicativo di errore database può confermare un tentativo di SQL injection riuscito o meno.

Integrazione e concetti trasversali: Una cosa importante da capire è che i livelli non sono completamente isolati: ogni livello aggiunge il suo overhead e le sue vulnerabilità possono propagarsi. Ad esempio, un attacco DDoS a livello 7 (come HTTP Flood, numerosissime richieste web) sfrutta comunque la connessione TCP sottostante: mitigarlo può richiedere azioni a livello 7 (rispondere con CAPTCHA, tarpit) ma anche a livello 4 (limitare connessioni per IP) e livello 3 (filtrare IP noti malevoli). Oppure, una falla a livello 2 come ARP poisoning può portare a Man-in-the-Middle che intercetta e poi manipola dati di livello 7 (inserendo script malevoli nel traffico web, se questo non è cifrato). Conoscere l’OSI aiuta a compartimentalizzare i problemi e a parlare con gli specialisti giusti: ad esempio, se si riscontra che “le email non arrivano a destinazione”, potrebbe essere un problema di livello 7 (misconfigurazione SMTP, o bloccate per contenuti), livello 3 (routing verso il mail server errato) o altro; il modello OSI offre un approccio per isolare: ping (L3), telnet porta 25 (L4), analisi logs SMTP (L7) e così via. Nella risoluzione di incidenti, spesso si “risale la pila OSI” per individuare dove esattamente risiede il fault o l’attacco.

In conclusione, il modello OSI con i suoi 7 livelli – Fisico, Collegamento dati, Rete, Trasporto, Sessione, Presentazione, Applicazione – è uno strumento concettuale che aiuta a progettare, proteggere e diagnosticare le reti di calcolatori. Ogni livello introduce considerazioni di sicurezza specifiche e un responsabile per la sicurezza informatica deve averne padronanza per implementare una strategia di difesa in profondità: multiple protezioni sovrapposte attraverso la pila, cosicché anche se un attacco aggira un livello (es. malware che viaggia cifrato su HTTPs – invisibile al firewall L7), venga intercettato a un altro (es. analisi comportamentale al livello applicazione endpoint, o decrittazione in un proxy per l’ispezione). Lo standard ISO/OSI stesso, pur teorico, ha generato protocolli e influenzato architetture – conoscere ad esempio che X.509 (certificati) nasce da standard OSI di presentazione, o che LDAP è figlio di X.500 (applicazione OSI), arricchisce la comprensione storica e pratica che torna utile quando si incrociano sistemi eterogenei (ad es. integrazione di vecchi sistemi mainframe o SCADA che a
volte ancora usano stack particolari).

Fondamenti di algoritmi

Un algoritmo è una procedura definita, costituita da una sequenza finita di istruzioni, che risolve un problema o svolge un determinato compito. In informatica, gli algoritmi rappresentano le ricette operative per qualsiasi programma: dal semplice calcolo di una somma alla crittografia avanzata, tutto si riduce a passi elementari che il calcolatore esegue. Formalmente, si richiede che un algoritmo abbia alcune proprietà: finitezza (deve terminare in un numero finito di passi), determinismo (stessi input producono stessi output, a meno di componenti aleatorie volute), non ambiguità (ogni passo è definito in modo univoco, interpretabile senza dubbio) e generalità (risolve una classe di problemi, non un solo caso specifico).

Esempi di algoritmi classici includono: l’algoritmo di ordinamento (ordinare una lista di numeri o stringhe – con varianti famose come QuickSort, MergeSort, HeapSort, etc.), algoritmi di ricerca (trovare un elemento in una collezione – es. ricerca lineare vs ricerca binaria in una lista ordinata), algoritmi di grafi (cammini minimi, visite in profondità/ampiezza, ecc.), algoritmi di ottimizzazione (zaino, percorso più breve, flusso massimo) e tanti altri. Nella pratica quotidiana, un professionista di sicurezza può incontrare algoritmi ad esempio nell’analisi di performance di un sistema (sapere se una certa operazione è O(n) lineare o O(n^2) quadratica aiuta a capire se un attacco di stress potrebbe causare rallentamenti significativi), oppure nella comprensione di meccanismi crittografici (dove la solidità di un algoritmo di cifratura spesso si basa su problemi computazionalmente difficili, come la fattorizzazione dei grandi numeri primi per RSA).

Complessità computazionale: uno degli aspetti fondamentali nello studio degli algoritmi è la loro complessità, cioè la quantità di risorse (tempo di calcolo, spazio di memoria) che richiedono in funzione della dimensione dell’input. La complessità in termini di tempo viene di norma espressa tramite la notazione O-grande, che fornisce un limite superiore asintotico sulla crescita del costo computazionale al crescere di n (taglia input). Ad esempio, dire che un algoritmo è O(n log n) significa che per gestire input più grandi, il suo tempo cresce proporzionalmente a n log n. In generale, classifichiamo le complessità asintotiche in classi come: costante O(1), logaritmica O(log n), lineare O(n), quasi-lineare O(n log n), quadratica O(n^2), cubic O(n^3), …esponenziale O(2^n) e oltre. Chiaramente, algoritmi più efficienti sono preferibili – un problema risolvibile con un algoritmo O(n) sarà gestibile per input grandi molto meglio di uno O(n^2). Per contestualizzare: in un attacco di forza bruta, provare tutte le combinazioni di una password di lunghezza n può essere ~O(k^n) (esponenziale nel numero di caratteri se ogni posizione ha k possibilità), il che spiega perché aumentando lunghezza e complessità delle password la ricerca esaustiva diventa impraticabile.

Per un responsabile alla sicurezza, la teoria degli algoritmi ha ricadute pratiche. Un esempio evidente è nella crittografia: la sicurezza di molti algoritmi crittografici è legata alla complessità computazionale di certi problemi. RSA, ECC, Diffie-Hellman si basano sul fatto che alcuni problemi (fattorizzazione di interi grandi, logaritmo discreto in certi gruppi) sembrano richiedere tempo esponenziale con i migliori algoritmi noti: quindi, con chiavi abbastanza lunghe, la brute force diventa impossibile nei tempi dell’universo (a meno di progressi algoritmici o quantistici). Comprendere questo aiuta a scegliere parametri sicuri: ad esempio, sapere che il migliore algoritmo di fattorizzazione noto ha complessità sub-esponenziale (sì, c’è il Number Field Sieve che è circa O(exp( (64/9)^(1/3) * (log n)^(1/3) * (log log n)^(2/3) )) ), consente ai crittografi di stimare quanti bit di RSA servono (oggi almeno 2048-bit) per resistere X anni. Un altro esempio: gli algoritmi di hashing (SHA-256, SHA-3) sono progettati per essere veloci da calcolare ma non invertibili senza provare molte possibilità. La difficoltà di trovare collisioni in SHA-256 è legata a dover provare 2^128 operazioni (complessità bruteforce). Se un attaccante scoprisse un algoritmo molto migliore (es. O(2^64)), quell’hash non sarebbe più sicuro. Dunque, chi lavora in sicurezza deve seguire anche le scoperte nel mondo algoritmi (ad esempio, i recenti progressi su SHA-1 collisioni hanno reso questo hash deprecato). E ovviamente il calcolo quantistico promette di ridurre drasticamente la complessità di alcuni problemi: Shor’s algorithm porta la fattorizzazione a complessità polinomiale, distruggendo RSA/ECC una volta che avremo quantum computer abbastanza grandi.

Al di là della crittografia, l’analisi degli algoritmi è utile per ottimizzare le difese e attacchi. Dal lato difensivo: un SIEM che raccoglie log deve avere algoritmi di correlazione efficienti, altrimenti con milioni di eventi genererà ritardi – un buon coordinatore sa scegliere strumenti validi o architetture big data (es. utilizzare motori come Elasticsearch che usano algoritmi di ricerca efficaci). Dal lato offensivo: alcuni attacchi DoS sfruttano algorithmic complexity attacks, ad esempio l’HashDoS (inviare tanti input calibrati per provocare collisioni in una tabella hash usata dall’applicazione, degradando le look-up da O(1) a O(n) e bloccando il server) – questo fu dimostrato su Java, PHP e altri linguaggi, costringendo a migliorare gli algoritmi di hashing o introdurre randomizzazione. Un altro esempio sono i ReDoS (Regular Expression Denial of Service): usare input particolari per mandare in worst-case l’algoritmo di matching delle espressioni regolari (che in alcuni engine può diventare esponenziale). Questi sono attacchi sottili che richiedono comprensione di come un algoritmo risponde al worst-case.

Strutture dati e algoritmi: spesso insieme agli algoritmi si studiano le strutture dati (array, liste, pile, code, alberi, grafi, tabelle hash, ecc.), che influiscono sulle prestazioni. Una buona scelta di struttura può prevenire inefficienze – es: cercare elementi duplicati in un array fa O(n^2) naive, ma usando una hash set diventa O(n) mediamente. Nella sicurezza software, questo significa anche prevenire vulnerabilità di prestazioni: se un input controllato dall’utente potrebbe indurre il programma a usare un algoritmo quadratico, un attaccante può sfruttarlo per rallentarlo. Ad esempio, generare intenzionalmente situazioni pessime (come l’HashDoS citato). Dunque, parte del secure coding è anche evitare costrutti algoritmicamente rischiosi o porre limiti (ad esempio, limitare lunghezza massima di input per evitare loop troppo lunghi).

P vs NP e problemi intrattabili: un concetto teorico ma con implicazioni è la distinzione tra problemi in P (risolvibili in tempo polinomiale) e in NP (verificabili in polinomiale, ma non si conosce algoritmo polinomiale per risolverli). Molti problemi di ottimizzazione o ricerca combinatoria sono NP-difficili (come il Traveling Salesman, il Subset Sum, ecc.). Per la sicurezza, questo spiega perché certi obiettivi dell’attaccante sono difficili: ad esempio, craccare un cifrario robusto equivale a cercare nello spazio delle chiavi (che cresce esponenzialmente col numero di bit). Oppure, un software antivirus che voglia decidere in generale se un programma è malevolo va incontro al problema della fermata e questioni indecidibili; per questo gli antivirus usano euristiche imperfette – capire i limiti computazionali ci fa comprendere perché non esiste e probabilmente non esisterà mai “l’algoritmo perfetto” per distinguere malware da software legittimo in ogni caso (problema indecidibile, riducibile all’halting problem). Quindi si lavora per euristiche (firma, comportamento) sapendo che esisteranno falsi negativi/positivi.

Algoritmi distribuiti e fault tolerance: In un contesto come la sicurezza nazionale, con infrastrutture distribuite, è importante conoscere anche gli algoritmi per consenso distribuito (es. Paxos, Raft) e per gestione di guasti – questi sono algoritmi non banali che garantiscono consistenza e disponibilità su più nodi; la sicurezza di sistemi come blockchain, oppure di sistemi cluster per servizi critici, discende dalla solidità di tali algoritmi. Ad esempio, la robustezza di una blockchain dipende dall’algoritmo di consenso (Proof of Work è un “algoritmo” in senso lato con complessità regolata dalla difficoltà, BFT consensus ha tolleranza fino a f nodi corrotti se N > 3f, ecc.).

In sintesi, i fondamenti di algoritmi equipaggiano il professionista con un approccio analitico ai problemi: capire l’ordine di grandezza di un attacco brute-force, valutare l’impatto prestazionale di una misura di sicurezza (es. criptare tutto il traffico aggiunge overhead, ma di quanto?), scegliere strumenti in base alla scala (un SIEM con algoritmi subottimali funzionerà su 1k eventi al secondo ma non su 100k eps). La è quindi parte del bagaglio di un coordinatore, sebbene non debba implementare algoritmi da zero quotidianamente, deve saperne leggere i risultati e conversarci: ad esempio, comprendere un report che dice “la complessità computazionale di rompere AES-256 è di 2^254 operazioni, che con i mezzi attuali è impraticabile” oppure “un attacco di tipo meet-in-the-middle riduce la complessità su 2DES da 2^112 a 2^57, ecco perché 2DES non è considerato sicuro”. Senza basi sugli algoritmi, tali affermazioni sarebbero aride; con le basi, diventano guida all’azione (passare direttamente ad AES o 3DES perché 2DES è debole, ecc.). Dunque la padronanza degli algoritmi e della loro complessità permette di valutare rischi in modo quantificabile e di progettare contromisure efficaci.

Linguaggi di programmazione (imperativi, di scripting, orientati agli oggetti)

I linguaggi di programmazione sono gli strumenti con cui vengono implementati gli algoritmi e le funzionalità software. Esistono centinaia di linguaggi, ma essi possono essere classificati per paradigma in base allo stile con cui si descrivono le istruzioni e i dati. In questa sezione ci focalizziamo su tre categorie importanti: linguaggi imperativi, linguaggi di scripting e linguaggi orientati agli oggetti.
Ognuno di questi paradigmi presenta caratteristiche peculiari, vantaggi, limitazioni e implicazioni per la sicurezza del codice prodotto.

Linguaggi imperativi (procedurali)

La programmazione imperativa è il paradigma classico in cui un programma è visto come una sequenza di istruzioni che modificano lo stato del programma stesso (variabili, strutture dati) per ottenere il risultato desiderato. In altre parole, l’attenzione è sul come fare le cose: si specificano esplicitamente i passi da seguire, in ordine, includendo strutture di controllo come assegnamenti, cicli ( for , while ), condizionali ( if / else ), chiamate di funzioni/procedure, ecc. La maggior parte dei linguaggi tradizionali rientrano in questo paradigma: linguaggi procedurali come C, Pascal, BASIC, Fortran (dove esistono procedure e funzioni come unità di modularizzazione) sono imperativi; anche il linguaggio Assembly (di basso livello) è imperativo puro, in quanto si scrivono istruzioni macchina che cambiano registri e memoria step-by-step. Persino linguaggi come Java o Python supportano uno stile imperativo (Python, ad esempio, pur essendo multi-paradigma, permette di scrivere codice procedurale imperativo). Caratteristiche tipiche di linguaggi imperativi/procedurali includono la gestione esplicita della memoria (in C, ad esempio, con malloc / free o lo stack frame delle funzioni), l’uso di variabili mutate nel corso dell’esecuzione e un flusso di controllo che può usare costrutti come goto (nei casi più base) o strutture strutturate. Il codice imperativo rispecchia l’architettura di von Neumann: infatti questi linguaggi sono “vicini al modo in cui lavora l’elaboratore”, aggiornando locazioni di memoria e eseguendo istruzioni in sequenza.

Implicazioni per la sicurezza: nei linguaggi imperativi a basso livello (es. C, C++, assembler) sta l’origine di molte vulnerabilità classiche, proprio perché lasciano molto controllo (e responsabilità) al programmatore. Ad esempio, la gestione manuale della memoria in C/C++ è fonte di bug quali buffer overflow, use-after-free, double free, integer overflow e così via, che se non prevenuti portano ad exploit di memoria e code execution arbitraria. Un responsabile della sicurezza deve conoscere bene questi rischi: ad esempio, l’attacco stack buffer overflow sfrutta il fatto che in C si possono scrivere dati fuori dai limiti di un array, andando a sovrascrivere il return address di funzione nello stack; mitigazioni come canary, ASLR, NX bit sono stati sviluppati per attutire il problema, ma la vera soluzione è scrivere codice robusto (o usare linguaggi che prevengono out-of-bounds, come Java o Rust). Nei contesti dove la performance e il controllo spingono a usare C/C++ (kernel OS, driver, sistemi embedded, highperformance computing), è cruciale adottare standard di codice sicuro (es. CERT C Coding Standard) e strumenti di analisi (sanitizer, static analysis) per ridurre i bug imperativi.

Nei linguaggi imperativi di più alto livello (es. Java, che è orientato agli oggetti ma si può vedere come imperativo nel flusso; o Python se scrivi script procedurali), molti errori di memoria sono evitati (garbage collector, check runtime su array, ecc.), ma persistono problemi come la gestione delle condizioni di errore, la concorrenza (race conditions se thread paralleli accedono a variabili condivise), etc. Il paradigma imperativo incoraggia l’uso di stato mutabile e questo è terreno di race condition e TOCTOU (Time-of-check to time-of-use) bugs: ad esempio, un programma imperativo multi-thread potrebbe controllare l’esistenza di un file e poi aprirlo; se tra check e open passa tempo e un attaccante cambia il file (symlink attack), abbiamo un TOCTOU bug. Un responsabile deve sapere che certe classi di vulnerabilità (soprattutto in codice multi-thread o multi-processo) derivano dalla difficoltà di ragionare su stato mutabile e tempi di esecuzione – ecco perché paradigmi alternativi (es. la programmazione funzionale, che evita stato mutabile) vengono talvolta adottati per ridurre bug, ma la maggioranza del codice rimane imperativo.

In campo offensivo, conoscere la natura imperativa dei programmi aiuta a fare reverse engineering: ad esempio, i malware scritti in C/C++ compilano in assembly macchina e un analista dovrà interpretare quell’assembly come un flusso di operazioni (imperative) per capire cosa fa il malware. Saper leggere pseudocodice imperativo o flusso di un binario è competenza essenziale in analisi malware/forense.

Esempi di linguaggi imperativi popolari: C (usato per kernel, sistemi operativi, software di rete; critico per exploit), C++ (che aggiunge oggetti ma resta principalmente imperativo, usato in applicativi veloci, anche in diversi malware avanzati), Ada (in ambito aerospaziale, focus su sicurezza e affidabilità), Go (Google Go, imperativo concurrent, con gestione memoria automatica e forte supporto al multithread – spesso usato per strumenti di rete e cloud, la sua semplicità riduce alcune classi di bug rispetto a C) e tanti altri incl. Rust (che pur supportando vari stili viene spesso usato in modo imperativo ma “memory safe” grazie al suo sistema di proprietà).

Linguaggi di scripting

Un linguaggio di scripting è tipicamente un linguaggio interpretato, di alto livello, pensato per automatizzare compiti in un ambiente runtime esistente. Il termine deriva dal fatto che inizialmente questi linguaggi erano usati per scrivere script (copioni) che eseguono operazioni su sistemi operativi o applicazioni, invece che per sviluppare applicazioni stand-alone complesse. Caratteristiche comuni dei linguaggi di scripting includono: tipizzazione dinamica (non occorre dichiarare esplicitamente il tipo delle variabili), gestione automatica della memoria (garbage collection), sintassi semplice e concisa, e disponibilità di un ambiente interpretativo (shell, REPL) dove eseguire i comandi al volo.
Esempi classici sono bash/sh (scripting di shell Unix), JavaScript originariamente scripting client-side per i browser, oggi grazie a Node.js usato anche lato server), Python, Perl, Ruby, PHP, PowerShell (scripting avanzato su Windows), ecc. Questi linguaggi spesso interagiscono con un sistema più grande: ad esempio, JavaScript in una pagina web manipola l’HTML/CSS e il browser funge da runtime; Python può essere usato come script per automazione di task di sistema, o incorporato in applicazioni; PHP è un linguaggio di scripting lato server per generare contenuti web dinamici; Bash orchestrа comandi del sistema operativo e programmi.

Il vantaggio dei linguaggi di scripting è la produttività e la facilità d’uso: permettono di sviluppare rapidamente funzionalità senza gestire i dettagli di basso livello (gestione memoria, compilazione). Questo li rende ideali per la scrittura di strumenti di automazione, estrazione di dati, prototipazione, e (nel nostro contesto) per molti script e tool di sicurezza. Un analista di sicurezza scrive comunemente script Python o Bash per analizzare log, per eseguire scansioni personalizzate, per automatizzare reazioni a incidenti (es. uno script che disattiva automaticamente un account sospetto su più sistemi, integrandosi via API).

Implicazioni per la sicurezza: Da un lato, usando linguaggi di scripting si evitano molte vulnerabilità tipiche del C (buffer overflow, ecc.), quindi per script e tool interni spesso si preferisce Python o PowerShell per ridurre rischi di bug memory corruption. Dall’altro lato, i linguaggi di scripting portano sfide proprie: essendo spesso interpretati, il codice può essere più facilmente letto/modificato da un attaccante se trova gli script sul sistema (a meno di offuscazioni); e poiché molti sono usati in contesti di elevati privilegi (si pensi a script Bash lanciati come root per manutenzioni, o script PowerShell per amministrazione di dominio), diventano bersagli: gli attaccanti possono tentare di alterare script esistenti (supply chain, se uno script viene scaricato da internet e poi eseguito con fiducia – come a volte succede con script di installazione), oppure usarli a proprio vantaggio (es. se un webserver permette di caricare ed eseguire file PHP, l’attaccante può caricare una web shell PHP, sfruttando il linguaggio di scripting del server per eseguire comandi arbitrari sul sistema). Ciò sottolinea la necessità di trattare gli script come codice a tutti gli effetti: revisionare la sicurezza, proteggerli con controlli di integrità, limitarne i permessi di esecuzione, ecc.

Nei sistemi, spesso i linguaggi di scripting fungono da collante: ad esempio, un attaccante che abbia compromesso un server Linux potrebbe scrivere uno script bash per mantenere la persistenza (inserendolo magari in /etc/init.d per avviarsi al boot) o per esfiltrare dati periodicamente. Dunque, chi gestisce la sicurezza deve monitorare non solo eseguibili compilati ma anche i file di script, e utilizzare strumenti tipo OSSEC o Tripwire per notare modifiche anomale a script chiave.
Le applicazioni web scritte in linguaggi di scripting (PHP, Python via Django/Flask, JavaScript via Node.js) ereditano i rischi di vulnerabilità applicative (XSS, injection, etc.), con la differenza che essendo i linguaggi spesso molto dinamici può essere più facile introdurre errori se non si seguono regole (es. in PHP, un tempo la registrazione globale delle variabili portava a vulnerabilità se non attenta; in Node.js, la presenza di un ricco ecosistema di package richiede attenzione alla supply chain e a aggiornare le dipendenze per evitare moduli malevoli).

Esempi pratici in scenario di sicurezza: uno script Python può essere scritto per analizzare i pacchetti di rete (usando Scapy) e rilevare un pattern di scansione, inviando alert. Oppure script Bash vengono usati negli SIEM per parsare formati di log e normalizzarli. Con PowerShell, un team di incident response può interrogare in modo massivo tutte le macchine di un dominio cercando indicatori di compromissione – infatti, oggi gli attaccanti stessi usano PowerShell per i loro scopi (PowerShell Empire e altri framework di post- exploitation): ciò perché con script si integrano nativamente nell’ambiente senza portare eseguibili che possano essere bloccati da whitelist. Un reaponsabile deve essere consapevole di queste tattiche e, ad esempio, abilitare PowerShell Logging e Constrained Language Mode su host Windows per avere visibilità e limitare l’uso malevolo.

In sintesi, i linguaggi di scripting sono potenti e flessibili; per la difesa informatica sono armi essenziali (per automazione e integrazione), ma vanno gestiti con regole di sicurezza come qualsiasi codice: controllo delle entrate (validazione input negli script), least privilege (non far girare script con privilegi oltre il necessario), mantenimento (aggiornare le versioni interpreter – molte falle in PHP/Python stesso corrette con patch), e rilevamento di abuso (monitorare esecuzioni anomale, come un utente non amministrativo che improvvisamente lancia script PowerShell con comandi di dumping credenziali).

Linguaggi orientati agli oggetti (OOP)

La programmazione orientata agli oggetti (Object-Oriented Programming, OOP) è un paradigma in cui il software viene modellato come un insieme di oggetti che interagiscono tra loro scambiandosi messaggi (chiamando metodi l’uno dell’altro). Un oggetto incapsula stato (dati, sotto forma di attributi/variabili) e comportamento (funzionalità, sotto forma di metodi/funzioni). I linguaggi OOP offrono costrutti come classi (definizioni generiche da cui istanziare oggetti concreti), ereditarietà (una classe può derivare da un’altra ereditando attributi e metodi, consentendo specializzazione e riuso del codice), polimorfismo (il fatto che chiamate a metodi possano riferirsi a implementazioni diverse in classi diverse, tipicamente via overriding – es. diversi oggetti tipo Figura con metodo disegna() implementato diversamente in Cerchio, Quadrato), e incapsulamento (detto sopra: la capacità di nascondere i dettagli interni di un oggetto e offrire solo interfacce pubbliche – spesso con modificatori di accesso come public/private/protected).

L’OOP nasce per gestire meglio la complessità di grandi progetti software, modellando entità vicine al dominio reale e promuovendo modularità e riusabilità. Ad esempio, in un sistema bancario si potrebbero avere classi Conto, Transazione, Cliente con relazioni di composizione e specializzazione (un ContoCorrente estende Conto aggiungendo un fido, etc.). Linguaggi strettamente OOP includono Java, C#, C++ (ibrido, multi-paradigma ma con forte supporto OOP), Python (multi-paradigma ma con OOP completo), Ruby, JavaScript (che in realtà è basato su prototipi, ma concettualmente OOP), ecc. Oggi, OOP è forse il paradigma dominante nello sviluppo di applicazioni enterprise.

Implicazioni per la sicurezza: la programmazione a oggetti porta benefici di organizzazione, ma introduce anche superfici di attacco peculiari. Ad esempio, la presenza di gerarchie di classi e funzioni virtuali apre il fianco a attacchi come l’overwrite di puntatori virtuali in exploit memory corruption (in C++ un oggetto ha un vtable pointer – se un buffer overflow sovrascrive quel puntatore, un attaccante può far eseguire codice arbitrario quando il programma chiamerà un metodo virtuale dell’oggetto). Questa è una considerazione bassa, valida solo in linguaggi non memory-safe (C++): mitigazioni come Control Flow Guard di Microsoft cercano proprio di impedire salto a vtable rogue.

Dal punto di vista di design, l’OOP a volte incoraggia un’eccessiva fiducia sugli oggetti – ad esempio, concetti come l’esecuzione di codice mobile: Java Applet, ActiveX, .NET assemblies, tutti casi in cui oggetti provenienti da terze parti vengono eseguiti localmente, con meccanismi di sandbox vari (Java aveva il security manager per applet, ActiveX si basava su firme digitali – con noti problemi se l’utente autorizzava un controllo malevolo). Questo scenario di mobile code necessita che i runtime siano robusti nel far rispettare i confini (spesso non lo furono, portando a deprecazione di tali tecnologie).

Un altro punto: i framework ad oggetti (tipici in Java, C#) che fanno ampio uso di riflessione e serializzazione. La serializzazione di oggetti è la capacità di convertire un oggetto in una forma (tipicamente binaria o testuale) per salvarlo o trasmetterlo, e poi ricostruirlo. Questo meccanismo ha portato a exploit come le deserialization vulnerabilities: se un’app accetta da input un oggetto serializzato (ad esempio, un token di sessione Java serializzato inviato nel cookie) un attaccante potrebbe manipolarlo per far istanziare oggetti malevoli o con stati inconsistenze. Ci sono state grosse vulnerabilità (es. CVE di Apache Commons-Collections e altri, dove un oggetto opportunamente costruito portava all’esecuzione di comandi arbitrari durante la deserializzazione, perché la classe aveva blocchi statici o metodi finalize con chiamate pericolose). Un responsabile deve conoscere questi pattern: ad esempio, in pen test su applicazioni Java enterprise, la deserializzazione non sicura è un must-check. La best practice è evitare la deserializzazione di oggetti da fonti non fidate, o usare formati sicuri (JSON, protocolli con schema), o whitelisting di classi deserializzabili.

Controllo degli accessi a oggetti: OOP a volte induce a pensare che i controlli possano essere fatti a livello di oggetto, ma in ambienti multi-utente/multi-tenant non basta. Ad esempio, in un’app web OOP potrebbe esserci metodo Documento.approva(); ma bisogna assicurarsi a livello applicativo che l’utente X possa approvare solo i documenti di sua competenza. Ciò porta a vulnerabilità come Insecure Direct Object Reference (IDOR): se l’app espone un endpoint /documento/approva?id=123 che chiama internamente doc.approva(), un utente malintenzionato potrebbe fornire un id di un documento che non dovrebbe poter modificare e se manca il controllo, l’oggetto viene comunque recuperato e il metodo invocato (violazione autorizzazione). L’approccio OOP puro a volte fa sottovalutare questo – perché a livello di codice, chiamare il metodo è lecito, ma manca il contesto di sicurezza. Quindi, un principio: integrare controlli di autorizzazione in tutti i metodi sensibili, oppure usare un framework di sicurezza (es. Spring Security) che si integri con l’OOP (annotation tipo @PreAuthorize su metodi, ecc.).

Benefici OOP per la sicurezza: d’altro canto, se ben applicato, OOP migliora la sicurezza del codice: l’incapsulamento può prevenire accessi indesiderati – se tutti gli campi sono private e l’oggetto valida i dati tramite setter, è più difficile corrompere lo stato. L’ereditarietà e polimorfismo possono favorire la scrittura di checker di sicurezza generici: ad esempio, una classe base Utente con metodo virtuale haPermesso(azione) può essere implementata diversamente in UtenteStandard e Admin, permettendo all’app di chiedere genericamente utente.haPermesso("DELETE_USER") senza conoscere la classe concreta – design pulito che centralizza logica di auth. Tuttavia, se un attaccante riesce a far istanziare una sottoclasse controllata (vedi problema deserialization su classpath), quell’interfaccia generica potrebbe rispondere “sì ho permesso” falsamente. Perciò la riflessione insegna: l’OOP va usato con coscienza e meccanismi magici come riflessione, dependency injection, ecc. vanno vigilati. Ad esempio, i container di inversion of control (Spring, etc.) automaticamente viranano dipendenze tra oggetti; se configurati male, potrebbero esporre bean sensibili su canali remoti (vedi ad es. JMX misconfigurato, o endpoint actuator in Spring Boot esposti senza auth, che permettono di manipolare runtime).

In termini di linguaggi concreti: Java e C# sono fortemente tipizzati e gestiti, riducono molti errori (no buffer overflow classici), ma ricordiamo incidenti come Log4Shell (una vulnerabilità in un logger che attraverso un lookup JNDI permetteva di scaricare un oggetto remoto – combinazione di serializzazione, rete e riflessione). Dunque, anche se il linguaggio previene certi bug, rimane la superficie dei runtime environment (JVM, .NET) e delle librerie di base. C++ aggiunge OOP al C ma mantiene la pericolosità del controllo manuale: così somma rischi (memory + OOP). Sviluppatori esperti possono scrivere codice sicuro, e moderne guidelines (C++ Core Guidelines) spingono a usare costrutti sicuri (smart pointer invece di raw pointer, etc.), ma molto codice legacy è vulnerabile. Python, JavaScript, PHP, Ruby supportano OOP ma in modo dinamico: qui la flessibilità è massima (es. in Python puoi aggiungere attributi a runtime agli oggetti, in JavaScript modificare prototipi al volo), e questo dinamismo può essere sfruttato malevolmente. Ad esempio, Prototype Pollution in JavaScript: se una libreria non isola bene i dati, un attaccante può iniettare proprietà nell’Object prototype globale, influenzando tutti gli oggetti (impatto a cascata su app intera). Ciò evidenzia che la surface di errori si sposta: meno memory corruption, più logiche e inconsistenze.

Paradigmi misti: molti team oggi adottano linguaggi multi-paradigma (es. Python, JavaScript) o abbracciano stili come la programmazione funzionale all’interno di contesti OOP (es. metodi immutabili, uso di lambda e stream in Java). La programmazione funzionale riduce certi bug (immutatibilità -> no race, no side effects difficili), ma non sempre è praticabile da sola (sistemi I/O, UI etc. spesso sono più facilmente espressi con oggetti). Tuttavia, un responsabile dovrebbe promuovere “il giusto strumento per il lavoro”: in componenti dove la robustezza è critica, valutare linguaggi memory-safe (Java, C#) o addirittura “provably safe” (es. Rust in sistemi), oppure script come Python per prototipi e analisi rapida sapendo che saranno un po’ più lenti. Per parti performance-critical ma delicate, considerare tecniche di verifica (es. strumenti di static analysis, o addirittura approcci formali se giustificato, come SPARK/Ada per software militare).

Sicurezza e ciclo di vita del software: indipendentemente dal linguaggio o paradigma, contano i processi: code review, static analysis, fuzzing, patching, gestione dipendenze (questo soprattutto in scripting: pip/npm composer – supply chain risk). Un responsabile dovrebbe assicurarsi che i team di sviluppo seguano secure coding guidelines e che ogni linguaggio usato abbia i suoi checker (es. linters, SonarQube ruleset per Java, ESLint/Retire.js per JS, Bandit per Python, PHPStan per PHP, ecc.).

In conclusione, comprendere i vari tipi di linguaggi e paradigmi consente a un responsabile della sicurezza di dialogare efficacemente con gli sviluppatori e valutare i rischi del software in esame. Ad esempio, se un nuovo sistema da proteggere è scritto in C++ con moduli Python embedded (come a volte succede in tool scientifici), egli saprà che deve considerare sia vulnerabilità a basso livello (C++) sia di alto livello (injection possibili in Python eval? ecc.). Se invece la sua organizzazione passa a microservizi in Node.js e Go, studierà gli specifici pitfalls (Prototype pollution, moduli npm malevoli, vs concurrency issues e memory usage in Go). In definitiva, la diversità di linguaggi riflette la diversità di problemi da risolvere; per la sicurezza informatica, ogni linguaggio/paradigma aggiunge un tassello: conoscendoli, si può implementare difese profonde (ad esempio: firewall WAF che riconosce attacchi comuni in PHP vs in Node), e soprattutto prevenire incidenti formando i team di sviluppo sulle giuste pratiche per quel contesto (ad es., per Java: “attenti alla deserializzazione di oggetti”; per C: “usa snprintf invece di sprintf per prevenire overflow”; per JavaScript: “valida bene input prima di usarli in DOM manipulations per evitare XSS”, e così via). Un professionista completo di sicurezza sa quindi muoversi trasversalmente tra il codice, individuando pattern pericolosi e suggerendo soluzioni appropriate al paradigma in uso.