PCI DSS 11.3: Pentest Methodology

As commented in the previous post, one of the new requirements of the PCI DSS v3 is to have a procedure that describes the methodology to be followed in conducting the  internal and external pen-test. I have developed a sample procedure that can be easily adapted to the specific casuistry of your Organization in order to meet the requirement 11.3 of the standard.

I hope you find it useful, and any comments or ideas for improvement are welcomed.
 

1. Introduction

 1.1 . Objectives

The purpose of this document is to establish a methodology for planning , implementation and review of the penetration testing to be performed annually in the Organization. This methodology, based on NIST SP 800-115 standard will follow a consistent and repeatable process in each of these tests , ensuring the quality and reliability of these.The responsibility for carrying out these intrusion tests annually is of XXXX department. The tests can be executed both by internal staff as always outsiders and when executed by specialists in testing intrusion that have the experience and knowledge .Finally , it should be noted that the purpose of the tests to be performed will identify vulnerabilities that could be exploited by an attacker to compromise the security of the systems of the Organization thereby compromising the confidentiality, integrity or availability of information stored, processed or transmitted by these.Note that this method includes all the minimum requirements set by the requirement 11.3 of the PCI DSS standard .

 1.2 . Scope

The scope of the penetration test includes the following elements :

• External intrusion test, i.e. analysing the vulnerabilities that could be exploited by an attacker is located in the Internet:

• Black box tests: with no users or prior information.

• Grey box tests: not users, but having the details of the applications and the infrastructure of the organization perimeter .

• White box test: With users to access systems, application or authenticated areas that want to be tested.

• Internal intrusion, i.e. analyzing the vulnerabilities that could be exploited by an attacker with access to the internal network of the organization:

• Black box tests:with no users or prior information.

• Gray box tests: not users, but having the network diagram of the organization. Additionally, if there are several network segments used by users with different levels of privileges (eg, normal users and admin users ) are allowed to perform audit tests from various network segments.

• White box tests: tests with domain users, system users or application users. The method to follow is to asign same profiles and access privileges to auditors who are assigned to the users you want to check the level of system security. For example , if we want to see is what a provider can leverage vulnerabilities to compromise the security of our organization, should be assigned to audit users with the same profile and privileges assigned to that provider.

• Exploitability tests. For vulnerabilities identified in internal and external pentest these tests should check if you really are exploitable considering that the following conditions are met:

• It was determined that the risk of executing the exploit is acceptable . Keep in mind that running an exploit always carries some risk of causing a denial of service or instability on the target system or application.

• There is a publicly available exploit for the vulnerability.

• Can be generated as an exploit at a time and with reasonable effort into the planning of the tests performed.

• Documentation of the tests performed, the findings, their evidence, the conclusions reached and the recommendations made to address the vulnerabilities identified during testing.

• Re-test and capture evidence after the resolution of each of the vulnerabilities reported during testing.

 1.3 . Assumptions and limitations

This section should be identified (if any) the assumptions or limitations applicable, both the organization and the team that performed the tests.
 

 1.4 . Risks

In this section should be listed the risks inherent in conducting penetration testing over the information systems of our organization. Additionally, it should be noted for each mitigation measures that will be taken. Examples might be:

Example 1#

• Risk: Denial of Service in systems or network devices because the network scans.

• Mitigation measure 1: network scans must be performed in a controlled manner. The start and end of the scan must be notify to responsible personnel to allow monitoring during testing. For any sign of trouble will abort the scan in progress.

• Mitigation measure 2: scanning tools must be configured to guarantee that the volume of sent packets or sessions established per minute does not cause a problem for network elements. In this sense, we must perform the first scans in a very controlled way and use minimum configurations that may be expanded when is evident that the configuration is not dangerous for network devices or servers in the organization.

Example 2#

• Risk: During testing, if auditors are successful in testing may have access to confidential information of the organization.

• Mitigation Measure 1: Both the provider as organization and the individual professionals involved in testing must sign confidentiality agreements in which the responsibilities assumed in case of breach are stated.

• Mitigation Measure 2: Documents and evidence generated by the audit team will have the classification of confidential information and should only be accessed by authorized staff based on the principle of need to know.

• Mitigation Measure 3: The audit team will apply all necessary measures to ensure that the confidentiality of information organization can't be compromised because of the tests performed. These measures include encryption of reports and evidence and masking of any sensitive data that is included in the reports or evidence generated .

2 Logistics

 2.1. Staff

Key staff involved in the project by the organization will be listed :

• Technical Project Manager: XXXXX
• Chief Information Security Officer: XXXXXX
• Chief Information Officer: XXXXX
• Head of Communications: XXXXX
• Responsible for web site YYYY.com: XXXXX

Telephones and emails to contact all personnel involved in the tests (both, supplier and Organization) are listed in the Annex I "contact sheets" of this document.

Is particularly important to correctly identify the  people to contact in case of major incident, both by the supplier and by the Organization.

 2.2 . Calendar

Penetration testing must include a schedule detailing where the main tasks and milestones to be achieved during testing. In this sense, they should be planned at least the following dates:

• Pre-project activities
• Meeting of Project Start
• Start and end of external tests
• Start and end of internal testing
• Project monitoring meetings
• Delivery reports
• Presentation of results
• Meeting project completion

 2.3 . Location of evidence

