CVSS

14/09/2010

C SS + ISO 27001 Usando Common Vulnerability Scoring System junto a ISO 27001

Miguel Ángel Hernández Ruiz ;

http://www.miguelangelhernandez.es

Miguel%20Ángel%20Hernández%20Ruiz%20;%20%20%20%20%20http:/www.miguelangelhernandez.es

Miguel%20Ángel%20Hernández%20Ruiz%20;%20%20%20%20%20http:/www.miguelangelhernandez.es


1

Tabla de Contenidos

Tabla de Contenidos _____________________________________ 1

Tabla de Ilustraciones ___________________________________ 2

Introducción __________________________________________ 3

¿Cómo funciona CVSS? ______________________________________ 3

¿Quién calcula los valores? ____________________________________ 4

¿A quién pertenece CVSS? ____________________________________ 4

¿Quién lo usa? _____________________________________________ 4

Definiciones ______________________________________________ 5

Grupos de Métricas______________________________________ 5

Métricas base _____________________________________________ 5

Vector de Acceso (Access Vector / AV) ________________________________________ 6 Complejidad de Acceso (Access Complexity / AC) ________________________________ 6 Autenticación (Authentication / Au) _________________________________________ 7 Impacto en la Confidencialidad (Confidentiality / C) ______________________________ 7 Impacto en la Integridad (Integrity / I) _______________________________________ 8 Impacto en la Disponibilidad (Availability / A) __________________________________ 8

Vector Base _______________________________________________ 8

Ecuación Base _____________________________________________ 9

Métricas Temporales ________________________________________ 9

Aprovechamiento (Exploitability / E) ________________________________________ 9 Nivel de Solución (Remediation Level /RL) ___________________________________ 10 Confianza en la Fuente (Report Confidence / RC) _______________________________ 10

Vector Temporal __________________________________________ 11

Ecuación Temporal ________________________________________ 11

Métricas del Entorno _______________________________________ 11

Potencial de Daño Colateral (Collateral Damage Potencial /CPD) ____________________ 12 Distribución del Objetivo (Target Distribution / TD) _____________________________ 12 Requisitos de Seguridad (Security Requirements / CR, IR, AR) ______________________ 13

Vector de Entorno _________________________________________ 13

Ecuación de Entorno _______________________________________ 14


2

¿Cómo encaja CVSS dentro de la gestión del riesgo? _____________ 14

Pinceladas sobre ISO 27005 __________________________________ 15

Fijando los Criterios de Impacto _______________________________ 16

Identificando las Consecuencias _______________________________ 16

LLevándolo todo a la práctica _________________________________ 18

Trabajos citados _______________________________________ 18

Anexo A: Cálculo de las ecuaciones. _________________________ 19

Ecuación Base ____________________________________________ 19

Ecuación Temporal ________________________________________ 20

Ecuación del Entorno ______________________________________ 21

Tabla de Ilustraciones

Ilustración 1: Métricas y Ecuaciones ____________________________________________ 4 Ilustración 2: Colectivos que se benefician de CVSS. _________________________________ 5 Ilustración 3: Vector de Acceso ________________________________________________ 6 Ilustración 4: Complejidad de Acceso ___________________________________________ 6 Ilustración 5: Autenticación. _________________________________________________ 7 Ilustración 6: Impacto en la Confidencialidad. _____________________________________ 7 Ilustración 7: Impacto en la Integridad. _________________________________________ 8 Ilustración 8: Impacto en la Disponibilidad. ______________________________________ 8 Ilustración 9: Aprovechamiento ______________________________________________ 10 Ilustración 10: Nivel de Solución. _____________________________________________ 10 Ilustración 11: Confianza en la fuente. ___________________________________________ 11 Ilustración 12: Potencial de Daño Colateral. _____________________________________ 12 Ilustración 13: Distribución del Objetivo. ________________________________________ 12 Ilustración 14: Evaluación de Requisitos de Seguridad ______________________________ 13 Ilustración 15: Gestión del Riesgo en ISO 27005. __________________________________ 15 Ilustración 16: Modelado y Herencia de Impactos. _________________________________ 17


3

C SS + ISO 27001

Usando Common Vulnerability Scoring System junto a ISO 27001

Importante:

