Domanda:
Come proteggere il mio codice dalle minacce "interne" quando assume il mio primo dipendente?
arao6
2020-06-29 04:41:27 UTC
view on stackexchange narkive permalink

Ho lasciato il lavoro per avviare il mio prodotto SaaS. Ora sto cercando di assumere il mio primo dipendente (un altro sviluppatore).

Prenderò le precauzioni legali appropriate per proteggere il mio IP, ma mi chiedo quali altre azioni ragionevoli posso intraprendere per proteggere ulteriormente il mio codice / dati. L'ultima cosa che voglio che accada è quello che è successo a Tesla, dove qualcuno ha scaricato il codice sorgente su iCloud e lo ha portato a un concorrente.

So che è praticamente impossibile impedire che ciò accada al 100% e che devo assicurarmi di assumere persone di qualità, offrire una paga significativa e far firmare i documenti legali appropriati. A parte questo, cos'altro posso fare per proteggermi dalle minacce interne? Sto investendo i risparmi della mia intera vita in questo e sarò devastato nel perdere ciò che ho passato la parte migliore di 2 anni a scrivere codice.

Ecco cosa ho pensato finora:

  • Acquista un laptop da lavoro per loro
  • Cripta il disco rigido (come con Bitlocker)
  • Disabilita tutte le porte USB
  • Crea un non amministratore / account utente limitato senza autorizzazioni di installazione e solo gli IDE (ad esempio Visual Studio) installati. Uso Windows 10 per la maggior parte dello sviluppo, ad eccezione di un Mac per la parte iOS dello sviluppo dell'app.
  • Installa qualche tipo di software di registrazione dei dipendenti.
  • Disabilita l'accesso ai siti Web di hosting di file .
  • In qualche modo rilevare e fermare quando una determinata cartella viene caricata o copiata da qualche parte?
  • Rendi in qualche modo il repository git accessibile solo da quella macchina.
  • Installa alcuni tipo di sistema di gestione amministrativa remota? Azure Active Directory o qualcosa del genere?

Questo deve essere un problema comune per le aziende, ma devo cercare la cosa sbagliata perché non riesco a trovare una guida da nessuna parte su questo problema.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/110231/discussion-on-question-by-arao6-how-to-protect-my-code-from-insider-threats-wh).
Nella mia carriera non ho mai avuto un datore di lavoro che cercasse di darmi accesso al loro codice sorgente, ma cercò anche di impedirmi di rubarlo.È praticamente impossibile e controproducente.
Undici risposte:
#1
+81
Anonymous
2020-06-29 06:50:08 UTC
view on stackexchange narkive permalink

Per la maggior parte questo non è un problema tecnico ma un problema umano. Quindi, sebbene la tecnologia abbia un ruolo da svolgere, ha dei limiti.

Se il dipendente lavorerà da casa, la supervisione è più difficile. Se monitorerai la sua attività, non vuoi violare le leggi sulla privacy applicabili.

Ovviamente il computer deve essere protetto, ma anche il resto dell'ambiente è importante. Se hai una LAN aziendale, dovrebbero esserci protezioni adeguate come un IDS / firewall. Ma l'attrezzatura è spesso inutile senza che qualcuno tenga d'occhio i log e gli avvisi.

Dato che hai menzionato Visual Studio, lo sviluppatore potrebbe aver bisogno di essere almeno un amministratore locale per lavorare in condizioni ottimali. Se paralizzi il loro ambiente, potrebbero essere tentati e persino costretti a trovare soluzioni alternative e annullare le tue misure di sicurezza, che è ciò che vuoi evitare.

Temo che tutti dobbiamo fidarci delle altre persone e correre dei rischi. Più controlli i tuoi dipendenti, più rendi loro evidente che non ti fidi di loro e li fai sentire inaffidabili. Ad un certo punto lo sforzo di sorveglianza diventa controproducente perché li frustri e demotivi. Possono diventare meno produttivi, meno fedeli.

Anche la formazione sulla sicurezza può essere utile. Il dipendente potrebbe essere onesto e agire in buona fede, ma vulnerabile all'ingegneria sociale e mettere inconsapevolmente a rischio l'azienda e le sue risorse. L'ingenuità può essere pericolosa quanto un intento dannoso. Direi che a molti sviluppatori manca la consapevolezza della sicurezza informatica.

Forse dovresti ordinare un test di penetrazione contro la tua azienda e imparare da esso. In questo modo la tua posizione di sicurezza migliorerà e sarai meglio equipaggiato per respingere gli attacchi.

I dipendenti sono spesso l'anello più debole, ma dovresti anche considerare la minaccia di hacker e concorrenti non etici. In altre parole, non concentrarti troppo sui tuoi dipendenti, ma sviluppa un approccio alla sicurezza a 360 ° per la tua azienda.

Anche la sicurezza fisica è importante. Un laptop perso non dovrebbe essere un grosso problema se il disco rigido è crittografato e ha una password complessa. Ma i tuoi backup dovrebbero essere in un posto sicuro. Considera il rischio di furto con scasso.

