Policy mandate dilemma

Per citare AviD su questo:

Security at the expense of usability comes at the expense of security

Se rendi troppo difficile l'adempimento di una politica di sicurezza, la gente la ignorerà o cercherà scappatoie e soluzioni alternative che lo soddisfino alla lettera ma non allo spirito. In questo modo raggiungerai l'opposto di ciò che intendi e indebolirai la sicurezza.

Una politica di sicurezza dovrebbe quindi:

• Avere l'obiettivo di rendere le persone sensibili ai problemi invece di implementare le soluzioni.
• Incoraggiare le persone ad assumersi la responsabilità di mantenere una buona sicurezza invece di seguire ciecamente le istruzioni.
• SIA per lo più DOVREBBE politiche e NON DEVI politiche, quindi le persone possono divergere quando hanno una buona ragione.
• Trova un ragionevole compromesso tra sicurezza e usabilità.

Anecdote: I miei amici hanno lavorato in un team mantenendo un sistema con una politica delle password molto rigorosa. Non solo richiedeva modifiche regolari della password, una lunghezza minima e l'uso di numeri, lettere minuscole, lettere maiuscole e caratteri speciali, aveva anche una lunga serie di regole che avevano l'intenzione di impedire alle password di essere troppo simili alle precedenti Le password. Il risultato è stato che di solito si potevano trovare documenti nei cassonetti o disseminati nell'ufficio in cui le persone cercavano di costruire password per adeguarsi a queste rigorose politiche. Grazie alla politica della password, sarebbe stato incredibilmente facile ottenere le password attraverso i dumpster diving.

Alcuni consigli da qualcuno che ha scritto molti criteri:

Regola # 1.

Questa è la regola più importante. In realtà è un requisito per avviare qualsiasi altro processo. Se il team di gestione non intende appoggiare le politiche, non vale il tuo tempo, le aziende cronometrano, figuriamoci gli utenti il tempo di attuare qualsiasi cosa. Sto parlando del tuo livello C, se non sono a bordo, fermati ora. Salva la tua angoscia mentale.

Politica, standard, procedura, linea guida

C'è una drastica differenza tra loro, e dovresti leggerlo, ma in breve:

• Criterio - Perché ne abbiamo bisogno?
• Standard - Cosa è necessario per questo?
• Procedura - Come eseguiamo questo?
• Linee guida - Best practice, note importanti, ecc.

Le politiche sono obiettivi

Le politiche sono ciò che cerchi nella tua azienda. Le situazioni sorgono tuttavia dove non è sempre possibile raggiungere l'obiettivo delle vostre politiche. Chiamiamo queste eccezioni e di solito ci sono team che analizzano il rischio di non soddisfare i requisiti. Alcune aziende possono fare eccezione per un'inutile politica di sicurezza (molto cattiva) altre società sono così pesantemente regolamentate (pensate al settore bancario) dove il mancato rispetto della politica può significare un grande impatto per le operazioni delle società.

Gli utenti sono importanti ............ ish

Più grande è l'organizzazione, più utenti, più opinioni, più difficile da cambiare. Ad un certo livello i cambiamenti vengono attuati dalla direzione con l'aiuto dei dipendenti. Organizzazioni più piccole, può essere approvata dal dipendente con l'approvazione della direzione. Sembra simile, ma può essere molto diverso per le interazioni.

Sicurezza delle informazioni ha un tempo piuttosto difficile con la politica per il semplice fatto che normalmente stiamo costringendo altri gruppi a rispettare i nostri mandati. Nelle grandi aziende, forzare una politica come i requisiti delle password, non è qualcosa che l'IS è responsabile dell'implementazione. Normalmente è un team OPS o il proprietario dell'applicazione.

Non tutti hanno bisogno di un criterio, ma questo li colpisce

Jenny in Contabilità non si cura che Frank in IT sia richiesto da Paul in Information Security per assicurarsi che il server stia eseguendo TLS o per implementare una password minima nell'Applicazione Contabilità. A Jenny interesserà se non hai una politica e magicamente un giorno la password di Jenny di 1234 deve essere composta da 8 caratteri alfa numerici. Questa non è una politica, questo è un impatto e tu puoi o meno far parte di occuparsene. Nota semplice, HR è tuo amico.

In pratica hai due opzioni: 1) consideri le capacità e hai un processo per le eccezioni o 2) rifiuti di lavorare con chiunque non sia in grado di implementare le tue politiche.

Se non lo fai 1) e non puoi farlo 2) significa che le tue politiche esistono solo su carta. Se non si ha il potere di fare 2), si è lasciati a considerare le capacità. Direi, tuttavia, hai bisogno di avere una certa capacità di essere severi. Se un venditore non può fare un minimo di 12 caratteri, potresti essere in grado di accettare quella data altre strategie di mitigazione, ma non vorrai accettare problemi davvero eclatanti, ad es. una password di amministratore hardcoded.

Una cosa che potresti essere in grado di fare a seconda delle politiche adottate è far sì che le tue politiche si completino a vicenda, laddove l'implementazione di una politica diventa più facile e / o più sicura se implementa anche un'altra politica.

Ad esempio: si fornisce la politica di esempio dei requisiti della password. Se affianchi a questa politica anche una politica che impone ai tuoi utenti di utilizzare un gestore di password che possa occuparsi di creare e archiviare una password corretta in modo sicuro, i tuoi utenti saranno meno inclini a giocare al sistema, perché non giocheranno il sistema è più facile.

