Skip to content

Come fanno le grandi aziende a proteggere il loro codice sorgente?

Questa è la soluzione più completa che possiamo offrirti, tuttavia, guardala attentamente e verifica se è compatibile con il tuo progetto.

Soluzione:

Innanzitutto, voglio dire che solo perché un'azienda è grande non significa che la sua sicurezza sia migliore.

Detto questo, vorrei ricordare che, avendo lavorato sulla sicurezza in un gran numero di aziende Fortune 500, tra cui molti marchi conosciuti dalla maggior parte delle persone, posso dire che attualmente il 60-70% di esse non fa tutto quello che si pensa dovrebbe fare. Alcune danno addirittura a centinaia di aziende di terze parti in tutto il mondo il pieno accesso per prelevare dal loro codice, ma non necessariamente per scriverci.

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

Altre aziende sono molto attente alla protezione delle cose, quindi fanno tutto in casa e utilizzano quelli che per molte altre aziende sembrerebbero livelli eccessivi di controllo della sicurezza e di monitoraggio dei dipendenti. Queste aziende utilizzano soluzioni come gli strumenti di Data Loss Prevention (DLP) per controllare l'esfiltrazione del codice, l'accesso interno tramite VPN ad ambienti fortemente protetti solo per lo sviluppo, con una tonnellata di controlli di sicurezza e monitoraggio tradizionali e, in alcuni casi, l'acquisizione di pacchetti completi di tutto il traffico nell'ambiente in cui è memorizzato il codice. Ma nel 2015 questa situazione è ancora molto rara.

Una cosa che può essere interessante e che mi è sempre sembrata insolita è che l'industria finanziaria, in particolare le banche, hanno una sicurezza molto peggiore di quanto si possa pensare e che l'industria farmaceutica è molto meglio di altri settori, compresi molti appaltatori della difesa. Ci sono alcune industrie che sono assolutamente orribili per quanto riguarda la sicurezza. Lo dico perché ci sono altre dinamiche in gioco: non si tratta solo di grandi aziende contro piccole aziende, ma gran parte di esse ha a che fare con la cultura organizzativa.

Per rispondere alla sua domanda, vorrei sottolineare che è l'azienda nel suo complesso a prendere queste decisioni e non i team di sicurezza. Se i team di sicurezza fossero a capo di tutto, o anche solo a conoscenza di tutti i progetti in corso, probabilmente le cose non avrebbero l'aspetto che hanno oggi.

Detto questo, bisogna tenere presente che la maggior parte delle grandi aziende sono quotate in borsa e, per una serie di ragioni, tendono a preoccuparsi molto di più dei profitti a breve termine, di rispettare i numeri trimestrali e di competere per la quota di mercato con gli altri grandi concorrenti, piuttosto che dei rischi per la sicurezza, anche se questi rischi potrebbero effettivamente distruggere la loro attività. Tenete quindi presente questo aspetto quando leggete le risposte seguenti.

  • Se il codice sorgente venisse rubato:

    1. La maggior parte non se ne preoccuperebbe e non avrebbe quasi alcun impatto sul marchio o sulle vendite. Tenete presente che in molti casi non è il codice in sé a conservare il valore dell'offerta di un'azienda. Se qualcun altro ottenesse una copia dei sorgenti di Windows 10, non potrebbe improvvisamente creare un'azienda che venda un sistema operativo clone di Windows 10 e sia in grado di supportarlo. Il codice stesso è solo una parte della soluzione venduta.

    2. Il prodotto sarebbe più a rischio per questo motivo? Assolutamente sì.

  • Modifica esterna: Sì, ma questa è più difficile da fare e più facile da catturare. Detto questo, poiché la maggior parte delle aziende non monitora seriamente questo aspetto, è una possibilità molto concreta che ciò sia accaduto a molte grandi aziende, soprattutto se l'accesso back-door al loro software ha un valore significativo per altri Stati nazionali. Probabilmente questo accade molto più spesso di quanto si pensi.

  • Attaccante interno: A seconda dell'intelligenza dell'attaccante, questo potrebbe non essere mai notato o potrebbe essere fatto passare per un errore di programmazione poco evidente. Al di fuori dei controlli sul background e del monitoraggio del comportamento, non c'è molto che possa impedirlo, ma si spera che alcuni strumenti di analisi del codice sorgente lo individuino e costringano il team a correggerlo. Si tratta di un attacco particolarmente difficile da difendere ed è il motivo per cui alcune aziende non esternalizzano il lavoro in 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, le falle usciranno sempre prima delle correzioni, quindi affrontare la maggior parte dei problemi di sicurezza diventa una sorta di corsa contro il tempo. Gli strumenti per la sicurezza aiutano a fornire i tempi, ma non si potrà mai avere una sicurezza "perfetta" e avvicinarsi ad essa può diventare molto costoso in termini di tempo (rallentando gli sviluppatori o richiedendo molte ore di lavoro in più da qualche altra parte).

Ancora una volta, solo perché un'azienda è grande non significa che abbia una buona sicurezza. Ho visto alcune piccole aziende con molto e credo che questo sarà sempre più il caso, dato che le aziende più piccole che vogliono prendere la sicurezza più seriamente non devono fare cambiamenti organizzativi massicci, mentre le aziende più grandi saranno costrette ad attenersi al modo in cui hanno fatto le cose in passato a causa dei costi di transizione.