External intrusion tests will be performed remotely from the supplier's premises .Internal intrusion tests will be conducted in the office XXXX of the Organization. Audit team must to have access to the Organization's network.It must manage access permissions to the building early enough to ensure that the audit team can access without problems during planning period .

 2.4 . Equipment for performing the tests

All the tests will be conducted from the equipment owned by the audit team so no equipment for the execution of the tests is required.The only requirement in this regard will be to have an active network connection for each member of the audit team. Those connections must provide access to the target network segment in every case.

3 Communication strategy

 3.1 . General communication

The following meetings between the audit team and the organization will be conducted during the course of the project :

• Previous meeting

• Channel : Telephone
• Required Attendees : XXXXXX
• Optional Attendees: XXXXXX

• Kick-off Meeting

• Channel : Face to face meeting in the office of the Organization YYYYY.
• Required Attendees : XXXXXX
• Optional Attendees: XXXXXX

• Meeting Follow-up 1

• Channel : Telephone
• Required Attendees : XXXXXX
• Optional Attendees: XXXXXX

•  Meeting Update 2

• Channel : Telephone
• Required Attendees : XXXXXX
• Optional Attendees: XXXXXX

• Meeting presentation of results

• Channel : Face to face meeting in the office of the Organization YYYYY.
• Required Attendees : XXXXXX
• Optional Attendees: XXXXXX

• Closing meeting

• Channel : Face to face meeting in the office of the Organization YYYYY.
• Required Attendees : XXXXXX
• Optional Attendees: XXXXXX

 3.2 . Incident Response and Management

If an incident occurs during the execution of the tests that have an impact on the systems or services of the organization, the incident should be brought immediately to the attention of those responsible for incident management in the project. Contact phones are detailed in Annex II "Contacts Incident". This annex also includes scaling procedures to resolve the incident.

The provider will follow the instructions of the incident management team of the organization to contain and solve any impact caused by penetration testing.

Having identified an incident, penetration testing must be stopped immediately and will not be resumed until receiving authorization from the technical manager of the project.

4 . Target systems and networks

It should be noted that in order to complies with PCI DSS the scope of the test should include, at least the following :

All systems and applications that are part of the perimeter of the cardholder data environment card (CDE ).

 4.1 . Systems included in the scope

• System 1: IP: System: System Description
• System 2: IP: System: System Description
• Wifi network XXXXYYYYY
• ................

 4.2 . Applications included in the scope

• Application 1: URL: Description of the application 
• ...................

 4.3 . Systems excluded from the scope

• System 5: IP: System: System Description
• System 6: IP: System: System Description
• ....................

 4.4 . Applications excluded from the scope

• Application 3: URL: Description of the application
• .....................

  

5. Executing the tests

 5.1 . No technical evidence

Non- technical tests to be performed during penetration testing are detailed in this section. Note that some of these tests can be combined with technical tests to increase their effectiveness:

• Attempted access to the facilities of the organization without identification , posing as employees of the Organization.

• Review of bins or containers for sensitive information of the organization.

• Attempt to obtain confidential information using social engineering techniques, both onsite and telephone .

(Note that these tests are an example. Each organization can add or remove evidence of this type according to your circumstances and objectives) .

 5.2 . technical tests

Technical tests must be follow the OSSTMM methodology. Tests must be conducted at network, system and application level and must ensure that at least identifies any vulnerabilities documented by OWASP and SANS ,as well as those identified in the PCI DSS standard v3:

• Inejections: Code, SQL, OS commands, LDAP , XPath , etc.
• Buffer overflows .
• Insecure storage of cryptographic keys
• insecure Communications
• Improper error handling
• Cross -site scripting (XSS )
• Control of inappropriate access.
• Cross - site request forgery (CSRF ) .
• Broken authentication and incorrectly session management.
• Any other vulnerability considered High Risk by the organization.

Additionally, we must carry out tests to validate the effectiveness of the controls established to segment the data environment cardholders (CDE ) from other systems and networks of the Organization.

  

6. Information Management

Note that all information generated as part of the audits will be owned by the organization and will have the classification of Confidential. Therefore, it must be stored and transmitted ever in encrypted way.

Reports and evidence generated should only be accessed by authorized personnel based in the need to know principle. 
 
Information concerning the audit will be stored only for a term of X years, being securely deleted and unrecoverable after that period.

The supplier undertakes to store the information on audit only for a period of X months, thus committing itself to eliminate it safely and unrecoverable after that period.

 6.1 . evidence

For all findings or vulnerabilities identified during the tests carried out will be generated and documented sufficient evidence to prove the existence of the same. The format of the evidence can be variable in each case, screen capture, raw output of security tools, photographs, paper documents , etc.

 6.2 . deliverables

As a result of tests performed should generate a document containing at least the following sections:

1. Introduction
2. Executive Summary
3. Methodology
4. Identified vulnerabilities
5. Recommendations for correcting vulnerabilities
6. Conclusions
   Annex I: Evidence

