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

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:

• Il TPM può monitorare lo stato della piattaforma e fornire un rapporto sull'integrità della piattaforma .
• Il TPM può memorizzare una chiave di crittografia del disco , che ti consente di utilizzare eccellente crittografia del disco in modo che il disco non possa essere utilmente montato su un'altra macchina.

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.

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!

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 '.

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?