Dentro de los requerimientos PCI DSS hay uno específico que requiere la implementación de un análisis de riesgos sobre el entorno de cumplimiento PCI DSS. Se trata del requerimiento 12.2 y un error común en las empresas que abordan por primera vez una adecuación al estándar PCI DSS consiste en no dar la suficiente importancia a este requerimiento, que es simple en su definición pero complejo en su ejecución. Su dificultad se entiende fácilmente si pensamos en que implica la colaboración de diferentes roles, un análisis en profundidad del entorno y la toma de decisiones para definir un plan de acción consensuado, justificado y alineado con PCI DSS.
Tal es la complejidad que el PCI SSC ha definido un documento de soporte que ayuda a clarificar los aspectos críticos a tener en cuenta en la implementación de este requerimiento.
https://www.pcisecuritystandards.org/documents/PCI_DSS_v2_Risk_Assmt_Guidelines.pdf
Características del análisis de riesgos
Existen una serie de conceptos que se deben tener en cuenta en el momento de ejecutar o auditar un análisis de riesgos:
- Metodología. Debe aplicarse una metodología reconocida. El propio requerimiento proporciona ejemplos de las metodologías permitidas (Octave, ISO27005, NIST). Existen dos opciones:
- Basarse plenamente en una metodología reconocida.
- Definir una metodología propia basándose en una reconocida conservando los conceptos básicos de la misma.
- Alcance. Debe incluir todos los activos dentro del entorno PCI DSS incluyendo procesos, personas, terceros y tecnologías. Todo componente que de alguna manera pueda suponer un riesgo para la protección de las tarjetas debe estar representado en el análisis de riesgos. Una forma de simplificar esta representación consiste en el uso de dependencias entre los activos.
- Criticidad de los activos. Podemos obtener la criticidad de los activos de muchas fuentes de información. Por ejemplo:
- Valoración de los propietarios o responsables de los activos. Las opiniones tienen que ser imparciales por lo que es recomendable consultar a los responsables de los diferentes procesos o servicios sobre la importancia de todos los procesos dentro del alcance, incluso de los que no son responsables, o bien consultar a un responsable que tenga una visión global del negocio.
- Basarse en la información del Bussiness Impact Analysis, del Bussines Continuity Plan u otro análisis anterior en el que los activos hayan sido clasificados según su criticidad e impacto en la organización.
- Análisis de las amenazas. En ocasiones es útil partir de los catálogos de amenazas existentes y públicos. Se trata de catálogos basados en estadísticas y son generales para cualquier tipo de empresa, por lo que resulta necesario un trabajo de personalización para adecuarlo a las características de la empresa analizada. Por ejemplo: si el personal de la empresa lleva 30 años trabajando en ella se puede considerar que es menos probable que haya un ataque interno que en una empresa con un alto grado de rotación del personal.
En cualquier caso, partamos de unos catálogos estándares o partamos de cero, el análisis interno para determinar las amenazas existentes debe tener en cuenta los incidentes de seguridad detectados en la empresa.
También hay que tener en cuenta que las amenazas resultantes se deben asociar a los activos dentro del alcance. Evidentemente no es lo mismo lo que le puede ocurrir a un servidor que a una persona.
- Vulnerabilidades. Cada empresa presenta un escenario diferente de vulnerabilidades. Afortunadamente, la implementación del estándar PCI DSS nos proporciona información que podemos tener en cuenta para representar este escenario de vulnerabilidades en el análisis de riesgos. Hay ciertas tareas que proporcionan la información que necesitamos, por ejemplo:
- Escaneos trimestrales de vulnerabilidades: externos ASV, internos y wifi.
- Tests de Intrusión.
- Revisión de las reglas de los firewalls.
- Revisión de código.
Adicionalmente se debería tener en cuenta la actividad de la empresa, el sector, el beneficio para el atacante, el grado de exposición y cualquier otro parámetro que ayude a determinar lo vulnerable que es la empresa.
- Análisis de los controles de seguridad implementados. Se trata de evaluar cuál es la situación de la empresa en cuanto a seguridad y para ello se evalúan diferentes controles de seguridad de diferentes ámbitos (físico, lógico, legal…). El estándar PCI DSS proporciona un marco de referencia en cuanto a controles de seguridad a evaluar, aunque también es posible completarlo con otros estándares que hayan podido ser utilizados en la empresa.
- Riesgo. La metodología de análisis de riesgos debe definir cómo afectan los conceptos anteriores al cálculo del riesgo. Básicamente, la lógica nos dice que el riesgo será proporcional a la criticidad del activo, a las amenazas y a las vulnerabilidades e inversamente proporcional a las medidas de seguridad implementadas.
A continuación será necesario definir estrategias de tratamiento de riesgo y una priorización de los riesgos a tratar. Sobre este concepto hay dos peculiaridades a tener en cuenta:
- Teniendo en cuenta que se trata de un análisis de riesgos orientado a la protección del entorno PCI DSS, los riesgos más críticos son los que afectan a la confidencialidad de los datos de las tarjetas.
- Dentro de las acciones posibles para el tratamiento del riesgo no existe la posibilidad de aceptar, transferir o compartir el riesgo si esto resulta en la no implementación de alguno de los requerimientos PCI DSS.
- Plan de acción. La definición del plan de acción es un requisito imprescindible y su ejecución se verificará durante la siguiente auditoría. Este plan de acción estará alineado con los análisis y las conclusiones anteriormente comentadas.
PCI DSS contempla varios ámbitos de seguridad: seguridad en la red, sistemas y aplicaciones, desarrollo, gestión de terceros, recursos humanos... Podríamos pensar que su implementación no debería dejar ningún cabo suelto, pero no podemos olvidar que el estándar PCI DSS es precisamente eso, un estándar que se aplica a todas las empresas afectadas por PCI independientemente de lo diferentes que sean entre ellas. Es por ello que, a veces ocurre que hay carencias de seguridad que únicamente se podrían asociar al requerimiento del estándar PCI DSS 12.2 que requiere realizar un análisis de los riesgos.
Por lo tanto, si hay una carencia en seguridad esto supone un riesgo que debe contemplarse y tratarse dentro del Análisis de Riesgos. Su implementación debe entenderse como una ayuda definitiva para mejorar la seguridad en el entorno PCI DSS.
La última versión del estándar PCI DSS publicada en Noviembre del 2013 añade una aclaración sobre el requerimiento 12.2. No sólo es necesario realizarlo anualmente, sino también cada vez que se realice un cambio importante en la organización. Bajo estas nuevas circunstancias los resultados de un análisis de riesgos pueden quedar totalmente obsoletos.
PCI DSS vs ISO/IEC 27001
Hemos visto muchos mapeos y tablas de equivalencia entre los requerimientos PCI DSS y la norma ISO/IEC 27001. De hecho, es fácil crear falsas expectativas de cumplimiento de los requerimientos PCI DSS en empresas y entidades que se han certificado o han hecho trabajos de implementación sobre el estándar ISO/IEC 27001. Sin embargo, es necesario tener en cuenta que hay una diferencia muy grande entre los dos estándares.
- La ISO/IEC 27001 se basa en un ciclo de mejora continua y en la elección de los controles de seguridad a implementar basándose en los resultados de un análisis de riesgos. Permite por lo tanto cierta flexibilidad para decidir hasta dónde queremos reducir el riesgo y cómo lo vamos a conseguir, todo ello con el conocimiento y la autorización de la Dirección.
- El estándar PCI DSS establece unos requerimientos obligatorios para todas las empresas a las que aplique dicho estándar. El no cumplimiento de uno de los requerimientos determina el no cumplimiento del estándar. Así pues la flexibilidad permitida es poca o nula y se apoya simplemente en la definición de controles compensatorios.
La nueva versión de la ISO/IEC 27001
La nueva versión de la ISO/IEC 27001 aporta más flexibilidad en la elección de una metodología para implementar el ciclo PDCA (Plan, Do, Check, Act) y reestructura la organización documental afectando tanto al lugar donde típicamente se documentaban ciertos controles como en la obligatoriedad o no de definir ciertos documentos. La nueva versión de la ISO realiza un cambio de enfoque, mira todo el proceso desde el punto de vista de la organización , no da la posibilidad de “olvidar” dentro del análisis un proceso que pueda afectar a la seguridad de los activos esté dentro o no dentro del entorno a certificar.
Aunque el PCI SSC por el momento no ha actualizado el documento “PCI DSS Risk Assessment Guidelines” anteriormente mencionado, es posible que en el futuro intente alinearlo con esta estrategia. Quizá el cambio más probable consistirá en aclarar (porque ahora mismo está implícito) que el alcance del análisis de riesgos debe incluir todos los procesos que puedan afectar a la seguridad del entorno PCI DSS y no solamente los activos directamente afectados por el cumplimiento del estándar. Otro posible cambio podrá consistir en aportar más flexibilidad en los elementos que ahora mismo está requiriendo dentro del análisis (gestión de amenazas, vulnerabilidades…). Sin embargo, para considerar realmente cómo afecta los cambios en los requerimientos del análisis de riesgos contemplado dentro de la ISO/IEC 27001 tendremos que esperar a la nueva versión del documento "PCI DSS Risk Assessment Guidelines”.
Autor: Núria Colinas - CISM, CISA, CISSP, PCI QSA, CHFI, ITILF, MCSA
Departamento de Consultoría.
