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

New ISO27001:2013

Since last quarter of 2013 it is available the new version of ISO27001. This version 2013 includes many changes and the purpose of this post is to take a high-level look over them.
First, the new version fits the ISO Annex SL. This means that the distribution of sections and phases of the standard will be extremely similar to the rest of ISO standards that are also adapting to this Annex. In practice, what is proposed is that organizations can have a common management framework in which they are integrated the different ISO that have implemented.The following will list other significant changes introduced by the new version:

• The definition of context will have a key importance as the beginning of the ISMS planning.
• A new specific section to deal with the Leadership in the ISMS. Therefore, this concept will be particularly important in the transitions to the 2013 version.
• "Preventive actions" concept is replaced by "management of risks and opportunities". 
• ISO31000 is referred to as the risk management framework. Aligned with Annex SL it is intended that risk management will become homogeneous at the corporate level. In this way, organizations could compare risks of different types ( information, people, financial, etc.). 
• The adoption of ISO31000 as risk analysis framework causes that the requirements of risk analysis turn more generic and less detail than those defined in ISO27001:2005 and ISO27005. The purpose is to facilitate the implementation of risk analysis in other management systems that not incorporated it (such as environmental management, quality or IT services ). 
• Security objectives must be approved by business and should allocate the necessary resources to achieve them. There will be special emphasis on this aspect, so that the allocation of resources should be appropriately evidenced .
• Appears a new concept of great importance will be the communication to interested parts.
• Another important change is that it abandons the concept of asset owner and is replaced by risk owner. 
• It passes the 133 controls in Annex A to 114 controls. Actually controls are not removed, only a rearrangement proceeds to reformulate many of them.

Althought PDCA is not mandatory in this new version you can easily match the clauses with the PDCA scheme (note that the structure is identical for all standards that are adopting ISO Annex SL): 
PLAN

• Clause 4 Context: In the new version becomes of paramount importance to properly define the context, both internal and external to the organization. That is, bear in mind the ecosystem in which we live for the rest of decisions taken in the ISMS. Furthermore, the concept of context is perfectly aligned with the ISO31000 regarding context definition to be performed on risk analysis. 
• Section 5 Leadership: As mentioned earlier, this is an entirely new clause. In this new version the definition of leadership and responsibilities will be central, with the aim of ensuring that the necessary resources are allocated to ensure the achievement of the security objectives. 
• Clause 6 Planning: This clause defines the requirements of risk analysis using ISO31000 as a framework and define the requirements to be met in terms of goal setting and planning. The applicability statement remains almost unchanged . 
• Clause 7 Support: This clause defines the requirements in terms of training , resource allocation, awareness, communication and document management. Also, as mentioned before, is given great importance to the management of communication to interested parts, to be established what should be reported, to whom to communicate and how to communicate it.

DO 
Clause 8: This is the clause of Annex SL more change for each ISO as the DO of the 27001 will be totally different to the DO on environmental management, quality or any other ISO. This clause is where, based on the declaration of applicability must be implemented the relevant controls.
CHECK
Clause 9: The ninth clause define the requirements for the ISMS metrics and indicators. In this new version reinforces the requirement in terms of definition and implementation of metrics. 
ACT
Clause 10: The last clause puts the focus on continuous improvement. In this respect, the changes from version 27001:2005 are minimal.

Finally, I must say that after my experience working in the transition from an ISMS based on ISO27001:2005 to the new version  ISO27001:2013 I am convinced that the changes are very positive and that will result in improved efficiency for those ISMS that uses this standard as a basis for implementation.
I hope you've enjoyed this post and have found it useful.
twitter: @omarbenjumea
linkedin: http://www.linkedin.com/in/omarbenjumea

Nueva ISO27001:2013

Por fin tenemos disponible la nueva versión de la 27001. Está versión 2013 incluye bastantes cambios y el propósito de este post es echarles una ojeada de alto nivel a las principales novedades.

En primer lugar, la nueva versión se adapta al Anexo SL de ISO. Esto significa, que la distribución de apartados y fases de la norma será extremadamente similar con el resto de normas que también se están adaptando a este anexo. En la práctica, lo que se propone es que las organizaciones puedan contar con un único marco de gestión común en el que se encuentren integradas las diferentes ISO que tengan implementadas.

A continuación listaremos otros cambios significativos introducidos por la nueva versión:

