In che modo dovrebbe essere coinvolto uno sviluppatore nella progettazione di una politica di sicurezza?

Sono anche uno sviluppatore e la mia passione per la sicurezza spesso rende la dinamica un po 'insolita quando si tratta di altri sviluppatori non incentrati sulla sicurezza.

Ci sono tre principali aree di vincolo quando si tratta di politica di sicurezza:

• Usabilità: accertarsi che l'utente possa effettivamente utilizzare il software e che non venga eccessivamente irritato o ritardato dalle misure di sicurezza.
• Tecnico: accertarsi che i meccanismi di sicurezza siano implementati correttamente e che non influiscano sul tempo di attività, sulla manutenibilità o su altri fattori tecnici critici.
• Finanziario: accertarsi che le misure di sicurezza non costino troppo, sia che si tratti di costi finanziari diretti (ad esempio l'acquisto di scatole nere con luci lampeggianti) o di ore di manodopera aggiuntive.

Il tuo lavoro dovrebbe implicare consulenza sui fattori tecnici e suggerire modi in cui potresti mitigare qualsiasi impatto sull'usabilità. Tuttavia, dovresti quasi sempre posticipare al giudizio tecnico di un consulente di sicurezza competente (essendo competente la parola chiave) se non sono d'accordo con te su un problema di sicurezza tecnica. Il tuo compito è integrare le necessità in un prodotto in modo ottimale, superando i difficili ostacoli.

In termini di coinvolgimento diretto nella politica di sicurezza per lo sviluppo del software, dipende in gran parte da:

• Indipendentemente dal fatto che tu abbia una persona o un gruppo di sicurezza dedicato.
• In quale settore lavori (potresti dover trattare con dati PII o HIPAA)
• Dove ti trovi nell'organizzazione e se sei in grado di apportare modifiche.
• Quanto è incentrata sulla sicurezza la società.

La parte interessante di questa domanda arriva quando si considera che la maggior parte delle organizzazioni di software non ha una persona di sicurezza dedicata, per non parlare del dipartimento. Indipendentemente dal fatto o meno dalla tua azienda, hai il dovere di conoscere i tipi di problemi di sicurezza e i meccanismi che si applicano al tuo lavoro. Se la tua azienda non ha un "ragazzo della sicurezza", quella responsabilità è ancora più grande. Parte del tuo lavoro consiste nell'implementazione di software funzionante e affidabile, che include la sicurezza, ma un'altra parte riguarda il trasferimento delle informazioni tecniche alla gestione in modo che possano essere comprese. Non puoi farlo efficacemente se non comprendi i problemi a portata di mano.

In breve, non esiste una risposta semplice. Devi prendere alcune decisioni sulla sicurezza e implementare determinati meccanismi come parte del tuo lavoro, perché è quello che fa uno sviluppatore. Quanto a quanto lontano vai, dipende interamente da te come persona e dall'organizzazione in cui lavori. Per emettere giudizi ragionevoli quando non viene fornita alcuna direttiva sovrascritta, tu è necessario inserire il lavoro per comprendere i problemi.

Sono favorevole a spingere le persone a migliorare gli standard di sicurezza, tuttavia mi piace controllare il mio destino. La mia preferenza sarebbe per voi di sviluppare opzioni per dare agli amministratori la flessibilità di fare le proprie scelte, ma impostare i valori predefiniti ad un livello di sicurezza elevato. In questo modo, se qualcuno si interessa di loro, può rendere le cose conformi alla propria politica di sicurezza interna e, se lo usano fuori dagli schemi, ha standard elevati.

IMO, anche in un "mondo perfetto" dovrebbe essere coinvolto un programmatore. Il programmatore dovrebbe essere sufficientemente esperto per tradurre i requisiti di business e il gergo della sicurezza in termini di sviluppatori e viceversa.

In parole povere, solo uno sviluppatore comprende esattamente come funziona il software, ed è possibile che qualcosa sia stato "perso nella traduzione". Come minimo, uno sviluppatore (o un revisore di codice - qualcuno che abbia familiarità con il codice reale) dovrebbe sedersi e assicurarsi che le persone che fanno le politiche non lo facciano da un fraintendimento di come qualcosa viene implementato sotto il cofano.

Non solo aiuta ad assicurarsi che gli altri membri del team comprendano ed evitino errori, istituendo tale politica / strategia aiuta a garantire che il programmatore sia pienamente investito nella sicurezza del suo sistema. Semplicemente non insegnano pratiche di codifica sicure come dovrebbero. Le scuole o le esercitazioni online iniziano tutte mostrandoti come fare le cose e c'è così tanto da imparare che raramente si preoccupano di come non fare cose.

Ogni singolo difetto di sicurezza nel mondo IT è il risultato del software da qualche parte. A livello di sistema operativo, nelle API che stai chiamando, il tuo codice, da qualche parte c'è un difetto che sta permettendo il cattivo comportamento. Potrebbe trattarsi di un bug nel codice o di un requisito insensato, ma anche i requisiti minimi sono difetti del codice costruito secondo le specifiche di tali requisiti.

Quindi ha senso assicurarsi che gli sviluppatori siano coinvolti - per convincerli a pensare alla sicurezza, e per garantire che non ci siano equivoci che potrebbero causare problemi.

Come sviluppatore direi che spetta all'utente finale definire quali devono essere i requisiti di sicurezza del prodotto. Dovrebbero essere i posti migliori per capire il panorama delle minacce che devono affrontare e i rischi che devono affrontare.

Detto questo ... è improbabile che tu trovi un cliente perfetto che sappia subito i loro requisiti di sicurezza, a quel punto stai guardando agli analisti di business (che potrebbero benissimo comprendere gli sviluppatori, in particolare gli architetti con una profonda comprensione del prodotto) per contribuire a derivare tali requisiti.

Dal punto di vista degli sviluppatori, il modo migliore per implementare questi requisiti è la chiave. E, altrettanto importante, sapendo come scrivere software sicuro, l'ultima cosa di cui hai bisogno è un buffer overflow / SQL injection che rompe tutti quei begli requisiti e design.

In termini di configurabilità della sicurezza mi piacerebbe abbonarmi alla mentalità sicura per impostazione predefinita, in modo tale che sia distribuito nel modo più sicuro possibile con l'opzione di rilassare i controlli di sicurezza se necessario.

Come architetto e professionista della sicurezza, il mio pensiero su questo è che mentre è fondamentale per gli sviluppatori avere una mentalità focalizzata sulla sicurezza per progettare software sicuro di alta qualità, la configurazione in definitiva deve essere all'altezza delle esigenze aziendali della fine società o utente. Il software dovrebbe essere progettato in modo tale da salvaguardare da comportamenti malevoli e da supportare come rigoroso di un sistema di sicurezza come ci si aspetta sia necessario, ma la sicurezza è anche un atto di bilanciamento tra la necessità di usabilità e la necessità di sicurezza. Come sviluppatore, spesso non è possibile per noi prendere la decisione migliore in merito ai dettagli esatti della configurazione che meglio soddisfano le esigenze di qualsiasi azienda o utente finisca per utilizzare il prodotto.

Questa risposta cambia se stai progettando software per uso interno e il livello necessario di sicurezza è noto prima di implementare il software, ovviamente, anche se avere la possibilità di regolare la configurazione in un secondo momento non è necessariamente una cosa negativa se non causa il rischio di ulteriori buchi di sicurezza per eccesso di complessità.

Ho scritto alcune linee di base per un cliente, una delle cose più importanti da fare è assicurarsi che le persone che lo implementeranno siano anche coinvolte nella creazione. Indipendentemente dal fatto che siano sviluppatori o amministratori, ... dovrebbe esserci una (parziale) politica di sicurezza simile, specialmente quando si tratta di password.

Quando li coinvolgi, farai:

• Ottieni input e problemi che affrontano regolarmente, in questo modo puoi definire facilmente l'ambito, offrire loro nuove conoscenze e aiutarli a risolvere i problemi dal punto di vista della sicurezza
• Lo vedono un po 'come il loro progetto e adotteranno e accettano la politica più facilmente
• Se hanno domande, chiedono loro molto più velocemente e puoi dare loro un consiglio
• Poiché accettano e capiscono perché stai adottando una politica di sicurezza potrebbero persino promuovere o richiedere più facilmente progetti di sicurezza simili

In un mondo perfetto il tuo team / azienda seguirebbe linee guida come il ciclo di vita sicuro dello sviluppo, combinato con ulteriori restrizioni a seconda del tuo campo di lavoro (influenzato da restrizioni di legge / conformità a.e.).

Se dai un'occhiata qui: link vedrai su una base molto tecnica dove tutto ciò che POTREBBE essere coinvolto in.

Di solito gli Scrum Masters supervisionano l'implementazione di queste linee guida e raccolgono feedback dagli sviluppatori. Ma probabilmente non è la "soluzione perfetta per il mondo".

Per andare con il tuo esempio della password: il responsabile della supervisione dell'implementazione della politica di sicurezza direbbe / al responsabile della tua squadra / al proprietario del prodotto, che la password deve avere 16 numeri alfa e ricontrollare per vedere se è stato implementato. Non è sicuramente il tuo lavoro fare ricerche su questo (mondo perfetto). Avrebbe una lista terribile lunga di queste cose, in realtà:)