Ridurre le minacce e incrementare le prestazioni: il Security Hardening potenzia il sistema
Il Security Hardening dei sistemi rappresenta la base per un’infrastruttura IT sicura: tema particolarmente rilevante quando si parla di progettazione embedded, l’irrobustimento della sicurezza prevede il contenimento dei rischi, anche tramite l’eliminazione di tutto quanto non è utile, incrementando così anche le performance di sistema.
Nell’ultimo appuntamento qui sul nostro blog abbiamo parlato di come potenziare la sicurezza dei propri asset informatici, riprendendo sia le norme e gli standard esistenti in materia, sia alcune regole e prassi di buon utilizzo che ogni utente può e dovrebbe adottare. La sicurezza informatica è però un tema che può essere preso in considerazione anche a monte, ovvero nella fase di progettazione di un sistema embedded: è questo un aspetto che noi di Idem-Tech conosciamo bene, in quanto il Security Hardening, ovvero l’”irrobustimento” della sicurezza dei sistemi è spesso anche un pre-requisito richiestoci dai nostri clienti.
Parliamo in particolare di Security Hardening in ambito Linux, ovvero quell’insieme di operazioni e configurazioni che, fatte sul sistema informatico, consentono di rendere un sistema embedded il più sicuro possibile, riducendone la vulnerabilità: è proprio Linux, infatti, il sistema operativo che il nostro team utilizza più frequentemente e che, di nuovo, ci viene spesso esplicitamente richiesto dai clienti in fase di progettazione.
Anche in ambito di Security Hardening, un team di lavoro esperto deve essere in grado di garantire un buon trade-off tra sicurezza e usabilità del sistema.
Il processo di Security Hardening deve essere svolto in fase di sviluppo iniziale del progetto (by design) e deve poi essere ripetuto ciclicamente per far fronte ai cambiamenti delle specifiche del sistema o al sopraggiungere di nuove necessità in termini di sicurezza. Il Security Hardening può inoltre essere fatto su vari componenti (sistema operativo, applicativi, device ecc.), sempre con lo scopo di irrobustire la sicurezza del sistema nel suo complesso.
In Idem-Tech parliamo in particolare di Security Hardening in ambito Linux perché si tratta di un sistema operativo open source, su cui interviene abitualmente una comunità di persone. Questo significa che vi sono molte persone in grado di indentificarne eventuali falle di sicurezza, cosa che non avviene invece con i sistemi operativi con codice chiuso e privato: la community di sviluppatori alle spalle di Linux riduce quindi il rischio che un baco nella sicurezza venga ignorato per periodi di tempo prolungati. Al contrario Windows, avendo un codice sorgente privato e non accessibile, è spesso affetto da bug che perdurano a lungo prima di essere risolti.
Quando si parla di Security Hardening in ambito Linux, l’incremento della sicurezza passa anche dalla possibilità di costruirsi il proprio sistema operativo.
La progettazione embedded è infatti fondamentale per accrescere la sicurezza del sistema. Uno degli strumenti più efficaci per procedere in tal senso, come abbiamo visto anche in un articolo dedicato, è Yocto.
Effettuando un tailoring del sistema operativo è infatti possibile eliminare tutti quei driver che non occorrono per quel caso specifico, perché non verrebbero utilizzati o anche perché il device su cui verrà poi messo il sistema operativo non prevede del tutto determinate periferiche. Una regola di base del Security Hardening in ambito Linux è infatti quella di non prevedere mai parti di software che creerebbero falle alla sicurezza, ma che non apportano nessun beneficio pratico: se non si ha bisogno di un software o di un servizio, è sempre meglio non prevederlo o disinstallarlo, di modo da ridurre le possibilità di esposizione ad un attacco.
Inoltre, agendo invece a livello di kernel, con la programmazione embedded è possibile modificare una serie di parametri di configurazione che possono rendere più o meno sicuro il sistema stesso: si parla in questo caso di Kernel Custom Configuration.
Il kernel presente di base con le più comuni distribuzioni Linux è infatti concepito per essere adatto a più usi possibili, con una logica one-size-fits-many, e dovrebbe quindi essere modificato e adattato per usi specifici. Ad esempio, esiste un paramento che abilita la possibilità per un nuovo kernel di essere caricato senza re-inizializzare l’hardware: questo creerebbe dei problemi di sicurezza, quindi il parametro config_kexec può essere impostato su no. Un altro esempio è il parametro config_livepatch, che abilita il kernel alla ricezione di patch in run time: questo espone il sistema a una serie di vettori di rischio e può permettere di disabilitare una serie di funzioni di sicurezza. Anche in questo caso, il parametro può quindi essere spento per incrementare la sicurezza del sistema. Questi esempi sono simbolici e non esaustivi: gli interventi fattibili a livello di kernel per incrementare la sicurezza sono infatti molto numerosi.
La possibilità di fare tailoring del sistema operativo ne aumenta la sicurezza e le prestazioni, impedendo che giri del software, sia a livello di sistema operativo che di aggiornamenti che di applicativi, che non viene poi utilizzato nella realtà.
Il team di Idem-Tech è anche in grado di scrivere da zero o modificare i driver di periferica per Linux: questo può apportare una serie ulteriore di benefici, permettendo di eliminare i servizi del driver che non servono in quel caso specifico ma che possono rappresentare delle falle alla sicurezza.
Lavorare in ambito embedded consente infatti di personalizzare del tutto hardware e software, eliminando componenti non necessari e incrementando la sicurezza, ma rappresentando spesso anche un enhancement a livello prestazionale. Banalmente, se la macchina dove girerà il sistema operativo non ha schermi e uscite video è inutile che il sistema operativo includa una parte di gestione grafica: la progettazione embedded consente di non inserire elementi non necessari come questo.
Buona norma in fase di progettazione hardware è anche quella di non esporre periferiche che non si vogliono rendere accessibili a terzi.
Di pari passo, non mettendo la periferica, anche il sistema operativo non prevederà il driver per pilotare quella data periferica. È importante definire anche che nessun altro sistema operativo oltre a quello previsto dallo sviluppatore possa essere lanciato: il Secure Boot è un esempio di Security Hardening anche in ambito Linux.
Il Secure Boot consente il caricamento, all’avvio della macchina, esclusivamente dei moduli software dotati di una firma digitale autorizzata e riconosciuta.
Si evita così che altri moduli possano fare il boot. Va considerato che il Secure Boot può essere fatto solo su sistemi dotati di UEFI (Unified Extensible Firmware Interface). Il UEFI ha infatti al suo interno una chiave pubblica che deve essere confrontata con una chiave privata posta all’interno del sistema operativo o del Boot Loader. Se il Secure Boot è abilitato, il UEFI non consente l’avvio di un Boot Loader (e quindi il caricamento di un sistema operativo) che non abbia la chiave privata corrispondente a quella pubblica. Quando il Secure Boot è abilitato, non sarà quindi possibile alcun tentativo di eseguire un programma identificato come non attendibile.
Come ulteriore forma di sicurezza, il UEFI deve anche essere protetto da password per evitare che sia possibile modificarne le impostazioni e rendere così meno sicuro il Secure Boot. In ogni caso, se si dovesse riuscire a modificare il gestore dell’avvio – GRUB quando si lavora in ambito Linux – si andrebbe a modificare il Boot Loader che, non venendo più riconosciuto dal UEFI, non verrebbe più caricato.
Anche nei sistemi non dotati di UEFI è comunque possibile garantire un avvio sicuro del sistema, anche se è improprio parlare di Secure Boot in quanto il processo assume nomi diversi: ad esempio sotto ARM è presente l’ARM Trusted Firmware (ATF).
Esistono dei veri e proprio standard che definiscono i sistemi di Encryption tramite certificati a chiave pubblica-privata, come l’X.509.
Lo standard X.509 definisce il formato dei certificati a chiave pubblica e delle autorità di certificazione, facendo sì che la Certification Authority emetta il certificato collegato alla chiave pubblica destinato ad un’entità specifica. Solo a questo punto, questa terza entità può generare dei certificati a sua volta, diventando essa stessa una Certification Authority. Tutti i certificati firmati con questa sequenza instaurano una Chain of Trust, consentendo sempre di risalire alla prima Certification Authority.
Il sistema di certificazione a chiave pubblica e chiave privata può essere utilizzato anche negli aggiornamenti: in fase di programmazione del sistema è quindi possibile far sì che questo riceva ed esegua esclusivamente gli aggiornamenti certificati.
Un’altra buona norma di Security Hardening in ambito Linux è la Disk Encryption, che fa sì che, se la macchina è spenta, il sistema risulti criptato.
Il disco dati viene infatti posto sotto codifica: quando la macchina viene accesa, la codifica viene aperta permettendo all’utente di lavorare sui dati. Quando la macchina viene spenta i dati vengono nuovamente criptati. Inoltre, sulla macchina deve essere presente un chip TPM (Trusted Platform Module) che contiene l’unica chiave di cifratura utilizzabile per decriptare e rendere visibili i dati: questo fa sì che, anche rimuovendo il disco, non sia possibile accenderlo e accedere ai dati da un’altra macchina.
Esistono poi alcuni protocolli che è consigliabile utilizzare in ambito di sicurezza informatica, come ad esempio il protocollo SSH (Secure SHell), che permette di stabilire una connessione da remoto con la macchina tramite una cifratura.
In ottica embedded tutte queste procedure di Security Hardening in ambito Linux hanno una particolare rilevanza e consentono la creazione di sistemi e macchine altamente sicuri.
Affidandosi a un team di professionisti esperti in quest’ambito è possibile essere certi di rispettare le più stringenti necessità in materia di Security Hardening. Negli anni, in Idem-Tech abbiamo sviluppato un forte expertise che ci permette di far fronte alle specifiche richieste anche dei clienti più esigenti che, ad esempio per ragioni di ambito di lavoro, richiedono il rispetto di elevati standard di sicurezza.
Alcuni clienti richiedono ad esempio la progettazione di uno specifico hardware in grado di eseguire solamente uno specifico software, andando quindi a creare macchine che non sono general purpose: la creazione di sistemi operativi Linux tramite Yocto è una delle nostre aree di expertise, consentendoci di proporre soluzioni con elevatissimi requisiti di Security Hardening.