Un altro esempio: se si richiede agli utenti di utilizzare TLS sui propri server front-end, alcuni di essi potrebbero eseguire un'implementazione scadente con certificati scaduti o non sicuri. Una politica complementare consisterebbe nell'utilizzare Let's Encrypt per semplificare la gestione dei certificati.

Qualcosa che potresti usare simultaneamente sta incoraggiando le persone a implementare le politiche correttamente attraverso incentivi monetari. Non sto parlando di distribuire commissioni o multe a coloro che fanno un lavoro scarso, ma più di dare un piccolo sconto (come l'1% o qualcosa del genere) su cose come le tasse di licenza o di supporto basate su determinati obiettivi quantificabili ed equi. Ad esempio: se il sito web sul quale il tuo prodotto richiedente TLS è in esecuzione ottiene un A on Qualys (che è banale da controllare), ottiene uno sconto dell'1% sul successivo rinnovo della licenza (a meno che tu non sia quello che gestisce il sito Web, ovviamente).

Quindi scrivi la tua politica in modo tale che i segmenti si rinforzino l'un l'altro e ricompensi quelli che vanno al di là del dovere.

La risposta dipende dal motivo per cui stai persino pensando di impostare un limite di 12 caratteri.

Se è perché il sistema è noto per essere semplice da attaccare con password di 11 caratteri, e risulta essere computazionalmente impossibile da attaccare con password di 12 caratteri e le risorse di calcolo prevedibili del pianeta, allora lo si rende un requisito assoluto . Chiunque non possa o non vuole implementare quel limite semplicemente non soddisfa la tua politica di sicurezza, e basta. Le conseguenze per loro potrebbero essere davvero pessime (non possono vendere il loro prodotto), potrebbero essere gestibili o assolutamente insignificanti (usano un sistema diverso che fa affidamento sulla sua sicurezza su un valore diverso dai limiti di 12 caratteri e quindi ha una politica diversa ), ma quelle conseguenze sono giustificate .

Se imposti un limite di 12 caratteri perché non hai idea di quale limite si debba impostare, e 6 è ok ma non abbastanza per sempre, quindi lo hai raddoppiato, allora dovresti tenere conto di ciò che è pratico da implementare. Presumibilmente vuoi che le persone usino la tua politica (preferibilmente: se sono un dipendente che trova un lavoro che non li rende pazzi con richieste impossibili, se sono il CEO che lo ignora e acquista qualcosa che non soddisfa nessuna parte della vostra politica, se sono un fornitore che trova un altro cliente o raddoppia i loro prezzi per coprire lo sforzo supplementare). Pertanto, se la norma contiene requisiti arbitrari e onerosi, rischi di mettere a repentaglio le cose.

In pratica sei da qualche parte tra questi due estremi. Ma una volta che sai perché stai facendo il requisito, puoi decidere:

• è un requisito difficile. Tutto ciò che non lo soddisfa non è conforme alla politica.
• è una raccomandazione che ritieni sia realizzabile e spieghi le conseguenze della mancata soddisfazione.
• è cotto a metà. Devi fare più lavoro per stabilire quale dovrebbe essere il requisito prima di impostare la politica.

Considera anche l'obiettivo della politica. Se l'obiettivo dell'esercizio è quello di garantire che non si utilizzino fornitori con impostazioni di sicurezza mediocri o scadenti, quindi escludere i fornitori che non dispongono di buone impostazioni di sicurezza, sia a causa delle loro dimensioni ridotte o in altro modo, è un vantaggio di un requisito che può essere soddisfatto solo da chi ha una buona sicurezza. La politica è lì per guidare le persone, è anche lì per escludere le persone che non possono soddisfarle.

Who is going to get blamed when things happen? The security team right?

Sì, e ci sono due modi in cui la tua politica può fallire e ti verrà data la colpa. Può includere qualcuno che, con il senno di poi, ti rendi conto che avrebbe dovuto essere escluso e che tieni la colpa di una violazione della sicurezza. Può escludere qualcuno che, con il senno di poi, ti rendi conto che avrebbe dovuto includere, e ti viene incolpato per aver ostacolato il business della compagnia. Un sistema critico taglia in entrambi i modi - non vuoi che sia insicuro, e anche non vuoi che non venga mai costruito perché è troppo difficile rispettare la politica. Il tuo compito è trovare qualcosa che sia adeguato e realizzabile (o, se non puoi farlo, almeno per spiegare perché non così che qualcun altro possa essere coinvolto nella modifica dei vincoli con cui stai lavorando).

Una massiccia violazione della sicurezza è cattiva, ma se fosse intrinsecamente peggiore di quella dell'insolvenza, le aziende "giocheranno" (per esempio) non collegheranno mai nulla su Internet in primo luogo e andranno tutte a rotoli. Per ovvi motivi questo non è ciò che scelgono di fare. Pertanto, le disposizioni della politica devono essere giustificate e le giustificazioni devono essere disponibili per essere esaminate in un secondo momento, in modo tale che anche se qualcosa va storto, sembreranno ancora decisioni ragionevolmente buone, dato ciò che si sapeva al momento in cui le hai fatte.