Come devo impostare l'accesso di emergenza ai segreti aziendali-critici nel caso in cui io sia "colpito da un autobus"?

Ottieni un dispositivo USB. Metti tutti i segreti su USB, preferibilmente in un file KeePass. Nella documentazione, indica alla persona nuova dove si trova l'USB e come sbloccarlo, ma metti il dispositivo in un luogo fisico sicuro come l'ufficio del proprietario, la cassastrong dell'azienda, una cassetta di sicurezza, ecc. Da qualche parte fuori dalla portata del pubblico e lontano dagli sguardi indiscreti di altri dipendenti.

I vantaggi di questo piano sono:

• Non è su Internet o sulla rete interna
• Puoi essere certo che il nuovo dipendente è almeno riuscito a convincere la persona responsabile del luogo di stoccaggio che sono autentici (e molto probabilmente sarà affiancato da dipendenti di alto livello anche per avvicinarsi alla tua posizione di archiviazione).
• Se qualcuno tenta di raggiungere la flashdrive prima che tu, ehm, venga colpito dal proverbiale bus, qualcuno dovrebbe probabilmente pensare a se stesso: "Hmm, Andrew è ancora vivo. Perché qualcuno lo sta toccando?"
• Se qualcuno trova la tua documentazione, l'ammontare del danno che potrebbero fare è limitato (specialmente se sono riusciti a penetrare su Internet - pochissime persone stanno andando in viaggio per le tue informazioni).

Per trovare i gadget, hanno bisogno di 1) la documentazione, 2) accesso fisico, 3) di essere "struggente per i fiordi". L'USB è anche un piccolo pacchetto per la prossima persona: plug and play! O panico, a seconda di quanto sei importante per la compagnia.

Crea account "solo per uso di emergenza"

Per la maggior parte dei sistemi, si avranno alcuni tipi di account privilegiati utilizzati nella loro amministrazione quotidiana, che possono essere personalizzati o meno in base ai criteri dell'organizzazione.

Per quanto riguarda le credenziali, potresti perdere l'accesso a queste per vari motivi, sia dalla persona che li conosce colpiti da un autobus, sia perdendo l'archiviazione sicura prevista di tali credenziali (ad esempio perdere un computer in un incendio) o in qualche modo riuscendo a cambiare una password a qualcosa che non sanno, ecc.

Ciò che può essere utile è creare account separati per sistemi chiave che hanno pieno accesso, ma non sono pensati per l'uso quotidiano. Questo implica:

1. Al momento, nessuno è in grado di accedervi - nessuno conosce le password richieste.
2. Se qualcuno accede a loro, tutti dovrebbero essere informati (poiché non dovrebbe accadere in circostanze normali). Ad esempio, gli script automatici che inviano email a più utenti chiave al momento dell'accesso, tutte le azioni di tali account vengono registrate e il monitoraggio quotidiano si accenderà se qualcosa viene eseguito da tali account.
3. Quando richiesto, le persone possono accedere a questi account - un modo semplice è generare una lunga password o chiave, stamparla, metterla in una busta sigillata e firmata e bloccarla in una cassastrong.

Inserisci le tue procedure di backup e le credenziali

Quando mantieni le tue procedure, il piano hit-by-a-bus e gli elenchi di credenziali secondarie in qualsiasi modo sia conveniente per te, assicurati che questi documenti o database delle password siano accessibili anche dall'account di utilizzo di emergenza.

Forse una soluzione migliore per la tua situazione è progettare il sistema in modo tale che anche se sei investito da un autobus e le tue credenziali sono perse per sempre, non succede niente di male.

Forse è meglio pensare al problema come a due problemi, autenticazione e autorizzazione .

L'autenticazione stabilisce che tu sei chi affermi di essere. Alcuni sistemi possono sapere che una richiesta proviene davvero da te perché solo una persona con le tue credenziali potrebbe aver effettuato la richiesta e solo tu conosci le credenziali.

L'autorizzazione stabilisce che ti è permesso fare una certa cosa. Una richiesta può essere autentica ma non autorizzata.

