Scansione del codice sorgente - Requisito PCI - Fornitore di servizi

5

Ho svolto molte ricerche in merito ai requisiti per la scansione del codice sorgente ma non ho trovato nulla di conclusivo quando si tratta della mia domanda di seguito. Quindi ho bisogno di una guida dagli esperti PCI qui nella comunità di Info Sec di StackExchange.

Un fornitore di servizi che utilizza un'applicazione di pagamento personalizzata in-house (non PA DSS) richiede l'utilizzo di uno strumento come HP Fortify SCA per eseguire la scansione del codice sorgente? Oppure possono rispettare semplicemente facendo revisioni manuali del codice per qualsiasi base di codice che hanno? Se riescono a scappare facendo revisioni manuali del codice, in che modo entra in gioco OWASP Top 10?

Ricorda che non hanno WAF in posizione.

Rif: link

    
posta avakharia 30.07.2015 - 00:03
fonte

2 risposte

1

È un requisito PCI DSS avere un ciclo di vita sicuro per lo sviluppo del software. Requisito 6.3.2 afferma:

6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following:

  • Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices.
  • Code reviews ensure code is developed according to secure coding guidelines
  • Appropriate corrections are implemented prior to release.
  • Code-review results are reviewed and approved by management prior to release.

Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle. Code reviews can be conducted by knowledgeable internal personnel or third parties. Public-facing web applications are also subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6.

e 6.6 indica WAF (che non hanno) o:

Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes

Una delle opzioni di 6.6 è

Requirement 6.6 Option 1 – Application Code Reviews

...

  1. Manual review of application source code

Quindi, per soddisfare entrambi i requisiti, è possibile effettuare revisioni manuali del codice.

How does the OWASP Top 10 come into play?

Torna alla versione 6.3.2, em me:

Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices.

6.5 segue su questo (em me):

6.5 Address common coding vulnerabilities in software-development processes as follows:

  • Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory.

    • Develop applications based on secure coding guidelines.

Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements

Pertanto, devono eseguire le revisioni del codice con le linee guida del settore come OWASP in mente. Le loro politiche PCI dovrebbero indicare quale serie di linee guida vengono seguite durante lo sviluppo e le revisioni del codice.

Dichiarazione di non responsabilità standard: non sono un QSA, né più importante, il tuo QSA

    
risposta data 03.08.2015 - 13:13
fonte
3

Scansione e recensioni di codici manuali

Il software in-house personalizzato è in-scope per la conformità PCI se si occupa di dati PAN. PCI DSS, Requisito 6.6 esprime due opzioni per gli sviluppatori interni di software che gestiscono i dati PAN: è possibile eseguire revisioni del codice o implementare un firewall per applicazioni Web (WAF). Naturalmente, specifica la natura delle opzioni per la revisione del codice o WAF e gli standard minimi per la conformità quando si utilizza una delle due opzioni.

Quindi, è possibile scegliere di utilizzare il percorso di revisione del codice o eseguire il percorso del firewall dell'applicazione Web per ottenere la conformità.

Recensioni del codice

Il PCI DSS afferma che sono disponibili quattro opzioni per le revisioni del codice conformi:

  1. Manual review of application source code
  2. Proper use of automated application source code analyzer (scanning) tools
  3. Manual web application security vulnerability assessment
  4. Proper use of automated web application security vulnerability assessment (scanning) tools

Pertanto, un processo di revisione "manuale" (che descrivi) è sufficiente a condizione che copra i requisiti menzionati più avanti in PCI DSS Sezione 6.6. , in particolare che viene eseguito da qualificati e incorporati nello SDLC.

Naturalmente, si può anche scegliere di utilizzare uno strumento automatico; a condizione che lo strumento funzioni anche per soddisfare i requisiti. Molte organizzazioni sceglieranno di utilizzare una combinazione di revisioni sia automatizzate che manuali, che forniranno una sicurezza più reale rispetto al semplice fatto di essere sufficienti per la conformità.

OWASP Top 10

La menzione di OWASP Top 10 è orientata verso la seconda opzione, i firewall a livello di applicazione. Lo standard PCI DSS afferma che, poiché uno dei requisiti per un firewall di un'applicazione Web è da considerarsi conforme, deve:

React appropriately (defined by active policy or rules) to threats against relevant vulnerabilities as identified, at a minimum, in the OWASP Top Ten and/or PCI DSS Requirement 6.5.

Se stai facendo il percorso di revisione del codice "Opzione 1", non devi preoccuparti del materiale WAF per mantenere la conformità.

Tuttavia, molte organizzazioni sceglieranno di utilizzare entrambe le revisioni del codice "Opzione 1" e di implementare un firewall per applicazioni Web, che aumenterà considerevolmente la sicurezza dell'organizzazione, pertanto le opzioni non si escludono a vicenda. È solo che la selezione di un'opzione è abbastanza buona, per ora, per raggiungere la conformità.

Compliant non significa sempre sicuro

Spetta a te determinare se "compliant" sia o meno sufficiente per essere "sicuro" e quali sono i rischi di una violazione nel tuo software, e in quanto tale, quante risorse dovrebbero essere investite per assicurarlo correttamente.

    
risposta data 30.07.2015 - 00:18
fonte

Leggi altre domande sui tag