Sicurezza Applicativa: linee guida

Una sicurezza applicativa che venga gestita solo dopo che il prodotto sia stato rilasciato comporterebbe dei costi notevoli per la correzione di falle o bachi. Si parla infatti in questo caso di Retrofit security, una metafora che rende bene l'idea! Minima resa, massima spesa :-D

E' quindi necessario prevedere che in ogni fase del ciclo di vita del software sia posta opportuna attenzione anche alle problematiche di sicurezza (Secure SDLC), ossia non solo considerare fattori come efficacia, efficienza e usabilità ma anche sicurezza. I processi relativi alla sicurezza applicativa infatti si distinguono da quelli inerenti alla qualità del software perché, nel caso dei primi, gli attori coinvolti nello sviluppo in taluni casi devono pensare come utenti maliziosi mettendosi il cappello nero da "black hat".

Le linee guida qui proposte (prendendo spunto dai 7 touchpoints di Cigital) per lo sviluppo di applicazioni sicure rappresentano quindi un utile strumento da unire alla metodologia di sviluppo del software. Qualunque essa sia: dalla classica metodologia "a cascata" fino alle nuove metodologie "agili".

Gli attori dedicati alle diverse attività indicate nelle linee guida sono tutti quelli coinvolti nel processo di sviluppo del software: analisti, tester, il supporto, sviluppatori, etc.; con figure orientate specificatamente alla sicurezza del software che debbono appartenere necessariamente al mondo del software. Non dobbiamo fare lo sbaglio di mettere a capo della parte di sicurezza applicativa di un progetto software un esperto di network security. Serve un application security expert che sia prima di tutto esperto nello sviluppo di applicazioni.

Grande importanza rivestono anche organismi esterni allo sviluppo (ma interni all'azienda) che valutino con punti di vista differenti la sicurezza dei sistemi software. In un'azienda che decida di implementare un ciclo di vita del software sicuro c'è appunto bisogno di unità di coordinamento, supporto, formazione e controllo delle attività di sicurezza, non solo applicativa.

Dei CERT interni alle aziende potrebbero ragionevolmente essere deputati a tali funzioni, coinvolgendo eventuali outsourcer che possano offrire supporto nel caso di revisioni o test di sistemi preesistenti, revisioni spesso onerose e non sostenibili all'interno dell'azienda.

Nella figura seguente vi è un diagramma che evidenzia, dato un ciclo di vita del software di tipo a cascata o a spirale, le diverse attività di sicurezza applicativa che incidono nelle diverse fasi del ciclo e che rappresentano le linee guida per lo sviluppo di applicazioni sicure.

Le linee guida prevedono le seguenti fasi (in ordine) di sicurezza:

1. Casi di abuso: valutazione delle possibili minacce e dei pattern di attacco a cui l'applicazione potrebbe essere sottoposta e formalizzazione nella fase di analisi tramite gli "Abuse case"; i casi di abuso formalizzeranno le attività malevole indotte dalle minacce tramite i pattern di attacco con dei "modelli di attacco";
2. Requisiti di sicurezza: formalizzazione dei requisiti di sicurezza dell'applicazione alla luce dei casi di abuso elaborati;
3. Analisi dei rischi architetturale: analisi dei rischi con valutazione delle eventuali falle di sicurezza da un punto di vista architetturale; elaborazione delle opportune contromisure;
4. Revisione del codice: adozione di strumenti per l'analisi statica del codice che garantiscano velocità di correzione, knowledge base aggiornata e formazione continua dello sviluppatore;
5. Test di sicurezza basati sul rischio: pianificazione dei test di sicurezza applicativa legati all'analisi dei rischi effettuata in precedenza;
6. Test di intrusione: effettuare test di intrusione cadenzati su applicazioni critiche o fornite da outsourcer; possono essere utilizzate metodologie di test di sicurezza consolidate quali OWASP Testing guide;
7. Sicurezza in produzione: analisi delle possibili minacce e rischi a cui l'applicazione, una volta in produzione, è sottoposta in modo da aumentare la consapevolezza degli attori nel contesto della sicurezza applicativa;

• Revisioni esterne: gran parte delle attività di sicurezza dovrebbero essere svolte da esterni rispetto al team di progetto e sviluppo del sistema applicativo; questa attività incide in tutte le fasi del ciclo di vita.

I post precedenti:

• Sicurezza Applicativa: introduzione
• Sicurezza Applicativa: riferimenti
• Sicurezza Applicativa: Podcast su CLASP, 7 TouchPoints e Microsoft SDL

Qualche blog link:

• SDLC on the shoulders of giants
• Cigital’s Touchpoints versus Microsoft’s SDL
• Security is not all about Security Updates
• Securing Existing Code
• I nuovi Webcast sicurezza sono partiti