KPI - No se puede evaluar lo que no se puede medir

No se puede evaluar lo que no se puede medir

...y, para poder medir un proceso se debe contar con algún tipo de indicadores.
Los KPI ("Key Performance Indicators", o indicadores claves del desempeño) son métricas orientadas a cuantificar el grado de cumplimiento de un objetivo de negocio, por parte de un proceso.
La mayoría de las métricas que se utilizan en seguridad desafortunadamente no cumplen con esta definición. Típicamente usamos indicadores de efectividad técnica u operativa que no podemos relacionar directamente con el cumplimiento de objetivos de negocio.
Además, la mayoría de estos indicadores son específicos para cada control (no describen un proceso, que es otro requerimiento para considerar como clave a un indicador).
Algunos ejemplos de indicadores que usamos típicamente en seguridad:

• Número de ataques prevenidos/detectados (FW, IPS, etc.)
• Número de programas maliciosos detectados (antivirus, antispyware, etc.)
• Número de incidentes de seguridad reportados y atendidos (equipos de respuesta ante incidentes)
• Número de actualizaciones de seguridad
• Tiempo de respuesta para atender incidentes
• Tiempo promedio de distribución de parches de seguridad

Como referencia, en KPI library pueden encontrar cientos de indicadores adicionales de diversos tipos. (Ej. information+security, Outsourcing)
Las 2 preguntas que queremos responder en este artículo son: 

• ¿Cuáles de estos indicadores técnicos realmente nos sirven? 
• ¿Cómo podemos generar indicadores de seguridad de la información, que sean realmente claves para el negocio, a partir de ciertos indicadores técnicos?

Indicadores técnicos

Debemos distinguir entre indicadores técnicos que son útiles y aquellos que son meramente informativos y no aportan datos concretos sobre la efectividad de un control.
Los indicadores que son útiles miden cosas que están bajo nuestro control y no dependen del entorno.
Ejemplos de malos indicadores técnicos:

• Controles:
• Número de virus detectados
• Número de cambios en configuración
• Número de parches aplicados en el mes
• Número de intentos de ataque detectados
• Número de cintas de respaldo generadas en un mes
• Procedimientos:
• Número de solicitudes atendidas
• Horas invertidas en solución de problemas

Ejemplos de buenos indicadores:

• Controles:
• Porcentaje de virus detectados y eliminados oportunamente
• Porcentaje de ataques prevenidos
• Porcentaje de parches críticos aplicados en el mismo mes de su liberación
• Procedimientos:
• Tiempo promedio de restauración de un sistema a partir de un
• Tiempo de respuesta promedio para solución de un incidente
• Costo promedio de solución por incidente (horas hombre + recursos materiales)

De los ejemplos anteriores, es claro que los buenos indicadores son el resultado de una ponderación entre acciones ejecutadas correctamente y acciones incorrectas (siendo las acciones incorrectas la suma de falsos positivos y faltos negativos). También son buenos indicadores las métricas de niveles de servicio (tiempo) y costo, relacionadas únicamente con variables locales.

Manejo de indicadores técnicos
Es claro que generar cientos de indicadores a nivel técnico no es sinónimo de un mejor control o de mayor precisión. Tenemos que utilizar la cantidad mínima necesaria de indicadores técnicos para armar los indicadores clave de despempeño que requiere el negocio, pero además tenemos otros problemas:

• La medición de eventos prevenidos - medir eventos reales (incidentes) con un impacto al negocio es relativamente fácil. Basta con revisar la lista de reportes de la mesa de servicio, pero existen una gran cantidad de controles que no documentan eventos prevenidos con éxito (Ej. ¿cuántos incidentes previno el candado de una laptop? ¿Cuántos incidentes previno la desactivación de servicios no indispensables en un servidor?
• El empalme de controles - Cuando hay controles que trabajan en conjunto (en diferentes capas usualmente) es difícil medir la eficacia de cada uno de ellos. Por ejemplo, el hecho de que un firewall por su configuración haya evitado que cierto tráfico de propagación de un virus nuevo pasara hacia la red interna, no asegura que un antivirus o un IPS detrás de este firewall hubieran podido actuar eficazmente sobre este evento.

Si no podemos medir con toda certeza falsos positivos y negativos, no podemos determinar un indicador de efectividad a nivel de un control particular.

Por otro lado, si no podemos saber con certeza la reacción de un control ante un evento que en teoría debería prevenir pero que detuvo otro control, tampoco tenemos métricas de falsos positivos y negativos confiables.

Parecería que es imposible poder medir la eficacia de todo tipo de controles y procedimientos que tenemos, sin embargo ¿realmente necesitamos llegar a este nivel de detalle para generar indicadores clave de desempeño?

La respuesta es no. Sin embargo, es importante aclarar que los indicadores técnicos y operativos no son inútiles y debemos generar todos aquellos que se puedan, para cada control y procedimiento.

La diferencia es que no los vamos a usar para generar los indicadores clave, sino como herramienta de diagnóstico para determinar qué controles y procedimientos debemos reemplazar cuando los indicadores clave de desempeño nos indiquen que debemos mejorar algo.

Indicadores clave y técnicos que requerimos
Sólo necesitamos 2 tipos de indicadores (uno técnico y otro de negocio) para generar los indicadores clave:

• Costo estimado de la solución por día = (Costo de la solución de seguridad anualizado + costo de incidentes reales en el año) / 365
• Costo anualizado incluye:
• Costo de controles y su mantenimiento +
• Sueldos de personal a cargo +
• Costo de servicios tercerizados
• Costo de incidentes reales en el año incluye eventos de pérdida documentados con costos asociados al negocio
• Costo promedio por incidente (sin considerar controles)
• Es el costo de un evento antes de considerar controles (los controles afectan probabilidad de ocurrencia o impacto en este costo), es decir, el costo puro como lo percibe el negocio
• Se recomienda separar por tipo de evento:
• Integridad
• Confidencialidad
• Disponibilidad
• Autenticidad
• Si no se tienen datos históricos suficientes para determinar este dato, se pueden usar promedios de la industria, aunque evidentemente puede haber variaciones significativas con respecto al negocio (ej. el estudio de costos por fuga de información del Instituto Ponemon).

Dado que no podemos asegurar el contar con indicadores de eficacia para todos los controles, vamos a estimar el costo de protección por evento y compararlo contra el costo promedio de cada evento.

En este caso, es razonable asumir que se puede generar un evento potencial en un día cualquiera del año (no sabemos cuántos en el año pero asumimos que al menos se generará uno por año) y que el costo de protección de un día es cercano al costo de protección de un evento, considerando que para la mayoría de los casos, las empresas agrupan eventos  de un mismo tipo en un incidente por día; es decir, si por ejemplo no tuviéramos un antivirus instalado y sufriéramos en consecuencia la caída de varios equipos por infecciones, la mayoría de las empresas tratarían la situación como un único incidente en el mismo día (con varios elementos afectados), en vez de distinguir entre los eventos generados por cada tipo de malware que participó.

Dado lo anterior, también es razonable asumir que el costo promedio de protección por un día debería ser menor al costo promedio de un tipo de incidente determinado. Como seguramente ya habrán adivinado, este balance constituye nuestra propuesta de indicador clave de desempeño:

• KPI para una solución de seguridad = costo estimado de la solución por día - costo promedio de incidente

Para ser costo-efectiva, la solución deberá producir un resultado negativo en el KPI.

Posted in: Mundo Empresa, Seguridad