Se almeno due persone sono autorizzate a fare una cosa, allora non importa se una di esse viene colpita da un autobus. Alice può essere uccisa da un autobus, e la conoscenza delle sue credenziali perse per sempre. Ma Bob conosce le sue credenziali, ed è autorizzato a fare qualsiasi cosa che Alice potrebbe fare.

Se il sistema è progettato in modo tale che chiunque possa essere letteralmente colpito da un autobus e ucciso, significa anche che è possibile revocare le credenziali di una persona. Gli ex dipendenti, in particolare quelli che partono in cattive condizioni, sono una responsabilità per la sicurezza. Non è possibile forzare un ex dipendente a dimenticare una password, quindi per sicurezza si dovrebbe cambiare tutte le password condivise ogni volta che un dipendente lascia. In pratica questo è troppo doloroso e non è fatto. Non condividere le password in primo luogo risolve il problema.

Non condividere mai le password mantiene anche la responsabilità . Non puoi gestire un'impresa senza amministratori, ma ti piacerebbe avere la possibilità di sapere se un amministratore particolare abusa dei suoi poteri. In definitiva, la minaccia di risoluzione o contenzioso dissuade qualsiasi amministratore dall'abuso. Se le password sono condivise, "deve essere stato uno degli altri amministratori con la password" è una difesa plausibile.

A volte ti imbatti in situazioni in cui sembra impossibile evitare di condividere una password. Ma di solito c'è una soluzione, anche se non è immediatamente evidente.

Hai bisogno di condividere le password di root? No, non puoi avere una password di root e invece usa sudo .

Quali sono le credenziali di root di AWS? Puoi invece utilizzare IAM.

Forse hai un'applicazione web particolarmente cerebrale che non puoi evitare? Potresti non essere in grado di risolvere questo problema ma puoi coprirlo: utilizzare un gestore di password che consente di condividere le credenziali tra più utenti. (So che LastPass può farlo). Mentre stai ancora condividendo la password, hai almeno un mezzo automatico per cambiarla e distribuire la conoscenza della nuova password. Cambia la password almeno ogni volta che un dipendente lascia, ma preferibilmente più frequentemente.

La maggior parte delle risposte qui si riferiscono alla gestione delle credenziali, probabilmente a causa di questa domanda esplicita nell'OP:

What's the best way to manage the "secrets" (passwords, private keys, MFA access) in this documentation to ensure it remains comprehensive without compromising security?

Tuttavia, il titolo pone una domanda diversa, che non vedo indirizzata:

Developing a secure hit by a bus plan

La risposta alla domanda quella è automazione.

Nei devops, trovo che la maggior parte del lato server della posizione si divide in due categorie:

• Correggi l'infrastruttura : di solito non c'è nulla da automatizzare: ogni problema è diverso. In questi casi la familiarità con l'infrastruttura (server, rete, modalità di interazione degli sviluppatori con i repository Git) è fondamentale.

• Gestisci l'infrastruttura : crea nuove istanze VM, configura Apache , abilita dev accesso alle risorse, ecc. Questo è il posto dove l'automazione è più visibile.

Il ruolo dell'automazione in quest'ultimo è ovvio, la chiave per risolvere con successo i problemi nel primo è l'automazione in quest'ultimo . Gli script Python e Bash automatizzati servono come documentazione vivente di ciò che è previsto dei server e della rete: quando il flusso di lavoro cambia, sono gli script che cambiano. Git registra le modifiche che potrebbero essere applicabili ai server meno recenti e i messaggi di commit git sono espliciti.

Questa non è un'altra idea su come farlo di per sé, piuttosto un punto per segnalare qualcosa che non è stato ancora discusso, ma è molto importante. Sto procedendo dal punto di vista che questi segreti sono davvero critici dal punto di vista aziendale.

Test.

