Che cosa può fare un'azienda contro gli addetti ai lavori imbrogliare e influire negativamente sull'infrastruttura essenziale?

What things can be done to prevent sudden rogue insiders from negatively impacting essential infrastructure using techniques they're privileged to do?

In pratica, molto poco . Ma per spiegare perché, lasciami parlare di cosa puoi fare.

Il problema qui è che l'utente è "privilegiato" - gli è stato concesso il potere legittimamente.

Ci sono alcune cose che possono essere fatte per limitare la potenza fornita agli utenti legittimi, anche agli amministratori privilegiati:

• Controlla i comandi disponibili utilizzando qualcosa come sudo o PowerBroker.
• Doppio controllo (la "regola dei due uomini" @ paj28 descrive
• Controlli del flusso di lavoro (che sono spesso una forma di doppio controllo)

Ora, questi controlli sono usati molto meno di quanto potrebbero essere. Perché? Poiché gli utenti privilegiati sono considerati affidabili per definizione . Quindi dico molto poco non perché non ci sono controlli, ma perché il rapporto costi-benefici di tali controlli quando applicato a personale fidato non è sufficiente per giustificarlo.

Si noti inoltre che il vettore di attacco qui era "nell'impianto idraulico" - se Citibank ha due controlli, probabilmente sono focalizzati su cose come trasferimenti di fondi, mentre questo attacco è arrivato alle ginocchia e ha semplicemente tolto la rete sottostante. Questi sistemi vitali ma silenziosi spesso hanno circoli più piccoli di utenti privilegiati e controlli meno eccessivi.

Il vero fallimento qui non era che non c'erano controlli tecnici, ma che i controlli del personale fallivano miseramente. È prassi normale revocare l'accesso ai dipendenti privilegiati prima che vengano interrotti. Chiunque abbia deciso che nessuna precauzione del genere fosse necessaria quando si introduceva un conflitto con un dipendente privilegiato ha utilizzato un giudizio insoddisfacente.

(La società ha anche utilizzato controlli punitivi - l'aggressore è ora condannato a quasi 2 anni di carcere e deve pagare quasi $ 80 mila. Come sottolinea l'articolo, queste cose non risolvono nulla di tutto ciò.)

Regola di due uomini : configura i tuoi sistemi in modo che tutti gli accessi privilegiati richiedano due persone.

Potrebbe trattarsi di un controllo fisico: l'accesso privilegiato può venire solo dal NOC e all'interno del NOC le persone applicano fisicamente la regola.

Più pratico sarebbe un sistema di scripting. Gli amministratori di sistema non hanno accesso root, ma possono inviare script da eseguire come root. Verranno eseguiti solo dopo che una persona separata ha esaminato e approvato la sceneggiatura. Ci sarebbe ancora bisogno di un metodo per l'accesso SSH in caso di emergenza - e la regola dei due uomini potrebbe essere mantenuta in quel caso usando i controlli fisici.

NSA ha implementato questo dopo le perdite di Snowden. Non ho mai visto un sistema completo di due uomini in nessuno dei sistemi commerciali o governativi che ho controllato - anche se ho visto vari tentativi parziali.

Aggiornamento - ci sono ulteriori informazioni su come implementarlo su domanda separata .

Un approccio è accettare che le azioni canaglia non possano essere prevenute e concentrarsi sull'assicurarsi che il danno possa essere riparato. Ad esempio, assicurati che i router dispongano di un piano di controllo separato tramite il quale possano essere riportati online. Assicurati di avere backup di sola lettura (ad esempio nastri off-site), quindi se qualcuno cancella tutti i dischi rigidi puoi recuperare i dati. Assicurati che i dati e il codice possano essere riportati rapidamente a uno stato buono noto.

Queste misure di sicurezza aiuteranno molto anche in caso di errori non intenzionali.

Audit. In particolare il traffico di rete e le azioni / operazioni eseguite su particolari macchine. Vuoi catturare, chi ha cosa , quando l'hanno fatto e da dove . Anche se questo non previene un attacco, aiuterà a scoraggiare tali azioni se l'insider ritiene che saranno identificati e catturati.

Quindi devi entrare nel problema dei meccanismi di auditing a prova di manomissione

La questione della protezione di un sistema o di una rete da parte di un insider, in particolare da parte delle persone la cui descrizione del lavoro include la creazione e la gestione di tale sistema, è sempre stata complicata.

In primo luogo, ciò che si deve capire è che, alla fine, è completamente impossibile impedire ogni tipo di attacco contro un'infrastruttura dall'interno, perché ciò implicherebbe la limitazione di tutti i contatti con l'infrastruttura , rendendolo particolarmente inutile.

Tuttavia, ci sono modi in cui possiamo prevenire e ridurre al minimo qualsiasi danno al sistema. Per questo processo, riconosco personalmente che ci sono tre fasi:

1. La regola di due uomini
2. La regola di responsabilità
3. Divisione del lavoro

Questi processi si completano a vicenda per aiutare qualsiasi sistema a rimanere al sicuro dagli intrusi che lavorano dall'interno.

La regola di due uomini

Iniziamo da quello più ovvio, la regola dei due uomini. Una parte importante della sicurezza IT e dell'infrastruttura è assicurarsi che tutto il comportamento all'interno del sistema sia identificabile e desiderato. Con questo si intende che qualsiasi azione intrapresa all'interno del sistema è trusted .

Quando mostro un esempio di questo, il mio modo preferito di spiegare è il sistema Git di Forking and Pulling. In Git, chiunque abbia accesso al repository (l'infrastruttura in questo caso) può fare una copia. Quindi, le persone con accesso possono richiedere di inserire il loro codice nel repository. Tuttavia, affinché ciò accada, il codice estratto deve essere analizzato, contrassegnato come compatibile e quindi autorizzato da qualcun altro.

Lo stesso potrebbe dirsi e fatto per un'infrastruttura sicura. Tutto il personale dirigente può modificare il codice, ma affinché le modifiche entrino in produzione, devono essere approvati da uno o più membri dello staff.

La regola di responsabilità

Un altro problema comune con alcuni tipi di sistemi e reti è che esiste un account di gestione, la cui password è nota a tutti i membri con accesso. Il primo problema con la responsabilità è sollevato qui. Molte aziende, quando si trovano in situazioni di membri non autorizzati che eseguono modifiche non autorizzate nel server, si basano su metodi primitivi come il controllo dell'indirizzo IP della macchina, per individuare chi potrebbe aver pubblicato modifiche al sistema. Ciò può essere risolto semplicemente assicurando che tutti abbiano il proprio account e informando che le loro modifiche sono state registrate.

Come accennato nell'ultimo paragrafo, la registrazione è il secondo problema. In questo caso, il problema di trust torna in superficie. Poiché il membro è fidato per apportare determinate modifiche al sistema, nella maggior parte dei casi il sistema non registra correttamente le azioni dell'utente.

Questa situazione è il punto perfetto per implementare la responsabilità dell'azione. L'utente della gestione deve essere consapevole del fatto che non solo le sue azioni vengono monitorate in qualsiasi momento durante la modifica dell'infrastruttura, ma anche le responsabilità legate al contratto e le sanzioni per le azioni deliberate.

Divisione del lavoro

Questo è un altro concetto trascurato nella maggior parte delle posizioni manageriali IT Infrastructure. I team IT hanno la tendenza a suddividere i propri compiti, tuttavia, non è raro che la maggior parte degli utenti abbia accesso per eseguire un'attività qualsiasi .

Il modo migliore per evitare ciò è di avere compiti specifici di gestione del sistema assegnati a due soli individui (per evitare casi in cui un individuo non è disponibile). Mentre altri utenti possono ancora verificare e approvare le modifiche, utilizzando la regola di due uomini , solo una manciata di utenti può effettivamente avviare tali modifiche in primo luogo.

Suggerimento personale

Un modo preferito di implementare la sicurezza a livello di sistema, specialmente in ambienti aziendali di grandi dimensioni, è costituito da 3 set di server. Alpha, Beta e Production, i primi due sono un clone di quest'ultimo. Chiunque può spostare le modifiche su Alpha, usiamo questo sistema per testare come reagirebbe in produzione. Beta è per le modifiche che sono state testate e sono pronte per essere distribuite. Per raggiungere questo stadio, diversi membri (~ 5) del dipartimento IT devono approvare la modifica. Quando in questa fase, il reparto IT documenta anche le modifiche e le invia a Management e Memo all'IT. Per raggiungere la produzione, 3 membri di gestione di alto profilo devono approvare la modifica, utilizzando i propri account, a cui non è possibile accedere dal reparto IT.

Ultima nota

Come avrai notato, non è un processo facile. L'implementazione di molte di queste idee rallenterà la produzione. Questa è una delle domande per eccellenza della sicurezza. Più un sistema è sicuro, più diventa difficile modificarlo e modificarlo. Per rendere produttiva la tua azienda, devi bilanciare Sicurezza e Fiducia .

Assicurandosi che i comandi che influirebbero negativamente sull'infrastruttura in modo tale che non possano essere accessibili da remoto, possono essere eseguiti solo localmente.

Questo può essere ottenuto in molti modi. Ad esempio, non consentire il comando di spegnimento. Un altro modo è disporre di un watchdog (dispositivo hardware che rileva i cambiamenti nella disponibilità) che riavvierà detta infrastruttura o eseguirà una procedura di ripristino se l'infrastruttura diventa irraggiungibile.

Un terzo modo è garantire l'accesso remoto, ad esempio utilizzando soluzioni KVM-Over-IP, e quindi legare queste risorse a controlli che possono essere manipolati solo sul posto. Pertanto, se l'infrastruttura viene disattivata, può essere facilmente ripristinata in remoto.

Ovviamente, è importante avere backup di file di configurazione, sistemi importanti e così via. Dato che i file di configurazione vengono raramente modificati, direi che un backup dei file di configurazione sarebbe utile dopo ogni modifica alla configurazione che è stata decisa per il commit.

Nel caso in cui sia necessario disconnettere l'infrastruttura a causa di eventi di sicurezza critici, è possibile utilizzare un sistema di emergenza che disconnetterà l'infrastruttura in modo facilmente recuperabile dalla gestione, senza richiedere una visita in loco.

Il problema qui non era proprio quel dipendente canaglia. Che cosa succede se quel dipendente ha fatto la stessa cosa, ma come un errore. Diciamo che la sua intenzione era quella di riparare un dispositivo di rete malfunzionante, non rendendosi conto che l'apparecchiatura verrà messa offline dopo una configurazione, e fa quel particolare codice e ampli; comando citato nella domanda, con l'intenzione di ricreare il file di configurazione dopo che è stato cancellato, ma dopo aver eseguito il comando, realizzando "oops, non può più connettersi al dispositivo".

E quindi causa lo stesso tipo di danno? Fidati di me, ho fatto lo stesso errore, soprattutto con i miei sistemi, che mi hanno poi richiesto di visitare la posizione fisica dell'attrezzatura. (ma in quel caso le cose non erano critiche, ma se i sistemi sono critici, dovresti fare qualcosa)

Ecco perché deve esistere la sicurezza, quindi è impossibile causare quel tipo di danno da remoto, intenzionale o meno.

Molte buone risposte qui, ma quella che sembra mancare è abbracciare il principio del privilegio minimo (PoLP). Se non esiste un caso d'uso legittimo per cancellare i file di configurazione del router, non dare a nessuno l'accesso per farlo. Se esiste un caso d'uso legittimo ma non è rilevante per le operazioni quotidiane, richiedere (e verificare) un processo di approvazione per ottenere tale privilegio (questa è, in effetti, una variazione sulla regola dei due uomini che si applica solo a operazioni particolarmente delicate).

Esistono anche backup e fail-safe. Per fare l'esempio originale, se la configurazione di un router è cancellata, dovrebbe ripristinare una configurazione failsafe non rimovibile (e generare un allarme). Questo dovrebbe accadere anche se fallisce un controllo sanitario interno. In alternativa, se si dispone di controlli di integrità, è possibile che il sistema ritorni ad una configurazione di "ultimo valore conosciuto", ripristinando essenzialmente se stesso da un backup se qualcosa va storto. L'accesso in scrittura a questi fail-safe / backup / controlli di integrità dovrebbe essere sottoposto a una sicurezza estremamente rigida - nessuno dovrebbe avere privilegi giornalieri per loro, o essere in grado di ottenere facilmente tali privilegi - tale che anche il più l'insider altamente affidabile non può ignorarli o sovrascriverli unilateralmente.

Ovviamente, tutte queste soluzioni avranno dei costi. C'è quasi sempre un compromesso tra sicurezza e risorse in scadenza (di solito descritto come "convenienza", ma le risorse possono anche essere tempo e / o denaro). PoLP davvero buono significa che nessuno ottiene un accesso root genuino (a livello di dio) a qualsiasi cosa, ad esempio, che rallenta le cose per le persone che possono probabilmente avere fiducia con tale accesso (non si può mai sapere veramente ). Il codice Failsafe è più difficile da scrivere rispetto al codice che si fida solo dei comandi inviati da una fonte "affidabile", anche se tale comando è HCF . La paranoia ha il suo prezzo ... ma quel prezzo potrebbe essere inferiore a quello che costa se perdi il 90% della tua connettività di rete.

Un solo dipendente non dovrebbe mai avere il potere di eseguire danni così estesi. Le azioni amministrative come queste dovrebbero sempre richiedere l'autenticazione da parte di due o più amministratori separati, in cui il sistema di autenticazione può essere disabilitato solo dagli amministratori di primo livello.

Nel caso in cui sia già accaduto, il datore di lavoro avrebbe tutto il diritto di licenziare il dipendente.

In ogni azienda ciò che ho visto, c'erano anche regole di sicurezza interne molto rigide. Non abbiamo potuto vedere nulla da altri progetti, solo i nostri compiti effettivi.

Se ci spostassimo tra progetti / reparti, le nostre autorizzazioni erano sempre ottimizzate con precisione.

Solo una serie ristretta di amministratori di sistema ha avuto accesso a grandi parti dell'infrastruttura, hanno lavorato tutti almeno 5-10 anni là. Probabilmente nessuno ha avuto accesso all'intera rete.

Connettere qualsiasi cosa alla rete aziendale senza il permesso esplicito (era addirittura impossibile richiederlo) era sempre severamente vietato. Una volta collegato il mio smartphone alla porta USB (solo per caricarlo), in 5 minuti mi è stato chiesto dal mio collega cosa sto facendo.

I nostri computer / laptop ci sono stati forniti preinstallati con i certificati aziendali. Dopo aver lasciato l'azienda, li abbiamo restituiti.

C'erano controlli di sicurezza regolari, questi sono stati fatti da una società esterna (- > nessuno sapeva, cosa e come fanno). Anche i nostri software che abbiamo prodotto sono stati esaminati da loro.

Ciò che abbiamo fatto sulla rete aziendale, sono stati probabilmente registrati e sottoposti a backup fino alla rete.

Se avessimo fatto qualche dubbio, non lo sapevamo, come saranno archiviati ed esaminati i registri. Dopo aver lasciato l'azienda, anche i nostri computer sono stati controllati dalla sicurezza dall'azienda esterna, e probabilmente hanno fatto il backup a livello di settore, per il caso di un "problema" che appariva più tardi, come prova.