Este artículo no pretende exponer una forma única de llevar a cabo la interconexión entre CVSS e

ISO 27001 dado que la metodología de análisis de riesgos puede variar sustancialmente entre

implantaciones. Es por ello que se apoya en su parte normativa en ISO 27005 para intentar huir

de metodologías concretas, aunque cierta concreción ha sido inevitable para mostrar los ejemplos.

Introducción

El sistema de puntuación de vulnerabilidades comunes (Common Vulnerability Scoring System,

en adelante CVSS) viene a solucionar la problemática de priorizar las actuaciones entorno a las

vulnerabilidades técnicas localizadas dentro de la organización en el proceso de gestión de la

vulnerabilidad técnica, unificando la forma en la que las vulnerabilidades son evaluadas.

CVSS constituye un marco de trabajo en el cual se definen una serie de parámetros que permiten

asignar un valor de riesgo a una determinada vulnerabilidad basándose en tres diferentes grupos

de métricas:

Métricas Base: recogen las características intrínsecas y fundamentales de la

vulnerabilidad que son independientes del tiempo y del entorno en el que ésta se pueda

presentar.

Métricas Temporales: reflejan aquellas cualidades que pueden variar en el tiempo.

Métricas de Entrono: involucran aquellas variables que dependen del entorno en el que se

encuentra la vulnerabilidad.

¿Cómo funciona CVSS? La idea para el cálculo del valor de la vulnerabilidad pasa por hacer obligatorio el cálculo de las

métricas base y opcional los cálculos de las métricas temporal y de entorno siendo estas últimas

modificadores de la base.

De esta forma, una vez fijados los valores que componen la fórmula de cálculo base se obtiene un

valor entre 0 y 10 que posteriormente puede ser refinado por características temporales o del

entorno. Este valor irá acompañado de lo que se denomina Vector que no es otra cosa que una

cadena de texto donde se refleja cómo se ha llevado a cabo el cálculo. La Ilustración 1 muestra la

filosofía detrás de esta idea:


4

Ilustración 1: Métricas y Ecuaciones

¿Quién calcula los valores? Generalmente, quien tiene mejor conocimiento de las diferentes métricas. Las métricas base y

temporal son calculadas por los emisores de boletines de vulnerabilidades, vendedores de

productos de seguridad o aplicaciones, mientras que la del entorno es fijada por los usuarios, que

son los que mejor conocen las circunstancias y distribución de las Tecnologías de la Información

en su organización.

¿A quién pertenece CVSS? CVSS está bajo la custodia y cuidado del Foro de Respuesta a Incidentes y Equipos de Seguridad

(Forum of Incident Response and Security Teams, en adelante FIRST). No obstante nadie es

propietario de CVSS y no se requiere ser miembro de FIRST para poder usarlo o implementarlo.

¿Quién lo usa? Diferentes colectivos se benefician de diferente forma de CVSS entre los que destacan los

mostrados en la Ilustración 2.

Métricas

Base

• f(x1,x2,....xn)

Métricas

Temporales

• f(y1,y2,....yn)

Métricas del

Entorno

• f(z1,z2,....zn)


5

Ilustración 2: Colectivos que se benefician de CVSS.

Definiciones Dentro de CVSS los términos Vulnerabilidad, Amenaza y Riesgo se definen como sigue:

Vulnerabilidad: un problema, debilidad o exposición de una aplicación, dispositivo,

sistema o servicio que puede llegar a causar un problema de confidencialidad, integridad o

disponibilidad.

Amenaza: probabilidad o frecuencia de que ocurra un evento no deseado.

Riesgo: el impacto relativo que una vulnerabilidad aprovechada pudiera tener en un

entorno usuario.

Grupos de Métricas

Métricas base El grupo de métricas base acoge las características de la vulnerabilidad que no son alterables en

el tiempo ni dependientes del entorno. Este grupo contiene tres métricas denominadas Vector de

Acceso (Access Vector o AV), Complejidad de Acceso (Access Complexity o AC) y Autenticación

(Authentication o Au). Y otras tres más para recoger el impacto en cada uno de las dimensiones

de la Información; Confidencialidad, Integridad y Disponibilidad. De esta forma se recoge la

posibilidad de que una vulnerabilidad pueda afectar a algunas de las dimensiones más que a