Sì, i backup sono estremamente importanti . Assicurati di avere un solido piano di backup in atto, testalo di volta in volta. Prepara un piano di ripristino di emergenza . Cosa succederebbe se il tuo ufficio bruciasse con tutta la tua attrezzatura informatica? È necessario proteggere il codice sorgente ma anche pianificare la continuità aziendale. Suggerimento: assicurazione.

Se possiedi una proprietà intellettuale di valore, potresti prendere in considerazione la richiesta di brevetti . Di nuovo, questo è il lavoro di un avvocato qui.

Probabilmente puoi trovare un ' assicurazione per coprire il rischio. La domanda è se vale la pena pagare per un rischio basso.

Vorrei anche offrire azioni o un po 'di partecipazione nella società. Allora i tuoi dipendenti hanno meno incentivi a diventare disonesti e sabotare la tua impresa.

Per riassumere: ci sono tanti rischi possibili, penso che tu stia dando troppa enfasi alla minaccia interna. È più probabile che tu venga violato , che licenziare qualcuno per cattiva condotta. I tuoi dipendenti devono essere tuoi alleati e considerati come tali, non come potenziali nemici.

"Vorrei anche offrire azioni o partecipazioni nella società. Quindi i tuoi dipendenti hanno meno incentivi a diventare disonesti e sabotare la tua impresa".Dai al dipendente un po 'di pelle nel gioco e sarà meglio di qualsiasi soluzione tecnologica per impedirgli di diventare un ladro.
#2
+66
Douwe
2020-06-29 13:10:00 UTC
view on stackexchange narkive permalink

Non farlo:

Crea un account utente non amministratore / con limitazioni senza autorizzazioni di installazione e solo gli IDE (ad esempio Visual Studio) installati.

Disabilitare l'accesso ai siti web di file hosting.

Installare un qualche tipo di sistema di gestione amministrativa remota? Azure Active Directory o qualcosa del genere?

Molti sviluppatori, me compreso, non lavoreranno per te su questa macchina a meno che tu non sia disposto a fare in modo che ne valga la pena. Offrirà poca sicurezza, ma sarà incredibilmente frustrante lavorarci.

Ecco una semplice regola pratica:

Uno sviluppatore maligno sarà in grado di penetrare a qualsiasi cosa (dati, codice sorgente, rete) utilizzata dal prodotto su cui stanno lavorando. Inoltre violeranno il laptop che gli hai dato. Pertanto, proteggere e proteggere il tuo IP in questo contesto non è una questione tecnica, è una questione organizzativa .

Devo assicurarmi di assumere persone di qualità, offrire una retribuzione significativa e far firmare i documenti legali appropriati.

Questa è la tua risposta.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/110060/discussion-on-answer-by-douwe-how-to-protect-my-code-from-insider-threats-quando).
Praticamente come i giochi con DRM odioso: danneggiano i consumatori legittimi, ma quelli che vogliono semplicemente decifrarlo e scaricarlo gratuitamente riusciranno comunque a farlo.
Se un'azienda si rifiuta di concedermi l'accesso come amministratore locale al mio dev box, è probabile che stia cercando un altro lavoro.Non è certo perché in rare occasioni l'azienda sa cosa sta facendo ed è facile chiedere aiuto a un tecnico IT nelle rare occasioni in cui non hanno già impostato qualcosa di cui ho bisogno.Ma la maggior parte delle volte vedo accesso locale limitato solo nelle aziende in cui il personale IT non sa di cosa ho bisogno e ogni volta che ho bisogno di privilegi elevati devo sprecare il mio tempo, il tempo dell'IT e probabilmente il tempo di due manager per ottenere l'approvazionee poi fallo.Non ne vale la pena.
#3
+18
pjc50
2020-06-30 13:10:50 UTC
view on stackexchange narkive permalink

L'ultima cosa che voglio che accada è quello che è successo a Tesla, quando qualcuno ha scaricato il codice sorgente su iCloud e lo ha portato a un concorrente.

E poi Tesla fallito e non se ne è mai sentito parlare? O Valve dopo la fuga di Half-Life?

O, in realtà, il semplice codice sorgente non è poi così prezioso. In genere è un problema integrarsi con altri progetti, quindi a meno che qualcuno non voglia clonare completamente l'attività (il che è molto ovvio e può essere risolto con un'azione legale), avere una copia della tua fonte è molto meno utile di quanto pensi.

La cosa importante da proteggere sono le credenziali e i dati dei clienti . Proteggi i server live, accedi ad essi e qualsiasi account AWS o simile. È molto più probabile che un hacker su AWS distrugga l'azienda rispetto a una fuga di codice sorgente. Anche il mancato controllo accidentale dei costi su AWS potrebbe distruggerti. La fuga di dati dei clienti può esporti a responsabilità del GDPR.

L'autenticazione a due fattori è probabilmente una base ragionevole. Questo può essere integrato con Active Directory quando lo ottieni (non lo consiglio al di sotto dei 10 dipendenti).

