Qualcosa che probabilmente dovrebbe includere quando costruisce i suoi prossimi modelli di minaccia

Qui in DisruptOps stiamo lavorando ai nostri modelli di minaccia, perciò ho deciso di aggiornare le mie conoscenze sui diversi approcci. Una cosa è emersa subito: quasi nessuna delle documentazioni o degli strumenti di threat modeling che ho visto copre la pipeline CI/CD.

Questo. È. Un. Problema. Includa la sua pipeline nei modelli di minaccia.

Negli ultimi anni ho condotto direttamente alcune decine di valutazioni di sicurezza del cloud, oltre a diverse altre attività di consulenza. Includo sistematicamente le pipeline di sviluppo/deployment nell'ambito di analisi, ed è spesso lì che riscontro alcuni dei problemi di sicurezza più rilevanti. Il suo ambiente cloud iper-sicuro è poco più di un castello di carte se qualcuno può modificare l'infrastruttura di base cambiando un template da qualche parte o compromettendo le chiavi archiviate.

La maggior parte dei modelli di minaccia parte da un diagramma di flusso dei dati o da un'architettura, che può utilizzare per esaminare l'applicazione modellando le minacce (personalmente preferisco STRIDE, che proviene da Microsoft). Questo copre le funzionalità applicative, ma non la pipeline.

Quando applica alla sua pipeline il modello di minaccia *du jour*, tratti gli sviluppatori/amministratori come utenti e tratti come utente anche la pipeline stessa, se dispone di credenziali archiviate (considerando il modo in cui si collega al suo ambiente).

Per esempio: qualcuno può falsificare una chiamata API verso Jenkins per innescare una modifica nell'applicazione di produzione? (Probabilmente sì, visto come Jenkins viene spesso configurato). E il ripudio delle modifiche ai job rispetto alle modifiche al codice? L'escalation dei privilegi nella pipeline?

Le pipeline tendono a non reggere molto bene un esame di sicurezza approfondito, perciò le affronteremo in futuri articoli sui fondamentali della sicurezza. Probabilmente non la sorprenderà sapere che tendo a raccomandare guardrail sia sui deployment della pipeline sia su qualsiasi infrastruttura collegata, per ridurre il rischio. Per esempio, il suo server CI non dovrebbe mai essere esposto o esponibile pubblicamente. Potrebbe utilizzare guardrail di rinforzo per garantire che si trovi in un segmento di rete privo di Internet Gateway e che i suoi security group non consentano l'accesso pubblico (meglio ancora, si assicuri anche che i server CI siano sempre dietro elastic load balancer).

I tempi in cui la superficie di attacco di un'applicazione si limitava ai suoi componenti sono finiti da un pezzo. Nel cloud la maggior parte delle nostre applicazioni è alimentata da pipeline, che hanno un enorme potenziale di diventare il punto debole, a causa degli accessi estesi e delle credenziali archiviate.