Hardening: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica
Pontsort (discussione | contributi)
formattazione
Riga 6:
In [[italia]] rientra nelle pratiche tecniche introdotte dal [[documento programmatico sulla sicurezza]] 196/03 sulla sicurezza dei dati ed in generale enuncia i criteri da adottare per garantire l'adozione delle misure minime di sicurezza sui sistemi e sulle infrastrutture tecnologiche. Dal 25 Maggio 2018 ha efficacia il [[Regolamento generale sulla protezione dei dati]].
 
Uno degli errori più comuni nella realizzazione di un sistema informatico riguarda la fase di installazione di un sistema operativo, di ununa networkrete devicedi dispositivi o di un'applicazione. Quando si procede ad un lavoro di questo genere, spesso questi componenti non sono ben configurati per impedire i relativi rischi di [[sicurezza informatica]] che possono derivarne, ma sono soggetti ad una configurazione quanto più aderente ai principi basilari dell'amministrazione e più in generale al fine economico che l’azienda persegue. Inoltre, soprattutto la componente software può contenere vulnerabilità che mettono a rischio il sistema.<ref>{{it}}https://www.01net.it/i-principi-di-base-dellhardening-dei-sistemi-parte-1/</ref>
 
È questo uno dei motivi per cui si parla di esigenze di ''hardening'', cioè di rafforzamento delle piattaforme installate dal punto di vista della security. Esempi di operazioni hardening sono: chiusure di porte, arresto di servizi, disabilitazione di privilegi, eliminazione di utenti/account amministrativi o guest o di assistenza, disinstallazione programmi o strumenti particolari del sistema operativo, limitazione a connessioni o registrazioni su reti, negazione di accessi o diritti, impedimento o controllo della navigazione o della posta elettronica, sblocco operazione mediante consenso hardware o logico, ecc.
 
=== Tipologie ===
Riga 16:
1) ''One Time Hardening'': viene effettuato solo una volta dopo la prima realizzazione del sistema
 
2) ''Multiple Time hardening''. Viene effettuato più volte durante la vita del sistema, e la sua ripetizione nel tempo dipende da due fattori fondamentali che sono il rilascio di [[Patch (informatica)|patch]] di aggiornamento (patch management) per far fronte alle ''zero day vulnerability'' e l'aggiunta di moduli complementari a quello installato di base.
 
==Fasi==
''L'hardening'' si divide in tre parti fondamentali:
 
1) '''pre-analisi sullo stato attuale'''
Riga 33:
Ultimo fattore da analizzare è dato dalla robustezza fisica dei componenti. L'hardening qui riguarda la capacità del sistema di far fronte principalmente a disastri naturali e a problemi derivanti dalle alterazioni cui possono essere soggetti i componenti fisici del sistema informatico.
 
2) '''''remedy'''''
 
Per la parte di ''remedy'' (letteralmente rimedio) vengono elencate delle attività tecniche mirate che poi devono essere opportunamente documentate([[Report informativo|report]]) al fine di garantire la historycronologia sul singolo componente dell'infrastruttura e poter permettere un eventuale ripristino ([[rollback|''rollback'']]) in caso di blocco della funzionalità. La parte di report è poi soggetta ad un test ([[Audit (informatica)|''audit'']]) successivo di verifica atto a convalidare lo stato di sicurezza raggiunto (''compliance''). La documentazione dovrà essere attinente alla nuova legge europea
 
Questa attività di ''remedy'' viene normalmente effettuata attraverso operazioni distinte:
 
1) la riduzione della [[superficie di attacco]] ottenibile ad esempio attraverso:
Riga 45:
:*
2) la riconfigurazione dei servizi esistenti al fine di renderli maggiormente "robusti":
 
:* applicazione di permessi restrittivi sui file;
:* applicazione di ''policy'' per la complessità delle [[password]];
:* abilitazione dei [[log]] di sicurezza;
:* installazione delle [[patch (informatica)|patch]] di sicurezza;
Line 54 ⟶ 55:
3) '''monitoring per un dato tempo'''
 
Si tratta di tenere sotto controllo il funzionamento del sistema dopo le modifiche apportate nella fase di ''remedy''.
 
Questo punto è assente nel caso di "''One Time Hardening''" sopra descritto.
 
==Considerazioni==
 
Ogni componente erogante il servizio dovrà essere oggetto di ''hardening'', (es. [[sistema operativo]], [[webserver]], [[applicazione web]]), etc. Una configurazione molto stringente, spesso richiede un discreto tempo di applicazione, a causa a volte della complessità o della scarsità di documentazione del servizio ospitato. Nelle aziende tipicamente viene definito un livello base di ''hardening'' da applicare a tutte le piattaforme, viene successivamente deciso in funzione di un'attività di [[analisi del rischio]] se incrementare e di quanto la profondità dello stesso.
 
Ad oggi esistono anche insiemi di [[script]] di hardening e tool come [[Security-Enhanced Linux]], Bastille linux<ref>{{en}}http://bastille-linux.sourceforge.net/</ref>, Microsoft Group-Policy<ref>{{en}}http://technet.microsoft.com/en-us/library/cc771361(v=WS.10).aspx</ref> JASS<ref>{{en}}http://www.sun.com/software/security/jass/</ref> per [[Solaris (sistema operativo)|Solaris]] e Apache/PHP hardener<ref>{{en}}http://www.syhunt.com/</ref>, che possono, per esempio, disattivare funzionalità non necessarie nei file di configurazione e applicare misure protettive di varia natura. Sono disponibili in commercio soluzioni commerciali, piuttosto complesse, per il controllo centralizzato della sicurezza della rete, con possibilità di configurazione estremamente granulare per qualsiasi dispositivo/componente del sistema.