Perchè la sicurezza applicativa è così... OSTICA ??!?

Semplice!!! Perchè non sempre è chiaro cosa sia esattamente !!

Il primo mito da sfatare è che la sicurezza applicativa sia sinonimo del solo "scrivere codice sicuro" e quindi ad esclusivo appannaggio dei programmatori. Questa visione riduttiva a lungo andare ha comportato una minore attenzione da parte dei responsabili dell' IT e dei CEO al problema della sicurezza nelle applicazioni creando una specie di Araba Fenice dove tutti ne parlano ma pochi sanno esattamente cosa sia e soprattutto come implementarla.

Ma quindi cosa è la sicurezza applicativa?

La sicurezza applicativa è un insieme di aspetti tecnologici coordinati da un processo proattivo e iterativo condiviso tra diveri attori!

Perchè è importante?

perchè ormai è anacronistico pensare alla sicurezza aziendale solo dal punto di vista perimetrale.E' invece necessaria una visione olistica di tutti i 3 livelli di sicurezza dell' IT : rete, sistemi ed applicazioni. Una vulnerabilità in uno qualsiasi di questi layer può compromettere l'integrità e la riservatezza dei dati aziendali.

Analizziamo un po' più nel dettaglio cosa intendiamo per aspetti tecnologi, processo proattivo e itereativo e diversi attori.

Aspetti tecnologici

Gli aspetti tecnologici che formano la sicurezza applicativa sono riassumibili nelle 10 categorie della seguente tabella:

e rapprenentano le macro aree di attenzione quando si progettano, scrivono e gestiscono le applicazioni.

Processo Proattivo e iterativo

Un processo che permetta di tenere sotto controllo tutti gli aspetti tecnologici appena visti durante le fasi del ciclo di vita del sofware indipendentemente dagli approcci allo sviluppo adottati (Agile, XP,Waterfall ..). Dalla fase di Planning fino ai vari momenti di maintenance ed integrazione con gli aspetti di gestione dell' IT.
Perchè proattivo? Perchè è in contrapposizione ad un atteggiamento tipicamente reattivo come potrebbe essere un processo basato solo sulle analisi statiche del codice e di attività di penetration test. Queste attività sono ottimi strumenti per determinare eventuali problematiche ma diventano veramente utili solo se inseriti in un processo che analizza le cause dei problemi di sicurezza e non solo i sintomi. Inoltre queste attività svolte una tantum riportano solo una fotografia, una istantanea della qualità del proprio codice nel momento in cui si eseguono i test ma non garantiscono la necessaria continuità.
Questo processo ha un nome e pure un cognome: SDL - Security Development LifeCycle- ovvero un processo di Risk Management applicativo.

 
Per chi è nuovo al concetto di SDL consiglio la lettura del "documento ufficiale" The Trustworthy Computing Security Development Lifecyclescritto dai suoi autori Steve Lipner e Michael Howard.

Perchè Iterativo? Perchè nessuno è perfetto !! E perchè col tempo le minacce e i metodi di attacco cambiano! Quindi anche lo stesso SDL deve essere continuamente migliorato ed aggiornato! Come si migliora il proprio SDL? La scoperta di vulnerabilità nel proprio software non deve portare solamente al processo di bug-fixing ma anche (e soprattutto) all' analisi del perchè il processo di SDL nei suoi stage non ha portato alla luce la problematica prima del rilascio del software. Questa importantissima attività permette nel tempo di rendere il proprio SDL più forte e più maturo!
L'esempio più significativo che mi piace riportare come esempio è quello dell'analisi del processo del proprio SDL che Microsoft ha fatto partendo dalla vulnerabilità dei cursori animati.

Diversi attori

