La estructura de PCI S3 contará con tres documentos principales:

 Requerimientos de seguridad de software («Software Security Requirements»):

Controles específicos para software de pago para proteger de forma adecuada la
integridad y confidencialidad de las transacciones de pago y sus datos asociados.

 Requerimientos de seguridad del ciclo de vida de desarrollo de software

(«Secure Software Life Cycle Requirements»): Controles de seguridad para
empresas desarrolladores de software de pago para gestionar de forma efectiva la
seguridad en el desarrollo durante todo el ciclo de vida de sus aplicaciones.

 Visión general del marco de trabajo PCI S3 («S3 Framework Overview»): Un

documento en donde se describirá a alto nivel el marco de trabajo propuesto y su
programa de validación relacionado.
¿Cómo cumplir con PCI DSS Req 6.3?

Si procesa, transmite o almacena datos de tarjetas de crédito en su software, es probable que esté
sujeto al Estándar de seguridad de datos de la industria de tarjetas de pago (PCI DSS). Una de las
secciones más onerosas de PCI DSS es el requisito 6: desarrollar y mantener sistemas y
aplicaciones seguros. En particular, PCI DSS 6.3 requiere que las organizaciones "... incorporen la
seguridad de la información durante todo el ciclo de vida de desarrollo de software [SDLC] ...". Un
procedimiento de prueba específico para los auditores es "Examinar los procesos de desarrollo de
software escritos para verificar que la seguridad de la información se incluya durante todo el ciclo
de vida". Si tiene un auditor no tan estricto, simplemente escribir que incorpora seguridad en el
SDLC en la documentación sin practicarlo realmente puede ser suficiente (esto a menudo sucede
en la práctica). Sin embargo, los auditores más rigurosos pueden profundizar y exigir pruebas de
que está incorporando seguridad de la información en todo el SDLC para PCI DSS 6.3. Las
organizaciones generalmente recurren a los siguientes tipos de evidencia

Mostrar resultados de análisis y / o análisis de seguridad

Mostrar prueba de que los desarrolladores han recibido capacitación en seguridad

Claramente, sin embargo, esto no cubre el espectro de todo el SDLC. Puede proporcionar una
prueba real de un SDLC seguro haciendo lo siguiente:

Proporcione un conjunto documentado de requisitos de seguridad específicos de la aplicación

dentro de un documento / PDF de Word de especificación de requisitos, la herramienta de gestión
del ciclo de vida de la aplicación o la herramienta de gestión del ciclo de vida de la aplicación
segura

Proporcionar los resultados de un proceso de auditoría de código.

Proporcione evidencia de que los requisitos fueron probados, ya sea utilizando las mismas
herramientas del paso 1 o resultados de una solución de prueba como HP Quality Center que
define los scripts / pasos que los probadores siguieron y los resultados de las pruebas.

Seguir estos pasos es un gasto inteligente en el cumplimiento de PCI, ya que no solo cumplirá con
PCI DSS 6.3, sino que también reducirá el costo de proteger sus sistemas con los requisitos de
seguridad del software.
Aplicación de software segura definida

El requisito 6.3 de PCI se centra en el ciclo de vida de desarrollo de software o SDLC. El requisito
6.3 de PCI establece que todas las aplicaciones de software internas y externas deben
desarrollarse de forma segura, de acuerdo con las PCI DSS, las mejores prácticas de la industria y
con la seguridad de la información incorporada.

Una aplicación de software desarrollada de forma segura debe tener varias capacidades. Debe
poder funcionar en una aplicación o sistema operativo reforzado. La aplicación debe cifrar datos
confidenciales en el almacenamiento y en la transmisión. Debe funcionar en un sistema que
admita antivirus. El software desarrollado de forma segura admite controles de autenticación.
También debe poder parchearse y actualizarse continuamente.

Cómo desarrollar aplicaciones de software seguras

Las aplicaciones de software seguras deben desarrollarse de acuerdo con las mejores prácticas de
la industria. Hay varias metodologías de desarrollo para trabajar (Waterfall, Scrum), pero de
acuerdo con PCI DSS, la mejor manera de garantizar que desarrolle aplicaciones de software de
forma segura es incorporar la seguridad de la información en varias fases de su proceso de
desarrollo: recopilación de requisitos, diseño, desarrollo, y pruebas.

1. Recopilación de requisitos: su organización debe dedicar tiempo a identificar los requisitos

