Domanda:
Perché è importante applicare le migliori pratiche di sicurezza quando il rischio da cui proteggono è molto basso?
Eloy Roldán Paredes
2015-12-11 16:57:29 UTC
view on stackexchange narkive permalink

A volte, le best practice di sicurezza ti proteggono da attacchi molto improbabili. In questi scenari, come difendi l'implementazione di tali misure di sicurezza?

Ad esempio, proteggendo con password l'accesso al BIOS di un client thinc. Un BIOS senza password è un rischio perché un utente malintenzionato con accesso fisico può modificare la configurazione del BIOS per eseguire l'avvio da USB e accedere ai dati del sistema senza autenticazione. In questo caso, l'attaccante ha bisogno di un accesso fisico, il client thinc non memorizza troppe informazioni importanti, ecc. Il rischio è molto basso.

Altri esempi possono essere correlati ad alcune misure quando si rafforzano i sistemi.

In questo caso, è meglio non imporre questa misura di sicurezza per essere ragionevole con il resto dell'azienda o stai aprendo piccoli buchi che ti daranno un pugno in faccia in futuro?

I commenti non sono per discussioni estese; questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/32959/discussion-on-question-by-eloy-roldan-paredes-why-is-it-important-to-apply- secur).
Dieci risposte:
Ben
2015-12-11 18:00:32 UTC
view on stackexchange narkive permalink

Il potenziale impatto di ciò non è basso, indipendentemente dalla quantità di informazioni archiviate dal thin client.

