codice corretto, codice robusto, codice sicuro

Salve a tutti,
nello scrivere la mia tesi ho dovuto affrontare il problema
di definire la programmazione corretta, robusta e sicura.
Sottopongo a quanti interessati la mia soluzione, attendendo
una vostra opinione in merito.

_____________________________

Suddividiamo l'input, l'output e lo stato di un programma in "validi" ed
"invalidi", dove per validità si intende la coerenza con le specifiche.
(definizione di stato?)
Un programma è corretto se si comporta come previsto dalle proprie
specifiche; in altre parole un programma è corretto se, sottoposto ad input
validi, fornisce output validi.
Un programma è robusto se, sottoposto ad input invalidi, fornisce output
validi. Questo significa che un programma robusto dovrà fornire output
coerenti con le specifiche anche se sottoposto ad input imprevisti. La
nozione di robustezza di un programma non ha una definizione che indichi
precisamente cosa si debba fare per ottenere software robusto. Da un
programma robusto ci si aspetta che sia corretto ma che sia in grado di
comportarsi correttamente anche in presenza di situazioni non previste in
origine (o dalle specifiche?).
Un programma è sicuro se, sottoposto ad input invalidi e/o validi, si trova
sempre in uno stato valido. Il fatto che il programma sia sempre in uno
stato valido consente di evitare comportamenti anomali, volutamente o
involontariamente prodotti, che possono, in un modo o in un altro,
consentire al programma di eseguire operazioni non desiderate.

figura 1 - programma corretto, robusto, sicuro.

Le definizioni  date rendono chiare le seguenti implicazioni:
· un programma robusto è anche corretto;
· un programma non sicuro potrebbe comportarsi in modo corretto e robusto;
· un programma sicuro potrebbe essere non corretto e non robusto;
In altre parole non c'è alcun legame diretto tra la robustezza/correttezza
di un programma e la sua sicurezza. Tuttavia è opportuno osservare che la
definizione data di programma sicuro presuppone che il programma stesso
reagisca ad input validi o/e invalidi in modo da portarsi sempre in uno
stato valido. Quando questo è possibile contrasta con requisiti di
efficienza e complessità; quando non è possibile contrasta con i requisiti
di funzionalità in quanto alcuni input e/o output non possono essere gestiti
e quindi accettati dal programma in quanto porterebbero lo stesso,
inevitabilmente, in uno stato non valido.
Meritevole di nota è poi la scelta di distinguere lo stato di un programma
in valido e/o invalido e non in sicuro e/o non sicuro. Siccome un programma
è sicuro se il suo stato è valido potrebbe sembrare più opportuno parlare di
stato sicuro e/o non sicuro; questa scelta tuttavia nasconderebbe una
ambiguità di fondo. Uno stato non è mai sicuro di per sé ma lo è in
riferimento ad una specifica di programma. Pare quindi più corretto parlare
di stato valido che di stato sicuro.
___________________________

ciao,
Orlando




________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List