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:
- Un utente crea un ticket, indicando quale base di codici o server a cui hanno bisogno di accedere.
- 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
- 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).