Con la evolución de las diferentes normativas y estándares dentro de la industria de la ciberseguridad, cada vez se va extendiendo de una forma más clara la importancia de implementar unas metodologías de análisis de riesgos que sirvan como base para la protección de los denominados activos críticos.
Siguiendo esta tendencia, el PCI SSC ha querido incorporar estas metodologías dentro de la "actualización" del estándar PA-DSS, el cual ha sido remplazado completamente por el estándar PCI SSS dentro del marco PCI SSF (podéis encontrar más información en este artículo de comparativa y en este otro artículo de análisis de la transición entre ambos estándares).
Para tratar de explicar todos los conceptos y detalles que intervienen en estos mecanismos de protección del software basados en los “análisis de riesgos extendido para PCI SSF” seguiremos varias implementaciones ya instauradas en la industria, como pueda ser las metodologías STRIDE o DREAD, siempre enfocadas al cumplimiento de los requerimientos descritos en el requisito 4 del estándar PCI SSS.
El principal objetivo es la implantación de controles de seguridad del software que consigan proteger tanto la integridad como la confidencialidad de los activos críticos. Persiguiendo este objetivo vamos a ser capaces de dotar a los activos críticos de una protección adecuada frente a los escenarios de ataque.
Este objetivo que se puede presumir como sencillo, supone una gran dificultad, ya que requiere profundizar en la organización y su contexto para definir la identificación y clasificación de los diferentes aspectos a tener en cuenta en el análisis de riesgos extendidos (de adelante AR-E), con toda la complejidad que ello conlleva.
Para estructurar este AR-E, vamos a ir siguiendo todos y cada uno de los puntos que sugieren las buenas prácticas de la industria que debe contener una metodología de estas características.
En este AR-E que vamos a abordar, debemos tener en cuenta su ámbito al estar enfocado a cumplir los controles del estándar PCI SSS del marco PCI SSF, y por tanto, este AR-E tiene por objetivo analizar los riesgos del software y todos los componentes que lo conforman.
Dentro de una infraestructura de software de un aplicativo, los elementos que conforman los activos críticos y que pueden estar incluidos en el conjunto de componentes que definen la superficie de ataque son aquellos que sean susceptibles de tener vulnerabilidades con posibilidad de ser explotadas por un incidente natural o un ataque deliberado. Estas vulnerabilidades pueden estar vigentes en el propio activo o venir ya predefinidas por la propia clasificación del activo.
De estos hechos se concluye que cuanto mayor sea la superficie de ataque, existirá un mayor número de elementos expuestos (o vectores de ataque) y una mayor probabilidad de que existan vulnerabilidades con posibilidad de ser atacadas. Es por ello que se debe tratar siempre de minimizar la superficie de ataque, pues de esta manera también se estará reduciendo el riesgo de un potencial ataque.
Primero debemos centrarnos en los activos críticos, pues son aquellos en los que nos vamos a enfocar y volcar todos los esfuerzos del AR-E. En este sentido, la organización deberá ser capaz de descomponer todas las piezas que forman parte del software (como funciones, recursos y datos) que son críticos o sensibles y que, por tanto, pueden tener un alto impacto en la integridad y/o confidencialidad del software. Estas piezas o “activos críticos” van a formar parte del conjunto de elementos considerado como “superficie de ataque”, por tanto, este proceso de identificación afecta de lleno a la propia metodología para una correcta identificación de la superficie de ataque del software.
Este aspecto es altamente complejo pues habitualmente nos vamos a encontrar con un gran número de potenciales funciones, recursos y datos que son manejados por un software, por lo que tener un criterio bien definido será fundamental para poder identificar estos activos críticos. A continuación expongo la definición de los activos críticos establecida por el documento Glosario del PCI SSF:
Dentro del listado de activos críticos, deberán incorporarse como mínimo aquellos componentes virtuales o físicos incluyendo máquinas o bibliotecas externas que estén involucrados en las funciones de la aplicación.
Con este conjunto de activos críticos, se deberían poder cubrir los siguientes aspectos:
Todos estos aspectos aúnan en una metodología robusta que habilita un nivel de madurez elevado en la organización y, por tanto, la consistencia entre tres aspectos fundamentales a la hora de definir el alcance y superficie de ataque del software; el mapa de red, el diagrama de flujo de datos y el AR-E.
Dentro del modelado de amenazas, se puede emplear la metodología de STRIDE, que aglutina las seis amenazas que, a criterio de Microsoft, afectan más negativamente a las empresas en términos de protección de la información. STRIDE es un modelo de amenazas desarrollado por Praerit Garg y Loren Kohnfelder en Microsoft para la identificación de amenazas de seguridad informática. Esta proporciona un mnemónico para las amenazas a la seguridad en seis categorías, las amenazas son:
Cada una de estas seis categorías de amenazas, afecta directamente a un propiedad de la ciberseguridad, tal y como se puede observar en la siguiente tabla:
| Amenaza | Propiedad de Ciberseguridad |
| Spoofing | Autenticidad |
| Tampering | Integridad |
| Repudio | No repudio |
| Revelación de información | Confidencialidad |
| Denegación de Servicio | Disponibilidad |
| Elevación de Privilegio | Autorización |
Se debe definir una metodología que sea capaz de medir la probabilidad y el impacto de la explotabilidad de cualquier amenaza que afecta al sistema, así como las posibles amenazas que puedan afectar al software.
En resumen, se deben conjugar dos conceptos de análisis de riesgos que son el Modelado de Amenazas y la Identificación de Superficie de Ataque.
Esto requiere seguir metodologías como la ya definida DREAD, la cual es la que seguiremos establecer nuestra metodología de AR-E. DREAD cuenta con cinco criterios de evaluación del ataque o amenaza, los cuales son:
Con esta metodología, y siguiendo los requisitos establecidos en el estándar PCI SSS es el control 4.1.c, que obliga a realizar el cálculo del riesgo a través del Impacto y la Probabilidad, se propone evaluar estos valores de la siguiente forma:
Por tanto, podremos calcular el riesgo de una forma ponderada (una vez hayamos dado un valor a los cinco criterios) de la siguiente forma:
Las métricas utilizadas (ya sean cualitativas o cuantitativas) deben ser definidas a criterio de la organización en base a su madurez. En caso de utilizar las métricas cualitativas, siempre debe existir una tabla que traduzca la métrica cualitativa en una numérica para su computo de riesgo.
Tras identificar los activos, clasificarlos y calcular su riesgo mediante la fórmula de Impacto*Probabilidad=Riesgo, toca identificar las salvaguardas. Recordemos que las salvaguardas van a provocar una reducción del riesgo del activo. Pasaremos de un riesgo potencial (antes de aplicar la salvaguarda) a un riesgo actual (tras aplicar la salvaguarda).
Antes de pasar al tratamiento del riesgo, debemos considerar las salvaguardas que tenemos actualmente implementadas en los componentes dentro del alcance, ya que con su aplicación valoraremos si el nivel de riesgo actual es aceptable o necesitamos aplicar más salvaguardas o mejorar la madurez de las que ya tenemos. La decisión sobre qué hacer con ese riesgo se explica más ampliamente en el siguiente apartado de tratamiento del riesgo.
Otro aspecto a tener en cuenta es cuando el entorno de ejecución proporcione API para consultar el estado de los controles de mitigación, se deberá confirmar que las verificaciones de software para estas mitigaciones estén implementadas y activas antes de su lanzamiento, y periódicamente durante la ejecución.
Con la implementación y definición de un procedimiento para la identificación de los activos críticos del software junto con la aplicación del modelado de las amenazas identificadas y el estado de las salvaguardas, faltaría definir el tratamiento del riesgo que seguirá la organización para completar su metodología de AR-E.
Para definir el tratamiento del riesgo a seguir, al igual que un Análisis de Riesgos, existen cuatro estrategias principales:
Será la organización quien a través de sus necesidades de negocio determinará la elección del tratamiento del riesgo adecuado en cada caso.
Otro aspecto a incluir es la identificación y definición de un responsable formal que sea asignado al software. Habitualmente esto debe ser definido a través de un rol para una persona o puesto especifico. Es importante este hecho pues debe quedar claro quién es la persona que se hace responsable de forma inequívoca de la seguridad del software.
Esta definición dentro de los procedimientos de roles y responsabilidades es exigida por la norma, pero adicionalmente a dichas responsabilidades sería recomendable añadir la de la supervisión de la mitigación de los riesgos.
Como he comentado al principio de este artículo, cada vez se va instaurando con mayor madurez el análisis de riesgos como el pilar fundamental y la base sobre la que definir los controles de seguridad a implementar en la infraestructura deseada. Sin embargo, esto no resultará sencillo pues habitualmente las organizaciones no han aplicado correctamente las metodologías de análisis de riesgos en sus procesos o entornos críticos, relegando el análisis de riesgos a un segundo plano y aplicando un nivel de madurez escaso en la mayoría de las situaciones.
Es por ello, que uno de los principales esfuerzos en el futuro de la ciberseguridad en las organizaciones para mejorar los controles de seguridad aplicados a entornos o infraestructuras críticas, pasará por la definición e implementación de una metodología de riesgos adecuada y que incluya la identificación de los posibles escenarios de ataque y la mitigación de los mismos. Además, en caso de que la organización quiera alinearse a algún estándar o normativa de la industria, esta obligación vendrá incluida en los propios controles en la mayoría de los casos.
Todos estos aspectos han sido tenidos en cuenta por el PCI SSC para incluirlos dentro del marco normativo de PCI SSF, y que adiciona estas metodologías de análisis de riesgos para ser aplicadas no solo en procesos sino también de forma minuciosa en todos los activos críticos llegando a un nivel de detalle alto para incluir IP estáticas, dominios, direcciones URL o puertos requeridos por el software para su funcionamiento.
Autor: Alberto Villar - PCI SSA, PCI QSA, CISSP, CSSLP, ISO 27001 L.A., CSFPC, SFPC
Dpto. Consultoría