Blog de Internet Security Auditors: Análisis de Riesgos Extendido para SSF

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.

¿Cuál es el objetivo de un Análisis de Riesgos "extendido"?

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.

Activos Críticos – Superficie de Ataque

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:

Las funciones críticas o sensibles se pueden considerar aquellas que tratan datos sensibles o bien configuraciones que provean funciones de seguridad al software, como, por ejemplo, funciones de autenticación, funciones criptográficas, protocolos de comunicación, demonios de procesamiento, etc.
Datos sensibles en producción, los cuales son los generados y/o los que son dueños otras empresas diferentes de la que es fabricante del software. Estos datos se componen por los que son recopilados o generados por el software cuando es puesto en producción por la organización o terceras partes.
Los recursos sensibles son considerados como recursos externos en los que el software delega ciertas funciones de seguridad o a través de los cuales procesa datos sensibles. Estos recursos sensibles son habitualmente provistos o compartidos por plataformas, entornos operativos u otras aplicaciones que coexisten dentro o fuera del entorno de operación del software. Un ejemplo de los mismos suelen ser ficheros compartidos, claves de registro, configuraciones de entorno, canales de comunicación, cache, librerías compartidas, interfaces de sistema, servicios web, etc.

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:

Inventariado de todos los activos críticos gestionados por el software.
Definición de todos los métodos de entrada y salida de datos sensibles por parte del software, así como el modelo de autenticación y confianza aplicado a cada uno de estos puntos de entrada/salida.
Todos los flujos de datos, segmentos de red y límites de autenticación/privilegios están definidos.
Todas las direcciones IP estáticas, dominios, direcciones URL o puertos requeridos por el software para su funcionamiento están documentados.
Documentación de las consideraciones para elementos de criptografía como modos de cifrado, protección contra ataques de tiempo, “Padding Oracles”, fuerza bruta, ataques de "Rainbow Tables", ataques de diccionario contra el dominio de entrada, etc.
Documentación de las especificaciones o suposiciones de la implementación del entorno de ejecución, como las configuraciones de red, las configuraciones de seguridad del sistema operativo, etc.
Documentación de las consideraciones sobre el entorno instalado del software, incluidas las consideraciones sobre el tamaño de la base/superficie de instalación.

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.

Identificación de Amenazas

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:

Suplantación de identidad de usuario
Tampering
Repudio
Divulgación de información (brecha de privacidad o filtración de información)
Denegación de servicio (D.O.S)
Elevación de privilegios

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

Con este modelado de amenazas, se conseguirá identificar y clasificar todas las amenazas que deben mitigarse, utilizando para ello la implementación de avisos de usuario inseguros o la separación de pilas de protocolos abiertos; el almacenamiento de datos confidenciales después de la autorización o el almacenamiento de datos confidenciales utilizando métodos inseguros, etc.

Metodología de Análisis de Riesgos para Amenazas de Software

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:

Daños (Damage): ¿Cuánto daño podría hacer?
Reproducibilidad (Reproducibility): ¿Qué tan difícil es la ejecución del ataque/amenaza?
Aprovechamiento/Explotabilidad (Explotability): ¿Qué se necesita para ejecutar el ataque/amenaza?
Usuarios afectados (Affected users): ¿Cuántas personas probablemente se verían afectadas?
Descubrimiento (Discoverability): ¿Qué tan difícil es encontrar la vulnerabilidad?

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:

Impacto = Daños + Usuarios afectados
Probabilidad = Reproducibilidad + Explotabilidad + Descubrimiento

Por tanto, podremos calcular el riesgo de una forma ponderada (una vez hayamos dado un valor a los cinco criterios) de la siguiente forma:

Riesgo = (Impacto/2) * (Probabilidad/3)

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.

Salvaguardas

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.

Tratamiento del Riesgo

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:

Aceptación del riesgo.
Eliminación o rechazo del riesgo.
Transferencia del riesgo.
Mitigación del riesgo.

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.

Responsable de la Seguridad del Software

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.

Conclusiones

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.

Referencias

Autor: Alberto Villar - PCI SSA, PCI QSA, CISSP, CSSLP, ISO 27001 L.A., CSFPC, SFPC
Dpto. Consultoría