Sviluppo e produzione separati

È pratica normale concedere agli sviluppatori i diritti di amministratore / root locale sulla loro workstation. Tuttavia, gli sviluppatori dovrebbero avere accesso solo agli ambienti di sviluppo e non avere mai accesso ai dati in tempo reale. Gli amministratori di sistema, che hanno accesso alla produzione, dovrebbero disporre di workstation molto più controllate. Idealmente, le workstation sys-admin non dovrebbero avere accesso a Internet, sebbene ciò sia raro nella pratica.

Una variazione che ho visto è che gli sviluppatori hanno una build aziendale bloccata, ma possono fare quello che vogliono all'interno di virtual macchine. Tuttavia, questo può essere fastidioso per gli sviluppatori, poiché le VM hanno prestazioni ridotte e i vantaggi in termini di sicurezza non sono così grandi. Quindi è più comune vedere sviluppatori semplicemente avere pieno accesso alla propria workstation.

Quindi questa risposta viene dal punto di vista di uno sviluppatore. Tienilo a mente.

Primo, non avere i diritti di "amministratore locale" sulla mia macchina è un segno che dovrei cercare un lavoro altrove. È quasi impossibile scrivere codice, armeggiare con cose e mantenere una toolchain se devi chiedere il permesso ogni volta che devi aggiornare (o testare) una nuova dipendenza o uno strumento. Quindi, ecco i livelli di autorizzazione che richiedo . Tieni presente che di solito sono piuttosto in alto sulla scala per così dire.

