Il potenziale impatto di questo non è basso, indipendentemente dalla quantità di informazioni memorizzate dal thin client.

In particolare, il rischio è che un utente malintenzionato installi qualcosa come un rootkit o un keylogger del software nel sistema operativo del thin client, che è improbabile che sia possibile scoprire tramite ispezione. (Questa è una variante dell'attacco Malvagità).

Se un amministratore dovesse mai utilizzare quel client in futuro, sarà game over per la rete. Il thin client può anche essere utilizzato come testa di ponte per lanciare ulteriori attacchi contro la rete o per condurre la ricognizione.

La protezione del BIOS impedisce che ciò accada, proteggendo l'integrità del sistema operativo thin client.

La lezione più ampia qui: la migliore pratica ti fa risparmiare le spese e la difficoltà di valutare ogni rischio, che come dimostra questa domanda, è difficile da fare.

I costi sono la base per valutare i rischi e le loro attenuazioni. Se i costi (costi monetari, costi operativi, costi di facilità d'uso ecc.) Per implementare una difesa (best practice, ecc.) Eccedono il danno causato dal rischio che si realizza, allora sei giustificato nella scelta di accettare il rischio .

Questo è un concetto piuttosto basilare nella gestione del rischio.

Le migliori pratiche non sono leggi ma raccomandazioni. Di solito vengono con una spiegazione del perché sono raccomandati. Se ritieni che la spiegazione non si applica nel tuo caso sei libero di ignorare la raccomandazione. Potresti anche avere ragione con questo sentimento e quindi puoi risparmiare sui costi.

Ma sappi che a seconda del tuo ambiente di lavoro non puoi semplicemente ignorare la raccomandazione, ma devi documentare perché ritieni che possa essere ignorata. Potrebbe anche essere che sei responsabile di persona se succede qualcosa di brutto perché le migliori pratiche sono state ignorate. Pertanto è spesso più facile e meno rischioso seguire le raccomandazioni piuttosto che ignorarle.

Ci sono una serie di fattori da considerare qui:

1. Qual è il costo dell'attuazione della misura? Proteggere tutti i BIOS può essere un problema, ma non è un esborso significativo di denaro o impegno.

2. qual è il rischio che succeda qualcosa di brutto? Le probabilità sono abbastanza basse, ma l'impatto è moderato (i keylogger sono menzionati, ci sono una serie di altri problemi con qualcuno che esegue il proprio codice sul proprio sistema, cioè che non è più il tuo sistema). Il rischio effettivo è basso-medio.

3. Qual è l'impatto dell'implementazione? Ci sono motivi legittimi per l'utente medio di accedere al BIOS del proprio thin client? Non proprio.

Quindi abbiamo qualcosa in cui la mitigazione non costa molto, non ha un impatto importante e protegge da un rischio basso-medio. Direi che è un buon argomento per implementarlo, personalmente.

In molti casi si riduce a una domanda su cosa significhi bassissimo rischio . Se hai una conoscenza esatta di quanto basso è il rischio, puoi fare calcoli sul costo previsto per non attenuare il rischio.

In realtà raramente conosci il rischio esatto. Spesso i potenziali problemi di sicurezza vengono liquidati come rischio molto basso senza alcun tentativo di valutazione effettiva del rischio.

In molti casi richiede meno sforzi per risolvere il problema di sicurezza piuttosto che valutare il rischio con sufficiente precisione per prendere una decisione informata su come affrontare la vulnerabilità della sicurezza. Per me questo è l'argomento principale per affrontare anche le vulnerabilità di sicurezza a rischio molto basso, perché significa che risparmi la maggior parte del costo associato alla valutazione del rischio.

Chi può sempre distinguere tra un problema di sicurezza noto per essere a basso rischio e uno ritenuto a basso rischio?

A volte è più produttivo valutare i problemi di sicurezza gli uni contro gli altri piuttosto che valutare ogni singolo problema di sicurezza contro una soglia di rischio basso.

Nel tuo esempio specifico puoi confrontare il rischio di modifiche malevoli delle impostazioni del BIOS al rischio di connessione di rete sul dispositivo che viene intercettato da un dispositivo MITM.

Sometimes, security best practices protect you against risks that are very unprobable. In that scenarios, how do you defend the implementation of these security measure?

Non dovresti difendere nulla; lascia che i numeri parlino da soli:

1. Probabilità di attacco X che si verifica = P.
2. Costo totale di X se si verifica = TC. (Questo deve includere la diagnosi e la correzione della violazione, le mancate entrate, la reputazione, le cause legali, la gestione delle crisi, ecc.)
3. Costo per adottare misure di sicurezza per prevenire X in primo luogo = C.

L'equazione è semplicemente:

C < P * TC

Quando l'equazione è vera, la misura di sicurezza dovrebbe essere implementata. Naturalmente, la parte difficile è il calcolo di P e TC, ma potresti scoprire che puoi essere eccessivamente prudente su TC e troppo ottimista su P e sarà comunque un investimento utile. Inoltre, hai anche il vantaggio di pubblicizzare le misure di sicurezza per investitori e / o clienti.

Questa è ovviamente una semplificazione eccessiva di tutti i fattori da considerare, ma da un punto di vista del ROI, la logica dovrebbe reggere.

La postura che adotti è basata sull'ambiente in cui stai operando. Per lo meno, le politiche di sicurezza che crei sono proporzionali al budget che hai e ai modelli di minacce che hai in mente. Senza una valutazione del valore del dollaro che stai proteggendo, trascorrerai una quantità esorbitante di tempo per capire dove si trovano i buchi. D'altra parte, gli elementi criminali usano elementi a basso / nessun elemento protetto per cercare obiettivi di valore più elevato.

Tieni presente che i venditori che intendono contribuire a mitigare i rischi non vengono con il proiettile d'argento per risolvere ogni singolo problema. In definitiva tu e il business siete gli unici responsabili della sicurezza. Da un punto di vista commerciale, potresti trasferire i costi di errori / difetti di sicurezza, ma a lungo andare potrebbe non essere d'aiuto. Al momento è un mondo piuttosto vecchio.

Quindi questa è una specie di estensione della risposta di schroeder .

Penso che ci sia un po 'di confusione in ciò che intendiamo con "rischio". Stai valutando il rischio dal punto di vista del sistema informatico (password del BIOS, installazione di AV, uso di un firewall, ecc.). La prospettiva di cui parla Schroeder è dal punto di vista del business: una volta che la macchina è stata compromessa, qual è il costo associato?

Quando un'azienda ha un "rischio", ci sono alcune cose può fare :

• Accetta il rischio - supponiamo che non accada nulla di brutto, e se lo fa non sarà un problema enorme da affrontare.

• Evitare il rischio: evitare l'esposizione al rischio.

• Limitazione del rischio (mitigazione) - Ridurre la probabilità che si verifichi il rischio.

• Trasferimento del rischio (CYA) - Assicurati che qualcun altro sia responsabile per il rischio.

Per essere chiari, i due tipi di rischio che vengono discussi nella discussione:

1. Il rischio un'azienda deve essere compromesso da un particolare sistema. Questo può includere informazioni finanziarie dei clienti (numeri di carte di credito, ecc.), Nonché informazioni proprietarie, segreti commerciali, informazioni classificate, ecc.

2. L'OP di rischio propone: il rischio che un computer venga compromesso in un modo specifico.

Ecco la sfumatura che sto ottenendo: il rischio # 1 è il business. La strategia per affrontare questo rischio è in genere attraverso limitazione del rischio (mitigazione) . Ecco dove entra in gioco # 2. # 2 attenua la probabilità che si verificherà # 1. Consideriamo molti metodi diversi in cui un computer può essere compromesso in # 2 e implementare misure preventive al fine di mitigare il più possibile # 1. Dal momento che molte "buone pratiche" sono economiche o senza cervello (vale a dire il loro costo è facilmente giustificato), ha senso seguirle anche se su base individuale il loro vettore di attacco è altamente improbabile.

Riguardo al tuo esempio:

Tutti gli accessi a un sistema / rete / foresta / cosa che contiene dati sicuri, devono essere mantenuti sicuri da un capo all'altro, non importa quanto sia piccola la fine.

Riguardo alla sicurezza in generale :

Tutto l'accesso a un sistema / rete / foresta / cosa che contiene dati protetti, deve essere tenuto al sicuro.

Perché?

C'è una ragione per questo. Un singolo punto di accesso a una rete che contiene dati protetti, ha bisogno di sicurezza. Le informazioni relative a ciò che è accaduto sul sistema in TUTTO devono essere sicure per mantenere i dati protetti fino in fondo nella parte più piccola sicura. Se un singolo collegamento nella catena si rompe, la catena è rotta.

Ma come posso interrompere quella catena se non ci sono informazioni di sicurezza sul client? Semplice, osservando la rete. Se riesco a vedere cosa succede nella rete, posso scoprire quali chiavi mi porteranno attraverso quali serrature, come e in quali modi. Quindi ho un modo semplice per entrare nella tua rete e ottenere i tuoi dati. Ecco perché, da un capo all'altro, TUTTE le attività devono essere mantenute sicure.

Andiamo all'esempio del punzonamento in faccia:

1. Pensi che la tua casa sia al sicuro.
2. Hai gli scanner di impronte digitali bio metrici (LIKE ON TV) che significano solo che le tue dita ti portano dentro
3. Tocca la maniglia di una porta di un negozio di fronte a 70 milioni di miglia di distanza, sei anni fa
4. Alzo quella stampa
5. Identifico la tua stampa (attraverso un lungo processo di elaborazione)
6. Uso quella stampa per aprire la tua casa mentre dormi
7. Ti do un pugno in faccia

Anche se era lontano chilometri, e quella stampa aveva molte altre stampe, e così via e in reparto, potevo ancora trovare la tua stampa e usarla per aprire la tua casa. Questo è molto improbabile, ma se VERAMENTE lo voglio, posso ancora prenderti a pugni in faccia con tempo, sforzo e un po 'di pazienza.

Tuttavia questo non fa altro che presentare un esempio. Diciamo invece la verità della sicurezza:

The most secure system in the world in buried underground, in an unknown location, burnt to a crisp, and destroyed.

Certo, è un po 'di lingua sulla guancia, ma ci viene l'idea. Quindi sì, questa best practice di sicurezza dovrebbe essere ancora utilizzata. Dopotutto il tuo sistema non è il sistema più sicuro al mondo, quindi dovresti cercare di avvicinarti.

Come è già stato detto, la sicurezza è principalmente un approccio basato sul rischio rispetto al costo.

Ma IMHO, c'è un altro punto in più: come nella sicurezza degli edifici, una porta rinforzata è di scarsa utilità se la finestra viene lasciata aperta. Per valutare correttamente un rischio è necessario sapere cosa si vuole proteggere contro. Quindi proteggere BIOS con una password perché potrebbe essere un vettore per un utente malintenzionato che potrebbe avere un accesso fisico . IMHO, se un utente malintenzionato può ottenere l'accesso fisico a un computer, questo computer è compromesso perché tutto potrebbe essere più felice: un keylogger fisico nella tastiera stessa, un analizzatore di rete tra il connettore interno e lo spinotto esterno, un dispositivo USB dannoso all'interno della scatola , ecc.

Ma la password del BIOS è ancora buona pratica perché può prevenire ulteriori infezioni se un attacco raggiunge il post, e soprattutto perché impedisce a un utente distratto o maldestro di rompere o compromettere se stesso il proprio terminale.