Metodología de Test de Intrusión (Requisito 11.3 de PCI DSS)

 Tal y como comentaba en la anterior entrada, uno de los nuevos requisitos de la PCI DSS v3 consiste en disponer de un procedimiento que describa la metodología a seguir en la realización de los test de intrusión internos y externos. El presente post tiene como objetivo ayudaros a cumplir con dicho requisito, ya que he desarrollado un procedimiento de ejemplo que podrá ser fácilmente adaptado a la casuística concreta de vuestra Organización.

Espero que os sea de utilidad, y cualquier comentario o propuesta de mejora será bienvenida.

1.Introducción

1.1.Objetivos

El propósito del presente documento es establecer una metodología para la planificación, ejecución y revisión de las pruebas de intrusión a realizar con carácter anual en la Organización. Esta metodología, basada en el estándar NIST SP 800-115 permitirá seguir un proceso consistente y repetible en cada una de estas pruebas, garantizando la calidad y fiabilidad de las mismas.

La responsabilidad de llevar a cabo estas pruebas de intrusión anuales será del departamento XXXX pudiendo ser ejecutadas tanto por personal interno como por personal externo siempre y cuando sea ejecutado por profesionales especialistas en la realización de pruebas de intrusión que cuenten con la experiencia y los conocimientos necesarios.

Finalmente, cabe señalar que el propósito de las pruebas a realizar será identificar las vulnerabilidades que pudieran ser explotadas por un atacante para vulnerar la seguridad de los sistemas de la Organización comprometiendo de esta manera la confidencialidad, integridad o disponibilidad de la información almacenada, procesada o transmitida por estos.

Cabe señalar que este procedimiento incluye todos los requisitos mínimos establecidos por el requisito 11.3 del estándar PCI DSS.

1.2.Alcance

El alcance de las pruebas de intrusión incluye los siguientes elementos:

• Pruebas de intrusión externas, es decir, analizando las vulnerabilidades que podrían ser explotables por un atacante ubicado en Internet:
  • Pruebas en formato de caja negra: sin usuarios ni información previa.
  • Pruebas en formato de caja gris: sin usuarios, pero contando con el detalle de las aplicaciones y de la infraestructura perimetral de la organización.
  • Pruebas en formato de caja blanca: contando con los usuarios de aplicación o de sistemas suficientes como para acceder a las áreas autenticables accesibles desde internet que quieran ser probadas.
• Prueba de intrusión internas, es decir, analizando las vulnerabilidades que podrían ser explotables por un atacante con acceso a la red interna de la Organización:
  • Pruebas en formato de caja negra: sin usuarios ni información previa.
  • Pruebas en formato de caja gris: sin usuarios, pero contando con el diagrama de red de la organización. Adicionalmente, si existen diversos segmentos de red utilizados por usuarios con diferente nivel de privilegios (por ejemplo, usuarios normales y usuarios administradores) se permitirá a los auditores realizar las pruebas desde diversos segmentos de red.
  • Pruebas en formato de caja blanca: contando con usuarios de dominio, usuarios de sistemas o usuarios de aplicación. El método a seguir es asignar los mismos perfiles y privilegios de acceso a los auditores que los que se asignan a los usuarios para los que queremos verificar el nivel de seguridad de los sistemas. Por ejemplo, si lo que queremos ver es qué vulnerabilidades puede aprovechar un proveedor para comprometer la seguridad de nuestra organización, se les debería asignar a los auditores usuarios con el mismo perfil y privilegios que se asignarían a dicho proveedor.
• Pruebas de explotabilidad. Tanto para las vulnerabilidades identificadas en las pruebas internas como para las identificadas en las pruebas de intrusión externas, se deberá verificar si realmente son explotables siempre y cuando se den las siguientes circunstancias:
  • Se determine que el riesgo de ejecutar el exploit es asumible. Hay que tener en cuenta que la ejecución de un exploit siempre conlleva un cierto nivel de riesgo de provocar una denegación de servicio en el sistema o aplicación objetivo.
  • Exista un exploit público disponible para la vulnerabilidad.
  • Pueda generarse un exploit a medida en un tiempo y con un esfuerzo razonable dentro de la planificación de las pruebas a realizar.
• Documentación de las pruebas realizadas, los hallazgos obtenidos, sus respectivas evidencias, las conclusiones alcanzadas y las recomendaciones emitidas para solventar las vulnerabilidades identificadas durante las pruebas.
• Verificación técnica y captura de evidencia tras la resolución de cada una de las vulnerabilidades reportadas durante las pruebas.

1.3.Asunciones y limitaciones

En este apartado debería identificarse (en caso de que las hubiera) cualquier asunción o limitación que sea aplicable, tanto para la organización como para el equipo que realizará las pruebas.

1.4.Riesgos

En este apartado deberían listarse los riesgos inherentes a la realización de las pruebas de intrusión en los sistemas de información de la organización. Adicionalmente, debería indicarse para cada uno de ellos las medidas de mitigación que serán adoptadas. Algunos ejemplos podrían ser:

Riesgo: denegación de servicio en elementos de red o servidores debidos a la ejecución de escaneos de red.

Contramedida1: Los escaneos de red se realizarán de manera controlada, notificando a los responsables el inicio y finalización de los mismos para permitir su monitorización durante las pruebas. Ante cualquier indicio de problema se abortará el escaneo en curso.

