Quale sarebbe un buon modo per creare un programma di test di sicurezza?

1

Mi è stato assegnato il compito di creare un programma / calendario di test di sicurezza formale per le applicazioni della nostra organizzazione, poiché la maggior parte dei nostri test correnti (scansioni, pentesting, ecc.) viene eseguita ad hoc.

Mi chiedo se qualcuno ha creato qualcosa di simile per la loro organizzazione e quale processo è stato utilizzato per costruire questo programma.

I miei pensieri correnti sono i seguenti:

  1. Crea un elenco di applicazioni disposte in categorie di criticità in base alla funzione che forniscono / alle conseguenze di un attacco riuscito (ad esempio, missione critica, critica, non critica)
  2. Determina cosa deve essere determinato per ciascun livello di criticità attraverso il test e determina quali test verranno eseguiti per ciascuno (ad esempio, i test del team rosso sono stati eseguiti solo in missione).
  3. Determina la regolarità dei test e i tipi di test per ciascuna categoria di criticità.
  4. Crea una pianificazione di test.

Non ho avuto molte opportunità di pensare a quanto spesso test / tipi di test dovrebbero essere fatti, quindi sono molto aperto ai riferimenti al materiale che potrei esaminare per ottenere una migliore comprensione.

    
posta Wesley 01.12.2014 - 00:51
fonte

2 risposte

1

"Testing" non lo farà.

  1. Valutazione del rischio

Frequenza: bi-annuale

  • Risorse informative del documento (sistemi, reti, componenti dell'infrastruttura, ecc.)
  • Identifica le minacce a tali risorse (vulnerabilità, vettori di attacco, ecc.)
  • Esaminare e verificare in che modo i controlli e le misure di sicurezza esistenti attenuano o eliminano il rischio di tali attacchi (controlli di accesso, processi, politiche, standard di sicurezza, ecc.)
  • Identifica esigenze di sicurezza, rimedi o aree di miglioramento

Quando si categorizzano le risorse, non considerare semplicemente l'importanza del servizio che fornisce all'organizzazione (ad es. mission critical), ma considerare i rischi associati a potenziali compromessi, il valore delle informazioni, l'impatto di potenziale compromesso. Un sistema potrebbe essere del tutto irrilevante per le attività quotidiane dell'organizzazione, ma potrebbe essere di grande importanza in termini di informazioni che può fornire a un utente malintenzionato, se compromesso. Abbiamo avuto uno scherzo in ufficio in ufficio - uno dei nostri impegni più importanti non andava da nessuna parte, i server web e l'infrastruttura pubblica del cliente erano tutti solidi, ma siamo riusciti a compromettere il portatile della segreteria CFO. È interessante notare che aveva una copia del rendiconto finanziario della società - giorni prima che sarebbe stato ufficialmente rilasciato. Dal momento che il cliente era una società quotata in borsa ... sai dove va.

  1. Controllo sicurezza

Frequenza: trimestrale

Purtroppo, molti dimenticano che la maggior parte dei problemi può essere identificata osservando le cose dall'interno, piuttosto che testare dall'esterno. Una verifica eseguita correttamente può rivelare problemi che potrebbero non essere facilmente rivelati durante un pentest (diamo un'occhiata agli account definiti per quel gestore Tomcat). Ecco alcuni punti fondamentali:

  • Controlla le configurazioni (server, router, switch, firewall)
  • Verifica che le norme siano applicate (ad esempio, assicurati che gli account degli ex dipendenti siano stati rimossi, guarda le password e quando sono state modificate per ultime)
  • Guarda come sono configurati e fatti i backup, crittografati i dati sensibili, come viene implementato il controllo degli accessi (inclusi badge fisici e altri elementi apparentemente poco importanti)

_

  1. Ciclo di vita dei sistemi

Frequenza: in corso

Ogni volta che l'IT lancia un nuovo sistema, aggiunge una rete, o fornisce un nuovo servizio, o dismette una vecchia, il team infosec deve essere coinvolto per rivedere, analizzare e implementare le misure di sicurezza. Rendilo parte del processo.

  1. Vulnerabilità e revisione delle patch

Frequenza: settimanale

Quando ricevi quei bollettini sulla sicurezza, se contengono oggetti direttamente correlati ai prodotti / sistemi che hai installato, fai attenzione. Inoltre, non "presumere" che tutto sia aggiornato martedì - WSUS potrebbe funzionare correttamente, ma devi eseguire alcuni controlli di base e osservare i log.

Ci sono più elementi, ma questo è già troppo lungo e non sto scrivendo un libro. Altre cose da vedere:

  • Eventi di sicurezza, rapporti sugli incidenti e risposta agli incidenti
  • Giorni di sensibilizzazione sulla sicurezza
  • Tavola rotonda sulla sicurezza (che coinvolge l'amministratore delegato)
  • ...
risposta data 01.12.2014 - 13:06
fonte
0

Ci sono alcune risorse su cui vorrei indirizzarti per comprendere appieno gli approcci tradizionali e non tradizionali alla ricerca di risorse per la penetrazione. Due libri, uno: "CISO's Guide to Penetration Testing: un quadro per pianificare, gestire e massimizzare i benefici", e l'altro, "Efficace prova di penetrazione" di Kevin Pescatello e Matthew Larsen. Nel precedente libro, il capitolo 5 tratta quattro tipi di test: parallelo condiviso, parallelo isolato, serie condivisa e serie isolate. I test, idealmente, dovrebbero essere coordinati in base al modo in cui si collegano in termini di dati e flussi di esecuzione: i sistemi più connessi saranno probabilmente test condivisi in parallelo, ad esempio.

Inoltre, ho letto molto a rischio ultimamente, soprattutto a causa di un libro, "Misurazione e gestione del rischio informativo". Esistono molti modi interessanti per modellare il rischio per il calendario di test di penetrazione, come mettere prima i sistemi rivolti verso Internet, quelli indiretti e quelli isolati, ma anche i fattori di controllo dalla prevenzione della perdita, il rilevamento della varianza e la risposta, e l'abilitazione alla decisione. Quali sono i valori delle tue risorse? Qual è l'efficacia dei tuoi attuali set di controllo?

    
risposta data 04.12.2014 - 00:53
fonte

Leggi altre domande sui tag