• Amministratore totale e completo sulla mia macchina locale
• Amministratore totale e completo su tutto l'hardware di sviluppo e test
• Un certo livello di accesso amministrativo alla produzione server (questo diventa complicato, non ho bisogno o voglio tutto, ma ho bisogno di abbastanza per diagnosticare e risolvere i problemi che si verificano in produzione, e abbastanza per distribuire effettivamente il codice (supponendo che io sia quello che deve supervisionare la distribuzione del codice). Di solito questo livello di accesso si evolve nel tempo, ma inizia con i file di log.

Meno di quello e puoi trovare un nuovo sviluppatore.

Detto questo, lì è un grande rischio connesso a quel livello di accesso. Quindi quello che normalmente consiglio è una rete separata. Metti tutte le "cose" di sviluppo nella sua rete. Il suo AD, il suo file hosting, tutto suo e non lasciare mai parla con la rete di produzione. (Ma lascialo uscire su Internet)

Sì, questo significa hardware duplicato (o VPS) ma ne hai comunque bisogno per i test. Sì, significa un po 'più di overh ead durante l'aggiornamento o l'amministrazione, ma di nuovo, è necessario per i test. Hai anche bisogno di un posto dove vedere "Cosa succede al software X se aggiorno il server AD?" Guarda che hai un'intera rete di macchine di prova pronte per quel tipo di prova.

Quello che ho implementato con successo (con l'aiuto di un buon team IT) è una VLAN separata per tutte le "cose" di sviluppo e un singolo host VPS a cui lo sviluppatore ha pieno accesso, per fare ciò che vuole. Su quell'host c'è un server AD configurato dall'IT per assomigliare a una versione più piccola del server AD dell'azienda. Quindi una serie di documenti e linee guida per ciò che, ad esempio, un server web dovrebbe eseguire. Cosa dovrebbe funzionare un server DNS, cosa dovrebbe funzionare un server xyz. Quindi, parte dello "sviluppo" è installare e configurare quei VPS per il nostro uso. Tutto su quella VLAN è totalmente isolato dalla produzione e considerato esterno all'azienda. Infine viene creata una serie di "punch through" per le risorse a cui avevamo bisogno di accedere (come la posta elettronica). Normalmente questo veniva gestito come se fossimo esterni e l'elenco di questi strumenti era molto piccolo.

Dal punto di vista di uno sviluppatore:

Il tuo compito è prevenire il cambiamento (bug noti e vulnerabilità sono meglio di sconosciuti, giusto?), ma il mio è cambiare le cose. Questo ci mette in un vicolo cieco. Il mio lavoro è creare / cambiare le cose. Se la tua politica lo impedisce, allora, come qualsiasi altro ostacolo, una parte del mio lavoro è trovare un modo per aggirarlo.

Quale pensi sia più un pericolo, uno sviluppatore a cui hai concesso l'accesso alle cose di cui ha bisogno per fare il suo lavoro, o uno che ha ottenuto quell'accesso imparando come aggirare tutte le tue misure difensive? E perché la tua azienda paga te e i tuoi sviluppatori per combattere questa guerra gli uni contro gli altri quando dovresti lavorare insieme?

La semplice risposta è: dai agli sviluppatori l'accesso a ciò di cui hanno bisogno per svolgere il loro lavoro. E parla con loro. Potrebbero verificarsi rare condizioni (reverse engineering della camera bianca con importanti conseguenze legali o gestione di dati governativi classificati top-secret) in cui è necessaria una politica più complicata. Ma per la maggior parte, non è un grosso problema. Se inizi una guerra e rendi i tuoi sviluppatori nemici, se ne andranno o diventeranno molto più pericolosi che se lavorassi con loro.

Le misure ragionevoli includono non consentire dump del database di produzione sui laptop di sviluppo (solo testare database con dati fasulli). In questo modo, se il laptop viene rubato, nessun dato riservato viene perso. Ma se lo sviluppatore ha bisogno di eseguire il debug, deve comunque accedere alle copie del database di produzione da qualche parte in un ambiente controllato.

Limitare l'accesso a Internet è ridicolo. Potresti anche richiedere a tutti i tuoi sviluppatori di scrivere il loro codice su carta con una penna d'oca e inchiostro.

Parla con i tuoi sviluppatori, trova un modo per dare loro ciò di cui hanno bisogno per svolgere il loro lavoro mantenendo il sicurezza di cui hai bisogno per mantenere al sicuro i dati importanti. I dettagli dipenderanno dalla tua azienda e dai dati con cui hai a che fare. Ma non è probabile che richieda misure draconiane.

Un tecnico della sicurezza non effettua la manutenzione dei computer, questo è ciò che fa il service desk. Nel tuo caso gli richiederai di installare tre strumenti:

• un hypervisor
• docker
• software di database

Da lì può aggiungere e rimuovere macchine per lo sviluppo quanto vuole (non dovrebbe richiedere l'intervento di un tecnico specializzato). Per quanto riguarda il tuo "contenitore canaglia". In generale, non distribuisci contenitori su un altro server, distribuisci file Docker che estraggono codice da un repository di codice o scarichi un binario firmato di codice compilato (che è ancora più sicuro).

In termini di canaglia posso solo immaginare un attaccante che ottiene l'accesso e aggiunge altro codice. Questo è il motivo per cui è necessario che la sicurezza sia incorporata in ogni fase dell'SDLC per garantire che tutto il codice sia almeno rivisto o passato attraverso un altro sviluppatore prima di spingerlo su per l'albero. Inoltre, puoi anche integrare scanner di codici per eseguire automaticamente la scansione di matrici di codice sospette o vulnerabili.

Sul terzo punto, in realtà dipende. Aziende come Riot Games stanno facendo esattamente questo. Hanno scoperto che limitare gli individui intelligenti li porterà a eludere i controlli. Così hanno deciso di utilizzare regole semplici e una formazione di sensibilizzazione efficace per assicurarsi di mantenere la sicurezza nella parte posteriore della loro mente e hanno concesso pieni privilegi amministrativi. Distribuirono piccole carte che indicavano cosa avrebbero dovuto prendersi cura e fare attenzione.

Diamo ai nostri sviluppatori l'accesso come amministratore sui loro computer e facciamo loro sapere quali sono le regole. La maggior parte esegue Linux, ma abbiamo anche alcuni sviluppatori su Windows. Sanno tutti come memorizzare i loro documenti, progetti, ecc. Sulle nostre condivisioni di file (che hanno autorizzazioni più specifiche) e inviare il loro codice sorgente al nostro server Git.

Sanno anche che non passerò molto tempo per risolvere un problema con il loro sistema operativo. Se il loro computer non funziona correttamente, spesso lo cancelleremo e reinstalleremo il sistema operativo. Le applicazioni e le impostazioni comuni vengono installate automaticamente tramite Puppet e dovranno fare il resto da soli. La maggior parte di loro ha un repository Git con dotfile (le impostazioni e le preferenze per il loro ambiente).

Il tempo che perdono in questo caso è una motivazione sufficiente per la maggior parte di loro. A loro piace portare a termine il lavoro, invece di giocherellare con la riparazione del loro sistema operativo. Se perdono un lavoro importante perché è stato archiviato solo localmente, verranno disapprovati dai colleghi e dal capo.

Non blocciamo alcun sito web o applicazione (ad eccezione di un filtro anti-malware basato su DNS ) ma hanno alcune regole della politica aziendale su cose come il software illegale. Facciamo affidamento sulla pressione dei pari per la maggior parte delle cose. Le persone che trascorrono il loro tempo su Facebook non sono produttive e non durano a lungo. Gran parte delle nostre norme si basano su un sistema di riconoscimento e sembra funzionare bene.

Questo dipende fondamentalmente dal contesto. Considera le seguenti due configurazioni, entrambe riscontrate in natura:

• Gli sviluppatori lavorano su macchine che possiedono o hanno accesso completo, inclusa l'installazione dei propri sistemi operativi. Non ci sono restrizioni su come scrivono l'applicazione. Hanno accesso SSH ai sistemi di produzione ogni volta che sono connessi alla rete, VPN inclusa.
• Tutto lo sviluppo viene svolto in un laboratorio di sviluppo con air gap, in cui gli sviluppatori non sono autorizzati a introdurre dispositivi elettronici. Tutti i computer hanno tutto il software consentito preinstallato. Gli elementi distribuibili vengono consegnati in modo sicuro su supporto fisico a un altro team, che è responsabile della distribuzione.

Entrambe queste configurazioni erano appropriate nel contesto, tenendo conto delle minacce che l'organizzazione doveva affrontare e delle esigenze del progetto.

Qui c'è un compromesso fondamentale. Ogni allontanamento dalla prima possibilità, verso la seconda, riduce la produttività. Chiunque abbia il controllo sull'applicazione si trova in una posizione di fiducia. Tutto ciò di cui non ti puoi fidare è qualcosa di cui dovrai fare a meno o creare un processo di consegna che qualcun altro lo faccia. Non puoi revocare la fiducia senza ridurre la produttività.

Dipende dal tipo di software che stai sviluppando e dalle dimensioni della tua organizzazione.

Per la workstation di un singolo sviluppatore rockstar in una piccola azienda, utilizzerei un'eccezione di sicurezza a livello esecutivo. I rischi (incluso il fastidio dell'IT, dei dirigenti e degli altri sviluppatori) dovrebbero essere discussi, ma alla fine, se la rockstar non ottiene ciò che vuole, probabilmente si trasferirà in un'altra azienda. Questi ragazzi non tollerano l'attrito, se lo incontrano, possono facilmente trovare posti più interessanti in cui lavorare.

Uno scenario più tipico di una uber-workstation è avere un cluster di sviluppo in cui le operazioni gestiscono la vita e morte delle VM, l'ambiente viene monitorato con IDS / IPS e l'accesso a Internet (sul cluster di sviluppo) è limitato ma aperto all'occorrenza. ad esempio, per la documentazione ... niente di sbagliato nell'inserire nella whitelist ogni fonte tecnologica correlata al tuo sforzo di sviluppo. Gli sviluppatori non possono comunque inserire il codice volenti o nolenti. Devono documentare le loro fonti e verificare le licenze strane.

Se riesci a ottenere l'orecchio della rockstar, può aiutarti a spingere i requisiti a operatori e dirigenti e ad architettare il cluster e i processi e istruire i team di sviluppo sulla necessità.

Se c'è un budget e lo sviluppatore è riluttante ... allora IMHO, non hai a che fare con una rockstar, ma una diva e le loro lamentele dovrebbero essere portate fino a quel rischio esecutivo signoff.

La parte difficile diventa gestire la durata della macchina e assicurarsi che i ripensamenti degli sviluppatori non diventino sistemi di produzione per sviluppatori "simili alle operazioni". Ma è molto più semplice delle VM sulle workstation degli sviluppatori.

Questa domanda solleva una serie di domande e sfide interessanti. Come qualcuno che ha lavorato come sviluppatore per molti anni e poi è passato alla sicurezza, posso apprezzare molti degli argomenti e dei punti di vista espressi nelle risposte e nei commenti. Sfortunatamente, non esiste una risposta definitiva perché la soluzione corretta dipende dal contesto, dall'esposizione al rischio e dalla propensione al rischio dell'organizzazione.

La sicurezza non è qualcosa che puoi misurare in termini assoluti. Ogni volta che vieni ad una persona di sicurezza acrossa che parla costantemente in termini assoluti e insiste sull'applicazione di politiche specifiche indipendentemente da qualsiasi altra cosa sia inesperta o incompetente. Il ruolo dell'ingegnere della sicurezza è quello di facilitare i processi aziendali, non di ostacolarli e di garantire che le decisioni aziendali siano prese informate dai rischi per la sicurezza pertinenti. Un buon ingegnere della sicurezza saprà che qualsiasi politica che impedisca al personale di svolgere il proprio lavoro fallirà inevitabilmente. Il personale troverà il modo di aggirare la politica. Il più delle volte, questi work-around saranno ancora meno sicuri. È responsabilità del responsabile della sicurezza comprendere i vari ruoli all'interno dell'organizzazione e garantire che le politiche siano strutturate in modo tale da non solo supportare ciò che il ruolo richiede, ma incoraggiare buone pratiche e scoraggiare quelle cattive. Questo può essere difficile, soprattutto nelle grandi organizzazioni. Allo stesso tempo, gli sviluppatori e gli altri all'interno dell'organizzazione devono anche riconoscere che potrebbero non avere tutte le informazioni rilevanti per capire perché sono necessarie determinate politiche. Troppo spesso, gli sviluppatori e altri vedono l'ingegnere della sicurezza come un ostacolo o un burocrate interferente che non capisce di cosa ha bisogno per portare a termine il proprio lavoro.

Il più delle volte, il modo per affrontare questi problemi è attraverso la comunicazione. Ho avuto spesso sviluppatori che sono venuti da me frustrati perché alcune politiche che considerano inutili si stanno intromettendo. Una volta che ci siamo seduti e discutiamo del problema, una serie di cose tipicamente accadono;

• Lo sviluppatore ha interpretato male la politica o ha letto in essa presupposti errati e ha dato l'impressione che la politica prevenga qualcosa che non fa. Ciò si tradurrà spesso in una revisione della politica per migliorare la chiarezza
• Il tecnico della sicurezza viene a conoscenza di un requisito aziendale legittimo che deve essere soddisfatto in modo da mantenere adeguati controlli di sicurezza. Ciò si tradurrà probabilmente in una revisione della politica.
• Lo sviluppatore viene a conoscenza di altri requisiti o rischi che inizialmente non gli erano evidenti. Ciò spesso porta lo sviluppatore a identificare soluzioni alternative per soddisfare i propri requisiti
• Viene identificato un problema che non può essere risolto in modo soddisfacente per nessuna delle parti in un modo che rientra nella propensione al rischio accettata dell'organizzazione (ovvero livelli di rischio accettati ). Questa situazione si tradurrà in genere nel problema che viene inoltrato al livello esecutivo per una decisione. La difficoltà di fare ciò dipenderà dalle dimensioni e dalla struttura dell'organizzazione. Una volta presa la decisione, sia lo sviluppatore che il tecnico della sicurezza devono lavorare entro i parametri impostati dal dirigente per trovare la migliore soluzione possibile.

Ci sono state numerose risposte critiche delle politiche che hanno un impatto negativo sul loro livello di produttività. Sebbene qualsiasi sviluppatore dovrebbe sollevare tali preoccupazioni, alla fine della giornata, deve accettare qualsiasi decisione presa dal dirigente o cercare un datore di lavoro alternativo. Presumere che tu sappia meglio o che tu abbia qualche diritto speciale di ignorare la politica è arrogante e pericoloso sia per te che per il tuo datore di lavoro. Se sei convinto di avere ragione, dovresti riuscire a convincere la direzione. Se non puoi, o non sei bravo come pensi, non hai capacità di comunicazione adeguate per presentare un argomento convincente, non possiedi tutte le informazioni o stai lavorando per un datore di lavoro incompetente. Dopo 35 anni nel settore e nonostante quello che Dilbert può indurti a pensare, quest'ultimo non è così comune come potresti aspettarti. La fonte più comune di conflitto in quest'area è dovuta alla scarsa comunicazione e alla mancanza di informazioni.

Un errore comune tra gli sviluppatori (e uno di cui sono stato colpevole) è concentrarsi così tanto sul tuo compito o obiettivo specifico che ti manca l'immagine più grande che i team leader, i manager e il dirigente devono anche gestire. Ambienti in cui agli sviluppatori è stata concessa molta libertà e fiducia, il che ha portato a livelli elevati di produttività, ma ha portato ad altri problemi: la situazione in cui uno sviluppatore chiave ha lasciato o è ammalato per un lungo periodo di tempo e nessuno può riprendere funziona perché è tutto sul loro desktop configurato e gestito in modo univoco o sta tentando di eseguire il debug di un problema difficile che non può essere facilmente riprodotto a causa della mancanza di impostazioni / configurazioni standard, o di gestire un'eventuale violazione della sicurezza dovuta a uno sviluppatore che ha lasciato accidentalmente alcuni servizi in esecuzione che erano in fase di sviluppo e mancavano controlli di sicurezza standard. Lo sviluppatore Beinga focalizzato su un dominio o una tecnologia specifica non garantisce anche la competenza in tutto il resto. Alcuni dei migliori sviluppatori con cui abbia mai lavorato sono stati tra i peggiori quando si tratta di sicurezza e / o gestione del loro ambiente. Ciò è probabilmente in parte dovuto alla focalizzazione su un problema specifico e più probabilmente semplicemente a causa della capacità. Nessuno di noi ha la capacità di attraversare tutto e dobbiamo riconoscere che a volte è importante fare riferimento a coloro che sono specializzati in aree in cui non siamo.

L'ambiente in evoluzione

Uno dei motivi principali per le politiche che limitano ciò che può essere fatto sul desktop è dovuto al presupposto sottostante che i desktop all'interno della rete locale hanno un livello di fiducia più elevato di desktop fuori dalla rete. Tradizionalmente, si trovano all'interno del firewall e altro perimetro difese e avere accesso alle risorse informative. Ciò significa che rappresentano un rischio più elevato e quindi necessitano di più controlli di sicurezza. Altre ragioni per politiche / pratiche restrittive includono la standardizzazione degli ambienti, che può ridurre i costi di supporto e aumentare la coerenza (il che era particolarmente vero quando c'erano più applicazioni in cui dipendevano dalla piattaforma / dal sistema operativo - ricorda tutte quelle applicazioni orribili che richiedevano AtiveX o una versione specifica di IE).

La crescita delle macchine virtuali e dei container, dei servizi cloud e dei servizi IT di base e la maggiore capacità di rete si traducono in una serie di cambiamenti che probabilmente renderanno irrilevanti molti dei problemi sollevati in questo thread. In particolare, il passaggio alle reti zero-trust probabilmente vedrà cambiamenti significativi. In una rete zero trust, i dispositivi all'interno della rete non sono visti come dotati di uno speciale livello aggiuntivo di fiducia rispetto ai dispositivi esterni alla rete. Non ti viene fornita la possibilità di accedere alle risorse semplicemente perché hai l'indirizzo IP corretto. Invece, la fiducia si basa più sulla combinazione di informazioni sull'utente e sul dispositivo. La policy che determina a cosa puoi accedere è determinata dalle tue credenziali e dal dispositivo da cui ti connetti. La posizione in cui si trova quel dispositivo è irrilevante. Questo è anche un modello che si adatta molto meglio alla crescita del BYOD e alla maggiore mobilità della forza lavoro e alla crescente domanda di assumere personale in base alle capacità / abilità e alla posizione geografica.

Una volta rimosso il livello di "fiducia" associato al dispositivo, non è necessario controllare ciò che è possibile applicare al dispositivo. Potresti ancora richiedere dispositivi per supportare profili specifici, ad esempio puoi rifiutare di consentire a chiunque di accedere alle tue risorse se il suo dispositivo esegue Windows XPetc. Tuttavia, sei meno preoccupato per il dispositivo. Allo stesso modo, non dovrai lavorare tanto direttamente sul dispositivo. In una certa misura, il dispositivo lo sarà più simile a un thin client. Utilizzerai VM e container ospitati in remoto. Questo di per sé non risolverà tutti i problemi e potrebbe essere visto come il semplice spostamento di alcuni di essi dal desktop locale alla VM o al contenitore remoto. Tuttavia, una volta combinato questo con varie orchestrazioni in stile DevOps, molti dei motivi per cui gli sviluppatori potrebbero aver bisogno di privilegi avanzati vengono rimossi. Ad esempio, non è possibile richiedere alcun accesso ai sistemi di produzione. La promozione del nuovo codice verrà gestita attraverso un sistema di integrazione continua orchestrato e quando sarà necessario eseguire il debug di un problema, verrà fornita una VM o un contenitore che è un clone esatto del sistema di produzione.

Nessuna di queste modifiche lo farà. risolvono magicamente qualsiasi cosa, ma forniranno una gamma più ampia di strumenti e soluzioni più flessibili con potenzialmente meno complessità. La riduzione della complessità renderà la gestione della sicurezza molto più semplice. Una gestione più semplice della sicurezza porterà a restrizioni o impedimenti meno involontari o non necessari allo svolgimento delle mansioni lavorative. Tuttavia, alla fine della giornata, i requisiti chiave sono

• Il riconoscimento da parte di tutti che una taglia non va bene per tutti. Tutto deve essere valutato nel contesto dell'organizzazione.
• Disponibilità a mettere al primo posto le esigenze dell'organizzazione.
• Buona comunicazione bidirezionale.
• Disponibilità per tutte le parti a lavorare verso soluzioni reciprocamente accettabili e
• Disponibilità per tutte le parti a scendere a compromessi
• Disponibilità a lavorare all'interno del sistema e adattare il flusso di lavoro o modalità preferita di fare le cose per adattarle ai requisiti dell'organizzazione

Sono anche uno sviluppatore e questa è la mia opinione:

Il problema è peggiore di quanto pensi

Non c'è cucchiaio

Lo sviluppo non riguarda Software. Lo sviluppo riguarda la creazione o il miglioramento di prodotti, servizi e processi. Il software è un ingranaggio importante ma non è l'unico. I bravi sviluppatori definiranno i processi in senso più ampio per sapere quali componenti software creare e quale processo umano, logistico e di gestione del rischio proporre. Non ha alcun senso sviluppare un sistema software che dipenda da processi umani, logistici e cartacei che non vengono implementati.

Non ci sono regole per lo sviluppo perché lo sviluppo sta definendo le regole. Questo è ciò che rende lo sviluppo l'ambiente peggiore da proteggere.

Ma questo non significa che alcuni controlli non dovrebbero essere stabiliti. Al contrario, molti controlli dovrebbero essere impostati dallo stesso team di sviluppo.

Processo di progettazione

Ci sono aziende che sostengono la separazione tra business e tecnologia in un processo dall'alto verso il basso. Questo è in realtà molto popolare perché suggerisce che gli uomini d'affari senza conoscenze tecniche dovrebbero essere in cima. I pigri lo adorano . Ma in ingegneria un design top-down semplicemente non funziona. Feyman (1985) ha scritto un bell'articolo a riguardo nella commissione presidenziale che ha analizzato l'esplosione del Challenger. Fondamentalmente l'ingegnerizzazione dei processi top-down alla fine distrugge l'azienda. E la mia esperienza di mercato rafforza questa comprensione.

L'esplosione del Challenger è un ottimo esempio. I dirigenti della Nasa testimoniano davanti alla telecamera su una commissione d'inchiesta di aver sviluppato una gomma che può rimanere flessibile sotto i 60 gradi sotto lo zero. Cosa che è stata contraddetta da un semplice esperimento fisico di scuola superiore fatto da uno dei commissari (mettere il componente in gomma in acqua ghiacciata pressato da una pinza). Questo è stato un ottimo esempio perché questo componente in gomma doveva essere flessibile affinché il booster non esplodesse; poiché aveva bisogno delle temperature estive per farlo, il booster funzionava solo in estate. Una caratteristica di un singolo componente definisce una caratteristica visibile dell'intero prodotto che è molto limitante.

L'ingegneria dovrebbe avvenire dal basso verso l'alto perché è necessario conoscere i limiti e le debolezze di ogni componente per elaborare processi per mitigarli . Il più delle volte, i processi di mitigazione non sono software e incideranno sul costo del prodotto. Ciò significa che le caratteristiche e le limitazioni dei singoli componenti definiranno le caratteristiche dei prodotti, servizi e processi.

I processi top-down sono fondamentalmente interrotti. Molte aziende che adottano questa filosofia sulla carta hanno ancora un certo successo di mercato. Ma quando si scende e si studiano i loro progetti più grandi e di maggior successo, si scopre che sono stati condotti al di fuori delle normali regole aziendali. I maggiori successi si ottengono quando una persona che ha una profonda conoscenza ingegneristica e una visione del mercato è informalmente autorizzata. Poiché ciò avviene in modo informale, la direzione ritiene che il processo dall'alto verso il basso funzioni. Dicono che tutte le altre squadre sono incompetenti. Chiudere un occhio sul fatto che lo schema iniziale del progetto quando è uscito dalla "fase superiore" è stato completamente ignorato e non descrive i prodotti, i servizi e i processi realizzati.

Il tuo manager può definire che progetterai un dispositivo di teletrasporto entro la fine del mese perché ha concluso che ciò consentirà un elevato profitto nel settore dei viaggi ... ma ciò non lo realizzerà. I progetti dall'alto verso il basso sono così, stabiliscono aspettative che non sono tecnologicamente valide.

Non fraintendetemi, è bello vedere il problema da molti punti di vista. Bottom-up, Top-down, SWOT e altro sono salutari per l'analisi, ma il vero sforzo di ingegneria è dal basso verso l'alto. Non esiste un vero obiettivo senza la fattibilità tecnica.

Sicurezza nello sviluppo

Dobbiamo ricordare che gli sviluppatori di software cambieranno regolarmente il software aziendale e, in questo modo, potranno: cambiare ciò che appare sullo schermo di chiunque, inviare e-mail automatizzate a chiunque, inclusi loro stessi, o aprire backdoor per fare ciò che vogliono. Ciò significa che un criminale assunto come sviluppatore può arrecare danni significativi all'azienda.

Peggio ancora, ci sono molte aziende che non impongono la provenienza di un repository di codice sorgente e quindi lo sviluppatore assunto può fornire un binario diverso dalla sorgente fornita. Ciò consente agli sviluppatori criminali di dirottare i sistemi aziendali, se non vengono assunti, le cose smetteranno di funzionare presto.

Per me la sicurezza dello sviluppo dovrebbe concentrarsi su:

• Controllo della versione del codice sorgente : per garantire che il codice sorgente e i componenti di terze parti necessari siano archiviati in un luogo sicuro.
• Divisione strategica del lavoro : junior e temporanea gli sviluppatori devono avere un accesso limitato al codice sorgente e ai dati. Hanno solo bisogno di accedere ai componenti che stanno cambiando per evitare che uno sviluppatore junior sia in grado di comprendere il funzionamento interno di tutti i sistemi ed essere in grado di sfruttarlo.
• Fidati degli sviluppatori principali : gli sviluppatori senior / core dovranno sapere tutto, avere accesso a tutto, pianificare e distribuire le attività e diagnosticare problemi gravi. Questo nucleo deve avere accesso a tutto, sia nello sviluppo che nella produzione. Sono i tuoi partner nello sviluppo delle politiche di sicurezza. Dobbiamo accettare che gli sviluppatori principali siano i proprietari dell'azienda. Il mio vecchio capo diceva: "siamo fortunati che Lucas sia dalla nostra parte, dall'altra ci distruggerebbe". Gli sviluppatori principali possono causare molti danni se lo desiderano e non esistono firewall e controlli di produzione che possano impedirlo.
• Separa l'ambiente tramite firewall : separa la tua rete di sviluppo, da la tua rete di test, dalla tua rete di produzione. Su un'azienda ho definito la rete 10.1. come sviluppo, 10.2. come test e 10.3. come produzione. Le reti 10.2 e 10.3 ricevono codice solo tramite il CVS aziendale e le creano automaticamente su comando admin. Sebbene fosse una piccola startup e io fossi nella produzione e nei team di sviluppo, ho fatto alcune burocrazie per evitare i miei errori (gli sviluppatori possono essere i tuoi migliori alleati). Ho anche cambiato i colori del terminale in base alla rete: quando mi collegavo a un server di produzione lo sfondo del terminale era rosso, il test era giallo e lo sviluppo verde. Poiché tutti i miei server utilizzavano la stessa configurazione, era facile confonderli se il prompt era aperto. In base alla mia esperienza, la maggior parte dei problemi deriva da software mal testato e nuove installazioni di software. Per essere chiari: dove ti trovi è una potente funzionalità di sicurezza secondo me. Non ha nulla a che fare con l'accesso, ma è la sicurezza.
• Assumere un esperto sviluppatore di test : l'aspetto chiave del test è disporre di grandi quantità di buoni dati simulati che siano significativi per i problemi che l'azienda deve affrontare. Le simulazioni Monte-Carlo sono utili per generare set di dati di grandi dimensioni che hanno un significato per altri sviluppatori e possono portare a software e processi più forti e resilienti. Per me non ci sono errori di "produzione", la colpa è sempre dello sviluppatore. Le attività di manutenzione e gli imprevisti devono essere scritti. Il software deve essere resiliente.
• Revisione del codice sorgente : chiedi alle persone di rivedere il codice sorgente prima di accettare la modifica. Tutti i progetti dovrebbero essere ramificati sul controllo del codice sorgente e l'unione dovrebbe essere rivista. La revisione del codice sorgente dovrebbe preoccuparsi solo del rilevamento del malware, dell'escalation degli accessi, dei profili di accesso e di una buona spiegazione di cosa significa e dovrebbe fare il codice sorgente. La qualità del codice sarà assicurata dal test, non dalla revisione del codice sorgente. Puoi vederlo in azione nella maggior parte dei progetti open source.
• I test delle policy di test sono molto più una cultura aziendale che un framework. Alcune aziende adottano framework di mercato, eseguono alcuni test, ma la qualità del loro codice è pessima. Ciò accade perché hai bisogno di persone in grado di progettare test significativi. In realtà lo sviluppo deve diventare test driven. Non conosco altro modo sicuro di sviluppo. E una cosa curiosa è che anche gli esseri umani, gli acquisti e le consulenze devono essere testati. I fornitori spesso affermano che i loro prodotti funzionano in modo impeccabile, ma non ho ancora trovato un prodotto impeccabile.
• Le norme non hanno senso se non vengono monitorate . Una società che conosco ha una burocrazia secondo cui ogni tabella di database dovrebbe avere una descrizione a livello di attributo. Il 95% degli attributi è descritto come "il $ {nome attributo} di $ {nome tabella}". Non spiega cosa sia realmente l'attributo, quali valori possono contenere e cose del genere.
• Retribuzione e ambiente di lavoro adeguati . Per avere buoni sviluppatori, sia per abilità che per personalità, devi avere buone politiche di compensazione. Il denaro è importante, ovviamente, ma non è sufficiente. Devi anche avere prospettiva / stabilità, vero riconoscimento e un buon ambiente di lavoro. Ad esempio, invece in un ufficio di sviluppo a New York dove le persone vivono in piccoli appartamenti, puoi scegliere una città più piccola dove lo stesso compenso consente una casa più grande e una maggiore vicinanza al lavoro. Computer più grandi, buoni laboratori sono anche un vantaggio per gli appassionati di tecnologia.
• Sicurezza dei dati molte attività richiedono dati di produzione sensibili e dovrebbero essere accessibili in un laboratorio speciale. A meno che le informazioni non siano pubbliche o non sensibili, forse la migliore politica è mettere i laboratori in buoni quartieri con accesso fisico controllato. Consentire l'inserimento solo di alcuni dati simulati su laptop personali e componenti non sensibili. È possibile. Ad esempio, ho sviluppato un archivio di dati di 4,5 miliardi di record con accesso pesante per un'azienda. L'ho fatto a casa mia e non ho utilizzato assolutamente dati aziendali a tal fine. Quando ho inviato il codice, ha funzionato come previsto al primo tentativo. Oltre ai guasti hardware e alla migrazione degli ambienti di produzione, abbiamo il 100% di disponibilità in 10 anni. Il rischio che lo sviluppatore porti con sé il codice sorgente non è rilevante. Questo particolare sistema mi ha richiesto 3 mesi per sviluppare, gran parte di questo tempo è stato per capire i limiti delle prestazioni dei componenti. Questa ora è conoscenza dentro la mia testa. Anche senza il codice sorgente posso sviluppare nuovamente questa soluzione in circa una settimana.
• I registri efficaci sono importanti per conoscere tutti coloro che hanno fatto qualcosa. La cosa migliore qui è che i log siano generati da un framework, registrando per schermate dettagliate di breve durata, per tempi di accesso e attività più lunghi e ancora più lunghi i log aziendali. I miei sistemi critici registrano ogni volta che si accede a una schermata (incluso il design dello schermo). Alcune delle risorse critiche dovrebbero essere registrate da un trigger sul database stesso e le tabelle o le risorse critiche dovrebbero essere contrassegnate per il controllo del codice sorgente.
  - Lo screening del log è difficile da eseguire manualmente. Scopri come creare filtri sui log per vedere le cose critiche. Un filtro molto utile è incrociare i rapporti sui reclami con l'accesso e le attività degli utenti. Se hai registri abbastanza buoni vedrai delle coincidenze. Ad esempio: prima di un problema l'utente1 effettua sempre l'accesso.

Informazioni sul mancato accesso alla produzione

Le regole che richiedono agli sviluppatori di non accedere ai sistemi di produzione poiché gli utenti sono lì per evitare che gli sviluppatori sottoporre il codice per mostrare al proprio utente le informazioni privilegiate. Penso che questa sia una misura di sicurezza molto, molto debole e facile da rilevare nell'audit del codice sorgente. Esistono diversi modi per aggirare il problema:

• uno sviluppatore più un dipendente poco retribuito;
• si invia un'e-mail;
• apre back-door nel sistema.

L'audit del codice sorgente alla ricerca di backdoor, escalation di accesso e malware sembra più produttivo. Permette di identificare i cattivi sviluppatori quando stanno testando i loro exploit e di licenziarli. Ovviamente uno sviluppatore esperto può nascondere un exploit in bella vista, quindi è importante usare linguaggi e nomi di variabili chiari e chiari. Ricorrere a soluzioni strane solo nei punti documentati delle applicazioni che richiedono prestazioni speciali o offuscamento. Ad esempio, 1 << 4 è uguale a 1 * 16. Ciò avrebbe senso solo se il linguaggio non esegue questa ottimizzazione da solo e il punto in cui si verifica è un collo di bottiglia delle prestazioni. Linguaggi troppo simbolici fanno male proprio per questa stessa ragione. Il codice sorgente dovrebbe essere leggibile da qualsiasi smanettone.

Il problema è peggiore di quanto pensi

I danni più semplici e peggiori che uno sviluppatore può causare non sono legati all'installazione dello strumento. Anche se l'ambiente di sviluppo è gestito, farà poca differenza se l'azienda non dispone di firewall potenti, repository di codice sorgente, build basati esclusivamente sui repository di codice sorgente e revisione del codice.

In qualità di consulente ho lavorato per molte aziende diverse, e solo 2 di loro non concedevano agli sviluppatori l'accesso amministrativo alle loro macchine; una era una piccola azienda, l'altra era un'azienda molto grande.

Nella piccola azienda ho richiesto l'accesso come amministratore, ho spiegato il motivo per circa 60 secondi e l'ho ricevuto subito.

Alla grande azienda ho richiesto l'accesso come amministratore e mi è stato detto che anche se sono d'accordo che dovrei averlo, la politica aziendale lo vieta e non possono cambiarlo. Quindi uno dei ragazzi IT è venuto e ha creato un account di amministratore locale sulla mia macchina e mi ha fatto impostare la password. Da quel momento in poi, ogni volta che avevo bisogno di essere un amministratore, potevo accedere alla macchina come amministratore locale, o semplicemente usare runas per avviare Visual Studio o qualsiasi servizio / applicazione di cui avevo bisogno per eseguire con un utente amministratore (IIS, ad esempio). Non è molto peggio che scegliere il built in "Esegui come amministratore"; è solo leggermente più lento, anche se fortunatamente non viene visualizzato troppo spesso.

Ricorda che il problema di sicurezza più grande qui è l'esfiltrazione di IP, non il malware. Si spera che tu abbia IDS / IPS in atto per gestire quest'ultimo, il che dovrebbe renderlo un non problema.

Puoi cavartela dando accesso amministratore alle apparecchiature di sviluppo, a condizione che tu abbia in atto quanto segue:

• Anti-eDLP (rete, USB, ecc.)
• IDS / IPS
• Proxy aziendale autenticato da MITM NTLM attraverso il quale si forzano tutte le connessioni e si monitorano per violazioni DLP
• Nega tutto il software di virtualizzazione sui desktop. Se hai bisogno di una VM, eseguine il provisioning da un cloud gestito in cui tutte le VM eseguono la stessa immagine obsoleta e standardizzata con gli strumenti di cui sopra.
• Blocca l'accesso ai repository software esterni a livello di rete (questo paralizza pip, git, maven, apt, yast, zypper e tutto il resto)
• Blocca l'accesso a github, codeplex e tutti gli altri 150 siti di code-sharing a livello di rete
• Blocca l'accesso a tutti i 9000+ siti di condivisione di file a livello di rete
• Blocca l'accesso al P2P ... ecc ...

Il mio datore di lavoro fa tutto questo e altro ancora. Parecchi colleghi finiscono comunque per sviluppare la propria attrezzatura personale dopo l'orario di lavoro a casa e lanciarla indietro oltre la recinzione attraverso canali laterali solo per aggirare l'infrastruttura paralizzata. Personalmente preferirei passare le mie serate a bere e sognare di overdose di tranquillanti per cani piuttosto che sprecare altre 20 ore non documentate facendo qualcosa che mi farebbe comunque licenziare.

Consideriamo l'informatica (e per estensione, l'ingegneria del software ) una scienza. Gli esperimenti scientifici vengono condotti in condizioni sterili per tenere sotto controllo le variabili. Non è scientifico svilupparsi in un ambiente paralizzato in cui le cose non si comportano come previsto a causa di fattori ambientali. Posso dirti per esperienza che non ottieni software ben progettato ... tutto ciò che è sviluppato internamente è guasto, il che porta a una maggiore spesa per soluzioni di terze parti.

Gli sviluppatori devono assolutamente disporre di un ambiente sterile in cui sviluppare. Non posso dirti quante volte i vari controlli di sicurezza hanno introdotto i gremlin nell'architettura di sviluppo e produzione, quindi un ambiente di sviluppo gestito, sterile e basato su cloud è davvero il unico modo per andare. "Ha funzionato in laboratorio, il problema deve essere qualcosa di esterno."

Devi solo assicurarti che le VM che consenti loro di eseguire il provisioning non siano anemiche e devi automatizzare il processo di provisioning come OpenStack o AWS in modo che gli sviluppatori non stiano aspettando giorni per soddisfare le esigenze di scalabilità. Averli tutti gestiti centralmente offre una grande quantità di controllo di auditing e, francamente, offre agli sviluppatori prestazioni migliori di quelle che otterrebbero comunque con le proprie apparecchiature.

Sono un fan dell'opzione n. 2: avere computer separati.

Consentire alle macchine aziendali con informazioni proprietarie di essere connesse a Internet apre la porta agli hacker. Inoltre, rende molto più facile per i dipendenti esfiltrare i dati aziendali per scopi illegittimi.

Se il dipendente deve utilizzare una macchina speciale per accedere alle risorse Internet, crea un percorso controllato per l'infiltrazione e l'esfiltrazione dei dati che è molto sicuro. Inoltre, scoraggia i dipendenti dal navigare pigramente sul Web o perdere tempo sui forum Internet, come sto facendo ora.

In qualità di amministratore, questo problema viene risolto completamente e completamente tramite un approccio SaaS. Virtualizza tutti i tuoi diversi ambienti, mettili su un server rack appropriato per il numero di client e configura alcuni accessi remoti (RDP, Servizi terminal o altro ...). Ora tutto è sul server e hai solo uno di ogni ambiente da mantenere per tutti.