Contramedida2: Se configurarán las herramientas de escaneo de tal manera que el volumen de paquetes enviados o sesiones establecidas por minuto no supongan un problema para los elementos de red de la Organización. En este sentido, será necesario realizar los primeros escaneos de manera muy controlada y utilizando configuraciones mínimas que podrán ir ampliándose en la medida que se compruebe que los volúmenes establecidos no supongan ningún perjuicio para los dispositivos de red o servidores de la Organización.

Riesgo: En el transcurso de las pruebas, si los auditores tienen éxito en las pruebas podrían tener acceso a información confidencial de la Organización.

Contramedida1: Tanto el proveedor a título de persona jurídica, como los profesionales que participen en las pruebas a título individual, deberán firmar acuerdos de confidencialidad en los que se detallen las responsabilidades asumidas en caso de incumplimiento de los mismos.

Contramedida2: Los documentos y evidencias generados por el equipo de auditoría tendrán la clasificación de información confidencial y sólo deberán ser accedido por el personal autorizado en base al principio de necesidad de conocer.

Contramedida3: El equipo de auditoría aplicará todas las medidas necesarias para evitar que la confidencialidad de la información de la organización pueda verse comprometida por culpa de las pruebas realizadas. Estas medidas incluirán el cifrado de los informes y evidencias y el enmascaramiento de todos aquellos datos especialmente sensibles que se hayan incluido en los informes o evidencias generados.

2.Logística

2.1.Personal

A continuación se listará el personal clave que participará en el proyecto por parte de la Organización:

• Responsable técnico del proyecto: XXXXX
• Director de Seguridad: XXXXXX
• Responsable de Sistemas: XXXXX
• Responsable de Comunicaciones: XXXXX
• Responsable de la aplicación YYYY.com: XXXXX

En el Anexo I “Fichas de contacto” se listarán los teléfonos y mails de contacto de todo el personal involucrado en las pruebas. tanto por parte del proveedor como por parte de la Organización. Será de especial relevancia identificar correctamente los métodos y las personas de contacto en caso de incidencia grave, tanto por parte del proveedor como por parte de la Organización.

2.2.Calendario

Las pruebas de intrusión deberán contar con un cronograma en el que se detallen las principales tareas y los principales hitos a alcanzar durante las pruebas. En este sentido, deberán planificarse como mínimo las siguientes fechas:

• Actividades previas al proyecto
• Reunión de Inicio del proyecto
• Inicio y fin de pruebas externas
• Inicio y fin de pruebas internas
• Reuniones de seguimiento del proyecto
• Entrega de informes
• Presentación de resultados
• Reunión de finalización del proyecto

2.3.Lugar de las pruebas

Las pruebas de intrusión externas se realizarán de manera remota desde las instalaciones del proveedor.

Las pruebas de intrusión internas se realizarán en la oficina XXXX de la Organización. Se deberá buscar una ubicación en la que el equipo de auditoría cuente con acceso a la red y puestos de trabajo suficientes.

Se deberán gestionar los permisos de acceso al edificio con la suficiente antelación para garantizar que el equipo pueda acceder sin problemas durante el periodo planificado.

2.4.Equipos para la realización de las pruebas

La totalidad de las pruebas será realizada desde los equipos del equipo de auditoría propiedad del proveedor por lo que no se requieren equipos para la ejecución de las mismas.

El único requisito en este sentido será el disponer de un cable de red activo para cada miembro del equipo de auditores con acceso al segmento o segmentos asignados en cada caso.

3.Estrategia de comunicación

3.1.Comunicación general

Se llevarán a cabo las siguientes reuniones entre el equipo de auditoría y la Organización durante el transcurso del proyecto:
Reunión previa
Canal: Telefónico
Asistentes necesarios: XXXXXX
Asistentes opcionales: XXXXXX
Reunión de Inicio
Canal: Presencial. En las oficina YYYYY de la Organización.
Asistentes necesarios: XXXXXX
Asistentes opcionales: XXXXXX
Reunión Seguimiento 1
Canal: Telefónico
Asistentes necesarios: XXXXXX
Asistentes opcionales: XXXXXX
Reunión Seguimiento 2
Canal: Telefónico
Asistentes necesarios: XXXXXX
Asistentes opcionales: XXXXXX
Reunión presentación de resultados
Canal: Presencial. En las oficina YYYYY de la Organización.
Asistentes necesarios: XXXXXX
Asistentes opcionales: XXXXXX
Reunión cierre
Canal: Presencial. En las oficina YYYYY de la Organización.
Asistentes necesarios: XXXXXX
Asistentes opcionales: XXXXXX

3.2.Respuesta y gestión de incidentes

En caso de que se produzca un incidente durante la ejecución de las pruebas que tenga un impacto en los sistemas o servicios de la organización, dicho incidente deberá ser puesto de inmediato en conocimiento de los responsables de la gestión de incidentes en el proyecto tanto de la Organización como del proveedor. Los teléfonos de contacto de ambos responsables se encuentran detallados en el Anexo II “Contactos ante incidentes”. En dicho anexo se incluye también el escalado a seguir para la resolución de dichos incidentes.

El proveedor seguirá las indicaciones del equipo de gestión de incidentes de la organización para contener y solucionar cualquier impacto causado por las pruebas de intrusión.

