Prima di tutto, voglio dire che solo perché un'azienda è grande non significa che la sua sicurezza sarà migliore.

Detto questo, menzionerò che aver svolto un lavoro di sicurezza in una grande numero di aziende Fortune 500, inclusi molti marchi famosi con cui la maggior parte delle persone ha familiarità, dirò che attualmente il 60-70% di loro non fa tutto quello che penseresti dovrebbe fare. Alcuni danno persino a centinaia di società di terze parti in tutto il mondo pieno accesso per estrarre dalla loro base di codice, ma non necessariamente per scrivere su di essa.

Alcuni utilizzano più repository Github privati ​​per progetti separati con l'autenticazione a due fattori abilitata e uno stretto controllo su chi concedono l'accesso e hanno un processo per revocare rapidamente l'accesso quando qualcuno se ne va.

Alcuni altri sono molto seri nel proteggere le cose, quindi fanno tutto in casa e usano cosa per molti altri le aziende sembrerebbero livelli eccessivi di controllo della sicurezza e monitoraggio dei dipendenti. Queste aziende utilizzano soluzioni come gli strumenti DLP (Data Loss Prevention) per controllare l'esfiltrazione di codice, l'accesso VPN interno ad ambienti fortemente rinforzati solo per lo sviluppo con una tonnellata di controlli di sicurezza e monitoraggio tradizionali e, in alcuni casi, l'acquisizione di tutti i pacchetti completi traffico nell'ambiente in cui è memorizzato il codice. Ma a partire dal 2015 questa situazione è ancora molto rara.

Una cosa che può interessare e che mi è sempre sembrata insolita è che il settore finanziario, in particolare le banche, ha una sicurezza di gran lunga peggiore di quanto si potrebbe pensare e che l'industria farmaceutica è molto migliore di altre industrie, compresi molti appaltatori della difesa. Ci sono alcune industrie che sono assolutamente orribili riguardo alla sicurezza. Dico questo perché ci sono altre dinamiche in gioco: non sono solo le grandi aziende contro quelle piccole, gran parte ha a che fare con la cultura organizzativa.

Per rispondere alla tua domanda, sottolineerò che è l'azienda nel suo insieme a prendere queste decisioni e non i team di sicurezza. Se i team di sicurezza fossero responsabili di tutto, o anche solo sapessero di tutti i progetti in corso, le cose probabilmente non sarebbero per niente come fanno oggi.

Detto questo, dovresti tenere a mente che la maggior parte le imprese sono quotate in borsa e per una serie di ragioni tendono a preoccuparsi molto di più dei profitti a breve termine, dell'incontro con i numeri trimestrali e della competizione per la quota di mercato rispetto agli altri grandi concorrenti che dei rischi per la sicurezza, anche se i rischi potrebbero effettivamente distruggere la loro attività. Quindi tienilo a mente quando leggi le seguenti risposte.

• Se il codice sorgente fosse stato rubato:

  1. Alla maggior parte non importerebbe e non avrebbe quasi alcun impatto sul loro marchio o sulle vendite. Tieni presente che in molti casi il codice stesso non è ciò che memorizza il valore dell'offerta di un'azienda. Se qualcun altro ha ottenuto una copia della fonte di Windows 10, non potrebbe creare improvvisamente un'azienda che vende un sistema operativo clone di Windows 10 ed essere in grado di supportarlo. Il codice stesso è solo una parte della soluzione venduta.

  2. Il prodotto sarebbe maggiormente a rischio a causa di ciò? Sì, assolutamente.

• Modifica esterna: Sì, ma è più difficile da fare e più facile da catturare. Detto questo, dal momento che la maggior parte delle aziende non lo sta monitorando seriamente, è una possibilità molto reale che ciò sia accaduto a molte grandi aziende, specialmente se l'accesso back-door al loro software è di valore significativo per altri stati-nazione. Questo probabilmente accade molto più spesso di quanto le persone credano.

• Attaccante interno: a seconda di quanto intelligente fosse l'attaccante, questo potrebbe non essere mai notato o potrebbe sembrare un errore di programmazione poco appariscente. Al di fuori dei controlli in background e del monitoraggio del comportamento, non c'è molto che possa impedirlo, ma si spera che alcuni strumenti di analisi del codice sorgente lo catturino e costringano il team a correggerlo. Questo è un attacco particolarmente duro da cui difendersi ed è il motivo per cui alcune aziende non esternalizzano il lavoro ad altri paesi e fanno controlli approfonditi sui loro sviluppatori. Gli strumenti di analisi statica del codice sorgente stanno migliorando, ma ci sarà sempre un divario tra ciò che possono rilevare e ciò che può essere fatto.

In poche parole, i buchi arriveranno sempre prima delle correzioni, quindi affrontare la maggior parte dei problemi di sicurezza diventa una specie di corsa contro il tempo. Gli strumenti di sicurezza aiutano a darti dei compromessi in termini di tempo, ma non avrai mai una sicurezza "perfetta" e avvicinarti a questo può diventare molto costoso in termini di tempo (rallentando gli sviluppatori o richiedendo molte più ore di lavoro da qualche altra parte).