otras.

cvss

Proveedores de Boletines de Seguridad

Vendedores de

Aplicaciones Software

Empresas Usuarias

Gestores de Vulnerabili-

dades

Investigadores

Gestores de Riesgo en Seguridad


6

Para cada uno de los valores que puede tomar una métrica, se exponen sus iniciales provenientes

del inglés. Para más detalles sobre qué hechos son determinantes a la hora de asignar un valor a

una métrica vea (1).

Vector de Acceso (Access Vector / AV)

Esta métrica refleja cómo se puede sacar partido de la vulnerabilidad en términos de lejanía. Los

valores que puede tomar esta métrica quedan reflejados en la Ilustración 3 .

Ilustración 3: Vector de Acceso

Conforme es más sencillo el acceso para sacar partido de la vulnerabilidad, mayor es la valoración

de la vulnerabilidad.

Complejidad de Acceso (Access Complexity / AC)

Lo que se pretende medir mediante esta métrica es cómo de complejo resulta aprovechar la

vulnerabilidad en términos de las condiciones que se deben presentar. Algunas vulnerabilidades,

por ejemplo, requieren interacción del usuario para obtener un resultado por parte del atacante o

requieren condiciones de acceso de Administrador.

Ilustración 4: Complejidad de Acceso

Donde los valores representan:

Acceso Local

(L)

Red Adyacente

(A)

Red

(N)

Alto

(H)

Medio

(M)

Bajo

(L)


7

Bajo: No se requieren condiciones especiales de acceso

Medio: Las condiciones de acceso son algo específicas

Alto: Existen condiciones de acceso especiales

Cuanto menores son las condiciones de acceso, mayor es el valor de la vulnerabilidad.

Autenticación (Authentication / Au)

Esta métrica mide el número de veces que un atacante debe autenticarse antes de tener acceso

para aprovechar la vulnerabilidad.

Ilustración 5: Autenticación.

Cuanto menores condiciones de autenticación son necesarias para el atacante, mayor es el valor

de la vulnerabilidad.

Impacto en la Confidencialidad (Confidentiality / C)

Mediante este valor se mide el impacto sobre la confidencialidad de un ataque satisfactorio.

Ilustración 6: Impacto en la Confidencialidad.

Un incremento de impacto en la confidencialidad, incrementa también el valor de la

vulnerabilidad.

Múltiple

(M)

Simple

(S)

Ninguna

(N)

Ninguno

(N)

Parcial

(P)

Completo

(C)


8

Impacto en la Integridad (Integrity / I)

Al igual que el anterior pero en esta ocasión para la dimensión de la disponibilidad, esta métrica

viene a medir el impacto sobre la integridad de la información de un ataque satisfactorio.

Ilustración 7: Impacto en la Integridad.

Un incremento en el impacto a la integridad se traduce en un incremento en el valor de la

vulnerabilidad.

Impacto en la Disponibilidad (Availability / A)

Impacto en la tercera dimensión de la información, la Disponibilidad, si se produce un ataque

exitoso.

Ilustración 8: Impacto en la Disponibilidad.

Cuanto mayor es el impacto, mayor es el valor de la vulnerabilidad.

Vector Base Cada métrica dentro del vector consta de el nombre abreviado de la métrica seguida del símbolo

“:”, a continuación el valor abreviado de la métrica, usando el carácter “/” para separar las

métricas. El vector Base tiene la forma general:

Ninguno

(N)

Parcial

(P)

Completo

(C)

Ninguno

(N)

Parcial

(P)

Completo

(C)


9

AV:[L,A,N]/AC:[H,M,L]/Au:[M,S,N]/C:[N,P,C]/I:[N,P,C]/A:[N,P,C]

Dónde AV, AC, Au… se corresponden con Access Vector, Access Complexity, Authentication…

vistos en las secciones anteriores y los valores entre corchetes son las abreviaturas de los posibles

valores para cada métrica (en Inglés).

Un ejemplo de posible valoración de las métricas sería:

Access Vector: Low

Access Complexity: Medium

Authentication: None

Confidentiality Impact: None

Integrity Impact: Partial

Availability Impact: Complete

Lo que dejaría el siguiente vector base:

