Un Framework per Integrare la Sicurezza delle Applicazioni nell'Ingegneria del Software (FIASSE)

Nota: Questo repository è un lavoro in corso. I contributi sono benvenuti!

Panoramica

TL;DR: si prega di leggere il DOC. Esplora il sito web FIASSE. Visita le GitHub Discussions per contribuire.

Questo repository contiene risorse e materiali per l'OWASP Framework for Integrating Application Security into Software Engineering (FIASSE). FIASSE (pronunciato /feiz/ come 'phase') è un framework indipendente dal fornitore che promuove un approccio basato sui principi e incentrato sullo sviluppatore per la creazione di software securable. Riconosce che la sicurezza è un processo dinamico e continuo come lo sviluppo. Introduce il Securable Software Engineering Model (SSEM) come un linguaggio di progettazione comune che utilizza termini consolidati dell'ingegneria del software per integrare la sicurezza nell'architettura, nella progettazione e nell'ingegneria del software, incorporando la sicurezza nei principi che plasmano il codice stesso. Il framework consente ai team di sviluppo di aggiungere valore informatico in modo resiliente, riducendo la probabilità di impatto materiale da eventi informatici durante l'intero ciclo di vita del codice.

FIASSE è un framework creazionale. Affronta il modo in cui la sicurezza viene implementata nel software, collegando direttamente le decisioni ingegneristiche a risultati securable. Non è un framework di assurance, un modello di maturità, né un sostituto di cataloghi di controlli o metriche di vulnerabilità. Integra tali approcci e allevia la pressione a valle su assurance e conformità.

Scopo

Fornire linee guida pratiche che rendano capaci gli sviluppatori di creare software securable senza richiedere una profonda competenza in materia di sicurezza, e guidare i professionisti della sicurezza nell'integrare efficacemente la loro esperienza di sicurezza nell'ingegneria del software. FIASSE raggiunge questo obiettivo attraverso una prospettiva di Ingegneria del Software, riducendo il carico cognitivo e favorendo la collaborazione tra team di sviluppo e di sicurezza.

In cosa è diverso?

Mentre i progetti focalizzati sull'assurance come l'OWASP Top 10 evidenziano cosa evitare (una block list), OWASP FIASSE fornisce un insieme di attributi e pratiche positive da seguire (una allow list). Questo approccio sfrutta le competenze esistenti di ingegneria del software per costruire software securable, invece di richiedere agli sviluppatori di apprendere tecniche di exploit o adottare una mentalità focalizzata sulle vulnerabilità. L'enfasi è sull'abilitare una codifica pratica e sicura attraverso principi ingegneristici familiari.

Definendo chiaramente il ruolo pratico della sicurezza all'interno del processo di sviluppo, questo framework garantisce che il valore aziendale venga catturato efficacemente. Stabilire aspettative di sicurezza esplicite prima che il codice venga scritto riduce la probabilità che difetti di sicurezza vengano scoperti e debbano essere corretti in seguito. Un'adozione efficace dovrebbe migliorare le metriche di assurance esistenti, ridurre il turnover dei risultati, produrre correzioni più durature e abbreviare i tempi di remediation.

Valori Fondamentali

FIASSE è orientato da quattro valori fondamentali. Ciascuno esprime una preferenza relativa: entrambi i lati hanno valore, ma quando è necessario fare delle scelte, FIASSE favorisce il lato sinistro.

Attributi Securable rispetto ai Controlli di Sicurezza: preferire le qualità ingegneristiche che consentono a un sistema di essere costruito e mantenuto difendibile rispetto ai controlli di sicurezza aggiunti a posteriori per compensare debolezze.
Partecipazione rispetto alla Valutazione: preferire un coinvolgimento strutturato tra sicurezza e sviluppo durante tutto il ciclo di vita rispetto a una valutazione eseguita dopo che il lavoro è stato completato.
Primi Principi dell'Ingegneria rispetto al Gergo della Sicurezza: preferire un fondamento sui primi principi consolidati dell'ingegneria del software rispetto al gergo specifico della sicurezza o alle euristiche avversariali.
Valore Aziendale rispetto all'Attività di Sicurezza: preferire una sicurezza che sostenga la creazione di valore dell'organizzazione rispetto a una sicurezza perseguita come fine a se stessa.

Principi Chiave

Il paradigma securabile: Non esiste uno stato statico di "sicuro". Un sistema dichiarato sicuro oggi potrebbe essere vulnerabile domani. FIASSE reindirizza l'obiettivo ingegneristico da "è sicuro?" a "è costruito in modo che la sicurezza possa essere mantenuta?" attraverso la resilienza adattiva, la sicurezza evolutiva e il miglioramento continuo.
Aggiungere valore informatico in modo resiliente: La direttiva primaria dell'ingegneria del software in un contesto aziendale. Il software deve soddisfare i requisiti funzionali sostenendo al contempo le qualità securabili che gli consentono di resistere al cambiamento, allo stress e agli attacchi che seguono ogni cambiamento.
Missione di sicurezza: ridurre l'impatto materiale: La missione della sicurezza è ridurre la probabilità di un impatto materiale di un evento informatico. L'eliminazione completa delle violazioni non è un obiettivo aziendale praticabile, quindi le strategie di sicurezza devono allinearsi agli obiettivi aziendali e alla propensione al rischio.
La relazione qualità-sicurezza: La sicurezza non può superare la qualità del software. Le qualità che rendono il software facile da comprendere, modificare, testare e osservare sono le stesse qualità che rendono possibile proteggerlo. L'investimento nella qualità ingegneristica è un investimento nella sicurezza.
Sicurezza incentrata sullo sviluppatore: Mettere in grado gli ingegneri del software di costruire sistemi securabili utilizzando principi di ingegneria del software familiari, anziché richiedere loro di adottare la mentalità di un penetration tester.
SSEM come linguaggio di progettazione comune: Utilizzare termini consolidati dell'ingegneria del software (ad es. Analizzabilità, Modificabilità, Testabilità) per definire e discutere gli attributi di sicurezza. Ciò rende la sicurezza accessibile agli sviluppatori e fornisce ai professionisti della sicurezza una base condivisa per la valutazione.
Allineare la sicurezza agli obiettivi di sviluppo e aziendali: Sicurezza e sviluppo sono complementari, non antagonisti. L'AppSec partecipa precocemente all'SDLC, in particolare durante la raccolta dei requisiti e la pianificazione delle funzionalità, affinché le aspettative siano esplicite prima che il codice venga scritto.
Il principio di trasparenza: I sistemi sono progettati in modo che le parti autorizzate possano comprendere lo stato interno e il comportamento. Logging strutturato, strumentazione e tracce di audit sono integrati nel codice anziché essere forniti solo da strumenti esterni.
Il principio della minima sorpresa: I sistemi si comportano in modi intuitivi e prevedibili per utenti, sviluppatori e amministratori. La prevedibilità agevola l'analisi, riduce il carico cognitivo e rende chiari i confini di fiducia.
I requisiti come cittadini di prima classe nell'AppSec: Funzionalità di sicurezza, scenari di minaccia e criteri di accettazione della sicurezza vengono forniti attraverso il processo dei requisiti. Le vulnerabilità sono comunemente riconducibili a un'aspettativa che non è mai stata specificata, quindi tale lacuna appartiene al processo dei requisiti.

FIASSE v1.1