Per sistemi particolarmente sensibili, con aree di "test", "staging" e "produzione" separate in cui solo tu (o i dipendenti autorizzati) avete accesso alla "produzione" e solo la produzione ha i dati reali dei clienti, è una buona idea.

Per apprezzare davvero la verità di questa risposta, prova a valutare cosa sarebbe necessario per avviare una linea di business dopo aver acquistato l'IP di un'azienda dalla loro banca / creditori / ecc.Se tutto ciò che hai è il codice e non le persone che lo capiscono, è un'impresa enorme.E se assumi un gruppo di persone per fare qualcosa di palesemente illegale, le probabilità che uno se ne accorga alla fine sei ... non basso.Il rischio / ricompensa semplicemente non c'è.
In realtà, ho visto alcune aziende in cui il modo migliore per eliminare un concorrente potrebbe essere convincerlo a provare a utilizzare il tuo codice sorgente.
@cjs Ha molto senso ... Potresti non aver pensato ad angular.js quando hai scritto questo, ma comunque: se vuoi scrivere un gmail-killer, pensa a _why_ google ti suggerisce di usare angular per quello :)
@Douwe Certamente non stavo pensando a angular.js, perché ci provo molto non dovevo pensarci.:-)
#4
+17
mentallurg
2020-06-29 06:08:42 UTC
view on stackexchange narkive permalink

Per prima cosa ti suggerisco di stimare il valore reale del software che svilupperai. È davvero la risorsa più preziosa che avrai? Quanto ti costerebbe se qualcuno ottenesse il codice sorgente?

Pensa a Facebook o Linkedin. Non erano i primi nel loro campo. E il loro software non era la risorsa più preziosa (sì, hanno sviluppato e successivamente open source Bootstrap, React, Kafka, Samza, per citarne alcuni).

Dopo aver stimato i rischi e i costi nel caso qualcuno ottenere il codice, stimare quanti soldi puoi investire per proteggerlo.

Ecco solo alcuni punti da considerare:

  1. Un compito sarebbe sapere cosa è esattamente inviato dal computer a Internet. La maggior parte dei siti utilizza HTTPS. Non puoi decodificarlo. Un'opzione potrebbe essere quella di forzare tutte le connessioni a utilizzare la tua VPN, forzare l'installazione dei certificati CA e tom implementare man-in-the-middle. Un'altra opzione potrebbe essere quella di utilizzare alcuni software spia sul computer.
  2. Un altro compito potrebbe essere quello di classificare i dati inviati a Internet. Se viene utilizzata una certa crittografia o offuscamento, può essere molto difficile prevenirlo.
  3. L'implementazione tecnica può essere molto complicata. Uno sviluppatore, per svolgere il suo lavoro quotidiano, potrebbe aver bisogno di diversi messenger, diversi browser, e-mail. Avresti bisogno di controllare tutto.
  4. Anche se avessi questi strumenti, è comunque possibile creare immagini dello schermo con i contenuti delle classi più importanti, file di configurazione, ecc.

Prevenire le perdite tramite la connessione Internet può essere piuttosto costoso e solo poche aziende possono permetterselo.

Considerando questo, disabilitare l'USB non aiuta molto. Il vantaggio principale della disabilitazione dell'USB può essere quello di impedire che il laptop venga infettato da codice dannoso tramite USB.

La crittografia non costa nulla e ha senso. Se lo sviluppatore è fedele e non distribuisce il codice, la crittografia può essere utile in caso di furto o smarrimento del laptop.

Il primo paragrafo è il più importante (e in questo momento non vedo lo stesso pensiero in altre risposte).È improbabile che il tuo codice sorgente, scaricato direttamente da GitHub, sia dove si trova il valore della tua attività.Molto probabilmente il valore della tua azienda sta nel mantenere felici i clienti comprendendo e soddisfacendo le loro esigenze, inclusi servizi di presa in mano e altri servizi, soddisfacendo gli SLA operativi per la disponibilità e le prestazioni e mantenendo i loro dati in modo sicuro.Molto probabilmente il tuo codice, scaricato da un repository github pubblico, non darà nulla al tuo concorrente nei confronti di nessuno di questi.
@davidak In un certo senso sono d'accordo, tranne per il fatto che una base di codice sicura e ben scritta non è la maggioranza del rispetto degli SLA operativi e del mantenimento della sicurezza dei dati?E rende più facile fornire altri servizi, offrire la possibilità di stringersi la mano e / o essere in sintonia con le esigenze di un'azienda.Solo perché un'azienda non dovrebbe aspettarsi che la base di codice fornisca valore ai propri clienti, non significa che non sarebbe sostanzialmente più facile per un concorrente offrire lo stesso valore con l'accesso al proprio codice sorgente.
@TCooper Questo presuppone che l'unico modo (o il modo più semplice, con un margine significativo) per i concorrenti di OP di ottenere una base di codice sicura e ben scritta, sia rubarla da OP.Questo a sua volta presuppone che i concorrenti di OP sappiano chi è e che il suo codice base sia scritto abbastanza bene da valere la pena rubarlo.Potrei uscire e rubare una bella macchina se volessi, ma dato che ho i soldi, acquistarne una legalmente sembra molto più facile.Se il concorrente sapesse di volere così tanto il codice di OP, potrebbe semplicemente comprarlo.In qualche modo dubito che il suo prezzo sarebbe così eccessivo, su scala aziendale.
@Steve-O Se si tratta di un unico avvio SaaS, potrebbe esserlo molto bene.E questo riguarda più la preoccupazione di un dipendente interno che ruba il codice e crea un concorrente, non un'entità esterna.Non vedo nemmeno il tuo punto di vista / la relazione della tua analogia con la macchina.Ancora una volta, parlando di un dipendente assunto dalla start up, non di una grande azienda.
Che cos'è "smb" in questo contesto?Se è "qualcuno", scrivilo per favore.
#5
+12
mjt
2020-06-30 00:10:54 UTC
view on stackexchange narkive permalink

