Applicazione dell'approccio Continuous Security Development Lifecycle (Continuous SDL)

L'innovazione è la linfa vitale di un'organizzazione nell'era digitale e deve essere implementata e mantenuta. La sicurezza nell'innovazione protegge i processi e i dati da attacchi informatici. L'innovazione nell'era digitale ha la forma di sviluppo di applicazioni usando il metodo DevOps o DevSecOps . Questo approccio consente alle organizzazioni di innovare rapidamente senza attendere le pianificazioni tradizionali delle navi a cascata che possono richiedere mesi o anni tra le versioni.

Le funzionalità e le applicazioni con successo soddisfano tre tipi di requisiti diversi:

• Funzionale (sviluppo): l'applicazione deve soddisfare le esigenze aziendali e degli utenti, che sono spesso in rapida evoluzione.
• Secure (Sec): l'applicazione deve essere resiliente agli attacchi da utenti malintenzionati in rapida evoluzione e sfruttare le innovazioni nelle difese di sicurezza.
• Reliable (Ops): l'applicazione deve essere affidabile ed efficiente.

La combinazione di questi tre requisiti e la creazione di impostazioni cultura condivise sono fattori di fondamentale importanza, ma spesso complessi. I responsabili dei team di sviluppo, IT e sicurezza devono collaborare per favorire questo cambiamento.

Guardare il video seguente per altre informazioni sul metodo DevSecOps per l'innovazione sicura e rapida.

Integrare la sicurezza durante tutto il ciclo di vita dello sviluppo

È fondamentale integrare la sicurezza durante tutto il ciclo di vita dello sviluppo per identificare e correggere rapidamente progettazione, codice e altri problemi, mentre le persone lavorano su tale parte del processo. Questo approccio evita correzioni più costose e difficili in un secondo momento che possono causare una grande quantità di rielaborazione.

I rischi per la sicurezza (e la necessità di attenuarli) possono verificarsi in qualsiasi momento del ciclo di vita dello sviluppo:

• Progettazione : assicurarsi che la progettazione non consenta naturalmente agli utenti malintenzionati di ottenere facilmente l'accesso non autorizzato al carico di lavoro, ai relativi dati o ad altri asset aziendali nell'organizzazione.
• Codice : assicurarsi che la scrittura (e il riutilizzo) del codice non consenta agli utenti malintenzionati di assumere facilmente il controllo dell'applicazione per eseguire azioni non autorizzate che danneggiano clienti, dipendenti, sistemi, dati o altri asset aziendali. Gli sviluppatori devono anche lavorare in un ambiente sicuro che non consente agli utenti malintenzionati di assumere il controllo senza le proprie conoscenze.
• Compilazione e distribuzione: assicurarsi che i processi di integrazione continua e distribuzione continua (CI/CD) non consentano agli utenti non autorizzati di modificare il codice e consentire agli utenti malintenzionati di comprometterlo.
• Esegui : assicurarsi che l'ambiente che esegue il codice (cloud, server, dispositivi mobili, altri) segua le procedure consigliate per la sicurezza tra persone, processi e tecnologie per evitare che gli utenti malintenzionati compromettano e compromettano il carico di lavoro. Questo processo include l'adozione di procedure consigliate ben consolidate, configurazioni della baseline di sicurezza e altro ancora.
• Architettura e governance Zero Trust: tutte queste fasi devono seguire i principi Zero Trust per presupporre violazioni (presupporre compromissione), verificare esplicitamente l'attendibilità e concedere il privilegio minimo necessario per ogni account utente, identità del computer/servizio e componente dell'applicazione.

Cos'è DevSecOps?

L'innovazione tecnologica viene spesso sviluppata nel contesto di un approccio di sviluppo rapido, snella e agile che combina lo sviluppo e le operazioni insieme in un processo DevOps e l'integrazione della sicurezza in tale processo è fondamentale per attenuare i rischi per il processo di innovazione, la crescita dell'organizzazione e gli asset esistenti nell'organizzazione. L'integrazione della sicurezza nel processo crea un'operazione DevSecOps.

Sicurezza fin dalla progettazione e spostamento nelle fasi iniziali

Le organizzazioni adottano DevOps e altre metodologie di innovazione rapida e pertanto la sicurezza deve essere intrinseca nel tessuto dell'organizzazione e nei relativi processi di sviluppo. L'integrazione della sicurezza nelle fasi finali del processo è dispendiosa e difficile da correggere.