• La definición del contexto pasará a tener una importancia clave como inicio de la planificación del SGSI. 
• Aparece una nueva cláusula específica para tratar del Liderazgo en el SGSI. Por lo tanto, este concepto cobrará especial importancia en las transiciones a la versión de 2013.
• Se elimina el concepto de acciones preventivas siendo sustituido por el de gestión de riesgos y oportunidades.
• Se referencia la ISO31000 como marco de gestión de riesgos, por lo que, alineado con el anexo SL, se busca que la gestión de riesgos también sea homogénea a nivel corporativo. De esta manera las organizaciones podrán comparar riesgos de diferentes tipologías (de la información, riesgos laborales, riesgos financieros, etc..).
• El hecho de alinearse con la ISO31000 provoca a su vez que los requisitos del análisis de riesgos sean más genéricos y con menor detalle que los que se definínan en ISO27001:2005 e ISO27005. El propósito es facilitar la realización de análisis de riesgos en otros sistemas de gestión que hasta la fecha no lo incorporan (como la gestión medioambiental, la de calidad o la de servicios TI).
• Los objetivos de seguridad deberán ser aprobados por negocio y se deberán destinar los recursos necesarios para su consecución. Se realizará especial hincapié en este aspecto, por lo que la asignación de recursos deberá quedar debidamente evidenciada.
• Aparece un concepto nuevo de gran importancia que será el de comunicación a las partes interesadas.
• Otro cambio relevante es que se abandona el concepto de propietario del activo y se reemplaza por propietario del riesgo.
• Se pasa de los 133 controles del anexo A a 114 controles. En realidad no se eliminan controles, tan sólo se procede a una reordenación reformulando buena parte de ellos.

La nueva versión mantiene el esquema PDCA. La distribución de cláusulas en el esquema será la siguiente (cabe señalar que la estructura es idéntica para todas las ISO que van adoptando el anexo SL):

PLAN

• Cláusula 4 Contexto: En la nueva versión cobra una importancia capital definir adecuadamente el contexto, tanto interno como externo de la organización. Es decir, tener bien presente el ecosistema en el que nos movemos para que el resto de decisiones que se adopten en el SGSI hayan considerado adecuadamente la realidad actual. Además, el concepto de contexto se alinea perfectamente con el de la ISO31000 en cuanto a definición del contexto en el que se debe realizar en análisis de riesgos.
• Cláusula 5 Liderazgo: Como hemos comentado con anterioridad, se trata de una cláusula totalmente nueva. En esta nueva versión la definición de liderazgo y responsabilidades será central, con el objetivo de garantizar que se destinan los recursos necesarios para garantizar la consecución de los objetivos definidos.
• Cláusula 6  Planificación: En esta cláusula se definen los requisitos de realizar un análisis de riesgos usando la ISO31000 como marco de referencia y se definen los requisitos a cumplir en cuanto a definición de objetivos y su planificación. La declaración de aplicabilidad se mantiene sin apenas cambios.
• Cláusula 7 Soporte/Apoyo: En esta cláusula se definen los requisitos en cuanto a formación, asignación de recursos, concienciación, comunicación y gestión documental. Además, se exigirá que las tareas de mantenimiento del SGSI se deban realizar de forma distribuida durante el año. Así mismo, como hemos comentado antes, se da gran importancia a la gestión de la comunicación a las partes interesadas, debiendo definirse qué se debe comunicar, a quien se de comunicar y cómo se debe comunicar.

DO

• Cláusula 8: Esta es la cláusula del anexo SL que más cambiará para cada ISO ya que el DO de la 27001 será totalmente diferente al DO de la ISO de gestión medioambiental, de calidad o cualquier otra ISO. En esta cláusula es donde, en base a la declaración de aplicabilidad realizada se deberá llevar a cabo la implantación de los controles pertinentes.

CHECK

• Cláusula 9: La cláusula novena definirá los requisitos en cuanto a métricas e indicadores del SGSI. En esta nueva versión se refuerza la exigencia en cuanto a definición e implantación de métricas.

ACT

• Cláusula 10: La última cláusula pone el foco en la mejora continua. En este aspecto, los cambios respecto a la versión 27001:2005 son mínimos.

En conclusión, aunque sigue siendo la ISO27001, su adaptación al anexo SL y los cambios incluidos en la nueva versión van a exigir un esfuerzo importante de adaptación a realizar en 2014 por parte de las empresas que quieran mantener su certificación. Después de esta primera revisión a alto nivel de las novedades que incluye la ISO estoy convencido que los cambios son a mejor y que redundarán en una mejora de la eficiencia de los SGSI que utilicen esta norma como base para su implementación.