Sono stati postati alcuni scenari di ripristino di emergenza. Alcuni sono semplici, alcuni sono più complessi. Maggiore è la complessità, più motivi per testare. Questo problema deriva da come testare qualcuno che viene "rimosso" dalla scena in un ambiente business-critical? Mettere un giro di 20 mm attraverso il tuo server di produzione durante il periodo natalizio, con il tuo ragazzo IT primario in incommunicado sarà difficile da ottenere attraverso il consiglio della tua fabbrica di giocattoli. Questo è il dilemma di fronte al tavolo. Se è importante, è necessario testarlo. È troppo importante testare però?

Le cose semplici ti sorprenderanno. Qualcuno ha detto di mettere i dati nelle casseforti. Grande. Un sacco di gente tiene le cassette di sicurezza nel seminterrato dove è sicuro e lontano dalla gente. È anche il luogo che inizialmente si riempie di acqua dopo un incendio minore. Un altro; il tuo ingannevole impiegato dei libri paga ha fatto cose davvero losche con il tuo libro paga. La polizia entra e confisca tutti i tuoi server per l'indagine successiva. Ci vuole un anno per riaverli. Non roteare gli occhi: succede.

La business continuity è un'arte abbastanza consolidata, quindi fai semplicemente ciò che fanno la NASA, Google, Barclays, l'esercito e le centrali nucleari. Crea ridondanza. Mi dispiace dirlo Andrew, ma tu sei il principale rischio per l'azienda in questo scenario. La scheda deve essere informata di questo, e tu e almeno alcuni dei tuoi kit devono essere resi ridondanti (nel senso della duplicazione).

Nel frattempo, chiedi al direttore delle operazioni di assicurarti un'assicurazione per persone critiche e / o per la continuità aziendale.

Mi trovo in una situazione molto simile all'amministratore IT di una società di medie dimensioni con un sacco di software personalizzati sparpagliati e vagamente correlati su piattaforme diverse. Peggio ancora, ho scritto tutto il software per l'azienda negli ultimi dieci anni, dal loro sistema POS alle prenotazioni online, un CMS homebrew, software di formazione dei dipendenti, ecc. A questo punto sono l'unica persona che capisce o ha mai ho persino visto la fonte di queste cose. Mentre la compagnia è cresciuta, mi è stato chiesto più volte di non essere investito da un autobus. Ti dirò qual è stata la nostra soluzione.

1. Comprendi che ci saranno interruzioni. Gestisci le aspettative. Se la società non vuole assumere una persona in esubero, presumibilmente una persona ben pagata, per imparare tutto ciò che sa, allora deve aspettarsi che ci sarà una curva di apprendimento molto ripida per chiunque debba entrare durante un'emergenza e prova a riempire le scarpe. Questo è vero non importa quanto sia grande la tua documentazione.

2. Assicurati che le fatture di servizio siano indirizzate all'azienda, non a te.

3. Continuità del documento commerciale. A un certo punto mi è stato chiesto di scrivere un documento in inglese, che il CEO della società può leggere, esattamente quali server abbiamo, cosa c'è su ciascun server, cosa fa ogni pezzo di software e le password per quelli conti. All'interno di questo sono note e suggerimenti per chiunque sia arrivato e ha bisogno di tenerlo in esecuzione. Tuttavia, per (1) si intende che occorrerebbe un libro per spiegare in dettaglio le funzioni, i problemi noti e le limitazioni e la struttura di tutto il software. Quindi questo documento contiene gli elementi essenziali, con la speranza che una volta che qualcuno è entrato nel codice inizieranno a guardare le attività di cron e a leggere i commenti e a capire come funziona.

Aggiorno il documento di continuità quando necessario, PGP lo crittografa in modo che possa essere aperto solo dal CEO della società e da me stesso e caricarlo sul proprio server web all'indirizzo che conosce. Il CEO è responsabile di mantenere la sua chiave PGP al sicuro. Questo è tutto quello che c'è da fare.

E ascolta - se non ti lasceranno nemmeno rilassare dopo che sarai morto, è ora di chiedere un aumento.