In particolare il rischio è che un utente malintenzionato installi qualcosa come un rootkit o un software keylogger nel sistema operativo del thin client, che difficilmente sarai in grado di scoprire mediante ispezione. (Questa è una variante dell'attacco Evil Maid).

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

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

La lezione più ampia qui: le migliori pratiche ti consentono di risparmiare la spesa e la difficoltà di valutare ogni rischio, che come dimostra questa domanda, è difficile da fare.

Tuttavia hai bisogno di spiegare il rischio per giustificare questa specifica migliore pratica ... è la tua raccomandazione di esplorare il motivo dopo ogni migliore pratica (buona idea IMO) o di accettare le migliori pratiche come dogma senza mettere in dubbio il motivo (cattiva idea IMO )?
Se ritieni che le migliori pratiche non si applichino alla tua situazione, potresti avere ragione o semplicemente non comprendere appieno le ragioni. Ovviamente puoi indagare sui motivi e potresti ancora pensare che non si applicano. Ma devi considerare: "Quante probabilità ci sono che mi sbagli?" Non si può sapere tutto, non è conveniente. Indagare le ragioni con la speranza di evitare la pratica, può alla fine essere più impegnativo che implementare la pratica.
Posso accettare che nessuno sappia tutto, ma usando questo argomento posso dire che una buona pratica può introdurre una vulnerabilità ed essere più insicuro e potresti non vederlo perché nessuno sa tutto. Quindi, con questi argomenti non sono ancora sicuro se sia meglio applicare una buona pratica senza giustificazione o no ...
Le migliori pratiche rappresentano l'esperienza degli altri e la conoscenza e l'esperienza accumulate in molti anni. È meglio avere comprensione, ma in assenza di comprensione, la saggezza ricevuta generalmente è sufficiente.
Oppure potresti dire che le migliori pratiche sono cose che sono così spesso la cosa corretta da fare, che in genere è più facile farle che decidere se farle o meno e quindi garantire che la decisione rimanga corretta di fronte a cambiamenti futuri .
@SteveJessop - Esattamente. Penso che i "cambiamenti futuri" siano una delle considerazioni più importanti. Supponiamo che tu abbia fatto tutte le ricerche e (oggi) potresti essere sicuro al 100% e persino effettivamente corretto, che non è necessario seguire alcune "migliori pratiche". Ma qualche piccolo cambiamento domani, da parte di qualcun altro (anche un fornitore), potrebbe rendere importante quella best practice omessa.
Va tutto bene e va bene affermare che una buona pratica non vale davvero il tempo / sforzo / etc / e non dovrebbe essere davvero una buona pratica. Ma cercare di valutarlo ** prima di capire perché la migliore pratica è presente in primo luogo ** non è un buon approccio. Quando comprendi a fondo qual è la pratica e perché è stata considerata una best practice così com'è, puoi prendere la tua decisione informata se pensi che debba davvero essere una best practice. Ma, nel frattempo, sbagliare dalla parte della sicurezza con cose come questa potrebbe essere ... prudente.
Ho avuto la stessa idea (keylogger rootkit) di te. Tuttavia la mia conclusione è leggermente diversa: rischio a cascata. Qualsiasi piccolo rischio può spesso essere sfruttato in un modo che crea più vulnerabilità e il risultato finale può essere imprevedibile. Supponiamo che qualsiasi rischio noto possa decuplicare.
Questo è il motivo per cui dovrebbe essere eseguita una valutazione quantitativa del rischio, inclusa la valutazione sia dell '** impatto ** che della ** probabilità **. Ci sono molti attacchi improbabili, la domanda è: qual è il costo di implementare le contromisure rispetto al costo di un attacco riuscito? In molti casi, anche un singolo attacco riuscito può avere conseguenze devastanti, motivo per cui è consigliabile proteggersi, per quanto improbabili possano essere. Maggiore è l'impatto, minore è la probabilità.
@DrewJordan a volte il costo della valutazione è superiore al costo della migliore pratica ...
Ebbene, l'OP si chiedeva "come difendi l'attuazione di tali misure di sicurezza?" Hai detto che l'impatto non è basso e il PO ha già considerato la probabilità ... Questa è la tua valutazione in questo caso. OP chiedeva come giustificare le migliori pratiche: ecco come, con i numeri. Quanto ti è costato trovare questo esempio e documentarlo sotto forma di risposta? Molto poco sospetto, e ora hai un motivo per seguire le migliori pratiche. Sì, potrebbe costare più della semplice implementazione in primo luogo, ma ora hai la giustificazione, che ha anche un valore.
Il modo in cui lo giustificherei sarebbe dire "La valutazione completa del rischio costerebbe due giorni-uomo, quindi spiegare a ogni nuovo cliente perché non pensavamo fosse necessario sarebbe un progetto in corso, ma implementare questa best practice di riferimento del settore ci vorrebbero quattro ore .... Ora, vorrei valutare correttamente il rischio perché è un progetto interessante, ma sospetto che tu come azienda preferiresti che lo implementassi e poi passassi al lavoro successivo ".
Questa non è solo una buona risposta. Sei libero di non essere d'accordo con l'OP e il suo esempio. Ma il suo punto era che alcune "migliori pratiche" sono per eventi improbabili che potrebbero valere o meno il tempo per mitigarli. La domanda riguardava la difesa e la non applicazione delle "migliori pratiche" non la protezione del BIOS.
@SteveSether, Hai letto male la domanda o forse hai digitato male il tuo commento? OP non riguardava "difendere * non * applicare le migliori pratiche", ma "difendere * applicare * le migliori pratiche" di fronte alla pressione di non applicarle.
@Ben Hai ragione. Non ha molta importanza, poiché questa domanda risponde all'esempio e non affronta la domanda reale.
schroeder
2015-12-11 21:27:15 UTC
view on stackexchange narkive permalink

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

Questo è un concetto piuttosto basilare nella gestione del rischio.

Ma per molte delle solite best practice (password che proteggono il BIOS, crittografia del disco rigido di un server ...) il rischio può essere molto basso perché la probabilità è molto molto bassa tenendo conto delle altre misure di sicurezza già implementate. Forse potremmo dire che l'80% del rischio è coperto dal 20% delle misure di sicurezza ... quindi perché implementare l'altro 80% di misure di sicurezza che sono solo best practice difficili da giustificare?
Non sono difficili da giustificare. Perché pensi che siano difficili da giustificare?
valuta i rischi (tenendo conto della probabilità e di altre misure di mitigazione) e prendi una decisione in base al rapporto costi / benefici.
Ad esempio, un BIOS non protetto da password è un rischio se l'attaccante ha accesso fisico al dispositivo, sa come entrare nel BIOS, ha una pendrive preparata con un sistema operativo avviabile, ha un altro dispositivo per memorizzare ciò che sta per rubare , ha il tempo di eseguire tutto questo contro il dispositivo senza che nessuno se ne accorga, deve evitare tutte le altre misure di sicurezza fisica e tutto ciò per compromettere un client sottile che ha quasi tutto memorizzato solo l'accesso alla rete ad altri sistemi più rilevanti che hanno la propria sicurezza le misure...
La tua risposta non risponde alla mia domanda
Penso che siano difficili da giustificare perché sembra che il rischio sia molto basso e lo sforzo sembra alto per un rischio così "apparente" basso.
Ma questo è esattamente quello che ho detto nella mia risposta.
La chiave è il lavoro "apparente". Il "rischio apparentemente basso" è evidente perché è difficile misurare scientificamente che un rischio è alto o basso. Difficoltà a misurare * scientificamente * il rischio = difficile giustificare una migliore pratica contro il rischio.
Il rischio è una combinazione di probabilità e impatto. L'impatto è facilmente misurabile scientificamente. La probabilità è quasi impossibile da misurare scientificamente nel rischio infosec. Si basa sull'esperienza e sul giudizio. Sono ancora confuso su quale sia veramente la tua domanda, però! Anche se il rischio è difficile da misurare, è comunque possibile assegnare un livello di rischio e soppesare i costi di una "best practice" rispetto ad esso.
@Eloy: una volta che "l'attaccante ha preparato una pendrive", il resto è ridondante poiché qualcuno che è preparato ha coperto tutte quelle cose (incluso il problema del tempo: se è adeguatamente preparato, inserisce semplicemente la pendrive, spegne e spegne la macchina , seleziona per avviare dall'unità e poi lascia che faccia il suo dovere). Sembra che tu stia cercando di giustificare * non * farlo trattando un utente malintenzionato come se si affidasse a un sacco di coincidenze che si uniscono ("oh guarda, mi capita di avere una pendrive con me!") . Ma ovviamente sono preparati: sono un attaccante, è il loro lavoro.
@Schroeder D'accordo con quasi tutto quello che dici sopra. Tranne che "l'impatto è facilmente misurabile scientificamente". In realtà questo è un grosso problema con il motivo per cui molte persone sottovalutano il rischio cibernetico; non prestano attenzione a elementi di rischio molto importanti a cui è difficile dare un numero concreto. Quanto valeva l'enorme quantità di cattive pubbliche relazioni e violazione della fiducia con i clienti derivante dall'hacking Target? Quanto è stato enorme l'effetto sulla NSA e sul governo degli Stati Uniti dall'hack di Snowden? Ma gli elementi di rischio difficili da quantificare con esattezza sono ancora vitali per tenere conto in qualche modo del rapporto costi / benefici della mitigazione del rischio.
Ma il punto chiave è, ovviamente: i capricci della misurazione del rischio tendono a indurre le persone a * sottovalutarlo * frequentemente, piuttosto che sopravvalutarlo. E sottovalutare il rischio può essere estremamente pericoloso, mentre sovrastimarlo un po 'è semplicemente inefficace.
@halfinformed È possibile quantificare l'impatto di un certo livello di impatti soft, come il rischio reputazionale. Ciò che è impossibile quantificare, che ho già affermato nella mia risposta, è la probabilità che si verifichi un certo livello di rischio reputazionale a seguito di un qualsiasi incidente di sicurezza. Sembra che tu abbia equiparato "impatto" a "rischio" nel tuo commento.
@Schroeder Ebbene, dal mio punto di vista ciò che differenzia un "rischio" da un "impatto" può essere una cosa ambigua, a seconda del contesto circostante. Un po 'come determinare se una certa cosa costituisce un "mezzo" o un "fine". Potresti dire "Beh, il rischio è un evento contingente". Ma molti "impatti" comportano anche situazioni di incertezza. Ad esempio, se dico "Se non guardo la mia dieta il mio peso potrebbe aumentare. Se il mio peso aumenta potrei avere un attacco di cuore. Se ho un attacco di cuore, potrei morire". avere un attacco di cuore è un "rischio" o un "impatto"? O entrambi?
Ad ogni modo, suppongo che stessi usando la parola "rischio" sopra in un senso colloquiale coprendo sia quelli che potrebbero essere chiamati "rischi" e "impatti" in senso accademico. Quello che stavo cercando di trasmettere era che le persone tendono a sottovalutare o ignorare completamente le possibilità negative che sono difficili o impossibili da quantificare con precisione con un valore monetario. Il che, a sua volta, tende a portare le organizzazioni a sottovalutare sistematicamente le risorse che è opportuno destinare alla sicurezza informatica come riduzione del rischio (nel senso ampio del termine).
Esistono best practice per la sicurezza perché la stragrande maggioranza delle persone impiegate in ruoli di sicurezza non dispone degli strumenti necessari per valutare il rischio. Viviamo nell'era dell'informazione, dove la più grande risorsa e responsabilità di un'azienda tende ad essere le informazioni che possiede.
@Aron Questa è un'affermazione interessante. Hai qualche sostanza per sostenerlo?
@schroeder Sto seguendo la vecchia statistica secondo cui la maggior parte delle aziende non riesce a recuperare da una violazione dei dati (e fallisce entro x mesi). Ma ulteriori ricerche sembrano indicare che la fonte originale di questa statistica spesso citata l'ha inventata sul posto ....> _ <
@Aron la valutazione del rischio prima di un incidente e il mancato recupero da un incidente sono due cose molto, molto diverse. Il PO chiede di valutare il rischio di un'attività prima ancora che arrivi al punto di un incidente.
Steffen Ullrich
2015-12-11 18:09:13 UTC
view on stackexchange narkive permalink

Le migliori pratiche non sono leggi ma raccomandazioni. Di solito vengono forniti con una spiegazione del motivo per cui sono consigliati. Se ritieni che la spiegazione non si applichi al tuo caso, sei libero di ignorare la raccomandazione. Potresti anche avere ragione con questa sensazione e quindi puoi risparmiare sui costi.

Ma tieni presente 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 tu sia 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 che ignorarle.

Accetto il tuo consiglio di non applicare una migliore pratica se non ha senso per me, ma non sono d'accordo su due cose: 1) Nella mia esperienza le migliori pratiche di solito vengono senza la spiegazione del perché è importante ... se è solo accettata. 2) Non credo sia più facile seguire le raccomandazioni che ignorarle ... è più facile ignorarle ... soprattutto se devi combattere contro altri reparti per attuare qualche misura di sicurezza non correttamente giustificata.
@EloyRoldánParedes: dipende molto dal tuo ambiente di lavoro (ad esempio industria o piccola azienda) e chi è responsabile se qualcosa va male. Se puoi trasferire la responsabilità a qualcun altro, potrebbe essere più facile ignorare la raccomandazione.
@EloyRoldánParedes - Alcuni settori * richiedono * determinate cose (HIPPA per l'assistenza sanitaria, PCI per le carte di credito, ecc.). Spesso, c'è un certo margine di manovra nei requisiti, in cui puoi scegliere di non fare qualcosa, ma solo se documenti il ​​motivo per cui non lo sei e come non rappresenta un rischio.
Jozef Woods
2015-12-11 22:11:52 UTC
view on stackexchange narkive permalink

Ci sono una serie di fattori da considerare qui:

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

  2. qual è il rischio che accada una brutta cosa? Le possibilità sono piuttosto basse, ma l'impatto è moderato (vengono menzionati i keylogger, ci sono una serie di altri problemi con qualcuno che esegue il proprio codice sul tuo sistema, vale a dire che non è più il tuo sistema). Il rischio effettivo è medio-basso.

  3. Qual è l'impatto dell'implementazione? Esistono motivi legittimi per cui l'utente medio accede 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 medio-basso . Direi che è un buon argomento per implementarlo, personalmente.

C'è un quarto fattore rilevante: qual è l '* efficacia * dell'attuazione? Se l'implementazione della misura elimina completamente e perfettamente il rischio valutato al punto 2, allora è una situazione molto diversa da valutare rispetto a se l'implementazione della misura elimina solo una piccola quantità dalla gravità o dalla probabilità di quel rischio, e la prima può giustificare un costo (punto 1) e impatto (punto 3) molto più elevati rispetto a quest'ultimo. Metterei l'esempio fornito di password del BIOS da qualche parte nel mezzo di quella scala, forse un po 'più vicino a quest'ultimo rispetto al primo estremo.
kasperd
2015-12-12 00:20:48 UTC
view on stackexchange narkive permalink

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

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

In molti casi è necessario uno sforzo minore per risolvere il problema di sicurezza che per valutare il rischio con sufficiente accuratezza per prendere una decisione informata sull'opportunità di affrontare la vulnerabilità della sicurezza. Per me questo è l'argomento principale per affrontare anche le vulnerabilità di sicurezza a rischio molto basso, perché significa risparmiare la maggior parte dei costi associati alla valutazione del rischio.

Chi può sempre dire la differenza tra un problema di sicurezza noto essere a basso rischio e uno a basso rischio?

A volte è più produttivo valutare i problemi di sicurezza l'uno contro l'altro piuttosto che valutare ogni singolo problema di sicurezza rispetto a una soglia di rischio basso.

Nel tuo esempio specifico potresti confrontare il rischio di modifiche dannose delle impostazioni del BIOS con il rischio che la connessione di rete sul dispositivo venga disturbata con un dispositivo MITM.

"In realtà raramente si conosce il rischio esatto. Spesso i potenziali problemi di sicurezza vengono liquidati come un rischio molto basso senza alcun tentativo di valutazione effettiva del rischio." Darei +1000 se potessi. In effetti, l'intero concetto di creare un margine di sicurezza quando si ha a che fare con i sistemi - se la sicurezza di una rete contro un aggressore locale, la resistenza di un edificio al terremoto, ecc. - si basa sulla costruzione in un certo grado di protezione prudente contro il rischio che, beh, la tua valutazione del rischio stessa sia in qualche modo spenta.
m2kin2
2015-12-11 20:03:24 UTC
view on stackexchange narkive permalink

La postura che adotti si basa 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 minaccia che hai in mente. Senza una valutazione del valore in dollari che stai proteggendo, trascorrerai una quantità esorbitante di tempo per capire dove sono i buchi. D'altra parte, gli elementi criminali utilizzano elementi di protezione bassi o nulli per cercare obiettivi di valore più elevato.

Inoltre, tieni presente che i fornitori che pretendono di aiutare a mitigare il rischio non vengono con il proiettile d'argento per risolvere ogni singolo problema . In definitiva, tu e l'azienda siete gli unici responsabili della sicurezza. Da un punto di vista aziendale, potresti trasferire i costi di errori / difetti di sicurezza, ma a lungo termine potrebbe non essere d'aiuto. Al momento è un mondo piuttosto canuto là fuori.

TTT
2015-12-11 22:40:38 UTC
view on stackexchange narkive permalink

A volte, le migliori pratiche di sicurezza ti proteggono da rischi molto improbabili. In questi scenari, come difendi l'implementazione di queste misure di sicurezza?

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

  1. Probabilità che si verifichi l'attacco X = P.
  2. Costo totale di X se si verifica = TC. (Ciò deve includere la diagnosi e la risoluzione della violazione, la perdita di entrate, la reputazione, le azioni 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 . Ovviamente, la parte difficile è calcolare P e TC per cominciare, ma potresti scoprire di poter essere eccessivamente prudente su TC ed eccessivamente ottimista su P e sarà comunque un investimento utile. Inoltre si ottiene anche l'ulteriore vantaggio di rendere pubbliche le misure di sicurezza agli investitori e / o ai clienti.

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

Mi dispiace ma riuscire a calcolare una probabilità scientifica di un attacco mi sembra una falsità. Ad esempio, guardare negli eventi passati molto di solito porta a una probabilità di 0 e questo non è reale. Altra possibilità è "inventare" la probabilità o eseguire un "calcolo approssimativo" ... anche IMHO non molto scientifico. So che questo è lo standard nelle metodologie di rischio, ma non sono d'accordo su questo approccio. Se siamo d'accordo che abbiamo bisogno di una metrica per misurare, mi piace di più il calcolo del RAV da OSSTMM.
@EloyRoldánParedes - Solo perché non conosciamo un metodo * buono * per calcolare la probabilità non significa che non sia possibile farlo. E se la probabilità si avvicina davvero a 0, forse non dovresti preoccupartene a meno che non sia relativamente facile mitigarla. Questo è fondamentalmente il punto dell'equazione. Ad esempio, il proprietario di Ashley Madison una volta ha affermato che il valore della sua azienda era di $ 1 miliardo. Probabilmente il costo della violazione potrebbe essere il valore dell'intera azienda. Se quella violazione avesse un P di 1 su 1.000, il costo per aggiungere una maggiore sicurezza doveva essere inferiore a $ 1 milione - avrei dovuto farlo ...
Un altro modo di vederlo è questo: se C / TC
Shaz
2015-12-11 22:58:01 UTC
view on stackexchange narkive permalink

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

Penso che qui ci sia un leggero miscuglio in ciò che intendiamo per "rischio". Stai guardando i rischi dal punto di vista del sistema informatico (password del BIOS, installazione di AV, utilizzo di un firewall, ecc.). La prospettiva di cui parla Schroeder è dal punto di vista aziendale: una volta che la macchina è stata compromessa, qual è il costo associato?

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

  • Accetta il rischio - si assume non accadrà nulla di male e, in tal caso, non sarà un grosso problema da affrontare.

  • Evitare i rischi: evitare del tutto l'esposizione al rischio.

  • Limitazione del rischio (mitigazione): riduce 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 nel thread:

  1. Il rischio che ha un'azienda se un particolare sistema dovesse essere compromesso. Ciò può includere informazioni finanziarie del cliente (numeri di carta di credito, ecc.), Nonché informazioni proprietarie, segreti commerciali, informazioni classificate, ecc.

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

Ecco la sfumatura che sto ottenendo: # 1 è il rischio aziendale. La strategia per affrontare questo rischio è in genere attraverso la limitazione del rischio (mitigazione) . È qui che entra in gioco il n. 2. Il n. 2 attenua la probabilità che il n. 1 si verifichi. Consideriamo molti metodi diversi in cui un computer può essere compromesso in # 2 e implementiamo misure preventive per mitigare # 1 il più possibile. Dal momento che molte "best practice" sono economiche o prive di cervello (ovvero il loro costo è facilmente giustificabile), ha senso seguirle anche se su base individuale il loro vettore di attacco è altamente improbabile.

A volte il rischio aziendale non è molto chiaro per i dispositivi che non archiviano dati aziendali o eseguono funzioni critiche per l'azienda, ma sono una prima porta per un'infrastruttura protetta con altre misure di sicurezza. In questo scenario suppongo che sia meglio non implementare le migliori pratiche ma sono preoccupato di non implementare un basso numero di best practice non importanti e quindi avere un rischio accumulato molto alto.
@EloyRoldánParedes Il problema è che devi essenzialmente trattare tutti i tuoi sistemi allo stesso modo. Puoi provare a giustificare pratiche di sicurezza inferiori sul computer di Jim poiché lavora in fabbrica e lo utilizza solo per la posta elettronica, ma un hacker vedrà un computer con un profilo di sicurezza inferiore come obiettivo principale. Hackereranno il computer di Jim e lo useranno come punto di lancio verso i tuoi server, informazioni finanziarie, ecc.
Robert Mennell
2015-12-18 06:29:39 UTC
view on stackexchange narkive permalink

Per quanto riguarda il tuo esempio:

Tutti gli accessi a un sistema / rete / foresta / cosa che contiene dati protetti, devono essere mantenuti protetti da un'estremità all'altra, non importa quanto piccola sia la fine è.

Per quanto riguarda la sicurezza in general:

Tutti gli accessi a un sistema / rete / foresta / cosa che contiene i dati protetti devono essere mantenuti al sicuro.

Perché?

C'è una ragione per questo. Un unico punto di accesso a una rete che contiene dati protetti necessita di sicurezza. Le informazioni su ciò che è accaduto nel sistema nel suo complesso devono essere sicure per mantenere i dati protetti fino alla più piccola parte al sicuro. Se un singolo collegamento nella catena si interrompe, la catena viene interrotta.

Ma come interrompo quella catena se non ci sono informazioni di sicurezza sul client? Semplice, osservando il Rete. Se riesco a vedere cosa succede nella rete, posso sapere quali chiavi mi faranno passare 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é, dall'inizio alla fine, TUTTE le attività devono essere mantenute al sicuro.

Andiamo all'esempio del prenderti a pugni in faccia:

  1. Tu pensa che la tua casa sia sicura.
  2. Hai scanner biometrici di impronte digitali (COME SULLA TV) che significa che solo le dita ti fanno entrare
  3. Tocchi la maniglia di una porta sulla facciata di un negozio 70 milioni di miglia di distanza, sei anni fa
  4. Sollevo quella stampa
  5. Identifico la tua stampa (attraverso un lungo processo)
  6. Uso quella stampa per aprire casa tua mentre dormi
  7. Ti do un pugno in faccia

Anche se era a chilometri di distanza, e quella stampa aveva molte altre impronte, e così via e avanti , Alla fine potrei ancora trovare la tua stampa lì e usarla per aprire la tua casa. Questo è molto improbabile, ma se lo voglio DAVVERO, posso ancora prenderti a pugni in faccia con tempo, impegno e un po 'di pazienza.

Tuttavia, questo non fa più del presente un esempio. Affermiamo invece la verità sulla sicurezza:

Il sistema più sicuro al mondo in sotterraneo, in un luogo sconosciuto, bruciato e distrutto.

Certo che è un po 'ironico, ma rende l'idea. Quindi sì, questa best practice per la sicurezza dovrebbe essere ancora utilizzata. Dopo tutto il tuo sistema non è il più sicuro al mondo, quindi dovresti provare ad avvicinarti.

Serge Ballesta
2015-12-12 17:36:48 UTC
view on stackexchange narkive permalink

Come è già stato detto, la sicurezza è principalmente un approccio rischio vs costo.

Ma IMHO, c'è un altro punto da considerare: come nella sicurezza degli edifici, una porta blindata è poco utile se la finestra è lasciato aperto. Per valutare correttamente un rischio è necessario sapere da cosa proteggersi. Quindi proteggere il 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é potrebbe succedere qualcosa: un key logger fisico nella tastiera stessa, un analizzatore di rete tra il connettore interno e il connettore esterno, un dispositivo USB dannoso all'interno della confezione , ecc.

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



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...