Come impedire al codice di fuoriuscire dal lavoro? [duplicare]

Questa è una delle situazioni in cui cerchi una soluzione tecnica a un problema sociale .

Un problema sociale dovrebbe richiedere una soluzione social, che, in questo caso, richiede due moduli complementari e una soluzione organizzativa aggiuntiva che può aiutare:

• Fiducia. Se non ti fidi degli sviluppatori, non assumerli. Lavorare con persone che non ti fidi è sinonimo di fallimento. Le relazioni basate sulla sfiducia richiedono molto formalismo, che può avere un impatto grave non solo sulla produttività dei dipendenti, ma anche sul numero di persone pronte a lavorare con voi. È probabile che i migliori sviluppatori evitino la tua azienda a tutti i costi.

• NDA. Affidarsi a qualcuno non significa che non si dovrebbero prendere precauzioni legali. Tali precauzioni possono assumere una forma di contratto o clausola NDA con gravi conseguenze per il dipendente in caso di divulgazione.

  Quanto gravi sono le conseguenze dipende da chi sei. Organizzazioni governative, terroristi o mafiosi possono consentire alcuni deterrenti. Le società ordinarie possono essere limitate, per legge, solo a quelle finanziarie.

• Affettare. La fiducia e i contratti sono un buon inizio, ma possiamo fare di meglio. Se la parte sensibile della base di codice può essere suddivisa in modo che due o più parti siano necessarie per il funzionamento del prodotto, assicurarsi che lo sviluppatore del dipartimento 1 non veda mai il codice sorgente sviluppato nel dipartimento 2 e viceversa.

  Le persone di un dipartimento non dovrebbero essere in grado di incontrare persone provenienti da altri dipartimenti e, idealmente, non dovrebbero nemmeno essere in grado di indovinare cosa fanno gli altri reparti, né quanti reparti ci sono. Ogni persona conosce solo una piccola parte, che non è sufficiente per avere un'intera immagine (e ricostruire un intero prodotto al di fuori dell'organizzazione).

Quelle erano misure sociali e organizzative.

Ora, tecnicamente parlando, non c'è niente che puoi fare.

Puoi provare a:

• costringe gli sviluppatori a lavorare in una stanza chiusa su una macchina che non è connessa a Internet e non ha porte USB.

• Installa telecamere che monitorano tutto ciò che accade nella stanza, con diversi addetti alla sicurezza che osservano costantemente gli sviluppatori che lavorano.

• Elimina la strip da ogni sviluppatore ogni volta che esce dalla stanza per essere certo di non avere alcun dispositivo elettronico che possa contenere il codice.

• Richiedi ad ogni sviluppatore di avere un monitor per caviglia. Il dispositivo ascolterà ciò che dice, registrerà la propria posizione e tenterà di rilevare qualsiasi dispositivo elettronico nelle vicinanze. Se lo sviluppatore si trovava vicino a un dispositivo non identificato e non ha installato il software di tracciamento, gli investigatori privati e gli hacker potrebbero tentare di verificare se lo sviluppatore non stava utilizzando il dispositivo per rilevare le informazioni.

• Impedisci agli sviluppatori di lasciare i tuoi edifici, a meno che non siano sotto sorveglianza pesante, e di interagire in alcun modo con il mondo esterno.

Alcune o tutte queste misure sono illegali in molti paesi (a meno che tu non rappresenti alcune agenzie governative ), ma la cosa peggiore è che anche con tutte quelle misure in atto, gli sviluppatori saranno in grado di ottenere il codice, ad esempio scrivendolo discretamente sulla loro pelle o su un pezzo di carta e nascondendolo nei loro vestiti, o semplicemente memorizzandolo se hanno Memoria Eidetica .

Oppure possono solo memorizzare a livello globale le strutture dati e gli algoritmi, che è l'unica cosa importante in cui la proprietà intellettuale è importante e creare il proprio prodotto ispirato a queste due cose.

1. Falli firmare un accordo di non divulgazione.

2. Assumi solo persone di cui ti fidi.

