Il problema con la situazione (come la stai segnalando) è che ci sono molte ipotesi fatte con molte opinioni. Hai le tue opinioni e vuoi che condividano le tue opinioni, ma hanno le loro opinioni.

Se vuoi che tutti siano d'accordo su qualcosa, devi trovare un terreno comune. Devi sfidare e confermare ogni assunto e trovare dati concreti per supportare la tua opinione o la loro. Una volta che hai un terreno comune, puoi andare avanti tutti insieme.

1. Hai la whitelist: fantastico, cosa significa? Ci sono modi per aggirarlo? Un'applicazione inserita nella whitelist può essere danneggiata?
2. Cosa fa il firewall? Come si configura? I firewall indicano porte bloccate, ma significano anche porte consentite . È possibile abusare di quelle porte consentite?
3. Nessuno ha accesso? Chi ha accesso al dispositivo? Ti fidi di un insider o dell'ignoranza di un utente per mantenerlo al sicuro?
4. Cosa succede se qualcuno ottiene l'accesso locale al dispositivo? Quanto è probabile?

In qualità di professionista della sicurezza delle informazioni, il tuo lavoro non è picchiare le persone in testa con "best practice", ma eseguire analisi dei rischi e progettare una via da seguire che limiti il ​​rischio sotto la soglia di rischio in modo conveniente. Devi giustificare non l'utilizzo di best practice, ma se la giustificazione è valida, allora è valida.

Se qualcuno mi dice che la sua macchina non è hackerabile e dovrei credergli, concludo immediatamente che

• La macchina è custodita in condizioni di Fort Knox / prigione di alta sicurezza, con 24 / 7 guardie e telecamere di sicurezza,

e anche uno dei seguenti:

• La macchina non ha scambio di informazioni di alcun tipo (no usb, ethernet, firewire, seriale, parallela, ecc. di qualsiasi tipo)

• La macchina è permanentemente spenta.

Perché desideri una strategia di sicurezza multilivello con una difesa approfondita. Hai un firewall, ma cosa succede se c'è una vulnerabilità di sicurezza nel tuo firewall? Cosa succede se qualche exploit dell'applicazione fornisce l'accesso al sistema operativo a livello di utente e quindi una vulnerabilità del sistema operativo senza patch consente l'escalation all'accesso root? Per una sicurezza adeguata è necessario patchare tutte le vulnerabilità note, non solo quelle che ritieni possano essere sfruttate sul tuo sistema, perché una combinazione di una vulnerabilità sconosciuta e una vulnerabilità nota che ritieni non possa essere sfruttato può consentire la compromissione laddove uno dei due da solo non lo consentirebbe e non è possibile correggere le vulnerabilità sconosciute.

Il motivo è semplice, la sicurezza viene applicata a strati. Ad esempio, per connettersi a un database importante, è necessario prima entrare nella rete del database (passare firewall), aggiungere il proprio indirizzo IP all'elenco dei client autorizzati a connettersi, quindi avviare la connessione con nome utente e password. Uno qualsiasi degli strati rende gli altri due ridondanti. Il problema è "cosa succede se". Pensiamo al login scott / tiger predefinito del vecchio Oracle o ad un dipendente che inavvertitamente inoltra una porta a Internet pubblico. Il firewall potrebbe bloccare solo TCP, mentre il server è in ascolto anche su UDP o IPv6 è configurato in modo errato e la sicurezza si applica solo per IP4. Questo è il motivo per cui una buona sicurezza arriva a strati, i tentativi vengono monitorati e gli esperti di sicurezza imparano dai tentativi (si spera falliti) di attacchi o ispezionano l'attività sugli honeypot. Inoltre, gli exploit zero day (quelli che si applicano anche alla patch più recente) hanno meno probabilità di avere successo in un ambiente a più livelli, poiché l'attaccante avrà bisogno di un exploit per ogni livello.

Nessun dispositivo non è hackerabile, basta non è mai stato violato prima. O ci sono pochi interessi sul tuo dispositivo e / o il guadagno è molto basso. Potrebbero ancora esistere exploit zero day.

Inoltre, alcuni dispositivi Android semplicemente non possono essere aggiornati oltre una versione specifica. Sapere che un avversario ha un tale dispositivo è un invito aperto all'hacking, poiché il nome / marca del dispositivo riporta la ricetta esatta di come hackerarlo.