Una vez identificado un incidente, las pruebas de intrusión deberán ser detenidas de inmediato y no serán retomadas hasta recibir la autorización por parte del responsable técnico del proyecto por parte de la Organización.

4.Sistemas y redes objetivo

Cabe señalar que para que el procedimiento cumpla con PCI DSS se deberá incluir entre los sistemas y redes objetivo, al menos, los siguientes:

• Todos los sistemas y aplicaciones que formen parte del perímetro del entorno de datos de titulares de tarjeta (CDE).
  
  

4.1.Sistemas incluidos en el alcance de las pruebas

Sistema 1: IP: Sistema Operativo: Descripción del sistema
Sistema 2: IP: Sistema Operativo: Descripción del sistema
Red Wifi XXXXYYYYY
xxxxxxxxx

4.2.Aplicaciones incluidas en el alcance de las pruebas

Aplicación 1: URL: Descripción de la aplicación
xxxxxxxxxxxxxxxxxx

4.3.Sistemas excluidos del alcance de las pruebas

Sistema 5: IP: Sistema Operativo: Descripción del sistema
Sistema 6: IP: Sistema Operativo: Descripción del sistema
xxxxxxxxx

4.4.Aplicaciones excluidas del alcance de las pruebas

Aplicación 3: URL: Descripción de la aplicación
xxxxxxxxxxxxxxxxxx

5.Ejecución de las pruebas

5.1.Pruebas no técnicas

A continuación se detallarán las pruebas no técnicas que se deberán realizar durante las pruebas de intrusión. Cabe señalar que algunas de estas pruebas pueden combinarse con pruebas de tipo técnico para aumentar su efectividad:

• Intento de acceso a las instalaciones de la organización sin identificación previa, haciéndose pasar por empleados de la Organización.
  
• Revisión de papeleras o contenedores en busca de información sensible de la Organización.
  
• Intento de obtención de datos confidenciales mediante el uso de técnicas de ingeniería social, tanto presenciales como telefónicas.
  

(Cabe señalar que estas pruebas son un ejemplo. Cada Organización puede añadir o eliminar pruebas de este tipo según sus circunstancias y objetivos).

5.2.Pruebas técnicas

Las pruebas técnicas a realizar seguirán las pautas establecidas en la metodología OSSTMM. Las pruebas deberán realizarse a nivel de red, de sistemas y de aplicación y garantizar que se identifiquen, al menos, las vulnerabilidades documentadas por OWASP y SANS, así como las que se identifican en el estándar PCI DSS v3 que son las que se listan a continuación:

• Inyecciones de código, de SQL, de comandos del sistema, de LDAP, Xpath, etc..
• Buffer overflows.
• Almacenamiento inseguro de claves criptográficas
• Comunicaciones inseguras
• Gestión de errores incorrecta
• Cross-site scripting (XSS)
• Control de acceso inapropiado.
• Cross-site request forgery (CSRF).
• Rotura de autenticación y gestión de sesiones incorrecta.
• Cualquier otra vulnerabilidad considerada como de Alto Riesgo por parte de la organización.

Adicionalmente, se deberán llevar a cabo pruebas destinadas a validar la eficacia de los controles establecidos para segmentar el entorno de datos de titulares de tarjeta (CDE) del resto de sistemas y redes de la Organización.

6.Gestión de la información

Cabe señalar que toda la información generada en el marco de las auditorías será propiedad de la Organización y tendrá la clasificación de Confidencial. Por lo tanto, se deberá almacenar y transmitir siempre de manera cifrada.

Los reportes y evidencias generados tan sólo deberán ser accedidos por el personal autorizado por parte de XXXXX. Dicha autorización se realizará siempre bajo el principio de necesidad de conocer.

La información relativa a la auditoría se almacenará únicamente durante por un plazo de X años, siendo eliminada de forma segura e irrecuperable después de dicho plazo.

El proveedor se compromete a almacenar la información relativa a la auditoría únicamente por un plazo de X meses, comprometiéndose así mismo a eliminarla de forma segura e irrecuperable transcurrido dicho plazo.

6.1.Evidencias

Para todos los hallazgos o vulnerabilidades identificados durante las pruebas realizadas se generará y documentarán las evidencias suficientes para demostrar la existencia de las mismas. El formato de las evidencias puede ser variable en cada caso; capturas de pantalla, salidas de herramientas de seguridad, fotografías, documentos físicos, etc...

6.2.Entregables

Como resultado de las pruebas realizadas deberá generarse un documento que incluya, al menos, los siguientes apartados:

1. Introducción
2. Resumen Ejecutivo
3. Metodología utilizada
4. Vulnerabilidades identificadas
5. Recomendaciones para la subsanación de las vulnerabilidades
6. Conclusiones
7. Anexo I: Evidencias

Nueva PCI DSS v3

Éste mes de noviembre ha visto la luz la tercera versión de PCI DSS. El nuevo documento incorpora unos cuantos cambios respecto a la versión anterior tanto en los apartados introductorios como en los propios requisitos y procedimientos de prueba.

La mayoría de los cambios tienen como principal objetivo aclarar cuestiones que en la versión anterior se prestaban a malinterpretaciones o que habían suscitado numerosas dudas a las organizaciones o incluso a los QSA. Sin embargo, también nos encontramos con algunos cambios de mayor calado, como nuevos requisitos, requisitos modificados para hacerlos más exigentes, o modificados para dar mayor flexibilidad en su cumplimiento.

