Medir Para Decidir.

¿Cuál es el objetivo de las métricas de seguridad? Medir a un control de seguridad. Ya sé, es obvio. Mejor: las métricas intentan asignar valores alrededor de actividades orientadas a proteger los recursos de información. Por ahí dicen que “las métricas de seguridad son sirvientes de la administración del riesgo, y la administración del riesgo es acerca de tomar decisiones”.

Por lo tanto: “las únicas métricas de seguridad que nos deben de interesar son aquéllas que soportan la toma de decisiones respecto al riesgo con el propósito de manejarlo o administrarlo”.

Las métricas de seguridad son un tema relativamente nuevo e inmaduro (sobre todo comparado con otros indicadores como los que genera el sector financiero, por ejemplo); es una cuestión poco explorada y escasamente dominada como bien nos dice Andrew Jaquith en su libro “Security Metrics”. Que por cierto y como podrán intuir, este post se basa en la lectura que hice de algunos capítulos del mismo (en concreto, el 2: “Defining Security Metrics”).

Las métricas de seguridad intentan medir el nivel de seguridad (o un aspecto de ella) en una corporación y por cierto el estándar ISO/IEC 27001 las exige en el sentido de contar con métricas (indicadores) para medir la eficacia de los controles de seguridad que tenemos en la organización (no todos los controles, sino aquéllos que estén dentro del alcance establecido en el sistema de gestión que propone el 27001).

Ejemplifiquemos con el control contra código malicioso (antivirus).

Una métrica podría ser “cantidad de código malicioso detectado” o “número de actualizaciones de firmas mensuales”. Ambas, aunque indican algo, realmente no arrojan un valor con valor; nos quedamos más con cara de “so what?” Aquí viene al rescate Jaquith que nos dice las 5 características que toda métrica debería de tener:

a).- Obtenidas consistentemente. Si en un momento dado se obtienen valores diferentes debido al método usado para generarlas, no estoy haciéndolo consistentemente. “Días para aplicarle un parche crítico al 50% de los servidores”: si tú generas un reporte y obtienes 13 y yo 21 días, estamos fritos. Personas diferentes deberían de seguir un mismo procedimiento para arrojar resultados idénticos.

b).- Recolectadas sin esfuerzo. Tal vez el indicador sea muy relevante y útil, pero si tienes que invertir 20 minutos durante 30 días para obtener el indicador mensual, olvídalo. Deberíamos tratar de que la obtención de la métrica sea lo más automatizada posible a través de una herramienta. Es muy importante mantener en mente que se debe de invertir mucho más tiempo en analizar las métricas y sus tendencias que en generarlas.

c).- Expresadas con un número o porcentaje. Olvidémonos del rojo, amarillo y verde. O del muy alto, alto, medio, bajo, muy bajo. Las métricas deben de ser expresadas con números cardinales, es decir, que cuenten cuánto hay de algo “Minutos sin servicio no planeados”, “Porcentaje de avance en la aplicación de X parche”.

d).- Expresadas con al menos una unidad de medida. “Bugs presentes en las aplicaciones” tiene una unidad de medida: los bugs. De hecho, si consideramos “Bugs presentes por cada 1,000 líneas de código”, vemos que tiene dos unidades: bugs y líneas de código; es decir, la hemos enriquecido.

e).- Relevantes. La prueba del fuego para una métrica es cuando pasa el test del “so what?”. Es decir: “Cantidad de troyanos detectados por mes” tal vez cumpla con el resto de características antes mencionadas, pero y luego qué? ¿Qué significa?

En enero se detectaron 12,567 troyanos, en febrero 2,456 y en marzo 7,569. ¿Se puede tomar una decisión u acción? No, esos números cuentan troyanos y la variación de cada mes se podrá deber a factores como cantidad de USB insertados, archivos bajados, periodo vacacional del personal, etc.

¿Nos dice por ejemplo qué tan bien trabaja el antivirus? No, porque me dice cuántos detectó y eso no es un buen indicador de eficacia.

Cambiemos la métrica a “Cantidad de troyanos no detectados”. Es una métrica que nos hablaría de su eficacia: si es cero o tiende a cero significa que está haciendo su labor eficazmente. Valores más altos nos dirán que no está haciendo bien su labor y podríamos tomar una decisión luego de un análisis: comprar otro antivirus, prohibir los dispositivos USB o comparar un filtrado de contenido perimetral. Ese es el poder de esta métrica: que podemos tomar decisiones en base a los valores arrojados.

Sé lo qué están pensando. “¿Cómo diablos se puede obtener una métrica de troyanos no detectados y que por lo tanto se lograron colar?” Efectivamente, ningún antivirus te va a decir ese valor. A mi gusto, es una excelente métrica relevante para medir la eficacia, pero desgraciadamente su obtención es complicada e imprecisa por decir lo menos (se podría sacar en base a avisos de los usuarios donde la evidencia haya arrojado que el antivirus no logró detener esa infección).

Otras métricas relevantes del antivirus (y que sí se puedan generar con facilidad) sería la cobertura del control (% de equipos con antivirus), o el porcentaje de equipos que cuentan con la última firma de antivirus, entre otras.

Ya por último, algunas citas célebres en torno a este tema.

Fred Cohen: “The vast majority of information security-related measurement measures what is trivial to measure and not what will help the enterprise make sensible risk management decisions”

Andrew Jaquith: “Technical security metrics should not simply be “fun facts” that tell the CSO what a great job the security team is doing. They should reveal more interesting insights such as gaps in coverage, environmental stability or problems with change controls”.