Mantieni il software per tutta la sua vita utile

Assegna la manutenzione a un responsabile del servizio

Il software utile continua a cambiare dopo il primo rilascio. Le dipendenze ricevono correzioni. I runtime perdono supporto. I certificati scadono. Le regole aziendali cambiano. Gli accessi concessi durante la configurazione possono restare attivi più del previsto.

Mantieni un inventario di servizi, responsabili, versioni distribuite, dipendenze e scadenze del supporto. Includi lavoro pianificato e lavoro attivato da nuove segnalazioni. Riserva capacità a entrambi. Un backlog di manutenzione senza responsabile non protegge il servizio.

Separa la manutenzione dalla risposta immediata agli incidenti. Una credenziale esposta o prove di compromissione attiva possono richiedere contenimento prima che termini un normale ciclo di sviluppo. Rimanda questi casi al processo di risposta di sicurezza.

Assegna priorità all’esposizione effettiva

La gravità descrive le conseguenze potenziali. La priorità dipende anche da sfruttamento, raggiungibilità, dati, controlli esistenti e costo del ritardo. Un servizio interno con poco traffico può comunque contenere credenziali importanti.

Il catalogo Known Exploited Vulnerabilities di CISA registra vulnerabilità con prove di sfruttamento. Usalo come elemento per definire la priorità. L’assenza dal catalogo non dimostra che una vulnerabilità sia innocua. Catalogo CISA.

Considera questi problemi fittizi. I limiti temporali appartengono all’organizzazione di esempio; non sono scadenze universali.

Non trasformare automaticamente ogni segnalazione in un aggiornamento maggiore. Scegli una correzione supportata, esamina la compatibilità e verifica il comportamento importante. Registra le mitigazioni temporanee con un responsabile e una condizione di scadenza.

Segui la correzione fino alla produzione

Usa una sequenza tracciabile: segnalazione, decisione, modifica, revisione, deployment e verifica. Registra l’identificatore dell’artefatto realmente usato in produzione. Ripeti la scansione dell’artefatto o dell’ambiente pertinente dopo la modifica.

Per un pacchetto PDF fittizio vulnerabile, il team fa il merge di un aggiornamento alle 10:00. Alle 11:00 la produzione esegue ancora l’immagine di ieri. La correzione nel repository è completa. La correzione in produzione è incompleta.

Dopo il deployment, verifica sia la versione del pacchetto sia la generazione dei PDF. Una scansione delle vulnerabilità non dimostra che l’esportazione funzioni ancora. Un test funzionale non dimostra che il componente vulnerabile sia stato rimosso.

L’SSDF del NIST include identificazione e risposta continue alle vulnerabilità. Applica queste pratiche lungo il ciclo di vita, anche al software che riceve poche richieste di funzionalità. NIST SSDF.

Usa l’automazione con limiti visibili

Taiga Maintaining esegue scansioni dei repository collegati e può trasformare i problemi rilevati in iniziative di correzione. Controlla l’ultima scansione completa riuscita, la versione interessata e la modifica risultante. La scansione del repository non dimostra se il codice vulnerabile sia raggiungibile in produzione. Maintaining.

L’automazione può ridurre lavoro ripetitivo, ma il servizio ha comunque bisogno di responsabilità del deployment e verifica. Mantieni esplicite decisioni di rilascio, accessi di emergenza e scadenze delle eccezioni.

La manutenzione comprende anche la dismissione. Rimuovi route, credenziali, integrazioni e infrastrutture inutilizzate con un processo controllato. Prima di eliminare, verifica requisiti di conservazione e servizi dipendenti. Dismetti il servizio in esecuzione e assegna gli obblighi residui di conservazione o audit.

La prossima lezione approfondisce scansioni continue delle vulnerabilità e correzioni.