Ho letto sulla modellazione delle minacce applicative che rende sicuri i prodotti software dalle fasi iniziali (SDLC). Ma se facciamo qualcosa di sbagliato nella fase di distribuzione, questo sarà comunque un problema.
Ad esempio, un sysadmin apre una porta nel firewall che non è richiesta dal prodotto.
Quindi esiste una metodologia che possiamo utilizzare per identificare le minacce del tempo di implementazione?
In genere ciò che faresti qui è integrare una qualche forma di procedura di test nel tuo processo di distribuzione o di post-distribuzione.
Questo potrebbe essere leggero come una semplice scansione delle porte, che potrebbe identificare le porte lasciate aperte inavvertitamente o grande come una valutazione completa di sicurezza di terze parti (alias test di penetrazione) in cui si contrae una terza parte per rivedere la sicurezza del dispiegato sistema.
La cosa più importante che vuoi fare è capire e quindi comunicare quali sono le tue aspettative. Se il tuo modello di sicurezza vieta di aprire una porta del firewall, è documentato? (Per inciso, se ti aspetti di essere al sicuro perché sei dietro un firewall, ti suggerisco di ripensare, ma penso che tu stia usando questo come esempio.)
È possibile documentare in una "guida alle operazioni di sicurezza" o in codice, ad esempio uno script "check_security" o uno scanner cloud da convalidare. Entrambi hanno i loro usi e una guida può essere un buon modo per documentare e discutere le tue aspettative, mentre il codice si adatta meglio.
Una volta che hai una serie di aspettative nitide, ci sono molti modi per convalidarle.
In genere, il tuo codice verrebbe testato e amp; rimediato alle vulnerabilità negli ambienti di pre-produzione / produzione prima di entrare in produzione. Sì, non tutti gli ambienti sono uguali, quindi alcune misure che ho preso utilizzano Splunk (ovvero strumenti di correlazione dei registri) per monitorare le distribuzioni e correlarle con le attività Web per {x} ore dopo la distribuzione. Questa correlazione e avviso in Splunk mi ha aiutato a trovare traffico e schemi insoliti per quanto riguarda gli schieramenti, ad esempio improvvisi picchi di errori, cache errata che causa picchi di memoria, ecc.
Esistono anche strumenti come Contrast Security che fornisce Runtime Application Self Protection (RASP). In genere si integrano direttamente in IIS, ad esempio e bloccano gli attacchi. È diverso da IPS o WAF.
Leggi altre domande sui tag risk-management vulnerability threat-modeling threats vulnerability-scanners