Inoltre, penso che sia più facile per una nuova azienda (di qualsiasi dimensione, ma soprattutto per quelle più piccole) avere la sicurezza fortemente integrata nella propria cultura di base, piuttosto che dover cambiare la propria cultura attuale/legacy come hanno dovuto fare le aziende più vecchie. Potrebbe anche esserci l'opportunità di sottrarre quote di mercato a un prodotto meno sicuro creando una versione molto sicura. 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, dove c'è molto margine di miglioramento.

Esclusione di responsabilità: Lavoro per una grande azienda che fa un buon lavoro in questo settore, ma la mia risposta è una mia opinione personale e non è indicativa della posizione o delle politiche del mio datore di lavoro.

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

  • Sicurezza della rete: Questa è la cosa più ovvia: se gli hacker cinesi ottengono le credenziali per entrare nei vostri sistemi interni, cercheranno il vostro codice sorgente (se non altro perché il codice sorgente dirà loro dove andare successivamente). Quindi la sicurezza informatica di base deve essere un "dato di fatto".
  • Controllo degli accessi: La vostra receptionist ha bisogno di accedere al vostro repository di codice? Probabilmente no. Limitate la vostra esposizione.
  • Siate selettivi nelle assunzioni e mantenete un ambiente di lavoro sano: Misure di DLP come la scansione delle e-mail in uscita sono interessanti in teoria, ma se il vostro ingegnere è abbastanza intelligente da essere utile per voi, è abbastanza intelligente da capire come aggirare le vostre misure di DLP. I vostri dipendenti non dovrebbero avere un motivo per far trapelare il vostro codice sorgente. Se lo fanno, avete fatto qualcosa di terribilmente, terribilmente sbagliato.
  • Monitorate la vostra rete: Si tratta di un'estensione della risposta "sicurezza della rete", ma con l'accento sulla prevenzione della perdita digitale. Se notate un improvviso picco nel traffico DNS, è possibile che il vostro codice sorgente venga esfiltrato da un aggressore. Ok, ora chiedetevi se fareste anche solo sapere se ci fosse un picco improvviso di traffico DNS dalla vostra rete. Probabilmente no.
  • Trattate i dispositivi mobili in modo diverso: I telefoni e i computer portatili si perdono davvero spesso. Vengono anche rubati davvero spesso. Non dovreste mai memorizzare informazioni sensibili (compresi codice sorgente, dati dei clienti e segreti commerciali) su dispositivi mobili. Davvero. Mai. Questo non significa che non si possano usare i dispositivi mobili per accedere e modificare il codice sorgente. Ma se un portatile viene smarrito, dovete essere in grado di revocare da remoto qualsiasi accesso ai dati sensibili. In genere ciò significa che il codice e i documenti vengono modificati "nel cloud" (vedi c9.io, koding.com, Google Docs, ecc.) con un'autenticazione adeguata e tutto il resto. Questo può essere fatto con o senza fiducia in una terza parte, a seconda di quanto lavoro si voglia fare. Se la vostra soluzione non supporta il fattore 2, allora scegliete un'altra soluzione; volete ridurre la vostra esposizione con questa misura, non aumentare l'esposizione.

In secondo luogo, come prevenire la modifica del codice dannoso; c'è davvero una sola risposta a questa domanda: il controllo delle modifiche.

Per ogni carattere di codice nel vostro repository, dovete sapere esattamente chi ha aggiunto (o cancellato) quel codice e quando. Questo è talmente facile da fare con la tecnologia di oggi che è quasi più difficile non avere un sistema di tracciamento delle modifiche. Se si usa Git o Mercurial o qualsiasi altro sistema di controllo dei sorgenti modestamente utilizzabile, si ottiene il tracciamento delle modifiche e ci si fa molto affidamento.

Ma per aumentare un po' l'affidabilità, aggiungerei che ogni modifica al vostro repository deve essere firmata da almeno un'altra persona oltre all'autore della modifica. Strumenti come Gerrit possono rendere questo semplice. Molti regimi di certificazione richiedono comunque revisioni del codice, quindi imporre tali revisioni al momento del checkin significa che i malintenzionati non possono agire da soli per inserire codice scadente nel vostro repository, aiuta a prevenire che codice scritto male venga committato e aiuta a garantire che almeno due persone comprendano ogni modifica inviata.

Saranno messe in atto misure per prevenire il accidentale inserimento di codice problematico, alias bug. Alcune di queste misure saranno utili anche contro l'inserimento deliberato di codice problematico.

  • Quando uno sviluppatore vuole fare il commit del codice nel repository, un altro sviluppatore deve esaminare la richiesta di merge. Forse il secondo sviluppatore dovrà spiegare al primo sviluppatore cosa fa il nuovo codice. Ciò significa esaminare ogni riga.
  • Se il codice appare confuso, potrebbe essere rifiutato come cattivo stile e non mantenibile.
  • Il codice ha test di unità e di integrazione automatizzati. Quando non c'è un test per una certa riga di codice, la gente si chiede. Quindi dovrebbe esserci un test per verificare che la backdoor funzioni, o una sorta di offuscamento.
  • Quando viene costruita 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 costruito e distribuito utilizzando script automatici. Questo non solo per la sicurezza, ma anche per semplificare il carico di lavoro.

Naturalmente queste misure si basano sull'onestà e sulla buona volontà di tutti i partecipanti. Qualcuno con accesso da amministratore al server di compilazione o al repository potrebbe creare molto scompiglio. D'altra parte, i programmatori comuni non hanno bisogno di questo tipo di accesso.

Vi invitiamo ad aggiungere valore ai nostri contenuti informativi contribuendo con la vostra esperienza nei riferimenti.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.