Vamos a analizar todos esos cambios de mayor importancia que incluye la nueva versión:

• Encontramos un nuevo apartado llamado “Implementing PCI DSS into Business-as-Usual” en el que se presentan una serie de buenas prácticas y recomendaciones sobre cómo se debería implementar PCI DSS de manera que se integrara en los procesos de las organizaciones. Cabe destacar que se trata justamente de una serie de buenas prácticas y que por lo tanto no son de obligado cumplimiento ni reemplazan ninguno de los requisitos de las normas PCI DSS. En un futuro 'post' entraré en detalle a analizar este apartado ya que vale la pena revisarlo en profundidad.
• Se ha modificado la tabla en la que se presentan los requisitos, de manera que ahora se incluye una columna en la que se explica la motivación de cada requisito, tal y como en la v2 se hacía en la “navigating guide”. Me parece un cambio muy positivo, ya que esta explicación permitirá en muchos casos entender de forma más completa que se está solicitando exactamente en cada requisito del estándar sin tener que ir a consultar un documento adicional.
• Se han modificado los requisitos 12.1.1 y 12.1.2 de la v2 en los que se solicitaba que todos los requisitos contasen con los procedimientos documentados necesarios. En la v3, se han eliminado incluyéndose en un apartado específico de cada uno de los 11 primeros requisitos. De esta manera no queda duda de qué procedimientos deben documentarse en cada caso.
• Se incluye el requisito 2.4 en el que se indica que la organización debe mantener un inventario de los componentes incluidos en el alcance de PCI DSS para ayudar en el uso de los estándares de configuración a aplicar por la organización para mantener la seguridad de los sistemas.
• Como ya es sabido, el requisito 5 de PCI DSS exige el uso de antivirus en todos los sistemas del alcance excepto en aquellos que se considere que no se ven afectados por malware (Mainframe, AS400, UNIX, etc... ). Como novedad, en la nueva versión se incluye el nuevo requisito 5.1.2 en el que se establece la necesidad de seguir la evolución de los riesgos debidos al malware en sistemas que habitualmente no se ven afectados por malware y en su caso sacarlos de esta categoría.
• Otro nuevo subrequisito incluido dentro del requisito 5 ha sido el 5.3 que solicita que las soluciones antivirus se mantengan activadas y no puedan ser deshabilitadas o alteradas por los usuarios.
• El requisito 6.5.10 se considerará una buena práctica no obligatoria hasta el 1 de junio de 2015. Este requisito establece que en los procedimientos y políticas de desarrollo se deben contemplar medidas que prevengan ataques contra los marcos de autenticación y la gestión de sesiones web, incluyendo los siguientes aspectos:
  • Marcar los tokens de sesión (por ejemplo las cookies) con el flag “secure”.
  • No exponer las ID de sesión en la URL.
  • Incorporar tiempos de expiración y rotación adecuados para las ID de sesión después de un login correcto.