Spostare la sicurezza nelle fasi iniziali della sequenza temporale per integrarla nella definizione, la progettazione, l'implementazione e il funzionamento di servizi e prodotti. Quando i team di sviluppo si spostano a DevOps e adottano le tecnologie cloud, la sicurezza deve essere parte di tale trasformazione.

Nel modello a cascata la sicurezza era tradizionalmente un controllo di qualità al termine della fase di sviluppo.

DevOps ha esteso il modello di sviluppo tradizionale (persone, processo e tecnologia) per includere i team delle operazioni. Questo cambiamento ha ridotto il conflitto derivato dalla separazione dei team di sviluppo e delle operazioni. In modo analogo, DevSecOps espande DevOps per ridurre i problemi che si verificano a causa della separazione o dalla diversità dei team di sicurezza.

DevSecOps è l'integrazione della sicurezza in ogni fase del ciclo di vita devOps dall'inizio dell'idea attraverso la progettazione, la progettazione dell'architettura, lo sviluppo di applicazioni iterative e le operazioni. I team devono allinearsi contemporaneamente agli obiettivi di velocità, affidabilità e resilienza della sicurezza nell'innovazione. Con la comprensione reciproca e il rispetto reciproco per le esigenze dell'altro, i team lavorano prima sulle questioni più importanti, qualunque sia la fonte.

La metodologia Di organizzazione di Cloud Adoption Framework offre un contesto aggiuntivo sulle strutture DevSecOps in un'organizzazione. Per altre informazioni, vedere Informazioni sulla sicurezza delle applicazioni e funzioni DevSecOps.

Perché DevSecOps?

DevOps offre agilità, DevSecOps offre flessibilità sicura.

Quasi tutte le organizzazioni nel mondo guardano allo sviluppo di software per ottenere un vantaggio competitivo tramite l'innovazione. La protezione del processo DevOps è fondamentale per il successo dell'organizzazione. Gli utenti malintenzionati hanno notato questo passaggio alle applicazioni personalizzate e le attaccano quindi sempre più spesso. Queste nuove applicazioni sono spesso fonti di proprietà intellettuale importanti contenenti nuove idee preziose che non sono ancora diventate un prodotto nel marketplace.

La protezione di questa innovazione richiede che le organizzazioni affrontino potenziali punti deboli e attacchi alla sicurezza sia nel processo di sviluppo che nell'infrastruttura che ospita le applicazioni. Questo approccio deve essere applicato sia alla risorsa cloud che alla risorsa locale.

Gli utenti malintenzionati possono raggiungere i propri obiettivi sfruttando i punti deboli nel processo di sviluppo, nell'infrastruttura sottostante per i carichi di lavoro o in entrambi:

• Attacchi di sviluppo che usano punti deboli nel processo di progettazione e sviluppo dell'applicazione. Ad esempio, gli utenti malintenzionati potrebbero trovare codice che non convalida l'input (consentendo attacchi comuni come SQL injection) o potrebbero trovare che l'applicazione usi la crittografia debole (o nessuna crittografia) per le comunicazioni. Inoltre, gli utenti malintenzionati potrebbero impiantare le porte backdoor nel codice che consente loro di tornare in un secondo momento per accedere agli asset nell'ambiente o nell'ambiente del cliente.
• Attacchi all'infrastruttura che comprometteno gli elementi dell'endpoint e dell'infrastruttura ospitati dal processo di sviluppo usando attacchi standard. Gli utenti malintenzionati possono anche condurre un attacco multi-fase che usa credenziali rubate o malware per accedere all'infrastruttura di sviluppo da altre parti dell'ambiente.

Il rischio di attacchi alla supply chain del software rende fondamentale l'integrazione della sicurezza nel processo per questi aspetti:

• Protezione dell'organizzazione da codice dannoso e vulnerabilità nella supply chain del codice sorgente
• Proteggere i clienti da eventuali problemi di sicurezza nelle applicazioni e nei sistemi, che potrebbero causare danni alla reputazione, responsabilità o altri effetti negativi aziendali sull'organizzazione

Percorso DevSecOps

La maggior parte delle organizzazioni rileva che DevOps o DevSecOps per qualsiasi carico di lavoro o applicazione specifico è in realtà un processo in due fasi. Idee prima incubare in uno spazio sicuro e vengono successivamente rilasciate alla produzione come prodotto minimo praticabile (MVP). Vengono quindi aggiornati in modo iterativo e continuo.

Il diagramma seguente illustra il ciclo di vita di questo tipo di approccio all'implementazione dell'innovazione:

L'innovazione sicura è un approccio integrato per entrambe le fasi indicate di seguito.