La tua soluzione, per essere completa, deve essere una combinazione di controlli procedurali e tecnici. Il modo migliore per capirlo è vedere i controlli tecnologici come strumenti per migliorare la sicurezza procedurale. Rendono possibili alcuni controlli e altri più facili da eseguire.

Tenendo presente questo, dipenderà in gran parte da come stai usando la tua PKI. Se ti trovi in un'organizzazione più piccola, i vincoli di budget potrebbero limitare ciò che puoi fare, ma se possibile, ti consiglio un modulo di sicurezza hardware (HSM) per proteggere le tue chiavi private - come minimo, le chiavi private del tuo CA interna, se ne hai uno. I fornitori in questo spazio includono Thales e SafeNet.

Per quanto riguarda le password, esistono un certo numero di soluzioni per la gestione delle password progettate per le organizzazioni di servizi. La cosa più importante da cercare è una delle due cose: una soluzione che offre la possibilità di autorizzare un utente con i privilegi di accesso necessari per svolgere il proprio lavoro entro una finestra temporale predefinita senza dover assegnare a detto utente la password effettiva per il sistema / applicazione, AND / O un sistema progettato per supportare la conoscenza split-secret (dove nessuno ha la password completa).

Alcuni fornitori di sicurezza offrono un mezzo per creare ulteriore separazione dei ruoli in ciò che può fare un amministratore di dominio AD o un amministratore DB (ad esempio, potrebbero essere in grado di aggiungere utenti ai gruppi, ma non abilitare la possibilità di aprire / modificare effettivamente i file che l'appartenenza a quel gruppo di solito dà loro il diritto di - che l'abilità sarebbe gestita da un altro amministratore che allo stesso modo non può aggiungere / rimuovere utenti ai gruppi). Uno di tali fornitori è Vormetric: lo fanno con il loro prodotto di crittografia dei dati a riposo.

Sebbene il supporto esecutivo sia importante per il successo della strategia di sicurezza di qualsiasi organizzazione, diventa particolarmente importante in assenza di una soluzione vendor che fornisce queste funzionalità, poiché ciò significa che è necessario aumentare i programmi di sensibilizzazione sulla sicurezza per promuovere il tipo di cambiamento culturale che supporterà i controlli procedurali necessari a cui la maggior parte degli utenti IT non sono abituati - laddove i privilegi di amministratore di dominio e aziendali sono rigorosamente controllati e autorizzati solo dopo l'approvazione della gestione delle modifiche e solo durante una finestra temporale specifica . Gli amministratori IT devono incorporare password multiutente + controlli fisici.

Gli esempi includono l'utilizzo di 2-4 persone per generare metà di una password di 12 caratteri. Una coppia di personale genera la password e la inserisce nel campo "Nuova password". La seconda coppia rientra nei componenti della password creati dalla prima coppia (per garantire che una delle prime due coppie non stia digitando erroneamente o involontariamente la password ogni volta, rendendo l'account inaccessibile dopo aver modificato la password). L'utilizzo di una seconda coppia di personale garantisce inoltre che le password siano leggibili come scritte. Una volta modificata la password, i frammenti della password vengono quindi conservati in buste opache separate, sigillate, etichettate e depositate in sacchetti a prova di manomissione. Le borse possono quindi essere gettate in una cassastrong fisica. Replica il processo per l'archiviazione di backup off-site, ma incorpora processi per garantire che gli aggiornamenti delle password vengano replicati ogni volta per ciascun sito. Se la memoria a prova di manomissione non è sufficiente, cercare una cassastrong a doppia combinazione approvata GSA (X-10 Kaba Mas, per exmaple) e incorporare la stessa procedura di conoscenza divisa. Per una protezione aggiuntiva, conservare la cassastrong in un luogo con un sistema di telecamere a circuito chiuso che monitora l'area e incorporare un avvertimento a tutti i dipendenti che chiunque abbia trovato nell'area senza la preventiva autorizzazione scritta per entrare può essere soggetto a risoluzione. dall'alto.

Dipende solo dal tuo modello di minaccia e dall'appetito della tua organizzazione per la sicurezza.