de especificaciones funcionales y técnicas que una aplicación necesita para operar.
2. Diseño: el método de su organización para diseñar una aplicación debe garantizar que se
desarrolle de acuerdo con las especificaciones de requisitos mencionadas en la fase
anterior.
3. Desarrollo: los desarrolladores deben desarrollar códigos seguros. Su organización debe
capacitar a su personal, al menos anualmente, sobre cómo desarrollar un código seguro.
4. Pruebas: esta fase garantiza que una aplicación se endurezca por completo antes de que
entre en producción. Un asesor reunirá sus casos de prueba para verificar que las
especificaciones de requisitos, las funciones de diseño y las funciones de seguridad
incorporadas sean seguras.

Si la seguridad de la información no se incorpora en cada una de estas fases, las vulnerabilidades

de seguridad podrían introducirse de manera involuntaria o maliciosa en el entorno de
producción. En producción, el PCI DSS requiere la separación de tareas para asegurar aún más la
aplicación de software. El entorno de desarrollo debe estar separado de la producción, así como
los desarrolladores deben estar separados de los gerentes de producción.
El objetivo del Requisito 6 de PCI es mantener un entorno seguro alrededor de sus aplicaciones.
Como parte de esto, donde 6.1 y 6.2 están identificando sus vulnerabilidades y luego parcheando
sus sistemas, llegamos al Requisito 6.3. 6.3 se centra en mantener un ciclo de vida de desarrollo de
software. El SDLC, o ciclo de vida de desarrollo de software, debe desarrollarse de acuerdo con el
PCI DSS. No creo que muchas personas realmente entiendan lo que esto significa dentro de este
entorno o dentro del alcance de PCI, y hablaré de eso en un momento. Su SDLC debe basarse en
una práctica recomendada de la industria, y también hablaré sobre eso. Necesitamos asegurarnos
de que la seguridad se incorpore a lo largo de ese ciclo de vida.

Comencemos hablando sobre cómo el PCI DSS puede ser parte de su SDLC y lo que eso significa.
Debemos asegurarnos de que, cuando se desarrolle una aplicación, esa aplicación se pueda poner
en producción, se pueda endurecer por completo y sea totalmente compatible con todos los
requisitos de las PCI DSS. Por lo general, la orientación que les doy a los clientes cuando estoy
trabajando con ellos es: debe funcionar en una aplicación o sistema operativo reforzado y que
funcione completamente. Necesita encriptar los datos en almacenamiento y transmisión. Necesita
operar en un sistema que soporte antivirus. Necesitamos poder parchearlo y actualizarlo. Necesita
soportar controles de autenticación. A medida que avanzamos por el PCI DSS, cada uno de estos
controles tiene algún aspecto de la gestión del entorno de la tarjeta de crédito. Queremos
asegurarnos de que las aplicaciones que está desarrollando admitan ese entorno seguro y
protegido.

Lo siguiente de lo que habla el PCI DSS es que las aplicaciones deben desarrollarse de acuerdo con
las mejores prácticas. Eso es bastante fácil. Google busca SDLC y hay Cascada, Scrum y muchas
otras metodologías de desarrollo que puedes usar. Efectivamente, lo que estamos buscando son
varias fases, desde una perspectiva de evaluación.

La primera fase es la recopilación de requisitos. Lo que estamos buscando es que su organización

haya pasado tiempo con las unidades de negocios para identificar cuáles son los requisitos
funcionales y técnicos de las especificaciones que esta aplicación necesita para operar. Donde
encontramos que la mayoría de las organizaciones fallan es en el hecho de que realmente nunca
pasaron el tiempo para reunir los requisitos de seguridad. Entonces, tenemos la fase de requisitos.

El siguiente es el diseño. Luego buscamos el método y significa que usted ha utilizado el diseño de
esta aplicación para asegurarse de que esta aplicación se desarrollará de acuerdo con las
especificaciones que haya requerido. Tenemos consideraciones de diseño en torno al cifrado, la
autenticación (cómo puede autenticarse). También tenemos todos los requisitos de contraseña;
¿vas a permitir que la aplicación se autentique de forma nativa, o vas a conectarla a tu servidor de
autenticación? Hay muchas cosas que buscamos en términos de la fase de diseño, pero lo que
estamos buscando es que haya diseñado para cumplir con las especificaciones de seguridad que se
han llamado desde su fase de requisitos.

Entonces tenemos requisitos, tenemos diseño, y ahora entramos en desarrollo. En la fase de