3. Compartmentalize your code base. Uso di dependency injection in modo da poter soddisfare i requisiti che, una volta terminati, le classi risultanti si inseriscono nell'architettura esistente, ma non avranno accesso al "quadro completo", solo pezzi sciolti. Solo le persone di alto livello e fidate avranno il nulla osta alla "colla architettonica" che rende tutto il lavoro come un tutto completo.

Adoro l'idea che potrebbe esserci un'idea "intelligente" secondo cui "noi", in quanto sviluppatori, saremmo sconcertati. Dato che ogni strumento di sviluppo scritto è stato scritto da uno sviluppatore e tutto il resto.

Il più grande problema del tuo capo è l'ingenuità con un pizzico di paranoia. Sono educato lì. Davvero molto educato.

Se vuoi davvero una lista della spesa di cose per mantenere il tuo codice proprietario, basta implementare quanto segue:

1. Disabilita USB e altri IO in tutti i computer aziendali. Questo può essere fatto attraverso la maggior parte degli antivirus aziendali o simili.

2. Tutte le macchine sviluppatore devono essere desktop o torri. Nessun laptop.

3. Non consentire a nessun computer di connettersi a Internet. Nessun web, ftp, email, messaggistica istantanea, niente internet. Taglia i fili.

4. Nessun lavoro / accesso remoto (una sorta di copertura di Internet, ma qualche scintilla intelligente potrebbe suggerire una VPN)

5. Nessun telefono cellulare o altri dispositivi elettronici da portare nella "sala" di sviluppo sicura.

6. Configura tutte le stampanti per stampare una grande filigrana visibile su ogni pagina, fronte e retro.

