Come posso obiettare: "Il sistema non è accessibile, quindi perché le vulnerabilità delle patch?"

Il problema con la situazione (come lo 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 far accettare a tutti qualcosa, devi trovare un terreno comune. Devi sfidare e confermare ogni ipotesi e trovare dati complessi per supportare la tua opinione o la loro. Una volta che hai un terreno comune, puoi andare avanti insieme.

1. Hai whitelist: fantastico, cosa significa? Ci sono modi per aggirarlo? È possibile che un'applicazione autorizzata sia danneggiata?
2. Che cosa fa il firewall? Come è configurato? I firewall significano porte bloccate, ma significano anche porte permesse . È possibile abusare di quelle porte autorizzate?
3. Nessuno ha accesso? Chi ha accesso al dispositivo? Ti stai fidando di un insider o dell'ignoranza di un utente per tenerlo al sicuro?
4. Che cosa succede se qualcuno ottiene l'accesso locale al dispositivo? Quanto è probabile?

Come professionista della sicurezza delle informazioni, il tuo compito non è quello di sconfiggere le persone con le "migliori pratiche" ma di eseguire analisi dei rischi e progettare una soluzione che limiti il rischio sotto la soglia di rischio in modo economicamente vantaggioso. Devi giustificare non utilizzando le migliori pratiche, ma se la giustificazione è valida, allora è valida.

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

• La macchina è tenuta sotto la sorveglianza di Fort Knox / Alta sicurezza, con guardie 24/7 e telecamere di sicurezza,

e anche uno dei seguenti:

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

• La macchina è disattivata in modo permanente.

Perché vuoi una strategia di sicurezza a più livelli con difesa in profondità. Hai un firewall, ma cosa succede se c'è una vulnerabilità di sicurezza nel tuo firewall? Cosa succede se qualche exploit dell'applicazione offre accesso al sistema operativo a livello utente e quindi una vulnerabilità del sistema operativo senza patch consente di eseguire l'escalation dell'accesso root? Per sicurezza adeguata è necessario applicare una patch a tutte le vulnerabilità note di tutte , non solo a quelle che si ritiene possano essere sfruttate sul proprio sistema, poiché una combinazione di una vulnerabilità sconosciuta e una vulnerabilità nota che si ritiene non possa essere sfruttati potrebbero consentire compromessi laddove o meno da soli e non è possibile eseguire patch contro 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 (pass firewall), aggiungere il proprio indirizzo IP all'elenco dei client autorizzati a connettersi e quindi avviare la connessione con nome utente e password. Qualsiasi strato rende gli altri due ridondanti. Il problema è "cosa succede se". Pensiamo al login scott / tiger di default del vecchio Oracle o un dipendente inavvertitamente inoltra una porta alla rete pubblica. 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 a IP4. Questo è il motivo per cui una buona sicurezza arriva a livelli, i tentativi vengono monitorati e gli esperti di sicurezza apprendono dagli attacchi tentati (si spera non riusciti) o controllano l'attività su honeypot. Inoltre, gli exploit zero day (quelli che si applicano anche all'ultima patch) hanno meno probabilità di avere successo in un ambiente a più livelli, dal momento che l'attaccante avrà bisogno di un exploit per ogni livello.

Nessun dispositivo non è hackerabile, solo che non è stato hackerato prima. O ci sono piccoli interessi sul tuo dispositivo e / o il payoff è molto basso. Gli exploit Zero Day possono ancora esistere.

Inoltre, alcuni dispositivi Android semplicemente non possono essere aggiornati oltre una specifica versione. Sapere che un avversario ha un tale dispositivo è un invito aperto per l'hacking, dal momento che il nome / marchio del dispositivo porta la ricetta esatta di come modificarlo.

Il mantenimento di un dispositivo senza supporto attivo è pericoloso anche dal punto di vista funzionale.

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

Non ci sono sistemi sbloccabili. Per quelli che menzionano l'airgapping, ci sono un sacco di esempi di hack effettivi o potenziali hack sui sistemi airgapped. Stuxnet è probabilmente l'esempio più famoso (e più estremo). Alcuni altri includono phreaking di van Eck, analisi acustica o altri attacchi di canali laterali.

Esistono modi per mitigare le vulnerabilità che non coinvolgono le patch. Ad esempio, se il sistema è vulnerabile a KRACK è possibile disabilitare semplicemente il WiFi? Se il Wi-Fi è disattivato in modo permanente, non dovrebbe essere necessario applicare alcun aggiornamento che riguardi il WiFi. Allo stesso modo, se sul sistema sono presenti specifiche applicazioni che presentano una vulnerabilità (come Java, .NET, Flash, Browser, ecc.), È sufficiente disinstallare tali applicazioni. Non è necessario aggiornare Java se non è nemmeno installato.

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

Un sistema completamente aggiornato / aggiornato non è un sistema sicuro o non accessibile. Ma tende a minimizzare il rischio di vulnerabilità KNOWN. Per fare eco a Schroeder, l'analisi del rischio è più importante di "hardening / locking down" o ciecamente "upgrade" e sperando che entrambi ti rendano più sicuro.

Nessun sistema è veramente "inaccessibile". Tuttavia, una volta deciso che un sistema è "inaccessibile", non è necessario mantenere un canale per le patch di sicurezza.

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

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

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

Ho avuto questa idea da una presentazione a cui ho partecipato dove qualcuno ha descritto i sistemi che stavano costruendo per il governo. I componenti del sistema erano macchine virtuali di breve durata (in genere 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 hanno ssh.

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

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

Che dire

1. una fotocamera distribuita su Marte ... tutti sanno della fotocamera e tutti possono visualizzare i dati della videocamera
2. una telecamera che esiste segretamente dietro le linee nemiche (se il nemico fosse a conoscenza della telecamera, potrebbe facilmente prenderla ... 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 "irraggiungibile". Ecco perché, in via di principio, applichiamo tutte le patch di sicurezza, anche se si tratta di un componente che non dovrebbe essere accessibile (ad esempio perché applicare una vulnerabilità di escalation di privilegi se un utente malintenzionato non ha nemmeno l'accesso dell'utente?). p>

Ora potrebbe avere ragione, e non applicarlo correttamente potrebbe essere la decisione giusta nel tuo caso. Ma ci sono poche persone per le quali lo accetterei a titolo definitivo. E questi ingegneri probabilmente non sono particolarmente competenti in eseguire audit di sicurezza.

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

Se sono a disagio nel farlo, beh, in realtà non pensano che sia inaccessibile. E se pensano che fare ciò rivelerebbe informazioni importanti, significa che si affidano alla sicurezza per oscurità. Un sistema reale e inaccessibile sarebbe comunque hackerabile se l'aggressore sapesse tutto sul suo funzionamento.

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

the engineers who designed the original product feel that the machine is not hackable

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 poi i titoli dei giornali: "4 fabbriche sono state chiuse a causa dell'epidemia x" o "La società x è stata violata, i dettagli personali di milioni di clienti esposti".

Immagina, il cloud di IBM ha recentemente spostato tutti i clienti con forza su TLS 1.1 (YES, la versione già obsoleta) e alcuni clienti si sono lamentati ... QUESTI CLIENTI DEVONO ESSERE PREPARATI PER TLS 1.3, non so cosa stanno facendo, e io non importa quali sono le loro scuse, dovrebbero essere in esecuzione TLS 1.2 OVUNQUE! IBM restituito, UNACCEPTABLE!

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

feel that the machine is not hackable

I sentimenti non contano. Fatti fatti.

Torna alla valutazione del rischio e / o al modello di minaccia. Verificare se l'aggiornamento o l'aggiornamento del software facessero parte del piano di trattamento del rischio. Guarda se il software obsoleto faceva parte dell'analisi dei rischi o del modello di minaccia.

Torna dagli ingegneri con questi fatti e discuti con loro su come il rischio cambia o quali minacce non vengono ora trattate in base al fatto che il software non è più obsoleto. Considera anche che questo particolare rischio aumenterà nel tempo in quanto aumenterà la possibilità di scoprire un difetto sfruttabile. Quindi guarda avanti fino alla ragionevole fine vita del tuo prodotto.

Si noti che le loro azioni di mitigazione potrebbero rendere accettabile il rischio. Ma questo deve essere discusso e il piano di rischio aggiornato. Potrebbe anche essere che oggi il rischio sia accettabile, ma in pochi anni non più. Cosa poi? Invece di cercare argomenti contro gli ingegneri, vai sulla stessa pagina con loro. Il tuo almeno comprende che potrebbero essere necessarie azioni di attenuazione.

"Il sistema non è abilitabile, quindi perché le vulnerabilità delle patch?" Nella tua domanda, stai cercando di argomentare contro un errore e un argomento non dimostrabile ("Come sai che è" inaccessibile "? pensi che dal momento che non puoi hackerarlo, nessun altro può? "). Alla fine, comunque, penso che arriverà ad una discussione sull'accettabilità del rischio e chi è disposto ad accettare tale rischio. Prova a spiegarglielo in questo modo

"Abbiamo un elenco delle applicazioni in bianco, quindi perché dobbiamo correggere le vulnerabilità?"

La whitelist dell'applicazione è valida solo quanto la whitelist stessa, gli strumenti per bloccare le app non su quella lista bianca e presuppone che non vi siano errori o vulnerabilità nello stesso strumento di whitelisting dell'applicazione. Protegge inoltre solo da applicazioni sconosciute / non attendibili. Cosa succede se l'attaccante decide di "vivere fuori dalla terra" e utilizzare gli strumenti propri del sistema 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 è, in effetti, lo stesso argomento del precedente. Sei sicuro, assolutamente, positivamente, al 100%, al di là di un dubbio dubbio che non ci siano vulnerabilità nello stack di rete e / o nel firewall stesso né in nessuna delle applicazioni o servizi che possono essere ascoltati o accessibili tramite lo stack di rete?

Se le loro risposte a quanto sopra sono che sono al 100% positive riguardo alle loro scelte e decisioni, allora scriverò un documento che specifichi la loro accettazione di quel rischio e lo faccia firmare dal gruppo dirigente fino a il CIO. In fin dei conti è il loro (il livello CxO) a essere in difficoltà per il problema se e quando il sistema viene violato e loro sono quelli che potrebbero essere chiamati prima che il Congresso (o qualunque organo di controllo governativo cui sono soggetti) i dirigenti erano ad Equifax. Quando viene spiegato ai dirigenti che non stanno facendo tutto quanto è in loro potere per mantenere un sistema aggiornato e patchato (come richiesto da molti diversi gruppi / leggi di credenziali e di supervisione) e che loro (il CxO) potrebbero essere ritenuti responsabili, atteggiamenti spesso si sposterà.

Mi sembra semplice. Tornando alla domanda su come ottenere un punto in argomento contro non applicare patch a un sistema che si ritiene non possa essere risolto. Qual è lo scenario peggiore che può accadere se tale sistema viene violato? Supponiamo che tutte le protezioni presenti non funzionino o che vengano violate allo stesso modo. Non pregiudicare questo esercizio, escludendo le conseguenze perché non pensi che possa o verrà violato.

Ora, poniamo lo scenario peggiore in termini di costi di impatto aziendale sotto forma di mancati guadagni, ammende legali / normative o danni all'immagine dell'azienda nel settore.

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

D'altro canto, se l'impatto sul business non è tale, potrebbe avere senso continuare a utilizzare un SO EOL. Ma il modo migliore per farlo in un modo ben gestito dal rischio è un altro argomento.

Se il tuo dispositivo ha una connessione wi-fi, può essere attaccato attraverso la rete. L'attacco riuscirà? Si tratta dei vantaggi di attaccare il dispositivo, rispetto al livello di sforzo richiesto. Basandolo su un sistema operativo obsoleto e non supportato, semplifica decisamente il metodo di attacco.

La whitelist dell'applicazione non è una protezione, ma solo un blocco secondario. Pensi che un hacker non possa sviluppare un'app che si maschera come una nella whitelist dell'app? Certo che possono ... qualcosa che potrebbero esaminare se il loro primo tentativo non funziona.

Equifax aveva un firewall ben funzionante. Non ha impedito agli hacker di sfruttare il buco di Struts che i responsabili IT di Equifax non riuscivano a correggere, attraverso una porta che era stata lasciata aperta per necessità. Un firewall blocca solo alcuni degli attacchi più vecchi e ovvi.

Ripensa all'hack di Target: il CEO e il CIO hanno perso il lavoro su quello, ed è stato perpetrato da un insider, aiutato dall'uso da parte di Target di una vecchia versione di Windows, non più aggiornata, oltre a una connettività non sicura più vecchia metodi sui loro dispositivi di punto vendita. Indubbiamente, il CIO ha concluso che aggiornare la versione di Win sui propri dispositivi POS era troppo costoso, un giudizio che si è dimostrato molto sbagliato.

Il firmware incorporato è immune all'hacking? Si consideri l'hack della stampante HP. HP ha avuto l'intelligente idea di aggiornare il firmware della stampante attraverso un processo di stampa, facile da avviare. Fino a quando ... qualcuno ha realizzato una versione del firmware che trasformava la stampante in un relay di spam e la consegnava tramite un processo di stampa malware.

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

Un dispositivo in rete può essere hackerato diventando parte di una botnet ... un modo comune per lanciare un attacco DOS. Un hacker potrebbe trovare la vulnerabilità e, sapendo che danneggerebbe la reputazione dell'azienda, lanciare l'attacco nello stesso momento in cui stanno mettendo a corto le azioni dell'azienda. Quello è 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'individuare e mitigare le potenziali minacce, specialmente dal momento che stai basando il sistema su un sistema operativo che non viene più aggiornato? Suggerimento: prendere la parola di ingegneri che dicono che il sistema è "inaccessibile" probabilmente non si qualifica come due diligence.

Se è per questo, se i tuoi tecnici dicono che non sono accessibili, probabilmente non stanno nemmeno cercando potenziali vulnerabilità, per non parlare di attenuarle.

Chiunque affermi che un sistema non è accessibile non è realistico. Non in questo giorno ed età.

Questa potrebbe non essere una decisione tecnica. L'uso di qualsiasi componente esternamente significa generalmente che devi usare quel componente rigorosamente in conformità con le linee guida del produttore, o rischiare di rimanere bloccato con tutte le conseguenze e le responsabilità derivanti da qualsiasi errore in cui potrebbe essere implicato.

Quindi, se il dispositivo si comporta male e qualcuno è ferito (o qualche altra responsabilità), il produttore del sistema operativo originale dirà "software non supportato - non il nostro problema". E l'assicuratore della vostra azienda dirà "utilizzando software antiquato non supportato - è negligente, quindi non è il nostro problema".

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

• è stato dimostrato che lo stanno facendo (e tu lo hai scritto per iscritto)
• hanno affermato affermativamente che l'aggiornamento non è necessario (e lo hanno reso per iscritto)

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

In pratica, ci sono spesso aggiornamenti ai componenti che sono obbligati da loro a partire da EOL, anche se non ci sono reali esigenze tecniche per farlo. Questa è una parte necessaria dell'ingegnerizzazione di un prodotto complesso.

A seconda delle risorse a tua disposizione, il modo "infallibile" (con tutto il rispetto per i tuoi colleghi) sarebbe quello di dimostrare a loro che il sistema è hackerabile. Assumi qualcuno che possa, e fagli dimostrare le debolezze del sistema. La mia ipotesi è che con WLAN non dovrebbe essere terribilmente difficile. WLAN e firewall? Questo è un contradictio 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 (hacking) varrà sempre la pena.

Ogni giorno abbiamo titoli che dicono che alcuni sistemi sono compromessi. Non è perché non sono né aggiornati né protetti dalle mitragliatrici, ma perché qualcuno sta investendo il tempo per hackerarli.

Soprattutto, quelli che sono ben giocati 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 ci siamo imbattuti in quel buco ci danno le informazioni che non li aiutano.