Aiuta a rendere conto di tutti i punti di accesso fisico a un server rack per rubare software

2

Diciamo che voglio spostare il mio server Dell 1U per co-location del sito con una società ostile che proverà a rubare il mio codice (questa è quasi il 90% di probabilità se non faccio passi) ...

La limitazione per la loro ostilità vedo (o spero) - non possono rimuovere completamente la scatola e dirmi, "oops, si è perso nella posta", non possono assumere esperti di livello troppo alto (come l'FBI o NSA), quindi deve essere fatto al livello di un esperto sysadmin che legge i forum di hacking. Inoltre, dovrebbero spiegare eventuali tempi di fermo (il che è facile ma in combinazione con le prove di manomissione sarà un potente deterrente).

Ora ..

Da quanto ho capito, il modo migliore per proteggere il tuo software è crittografarlo sul disco.

Quindi per disabilitare l'accesso esterno per avviare il server per l'attacco a freddo (penso - disconnetti unità ottica, USB, porta com ecc.)

Quindi ho ancora i seguenti problemi: aprire la custodia e collegarmi al MB o rimuovere RAM in cui il software decripted era in esecuzione prima di un attacco di avvio a freddo.

Domanda n. 1 - ci sono altre minacce per il furto del codice nella situazione data?

Quello che sto pensando è assicurarsi che se manometteranno il caso otterrò una prova che può essere portata in tribunale e ottengo il risarcimento. Se il dispositivo antimanomissione è convincente e affidabile, non rischierà la sua reputazione con il caso legale e lascerà questo da solo.

Per favore dimmi cosa ne pensi. È un piano fattibile? È possibile restringere le possibilità di rubare ad aprire la scatola (voglio dire che la disconnessione USB ecc funzionerà?) Ci sono altre cose che devo considerare?

EDIT. Proverò a compilare le risposte.

La considerazione principale - utilizzando Dell TPM. La scatola è Dell R210

  1. Rimozione della RAM (attacco di avvio a freddo)
  2. Accesso alla console con account non protetto [fai in modo che aiuti a recuperare le chiavi TPM?]
  3. Avvio da un altro disco rigido [fai in modo che aiuti a ripristinare i tasti TPM?]

EDIT EDIT. Ragazzi, la maggior parte di voi ha assunto erroneamente che avere una scatola su colocation significa un ISP o un'azienda Internet che vende colo ai server web, ai giocatori ecc. Ci sono pochi ragazzi nella mia area di competenza che vende colo a prezzi accessibili. (Per colo intendo lasciare che altre persone sappiano mettere scatole nei loro rack) E tutti noi stiamo facendo la stessa cosa, quindi non hanno bisogno di chiedere loro sanno cosa faccio e so cosa fanno. Mettere loro una scatola non protetta è come lasciare una bottiglia aperta di Glenfiddich 18 accanto a un alcolizzato e andarsene. Qualunque sia la moralità, saranno davvero tentati di aprirla. So che lo farei anch'io nei loro panni. Anche l'avvio a freddo non è una cosa tanto sofisticata. Quindi la maggior parte delle tue proiezioni semplicemente non conta nel mio caso.

Lo lascerò aperto per un paio di giorni è qualcuno che vorrebbe aggiungere all'elenco delle minacce fisiche reali.

Grazie per la tua pazienza:)

    
posta Boppity Bop 19.02.2012 - 02:46
fonte

4 risposte

4

L'utente malintenzionato ha accesso fisico alla macchina e può avviarlo sotto un sistema operativo sotto il suo controllo o montare l'unità su un'altra macchina. Pertanto, è necessaria una sicurezza fornita almeno in parte al di fuori della memoria della macchina, in un modo che è alquanto resistente alle manomissioni fisiche.

Questo è un tipico caso d'uso per un Trusted Platform Module (TPM) . Il TPM è un chip aggiuntivo sulla scheda madre, un po 'resistente alla manomissione (non per un laboratorio ben attrezzato, nemmeno per un individuo esperto con un po' di attrezzatura elettronica, ma per una persona casuale dotata di nient'altro che un cacciavite e una USB stick) e a prova di manomissione (può essere sconfitto strappandolo dalla scheda madre e inserendo un chip attivo tra il TPM e il resto della scheda madre, ma sarebbe difficile ripristinarlo senza lasciare traccia). Il TPM può memorizzare chiavi segrete che non escono mai e possono eseguire operazioni crittografiche con queste chiavi. In particolare:

Un TPM non è una bacchetta magica. Deve essere configurato correttamente, e più in generale l'intera piattaforma deve essere configurata correttamente. Un TPM non è valido se l'utente malintenzionato può collegare una tastiera e ottenere l'accesso alla console a causa di un account protetto in modo errato o perché il BIOS consente l'avvio da un disco diverso dal proprio.

Un altro attacco che un TPM non impedisce è nella RAM. Ad esempio, l'utente malintenzionato potrebbe tentare un attacco hot swap sulla RAM e leggerne il contenuto. Quindi avresti bisogno di un caso resistente alle manomissioni, o almeno a prova di manomissione.

