Comprensione dei processi in "persone, processi e tecnologia"

2

Nel modello di sicurezza "persone, processi e tecnologia" reso popolare da Bruce Schneier - link

Viene discusso di come si possono verificare attacchi / attacchi su uno di questi 3 livelli generali.

Per sfruttare la tecnologia, questo è relativamente comune. Pentests, sfruttando bug, ecc.

Per sfruttare le persone, lo vediamo attraverso il phishing, l'ingegneria sociale, ecc. (c'è un qualche elemento di sfruttamento che usa la tecnologia coinvolta)

Tuttavia, nei processi, non sono sicuro di come vengano sfruttati.

Le mie domande sono quindi:

  1. Che cosa significa un "processo"? Si riferisce a qualche insieme di regole (come un algoritmo) che le persone / la tecnologia seguono?

  2. In teoria, come si potrebbe sfruttare un processo? (qualsiasi esempio teorico lo farà)

  3. Un processo è mai stato sfruttato nella realtà? In tal caso, qual era e come è stato sfruttato il processo?

posta alf3nso 31.10.2017 - 03:14
fonte

1 risposta

2

Un processo può riferirsi a qualsiasi insieme di politiche o procedure che segui. Potrebbe essere algoritmico, o potrebbe semplicemente essere politiche documentate o procedure che hanno lacune o difetti. Cioè, anche se le persone coinvolte stanno facendo il loro lavoro alla lettera, e la tecnologia sta facendo ciò che è previsto e si suppone, il processo può essere abusato o sfruttato.

Per dare un esempio semplice, dire che un'azienda ha un sistema di ticketing dell'help desk che viene utilizzato per richiedere permessi e privilegi. È un evento comune che occorrono ulteriori informazioni sul ticket, in modo che gli utenti possano modificare i ticket che hanno creato e solo creare un ticket come utente connesso. Il processo è il seguente:

  1. Un utente crea un ticket, indicando quale base di codici o server a cui hanno bisogno di accedere.
  2. Qualcuno del team di sicurezza controlla che l'utente richiedente abbia tali autorizzazioni e aggiunge un commento al ticket o cambia lo stato del ticket per indicare che è approvato
  3. Qualcuno del reparto IT elabora il ticket, aggiungendo le autorizzazioni appropriate.

Sulla carta, questo potrebbe sembrare superficialmente sicuro, a condizione che le persone stiano svolgendo il proprio lavoro (ad esempio aggiungendo l'utente giusto al giusto set di autorizzazioni) e che il sistema di tecnologia / ticketing sia sicuro.

Ma cosa succede se entri come utente che dovrebbe avere il permesso di modificare la documentazione di aiuto, e dopo che viene approvato al punto 2, si modifica il ticket per dire invece che è necessario il permesso per accedere al codice sorgente che non si dovrei avere accesso a un database di produzione contenente informazioni sensibili, ecc.? L'utente del reparto IT nel passaggio 3 può visualizzare il ticket, esaminare l'approvazione e ora disponi delle autorizzazioni che in realtà non dovrebbero avere.

Quello che hai è un fallimento del processo, perché la politica ufficiale / documentata non tiene conto della possibilità di modificare i ticket. È possibile correggere il criterio non consentendo modifiche del biglietto dopo l'approvazione o richiedendo all'utente IT nel passaggio 3 di esaminare una cronologia di modifica del ticket, ma come documentato e seguito, il processo è fondamentalmente non sicuro.

Per spiegare in che modo i legami nel post del blog ti hanno collegato: la tecnologia e l'automazione potrebbero eliminare la scappatoia nella procedura stessa. Forse quando la sicurezza lo approverà, collegheranno direttamente il ticket nel repository a cui si suppone abbia il permesso, e verrà inoltrato al reparto IT come nuovo ticket o completamente automatizzato. Ciò rimuove entrambi uno dei fattori umani per errore (l'amministratore IT fraintende un biglietto sicuro e non modificato, o seleziona il nome utente errato), e la scappatoia del processo (nessuna verifica tra i passaggi 2 e 3).

    
risposta data 31.10.2017 - 05:57
fonte

Leggi altre domande sui tag