• Se ha modificado el requisito 8.2.3 de manera que este requerimiento ahora establece los mínimos en cuanto a complejidad y tamaño de la contraseña pero permite una mayor flexibilidad en su cumplimiento. Aunque sigue exigiendo que se use una contraseña de 7 o más caracteres y que incluya tanto caracteres numéricos como alfabéticos, se da la posibilidad de utilizar otros tamaños o complejidades siempre y cuando se mantenga igual o mayor robustez en la contraseña a utilizar.
• Se ha incluido un nuevo requisito (8.5.1) que aplicará únicamente a los proveedores de servicios y que obliga a estos a utilizar credenciales diferentes para el acceso remoto a los sistemas de cada uno de sus clientes. Este requisito será considerado una buena práctica no obligatoria hasta el 1 de julio de 2015.
• El nuevo requisito 8.6 obliga a que, en caso de utilizar mecanismos de autenticación diferentes al de usuario/contraseña, estos mecanismos estén ligados de manera unívoca a cuentas de usuario individuales y garantizar que sólo el usuario apropiado pueda hacer uso de dichos mecanismos.
• El requisito 9.3 también es de nueva aparición en esta versión y establece la necesidad de controlar el acceso físico a las áreas sensibles por parte del personal 'onsite'. Así mismo, se deberá contar con procedimientos para autorizar el acceso y revocar dicho acceso de manera inmediata cuando el personal deje de prestar sus servicios en la organización.
• Otros requisitos de nueva aparición en esta versión son los que van del 9.9 al 9.9.3. Estos requisitos exigen que se protejan los dispositivos que capturan los datos de tarjeta directamente mediante la interacción física con las mismas (lectores de tarjeta, etc..). Concretamente, los requisitos solicitan que se mantenga una lista de los dispositivos existentes, que se inspeccionen visualmente de forma periódica para detectar anomalías en los mismos y que se entrene al personal para que pueda detectar si los dispositivos han sido sustituidos o manipulados.
• El requisito 10.5.2 refuerza los requisitos asociados a la generación y revisión de registros de log al requerir que se registren los cambios en los mecanismos de identificación y autenticación, incluyendo la creación de nuevas cuentas o el incremento de privilegios, como por ejemplo el uso del comando “su”.
• El 10.2.6 también se ha visto modificado para solicitar que se incluyan los eventos correspondientes a la parada o pausa de los logs de auditoría, además de la reinicialización o borrado de los logs que ya se exigía en la versión anterior.
• También se ha aumentado la exigencia del requisito 11.1.1 que ahora solicita que se documente el inventario de puntos de acceso wireless autorizados y su correspondiente justificación de negocio.
• Por su parte, el requisito 11.1.2 de nueva creación en la v3 establece la necesidad de que los procedimientos de respuesta ante incidentes detallen el curso de acción a seguir en caso de detectarse redes Wireless no autorizadas en las revisiones trimestrales.
• El requisito 11.3 es uno de los cambios más significativos de esta nueva versión. Tiene carácter de buena práctica hasta el próximo 1 de julio de 2015 fecha a partir de la cual se considerará de obligado cumplimiento. El requisito obliga a que las organizaciones cuenten con una metodología documentada a seguir para la realización de los test de intrusión anuales, tanto internos como externos, con independencia de que sean ejecutados de forma interna por personal de la propia organización o se subcontraten a una organización externa. Esta metodología deberá contemplar, al menos, los siguientes aspectos:
  • Deberá estar basada en aproximaciones aceptadas por la industria, como por ejemplo la NIST SP800-115.
  • Debe incluir en su alcance todo el perímetro de datos de titulares de tarjeta y los sistemas considerados críticos.
  • Debe incluir pruebas desde dentro y desde fuera de la red, es decir, pruebas de intrusión externas e internas.
  • Debe incluir pruebas específicas para validar que los controles establecidos para segmentar la red o para reducir el alcance de PCI DSS sean correctos y efectivos.
  • Debe incluir pruebas de penetración en la capa de aplicación incluyendo, al menos, las vulnerabilidades listadas en el requisito 6.5 de PCI DSS. Es decir, inyecciones, buffer overflows, almacenamiento inseguro de claves criptográficas, comunicaciones inseguras, gestión incorrecta de los errores, XSS, control de acceso inapropiado, Cross-site request forgery (CSFR), roturas de autenticación o de la gestión de sesiones, o en general cualquier vulnerabilidad categorizada como crítica por parte de la Organización.
  • Debe incluir pruebas de penetración en la capa de red que incluyan tanto los componentes y dispositivos de red como sistemas operativos.
  • Debe incluir la revisión de las amenazas y vulnerabilidades que hayan afectado a la organización en los últimos 12 meses.
  • Debe especificar el periodo de retención de los resultados de las pruebas de penetración y los resultados de las actividades dirigidas a remediar las vulnerabilidades detectadas.
• Adicionalmente, el nuevo procedimiento de test 11.3.b solicita que se corrijan todas las vulnerabilidades explotables encontradas durante las pruebas de intrusión y que se repitan dichas pruebas para verificar dichas correcciones.
• El requisito 11.5 también ha sido modificado para dar mayor flexibilidad en su cumplimiento. Ahora, en lugar de exigir que se instale un FIM, se solicita que se instale algún mecanismo de detección de cambios que permita alertar al personal de modificaciones no autorizadas en ficheros críticos de los sistemas, ficheros de configuración o ficheros de contenido y que se configure el software utilizado para realizar las comparaciones de estos ficheros al menos semanalmente en busca de cambios. Así mismo, el requisito 11.5.1 obliga a disponer de un procedimiento implementado para responder a cualquier alerta generada por la solución de detección de cambios que se utilice.
• Se ha modificado el requisito 12.2 (antiguo 12.1.2) de manera que ahora no sólo se exige la realización de un análisis de riesgo anual, si no también después de cualquier cambio significativo en el entorno (por ejemplo, adquisiciones, fusiones, traslados de sede, etc..).
• El nuevo requisito 12.8.5 solicita que se mantenga documentado el detalle de qué requisitos de PCI DSS son gestionados por cada proveedor de servicios contratado y cuales son gestionados directamente por la entidad.
• Y por último, el nuevo requisito 12.9 será de aplicación únicamente a los proveedores de servicio y se considerará una buena práctica hasta el 1 de julio de 2015. Este requisito obligará a los proveedores de servicios a proveer y firmar con sus clientes de un clausulado específico en el que reconozcan explícitamente su responsabilidad en la gestión de la seguridad de los datos de titulares de tarjeta de sus clientes.

En conclusión, pienso que todos los cambios incluidos en la nueva versión del estándar son positivos y que nos encontramos ante un estándar más claro, con menos zonas grises y que permitiría a las organizaciones que lo implementen no sólo cumplir con PCI DSS si no además mejorar de forma significativa la seguridad de los datos de titulares de tarjeta que almacenen, transmitan o procesen.

PCI_DSS_v3.pdf

PCI_DSS_v3_Summary_of_Changes.pdf

Twitter: @omarbenjumea

Linkedin: http://www.linkedin.com/in/omarbenjumea

PCI DSS v3.0

This November has been realised the third version of PCI DSS. The amendments include a few changes from the previous version in both the introductory paragraphs and in requirements and test procedures.

Most of the changes are aimed to clarify issues in the previous version were open to misinterpretation or had raised important questions for organizations or even QSAs.