AV:L/AC:M/Au:N/C:N/I:P/A:C

Ecuación Base La versión 2.10 de la fórmula para el cálculo mediante la ecuación base combina Impacto y

Aprovechamiento (Exploitability) con ciertos modificadores en forma de pesos numéricos.

Asignando valores numéricos a los literales definidos como valores posibles para cada métrica se

obtiene un resultado numérico entre 0 y 10. La asignación concreta de valores podéis verla en (1).

Métricas Temporales El grado de peligro que supone una vulnerabilidad puede cambiar con el tiempo. Tres de los

factores que incluye CVSS como componentes que influyen en el grado de peligro que supone la

vulnerabilidad son:

- El grado de confirmación de los detalles técnicos sobre la vulnerabilidad

- Cuáles son las soluciones planteadas, si éstas existen

- La existencia de código o técnicas que permitan aprovechar la vulnerabilidad

Estas métricas son opcionales por lo que incluyen un valor que no altera el cálculo total.

Aprovechamiento (Exploitability / E)

Esta métrica mide el estado actual en cuanto a la disponibilidad de código o técnicas que

permitan aprovechar la vulnerabilidad existente. El número potencial de atacantes aumenta

conforme las técnicas o códigos para aprovechar la vulnerabilidad se hacen más sencillos y

accesibles para los menos experimentados.


10

Ilustración 9: Aprovechamiento

Además de los valores reflejados en la Ilustración 9, esta métrica dado que es opcional puede

tomar el valor “No definido (ND)”. Cuanto más fácil pueda aprovecharse la vulnerabilidad, mayor

será el valor asignado a la misma.

Nivel de Solución (Remediation Level /RL)

Como su propio nombre indica, esta métrica trata de otorgar un valor conforme al tipo de solución

existente para la vulnerabilidad, que puede ser en forma de workaround, parche del fabricante, o

en primera instancia no disponer de ninguna solución. Conforme menos oficial es una solución,

mayor será el valor de la vulnerabilidad.

Ilustración 10: Nivel de Solución.

Al igual que en la métrica anterior, aparte de los valores expresados en la Ilustración 10, esta

métrica opcional incluye el valor “No Definido (ND)” que no altera el resultado final de la

vulnerabilidad.

Confianza en la Fuente (Report Confidence / RC)

Dependiendo de quién informe sobre la vulnerabilidad, ésta es más o menos creíble de forma que

se puede definir una escala según lo oficial de la fuente que comunica o reconoce la

No Probada

(U)

Prueba de Concepto

(POC)

Funcional

(F)

Alto (H)

No Disponible

(U)

WorkAround

(W)

Corrección Temporal

(TF)

Parche Oficial

(OF)


11

vulnerabilidad. La urgencia para el parcheo de una vulnerabilidad será mayor cuanto más oficial

sea la fuente que la confirme.

Ilustración 11: Confianza en la fuente.

El valor de la vulnerabilidad crecerá conforme esté confirmada por fuentes más acreditadas. Esta

métrica incluye el valor “No Definido (ND)” que no alterará el cálculo final.

Vector Temporal Con la misma filosofía en cuanto a codificación que en el Vector Base, se obtiene la siguiente

representación abreviada para el vector temporal.

E:[U,POC,F,H,ND]/RL:[OF,TF,W,U,ND]/RC:[UC,UR,C,ND]

Un ejemplo de posible valoración para estas métricas sería el siguiente:

Exploitability: Functional

Remediation Level: Temporary Fix

Report Confidence: Confirmed

Lo que dejaría el siguiente vector temporal:

E:F/RL:TF/RC:C

Ecuación Temporal Al igual que sucede en el caso de la Ecuación Base, para la Ecuación Temporal se crea una

equivalencia entre los literales que puede tomar como valor cada métrica y un valor numérico que

permita cuantificar la repercusión del aspecto temporal en la vulnerabilidad. Las Asignaciones de

valores de hacen de forma que las métricas temporales en caso de que no se tengan en cuenta

nunca disminuyan el valor del cálculo base. Si se establecieran los valores máximos para cada

una de las métricas, esta ecuación dejaría intacta la ecuación base mientras que cualquier valor

intermedio rebajaría su resultado total. En (1) puede ampliar información sobre cómo se calcula

