Cuantificación de la seguridad

(La entrada de hoy es la tercera colaboración de Francisco Benet, un amigo de algunos de nosotros —y familia de algún otro— que tiene gran experiencia en la gestión e integración de sistemas, protección de datos de carácter personal y evaluación de soluciones de integración de software y hardware, entre otros aspectos. Esperamos que les guste.)

En el mundo empresarial, tan alejado del mundo real de la seguridad informática, todo debe ser cuantificable; se definen ROIs (Return On Investment), ROSIs (Return On Security Investment) y otros tantos conceptos con sus correspondientes acrónimos para poder cuantificar los gastos e inversiones. La norma es que todo debe ser metido en caja. Y esto aplica para la seguridad, ya que la seguridad aunque no lo parezca, también se vende.

Pero al final de la película, cuando nos vamos al día a día, no sabemos realmente cómo decirles a nuestros directivos dónde realmente se esta viendo esta inversión; cómo podemos cuantificar la seguridad que hemos ‘adquirido’ en un momento especifico del tiempo (porque la seguridad se compra, aunque ustedes no lo crean, y se compra porque alguien la vende). En ese momento es cuando se plantea la necesidad de los cuadros de mando de TI orientados a seguridad con sus distintos perfiles y niveles de acceso, en función de sus diferentes intérpretes y vistas. La cuantificación y análisis de los incidentes, incidencias y problemas nos darán la visión del estado real de la seguridad de la empresa.

Y eso se traduce en las métricas de seguridad, que provienen de la recolección de los datos, y que una vez analizados son presentados de forma que reflejen su valor para la empresa.

Ahora bien, ¿qué cuantificar?

Pues la cuestión es que en los distintos foros, de distinta índole (técnica, organizativa, de gestión, etc.), sólo parece haber un aspecto cristalino y en torno al que hay consenso: hay que cuantificar. Pero cuantificar, ¿el qué? Pues existen diferentes tipos de información: número de equipos infectados, número de portátiles extraviados, número de caídas de los sistemas o tiempo de inactividad, número de tarjetas de identificación perdidas (¿seguridad física? ¡Cooooorrecto!), número de no conformidades de auditoría no resueltas, políticas de seguridad que no se cumplen (en porcentaje), número de usuarios genéricos, incidentes en clientes relacionados con la seguridad, incidentes de seguridad debido a los clientes (podemos considerar que un extravío de tarjeta de crédito es un potencial incidente de seguridad), etc.

Tendremos, a partir de esta información, un mapa de atributos de seguridad que debemos cuantificar y que finalmente debemos valorar para poder llevar poco a poco la vista de seguridad hacia parámetros más identificativos y “abstractos”, de forma que los diferentes ‘actores’ que usen dichas métricas las encuentren útiles para la toma de decisiones. Es decir, ¿le diremos a la dirección cuantos sistemas se han visto atacados por el virus Conficker? Pues sí, se lo podemos decir, pero sería más lógico darle la visión del riesgo que tenemos en la proporción del uso del e-mail con archivos anexos no filtrados con el número de PC’s infectados y el número de PCs con el antivirus sin actualizar, por poner un ejemplo (que puede no ser completamente válido). En definitiva, deberíamos poder tener una aproximación arriba-abajo donde la información se agregará para los diferentes ‘organismos’ que controlen estos datos.

Las métricas deben ser realistas, eficientes y eficaces y deben guiarse buscando las respuestas a las preguntas relativas a negocio, reporting y seguridad, siendo éstas dinámicas y presentándose de manera adecuada a las audiencias. No deben enfocarse las métricas de seguridad hacia un único público, sino hacia todos los sectores de la empresa, pero presentando a cada uno su visión particular. El principal reto que tenemos es la traducción en costes de la métrica de seguridad y enfocar estas métricas a negocio ‘hablando su mismo idioma’.

A fin de cuentas, sólo pretendemos saber cual es la realidad de la seguridad, tanto para el director de Seguridad, como el de Desarrollo, el de IT, el de Negocio…

Pero, ¿por qué cuantificar?

Seguro que alguno de ustedes se pregunta por qué debería sacar estas métricas. Se me ocurren, a bote pronto, unas cuantas:

• Las métricas nos da una visión real de la situación de seguridad en la empresa, permitiéndonos gestionar mejor.
• Permiten actuar de forma preventiva al conocer las carencias o debilidades que tenemos.
• Las métricas indican cuales son los puntos en los que debemos invertir en temas de seguridad.
• Poder reportar cuando estamos gestionando la seguridad de nuestros clientes.
• Gestión del riesgo, tanto para los sistemas de gestión propios, para las auditorías de terceros (proveedores, clientes, organismos reguladores) o certificaciones ISO.
• Para poder dotar de estrategia a la seguridad.

Naturalmente hay muchos más ‘drivers’ que nos llevan a cuantificar, pueden ser específicos o no de cada empresa, pero a mi gusto los arriba expuestos deben ser suficientes para convencer a cualquiera de la necesidad de desarrollar métricas de seguridad.

Algunos ejemplos.

Bien, cada empresa es un mundo y nunca una es igual que otra, pero aquí presento algunos datos que pueden ser útiles para construir métricas. Naturalmente, estos datos deben ser respuestas a la pregunta de cada métrica, ya que no podemos recopilar datos por que sí, es una tarea costosa y debe ofrecer algún valor:

• Número de virus por e-mail, pc, portátil.
• Número de tarjetas de identificación perdida, portátiles perdidos, teléfonos, PDA’s, tapes, …
• Número de backups con errores.
• Número de sistemas sin backup.
• Clasificación de datos sensibles por su distribución en los sistemas (es decir, cómo de esparcida está la información sensible de la organización).
• Tiempo de recuperación de los sistemas.
• Uso del e-mail: IN/OUT. Sobre todo e-mails con attachments y en relación con correo de webmails tipo hotmail/gmail/yahoo.
• Auditorías mensuales / test de penetración: vulnerabilidades detectadas en servidores y el coste de éstas (impacto y acción de parchearlas).
• Número de personas del security staff: estimación de la gestión de la seguridad que se esta realizando. Esfuerzo versus beneficio.
• Número de políticas de seguridad.
• Número de proyectos gestionados dentro de la organización que no siguen o se desvían de la política de seguridad: da una visión del estado de la seguridad a nivel organizativo/procedimental y el estado de la implementación, así como la realidad de las políticas.
• Número de incidentes del firewall.
• Número de falsos positivos contra positivos críticos.
• Número de usuarios con password bloqueado y accesos fallidos.
• Número de registros de usuarios por usuarios privilegiados por aplicaciones con registro de usuarios propios. Da una visión de la gestión de los usuarios y la complejidad de los procedimientos.
• Y un largo etcétera.

Hablando de métricas a un nivel más alto deberiamos considerar estos puntos:

• Métricas relacionadas con el cumplimiento de políticas de seguridad, con las que podemos ver el estado de la seguridad general.
• Número de proyectos en ejecución por número de evaluaciones del riesgo ejecutadas (risk assessments).
• Número de políticas modificadas o creadas en el último periodo.
• Número de revisiones de seguridad del código fuentes por errores de diseño encontrados (pensemos que podemos estar ofertando software al exterior, o comprándolo made-in-house).
• Número de incidentes de seguridad (ataques DoS, XSS, phising…) y su coste para la organización.
• Concienciación de los usuarios: e-learning, formación en seguridad, training específico. Mucho se ha hablado de este tipo de iniciativas, que no se están realizando extensivamente en el mercado.
• Número de casos abiertos por el departamento de auditoría y resueltos. El departamento de auditoría interna juega un papel bastante importante en la gestión del riesgo y seguridad.
• Número de documentos mal clasificados o no clasificados. La clasificación de documentos y su uso es un factor importante para medir la seguridad.

Naturalmente estas son unas cuantas, pero seguro que a cualquier ávido lector se le ocurren muchas más.

¿Cómo presentar estas métricas?

El cómo presentar una métrica siempre es un punto que, pese a parecer falto de complejidad, presenta grandes problemas: ¿un portal? ¿un dashboard? ¿un e-mail? Al final, creo que el cómo debe responder más al lector que al presentador, y sobre todo seamos prácticos; ¿Realmente es necesario un portal? ¿Por qué no presentar una Excel al comité de dirección cada mes? ¿Cómo de necesario es que las métricas estén al día para el director de Negocio —que no para el de IT?

El autor de este texto no cree que las soluciones únicas sean válidas, en este caso la audiencia manda y cada organización tiene unas necesidades.

Y ahora manos a la obra.

Cuando te enfrentas a la definición de un conjunto de métricas siempre suele existir una confusión sobre los datos y las métricas. No hay, sin embargo, gran complejidad: los datos se recogen, y las métricas salen del análisis de los datos. Y ya está.

Los datos residen en aplicaciones, sistemas operativos, registros de entrada, documentos, etc., y se deben recolectar, normalizar, agregar y correlar (por ejemplo, la caída intermitente de un mismo servicio durante tres minutos cada hora a lo largo de tres días no son 72 incidencias, es 1 problema). Todo esto es costoso y puede requerir de herramientas adicionales, de tiempo de proceso y nunca esta exento de complejidad; nadie dijo que fuese fácil.

No hay que olvidar un aspecto básico: debe existir un balance entre el beneficio y el coste. Demasiadas medidas eliminan la eficiencia, y eso debe ser un aspecto a tener en cuenta desde el principio.

A partir de estos puntos se podría decir que los pasos básicos pueden ser :

1. Identificar las guías para la definición: preguntas a responder, requisitos legales, objetivo de las mediciones.
2. Identificar lo que puede recolectarse: datos y su análisis.
3. Identificar los datos que se necesitan: implementar un plan de recogida.
4. Diseñar las métricas: proveer de meta-metricas, definirlas, y entenderlas.
5. Focalizar nuevas áreas: definir la granularidad de las métricas y el scope.
6. Seleccionar la forma (o formas) de presentación y la audiencia.
7. Responder al punto 1: si no es posible responder todas las preguntas, elegir la mejor respuesta posible.

Para acabar, como consejo publicitario (como dicen en la tele), y teniendo en cuenta que ni me llevo comisión ni estoy en nómina, recuerden, si ustedes no tienen tiempo o se ven perdidos en el camino, no duden que S2 Grupo siempre podrá ayudarles.

(N.d.E.: Como verán, hemos creado una cuenta Twitter asociada al blog. Pueden seguir los updates a través del blog o en la propia página de twitter. Espero que sirva para contar aquellas cosas que no dan para una entrada pero si para algo más breve. Quedan invitados a suscribirse, como no podría ser de otra manera.)