Fondamenti di Cybersecurity: Il Linguaggio della Difesa | Fondamenti di Test di Sicurezza Etico con Python: Una Guida Pratica per Principianti

La Triade CIA nel Lab Wintermute

Ogni controllo difensivo che costruiamo si ricollega a tre proprietà. Ho visto studenti inseguire exploit appariscenti dimenticando perché quegli exploit contano; la triade è la lente correttiva.

Proprietà	Cosa Protegge	Esempio Lab Wintermute	Modalità di Fallimento che Vedremo
Confidenzialità	Informazioni accessibili solo a parti autorizzate	Credenziali SSH memorizzate in `/etc/passwd` su 192.0.2.20; pannello admin DVWA su 192.0.2.30 senza timeout di sessione	Lettura non autorizzata di hash utente o credenziali database
Integrità	Informazioni e sistemi accurati, completi, non modificati	Modulo "File Upload" di DVWA che accetta qualsiasi estensione di file; directory di sistema scrivibili di Metasploitable2	File malevolo caricato ed eseguito; file di log manomessi per nascondere tracce
Disponibilità	Sistemi e dati accessibili quando necessari	Stack di rete deliberatamente debole di Metasploitable2; backend MySQL di DVWA senza limiti di connessione	Esaurimento risorse da richieste malformate; crash del servizio

Perché questo conta: Nel nostro lab, 192.0.2.20 esegue servizi che sono intenzionalmente fragili. Un SYN flood che rimbalzerebbe su un kernel moderno appiattirà questo target. Questo non è una vittoria — è una dimostrazione del perché esiste l'ingegneria della disponibilità (rate limiting, SYN cookies, accodamento connessioni). Ho visto studenti confondere "il servizio è morto" con "ho avuto successo." L'obiettivo di apprendimento è comprendere perché è morto e cosa impedirebbe ciò in produzione.

In termini semplici: la confidenzialità riguarda il mantenere segreti i segreti, l'integrità riguarda il fidarsi di ciò che si vede, e la disponibilità riguarda il funzionamento delle cose quando servono. Lab Wintermute rompe tutte e tre di proposito così potete studiare le rotture in sicurezza.

Terminologia Core: Un Glossario Operativo

Il campo della sicurezza affoga negli acronimi. Di seguito i termini che uso nel lavoro quotidiano, con il senso formale e cosa significano nella nostra rete isolata. Ho eliminato il fluff marketing che i vendor allegano a queste parole.

Termine	Definizione Formale	Contesto Lab Wintermute	Dove Lo Incontrerete
Vulnerability	Una debolezza in un asset o controllo che può essere sfruttata da una minaccia (adattato da NIST SP 800-115)	Samba non patchato su 192.0.2.20 (CVE-2007-2447); impostazione di sicurezza "low" di DVWA	Ogni risultato di scansione; ogni banner di servizio `nmap`
Exploit	Una tecnica che sfrutta una vulnerabilità per ottenere un specifico risultato tecnico	Il modulo `usermap_script` di Metasploit contro Samba; SQL injection nel form di login DVWA	Concettualmente nei moduli 6–9; non eseguiamo exploit remoti arbitrari senza documentare prima il controllo difensivo
Payload	Il codice o comando consegnato dopo lo sfruttamento riuscito per raggiungere l'obiettivo dell'attaccante	Una reverse shell (connessione di ritorno a 192.0.2.10); un comando `whoami` via SQLi	Discusso nel modulo 9; costruiamo comprensione senza deployare malware live
CVE	Common Vulnerabilities and Exposures: uno standard aperto di comunità per enumerare problemi di sicurezza software, usato da SCAP per gestione automatizzata [S2]	`CVE-2007-2447` per Samba usermap; `CVE-2015-3306` per ProFTPD	Cercate qualsiasi risultato su `nvd.nist.gov` [S2] — il NVD è sponsorizzato da DHS Cybersecurity and Communications
CVSS	Common Vulnerability Scoring System: un punteggio numerico di severità (0–10) derivato da metriche di exploitabilità e impatto	Samba usermap ha punteggio alto (exploitable da rete, bassa complessità, impatto pieno su confidenzialità/integrità/disponibilità); verificate l'attuale voce NVD per il vettore esatto	Usato per prioritizzare quali risultati affrontare prima nel vostro report di apprendimento
Threat	Qualsiasi circostanza o evento con potenziale impatto negativo su operazioni, asset o individui	Il ruolo "attaccante" che assumete da 192.0.2.10; in produzione, questo si espande a gruppi APT, minacce insider, worm automatizzati	La vostra stessa workstation Kali è l'emulatore controllato della minaccia
Risk	Il potenziale per perdita, danno o distruzione come risultato di una minaccia che sfrutta una vulnerabilità	Rischio = (Probabilità di exploit Samba) × (Impatto di compromissione root su 192.0.2.20) × (Assenza di segmentazione di rete)	Calcolato qualitativamente nel vostro report finale; non abbiamo dati attuariali per la nostra rete giocattolo
Mitigation	Un controllo o contromisura che riduce il rischio affrontando vulnerabilità, minaccia o impatto	Patchare Samba; disabilitare il servizio; firewall sulla porta 139/445; deployare rilevazione intrusioni host-based	Ogni categoria di attacco nei moduli 6–9 si conclude con controlli difensivi