esta Ecuación Temporal.

Métricas del Entorno

No Confirmada

(UC)

No Corroborada

(UR)

Confirmada

(C)


12

Las vulnerabilidades pueden suponer un problema de muy diferente grado dependiendo del

entorno en el que se presente. El grupo de métricas del entorno capturan las características de

una vulnerabilidad que están asociadas con el entorno TI del usuario.

Potencial de Daño Colateral (Collateral Damage Potencial /CPD)

Refleja el potencial de pérdidas humanas o de activos causado por daño o robo de propiedades o

equipamientos. Esta métrica puede también medir la pérdida de productividad o ingresos.

Ilustración 12: Potencial de Daño Colateral.

Como es lógico, cuanto mayor es el daño colateral provocado, mayor será el valor de la

vulnerabilidad. Esta métrica incorpora al igual que en el caso de las métricas temporales y el

resto de este grupo el valor “No Definido (ND)” que mantendrá inalterado el cálculo final.

Distribución del Objetivo (Target Distribution / TD)

Proporción de sistemas vulnerables en la organización. Esta métrica añade información sobre el

porcentaje aproximado de sistemas que se encuentran afectados en la organización con respecto al

total.

Ilustración 13: Distribución del Objetivo.

Ninguno

(N)

Bajo

(L)

Bajo-Medio

(LM)

Medio-Alto

(MH)

Alto

(H)

Ninguno

(N)

Bajo

(L)

Medio

(M)

Alto

(H)


13

Cuanto mayor sea la proporción de sistemas vulnerables mayor será el valor de la vulnerabilidad.

Requisitos de Seguridad (Security Requirements / CR, IR, AR)

Estas métricas permiten a un analista de seguridad instanciar el valor que CVSS otorga a una

determinada vulnerabilidad en función de la importancia de los activos afectados por las

dimensiones de Integridad, Confidencialidad y Disponibilidad. Cada requisito de seguridad tiene

tres posibles valores: bajo, medio o alto.

El efecto completo sobre el valor del entorno viene determinado por las correspondientes métricas

base de impacto (las métricas del cálculo base sobre confidencialidad, integridad y disponibilidad

no cambian por sí mismas). Esto es, estas métricas lo que hacen es introducir un modificador a las

métricas base de impacto sobre confidencialidad, integridad y disponibilidad. Por ejemplo, la

métrica de impacto en la confidencialidad se ve incrementada si el valor del requisito de

confidencialidad es alto. O al contrario, la métrica de impacto en la confidencialidad se ve

decrementada si el requisito de confidencialidad es bajo. En caso de que el valor del requisito de

confidencialidad sea medio, el cálculo para la métrica de impacto en la confidencialidad no se verá

afectada. La misma lógica se aplica a las dimensiones de integridad y disponibilidad.

Los posibles valores para cualquiera de estas métricas se muestran en la siguiente imagen:

Ilustración 14: Evaluación de Requisitos de Seguridad

Además incluyen el valor “No Definido (ND)” si no se desea que apliquen estas métricas.

Conforme mayor es el requisito de seguridad, mayor es el valor final de la vulnerabilidad. Este

valor puede verse alterado a lo sumo en +-2,5 mediante estas métricas de requisitos de seguridad.

Vector de Entorno Como sucedía para el Vector Base y para el Vector Temporal, el Vector de Entorno se define

mediante la siguiente nomenclatura:

CDP:[N,L,LM,MH,H,ND]/TD:[N,L,M,H,ND]/CR:[L,M,H,ND]/IR:[L,M,H,ND]/

AR:[L,M,H,ND]

Un posible ejemplo sería como sigue:

Bajo

(L)

Medio

(M)

Alto

(H)


14

Collateral Damage Potential: High (H)

Target Distribution: Medium (M)

Confidentiality Requirement: High (H)

Integrity Requirement: (L)

Availability Requirement: (H)

Quedando entonces el vector de entorno de la siguiente forma:

CDP:H/TD:M/CR:H/IR:L/AR:H

Ecuación de Entorno Quizá esta fórmula sea la de cálculo más enrevesado pero si tenemos en cuenta lo que se ha

expuesto con anterioridad, no resulta difícil interpretar el cálculo. Lo primero es recalcular el