Una volta ho sostenuto un colloquio di lavoro presso una società di compravendita di oggetti di scena che era preoccupata per i rischi interni. Le mitigazioni che hanno utilizzato sono state:

  • Tutto il lavoro svolto in sede
  • Nessun bagaglio, telefono o fotocamera consentito negli uffici
  • Nessuna posta elettronica
  • Rete aziendale non connessa a Internet
  • Nessun computer portatile, solo thin client
  • Tutti i thin client in armadi chiusi a chiave, accessibili solo tramite mouse e tastiera su schermo
  • Nessun accesso amministrativo locale
  • Regola solo software approvata applicata rigorosamente.
  • Metal detector e guardia ad ogni ingresso
  • No out-of -ore di lavoro consentite

Non ho accettato il lavoro perché pensavo di subire un grosso calo di produttività da tutte quelle restrizioni. Ma sono riusciti ad assumere un bel po 'di persone, perché offrivano una retribuzione eccezionalmente alta.

Queste attenuazioni sono prevedibili negli appalti per la difesa e in altri ambienti di alto profilo e ad alto rischio.Per OP assumere il suo primo dipendente anche se potrebbe essere eccessivo.
Mi sembra più una prigione, nemmeno la paga più alta mi assumerebbe con condizioni di lavoro così pazze, fanculo.
Hanno mai fatto notizia per aver subito una violazione?No?Quindi, anche se sembra eccessivo, probabilmente l'obiettivo è raggiunto.
@Criggie In realtà lo hanno fatto - o almeno, la loro risposta ha fatto notizia.È stato prima che intervistassi lì e potrei spiegare perché avevano così tante restrizioni.Dovrò essere timido riguardo al nome dell'azienda, dato che non ricordo la data di scadenza per l'intervista NDA.
#6
+10
John Zhau
2020-06-29 12:38:45 UTC
view on stackexchange narkive permalink

Suddividiamolo in 3 sezioni: Digitale, Fisico e Umano

Digitale

Suggerirei di fornire loro un computer aziendale, indipendentemente dal fatto che stiano lavorando o fuori sede. Ciò ti consentirà di limitare e monitorare alcune delle loro attività. Tuttavia, non andare così lontano da installare un keylogger. Nessuno vuole un keylogger sul proprio sistema, anche se si tratta di un PC aziendale. Dovranno utilizzare login con password, che non vanno bene con i keylogger.

La maggior parte del monitoraggio dovrebbe essere sul lato server. Monitorare il traffico da e verso il server. Le attività dovrebbero essere registrate, indipendentemente dal fatto che siano o meno un dipendente, se tenta di interagire con il tuo server. Puoi arrivare fino al logging di ogni singola richiesta (cosa non così insolita, credo), o semplicemente loggando cose che interagiscono con le parti importanti del tuo sistema come l'accesso diretto al database.

Il traffico normale può indicano attività dannose. Ad esempio, se vedi 1 GB di dati in uscita, potresti voler controllare che sia solo il tuo dipendente che recupera alcuni dati per lavoro o qualcuno che cerca di esportare i tuoi dati. Vedere 500 GB di flusso di dati da / a un singolo IP dovrebbe essere una bandiera rossa immediata.

Qualsiasi lavoro amministrativo deve essere svolto dalla rete interna. Ciò significa che dovrebbero essere dall'interno anche per vedere il tuo portale di amministrazione. Se vuoi consentire loro di lavorare da remoto, ti suggerisco di configurare una VPN per consentire ai tuoi dipendenti di connettersi alla tua rete interna da remoto.

Fisica

Lì sono due cose principali a cui devi prestare attenzione: l'accesso all'ufficio fisico e al computer di lavoro. Parlerò solo del computer aziendale.

Beh, in realtà, non c'è molto che puoi fare quando hanno il computer fisico nelle loro mani. Il meglio che puoi fare sarebbe probabilmente mettere dei sigilli sul computer, in modo tale che qualsiasi tentativo di aprire l'hardware del computer sia visibile a te o almeno rilevato da un professionista forense.

Questo è legge 3 sulla sicurezza:

Se un malintenzionato ha accesso fisico illimitato al tuo computer, non è più il tuo computer

