Il debito di sicurezza delle applicazioni ha alcune analogie con il debito tecnico, ma lì sono poche le differenze a cui dobbiamo pensare quando decidiamo se il nostro carico di titoli di sicurezza è diventato troppo alto e deve essere ripagato. Mi piacerebbe sapere come calcolare i debiti di sicurezza nelle nostre applicazioni bancarie?
Il miglior consiglio che ho sentito è quello di trovare un elenco di tutti i diversi tipi di eventi che potrebbero verificarsi a causa del tuo debito di sicurezza. Successivamente, prova a stimare il costo di ciascuno di quegli eventi. Quindi, calcola la probabilità che tali eventi si verifichino ogni anno. La tua formula finale dovrebbe assomigliare a
Probability(event type 1) * Cost(event type 1) +
Probability(event type 2) * Cost(event type 2) +
... +
Probability(event type N) * Cost(event type N)
Ad esempio, supponiamo tu determini che ci sono due problemi che potrebbero essere sfruttati dall'addebito di sicurezza: SQL Injection + CSRF. (Ho inventato i numeri per semplificare la matematica):
Il costo stimato del debito di sicurezza per l'anno in questione sarebbe:
(5 * $ 100.000) + (10 * $ 25.000) = $ 750.000
A questo punto, non esiste un metodo standardizzato per calcolare la dimensione (l'inventario) del debito tecnico. Ho lavorato con un gruppo di ricerca composto da ricercatori di dottorato dell'Università di Glasgow e del MIT per iniziare a creare un quadro per affrontare questo problema. Stiamo unendo l'Analisi dei Processi Teorici dei sistemi del MIT per la sicurezza ( STPA-Sec ) e i concetti dell'architettura navale navale, noti come Progettazione delle vulnerabilità . Sebbene le tecniche siano destinate all'analisi di un'organizzazione e di eventuali sottoprocessi, è anche adatta per una singola applicazione come target per l'analisi.
Quanto segue è in fase di sviluppo e test. I concetti sono comunque utili.
Il calcolo del "Debito per la sicurezza delle applicazioni", per il mio team, è solo un'altra forma di "Systems-Theory Vulnerability Engineering". Questo è diverso dalla tipica gestione delle vulnerabilità che può essere affrontata con scanner automatici, patch e configurazioni. Invece, considera il "sistema" in questione (la tua applicazione, in questo caso) nel suo intero contesto di persone, processi e tecnologia mentre si collega ad altri sistemi. Da questa prospettiva di teoria dei sistemi, si determina quindi dove si trovano le vulnerabilità e le debolezze (vulnerabilità prossime al futuro).
Queste vulnerabilità potrebbero essere nell'intero spettro di:
Tutte queste cose rappresentano un "debito di sicurezza" o una "vulnerabilità dei sistemi".
Si noti che questo approccio non riguarda le minacce anche se le vulnerabilità possono essere definite attraverso la comprensione delle minacce. Questo non è un processo di modellazione delle minacce (vedere l'ultima sezione).
Finisci con un'analisi sistematica delle attuali vulnerabilità del tuo sistema.
Ma ora devi ancora determinare se devi fare qualcosa a riguardo.
Si finisce con un elenco di vulnerabilità di sicurezza con mitigazioni insufficienti. Questo è il tuo debito.
Si noti che non tutti gli elementi risultanti da questo processo sono tecnologici (in effetti, dai nostri casi di studio iniziali, pochi elementi sono tecnologici). Potresti scoprire che il tuo problema SQLi è in realtà un punto debole nei processi di revisione del codice che sono il risultato di una cultura dello sviluppo delle funzionalità e non della messa a fuoco della qualità del codice. Il debito, in questo caso, è culturale.
Questo è il punto in cui inizi a progettare i trade-off tra 1) riducendo le vulnerabilità in vari modi (persone o processi o tecnologia) e 2) migliorando i controlli di risposta in modo che gli obiettivi del sistema possano essere supportati .
Proprio come qualsiasi processo di mitigazione del rischio, è necessario mantenere i costi di mitigazione inferiori alle perdite attese e tutto deve essere completato per supportare gli obiettivi del sistema.
Utilizzando un approccio basato sulla teoria dei sistemi e sulla vulnerabilità, abbiamo scoperto che questo processo promuove rimedi che sono economicamente vantaggiosi e si rivolgono alla causa principale dei problemi, non agli effetti dei problemi. Identificherà inoltre le aree che devono essere rimosse al fine di ridurre le vulnerabilità (un processo sottrattivo).
Gli approcci incentrati sulla minaccia tendono ad essere reattivi, costosi, tecnologici e additivi (c'è una nuova minaccia, abbiamo bisogno di più cose!). Ciò ha l'effetto di creare più debito, non di ridurlo.
Stima del debito di sicurezza delle applicazioni Durante il processo di sviluppo del software, devono essere eseguite rigorose procedure di programmazione, analisi del codice e test delle applicazioni. Queste procedure sono rivolte in particolare a garantire che l'applicazione sviluppata sia della massima qualità possibile e che tutti i difetti di sicurezza siano sigillati. Tuttavia, nonostante la stretta osservanza delle procedure di sviluppo stabilite, una volta tanto l'applicazione sviluppata diventa vulnerabile. L'accumulo di queste vulnerabilità in un'applicazione diventa infine il debito di sicurezza dell'applicazione. Nel suo articolo, Chris descrive il debito dell'applicazione come "*
Security debt is similar to technical debt. Both debts are design and implementation constructions that have negative aspects that aggregate over time and the code must be re-worked to get out of debt. Security debt is based on the latent vulnerabilities within an application. Application interest rates are the real world factors outside of the control of the software development team that lead to vulnerabilities having real cost. These factors include the cost of a security breach and attacker motivation to discover and exploit the latent vulnerabilities
* “. Modello finanziario del debito della sicurezza delle applicazioni Attualmente, ci sono diverse metriche del debito di sicurezza delle applicazioni che cercano di stimare il valore del debito di sicurezza. In questo articolo, tratterò un post di Russell credo che aiuti ad affrontare il concetto di debito di sicurezza.
Nel suo post, Russell indica che *
“Application Security Debt is a ‘loan’ with variable principal which could range from 0% to 100% of your original project costs. The ‘principal’ is what you’ll eventually have to pay to fix security bugs or rewrite the code. It also has varying and uncertain ‘interest costs’, which are the costs of security breaches due to these vulnerabilities. This includes the possibility of the mother-of-all balloon payments (i.e. a huge loss event).”
*
Questo ci fornisce la formula del debito
Debito = Principali attesi + Costi per interessi
Il compito principale consiste nella stima dei valori del capitale atteso e dei costi di interesse.
Principal previsto Una cosa che dovremmo notare è che il valore del capitale atteso sarà sempre una percentuale del costo iniziale del progetto. Ciò significa che l'entità prevista può avere un valore compreso tra lo 0% e il 100% del costo iniziale. Ciò significa che il valore principale atteso può aumentare con un valore discreto F. La gestione si trova di fronte a diversi scenari, cioè possono: Non riscrivere (0%), Fai una piccola riscrittura (10%), Fare una grande riscrittura (25%), Fare una sostanziale riscrittura (50%) o Paghi una riscrittura del 100%. Il capitale atteso sarà quindi una percentuale del costo iniziale del progetto F moltiplicato con la probabilità che il management scelga tale opzione.
EP = Σ_ (i = 1) ^ 5▒ 〖p (F¬¬i) .c (Fi)〗
Dove F¬i = Scenario di correzione codice (i = 0..n = 5) P (Fi) = probabilità di scegliere uno scenario particolare C (Fi) = costo di fissare lo scenario scelto. Tuttavia, il Preside previsto varia in base al settore, alle dimensioni dell'azienda e alle risorse aziendali, tra gli altri fattori. La direzione determinerà la quantità di risorse da investire in diverse circostanze.
Costi per interessi I costi per interessi comprendono i costi relativi alla copertura dei costi di violazione. Esse sono sostenute dopo l'utilizzo della vulnerabilità di un'applicazione. Stimare il tipo di verosimiglianza e la probabilità che si verifichi una violazione dell'applicazione è difficile. Questo perché non esiste una relazione diretta che impone quale tipo di violazione si verificherà su particolari applicazioni.
Attualmente, le informazioni di base sugli intrusi sono rivolte alle applicazioni che gestiscono dati sensibili dei clienti, ma allo stesso tempo il livello di sicurezza in queste applicazioni che gestisce i dati sensibili è molto alto. A causa della natura dinamica delle violazioni della sicurezza, una vulnerabilità in una applicazione potrebbe influire sulla sicurezza di altre applicazioni. Ad esempio, molte organizzazioni preferiscono integrare applicazioni di terze parti con applicazioni interne. L'integrazione di queste applicazioni potrebbe influire sulla sicurezza di un'altra applicazione. Pertanto, sarà difficile stimare la probabilità.
L'uso dei dati per stimare i costi degli interessi potrebbe essere utile per stimare il valore del costo degli interessi. I dati di diverse aziende nello stesso settore possono essere utilizzati per determinare quanto una società sosterrà per far fronte alla violazione dei dati.
Leggi altre domande sui tag web-application banks risk-management appsec risk-analysis