Impacto teniendo en cuenta las nuevas métricas Integrity, Confidenciality y Availability

Requirement para posteriormente recalcular también la Ecuación Temporal que dependía de la

Ecuación Base y combinar estos valores con los de Distribución del Objetivo y Potencial de Daño

Colateral.

El resultado se calcula de forma que el valor obtenido por la Ecuación de Entorno altera en un

máximo de 2,5 puntos de valor añadido o disminuido al valor de la Ecuación Base.

En (1) podéis encontrar ejemplos de cálculo para 3 vulnerabilidades, sin embargo aquí no los

incluiré porque la idea tras este artículo no es que se conozcan los valores que se han asignado a

cada literal sino cómo éstos contribuyen a un cálculo final, qué factores se tienen en cuenta y qué

relaciones mantienen las diferentes métricas y grupos de métricas.

¿Cómo encaja CVSS dentro de la gestión del riesgo?

Como ya se ha comentado anteriormente, CVSS incluye dentro de sus Ecuaciones una destinada a

recoger determinados aspectos que son dependientes de la organización en la que se presenta la

vulnerabilidad. Estos aspectos se encuentran recogidos dentro del conjunto de métricas de

entorno por las métricas denominadas:

Requisito de Confidencialidad

Requisito de Integridad

Requisito de Disponibilidad

La cuestión que se plantea ante los requisitos de las métricas de entorno es; ¿de donde saco estos

valores?. Y la respuesta es; del análisis de riesgos de la organización. En ISO 27001, el punto

4.2.1.d recoge las actividades a realizar para la Identificación de Riesgos que se compone de:

1. Identificar los activos que están dentro del ámbito de aplicación del SGSI y a los

propietarios de estos activos.

2. Identificar las amenazas a que están expuestos esos activos

3. Identificar las vulnerabilidades bajo las que podrían actuar dichas amenazas

4. Identificar los impactos que sobre los activos puede tener una pérdida de confidencialidad,

integridad y disponibilidad en los mismos.


15

Y anteriormente, en los apartados b y c nos habla sobre el establecimiento de los criterios de

estimación del riesgo y el enfoque de evaluación de riesgos de la organización.

Nos vamos a adentrar un poco más allá de la 27001 yendo hasta la norma ISO/IEC 27005/2008

para ver las recomendaciones al respecto de cómo se pueden llevar a cabo algunas de las

actividades que acabamos de comentar, las más relevantes para entender de dónde vienen los

valores de Confidencialidad, Integridad y Disponibilidad que se van a fijar en las métricas de

CVSS.

Pinceladas sobre ISO 27005 Vamos a dar una pincelada sobre ISO 27005. A modo de resumen, ISO 27005 expone, entre otras,

las siguientes fases para un buen proceso de gestión del riesgo.

Ilustración 15: Gestión del Riesgo en ISO 27005.

Cada una de estas fases tiene los siguientes objetivos a groso modo:

Establecimiento del contexto: Lo primero que tenemos que tener claro es dónde queremos

llegar y qué estamos dispuestos a tolerar. Debemos por tanto Establecer el objetivo y fijar

los criterios.

Evaluación de Riesgos: El proceso de Evaluar el Riesgo consta de dos partes bien

diferenciadas. En la primera de ellas se Analiza el Riesgo al que se está sujeto. Mientras


16

que en la segunda se deben priorizar esos riesgos para saber a qué debo prestar más

atención y destinar el mayor número de recursos.

Identificación de Riesgos: Identificar las amenazas, las vulnerabilidades, y las posibles

consecuencias

Estimación del Riesgo: Basándonos en las posibles consecuencias y su probabilidad de

ocurrencia, debemos estimar cuál es el nivel de riesgo al que estaríamos sometidos

Valoración del Riesgo: Decidir en base a los criterios establecidos en el establecimiento del

contexto, qué riesgos son más importantes.

Tratamiento del Riesgo: Mitigar / Evitar / Transferir / Aceptar

Aceptación del Riesgo: ¿Son aceptables los riesgos residuales propuestos?

Fijando los Criterios de Impacto Antes de asignar un valor de impacto se deben tomar decisiones entorno al cómo se van a fijar

dichos valores. Estos criterios implican decidir sobre el número de niveles de impacto que se van a

