Exploración de código fuente - Requisito de PCI - Proveedor de servicios

Es un requisito de PCI DSS tener un ciclo de vida de desarrollo de software seguro. Requisito 6.3.2 declara:

  

6.3.2 Revise el código personalizado antes del lanzamiento a producción o a los clientes para identificar cualquier vulnerabilidad potencial de codificación (ya sea utilizando   procesos manuales o automatizados) para incluir al menos lo siguiente:

     

• Los cambios en el código son revisados por individuos que no son los originarios   autor del código, y por individuos conocedores del código-revisión   Técnicas y prácticas seguras de codificación.
  
• Las revisiones de código aseguran que el código es   Desarrollado de acuerdo con las pautas de codificación segura
  
• apropiado   las correcciones se implementan antes del lanzamiento.
  
• resultados de revisión de código   son revisados y aprobados por la gerencia antes de su publicación.
  

Nota: Este requisito para revisiones de código se aplica a todos los códigos personalizados   (tanto interno como público), como parte del desarrollo del sistema   ciclo vital. Las revisiones del código pueden ser realizadas por expertos internos   Personal o terceros. Las aplicaciones web orientadas al público también son   sujeto a controles adicionales, para hacer frente a las amenazas en curso y   Vulnerabilidades después de la implementación, como se define en PCI DSS.   Requisito 6.6.

y 6.6 establecen WAF (que no tienen) o:

  

Revisión de aplicaciones web de orientación pública mediante manual o automatizado   herramientas o métodos de evaluación de seguridad de vulnerabilidad de la aplicación, a   menos anualmente y después de cualquier cambio

Una de las opciones dentro de 6.6 is

  

Requisito 6.6 Opción 1 - Revisiones de códigos de aplicación

     

...

     

1. Revisión manual del código fuente de la aplicación
  

Para cumplir ambos requisitos, pueden llevar a cabo revisiones manuales de códigos.

  

¿Cómo entra en juego el Top 10 de OWASP?

Volver a 6.3.2, em me:

  

Los cambios en el código son revisados por individuos que no son los originarios   autor del código, y por individuos conocedores del código-revisión   Técnicas y prácticas de codificación seguras .

6.5 sigue esto (em me):

  

6.5 Abordar las vulnerabilidades comunes de codificación en los procesos de desarrollo de software de la siguiente manera:

     

• Capacitar a los desarrolladores en técnicas de codificación seguras,   incluyendo cómo evitar vulnerabilidades comunes de codificación, y   entender cómo se manejan los datos confidenciales en la memoria.

       
  • Desarrollar   aplicaciones basadas en directrices de codificación seguras.
    
  

Nota: La   Las vulnerabilidades enumeradas en 6.5.1 a 6.5.10 estaban actualizadas con   mejores prácticas de la industria cuando se publicó esta versión de PCI DSS.   Sin embargo, como las mejores prácticas de la industria para la gestión de vulnerabilidades son   actualizado (por ejemplo, la guía OWASP , SANS CWE Top 25, CERT Secure   Codificación, etc.), se deben utilizar las mejores prácticas actuales para estos   requisitos

Por lo tanto, deben llevar a cabo sus revisiones de código teniendo en cuenta las pautas de la industria, como OWASP. Sus políticas de PCI deben indicar qué conjunto de pautas se siguen durante el desarrollo y las revisiones de código.

_{Descargo de responsabilidad estándar: No soy un QSA, y lo que es más importante, su QSA}

Revisiones de escaneo versus códigos manuales

El software interno, construido a medida, está dentro del alcance para el cumplimiento de PCI si se trata de datos PAN. PCI DSS, Requisito 6.6 expresa dos opciones para desarrolladores internos de software que manejan datos PAN: hacer revisiones de código o implementar un firewall de aplicación web (WAF). Por supuesto, especifica la naturaleza de las opciones para las revisiones de código o WAF y los estándares mínimos de cumplimiento al usar cualquiera de las dos opciones.

Por lo tanto, uno puede elegir utilizar la ruta de revisión de código o hacer la ruta del firewall de la aplicación web para lograr el cumplimiento.

Revisiones de código

El PCI DSS establece que hay cuatro opciones disponibles para las revisiones de códigos compatibles:

  

1. Revisión manual del código fuente de la aplicación
  
2. Uso adecuado de las herramientas del analizador de código fuente de la aplicación automatizada (escaneo)
  
3. Evaluación manual de la vulnerabilidad de seguridad de la aplicación web
  
4. Uso adecuado de la evaluación automatizada de vulnerabilidad de seguridad de la aplicación web   (escaneando) herramientas
  

Por lo tanto, un proceso de revisión 'manual' (que usted describe) es suficiente siempre que cubra los requisitos mencionados más adelante en PCI DSS Sección 6.6. , en particular que lo realiza alguien calificado e incorporado al SDLC.

Por supuesto, uno puede elegir usar una herramienta automatizada también; Siempre y cuando esa herramienta también funcione para satisfacer los requisitos. Muchas organizaciones elegirán utilizar una combinación de revisiones tanto manuales como automatizadas, lo que brindará más seguridad en el mundo real que simplemente ser lo suficientemente bueno para el cumplimiento.

Top 10 de OWASP

La mención de OWASP Top 10 está orientada hacia la segunda opción, los cortafuegos de nivel de aplicación. El PCI DSS establece que, como uno de los requisitos para que un firewall de una aplicación web se considere compatible, debe:

  

Reaccionar adecuadamente (definido por una política o reglas activas) ante amenazas contra   vulnerabilidades identificadas, como mínimo, en el OWASP Top Ten y / o PCI   Requisito DSS 6.5.

Si está realizando la ruta de revisión del código de la "Opción 1", entonces no necesita preocuparse por el material WAF para mantener el cumplimiento.

Sin embargo, muchas organizaciones elegirán usar tanto las revisiones de código de la "Opción 1" como implementar un firewall de aplicación web, lo que aumentará considerablemente la seguridad de la organización, por lo que las opciones no se excluyen mutuamente. Es solo que la selección de una opción es suficiente, por ahora, para lograr el cumplimiento.

El cumplimiento no siempre significa seguro

Depende de usted determinar si "cumplir" es suficiente o no para ser "seguro" y cuáles son los riesgos de una infracción en su software, y como tal, la cantidad de recursos que se deben invertir para asegurarlos adecuadamente.