• Incubazione idea, in cui un'idea iniziale viene definita, convalidata e preparata per l'uso iniziale in produzione. Questa fase inizia con una nuova idea e termina quando la prima versione di produzione soddisfa i criteri minimo di prodotto valido (MVP) per:
  • Sviluppo. La funzionalità soddisfa i requisiti aziendali minimi
  • Sicurezza. Le funzionalità soddisfano i requisiti di conformità normativa, sicurezza e protezione per l'uso in produzione
  • Operazioni. La funzionalità soddisfa i requisiti minimi di qualità, prestazioni e supporto per un sistema di produzione
• DevOps. Questa fase è il processo di sviluppo iterativo continuativo dell'applicazione o del carico di lavoro che consente l'innovazione e il miglioramento continui

Imperativo della leadership: unire le impostazioni cultura

Per soddisfare questi tre requisiti, è necessario unire le tre impostazioni cultura per garantire che tutti i membri del team rispettino tutti i tipi di requisiti e collaborino per raggiungere obiettivi comuni.

L'integrazione di questi obiettivi e impostazioni cultura in un vero approccio DevSecOps può essere complessa, ma vale la pena investirvi. In molte organizzazioni può esistere un elevato livello di conflitto appropriato tra team di sviluppo, operazioni IT e sicurezza che lavorano in modo indipendente, creando problemi in relazione agli aspetti seguenti:

• Distribuzione lenta del valore e bassa agilità
• Problemi di qualità e prestazioni
• Problemi di sicurezza

Anche se alcuni problemi sono normali e previsti con il nuovo sviluppo, i conflitti tra i team spesso ne aumentano notevolmente il numero e la gravità. I conflitti si verificano per motivi diversi, spesso perché uno o due team hanno un vantaggio politico e ignorano ripetutamente i requisiti di altri team. Nel corso del tempo, i problemi trascurati aumentano di volume e serietà. Se i problemi non vengono risolti, questa dinamica può peggiorare con DevOps perché la velocità nel prendere decisioni aumenta per soddisfare la rapida evoluzione delle esigenze aziendali e delle preferenze dei clienti.

Per risolvere questi problemi è necessario creare impostazioni cultura condivise che valorino i requisiti di sviluppo, sec e operazioni supportati dalla leadership. Questo approccio consentirà ai team di collaborare meglio e di risolvere i problemi più urgenti in qualsiasi sprint, indipendentemente dal fatto che migliorino la sicurezza o la stabilità operativa o che aggiungano funzionalità aziendali critiche.

Tecniche di leadership

Queste tecniche chiave possono aiutare la leadership a creare una cultura condivisa:

1. Nessuno vince su tutta la linea. I leader devono garantire che nessuna singola mentalità domini tutte le decisioni per evitare di causare uno squilibrio che può influire negativamente sull'azienda.
2. Prevedere un miglioramento continuo, non la perfezione. I leader devono definire un'aspettativa di miglioramento e apprendimento continui. La creazione di un programma DevSecOps efficace non è un'operazione rapida, ma un percorso continuo con avanzamento incrementale.
3. Evidenziare sia gli interessi comuni che i valori individuali univoci. Assicurarsi che i team possano capire che lavorano per ottenere risultati comuni e che ognuno di essi contribuisce con attività che gli altri non possono eseguire. Tutti i tipi di requisiti sono correlati alla creazione e alla protezione dello stesso valore aziendale. Lo sviluppo cerca di creare nuovo valore, mentre le operazioni e la sicurezza tentano di proteggere e preservare tale valore in diversi scenari di rischio. I leader a tutti i livelli dell'organizzazione devono comunicare questa comunanza e quanto sia importante soddisfare tutti i tipi di requisiti per un successo immediato e a lungo termine.
4. Sviluppare una comprensione condivisa: tutti i membri del team devono avere una conoscenza di base di:
   • Urgenza aziendale. Il team deve avere un quadro chiaro dei ricavi in gioco. Questa visualizzazione deve includere i ricavi correnti (se il servizio è offline) e potenziali ricavi futuri interessati da un ritardo nella distribuzione di applicazioni e funzionalità. Questa visione deve essere direttamente basata sui segnali degli stakeholder di leadership.
   • Rischi e minacce probabili. In base all'input del team di intelligence sulle minacce, se presente, il team deve definire un'idea delle probabili minacce che il portfolio di applicazioni dovrà affrontare.
   • Requisiti di disponibilità. Il team deve avere un'idea condivisa dei requisiti operativi, ad esempio tempo di attività richiesto e durata prevista dell'applicazione, e dei requisiti di manutenzione di risoluzione dei problemi, ad esempio l'applicazione di patch mentre il servizio è online.
