Forum programmazione

[Mips]

Per iniziare a essere considerato sicuro, un sistema deve superare un apposito controllo di protezione indipendente.

Gli scrittori sanno di non essere capaci di revisionare il loro stesso lavoro e, analogamente, i programmatori dovrebbero sapere che non possono collaudare i loro stessi programmi.
Per questo motivo numerose società adoperano tester per il software, che cercano i bug nei programmi che impediscono loro di svolgere le funzioni per cui sono stati creati: questa operazione è definita collaudo funzionale.
Essa differisce ampiamente dal collaudo di sicurezza, benché il nome sembri denotare una parentela: non è forse vero che entrambi cercano i bug? È vero solo in parte: il collaudo di sicurezza dovrebbe essere un ampio soprainsieme di collaudi funzionali; se è di buona qualità, richiede un’analisi assai più approfondita, che include di solito un esame del codice sorgente. Il collaudo funzionale viene effettuato per garantire che un’ampia parte degli utenti possa servirsi del prodotto senza lamentele. Difendersi dall’utente medio che si imbatte involontariamente in un problema è molto più facile che distogliere un abile hacker dalla bramosità di violare un programma in tutti i modi possibili e immaginabili.
Senza addentrarsi nella discussione sulla natura dei controlli di sicurezza, dovrebbe ormai essere chiaro perché essi sono necessari. Quasi nessun prodotto commerciale viene sottoposto a una revisione di sicurezza; solitamente, gli unici su cui viene svolta almeno una parvenza di controllo sono i prodotti di sicurezza, ma le pecche di una revisione sbrigativa non tardano a manifestarsi.
Gli utenti noteranno che la legge presenta la parola “iniziare”: il controllo è infatti solo una fase della produzione di sistemi sicuri. È sufficiente leggere gli archivi dei rapporti sulle vulnerabilità per rendersi conto che i pacchetti software sono costellati di bug: è ancora peggio il fatto che sono visibili gli stessi errori commessi a oltranza da svariate case.
Per fortuna vi sono anche ottimi controlli che portano a pacchetti molto più sicuri; l’esempio più interessante è forse dato da OpenBSD. In origine una filiale del progetto NetBSD, OpenBSD decise di concentrarsi sulla sicurezza e per circa due anni il suo staff ha svolto controlli sui codici sorgente per individuare e riparare i bug. Essi hanno riparato tutti i difetti, anche se non legati alla sicurezza: trovando un difetto comune, essi ripercorrevano tutto il codice sorgente per riscontrare l’eventuale presenza di un bug analogo. Tutto ciò ha fatto sì che OpenBSD sia ovunque ritenuto uno dei sistemi operativi più sicuri; non di rado, anche all’apparire di nuovi errori in NetBSD o FreeBSD (un’altra variante di BSD), OpenBSD non presenta alcun punto debole. Tale invulnerabilità è a volte dovuta al fatto che il programma era stato riparato per caso durante il normale processo di risoluzione dei bug, mentre altre volte la riparazione è stata deliberata. In questi casi NetBSD e FreeBSD (se possedevano lo stesso frammento di codice) erano vulnerabili perché qualcuno non aveva controllato nel database di OpenBSD se vi erano nuove riparazioni (tutte le riparazioni di OpenBSD vengono pubblicate).