representar (por ejemplo 3 de forma cualitativa; alto, medio, bajo) o 4 de forma cuantitativa

(valores de 1 a 4).

Otra de las decisiones que se ha de tomar es en base a qué ámbitos se va a valorar, esto es, qué es

aquello que puede ser dañado. La Imagen, la Operativa de la organización, Las relaciones con

terceros, Los niveles de clasificación de la información, etc.

En base a estas dos decisiones se puede crear una tabla en la que en las intersecciones de filas por

columnas se expongan de forma clara, no ambigua y no solapada qué factores ubicarán la

valoración en uno u otro nivel por cada ámbito.

Por ejemplo:

Si se decide que la escala de valores posibles para el impacto será de Alto, Medio y Bajo y uno de

los ámbitos es el operativo, los valores en la intersección podrían quedar descritos como sigue:

Ámbito Operativo:

nivel alto: se produce una parada total del servicio

nivel Medio: se aprecia una ralentización de las operaciones que no hace posible el

desarrollo normal del servicio

nivel bajo: se produce una ralentización de las operaciones aunque no afecta al desempeño

normal del servicio

Si realizamos esta labor por todos los ámbitos, la matriz resultante definiría los criterios de

impacto pero... ¿donde está aquí la Confidencialidad, la Integridad y la Disponibilidad?

Identificando las Consecuencias Tal como comentamos anteriormente, en la fase de Identificación de Riesgos es necesario

identificar activos, amenazas, vulnerabilidades e impactos. En este punto vamos a asumir que ya

disponemos de los activos de la organización, de las amenazas sobre los activos (ISO 27005 expone

un catálogo relativamente amplio de amenazas en su Anexo C) y de las vulnerabilidades de los

mismos. ISO 27005 nos invita a que definamos escenarios de incidentes donde se contempla la

posibilidad de que una amenaza se aproveche satisfactoriamente de una vulnerabilidad presente


17

en un activo. Estos escenarios son presentados a la persona encarga de evaluarlos (aquella que

tenga un conocimiento más amplio de las posibles repercusiones) quien nos dará un valor por

Confidencialidad, Integridad y Disponibilidad en cada escenario y atendiendo a los criterios

anteriormente fijados.

Ya tenemos nuestros valores de Impacto para Confidencialidad, Integridad y Disponibilidad para

cada activo pero... ¿y las dependencias? ¿Y si tengo un activo de Información que es manejado por

una aplicación?, puedo tener valores diferentes para cada uno y eso puede resultar incongruente.

A este respecto se Construye un Arbol de Activos de la Organización como el que se refleja en la

Ilustración 16.

Ilustración 16: Modelado y Herencia de Impactos.

Como se puede observar, cada activo hereda el valor máximo entre:

Su propio valor

El mayor valor de los activos que dependen de él

de esta forma se pretende reflejar su importancia no sólo como activo de carácter tecnológico o

dependencia física sino por cómo contribuye al proceso al que sirve. Y si alguien piensa que por

qué no sólo se heredan los valores de los activos de la información, a mi se me ocurren al menos

dos motivos, pensadlo bien.


18

LLevándolo todo a la práctica Las métricas de Requisito de Confidencialidad, Requisito de Integridad y Requisito de

Disponibilidad, pueden tomar los valores Alto, Medio y Bajo al igual que en el ejemplo que hemos

mostrado en la ilustración 16. Si los niveles son equiparables el mapeo entre ambos dominios, el

de CVSS y el de análisis de impacto, serían directos. Esto implica que, cuando en un escaneo de

vulnerabilidades se localice una vulnerabilidad para el software "SOFTWARE 2", dispondremos

de los valores CID para sustituirlos en el vector de entorno por sus valores correspondientes,

calculando el valor final de riesgo de la vulnerabilidad para nuestra organización. En caso de que

los valores en el dominio del impacto que se fijara en los criterios fuesen diferentes a los

existentes en CVSS deberíamos crear una correspondencia entre los dos dominios.

Pues bien, ¿pero todo esto hay que hacerlo a mano?, afortunadamente no, existen calculadoras de

vulnerabilidades que te permiten fijar los valores para las diferentes métricas obteniendo un