Di nuovo, solo perché un'azienda è grande non significa che abbia una buona sicurezza. Ho visto alcune piccole aziende con una sicurezza molto migliore rispetto ai loro concorrenti più grandi e penso che questo sarà sempre più il caso poiché le aziende più piccole che vogliono prendere la loro sicurezza più seriamente non devono fare cambiamenti organizzativi, in cui le aziende più grandi saranno costrette a mantenere il modo in cui hanno fatto le cose in passato a causa dei costi di transizione.

Ancora più importante, penso che sia più facile per una nuova azienda (di qualsiasi dimensione, ma soprattutto quelle più piccole) avere la sicurezza fortemente integrata nella sua cultura di base piuttosto che dover cambiare le loro culture attuali / legacy come devono fare le aziende più vecchie. Potrebbero anche esserci opportunità per sottrarre quote di mercato a un prodotto meno sicuro creando una versione molto sicura di esso. Allo stesso modo, penso che la tua domanda sia importante per un motivo completamente diverso: la sicurezza è ancora agli inizi, quindi abbiamo bisogno di soluzioni migliori in aree come la gestione del codice in cui c'è molto spazio per miglioramenti.

^{Disclaimer : lavoro per un'azienda molto grande che fa un buon lavoro in questo settore, ma la mia risposta è la mia opinione personale e non è indicativa della posizione del mio datore di lavoro o criteri.}

Prima di tutto, come proteggere il codice dalla fuga di notizie:

• Sicurezza di rete: Questo è ovvio: se gli hacker cinesi inseriscono le credenziali nei tuoi sistemi interni, cercheranno il tuo codice sorgente (se non altro per il fatto che il codice sorgente dirà loro dove andare dopo). Quindi la sicurezza informatica di base deve essere un "dato".
• Controllo degli accessi: il tuo addetto alla reception ha bisogno di accedere al tuo archivio di codice? Probabilmente no. Limita la tua esposizione.
• Sii selettivo nelle assunzioni e mantieni un ambiente di lavoro sano: le misure DLP come la scansione della posta in uscita sono in teoria ingegnose, ma se il tuo ingegnere è abbastanza intelligente da essere qualsiasi utilità per te, sono abbastanza intelligenti da capire come aggirare le tue misure DLP. I tuoi dipendenti non dovrebbero avere un motivo per far trapelare il tuo codice sorgente. Se lo fanno, hai fatto qualcosa di orribilmente, orribilmente sbagliato.
• Monitora la tua rete: questa è un'estensione della risposta "sicurezza di rete" ma con un'enfasi sulla prevenzione della perdita digitale . Se vedi un picco improvviso nel traffico DNS, potrebbe essere il tuo codice sorgente che viene esfiltrato da un aggressore. OK, ora chiediti se vuoi sapere se c'è stato un picco improvviso nel traffico DNS dalla tua rete. Probabilmente no.
• Tratta i dispositivi mobili in modo diverso: telefoni e laptop si perdono molto spesso. Vengono anche rubati davvero spesso. Non memorizzare mai informazioni sensibili (inclusi codice sorgente, dati dei clienti e segreti commerciali) su dispositivi mobili. Sul serio. Mai. Ciò non significa che non puoi utilizzare i dispositivi mobili per accedere e modificare il codice sorgente. Ma se un laptop scompare, dovresti essere in grado di revocare da remoto qualsiasi accesso che il laptop ha ai dati sensibili. In genere ciò significa che il codice e i documenti vengono modificati "nel cloud" (vedere c9.io, koding.com, Google Docs, ecc.) Con un'autenticazione appropriata e tutto il resto. Questo può essere fatto con o senza fidarsi di una terza parte, a seconda di quanto lavoro vuoi dedicarci. Se la tua soluzione non supporta 2 fattori, scegli un'altra soluzione; vuoi ridurre la tua esposizione con questa misura, non aumentarla .

Secondo, come prevenire la modifica del codice dannoso; c'è davvero una sola risposta a questa domanda: cambia il controllo.

Per ogni carattere di codice nel tuo repository, devi sapere esattamente chi ha aggiunto (o eliminato) quel codice e quando. È così facile da fare con la tecnologia odierna che è quasi più difficile non disporre del monitoraggio delle modifiche. Se utilizzi Git o Mercurial o qualsiasi sistema di controllo del codice sorgente utilizzabile in modo modesto, ottieni il monitoraggio delle modifiche e fai molto affidamento su di esso.

Ma per aumentare un po 'l'affidabilità, aggiungerei che ogni modifica a il tuo repository deve essere firmato da almeno un'altra persona oltre all'autore che ha inviato la modifica. Strumenti come Gerrit possono renderlo semplice. Molti regimi di certificazione richiedono comunque revisioni del codice, quindi l'applicazione di tali revisioni al momento del check-in significa che gli attori malintenzionati non possono agire da soli nell'introdurre codice errato nel repository, aiuta a prevenire il commit di codice scritto male e aiuta a garantire che almeno 2 le persone comprendono ogni modifica inviata.

Saranno in atto misure per prevenire l'inserimento accidentale di codice problematico, noto anche come bug. Alcuni di questi aiuteranno anche contro l'inserimento deliberato di codice problematico.

• Quando uno sviluppatore vuole eseguire il commit del codice nel repository, un altro sviluppatore deve esaminare questa richiesta di unione. Forse il secondo sviluppatore dovrà spiegare al primo sviluppatore cosa fa il nuovo codice. Ciò significa superare ogni riga.
• Se il codice sembra confuso, potrebbe essere rifiutato come cattivo stile e non gestibile.
• Il codice ha unità automatizzate e test di integrazione. Quando non esiste un test per una certa riga di codice, la gente si chiede. Quindi ci dovrebbe essere un test che la backdoor funzioni, o una sorta di offuscamento.
• Quando viene creata una nuova versione del software, gli sviluppatori e il controllo qualità controllano quali commit fanno parte della build e perché . Ogni commit deve avere uno scopo documentato.
• Il software viene creato e distribuito utilizzando script automatizzati. Questo non è solo per la sicurezza, ma anche per semplificare il carico di lavoro.

Ovviamente tali misure si basano sull'onestà e sulla buona volontà di tutti i partecipanti. Qualcuno con accesso amministrativo al server di compilazione o al repository potrebbe causare molti danni. D'altra parte, i programmatori ordinari non hanno bisogno di questo tipo di accesso.

Nella mia (grande) azienda, i nostri laptop utilizzano tutti dischi rigidi crittografati. Utilizziamo uno strumento chiamato Digital Guardian che monitora tutti i trasferimenti / caricamenti di file e che blocca le porte USB per la scrittura di file. Chiunque abbia bisogno di un'eccezione deve utilizzare un'unità USB crittografata con hardware (di nuovo, per impedire l'accesso ai file nel caso in cui l'unità venga persa o rubata). Tali eccezioni sono temporanee e occorre giustificare i file in fase di scrittura (che vengono registrati). Digital Guardian impedisce l'invio della maggior parte dei tipi di allegati a indirizzi e-mail esterni. Qualsiasi scambio di file interno viene eseguito utilizzando cartelle basate sul Web con controllo degli accessi e una traccia di controllo di chi ha eseguito l'accesso a cosa: ciò significa che la condivisione di file "per esigenze aziendali" è piuttosto semplice e tutto il resto è difficile.

Il sistema non è infallibile e ha un impatto sulla larghezza di banda, ma i soli strumenti di controllo hanno rilevato più istanze di dipendenti (spesso dipendenti che stavano per lasciare l'azienda) che hanno tentato di prendere il codice sorgente / documenti di progettazione ecc. Almeno stiamo fermando alcuni di questi tentativi.

E nel caso qualcuno pensasse che i caricamenti https sarebbero "invisibili": tutto il traffico web esterno è gestito da un proxy-in -il cloud che utilizza un certificato MITM per ispezionare il traffico https. È senza dubbio possibile aggirare queste misure - ci sono molti dipendenti intelligenti - ma a volte è sufficiente per rendere il tuo obiettivo più difficile di quello degli altri ragazzi.

Questa è una domanda delicata e poiché non ho mai lavorato in quel settore la mia idea potrebbe essere teorica o molto poco pratica.

E se i dipendenti con bassa gerarchia ricevessero solo piccole parti del codice sorgente? Il team di explorer.exe deve solo accedere al codice sorgente di explorer.exe, il che renderebbe più difficile il furto del codice sorgente dall'interno, poiché sarebbe necessario essere in posizioni più elevate per ottenere informazioni su più parti del codice sorgente.

Sicuramente avresti bisogno di una buona documentazione su tutte le parti di cui il team potrebbe aver bisogno ma non può vedere. Anche il debug diventerebbe più complicato perché dovresti unire il codice sorgente precomilato con quello appena compilato dal team explorer.exe Potrebbe esserci un server di compilazione che contiene tutto il codice sorgente e può compilare versioni complete del prodotto anche per quelli che hanno modificato solo un piccolo pezzo. (Perché hanno bisogno di testare le loro modifiche) Questo server sa anche chi ha accesso a quali parti del codice.

Non so se questo sia un approccio pratico o se sta realmente accadendo nel settore o non. È solo un concetto che penso avrebbe senso per prevenire il furto del codice sorgente.

Il valore di mercato di un software è una funzione diretta del

• Valore dei casi aziendali che supporta. RoI, cioè.
• Valore di mercato dei prodotti competitivi
• Il fatto che continuerà ad essere migliorato e supportato dall'azienda
• Marchio dell'azienda. Attività di marketing e vendita relative al prodotto
• Numero di clienti, sviluppatori e membri della comunità soddisfatti esistenti
• Caratteristiche, LoC, numero di brevetti, completezza e qualità del software

Quindi il codice sorgente è solo una parte del gioco. Non tutto.

Il codice sorgente stesso è protetto da

• Contratti legali / T&C firmati dai dipendenti e dall'appaltatore
• Brevetti
• Scomposizione del prodotto in più componenti black-box a cui nessuna singola persona o team ha accesso.
• Utilizzo di meccanismi di sicurezza a livello di software e fisico per proteggere l'accesso al codice