La sicurezza applicativa deve essere analizzata dagli architetti durante la fase di design, dagli sviluppatori durante la scrittura del codice, dai tester per la fase di verifica, dagli IT PRO e dai responsabili della sicurezza all'interno dell'azienda durante vari momenti del ciclo di vita delle soluzioni ed infine dai responsabili delle operations per le fasi di maintenance nel tempo. Queste figure professionali sono importanti perchè rappresentano dei ruoli e delle attività ben precise, diverse ma complementari. Quindi non ha imporanze se ci troviamo in una Enterprise dove ogni singolo ruolo è coperto da più persone o da una piccola-piccolissima realtà dove tutte queste figure vengono ricoperte dallo stesso individuo, spesso chiamato anche ONE-MAN-BAND :-)

Facciamo una rapida carrellata delle attività legate alla sicurezza rispetto ai vari profili (noterete che alcune attività sono ripetute... non è una svista... indica che l'attività è in condivisione):

Architetto

E’ senza dubbio la persona più appropriata per definire le basi della sicurezza applicativa in vari ambiti progettuali:

• Supporto ai responsabili della sicurezza nella definizione delle policy aziendali di sicurezza che riguardano la sfera applicativa.
• Sicurezza della soluzione da un punto di vista del design e dei flussi.
• Definizione con il Project Manager delle caratteristiche di ALM.
• Definizione con gli esperti di sicurezza del piano di training sulla sicurezza per il gruppo di lavoro.
• Definizione delle security best practices che il team di sviluppo dovrà adottare.
• Aderenza alle policy di sicurezza dell’infrastruttura.
• Supporto ai responsabili delle operations nella definizione di:
  • processi di deployment (sicurezza).
  • processi di maintenance della soluzione che garantiscano un continuo livello di sicurezza/qualità durante le attività di bug-fixing.
• Threat Modeling.
• Intersezione tra il Threat Modeling applicativo con il Risk Assessment di infrastruttura.

Sviluppatori e Tester

Gli sviluppatori hanno il compito di :

• Seguire i piani di formazione per la sicurezza applicativa.
• Aderire alle security coding best practices definite per il gruppo di lavoro.
• Supporto e partecipazione attiva al Threat Modeling (Senior Developers).

La figurare del tester è spesso dimenticata nei progetti ma è di fondamentale importanza. Ripeto quanto già detto anche in altri mie post : i Solutions Architects possono disegnare una soluzione applicativa sicura by design, gli sviluppatori la implementano scrivendo il codice secondo le best practices del "Writing Secure Code" ma è solo durante la fase di testing che si può determinare se il prodotto è realmente sicuro e aderente agli standard aziendali !!!

• Seguire i piani di formazione per la sicurezza applicativa.
• Verificare l'adozione delle coding best practices.
• Valutazioni del attack surface.
• Pen Testing
• Fuzz Testing
• Collaborazione al Threat Modeling

Responsabili sicurezza

• Definizione delle policy di sicurezza dell'intera infrastruttura IT.
• Indicare come gli architetti dovranno utilizzare tali policy all’interno delle proprie soluzioni.
  • Ad esempio:quali meccanismi di autenticazione sono supportati dall’infrastruttura, dove gestire gli utenti dell’applicazione, come gestire la sicurezza dei repository delle utenze, come garantire gli aspetti di autorizzazione, come propagare l’identity dell’utente, ecc… (si ritorna alla tabella degli aspetti tecnologici!!! )

IT PRO

Gli IT Pro ricoprono le seguenti attività :

• Rendere disponibili le policy di sicurezza dell’infrastruttura che ospiterà l’applicazione.
• Intersezione tra il Risk Assessment di infrastruttura e il Threat Modeling applicativo.
• Verificare che le applicazioni siano effettivamente compliant alle policy.

La seconda asserzione è il vero punto dolente…Come è possibile effettuare le verifiche in modo automatico e il più esaustivo possibile? Tramite i test !!! Il problema vero è : come scegliere quali test devono essere eseguiti e chi implementa i test ?!?!
Come questo possa avvenire dipende da azienda ad azienda e soprattutto se il processo di sviluppo è fatto in casa oppure no. Comunque volendo delineare un minimo comune divisore molti dei test da utilizzare per la verifica delle policy deve arrivare dal processo di ALM/SDL del gruppo di sviluppo perchè dovrebbero aver creato dei test automatici in relazione a quanto definito dalle policy di sicurezza aziendali...!!!

Da un punto di vista pratico è necessario trasformare se non tutte molte delle policy aziendali in qualche forma "eseguibile" per poterle verificare tramite dei controlli strutturati (manuali o automatici). Microsoft mette a disposizione tool semplici come ad esempio FxCop fino ad arrivare ad una soluzione completa con Visual Studio Team Foundation Server (TFS) . Lo so cosa state pensando?!? Un Visual Studio per gli IT PRO...ma ha BEVUTO??? Ebbene NO... non sono ubriaco...sono lucido e presente :-) Visual Studio Team Foundation Server non serve solamente a chi sviluppa codice...(e questo è un altro mito da sfatare)...
Vi ricordate quando prima dicevo che l' SDL è un processo di Risk Management applicativo? Bene... l' SDL può essere visto anche come un processo di controllo della sicurezza/qualità del codice prodotto rispetto alle policy aziendali erogabile anche tramite l'uso di TFS !! (su questo punto importantissimo è necessario un post ad-hoc e comunque stiamo preparando alcuni Webcast dedicati proprio alla realizzazione pratica di questi scenari).