desarrollo de su SDLC, queremos asegurarnos de que sus desarrolladores estén desarrollando
códigos seguros. ¿Como hacemos eso? Analizamos tu programa de entrenamiento. Un requisito es
que capacite a su personal, al menos anualmente, sobre cómo desarrollar un código seguro.
Hablaremos de ese requisito en breve.

Después de desarrollar esa aplicación, pasamos a una fase de prueba. Desde una perspectiva de
evaluación, solicitamos sus casos de prueba, mostrándome que todos los requisitos de seguridad y
todas las funciones de diseño y seguridad que ha diseñado se realizan de forma segura y que en
realidad cumple con todos esos requisitos. Una vez más, la intención es que después de que la
aplicación se haya desarrollado y puesto en producción, esta aplicación se haya endurecido por
completo.

Pasamos de requisitos, diseño, desarrollo, prueba y ahora pasamos a producción. Como parte de
su SDLC, buscamos los métodos y medios de cómo empuja esa aplicación a la producción de
manera segura. El requisito 6 requiere que tengamos una separación de deberes. Hay un par de
lugares donde se habla de la separación de tareas, pero específicamente dice que tenemos un
lugar separado para entornos de desarrollo de la producción, y personas separadas en desarrollo
que se utilizan para la gestión o la producción.

Por último, como parte de un SDLC, tenemos el final de la vida. Como asesor, realmente no
cuestionamos lo que está haciendo durante esas fases. Es posible que deseemos asegurarnos de
que esté cubriendo todos los atributos de seguridad necesarios y que esos atributos de seguridad
cumplan con todos los requisitos de seguridad establecidos por el PCI DSS. Incluso si desarrolla la
aplicación, estas aplicaciones deben desarrollarse de tal manera que sean seguras cuando se
pongan en producción y sin ninguna vulnerabilidad.
El Estándar de seguridad de datos de la industria de tarjetas de pago (PCI DSS) tiene 12 requisitos
principales, pero dentro de ellos tiene una multitud de requisitos secundarios. Si bien muchos de
estos son sencillos, hay varios que pueden dejar incluso perplejo a la persona tecnológicamente
inteligente.

El desarrollo seguro de aplicaciones de software es uno de esos requisitos. A menudo encuentro

clientes desafiados con los detalles específicos que rodean el requisito 6.3 de PCI DSS, que se
enfoca en el Ciclo de Vida de Desarrollo de Software (SDLC) cuando una compañía está
desarrollando software que interactúa con los datos del titular de la tarjeta.

El requisito 6.3 especifica:

Desarrolle aplicaciones de software internas y externas (incluido el acceso administrativo basado

en la web a las aplicaciones) de forma segura, de la siguiente manera:

De acuerdo con PCI DSS (por ejemplo, autenticación y registro seguros).

Basado en estándares de la industria y / o mejores prácticas.

Incorpore seguridad de la información durante todo el ciclo de vida del desarrollo de software.

Desarrollo de software seguro según el requisito 6.3

Si bien 6.3 es a menudo uno de los requisitos más ignorados dentro del DSS, se puede aprovechar
para madurar sus esfuerzos de desarrollo de software. Por lo tanto, analicemos este requisito
punto por punto.

Punto de viñeta 1: [Desarrollar software] de acuerdo con PCI DSS.

La intención aquí es que cuando una aplicación entra en producción, se puede colocar en un
entorno y una función completamente reforzados, así como operar, de manera compatible con
PCI. Esto significa que todos los requisitos que encontramos en PCI DSS 1 a 8, más 10, cuando
corresponda, deben integrarse en el software. Los ejemplos incluyen el enmascaramiento de los
datos del titular de la tarjeta, el cifrado, la autenticación, el registro, la transmisión segura, etc.

Bullet Point 2: [Desarrollar software] basado en estándares de la industria y / o mejores prácticas.

El objetivo de esta viñeta es que, al desarrollar software, la organización debe tener una actividad
de seguridad dirigida y tener en cuenta las vulnerabilidades conocidas; la seguridad no puede ser
una ocurrencia tardía o por casualidad.

Es imperativo que todos los desarrolladores comprendan el marco de seguridad contra el que
intentan desarrollarse defensivamente. El PCI DSS llama a OWASP; sin embargo, esto se centra
solo en las 10 principales vulnerabilidades de las aplicaciones basadas en la web. Por lo tanto,
también recomiendo echar un vistazo al CWE Top 25 como marco de seguridad.

Punto 3: incorpore la seguridad de la información a lo largo del ciclo de vida del desarrollo de
software.