Umano

Questo è il fattore principale qui. Come menzionato da @Anonymous, questo è principalmente un problema umano.

Prima di tutto, assumi qualcuno di cui ti puoi fidare . Abbiamo dei penetration tester che cercano di entrare nei sistemi tutto il tempo di proposito. Uno dei motivi principali per cui sono autorizzati a farlo è perché hanno poche ragioni per fare cose cattive al tuo sistema. Per qualificarci, dobbiamo essere accuratamente controllati dalla società che assume. La fiducia e l'interesse sono le cose principali che impediscono alle persone con accesso al tuo sistema di fare danni intenzionalmente .

Notare che ho detto intenzionalmente . Le minacce interne non sono sempre intenzionalmente dannose. Le chiavi TSA sono trapelate no perché qualcuno voleva fare del male, ma a causa di errori da parte di interni e di terze parti. Un dipendente non addestrato può facilmente cancellare l'intero database per errore con un solo comando. I dipendenti non addestrati sono spesso vulnerabili agli attacchi di ingegneria sociale e possono far entrare un estraneo quando non dovrebbero.

Per evitare tali problemi, devi formare i tuoi dipendenti sia sull'amministrazione del sistema che sulla sicurezza. La formazione aiuterà con piccoli incidenti, ma solo un controllo approfondito può impedire agli attori malintenzionati di diventare parte della tua azienda.

Ora per affrontare le tue idee suggerite

Acquista un laptop di lavoro per loro

Buona idea

Crittografa il disco rigido (come con Bitlocker)

Questo proteggerà dati a riposo . Ottima idea, ma non sarà di grande aiuto contro un dipendente con accesso al computer e password.

Disabilita tutte le porte USB

Usiamo le porte USB tutto il tempo . Mouse USB, tastiere, webcam, ecc. Questo sarà anche il mezzo principale per trasportare comodamente i dati per la maggior parte delle persone. Invece di disabilitarli tutti, usa un software per avvisare l'utente ogni volta che viene collegato un dispositivo USB. Dovrai anche istruire i tuoi dipendenti a non collegare al computer di lavoro alcune USB casuali che hanno trovato per strada. Il massimo che puoi realisticamente fare è addestrare e inserire nella whitelist i loro dispositivi USB in modo che solo i dispositivi registrati possano connettersi al computer.

Crea un account utente non amministratore / con limitazioni senza autorizzazioni di installazione e solo il IDE (ad esempio Visual Studio) installati. Uso Windows 10 per la maggior parte dello sviluppo, ad eccezione di un Mac per la parte iOS dello sviluppo dell'app.

Anche in questo caso, la preferenza del software è personale. Questa sarà interamente una tua scelta per limitare le loro prestazioni lavorative se non consenti loro di utilizzare i loro strumenti preferiti. Si consigliano account non amministrativi limitati, anche se dovrai gestire da solo l'installazione degli strumenti.

Installa un qualche tipo di software di registrazione dei dipendenti.

La maggior parte dovrebbe essere sul lato server anziché sul computer del dipendente. La registrazione delle loro attività locali renderà più facile monitorarli e citarli in giudizio per attività dannose, ma fai attenzione a non andare troppo lontano. Ai bambini non piace che i loro genitori guardino tutto ciò che fanno, e nemmeno i tuoi dipendenti. La registrazione lato server non dovrebbe metterli a disagio, quindi è un ottimo modo per monitorare.

Disabilita l'accesso ai siti Web di hosting di file.

Potrebbe essere difficile da fare, ma non sono sicuro di come puoi farlo da solo.

Anche se puoi farlo, potrebbero aver bisogno di accedere alle loro unità personali per alcuni lavori, ma è una tua scelta restrittiva .

In qualche modo rilevare e fermare quando una determinata cartella viene caricata o copiata da qualche parte?

Monitora il traffico da e verso il tuo server. È loro la scelta di copiare i file su una chiavetta USB e caricarli altrove. Puoi monitorare solo per rilevare traffico insolito / sospetto dal / al tuo server.

In qualche modo rendi il repository git accessibile solo da quella macchina.

Usa un VPN per questo, così come per tutti i tuoi portali amministrativi.

Installare una sorta di sistema di gestione amministrativa remota? Azure Active Directory o qualcosa del genere?

Uso principalmente Linux, quindi non sono esperto su Windows, ma Active Directory dovrebbe essere accessibile solo dalla rete interna. Ancora una volta, utilizza una VPN per l'accesso remoto.