Un' ultima precisazione : abbiamo parlato di sicurezza applicativa rispetto a software che è stato sviluppato ad-hoc. Ma che fare se si acquista del software come una scatola chiusa??? Beh, il concetto non cambia... si espande solo un po'. Abbiamo le nostre policy aziendali e valuteremo il prodotto secondo tali policy ed eventualmente anche grazie ai nostri tool. L'importante è avere delle policy ben fatte affinchè si sappia cosa chiedere al proprio fornitore rispetto alle esigenze di sicurezza e gestione della privacy (e non solo ) dell'azienda. Certe volte saper esattamente cosa chiedere è già metà dell'opera :-)

Responsabili Operations

Una volta terminato lo sviluppo della soluzione è necessario garantire il livello di qualità (e quindi di sicurezza) del codice prodotto anche durante le attività di bug-fixing e di installazione di nuove versioni. Questa attività è estremamente semplificata qualora si sia adottato un processo di sviluppo adeguato. I processi di Change Management dovranno integrare anche gli aspetti di verifica della sicurezza del nuovo codice prodotto.

Cosa offre Microsoft Italia per aiutare ad implementare la Sicurezza Applicativa?

Microsoft mette a disposizione molto materiale per coprire quest'area:

• Whitepaper ed articoli in italiano sulla sicurezza nel sito MSDN.
• Il percorso formativo sulla sicurezza applicativa che vede come audience : Architetti, Developers e IT Pro. Questo percorso comprende una serie di WebCast sui vari aspetti della sicurezza applicativa.
• Il percorso formativo degli architetti. Anch'esso ha alcuni webcast sugli aspetti di sicurezza.
• In generale tutti i percorsi formativi avranno degli approfondimenti sull'argomento sicurezza.
• La NewsLetter di MSDN (MSDN Flash) oltre agli speciali sulla sicurezza (come ad esempio l'ultimo) dalle prossime edizioni conterrà in ogni numero un'area di focus sulla sicurezza applicativa per evidenziare le ultime novità in ambito whitepapers/webcasts ed eventi.
• Il sito MSDN di sicurezza applicativa.
• Il mio blog e quello di Feliciano anche se con focus diversi.
• Alcuni MVP molto esperti di sicurezza applicativa come:
  • Raffale Rialdi e Lorenzo Barbieri che possono dare un importantissimo contributo alla... causa :-)
• La maggior parte degli eventi MSDN e TechNet trattano temi di sicurezza (applicativa) anche quando non è il topic principale.
• Il Microsoft Security Day, la conferenza che normalmente teniamo verso Maggio-Giugno.

--Mario