Come devo archiviare e conservare documenti di configurazione sicuri?

2

Abbiamo molti script che chiamiamo "linee di base sicure" che consentono ai nostri addetti all'installazione di server / desktop di installare sistemi operativi usando le migliori pratiche di sicurezza. Testiamo che le linee di base siano state configurate correttamente utilizzando gli strumenti di controllo automatico della conformità.

Il problema che stiamo affrontando è che i documenti di Word diventano rapidamente obsoleti mentre la minaccia alla sicurezza cambia e li stiamo trovando un po 'ingombranti da mantenere e gestire.

Processo corrente:

  1. l'amministratore del server installa i server su una linea di base sicura seguendo le istruzioni in un documento Word
  2. o scrivi script di avvio rapido per installare automaticamente i sistemi operativi su una base di sicurezza basata sul documento di Word.
  3. Ogni tanto il documento di Word viene aggiornato quando viene riconosciuta una nuova minaccia.

Esiste un modo migliore per archiviare e mantenere le baseline? in modo che:

  • sono più facilmente verificabili
  • più facile tenere aggiornato riconoscendo le minacce nuove e attuali
  • più facile registrare eccezioni in cui alcuni sistemi non sono in grado di soddisfare i migliori principi di sicurezza
  • sono facilmente modificabili.
posta Callum Wilson 09.10.2013 - 14:50
fonte

2 risposte

3

Come alcune persone hanno raccomandato, usa uno strumento di gestione della configurazione come Puppet (consigliato), Chef, ecc. Usa VCS come Git per archiviare le revisioni dei manifesti di Puppet. Usando Puppet, puoi definire la tua linea di base sicura e applicarla semplicemente a qualsiasi numero di macchine che desideri. Aggiungi alcuni commenti al codice Puppet (codice Ops) e hai il tuo "documento di configurazione".

    
risposta data 10.10.2013 - 10:03
fonte
2

Generalmente una baseline non può essere cambiata spesso. Generalmente richiede molto tempo con uno standard che è un approccio più teorico e che può essere tecnologicamente indipendente. La linea di base è tecnologicamente dipendente e dovrebbe stabilire come configurare una nuova macchina per renderla adeguatamente indurita per quanto riguarda la sicurezza.

Un passo potrebbe essere quello di creare configurazioni generiche, già consolidate prima di essere implementate.

Se inizi a coinvolgere feed di vulnerabilità intelligence, sei nel campo della gestione delle patch, non del baselining. Una linea di base dovrebbe indicare di aggiornare la macchina alla versione più recente. Uno standard dovrebbe spiegare che tutte le macchine dovrebbero essere aggiornate a intervalli regolari usando il metodo di gestione delle patch. Il processo di gestione delle patch non deve essere definito all'interno della linea di base stessa.

Normalmente il controllo dovrebbe essere fatto nel modo seguente:

  • dopo la distribuzione finale, il dispositivo viene controllato per verificare se la configurazione ha valori corretti
  • a determinati intervalli, le macchine dovrebbero essere selezionate casualmente e la configurazione dovrebbe essere estratta, sotto la supervisione del revisore dei conti, e dovrebbe essere verificata rispetto alla linea di base. Gli script di conformità possono essere eseguiti, ma dovranno essere aggiornati ad ogni modifica di base (che normalmente non dovrebbe essere quella frequente).

Per i seguenti passaggi:

  • più facile tenere aggiornato riconoscendo le minacce nuove e attuali
  • più facile registrare eccezioni in cui alcuni sistemi non riescono a soddisfare il meglio principi di sicurezza

Prima di tutto tieni presente che, anche nel riconoscere le minacce attuali, queste non verranno pubblicate in centinaia all'anno, forse dieci al massimo (a seconda delle dimensioni dei dispositivi della tua organizzazione, se hai 10 dispositivi diversi che eseguono la stessa attività dovrebbe rivedere il provisioning dell'infrastruttura e il processo di progettazione / processo decisionale.

Per tenere traccia delle eccezioni, è necessario notare che le eccezioni devono essere registrate nel processo di valutazione del rischio. Se esiste un rischio che deve essere accettato, è necessario creare un documento formale che specifichi il problema, il rischio e la soluzione suggerita. Un comitato di revisione / rischio / impresa può quindi riesaminare questo documento e approvare o respingere la soluzione.

Il controllo delle versioni sarà migliore se:

  • inizi a utilizzare PDF con versione
  • registra ogni modifica alla baseline nel tuo strumento di gestione delle modifiche

Ogni aggiornamento di un documento sarà il risultato di un determinato incidente. O questo incidente è dovuto all'intelligence delle minacce (ad esempio, è necessario disabilitare la compressione SSL) oa causa di problemi operativi. Questo incidente genererà una risposta, da questa risposta dovrebbe essere generato un nuovo ticket dicendo che il documento dovrebbe essere aggiornato e convalidato dal comitato delle modifiche.

Se non hai utilizzato uno strumento di gestione dei rischi / gestione dei cambiamenti, ti suggerirei caldamente di crearne uno.

    
risposta data 09.10.2013 - 15:33
fonte

Leggi altre domande sui tag