_Questa sarà interamente una tua scelta per limitare le loro prestazioni lavorative se non consenti loro di utilizzare i loro strumenti preferiti._ Tieni presente che costringere gli sviluppatori a utilizzare strumenti che non gli piacciono non è _solo_ un successo per la produttività e altrimenti è gratuito.Può anche (a seconda dello sviluppatore) renderla frustrata, il che paradossalmente potrebbe avere l'effetto diretto di incoraggiare i dipendenti a aggirare le tue politiche di sicurezza.
"* usa il software per avvisare l'utente ogni volta che viene collegato un dispositivo USB *" dialoghi di conferma in cui la risposta è la stessa quasi il 100% delle volte, istruisci l'utente a fare clic su "ok" senza pensarci.Probabilmente peggiorano la sicurezza perché l'utente non sta pensando alla sicurezza, stanno pensando a quanto sia fastidioso il popup di conferma.Una richiesta quando viene collegato un dispositivo USB * non riconosciuto * è più utile con le opzioni Consenti una volta, Consenti sempre, Non consentire e Non consentire sempre.
@Schwern Hai ragione.Di solito è meglio avere un elenco di dispositivi consentiti invece di chiedere ogni volta.
#7
+6
cjs
2020-06-30 04:39:34 UTC
view on stackexchange narkive permalink

Il tuo obiettivo sembra essere quello di proteggerti dagli insider avversari, ovvero coloro che stanno consapevolmente e deliberatamente cercando di violare la tua sicurezza.

Come altri hanno sottolineato, probabilmente non è pratico avere una protezione significativa contro gli attacchi deliberati tramite mezzi tecnici. La risposta eccellente di mjt fornisce un tipico insieme di restrizioni, ma anche queste non possono impedire alle persone di estrarre informazioni dalla loro testa. E come altri hanno sottolineato, questi hanno un grande impatto negativo sulla produttività. In particolare, vietare completamente l'accesso a Internet dalle macchine di sviluppo rischia di essere problematico in questo giorno ed età. (Probabilmente vorresti almeno fornire una seconda macchina "air-gap" connessa a Internet in modo che le persone possano cercare documentazione e simili, anche se questo ora ti espone a qualcuno che legge il codice dal sistema sicuro e lo digita sul sistema non sicuro .)

Tuttavia, quando si esaminano le misure tecniche di sicurezza interne, ciò su cui si vuole concentrarsi è mitigare il rischio di violazioni involontarie della sicurezza . Questi sono molto più comuni degli attacchi deliberati e molto più facilmente prevenibili.

La parte più importante dell'approccio per farlo, e quello che molte aziende sbagliano, è rendere più facile per il sviluppatori per fare in modo sicuro ciò che vogliono . Spesso tecnicamente questo non è troppo difficile e la maggior parte del lavoro è nel supporto e nella formazione.

Aspetti importanti di questo approccio sono:

  1. Sii disposto a prendere brevi risultati di produttività a lungo termine per eseguire correzioni di formazione e sicurezza. Ad esempio, se hai una politica secondo la quale le chiavi SH degli sviluppatori devono rimanere solo sul sistema a cui accedono e lo sviluppatore ha difficoltà con ssh-agent, assicurati di essere chiaro sia nelle parole che nelle azioni che farla funzionare senza problemi e correttamente con ssh-agent è una priorità più alta rispetto a ottenere la funzione Xdone.

  2. Quando uno sviluppatore dice di voler fare X, lavora immediatamente con lei per capire cosa vuole ottenere e un modo per farlo in modo sicuro e facilmente . Vuoi che lo sviluppatore se ne vada felice di avere una buona soluzione a questo problema, piuttosto che cercare soluzioni alternative perché trova che la soluzione che hai offerto sia scomoda o, peggio ancora, viene penalizzata per una minore produttività quando cerca di lavorare in sicurezza.

  3. Assicurati di essere in grado di fornire formazione e supporto immediato per svolgere il lavoro nell'ambito delle tue politiche di sicurezza. Se uno sviluppatore ha problemi a trasferire il file X al sistema Y mentre segue le tue politiche, devi mostrarle subito il tuo modo semplice e sicuro per farlo, piuttosto che lasciarla frustrata e cercare altri modi per farlo.

  4. Segui le tue politiche di sicurezza e risolvi i problemi segnalati dagli sviluppatori. Se hai una politica secondo cui non dovresti mai spostare dati sensibili su HTTP e uno sviluppatore sottolinea che ha provato a utilizzare un sistema interno che pensava dovesse utilizzare HTTPS ma non lo era, risolvilo immediatamente piuttosto che dirle solo di ignorare il problema. Se fai quest'ultimo, impareranno che ignorare le cose che sembrano sbagliate è la cosa giusta da fare. Se le politiche aziendali dicono il contrario, impareranno che ignorare le politiche aziendali è la cosa corretta da fare in alcune circostanze.

In breve, non è necessario solo impostare la sicurezza- sistemi e politiche consapevoli e parlarne agli sviluppatori, ma dimostrare che sono importanti per te a) essere disposti a impegnarti per rendere le cose facili e in sicurezza eb) dare loro la priorità rispetto al completamento delle funzioni Se lo fai bene non ti rallenterà a lungo termine, ma se le tue azioni non corrispondono alle tue parole in quest'area, i tuoi sistemi di sicurezza e le tue politiche saranno un costo con poco beneficio.

#8
+4
Zsolt Szilagy
2020-06-30 13:49:46 UTC
view on stackexchange narkive permalink

Ok, giochiamo: voglio rubare il tuo codice.

