Sicurezza Applicativa: best practice per l'analisi dei rischi architetturali
Continuiamo la saga sulla sicurezza applicativa e precisamente con le best practice per una buona analisi dei rischi architetturale.
L'analisi dei rischi architetturale è volta ad evidenziare eventuali falle di tipo architetturale, e quindi progettuale, che non potrebbero essere scoperte con la sola analisi del codice sorgente.
Si possono infatti distinguere due tipologie di errori che conducono a problemi di sicurezza applicativa: falle e bachi. Mentre per individuare i bachi nel codice potrebbe essere sufficiente la sola revisione del codice sorgente, per individuare le falle non è sufficiente il solo codice, ma è necessario invece avere la visione dell'intera architettura e degli elementi che la compongono.
Su tale architettura andrà fatta quindi una valutazione dei possibili rischi ovvero della probabilità che qualche tipologia di minaccia, sfruttando una o più vulnerabilità, arrechi un danno di un determinato impatto sul sistema applicativo.
Le best practice per questo tipo di attività sono le seguenti:
- Realizzare una vista complessiva dell'architettura: realizzare uno schema che rappresenti l'architettura del sistema software. E' importante che questo schema sia sintetizzato in un'unica pagina in modo da offrire una visione completa;
- Partizionare l'architettura in "zone di fiducia": individuare le cosiddette "trust zone", ovvero quelle zone architetturali definibili come: "high trust", ossia zone che debbano essere ad alta affidabilità; "medium trust", per la media affidabilità; "low trust" per la bassa affidabilità;
- Analizzare la "resistenza agli attacchi": analizzare quanto l'architettura resista agli attacchi formalizzati, anche con grafi di attacco, nei casi di abuso. Individuare le eventuali falle e mitigarle;
- Analizzare le "ambiguità": analizzare le possibili nuove falle non formalizzate nel modello di attacco e definire le strategie di mitigazione;
- Analizzare le "debolezze": analizzare le possibili falle introdotte dalle integrazioni di prodotti di terze parti e definire le strategie di mitigazione;
I/O:
- Input delle Best Practice: diagramma delle componenti e di deployment, modelli di attacco, casi di abuso.
- Output delle Best Practice: falle architetturali e strategia di mitigazione.
I post precedenti:
Qualche blog link:
Commenti
Posta un commento