En este artículo les presentamos, de acuerdo a nuestra experiencia, los errores comunes que cometen las empresas al implementar el requisito 6 del estándar PCI DSS: “Desarrolle y Mantenga Sistemas y Softwares Protegidos”. Asimismo, les recomendaremos factores claves que deben tener en cuenta para su cumplimiento.
Previamente, vamos a señalar de manera general algunos requerimientos comprendidos en el Desarrollo Seguro:
- Desarrollar aplicaciones de manera segura
- Capacitar a los desarrolladores sobre la seguridad del software
- Incorporar la Seguridad de la Información durante todo el ciclo de vida del desarrollo del software.
- Revisar el código personalizado antes de enviarlo a producción.
- Separar los entornos de desarrollo/prueba de producción.
- Desarrollar aplicaciones basadas en directrices de codificaciones seguras centrándose en impedir o mitigar los ataques de softwares comunes.
- Gestionar Vulnerabilidades y parches de seguridad
Ahora bien, algunos de los errores más comunes que cometen las empresas en el cumplimiento del requisito 6 son:
- No incorporar la Seguridad de la Información desde la definición de requisitos y el diseño de la aplicación.
- No contar con evidencia de que la Seguridad de la Información ha sido considerada durante todo el ciclo de vida del desarrollo.
- Adquirir aplicaciones de terceros que no han sido desarrollado de manera segura acorde a lo que establece PCI DSS.
- Las personas a cargo del desarrollo de la aplicación desconocen de buenas prácticas de codificación segura.
- Las personas a cargo de las revisiones de código carecen de conocimientos suficientes de prácticas de codificación segura.
- El desarrollo de la aplicación se pasa al ambiente de producción sin haber revisado que el código haya sido desarrollado siguiendo las directrices de codificación segura.
- La aplicación pasa al ambiente de producción sin haber resuelto las vulnerabilidades detectadas durante la revisión de código seguro.
- Los datos de producción se usan en el entorno de desarrollo/prueba.
- Al realizar un cambio significativo en la aplicación, no se identifican ni se implementan todos los requisitos pertinentes de PCI DSS.
Frente a esto, les compartimos lo que, de acuerdo a nuestra experiencia, consideramos factores claves de éxito para cumplir con el Requisito 6:
- Establecer un marco de gobierno de desarrollo seguro de las aplicaciones que comprende: políticas, estrategias, métricas, procedimiento de desarrollo seguro según estándares internacionales aceptados por la industria.
- Considerar los requisitos de seguridad desde la definición y el diseño de la aplicación. Es muy importante realizar la evaluación de riesgos y revisar la arquitectura de seguridad.
- Establecer procesos en que se incluya la Seguridad de la Información en todo el ciclo de vida del desarrollo.
- En caso de adquirir aplicaciones de terceros se debe asegurar de que se encuentre en cumplimiento de PCI DSS. El PCI SSC admite el uso de software de pago seguro dentro de entornos de datos de titulares de tarjetas (CDE) a través del Marco de seguridad de software (SSF), que consta del Estándar de software seguro y el Estándar del ciclo de vida del software seguro (Secure SLC).
- Mantener evidencias (Sistema de tickets, correos, actas, formatos de requerimientos, plantillas de pruebas, informes, reportes de herramientas, etc.) que permitan acreditar que la Seguridad de la Información se incluye en todo el ciclo de vida de desarrollo.
- Realizar pruebas de seguridad o ethical hacking, que incluyan la verificación de las vulnerabilidades de codificación comunes, cuando la aplicación se encuentre en la fase de prueba; aunque, también sería recomendable realizarla durante la fase de desarrollo.
- Revisar que el código de la aplicación cumpla con las directrices de codificación segura; por ejemplo, la guía de revisión del código OWASP.
- Capacitar al personal a cargo del desarrollo y a los responsables de la revisión de código en “codificación de desarrollo seguro” con la finalidad de que puedan identificar y solucionar los problemas relacionados con las vulnerabilidades de codificación comunes u otras que pueden ser aprovechadas por un atacante.
Autor: Marco Palomino
PMP, PCIP, CISM