Intuizione guadagnata: Il CVSS è un punto di partenza, non un motore decisionale. Ho visto un CVSS 9.8 su un servizio solo interno senza dati di valore trattato come "lasciare tutto," mentre un CVSS 5.3 su un gateway di autenticazione esposto a Internet viene accodato per il prossimo trimestre. Il punteggio misura la severità tecnica, non il rischio di business. Il vostro report di lab dovrebbe notare questa distinzione.

Superficie di Attacco: Cosa È Esposto nel Lab Wintermute

La superficie di attacco è tutto ciò che un avversario può toccare. Nella nostra rete, la controlliamo con precisione — il che la rende una superficie didattica, non una responsabilità di produzione.

Host	Ruolo	Servizi Esposti (Noti)	Perché Questo Conta per l'Apprendimento
192.0.2.10	Workstation attaccante Kali Linux	SSH (accesso admin), connessioni outbound solo verso target del lab	La vostra base operativa; qualsiasi tool installato qui resta isolato
192.0.2.20	Server target Metasploitable2	Multipli: SSH (22), Telnet (23), FTP (21), Samba (139/445), NFS (2049), MySQL (3306), e altri	Servizi deliberatamente vulnerabili per studio controllato; ognuno rappresenta un protocollo del mondo reale con debolezze storiche
192.0.2.30	Server applicativo web DVWA	HTTP (80), backend MySQL (3306, interno)	Vulnerabilità a livello applicativo (SQLi, XSS, file upload, CSRF) in un wrapper pedagogico

La superficie si espande con ogni servizio in esecuzione, ogni porta aperta, ogni funzionalità abilitata. In produzione, si restringe questa superficie; in Lab Wintermute, la mappiamo esaustivamente. Il modulo 5 copre il processo di mappatura. Per ora, comprendete che la superficie ampia di 192.0.2.20 è una scelta curriculare, non un pattern di design da emulare.

Autorizzato vs. Non Autorizzato: Il Confine Che Vi Protegge

Questa tabella non è decorazione burocratica. Ho visto tecnici competenti affrontare inchieste penali perché confondevano "stavo aiutando" con "avevo autorizzazione." La distinzione è binaria, non graduale.

Criterio	Attività Autorizzata (Lab Wintermute)	Attività Non Autorizzata (Illegale)
Documento di scope	Accordo scritto che definisce 192.0.2.0/24 come range target, tecniche specifiche permesse, finestra temporale	Scansione di qualsiasi IP fuori dal range definito; testare "giusto per vedere" dopo l'orario
Autorizzazione	Permesso esplicito, documentato, dall'entità che controlla gli asset	Qualsiasi accesso senza tale permesso, anche a sistemi "evidentemente rotti"
Scopo	Educazione, miglioramento difensivo, sviluppo controllato di competenze	Curiosità, vantaggio competitivo, guadagno finanziario, attivismo
Gestione dati	I risultati restano nel lab isolato; nessuna esfiltrazione verso internet	Copiare dati, credenziali o evidenze fuori dall'ambiente autorizzato
Divulgazione	Report interno all'istruttore del corso; nessuna pubblicazione esterna senza consenso	Divulgazione pubblica di vulnerabilità senza coordinamento

⚠️ Solo uso autorizzato e difensivo.

Perché questo conta: Il concetto di "scope scritto" appare in NIST SP 800-115, "Technical Guide to Information Security Testing and Assessment" [S4]. Lo standard tratta pianificazione, conduzione, analisi e sviluppo di strategie di mitigazione — ma enfatizza che è una panoramica di tecniche e raccomandazioni, non un programma di testing completo [S4]. Nel nostro lab, il vostro scope è l'accordo del corso. Nella pratica professionale, è un contratto con confini tecnici espliciti.

