Sicurezza di rete Air Gapped: è possibile impedire l'esecuzione del codice precompilato per limitare la vulnerabilità al firmware compromesso?

1

Non sono sicuro se questo sia il mezzo giusto per chiederlo ma sto cercando dei puntatori o se questo è stato fatto. Mi rendo conto che questa è ancora una domanda aperta.

Quando la rete interna contiene dati critici e software / hardware di controllo, l'airgapping è la norma. Ma come abbiamo visto in Stuxnet / Flame e nei loro fratelli, ha i suoi limiti. E ora che il gatto è fuori dalla borsa, probabilmente vedremo aggressori sponsorizzati da non stati che usano questo vettore.

Quindi, assumiamo un attaccante sofisticato e motivato senza accesso fisico. L'attaccante proverà a contrabbandare in firmware contaminato tramite intercettazioni hardware, ingegneria sociale o approcci innovativi. Controllare il firmware prima di connettersi alla rete sarebbe l'ideale ma anche allora, potrebbe non essere possibile ottenere il 100% di rilevamento. Sto cercando modi per mitigare il danno e ridurre al minimo il tempo fino al rilevamento, se ci riescono.

Presupposti: accesso all'origine di tutto ciò che viene eseguito all'interno della rete. I datadrive sono criptati. L'hacker conosce ampiamente il software e l'hardware utilizzati, ha una buona stima dell'architettura di rete. Non ha accesso fisico al sistema. L'attaccante ha a portata di mano vulnerabilità zero-day che consentono loro di violare le difese di livello superiore come i privilegi degli utenti.

Questa minaccia potrebbe essere mitigata rendendo il codice precompilato non in grado di essere eseguito nel sistema rendendo l'intera rete interna non in grado di eseguire codice precompilato? Come possiamo ottenere questo?

Sto pensando in linee di collegamento di tutto ciò con le librerie locali con abbastanza differenze che la compilazione di quelle librerie sarebbe necessaria perché l'attacco funzioni. Cos'altro possiamo mescolare? Obiettivo è quello di massimizzare la difficoltà aggiunta pur mantenendo la capacità di integrare il nuovo software compilandolo in-system.

Questo potrebbe aiutare? Il firmware continuerebbe a funzionare e potrebbe causare molti danni. Ma limitare la capacità di iniettare sostanze aumenterebbe il rischio di rivelazione, che è il massimo che possiamo sperare.

Mi rendo conto che la sicurezza per oscurità è disapprovata, ma sento che potrebbe avere il suo posto in questo. Poiché la parte oscurata è specifica del sito, l'utente malintenzionato dovrebbe avere accoplice sul posto e dobbiamo fare affidamento sulla sicurezza del personale per impedirlo.

Per ricapitolare sotto forma di domande:

  1. È possibile limitare significativamente l'esecuzione di codice estraneo all'interno della rete mediante modifiche che richiedono binari costruiti localmente?
  2. È stato fatto?
  3. Questo ha senso?
posta WhimsicalWombat 19.02.2015 - 18:35
fonte

0 risposte

Leggi altre domande sui tag