Mantenere un dispositivo senza supporto attivo è pericoloso anche dal punto di vista funzionale prospettiva.

La sicurezza non è necessaria per proteggere da estranei (firewall) ma anche da addetti ai lavori. Non conosco il contesto in cui è in esecuzione il tuo dispositivo, ma dato quello che scrivi, potrebbe essere vulnerabile a qualcuno già all'interno del firewall.

Non esistono sistemi non bloccabili. Per coloro che menzionano l'airgapping, ci sono molti esempi di hack effettivi o potenziali hack su sistemi airgapping. Stuxnet è probabilmente l'esempio più famoso (e più estremo). Alcuni altri includono il phreaking di Van Eck, l'analisi acustica o altri attacchi ai canali laterali.

Esistono modi per mitigare le vulnerabilità che non implicano l'applicazione di patch. Ad esempio, se il sistema è vulnerabile a KRACK è possibile disabilitare semplicemente il WiFi? Se il WiFi è permanentemente disabilitato, non dovrebbe essere necessario applicare alcun aggiornamento che coinvolga il WiFi. Allo stesso modo, se sul sistema sono presenti applicazioni specifiche che rappresentano una vulnerabilità (come Java, .NET, Flash, browser, ecc.), È possibile disinstallare semplicemente tali applicazioni. Non è necessario aggiornare Java se non è nemmeno installato.

Con gli aggiornamenti del sistema operativo questo è certamente più difficile. Devi essere consapevole delle potenziali vulnerabilità, quindi devi mitigarle. Il vantaggio di utilizzare un sistema operativo supportato è che qualcun altro sta (presumibilmente) già facendo la prima parte e metà della seconda parte per te.

Un sistema completamente aggiornato / aggiornato non è un sistema sicuro o non bloccabile. Ma tende a minimizzare il rischio di vulnerabilità NOTI. Per riprendere Schroeder, l'analisi del rischio è più importante di "rafforzare / bloccare" o "aggiornare" ciecamente e sperare che entrambi ti rendano più sicuro.

Nessun sistema è veramente "inattaccabile". Tuttavia, una volta che abbiamo deciso che un sistema è abbastanza "unhackable", non dobbiamo mantenere un canale per le patch di sicurezza.

Per un esempio concreto, il nostro sistema "unhackable" controlla una telecamera di sicurezza. Il compito della telecamera è guardare una posizione fissa. Ogni impostazione è costante o il sistema è abbastanza intelligente da adattarsi da solo. Il sistema trasmette dati video e non necessita di input da parte dell'utente.