valor final particularizado para la organización. Esta calculadora la puedes encontrar en (2).

Aún así, cuando se ha de gestionar una organización en la que los escaneos en busca de

vulnerabilidades son frecuentes y las vulnerabilidades en el software relativamente abundantes,

es inviable pensar en pasar el tiempo introduciendo valores en una calculadora.

Ahora voy a lanzar una idea al todo de Internet. Lo ideal sería que el propio software de escaneo

de vulnerabilidades fuese capaz de integrarse con el de análisis de riesgos hasta el punto de que,

con el valor CVSS base y el Temporal en el instante del escaneo, se pudiera calcular

automáticamente el valor para el entorno y devolver priorizadas las vulnerabilidades para la

organización.

Desconozco si este software existe o si alguien antes ha tenido la misma idea. Por si acaso, si

alguien lo implementa en alguna ocasión que sea bajo software libre al completo (todo el

producto), y si no es así, agradezco que cuente conmigo antes de hacerlo :).

Trabajos citados

1, F. o. (s.f.). FIRST.ORG. Recuperado el 14 de 10 de 2010, de FIRST.ORG:

http://www.first.org/cvss/cvss-guide.html

2, F. o. (s.f.). National Vulnerability Database. Obtenido de National Vulnerability Database:

http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2


19

Anexo A: Cálculo de las ecuaciones.

Ecuación Base

BaseScore = round_to_1_decimal(((0.6*Impact)+(0.4*Exploitability)-

1.5)*f(Impact))

Impact = 10.41*(1-(1-ConfImpact)*(1-IntegImpact)*(1-AvailImpact))

Exploitability = 20* AccessVector*AccessComplexity*Authentication

f(impact)= 0 if Impact=0, 1.176 otherwise

AccessVector = case AccessVector of

requires local access: 0.395

adjacent network accessible: 0.646

network accessible: 1.0

AccessComplexity = case AccessComplexity of

high: 0.35

medium: 0.61

low: 0.71

Authentication = case Authentication of

requires multiple instances of authentication:

0.45

requires single instance of authentication: 0.56

requires no authentication: 0.704

ConfImpact = case ConfidentialityImpact of

none: 0.0

partial: 0.275

complete: 0.660

IntegImpact = case IntegrityImpact of

none: 0.0

partial: 0.275

complete: 0.660

AvailImpact = case AvailabilityImpact of

none: 0.0

partial: 0.275

complete: 0.660


20

Ecuación Temporal

TemporalScore = round_to_1_decimal(BaseScore*Exploitability

*RemediationLevel*ReportConfidence)

Exploitability = case Exploitability of

unproven: 0.85

proof-of-concept: 0.9

functional: 0.95

high: 1.00

not defined: 1.00

RemediationLevel = case RemediationLevel of

official-fix: 0.87

temporary-fix: 0.90

workaround: 0.95

unavailable: 1.00

not defined: 1.00

ReportConfidence = case ReportConfidence of

unconfirmed: 0.90

uncorroborated: 0.95

confirmed: 1.00

not defined: 1.00


21

Ecuación del Entorno

EnvironmentalScore = round_to_1_decimal((AdjustedTemporal+

(10-AdjustedTemporal)*CollateralDamagePotential)*TargetDistribution)

AdjustedTemporal = TemporalScore recomputed with the BaseScores Impact

sub-equation replaced with the AdjustedImpact equation

AdjustedImpact = min(10,10.41*(1-(1-ConfImpact*ConfReq)*(1-

IntegImpact*IntegReq)*(1-AvailImpact*AvailReq)))

CollateralDamagePotential = case CollateralDamagePotential of

none: 0

low: 0.1

low-medium: 0.3

medium-high: 0.4

high: 0.5

not defined: 0

TargetDistribution = case TargetDistribution of

none: 0

low: 0.25

medium: 0.75

high: 1.00

not defined: 1.00

ConfReq = case ConfReq of

low: 0.5

medium: 1.0

high: 1.51

not defined: 1.0

IntegReq = case IntegReq of

low: 0.5

medium: 1.0

high: 1.51

not defined: 1.0

AvailReq = case AvailReq of

low: 0.5

medium: 1.0

high: 1.51

not defined: 1.0

CVSS

Documents

Transcript of CVSS