5. Dimostrare e modellare il comportamento desiderato. I leader devono modellare pubblicamente il comportamento desiderato dei propri team, ad esempio mostrare riservatezza, concentrarsi sull'apprendimento e valorizzare le altre discipline. Un altro esempio è dato dai responsabili dello sviluppo che illustrano il valore della sicurezza e le applicazioni di alta qualità o dai responsabili della sicurezza che illustrano il valore dell'innovazione rapida innovazione e delle prestazioni delle applicazioni.
6. Monitorare il livello di conflitto correlato alla sicurezza. La sicurezza crea naturalmente un conflitto che rallenta i processi. È fondamentale che i leader monitorino il livello e il tipo di attrito generati dalla sicurezza:
   • Conflitto appropriato. Proprio come l'esercizio rafforza i muscoli, l'integrazione del giusto livello di conflitto generato dalla sicurezza nel processo DevOps rafforza l'applicazione, richiedendo una riflessione critica al momento giusto. Se i team stanno imparando e usano tali apprendimento per migliorare la sicurezza, ad esempio considerando perché e come un utente malintenzionato potrebbe tentare di compromettere un'applicazione e trovare e correggere bug di sicurezza importanti, allora sono in pista.
   • Conflitto non appropriato. Cercare un conflitto che ostacola un valore maggiore di quello che protegge. Questo attrito si verifica spesso quando i bug di sicurezza generati dagli strumenti hanno una frequenza elevata di falsi positivi o falsi allarmi o quando lo sforzo di sicurezza per risolvere un problema supera il potenziale impatto di un attacco.
7. Integrare la sicurezza nella pianificazione del budget. Verificare che il budget di sicurezza sia allocato in modo proporzionale ad altri investimenti nella sicurezza. Questo concetto è analogo a un evento fisico come un concerto in cui il budget dell'evento include la sicurezza fisica come norma. Alcune organizzazioni allocano il 10% del costo totale per la sicurezza come regola generale per garantire un'applicazione coerente delle procedure consigliate per la sicurezza.
8. Stabilire obiettivi comuni. Assicurarsi che le metriche relative a prestazioni e successo per i carichi di lavoro delle applicazioni riflettano gli obiettivi di sviluppo, sicurezza e operazioni.

Nota

Idealmente, questi team devono creare collettivamente gli obiettivi condivisi per ottimizzare l'adesione, sia per l'intera organizzazione che per un progetto o un'applicazione particolare.

Identificare il prodotto minimo funzionante di DevSecOps

Durante la transizione da un'idea alla produzione, è fondamentale verificare che la funzionalità soddisfi i requisiti minimi o il prodotto minimo funzionante per ogni tipo di requisito:

• Gli sviluppatori si concentrano sulla rappresentazione delle esigenze aziendali per la distribuzione rapida di funzionalità che soddisfino le aspettative di utenti, clienti e responsabili dell'organizzazione. Identificare i requisiti minimi per garantire che la funzionalità sia utile per il successo dell'organizzazione.
• La sicurezza mira a soddisfare gli obblighi di conformità e a difendersi dagli utenti malintenzionati che cercano continuamente di ricavare un guadagno illecito dalle risorse dell'organizzazione. Identificare i requisiti minimi per soddisfare le esigenze in termini di conformità alle normative, mantenere un comportamento orientato alla sicurezza e garantire che le operazioni di sicurezza possano rilevare rapidamente un attacco attivo e rispondervi.
• Le operazioni si concentrano su prestazioni, qualità ed efficienza, garantendo che il carico di lavoro possa continuare a offrire valore a lungo termine. Identificare i requisiti minimi per garantire che il carico di lavoro possa essere eseguito e supportato senza richiedere enormi modifiche all'architettura o alla progettazione nel prossimo futuro.

Le definizioni per il prodotto minimo funzionante possono cambiare nel tempo e con diversi tipi di carico di lavoro, poiché il team apprende dalla propria esperienza e da altre organizzazioni.

Integrare la sicurezza in modo nativo nel processo

I requisiti di sicurezza devono essere focalizzati sull'integrazione nativa con il processo e gli strumenti esistenti. Ad esempio:

• Le attività di progettazione, come la modellazione delle minacce, devono essere integrate nella fase di progettazione
• Gli strumenti di analisi della sicurezza devono essere integrati nei sistemi di integrazione continua e recapito continuo (CI/CD), ad esempio Azure DevOps, GitHub e Jenkins
• I problemi di sicurezza devono essere segnalati usando gli stessi sistemi e processi di rilevamento dei bug, ad esempio lo schema di assegnazione delle priorità.