Collego i dispositivi, non funziona niente. Quindi creo alcuni file zip e li spedisco a casa. No, hai bloccato tutti i client web di posta? Ok, quindi vado su ftp / ssh / qualunque cosa. Hai bloccato anche quelli? Quindi lo carico su un sito web. Ne hai bloccati migliaia? In qualità di sviluppatore possiedo comunque alcuni domini, quindi lo carico su uno di essi. Quelli che puoi fermare non vuoi assumerli.

Ecco una soluzione: dai loro l'accesso su una necessità di conoscere le basi. Lascia che ogni sviluppatore lavori solo su una parte del tuo progetto e nessuno ha il codice completo. Crea più repository e le parti che sono di alto valore e con poche modifiche entrano in uno limitato. Puoi ancora condividere la documentazione per l'API.

Non conosco il tuo campo di lavoro, ma nella maggior parte dei progetti SaaS, il segreto non è come fai qualcosa - è principalmente dritto in avanti. Ciò che vuoi proteggere è il tuo vantaggio rispetto alla concorrenza, in quanto avrebbero bisogno di mettere il lavoro che già hai. Quindi, anche se sanno come funzionano le tue cose (o come potrebbero farlo funzionare comunque), avere loro da sviluppare invece di copiare è tutto ciò di cui hai bisogno.

"Lascia che ogni sviluppatore lavori solo su una parte del tuo progetto e nessuno ha il codice completo".Questi sono i livelli di sicurezza del progetto Manhattan e richiedono i livelli di risorse del progetto Manhattan.OP sta assumendo il loro primo dipendente .. è un po 'troppo, non credi?
"Quelli che puoi fermare non vuoi assumere."=> Mi piace ed è vero, uno sviluppatore competente troverebbe un modo.
@Douwe che dipende da come è costruito il sistema.Molti sistemi moderni sono comunque suddivisi in diversi repository, quindi è solo questione di assegnare il lavoro a quelli meno sensibili e non concedere l'accesso agli altri repository in tal caso.Mi piace questa idea in quanto dà allo sviluppatore tutta la libertà su come lavorare sulle cose su cui ha bisogno di lavorare senza doversi preoccupare di quelle altre parti che non sono loro responsabilità.È una vittoria per tutti nel mio libro, se fatto bene.Richiede molto meno sforzo rispetto allo spegnimento della macchina dello sviluppatore e alla cura di tutte le attività di amministrazione su di essa.Si adatta anche meglio.
@FrankHopkins Sono tutto per (micro) architetture di servizio, tuttavia quando ci sono solo 2 sviluppatori in un team, non vedo davvero questo lavoro in pratica.L'unico problema del punto di errore di _non_ lasciare che l'altro sviluppatore abbia accesso è peggio imho.E siamo onesti, in pratica questi piccoli team sono più simili a un matrimonio che a una grande azienda con una complessa strategia di sicurezza.Il tuo principale vantaggio come piccolo negozio è che ti mancano le spese generali e la burocrazia che ostacolano i grandi ragazzi.Le startup (dovrebbero) funzionare in modo diverso.
@Douwe Ho diversi repository per pezzi diversi anche per i miei progetti privati su cui lavoro da solo.Non sto dicendo che abbiano bisogno di un'architettura di microservizi e sicuramente per alcuni tipi di progetti potrebbe non adattarsi, ma non è così difficile spostare alcuni elementi essenziali in una libreria separata se lo desideri e non vedo alcun grande amministratore oimpatto sulla convenienza - tranne per il fatto che OP non riceverà aiuto per la codifica sui repo che mette da parte.
#9
+2
nbroeking
2020-07-02 08:55:40 UTC
view on stackexchange narkive permalink

Sono sorpreso di non aver visto la risposta utilizzata dalla maggior parte delle start-up.

Dare equità ai dipendenti. Rendili comproprietari, non deve essere 50-50 anni, ma offri loro un incentivo per far sì che l'azienda abbia successo. Molte start-up lo fanno con azioni o partecipazione agli utili, ecc.

Invece di cercare di limitarle. Garantisco che se dai ai tuoi dipendenti la promessa di un profitto del 10% (supponendo che questo sia significativo) e dai loro un laptop aperto senza restrizioni che lavoreranno davvero duramente per assicurarsi che l'attività abbia successo.

Fonte: I hanno lavorato in piccole start up e grandi aziende tecnologiche. Posso garantirti che nessuno di loro ha limitato i laptop come hai menzionato e quelli che non hanno assunto talenti ingegneristici di alto livello.

#10
+1
John Lally
2020-07-02 20:48:09 UTC
view on stackexchange narkive permalink

Ci sono due possibilità qui: assumere qualcuno di fiducia o assumere qualcuno inaffidabile. Se vuoi qualcuno affidabile, il lavoro deve essere attraente per qualcuno affidabile e le condizioni di lavoro del lavoro devono essere tali da mantenere il dipendente affidabile.

Se assumi qualcuno inaffidabile, lo faranno fare quello che vogliono indipendentemente dai passi che fai. Saranno sempre in vendita al miglior offerente.