Se si utilizza un TPM in questo modo, non dimenticare di eseguire il backup di tutte le chiavi principali del TPM prima di spedire la scatola, poiché i dati andrebbero persi senza di essi.

Dato il modo in cui presenti la tua situazione, sospetto che

  • o esagerate il valore del vostro codice per la società di hosting (perché dovrebbe importare? a chi lo vendono?)
  • o, se questo vale tanto per te, devi pagare per un hosting più costoso.

Non dimenticare che se hanno il tuo codice, non va bene se non possono trarne profitto. Se improvvisamente offrono un servizio come il tuo, potresti avere una buona ragione per fare causa e chiedere la scoperta di come hanno sviluppato il loro servizio (consulta il tuo avvocato). Non tutte le misure di sicurezza sono tecniche, un contratto può essere un deterrente.

    
risposta data 20.02.2012 - 19:26
fonte
7

Penso che tu non stia pensando a questo chiaramente.

Se sei convinto che il provider di hosting tenterà di rubare il tuo codice, c'è una soluzione molto semplice: non distribuire il tuo codice su una macchina con quel provider di hosting!

Se sei convinto che ogni provider di hosting tenterà di rubare il tuo codice, non distribuirlo su alcun provider di hosting: distribuilo su macchine nei tuoi stessi locali.

Detto questo, sospetto strongmente che l'analisi delle minacce sia errata. Trovo difficile credere che ci sia una probabilità del 90% che ogni provider di hosting ruberà il tuo codice, se può farla franca. Non c'è modo che sia preciso. Se venissero catturati, il colpo alla loro reputazione sarebbe devastante: li metterebbe fuori mercato. I fornitori affidabili non rischiano di correre questo rischio. Inoltre, la maggior parte dei provider di hosting non ha interesse per il tuo codice; sono focalizzati sul loro servizio di hosting e probabilmente non si preoccupano del tuo codice.

Quindi sospetto che abbiate valutato male il rischio. Ma se sei convinto di avere il rischio giusto, beh, la soluzione è semplice. Non usare un provider di hosting.

Conosci la vecchia battuta:
Paziente: Dottore, dottore, per favore aiutami. Fa male quando mi schiaffo il ginocchio.
Dottore: Beh, non farlo poi!

    
risposta data 21.02.2012 - 02:18
fonte
4

Classicamente, ci sono quattro cose che puoi fare con qualsiasi rischio:

  • Tratta il problema implementando i controlli di sicurezza.
  • Tolleralo come accettabile.
  • Trasferiscilo a terzi.
  • Termina.

Nella situazione in cui descrivi, dove hai una probabilità molto alta di un incidente, e supponendo che il costo di un incidente sia alto, allora l'approccio migliore sarà quello di porre fine al rischio - cioè non fallo al primo posto.

Non ti è di grande aiuto, ovviamente, ma c'è un motivo per cui la sicurezza continua a parlare dell'accesso fisico alla scatola; non ci sono controlli di sicurezza veramente efficaci quando l'attaccante ha accesso illimitato alla scatola.

Se non riesci a terminarlo, ovviamente puoi provare gli altri metodi. Il trasferimento a una terza parte sarà difficile, in quanto sarebbe complicato e costoso da assicurare, e già non ti fidi del contratto che hai con il provider di hosting.

Questo lascia una combinazione di Treat e Tolerate. Trattare il rischio implicherebbe cose come il rilevamento di intrusioni / manomissioni, il monitoraggio delle attività sulla scatola, avvisando il fornitore che si farà causa alla caduta di un cappello e così via. Tuttavia, poiché l'attaccante ha accesso fisico alla scatola, alla rete e al potere, ed è pronto a violare il loro contratto e la legge, questi trattamenti non saranno in grado di ridurre il rischio di molto.

Questo lascia solo tollerare il rischio nonostante la sua gravità: accettando che se devi mettere la scatola in quella situazione c'è una buona probabilità che la tua attività venga compromessa.

Infine, vi è un altro trattamento che consiglierei di prendere in considerazione in questo caso. Se sei in grado di dire che hanno rubato il tuo codice perché iniziano a usarlo, e se sostengono che non lo faranno, potresti cercare di convincere il tuo avvocato ad aggiungere clausole penali all'accordo con loro - una sorta di non -completare. Non è l'ideale, dal momento che prende il via solo dopo che il danno è stato fatto, ma in una situazione così brutta ogni trattamento che puoi accumulare aiuta un po '.

    
risposta data 20.02.2012 - 18:48
fonte
3

In realtà il modo migliore per proteggere il codice sorgente è di non metterlo su un server che non controlli. Puoi compilare il tuo codice e solo distribuire i file binari?

Sembra che ci sia un altro grande rischio che non si menziona, stai pensando di fare i backup? Chi li farà?

Se il colo sta facendo i backup, come fai a sapere di non averne fatto una copia.

Se stai facendo i backup via rete su un sito remoto, come fai a sapere che non stanno sniffando il traffico?

    
risposta data 19.02.2012 - 03:58
fonte

Leggi altre domande sui tag