A menudo escucho: "Usamos OWASP como nuestro SDLC"; sin embargo, es importante
comprender que el SDLC es un "ciclo de vida de desarrollo de software", mientras que el OWASP
SKF es un marco de seguridad. Si bien están relacionados, son diferentes. La mayoría de las
organizaciones probablemente utilizarán una metodología de desarrollo basada en AGILE, JAD /
RAD, Waterfall o alguna variante de estas.

Las fases del desarrollo de software seguro

Desde la perspectiva de PCI DSS, no importa qué metodología se use para desarrollar software
siempre que existan estas fases de desarrollo distintas:

Requisitos: en Agile, a menudo escuchamos los requisitos llamados "historias", pero estas historias
definen el estado final. En algunos casos, los requisitos se documentan como lo haría una política
(es decir, "la aplicación debe cifrar los datos en reposo"). Realmente no importa cómo los llames,
porque todos son lo mismo: los requisitos definen cómo funcionará la aplicación. En una tienda de
desarrollo madura, veremos "especificaciones de usuario, requisitos de especificaciones técnicas";
sin embargo, al observar los requisitos específicos, vamos a querer ver los requisitos de seguridad.
Esto refleja tanto el primer como el segundo puntos anteriores. También tenga en cuenta que los
requisitos deben cubrir los requisitos de PCI DSS aplicables, como se discutió anteriormente.

Diseño: en la fase de diseño de un SDLC, buscamos garantizar que los requisitos de seguridad que
se mencionaron en la fase de requisitos se diseñen en la aplicación. Además, no olvide comprobar
que el diseño en sí se basa en prácticas seguras (requeridas en los puntos 1 y 2 anteriores).
Cuando se realiza el diseño, generalmente debe haber una bifurcación para la fase de Prueba y la
fase de Desarrollo . Se requeriría que el equipo de prueba desarrollara sus guiones de prueba y
casos de prueba. Esto lleva tiempo, por lo que la mayoría de las organizaciones comenzarán esto
como parte de la fase de diseño, ya que están "diseñando los casos de prueba" para la aplicación.

Desarrollo: durante esta fase queremos asegurarnos de que los codificadores hayan recibido
capacitación en desarrollo de código seguro en el último año. También recomiendo saber lo
suficiente sobre cómo desarrollar software para saber cuándo las respuestas proporcionadas son
suficientes. Las pruebas para esto se encuentran en los requisitos de PCI DSS 6.5.1 a 6.5.10.
Cuando proporcione capacitación de código seguro anual a su personal, asegúrese de conservar
evidencia de que la capacitación se llevó a cabo y cubrió los atributos necesarios para defender sus
aplicaciones desarrolladas contra el ataque

Prueba: Hay dos formas de saber que la aplicación es segura cuando entra en producción: 1) El
equipo de prueba ha revisado el código fuente y / o ha realizado las pruebas empíricas apropiadas
para demostrar que la aplicación es segura, y 2) La prueba se ejecutó contra los requisitos para
garantizar que los requisitos de seguridad previamente identificados se hayan cumplido y se
implementen correctamente. Debe estar preparado para presentar registros de revisión de
código, evaluaciones de seguridad automáticas o manuales, casos de prueba de aceptación de
seguridad / regulación y resultados de cada uno, demostrando que La aplicación es segura y está
libre de vulnerabilidades.

Etapa: esta fase de desarrollo es donde buscamos asegurarnos de que haya SOD (segregación de
funciones) entre el personal de producción y el personal de desarrollo. Buscamos asegurar que el
personal de desarrollo no pueda entrar en producción y el personal de producción no pueda
entrar en desarrollo. También hay diferentes redes. Este control está destinado a garantizar que el
código no se promocione a producción sin los controles de seguridad correctos definidos por el
SDLC. El argumento contrario a esto es a menudo: "Somos una tienda unipersonal, por lo que no
tenemos SOD". Si encuentra esto, estoy feliz de tener una conversación sobre cómo superar este
desafío.

End of Life (EOL): la última fase de un SDLC es EOL. En esta fase, buscamos información para
definir cómo se da de baja la aplicación para garantizar que cualquier dato residual del titular de la
tarjeta se maneje / elimine de forma segura. Los detalles aquí están algo capturados en el
requisito 9.8 de PCI DSS.

Con suerte, los consejos que he proporcionado aquí lo ayudarán a establecer el camino para
cumplir con el requisito 6.3 de PCI DSS. Haga clic aquí para obtener más información sobre el
desarrollo de software seguro y cómo su empresa podría beneficiarse de una evaluación del ciclo
de vida del software seguro con certificación PCI.