Se blocchi le cose per assicurarti che chiunque assumi sarà frustrato in ogni momento, stai rendendo difficile per il dipendente affidabile svolgere il proprio lavoro e allo stesso tempo inviando il messaggio non ti fidi di loro. È probabile che il dipendente affidabile sia meno orientato al denaro e più orientato a svolgere un lavoro di qualità, ma vorrà un ambiente di lavoro di qualità. La mancanza di fiducia non crea un ambiente di lavoro di qualità, né il dover programmare su una macchina molto bloccata.

Abbandona le soluzioni tecniche e concentrati sul rendere le condizioni di lavoro e l'ambiente di lavoro attraenti per il dipendente affidabile.

#11
+1
The_Moth
2020-07-08 12:21:58 UTC
view on stackexchange narkive permalink

Risposta un po 'meschina, ma pensaci in questo modo. Se vogliono davvero rubare il tuo codice, potrebbero semplicemente scattare foto dello schermo. Pertanto, ti consiglierei di bloccare la luminosità dello schermo allo 0% in modo che non possano vedere su cosa stanno lavorando.

... Oppure potresti voler assicurarti che non abbiano un incentivo a rubarti, come prenderti cura dei tuoi dipendenti e trattarli come amici. Prima o poi, quando la tua azienda diventerà abbastanza grande, dovrai fidarti di molte persone, come le finanze, il reparto IT. È meglio abituarsi a fidarsi delle persone prima, piuttosto che dopo.

Per aggiungere a questo, se qualcuno con una conoscenza sufficiente vuole ottenere il tuo codice, lo farà. Non c'è quasi modo di fermarlo. Ciò che è molto più probabile che accada è un attacco esterno tramite ingegneria sociale o un hack diretto. Gli attacchi interni sono troppo pericolosi (in termini legali e finanziari) e richiedono molto tempo nella maggior parte dei casi. Se hai appena iniziato come azienda, la tua protezione legale dovrebbe fermare un simile attacco. Un caso diverso è la tua azienda da un miliardo di dollari, ma non sembri ancora un'azienda da miliardi di dollari, quindi probabilmente non è l'unica cosa di cui devi preoccuparti di più.

Le protezioni legali sono meno efficaci nelle aziende che hanno appena iniziato.Le perdite di proprietà intellettuale chiudono l'azienda anche con protezioni legali.Certo, potresti fare causa, ma non avrai più un'azienda quando qualcun altro arriverà sul mercato prima di te con il tuo prodotto.Le finanze e l'informatica non sono i "gioielli della corona" di un'azienda.Sì, devi fidarti delle persone che si occupano di queste cose, ma è molto più difficile affondare completamente un'azienda in quelle aree.E le protezioni legali sono più facili in quelle altre aree.IP *** è *** la tua azienda."Solo fidarsi" di uno sconosciuto con esso è un problema.
@schroeder Non sono del tutto d'accordo.Nelle finanze è abbastanza comune per le aziende più piccole avere solo una, forse due persone, senza supervisione.Ciò lascia aperta la possibilità per dette persone di sifonare denaro senza che nessuno lo sappia.Ma per arrivare alla protezione legale.Se op è davvero una società SaaS individuale, dubito che ci saranno una moltitudine di competizioni che si infiltreranno nella sua attività e ruberanno i suoi dati (penso a breve termine).Quando assumi un nuovo dipendente, assicurati che non sia il proprietario della propria attività SaaS o che abbia lavorato recentemente per un'altra piccola azienda SaaS.
"sifone denaro" non "chiuderà l'azienda" e tale situazione è recuperabile.Entrambi sono punti che ho menzionato sopra.
La tua risposta è "fai amicizia e fidati delle persone - le protezioni legali si occupano del resto".Per una piccola azienda che sta cercando di andare sul mercato, questo consiglio non è efficace e ingenuo.Inoltre, non stai dicendo niente di più di molte altre risposte, ma con consigli supplementari molto migliori.
@schroeder In nessun modo voglio implicare che op dovrebbe fidarsi di uno sconosciuto, op ha sicuramente bisogno di un'adeguata protezione legale e simili, ma non penso che questo livello di paranoia sia affatto utile in una nuova attività.Una nuova impresa è un rischio e va trattata come tale, non si hanno mai garanzie nella vita.Se pensi che tutti intorno a te vogliano prenderti, non andrai da nessuna parte.
C'è una differenza molto grande tra "paranoia" e "due diligence" e le protezioni fondamentali.Trovare un equilibrio è la chiave, ma nella tua risposta stai sostenendo di ignorare l'equilibrio e spostare le cose in una direzione estrema.Stai reagendo al suggerimento dell'OP, ma considerando la realtà.
Sono completamente d'accordo, c'è davvero bisogno di alcune protezioni di base, ma ciò che sta suggerendo l'op è ben oltre.Stavo cercando di evidenziare l'altro approccio possibile e forse migliore.Ma ammetterò completamente che suona come se stessi sostenendo di ignorare tutte le precauzioni di base.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...