Potremmo fare in modo che il sistema esegua ssh in modo da poter accedere periodicamente e applicare patch di sicurezza, ma in realtà si apre un (molto piccolo) buco di sicurezza. Un utente malintenzionato potrebbe utilizzare ssh per hackerare la telecamera. (Buona fortuna per l'hacking di ssh).

Quindi è un compromesso. Se credi onestamente che non avrai mai bisogno di applicare una patch di sicurezza, potresti decidere che non vale la pena lasciare quel canale aperto.

Ho avuto questa idea da una presentazione a cui ho partecipato in cui qualcuno ha descritto i sistemi che hanno stavano costruendo per il governo. I componenti del sistema erano macchine virtuali di breve durata (di solito meno di un giorno). Ogni macchina virtuale era immutabile e usa e getta. Il piano era che se avessero avuto bisogno di applicare una patch di sicurezza avrebbero semplicemente smaltito le macchine in modo ordinato e ne avrebbero create di nuove. Le macchine virtuali non avevano ssh.

Il revisore della sicurezza del governo ha fatto saltare una guarnizione e ha fatto loro installare ssh in modo che potessero applicare le patch di sicurezza. Il server ssh non forniva alcun valore di sicurezza ed era in effetti un buco.

Tuttavia, a pensarci bene, questo (e la mia telecamera) esempio sono solo aggiornamenti di sicurezza attraverso un canale non tradizionale.

Che ne dici di

1. una telecamera schierata su Marte ... tutti conoscono la telecamera e tutti possono visualizzare i dati della telecamera
2. una telecamera che esiste segretamente dietro le linee nemiche (se il nemico fosse a conoscenza della videocamera, potrebbe prenderla facilmente ... vogliamo mantenere un canale per gli aggiornamenti di sicurezza).

Il fatto che non riescano a pensare (in questo momento) a un modo per hackerarlo, non significa che sia "unhackable". Questo è il motivo per cui, in linea di principio, applichiamo tutte le patch di sicurezza, anche se si trovano su un componente che non dovrebbe essere accessibile (ad es. Perché applicare una patch a una vulnerabilità di escalation dei privilegi se un utente malintenzionato non avrebbe nemmeno accesso utente?).

Ora, potrebbero avere ragione, e non correggere potrebbe effettivamente essere la decisione giusta nel tuo caso. Ma ci sono poche persone per le quali lo accetterei completamente. E questi ingegneri probabilmente non sono particolarmente esperti in eseguire controlli di sicurezza.

Come argomento per convincerli, chiederei loro di fornire l'accesso a uno di questi dispositivi a chiunque sia interessato a una taglia succosa (ad es. scommettono sulla casa?).

Se non si sentono a proprio agio a farlo, beh, allora in realtà non pensano che sia inattaccabile. E se pensano che così facendo rivelerebbero informazioni importanti, significa che fanno affidamento sulla sicurezza per oscurità. Un vero sistema unhackable sarebbe comunque hackerabile se l'attaccante sapesse tutto sul suo funzionamento.

PS: anche se non finiscono per scommettere le loro case, trarresti davvero vantaggio dall'implementazione di un programma di bug bounty.

gli ingegneri che hanno progettato il prodotto originale ritengono che la macchina non sia hackerabile

Gli ingegneri che hanno progettato il Titanic hanno ritenuto che fosse inaffondabile.

Il problema nell'IT è che le persone non vedono la necessità di aggiornare un sistema, perché cambiare un sistema funzionante? Queste aziende fanno quindi i titoli dei giornali: "4 fabbriche sono state chiuse a causa dell'epidemia x" o "La società x è stata violata, i dettagli personali di y milioni di clienti esposti".

Immagina, il cloud di IBM ha recentemente spostato tutto clienti con forza a TLS 1.1 (SI, la versione già obsoleta) e alcuni clienti si sono lamentati ... QUESTI CLIENTI DEVONO PREPARARSI PER TLS 1.3, non so cosa stanno facendo e non mi interessa quali sono le loro scuse, dovrebbero eseguire TLS 1.2 OVUNQUE! IBM è tornato a spacciare, INACCETTABILE!

Ora puoi dirmi che l'unicorno nero nella stalla ti impedisce di spostare tutto su TLS 1.2, qualunque cosa, smaltirlo e non fare affari con la società che vende il unicorno nero ... Noi come industria non lo facciamo e le violazioni fanno notizia, le violazioni continueranno a fare notizia finché non impareremo la lezione.

ritiene che la macchina non sia hackerabile

I sentimenti non contano. I fatti sì.

Torna alla tua valutazione del rischio e / o al modello di minaccia. Verifica se applicare patch o mantenere aggiornato il software faceva parte del tuo piano di trattamento del rischio. Verifica se il software obsoleto faceva parte della tua analisi dei rischi o del tuo modello di minaccia.

Torna dagli ingegneri con questi fatti e discuti con loro come cambia il rischio o quali minacce non sono state trattate in base al fatto che il software non è più obsoleto. Considera inoltre che questo rischio particolare aumenterà nel tempo man mano che aumenteranno le possibilità che un difetto sfruttabile venga scoperto. Quindi guarda avanti fino al termine ragionevole del tuo prodotto.

Tieni presente che le loro azioni di mitigazione potrebbero rendere accettabile il rischio. Ma questo deve essere discusso e il piano dei rischi aggiornato. Potrebbe anche essere che renda il rischio accettabile oggi, ma tra qualche anno non più. E allora? Invece di cercare argomenti contro gli ingegneri, mettiti sulla stessa pagina con loro. Almeno i tuoi si rendono conto che potrebbero essere necessarie azioni di mitigazione.

"Il sistema non è bloccabile, quindi perché correggere le vulnerabilità?" Nella tua domanda, stai cercando di argomentare contro un errore e un argomento non dimostrabile ("Come fai a sapere che è 'inattaccabile'? O pensi solo che dal momento che non puoi hackerarlo, nessun altro può? "). Alla fine, tuttavia, penso che si tratterà di una discussione sull'accettabilità del rischio e su chi è disposto ad accettare tale rischio. Prova a spiegarglielo in questo modo

"Abbiamo una lista bianca delle applicazioni, quindi perché dobbiamo correggere le vulnerabilità?"

La lista bianca delle applicazioni è solo come buono come la whitelist stessa, gli strumenti per bloccare le app non presenti in quella whitelist e presume che non ci siano errori o vulnerabilità nello stesso strumento di whitelist delle applicazioni. Inoltre protegge solo da applicazioni sconosciute / non attendibili. E se l'aggressore decidesse di "vivere della terra" e utilizzare i propri strumenti contro se stesso? Che cosa succede se una delle applicazioni che hai inserito nella whitelist come parte del sistema operativo ha una vulnerabilità

"Abbiamo un firewall, quindi perché dobbiamo correggere le vulnerabilità?" Questo è, effettivamente, lo stesso argomento del precedente. Sei certo, assolutamente, positivamente, al 100%, oltre un pizzico di dubbio certo che non ci siano vulnerabilità nello stack di rete e / o nel firewall stesso né in nessuna delle applicazioni o servizi che potrebbero essere in ascolto o accessibili tramite quello stack di rete?

Se le loro risposte a quanto sopra sono che sono positive al 100% riguardo alle loro scelte e decisioni, allora scriverei un documento che descriva in dettaglio la loro accettazione di tale rischio e lo farei firmare dal loro team di leadership fino al il CIO. In definitiva è il loro (il livello CxO) che è sul gancio per la questione se e quando il sistema viene violato e sono quelli che potrebbero essere chiamati prima del Congresso (o di qualsiasi ente di controllo governativo a cui sono soggetti) come i dirigenti a Equifax erano. Quando viene spiegato ai dirigenti che non stanno facendo tutto ciò che è in loro potere per mantenere un sistema aggiornato e corretto (come richiesto da molti diversi gruppi / leggi di credenziali e supervisione) e che loro (il CxO) potrebbero essere ritenuti responsabili, atteggiamenti spesso cambierà.

Mi sembra semplice. Tornando alla domanda su come ottenere un punto in discussione contro la mancata patch di un sistema ritenuto inattaccabile. Qual è lo scenario peggiore che può accadere se quel sistema viene violato? Supponiamo che tutte le protezioni in atto falliscano o siano allo stesso modo violate. Non influenzare questo esercizio escludendo le conseguenze perché non pensi che possa o sarà violato.

Ora, inserisci lo scenario peggiore in termini di costo dell'impatto sul business sotto forma di mancati guadagni, sanzioni legali / normative o danni all'immagine dell'azienda nel settore.

Se l'impatto è grave, guarda i tuoi ingegneri negli occhi e dì "sei disposto a mettere il tuo lavoro - e forse l'intera carriera - in prima linea che questo non accadrà mai? Perché se lo fa, dopo aver spiegato come è successo, la decisione consapevole di continuare a utilizzare e il sistema operativo EOL e ritenere che l'applicazione di patch non sia necessaria sarà vicino, se non in cima, alla lista. "

D'altra parte, se l'impatto sul business non è così impattante, potrebbe avere senso continuare a utilizzare un sistema operativo EOL. Ma come farlo al meglio in un modo ben gestito dal rischio è un altro intero argomento.

Questa potrebbe non essere affatto una decisione tecnica. L'uso di qualsiasi componente di origine esterna in genere significa che devi utilizzare quel componente rigorosamente in conformità con le linee guida del produttore, o rischi di rimanere bloccato con tutte le conseguenze e le responsabilità derivanti da qualsiasi guasto in cui potrebbe essere implicato.

Quindi, se il dispositivo si comporta in modo anomalo e qualcuno si ferisce (o si incorre in qualche altra responsabilità), il produttore del sistema operativo originale dirà "software non supportato - non è il nostro problema". E l'assicuratore della tua azienda dirà "l'utilizzo di software antiquato fuori supporto - è negligente e quindi non è un nostro problema".

Quindi, dal tuo punto di vista personale, assicurati che coloro che prendono la decisione affermativa continuino a utilizzare componenti obsoleti e non supportati:

• è stato dimostrato che lo stanno facendo (e lo hai scritto per iscritto)
• hanno affermato in modo affermativo che l'aggiornamento non è necessario ( e lo hanno fatto per iscritto)

C'è un grande divario tra le persone che dicono "non abbiamo bisogno di fare questo aggiornamento" e "Accetto personalmente la responsabilità di non fare questo aggiornamento" .

In pratica, ci sono spesso aggiornamenti a componenti che sono obbligatori per essere passati a EOL, anche se non ci sono reali esigenze tecniche per farlo. Questa è una parte necessaria della progettazione di un prodotto complesso.

Se il tuo dispositivo ha una connessione Wi-Fi, allora può essere attaccato attraverso la rete. Quell'attacco avrà successo? È una questione di vantaggi di attaccare il dispositivo, rispetto al livello di sforzo richiesto. Basarlo su un sistema operativo obsoleto e non supportato semplifica decisamente il metodo di attacco.

La whitelist delle applicazioni non è una protezione, ma solo un piccolo ostacolo. Pensi che un hacker non possa sviluppare un'app che si maschera da una nella whitelist delle app? Certo che possono ... qualcosa che potrebbero esaminare se il loro primo tentativo non viene eseguito.

Equifax disponeva di un bel firewall. Non ha impedito agli hacker di sfruttare il buco di Struts che i responsabili IT di Equifax non sono riusciti a riparare, attraverso una porta che è stata lasciata aperta per necessità. Un firewall blocca solo alcuni degli attacchi più vecchi e ovvi.

Ripensa all'hacking di Target: il CEO e il CIO hanno perso il lavoro a causa di quello, ed è stato perpetrato da un addetto ai lavori, aiutato dall'uso di Target di una versione precedente di Windows, non più aggiornata e più vecchia , metodi di connettività non sicuri sui dispositivi dei punti vendita. Senza dubbio, il CIO ha concluso che l'aggiornamento della versione Win sui propri dispositivi POS era troppo costoso, un giudizio che si è dimostrato molto sbagliato.

Pensi che il firmware incorporato sia immune dall'hacking? Considera l'hack della stampante HP. HP ha avuto l'intelligente idea di aggiornare il firmware della stampante tramite un lavoro di stampa, facile da avviare. Fino a quando ... qualcuno ha inventato una versione del firmware che ha trasformato la stampante in uno spam relayer e l'ha consegnata tramite un processo di stampa malware.

Come vengono eseguiti gli aggiornamenti del firmware? Tramite wi-fi? Sì, un hacker può replicarlo ... se ha una ragione sufficiente.

Un dispositivo in rete può essere hackerato per diventare parte di una botnet ... un modo comune per lanciare un attacco DOS. Un hacker potrebbe scoprire la vulnerabilità e, sapendo che danneggerebbe la reputazione dell'azienda, lanciare l'attacco nello stesso momento in cui sta mettendo in corto le azioni della tua azienda. È successo ... Rubare informazioni PII e CC non è l'unico modo per trarre profitto da un hack.

Ora, chiediti: qual è il rischio per te personalmente? Se il tuo sistema dovesse essere violato, puoi dimostrare ai dirigenti della tua azienda che hai esercitato la dovuta diligenza nell'identificare e mitigare potenziali minacce, soprattutto perché stai basando il sistema su un sistema operativo che non viene più aggiornato? Suggerimento: prendere la parola degli ingegneri che affermano che il sistema è "inattaccabile" probabilmente non si qualifica come due diligence.

Del resto, se i tuoi ingegneri dicono che è inattaccabile, probabilmente non stanno nemmeno cercando potenziali vulnerabilità, per non parlare di mitigarle.

Chiunque dica che un sistema è inattaccabile semplicemente non è realistico. Non in questo giorno ed età.

A seconda delle risorse a tua disposizione, il modo "infallibile" (con tutto il rispetto per i tuoi colleghi) sarebbe dimostrare loro che il sistema è hackerabile. Assumi qualcuno che può e lascia che dimostri le debolezze del sistema. La mia ipotesi è che con WLAN non dovrebbe essere terribilmente difficile. WLAN e firewall? Questa è una contraddictio in adjecto .

Ripensamento: forse è possibile concordare il pagamento in caso di successo (il mio dizionario lo chiama "tassa di emergenza"); in questo modo il servizio (di hacking) varrebbe sempre i soldi.

Ogni giorno abbiamo titoli che dicono che un sistema è stato violato. Non è perché non siano né aggiornati né non protetti con le mitragliatrici, ma perché qualcuno sta investendo tempo per hackerarli.

Soprattutto, quelli che sono ben suonati non sono fatti dal potere del QI ma dalla semplice ingegneria sociale. Quindi ci viene detto di mantenere il sistema aggiornato perché se in qualche modo cadiamo in quella fossa, diamo le informazioni che non li aiutano.