Sicurezza informatica, l’organizzazione

Ovviamente la nostra analisi non deve fermarsi a valutare il fatto che possiamo vedere il codice sorgente o meno. Ci sono ancora molti altri aspetti da verificare.
Ad esempio è completamente inutile trovare i bug e non risolverli, sopratutto se i cracker sanno come sfruttarli!
Ci troviamo quindi di fronte a tre fattori da considerare una volta scoperto il bug
- Prima di tutto la velocità con la quale i programmatori correggono i bug
- In secondo luogo quanto velocemente vengono rilasciati gli aggiornamenti
- In terzo luogo quanto è difficile è applicare gli aggiornamenti o se sono disponibili per tutti

Detto questo dovreste capire subito che non vuol dire nulla il numero di vulnerabilità scoperte e quanto critiche fossero. Se non sono state scoperte, non vuol dire che non ci sono, se sono state corrette, non vuol dire chela gente le abbia applicate, e anche se ne sono state corrette tante e applicate non vuol dire che non si possono aggirare. A volte si leggono statistiche in internet senza nessun significato, eppure viene commentata la sicurezza dei programmi in base al numero di bug di sicurezza trovati, ma se ci fate caso non verrà quasi mai accenata nessuna parola su quanto velocemente sono stati chiusi (se non prima che venissero scoperti da eventuali attacc anti) e quanto critici sono quelli ancora in circolazione.
Supponiamo di avere due ipotetici programmi, uno con 100 bug, tutti corretti poco prima che venissero scoperti da eventuali attaccanti oppure corretti in un paio di giorni, e un secondo programma, con soltanto 10 problemi di sicurezza, di cui ancora due non risolti.
Cosa possiamo dire di questo paragone? Che il secondo è migliore del primo perchè sono state trovate meno vulnerabilità? Giammai, se non sono state trovate non vuol dire che non esistono (e che non ne verranno scoperti duecento nella prossima settimana), inoltre molto dipende da quanto importanti sono i due problemi di sicurezza. Se sono sfruttabili in qualsiasi occasione, o soltanto con configurazioni improbabili e assai complesse e se, peggio ancora, sono problemi di tipo strutturale e per correggerli è necessario riscrivere da 0 l’intero programma.

Una volta corretto il bug rimane il problema di rendere l’aggiornamento disponibile agli utenti finali. Per questo è sempre importante aggiornare i propri programmi, sopratutto se il nostro computer ha spesso “contatti” con programmi e file “esterni” (provenienti dalla rete, chat, chiavette usb, cd…).
Ad esempio trovo che sia sempre un gran problema reinstallare windows da zero, immaginate di dover reinstallare su un computer Windows, del quale avete il cd d’installazione originale, ad esempio Windows XP (o anche Vista nel frattempo) con SP1 e nient’altro.
Per fare gli aggiornamenti ci vuole una intera giornata se non di più, e nel frattempo un sacco di bug scoperti (e anche corretti) sono disponibili ad un sacco di cracker per poter entrare nel sistema operativo appena installato. Ovviamente questo discorso vale anche per Mac OS e ogni programma di cui abbiamo comprato un cd (perché difficilmente si può poi scaricare da internet una versiona più nuova).
Nel caso dovessi invece reinstallare un programma/sistema operativo gratuito (attenzione, non libero, ma gratuito, c’è una bella differenza), allora posso facilmente ottenere l’ultima versione disponibile, evitando così lunghi aggiornamenti.
Spesso invece per risparmiare risorse si disattivano gli aggiornamenti automatici. Infatti sia su Windows, sia su Mac non esistono i repository (oddio, si può implementare qualcosa del genere, ma attualmente non gli ho mai provati…), e quindi sarebbero magari addirittura più di una decina di programmi in esecuzione a cercare sulla rete il proprio aggiornamento, rallentando l’intero sistema e consumando in parte la banda di rete. Questo problema non si presenta invece su quasi tutte le distribuzioni, che grazie i package manager gli aggiornamenti vengono gestiti tutti insieme, evitando così un sacco di processi ridondanti.

Altrettanto importante è l’organizzazione.
Un gruppo ben organizzato può svolgere lo stesso lavoro in modo più veloce e efficente di un grande gruppo disorganizzato. Si possono evitare molte riscritture inutili, ottenere un codice più pulito…
È importante stabilire severe guide da rispettare, come ad esempio considerare l’importanza di ogni bug report, a cosa dare precedenza, a non litigare per feature di seconda importanza, aggiornare costantemente la documentazione per i futuri nuovi arrivati…
Purtroppo questo accadrà più difficilmente se i programmatori conosceranno soltanto una parte del codice e d’altra parte più facilmente se non tutti possono contribuire e dare consigli (in altre parole: in una società chiusa ci può essere meno materiale magari ridondante da gestire), è anche vero però che conoscendo l’intero ambiente in cui si lavora, è più facile valutare come programmare, per evitare alcuni controlli inutili e bug sciocchi, in un ambiente chiuso può darsi che tutto il codice deve venir testato a scatola chiusa per vedere se è coerente con se stesso e con il resto del sistema, in un ambiente aperto è un aspetto che viene già tenuto conto durante la scrittura del programma.
Grazie a Google Code e a Launchpad, come anche a SourceForge, è possibile organizzare “facilmente” il proprio lavoro, queste piattaforme di sviluppo aiutano a gestire i bug, le traduzioni, la documentazione e molto altro per molti progetti
In un ambiente chiuso purtroppo non so come venga gestito il lavoro normalmente, se qualcuno ha quindi qualche informazione è pregato di farsi avanti

Clicca sul link per tornare alla pagina principale sulla Sicurezza Informatica