Leggendo gli articoli o ascoltando gli interventi sulla sicurezza applicativa, si può essere portati a pensare che l'efficacia delle verifiche dipenda dalla qualità del personale impiegato e degli strumenti utilizzati. Non è vero. Immaginiamo di avere il miglior gruppo di lavoro e il miglior software di analisi del Mondo; facciamo i nostri test e riusciamo a scoprire tutte le vulnerabilità di un'applicazione Web. Questo rende il nostro sistema più sicuro? No, perché le vulnerabilità sono ancora lì e, finché qualcuno non le eliminerà, il nostro lavoro avrà tutt'al più il valore di una macabra profezia.
La correzione delle vulnerabilità non dipende dalle persone della Sicurezza, ma dai singoli gruppi di sviluppo e i gruppi di sviluppo, in qualunque azienda o Ente medio/grande, dipendono da altri uffici e da altre società; ciò ci porta al nostro primo assioma:
La sicurezza funziona tanto meglio quanto più è autorevole la figura che la esercita. Immaginiamo che nel luogo dove lavoriamo ci sia la seguente gerarchia:
- Direttore
- Dirigente ufficio Reti
- Dirigente ufficio Esercizio
- Dirigente ufficio Sviluppo
- Responsabile sviluppo applicazione 1
- Responsabile sviluppo applicazione 2
- Dirigente ufficio Sicurezza
- Responsabile gruppo Sicurezza Applicativa
Se il dirigente dell'ufficio che gestisce la sicurezza è un pari grado dei dirigenti degli altri uffici coinvolti nel processo di verifica e correzione, non potrà imporre le sue scelte, ma dovrà rifarsi necessariamente all'autorità del Direttore. In simili condizioni, il dirigente del'Ufficio Sicurezza coinvolgerà il suo superiore solo nelle questioni veramente gravi e, in tutti gli altri casi, sarà costretto a lasciare le cose come stanno. La sicurezza avrà fatto il suo lavoro, ma il sistema, nel suo complesso, non ne avrà minimamente beneficiato.
Le possibili soluzioni a questo problema sono due: o il dirigente della sicurezza è gerarchicamente superiore ai direttori degli altri uffici1 o, se ciò non fosse possibile, si deve collocare al di fuori dalle gerarchie aziendali e rispondere direttamente al vertice aziendale.
I test di sicurezza non devono essere una gogna
Tranne che in rarissimi casi2, gli esiti di una verifica della sicurezza di un'applicazione devono essere comunicati solo al capo-progetto e non devono per nessuna ragione essere comunicati ad altri gruppi di lavoro. Le verifiche di sicurezza devono essere approcciate, da una parte e dall'altra, come un esame medico invasivo: il gruppo di sviluppo deve accettarne il fastidio per prevenire fastidi ben peggiori; la sicurezza deve rendere l'esperienza meno spiacevole e umiliante possibile per il "paziente" e, soprattutto, non deve mai dare l'impressione di provare piacere in ciò che fa.
I test di sicurezza devono essere una sorta di confessione, che cancella i peccati dei gruppi di sviluppo e che è coperta dal più rigoroso segreto. La modifica del codice è l'eventuale penitenza per chi è caduto in errore.
Ricordiamoci sempre che un capo-progetto solitamente è solo, in un ambiente ostile; da un lato ha la sua società che lo incalza per chiudere il progetto o il SAL per fatturare; dall'altra ha la Sicurezza che lo costringe a spendere altri giorni-uomo nello sviluppo: è comprensibile che sia poco accondiscendente. Se noi gli facciamo la guerra, tutto ciò che otterremo sarà un codice raffazzonato e molto più pericoloso, perché alle vulnerabilità applicative (corrette male) si aggiungeranno gli errori dovuti alla fretta. Molto meglio cercare una soluzione che vada bene a tutti e due - fermi restando, ovviamente, i nostri obblighi nei confronti del cliente. Se riusciamo a far ciò, è molto probabile che in futuro sarà lui stesso a venirci a cercare per avere dei consigli o delle valutazioni preventive.
I requisiti di sicurezza devono essere noti, chiari e, se necessario, chiariti
È fondamentale che il gruppo di sicurezza applicativa sia e si dimostri a disposizione dei diversi gruppi di sviluppo. Deve fornire consulenza nella fase di progettazione del sistema (possibilmente dopo che ne sono stati definiti i requisiti funzionali e prima che ne sia definita l'architettura), deve essere disponibile per nuovi interventi nella fase dello sviluppo e deve aiutare il gruppo di sviluppo a risolvere eventuali problemi che si evidenzino in fase di collaudo.
I requisiti minimi di sicurezza richiesti dal committente devono essere esplicitati nei capitolati di gara e le linee-guida per la programmazione devono essere dettagliate in un documento disponibile per chiunque ne faccia richiesta.
I collaudi di sicurezza devono essere determinanti ai fini della chiusura dei SAL, ma non devono essere una sorpresa per i gruppi di sviluppo: per un capo-progetto non c'è niente di peggio dello scoprire, a pochi giorni da quella che lui pensava fosse la fine delle sue tribolazioni, di dover spendere altri giorni-uomo di sviluppo per la correzione delle vulnerabilità applicative.
Per prevenire discussioni sterili, le richieste di correzione devono essere sempre motivate con una mancata conformità ai requisiti di sicurezza, ignorando, per quanto possa apparire paradossale, ogni considerazione relativa al rischio derivante dalle vulnerabilità. Questo per due motivi: il primo è che l'effettivo livello di rischio di una vulnerabilità, oltre che da questioni puramente tecniche, dipende anche da fattori che le persone della sicurezza non sempre sono in grado di valutare; il secondo motivo è che mentre il livello di rischio di una vulnerabilità è un valore ipotetico, la mancata conformità è un dato oggettivo, che non può essere negato dal gruppo di sviluppo.
Immagine tratta da Shutterstock
L'analisi del codice può essere un bene e può essere un male
Fare analisi del codice è facile all'interno di una software-house, ma non a casa del cliente, in un ambiente dove i sistemi sono realizzati da società diverse, spesso in concorrenza fra loro. Indubbiamente, poter fare una buona analisi del codice è un bene, perché evidenzia i problemi alla radice, anche se questi non hanno degli effetti visibili dall'esterno; in molti casi, però, la code-review, più che risolvere i problemi, li crea.
Innanzi tutto, l'analisi del codice è complicata da attuare perché richiede la presenza, durante i test, di un analista-programmatore che conosca bene il sistema in esame e che possa valutare le implicazioni dell'eventuale correzione dei brani di codice vulnerabile; non sempre un gruppo di lavoro sotto pressione può o è disposto a cedere una simile risorsa. Inoltre, e questo si rivela spesso uno scoglio insormontabile, per poter fare un'analisi del codice si ha bisogno, appunto, del codice, cosa che raramente i fornitori sono disposti a fare; nominalmente, per questioni legate alla proprietà intellettuale. Ci permettiamo di diffidare di questa motivazione perché l'analisi del codice non permette alcuna possibilità di plagio, se non la si vuole permettere. A ogni modo, si può pensare di includere una clausola nei contratti, stabilendo che se un'applicazione fallisce i collaudi di sicurezza il committente ha il diritto di esaminarne il codice per accertarne l'effettiva vulnerabilità. Il fornitore può rifiutarsi di fornire il codice, ma, in quel caso, si assume la responsabilità di ogni attacco subìto dal suo sistema.
La sicurezza fatta bene non fa bene solo alla sicurezza
Se si riescono ad applicare tutte le condizioni esposte sopra, si possono utilizzare le prove di sicurezza come cartina di tornasole per evidenziare i lati carenti del proprio sistema. Questo, apparentemente contraddice quanto affermato prima, ma non è così, perché c'è una bella differenza fra il non complicare la vita a un capo-progetto che sta cercando di fare il proprio lavoro e passare sotto silenzio delle inefficienze che potrebbero rivelarsi fatali per il sistema.
La topologia di rete, gli indirizzamenti o le versioni dei sistemi operativi installati sui sistemi non riguardano direttamente la sicurezza applicativa, ma quando si deve fronteggiare un attacco o rispondere a un allarme, diventano questioni vitali per l'organizzazione delle difese o per l'analisi dei danni e, se qualcosa non va, diventa un nostro problema. Dobbiamo approfittare di questi momenti per guardarci intorno e cercare di capire se l'ambiente in cui sono ospitate le nostre applicazioni sicure sia sicuro a sua volta. Se troviamo qualcosa che non ci sembra sicuro (magari perché non lo è), dobbiamo prenderne nota per riparlarne in séguito, quando la tempesta sarà passata.
È assolutamente controproducente alzare polveroni quando si è o si potrebbe essere sotto attacco e lo si deve fare solo se la vulnerabilità rilevata potrebbe essere sfruttata per violare o compromettere il sistema. Anche in questi casi, comunque, dobbiamo evitare di far apparire la segnalazione come un crucifige nei confronti di altri reparti IT.
Per far ciò, la cosa migliore da fare, se la gravità dell'attacco ce ne concede il tempo, è di parlare con i responsabili dell'apparato che ha generato il problema e capire se la vulnerabilità sia frutto di un errore, se sia un male necessario, o, come più spesso avviene, un po' di tutte e due le cose. Fatto ciò, dobbiamo verificare la possibilità di correggere il problema e valutare l'impegno necessario a farlo. Se non è possibile far nulla, rimandiamo ogni altra discussione a momenti più tranquilli; se invece c'è la possibilità di intervenire, chiediamo a chi di dovere di farlo. Se accetta, tanto meglio per tutti; se rifiuta, non avremo altra scelta che portare la controversia a un livello superiore. Questo però è un caso piuttosto raro, che si verifica quasi sempre perché non siamo riusciti a mantenere la comunicazione con gli altri gruppi su toni fondamentalmente bonari.