twitter: @omarbenjumea
linkedin: http://www.linkedin.com/in/omarbenjumea

¿Vale la pena certificar nuestro SGSI?

De un tiempo a esta parte le he estado dando vueltas a la utilidad de certificarse en ISO27001. Conozco el estándar desde hace muchos años, tanto desde el punto de vista de consultor como de auditor interno, de implantador y de operador/administrador del SGSI (Sistema de Gestión de la Seguridad de la Información). La teoría está clara; estar certificado te permite contar con la confirmación de un tercero “independiente” que garantiza que el sistema de gestión de la información de tu organización cumple con los requisitos del estándar. Esto se supone que ha de ser una ventaja competitiva frente a otros competidores no certificados debido al aumento de confianza que el sello debería proporcionar en clientes y proveedores.

Y aunque puede que esto sea cierto en algunos casos, pero en mi opinión, no lo es en la mayoría. La ISO27001 sigue siendo una gran desconocida fuera del sector de TI y en muchos casos también dentro del propio sector. Así mismo, es muy raro el caso en el que un pliego o una RFP exijan que los proveedores estén certificados e incluso son raros los casos en los que se indica que la certificación será tenida en cuenta en la adjudicación del proyecto o servicio.

Estoy de acuerdo en que hoy en día es indispensable para toda empresa contar con un SGSI si se desean mitigar los riesgos que afectan a su información de una forma eficiente, y la ISO27001 es una excelente opción (aunque no la única) en la que basarlo. La ISO permite racionalizar los esfuerzos que se dedican a la seguridad, de manera que se optimiza la reducción de riesgo para una determinada inversión en seguridad. Además, establece un ciclo de mejora continua que también es indispensable para mantener unos niveles de seguridad aceptables a lo largo del tiempo.

Sin embargo, debería ponderarse con cuidado la decisión de abordar un proceso de certificación, teniendo en cuenta los beneficios y los esfuerzos que de ello se derivará. Dado que los auditores de certificación se focalizan en formalismos (no puede ser de otra manera en una auditoría de pocos días), puede ocurrir que los mayores esfuerzos en la implantación del SGSI no se dediquen estrictamente a montar el Sistema de Gestión más adecuado a nuestra organización, si no que es frecuente que los mayores esfuerzos se dediquen a cumplir con todos los formalismos documentales que exige la norma. Esto significa además, que nuestro SGSI perderá flexibilidad, ya que una vez adquirida la certificación no querremos arriesgarnos a perderla.

También hay que tener en cuenta que todo el tinglado de la certificación y los certificadores puede resultar en sí mismo perjudicial para el cumplimiento efectivo del estándar. Por un lado tenemos empresas certificadoras que se ganan la vida acreditando a las organizaciones y, especialmente, recertificándolas año tras año. Además, son competencias unas de las otras, por lo que cada una toma su rol. Tenemos las empresas en las que todo el mundo sabe que es fácil certificarse, y las empresas en las que se supone que es más difícil hacerlo. En cualquier caso, todas comparten el mismo objetivo (y no es mejorar la seguridad de sus clientes); certificar a tantas empresas como sea posible y fidelizarlas para continuar recertificándolas año tras año. Por otro lado, tenemos a los auditores, autónomos subcontratados por las certificadoras, que en muchas ocasiones realizan una interpretación extremadamente subjetiva del estándar llegando a establecer no conformidades u observaciones que en nada ayudan a mejorar la seguridad de la Organización. Sin embargo, deben ser acometidas si se quiere mantener la certificación. Creo que coincidiréis conmigo en que no es el ecosistema más propicio para la mejora

En conclusión, aunque puede ser muy beneficioso en determinadas circunstancias o para determinadas organizaciones, pienso que se debe considerar detalladamente hasta que punto los esfuerzos destinados a implantar o mantener un SGSI certificable merecen la pena en la mayoría de los casos. Si no tenemos claro que el hecho de certificar nuestro SGSI vaya a tener un ROI aceptable, pienso que es mejor dedicar los principales esfuerzos a tener un SGSI lo más eficaz y alineado con nuestra organización posible aunque no cumpla todos los requisitos necesarios para que la empresa certificadora de turno nos conceda su sello.