7. la borsa cerca sia dentro che fuori. Cerca note scritte a mano, qualsiasi cosa stampata su stampanti aziendali (qualsiasi cosa, potrebbero avere codice nascosto in un'immagine con steganografia!). Qualsiasi dispositivo elettrico o elettronico. Anzi, probabilmente è meglio assicurarsi che le borse siano tenute fuori dall'area protetta e gli sviluppatori dovrebbero indossare tute pulite, il genere di cose che si vedono nelle tane della droga e nelle fabbriche di chip fab.

8. I server dovrebbero essere equamente isolati, i backup devono essere crittografati e solo il tuo capo dovrebbe conoscere la password per ripristinarli.

Se non è possibile fidarsi delle persone in questione per mantenere i loro contratti di lavoro, allora non deve assumerle.

Se crede che non ci si possa fidare di nessuno, allora è troppo paranoico, e alla fine danneggerà la compagnia se continua così.

Ad un certo punto DEVI fidarti dei tuoi dipendenti. Non è davvero un'opzione per fare diversamente. Se non ti fidi affatto dei tuoi dipendenti, allora non possono essere efficaci, perché stai spendendo troppo tempo a diffidarli e sprecando molto del loro tempo saltando attraverso i cerchi a causa di problemi di fiducia.

Inoltre, quando fai capire alle persone che non ti fidi di loro, tendono a infastidirsi. E i programmatori infastiditi alla fine trovano un altro lavoro dove non sono trattati in quel modo.

La soluzione giusta è un controllo di base, un accordo di lavoro ben ponderato e un po 'di fiducia.

Ero solito scrivere codice per i sistemi informatici classificati. Avevano tutti i tipi di cerchi ridicoli da saltare per mantenerlo segreto. Ad esempio, non ci è stato permesso di portare CD musicali in alcune stanze perché potevano essere CD-RW sotto mentite spoglie.

Il fatto è che gli aspetti pratici del lavoro aprono le falle della sicurezza per necessità. A volte hai avuto per trasportare dati / codice non classificati dentro o fuori da un'area riservata per portare a termine il lavoro. Sì, c'erano anche regole e procedure per questo, ma alla fine tutte si sono ridotte a persone fidate. Invece di fidarsi delle persone per non mettere i dati riservati su una comoda chiavetta USB, ti stai semplicemente fidando delle stesse persone per saltare attraverso tutti i telai di sicurezza.

In altre parole, ci sono molte cose che puoi fare per proteggere dagli estranei, ma una volta che li hai lasciati entrare, è praticamente solo una questione di quanto vuoi infastidirli.

In breve , devi avere un accordo / contratto di non divulgazione con i dipendenti che stai assumendo. Oltre a questo accordo firmato, puoi assumere sviluppatori che possono fidarsi .

Tecnicamente parlando quel codice può facilmente essere copiato sul dispositivo e riutilizzato da qualche altra parte. Ciò che il tuo capo non vuole è l'accesso dei tuoi concorrenti a questo codice. È possibile applicare tali politiche solo attraverso contratti di lavoro o partnership.

Un'altra cosa che può funzionare è fornire formazione sulla sensibilità delle informazioni , su come ogni dipendente deve essere avvisato quando la riservatezza delle informazioni viene violata. Inoltre, il monitoraggio delle attività del computer all'interno della rete dell'ufficio aumenterà anche il livello di avviso.

Un tipo simile di formazione viene svolta annualmente per i dipendenti che si occupano di informazioni correlate a PHI .

Tuttavia, avere a bordo persone di fiducia e fornire formazione su come proteggere queste informazioni potrebbe essere la soluzione ottimale.

Hai visto Paycheck con Ben Affleck? Penso che sia l'unico modo per garantire che il tuo IP non venga "rubato". Posso dirti che, grazie alla mia memoria, ho potuto ricreare quasi tutti i sistemi su cui ho lavorato per un periodo di tempo considerevole. Se non si tratta di una ricreazione linea per linea, potrei produrre gli elementi significativi e probabilmente migliorarli nel processo a causa di come le mie capacità sono cresciute nel corso degli anni.

Semplice e semplice, ci sono solo due cose che puoi ottenere bloccando il tuo codice:

1. Respingerai i bravi sviluppatori che sono offesi dalla tua evidente mancanza di fiducia
2. Innalzerai una grande bandiera che attira gli sviluppatori più scrupolosi

Se pensi che il tuo software sia così nuovo e sorprendente, ottieni un brevetto.

1. Non puoi impedire la fuoriuscita di codice. Puoi limitare la perdita a un codice meno importante.
2. Normalmente c'è solo una parte dell'applicazione che lo rende unico. Quello sarebbe un algoritmo. Puoi interfacciare questo molto bene e metterlo in un ramo di controllo del codice sorgente separato. Tu e solo quelle persone che hanno bisogno di lavorarci dovrebbero averne accesso. Fornisci solo un binario (offuscato) e l'interfaccia agli altri sviluppatori.
3. Dividi il tuo codice in più moduli e consenti alle persone di lavorare solo su un particolare modulo. Gli altri moduli sono forniti in binario (offuscato). Questo, tuttavia, può essere allungato troppo lontano da renderlo ingestibile e può portare alla duplicazione del codice.

Conosco qualcuno che ha lavorato in un ambiente come questo.

Alcune misure che sono state prese lì:

1. Nessun accesso al computer fisico, tutti i computer sono stati archiviati in una stanza chiusa con buchi nel muro per display, tastiera e mouse.

2. Nessun accesso a Internet.

3. Sistema operativo personalizzato che utilizza un file system costruito internamente con crittografia (nel caso in cui un computer venisse rubato in qualche modo).

4. I progetti sono stati divisi in librerie statiche, nessuno ha avuto accesso all'intero codice sorgente (questo ovviamente non si applica a tutti i linguaggi di programmazione).

5. È stato un posto di lavoro molto spiacevole.

Fai attenzione a non sopravvalutare il valore del tuo codice sorgente a quelli esterni alla tua azienda.

Certo - hai pagato molti ingegneri (sviluppatori, QA, ecc.) per sviluppare un sacco di soldi, ma questo non significa che sia intrinsecamente prezioso per una terza parte.

Quali esatti attacchi esistono?

Il codice sorgente è spesso trapelato da (ad esempio) sviluppo di giochi o società di sicurezza IT. Certo, tali perdite li fanno sembrare cattivi, ma in caso contrario, non causano danni reali.

Chiediti:

• Sei così imbarazzato per la qualità del tuo codice sorgente, sarebbe dannoso per la tua reputazione perderlo?
• Il codice sorgente contiene segreti riservati (ad esempio chiavi di crittografia hard-coded, dettagli dei rapporti finanziari con altre società)? Dovrebbe?
• Un concorrente potrebbe davvero trarre vantaggio dall'utilizzo del codice sorgente, nonostante il rischio di essere scoperto?

Per quanto ne so, c'è stato un caso in cui un membro del personale di una società di sicurezza IT ha cercato di vendere il codice sorgente a un concorrente. Il concorrente ha immediatamente segnalato questo al suo datore di lavoro, e fu presto licenziato. Nessun denaro è cambiato mano, ma il personale non può più lavorare facilmente nel settore della sicurezza IT.

Devi fidarti, ma a volte è meglio monitorare le infrazioni. Ad esempio, se il codice viene eseguito, è possibile telefonare a casa a qualche indirizzo IP su Internet ogni volta che viene eseguito, registrando l'indirizzo IP, le informazioni sul computer, forse persino la posizione geografica in cui è in esecuzione. Esamina il registro per cercare i problemi.

Naturalmente ci sono dei modi per aggirarlo, e gli sviluppatori potrebbero semplicemente cercare sul codice, non eseguirlo.

Potresti configurare il firewall per eseguire l'ispezione dei pacchetti con qualcosa come Snort che potrebbe a) bloccare immediatamente la connessione se rileva, ad es. la tua nota sul copyright e b) segnalarla alla direzione per il follow-up. Per aggirare SSL e HTTPS devi eseguire un proxy HTTPS sul firewall.

Forse potresti avere un'utilità di sistema su ogni PC che controlla le unità esterne e le chiavette USB per specifici file o frasi chiave mentre sono collegati. Puoi anche disabilitare / escludere le unità esterne (ho sentito che il DOD americano fa questo ). Dovresti richiedere che utilizzino il tuo hardware e non portino l'hardware da casa.

Ci sono probabilmente programmi disponibili che registreranno tutto ciò che qualcuno fa con un computer. Pianifica solo controlli casuali di questi registri e assicurati che gli sviluppatori siano a conoscenza di questa funzionalità.

Una volta individuata un'infrazione, colpisci lo sviluppatore in testa con la NDA che hanno firmato.

Una soluzione tecnica potrebbe essere quella di avere tutte le sessioni di sviluppo ospitate su un server senza accesso alla rete (o severamente limitato e monitorato) oltre a quello richiesto per servire le sessioni RDP (o VNC). In questo modo, la fonte non è mai sul computer di uno sviluppatore. Permetterebbe anche di lavorare da casa o da un sito client.

In definitiva, penso che l'intera situazione sia matura per il fallimento. Se rendi evidente agli sviluppatori che non ti fidi di loro, e rendi più difficile il loro lavoro, allora IMHO stai creando un ambiente in cui gli sviluppatori troveranno un modo per rendere pubblica la fonte, giusto per "attaccalo all'uomo".

Lavori per persone che semplicemente non capiscono come funziona l'ingegneria del software. Peggio: non lo valutano (solo ciò che possono ricavarne). Non sarà possibile lavorare in modo produttivo per loro; alla fine, ti puniranno per questo. Trova un altro lavoro.

Mentre sono d'accordo che è una ricetta per il disastro perché nessun programmatore rimarrà lì abbastanza a lungo e passerai più tempo a cercare di capire il codice di altre persone, alcune cose vengono in mente:

• Blocca l'accesso a Internet
• Blocca l'accesso a terzi (USB, lettori di schede, ecc.)
• Cifra e salva altrove qualsiasi linea del codice. Ecco fatto, trasformare ogni codice in un'API in modo che i programmatori non possano più accedere alle funzioni.
• Ciò comporta: programmatori separati dai debugger.

Ad ogni modo ... preparati ad avere un alto movimento di persone e alti stipendi se vuoi che restino lì. Stai creando un ambiente di lavoro molto brutto.

Tieni presente che potresti praticamente scrivere molto codice da tutti gli esempi gratuiti disponibili in Internet. La maggior parte della programmazione sta effettivamente riutilizzando. Stai per bloccare e ritardare i tuoi lavoratori.