Scannerizzare 192.0.2.20 senza il documento di scope violerebbe l'autorizzazione — anche se l'host è progettato per essere scannerizzato, anche se "sapete" che è sicuro. L'abitudine di verificare lo scope prima di toccare un target è ciò che separa il testing etico dall'accesso sconsiderato.

Divulgazione Responsabile: Quando Trovate Qualcosa Fuori dal Lab

Lab Wintermute è contenuto. Eventualmente, potreste incontrare vulnerabilità in natura — forse in software open-source che usate, forse in un servizio dove detenete un account legittimo. Il processo di divulgazione protegge sia la parte vulnerabile che voi stessi.

Fase	Azione	Indicazione Temporale
Scoperta	Documentare la riproducibilità; isolare dai sistemi di produzione	Immediata: interrompere il testing, preservare le evidenze
Contatto iniziale	Notificare vendor/proprietario tramite contatto di sicurezza pubblicato o CERT	Entro 72 ore dalla vulnerabilità confermata
Periodo di attesa	Permettere tempo ragionevole per sviluppo e deployment della patch	Tipicamente 90 giorni; più breve per vulnerabilità attivamente sfruttate, più lungo per sistemi embedded complessi
Divulgazione pubblica	Pubblicare dettagli tecnici solo dopo fix disponibile o scadenza raggiunta	Coordinata con il vendor; mai "rilasciare" zero-day senza preavviso

Non mi pronuncio su tempistiche esatte perché nessuna fonte stabilisce periodi di divulgazione obbligatori [coverage gap]. La pratica industriale varia; la linea guida CERT/CC di 45 giorni è comune ma non universale. Ciò che conta è il principio: date al difensore tempo per difendersi prima di armare l'attaccante.

Quadro Legale: Confini Italiani e UE

Questa sezione inquadra ciò che dovete sapere; non è consulenza legale. Segnalo dove le fonti sono scarse o datate.

Dominio	Strumento Rilevante	Cosa Significa per la Pratica di Pentesting
Responsabilità ente (Italia)	D.Lgs. 231/2001: stabilisce la responsabilità diretta e autonoma degli enti per reati commessi nel loro interesse o a loro vantaggio [S1][S6]	Il vostro datore di lavoro o istituzione educativa può essere responsabile per il vostro accesso di rete non autorizzato; ecco perché richiedono accordi di scope firmati e protocolli per attività "a rischio" [S1]
Responsabilità amministrativa	Legge 29 settembre 2000, n. 300; modello D.Lgs. 231/2001 che richiede sistemi di controllo per attività sensibili [S1][S6]	I framework di corporate governance (a volte citati insieme al SOX USA [S1]) impongono protocolli preventivi; i programmi di ethical hacking sono attività "a rischio" che richiedono controlli documentati
Diritto penale (Italia)	Convention on Cybercrime (ratificata dal Senato italiano 27 febbraio 2008) [S7]; disposizioni di attuazione nel codice penale	Certi reati informatici richiedono querela di parte (iniziativa del privato); altri sono perseguibili d'ufficio [S7]. L'articolo 617-quater prevede pene detentive e ammende [S7] — notare che la fonte cita importi in lire pre-Euro, indicando informazioni potenzialmente datate; verificare sanzioni attuali con consulente legale
Protezione dati	D.Lgs. 196/2003 (Codice Privacy italiano); GDPR (UE 2016/679) [no direct source]	Qualsiasi dato personale incontrato durante il testing — anche in ambienti lab con dati sintetici — deve essere gestito secondo principi di privacy; l'isolamento del lab aiuta a dimostrare compliance

Gap critico: nessuna fonte stabilisce l'"autorizzazione scritta" come specifico requisito statutario per l'ethical hacking legale in Italia [coverage gap]. La mia pratica — e ogni framework rispettabile che seguo — la tratta come essenziale. L'assenza di un specifico rifugio statutario significa che la vostra protezione risiede nello scope contrattuale, nel consenso documentato e nell'aderenza rigorosa a quel confine.

Riferimento Rapido: Checklist Regole di Ingaggio

Prima di qualsiasi azione in Lab Wintermute o in qualsiasi futuro incarico:

[ ] Documento di scope revisionato e compreso
[ ] Range IP target confermato (qui: solo 192.0.2.0/24)
[ ] Snapshot effettuato (capacità di rollback verificata)
[ ] Isolamento di rete confermato (nessun bridge a produzione o internet per gli host target)
[ ] Finestra temporale di autorizzazione annotata
[ ] Obblighi di reporting compresi
[ ] Regole di gestione dati personali riconosciute

Il modulo 4 copre la costruzione tecnica di questo isolamento. La prossima pagina nella vostra progressione è la build dell'ambiente stesso.