Il modo in cui la sicurezza viene integrata nel processo deve essere migliorato continuamente in base all'apprendimento dei team e alla maturità die processi. Le verifiche di sicurezza e le valutazioni dei rischi devono garantire l'integrazione delle mitigazioni nei processi di sviluppo end-to-end, nel servizio di produzione finale e nell'infrastruttura sottostante.

Per altre informazioni su DevSecOps, vedere Controlli tecnici di DevSecOps.

Suggerimenti sull'analisi del percorso

La trasformazione richiede che questo stato ideale venga creato in modo incrementale in un percorso Molte organizzazioni devono affrontare complessità e sfide in questo percorso. Le più comuni vengono descritte in questa sezione.

• I cambiamenti in istruzione e cultura sono passaggi iniziali fondamentali:è necessario affrontarli con gli strumenti a disposizione. Il team di cui si dispone dovrà spesso sviluppare nuove competenze e adottare nuove prospettive per comprendere le altre parti del modello DevSecOps. Questo cambiamento in termini di istruzione e cultura richiede tempo, attenzione, sponsorizzazione e attività di completamento per consentire ai singoli utenti di comprenderne e acquisirne il valore. Il cambiamento drastico delle culture e delle competenze può talvolta attingere all'identità professionale degli individui, creando il potenziale per una forte resistenza. È fondamentale comprendere ed esprimere i motivi, gli elementi e le modalità del cambiamento per ogni singolo utente e per la relativa situazione.
• Il cambiamento richiede tempo: è possibile spostarsi nel percorso con la rapidità con cui il team è in grado di adattarsi alle implicazioni dovute all'operare in modi nuovi. I team devono sempre eseguire i processi esistenti durante la trasformazione. È importante definire con attenzione le priorità più rilevanti e gestire le aspettative sulla velocità con cui può verificarsi il cambiamento. Anche concentrarsi su una strategia di ricerca per indicizzazione, spostamento ed esecuzione, in cui gli elementi più importanti e di base devono essere considerati prima di tutto, sarà utile all'organizzazione.
• Risorse limitate: una sfida che le organizzazioni devono affrontare in genere nelle prime fasi consiste nel trovare talenti e competenze nello sviluppo di applicazioni e sicurezza. Quando le organizzazioni iniziano a collaborare in modo più efficace, possono trovare talenti nascosti, ad esempio sviluppatori con una mentalità orientata alla sicurezza o professionisti della sicurezza con un background nel campo dello sviluppo.
• Spostamento della natura di applicazioni, codice e infrastruttura: la definizione tecnica e la composizione di un'applicazione cambiano fondamentalmente con l'introduzione di tecnologie come serverless, servizi cloud, API cloud e applicazioni senza codice, ad esempio Power Apps. Questo cambiamento sta cambiando le procedure di sviluppo, la sicurezza delle applicazioni e consente anche ai non sviluppatori di creare applicazioni.

Nota

Alcune implementazioni combinano le responsabilità in termini di operazioni e sicurezza in un ruolo SRE (Site Reliability Engineer).

Sebbene la combinazione di queste responsabilità in un singolo ruolo possa essere lo stato finale ideale per alcune organizzazioni, si tratta spesso di un cambiamento estremo rispetto alle procedure, alle impostazioni cultura, agli strumenti e ai set di competenze aziendali attuali.

Anche se si ha come obiettivo un modello SRE, è consigliabile iniziare incorporando la sicurezza in DevOps usando i risultati rapidi pratici e i progressi incrementali descritti in queste linee guida per ottenere un buon ritorno sugli investimenti (ROI) e soddisfare le esigenze immediate. Ciò aumenterà le responsabilità in termini di sicurezza del personale operativo e di sviluppo, in modo da avvicinare le persone allo stato finale di un modello SRE (se l'organizzazione prevede di adottare tale modello in un secondo momento).

Passaggi successivi

Per indicazioni più dettagliate su DevSecOps, vedere Controlli tecnici di DevSecOps.

Per informazioni su come la sicurezza avanzata di GitHub si integra con la sicurezza nelle pipeline di integrazione continua e recapito continuo (CI/CD), vedere Informazioni sulla sicurezza avanzata di GitHub.

Per altri strumenti e informazioni su come l'organizzazione IT Microsoft ha implementato DevSecOps, vedere Toolkit DevOps sicuro.