Gestione dei rischi con analisi del codice del software

Il tuo riferimento alle patch software, ai diagrammi di rete e alle date di fine vita è vero per quanto riguarda il PCI DSS nel suo insieme, ma ci sono requisiti molto specifici e pertinenti riguardo alla tua domanda:

• 6.3.2: revisione del codice personalizzato prima del rilascio in produzione ... per identificare qualsiasi potenziale vulnerabilità di codifica
• 6.4: seguire i processi di controllo delle modifiche
• 6.5: Sviluppa applicazioni basate su linee guida di codifica sicure. Prevenire le vulnerabilità di codifica comuni ...

La sezione 6 di PCI DSS si concentra molto sulla sicurezza del processo di codifica, ma è giusto che non richieda un'implementazione specifica. Un kit di strumenti di analisi rientrerebbe nella sezione 6.3.2 che richiede la revisione del codice tramite mezzi manuali o automatizzati. Inoltre, dovresti avere un processo in atto per prevenire tutte le classi di vulnerabilità come referenziate tra i requisiti 6.5.1 e 6.5.9.

Esistono molti processi sovrapposti che dovrebbero essere utilizzati per mitigare le vulnerabilità e assicurare che non si introducano nel codice di produzione. Se si affronta seriamente la sezione 6 di PCI DSS e si soddisfano tutti i requisiti con i processi che funzionano per la propria organizzazione e sono sensati dal punto di vista della sicurezza, sarete in un buon posto.

Non c'è ragione per cui non dovrebbe, in effetti, questo è un ottimo modo per fare un controllo iniziale. La ragione per cui non è specificatamente elencata è perché il test delle penne e l'analisi manuale dovrebbero svolgere un lavoro molto migliore di un'analisi automatizzata (e potrebbe benissimo includerne uno come parte della revisione). Il punto è che il test automatizzato da solo non è sufficiente .

Ignora PCI DSS. È inutile (vedi anche: BlackPOS).

Ciò che è importante è la gestione dei processi aziendali e una profonda comprensione delle catene di output ad alto valore. Il problema della sicurezza di informazioni / dati / app è che le catene di input di basso valore possono far muovere gli avversari in catene di output di alto valore. Copri le tue catene tracciando il flusso di dati attraverso la tua organizzazione.

Identifica elementi critici e costruisci un apparato per assicurare tutte le tue catene di input appropriate. Acquista un'assicurazione informatica che corrisponda al tuo sistema BPM. Appello ai gruppi di controllo, ai consulenti legali, ai procuratori distrettuali e alla FTC (o ovunque si trovino le giurisdizioni) per l'autovalutazione mediante quadri alternativi. Se vuoi il mio suggerimento su un framework, ti consiglio VisibleOpsSec su, ad esempio, ISO 27001/27002, PCI DSS, IT COBIT, FISAP, CIP, ecc.

Appsec è semplicemente semplice. Integrazione di Microsoft TFS (o JIRA / Confluence Atlassian) con modelli di processo che corrispondono alle esigenze dell'organizzazione (approssimativamente) e che funzionano con modelli di processo esistenti come EssUP, Agile, Scrum, Waterfall o qualsiasi piccolo modello di processo modifica le coordinate del team di gestione prodotto con i tuoi proprietari di business / org. Se hai una terza parte che fa parte del tuo prodotto software, li includi (ovviamente) e li tenga agli stessi standard.

Quindi, esegui la simulazione e l'analisi della squadra rossa, oltre ad alcune analisi tipiche del metodo Delphi per raccogliere opinioni e comprendere i risultati prima che si verifichino nella vita reale. Integrate questi concetti nel vostro Application Lifecycle Management (ALM) attraverso bdd-sec e cacce agli insetti. Molti strumenti bdd-sec e bug hunt si basano su Burp Suite Professional, quindi assicurati che tutti abbiano una copia, ma armali anche con IronWASP e OWASP ZAP. Se gestisci un negozio JEE (probabilmente Atlassian per ALM), allora ti consigliamo un buon cablaggio di test automatizzato WebDriver (o O2) combinato con Contrast Security. Se hai un negozio Microsoft, dai un'occhiata agli strumenti standard VisualStudio (o O2) - magari aggiungendo Fortify o Checkmarx su progetti spot che richiedono una mitigazione intermedia o continua. Altre strutture richiedono alcune modifiche insolite, ma niente di troppo elaborato o "là fuori". Se stai eseguendo progetti per dispositivi mobili, le imbracature Appium combinate con Clang asan (per iOS) o Coverity (per Android) più un controllo su Appthority probabilmente funzioneranno bene.

È importante che questo sia supportato dai programmi di gestione e risposta degli incidenti di qualità ENISA e US-CERT. Il personale o il personale di talento DFIR è sempre il tuo più grande problema di infosec. L'aggiunta di processi e strumenti a quel programma è il tuo secondo più grande problema di infosec. Successivamente, appec, datasec, "netsec" (haha, come se esistesse anche!) E la gestione del rischio saranno una passeggiata nel parco.

Come menzionato, non c'è motivo per cui non dovrebbe. Uno dei motivi per cui non lo è è la mancanza di maturità della pratica industriale in materia di revisione / revisione del codice, non solo in un contesto PCI. Non esiste uno standard consolidato per cosa e come si dovrebbero verificare le vulnerabilità nel codice sorgente del software, nessun modo formalizzato per condurre tali valutazioni e, ad oggi, le soluzioni esistenti per eseguirle sono immature e il mercato non è completamente chiaro per i clienti . Aggiungi una costante mancanza di tecnici specializzati che capiscono come funziona ed eccoti qui.