However, we also find some more fundamental changes, such as new requirements, modified to make requirements more stringent, or also (in less cases) modified to provide greater flexibility in compliance.

We will analyse all these major changes including the new version:

• We found a new section called "Implementing PCI DSS into Business-as-Usual" in which a series of best practices and recommendations on how it should be implemented so that PCI DSS is integrated into the processes of organizations are presented. Note that this is just a series of good practice and therefore are not binding or supersede any of the requirements of PCI DSS.
• Modified the table in which the requirements, so that now a column in which the motivation of each requirement. I think it is a very positive change, and that this explanation will often understand more fully exactly is being requested in each standard requirement without going to see any additional document.
• Requirement 2.4 which states that the organization must maintain an inventory of the components included in the scope of PCI DSS to assist in the use of configuration standards.
• As is known, the PCI DSS Requirement 5 requires the use of anti-virus on all systems except reach those who are deemed unaffected by malware (Mainframe, AS400, UNIX, etc.). The new version 5.1.2 requirement stablish the need to follow the evolution of risks due to malware on systems that are not normally affected by malware and remove them from this category if it is necessary.
• Another new requirement included in the sub-requirement 5.3 has been requesting anti-virus solutions remain activated and can not be disabled or altered by users.
• 6.5.10 requirement is considered good practice not mandatory until June 1, 2015. This requirement states that the procedures and policies should include measures to prevent attacks against authentication frameworks and web management sessions, including the following:
  • Bookmark session tokens (eg cookies) with the flag "secure".
  • Do not expose the session ID in the URL.
  • Incorporate appropriate timeouts and rotation for the session ID after successful login.
• Changed the requirement 8.2.3 so now that this requirement sets minimum in complexity and size of the password but allows greater flexibility in compliance. Although still requires you to use a password of 7 or more characters and include both numeric and alphabetic characters, is given the possibility to use other sizes or complexities whatever remains the same or greater strength in the password to use.
• New requirement (8.5.1) apply only to service providers and requiring these to use different credentials for remote access to systems of each of its customers. This requirement will be considered a good practice not mandatory until July 1, 2015.
• The new requirement 8.6 mandates that, when using authentication mechanisms other than username / password, these mechanisms are univocally linked to individual user accounts and ensure that only the appropriate users can make use of these mechanisms.
• Requirement 9.3 is also new in this release and appearance establishes the need to control physical access to sensitive areas by onsite personal. Also, it must have procedures for authorizing access and revoke such access immediately in termination.
• Other new requirements in this release are ranging from 9.9 to 9.9.3. These requirements require to protect devices that capture the card data directly through physical interaction with them (card readers, etc. ..). Specifically, the requirements asking for a list of existing devices, which were visually inspected periodically to detect anomalies in the same and that is to train staff to detect if devices have been replaced or tampered keeps.
• Requirement 10.5.2 reinforces the generation and review of logs by recording changes in identification and authentication mechanisms, including the creation of new accounts or privilege scalation, such as use the "su" command.
• The 10.2.6 has also been amended to require that the events corresponding to the stop or pause the audit logs are included, in addition to resetting or deleting the logs that already required in the previous version.
• Requirement 11.1.1 now requests that the inventory of authorized wireless access points and their corresponding business justification is documented. Meanwhile, the newly created requirement 11.1.2 establishes the need for incident response procedures detailing the course of action to follow in case of detecting unauthorized wireless networks in the quarterly reviews.
• Requirement 11.3 is one of the most significant changes in this new version. Considered just a good practice until next July 1, 2015 date on which shall be considered mandatory. The requirement mandates that organizations have an annual pentest methodology. This methodology must to consider, almost, the next topics:
• Based on industry-accepted penetration testing approaches.
• Includes coverage for the entire Cardholder data Enviroment perimeter and critical systems.
• Includes testing from both inside and outside the network.
• Includes testing to validate any segmentation and scope-reduction controls.
• Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5 of PCI DSS.
• Defines network-layer penetration tests to include components that support network functions as well as operating systems.
• Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
• Specifies retention of penetration testing results and remediation activities results.
• Requirement 11.5 has also been modified to provide greater flexibility in compliance. Now, instead of requiring you install a FIM, it is requested that any mechanism that allows change detection to alert personnel of unauthorized critical system files, configuration files or content files modifications.
• Changed the requirement 12.2 (old 12.1.2) so that now not only the execution of an annual risk analysis is required, but also after any significant change in the environment (eg, acquisitions, mergers, relocations, etc. ..).
• New 12.8.5 requires to maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.
• And finally, the new requirement 12.9 apply only to service providers and will be considered a best practice until July 1, 2015. This requirement will force service providers to provide their customers and sign specific clauses which explicitly recognize their responsibility in managing the security of cardholder data from their customers. 

In conclusion, I think all the changes included in the new version of the standard are positive and that we have a clear standard, with less indefined areas and that permits those organizations that implements PCI DSS not just be compliant but also highly increment the security of card-holder data that is stored, transmitted or processed by the organization.

PCI_DSS_v3_Summary_of_Changes.pdf
PCI_DSS_v3.pdf

Twitter: @omarbenjumea

Linkedin: http://www.linkedin.com/in/omarbenjumea