Differenza tra "Correttezza" e "Sicurezza" di un sistema su rete

Differenza tra “Correttezza” e “Sicurezza” di un sistema su rete

Guzzo Antonio

Versione PDF del documento

Quando si parla di correttezza e sicurezza di un sistema su rete significa che i meccanismi di difesa devono lavorare correttamente e in sicurezza. Correttezza significa che il sistema soddisfa le specifiche. Per comprendere tale affermazione facciamo un esempio concreto.
Supponiamo di avere un firewall che ci dice che le comunicazioni verso il server che hanno indirizzo ip 10 possono passare solamente se sono comunicazioni web e cioè sulla porta 80. Se ciò concretamente ed effettivamente si verifica e ciòè che nessuno riesce a passare attraverso le altre porte, significa che il sistema per una richiesta “ragionevole”, risponde in modo “ragionevole” cioè se c‘è una richiesta di servizio di andare ad esempio al server 10 per fare ftp il server mi risponde no , voglio andare al server 10 per fare http il server mi risponde si.
Quando parliamo di sicurezza le proprietà del sistema sono mantenute in caso di attacco cioè per una richiesta “irragionevole”, il sistema risponde in modo non“disastroso” Ciò sta a significare, prendendo ad esempio il caso precedente, che siamo in presenza di due livelli di sicurezza, un primo firewall ed un secondo firewall interno che da questi server ci porta verso il database. Anche qui diremo che il server 10 ad esempio può andare solo al database 20 . In tale modo abbiamo messo su un architettura di rete tale che se qualcuno riesce a bucare questo firewall, comunque non ci troviamo ancora in una situazione disastrosa perché abbiamo almeno lasciate inalterate le regole interne, oppure potremmo dire che qualcuno ha bucato i firewall ma sta accedendo ai servizi solamente a questo livello, non riesce ad andare oltre ed in tal caso abbiamo gestito bene la sicurezza del sistema. Quindi la sicurezza del sistema per una richiesta irragionevole non deve rispondere in modo disastroso. Quando parliamo di sicurezza è necessario esaminare alcuni fattori che devono essere considerati. I problemi che nascono sono che l’avversario interagisce attivamente con il sistema cioè l’avversario può tentare diverse strade.
Questo significa, facendo un esempio, che se una sedia è stata certificata per 5 anni come durata, però lo è soltanto se questa sedia viene usata in maniera corretta. Immaginiamo ad esempio che io questa sedia la voglia usare come trampolino di una piscina, la durata diminuirà sensibilmente. Questo vuol dire che un utente, un attaccante, un avversario può usare il mio sistema in modo imprevisto e di conseguenza dato che io non ho preventivato tutti i casi possibili di uso del sistema che è complesso, l’avversario ha sempre potenzialmente la possibilità di crearmi una falla di sicurezza. L’approccio modulare alla programmazione, può provocare dei problemi perché il nostro avversario lavora ad un livello di astrazione inferiore al nostro, cioè ad esempio se il nostro avversario ci ha attaccato a su un determinato livello ma ci stiamo proteggendo su un altro livello, proteggiamo ad es. l’e-mail e cioè non proteggiamo il dato che ci arriva, non riusciamo a proteggerci dal fatto che il dato che ci arriva è stato strutturalmente modificato dal basso, ma se qualcuno lo ha cambiato da uno strato più basso siamo scoperti ad es. modificando le dimensioni di un pacchetto e può rendere il sistema vulnerabile: l’avversario lavora sempre ad un livello di astrazione inferiore al nostro. Però quando parliamo di sicurezza in realtà si hanno delle criticità come ad esempio il fatto che in azienda in genere la sicurezza non è sempre un obiettivo primario. Inoltre la performance, l’usabilità, hanno spesso la precedenza rispetto alla sicurezza anche perché non si conoscono mai tutte le funzionalità di un sistema (Es: APACHE).
Altri criticità sono cosi elencate:
1) I protocolli di alto livello sono sviluppati assumendo che quelli più bassi siano corretti;
2) Gli sviluppatori di software fanno tanti errori di sviluppo;
3) L’attacco più utilizzato è il “buffer overflow”;
4) Molti attacchi non sono di natura tecnica (Phishing, impersonificazione, …).
Le buone notizie
Più tempo passa e più abbiamo meccanismi di difesa che però dobbiamo studiare e comprendere le loro limitazioni. E’ emblematica a tal proposito l’espressione di Bruce Schneier “If you think cryptography will solve your problem, then you don’t understand cryptography… and you don’t understand your problem” cioè se pensiamo che la crittografia risolverà i nostri problemi , non avremo capito nulla della crittografia e non avremo capito il problema… Infatti molti problemi di sicurezza derivano dalla mancata comprensione del sistema
 
a cura del Dottor Antonio Guzzo
Responsabile CED Sistemi Informativi del Comune di Praia a Mare

© RIPRODUZIONE RISERVATA


Per la tua pubblicità sui nostri Media:
maggioliadv@maggioli.it  |  www.maggioliadv.it

Gruppo Maggioli
www.maggioli.it