Cómo todo empezó
Curiosamente, nuestros primeros pasos hacia la formación de KPI para Solar JSOC no estaban relacionados de ninguna manera con los centros de monitoreo y respuesta a los ataques cibernéticos. “En los albores de nuestra juventud”, ayudamos a las empresas a crear sistemas para evaluar la eficacia de la seguridad de la información (ISMS 27001 y eso es todo). La comprensión de su necesidad surgió entonces en el mercado de forma natural: casi cualquier departamento de seguridad de la información se ve obligado día tras día a analizar grandes cantidades de datos de muchos sistemas diferentes. Por supuesto, cada uno de ellos tiene algún tipo de informe, pero con un gran número de ellos, es muy difícil formarse una imagen holística del estado de la seguridad de la información y, posteriormente, proporcionar un informe a la gerencia en un formato conveniente. El problema se agrava si la organización está dispersa geográficamente.
Simplemente ayudamos a los clientes a crear no solo un complejo de indicadores clave de rendimiento / métricas, sino una solución analítica completa que agrega datos de los sistemas de seguridad de la información. De hecho, es un sistema de visualización, en el que se puede ver de forma rápida y sencilla la esencia del problema y su localización para tomar rápidamente las decisiones necesarias. En estos proyectos, ganamos experiencia y llegamos a la conclusión de que el sistema es realmente conveniente y útil. Y también, que el trabajo del SOC también necesita ser evaluado.
¿Por qué evaluar la efectividad de un SOC, especialmente uno externo?
Es simple: por un lado, queremos comprender qué tan bien brindamos el servicio y, por otro, tener la imagen más completa de la infraestructura del cliente, ver todos los “puntos negros” que no fueron incluidos en nuestra auditoría y se convirtieron en factores de riesgo para el servicio. En pocas palabras, queremos entender: veremos este o aquel ataque al cliente o no.
Cuando comenzamos a trabajar como proveedor de servicios, sucedió que el cliente se negó a darnos fuentes específicas de conexión, que eran necesarias para la identificación al 100% del ataque. Como resultado, ocurrió tal ataque, no lo vimos y recibimos reproches, a pesar de nuestra advertencia inicial.
Otro ejemplo: dijimos que para poder identificar de manera correcta y precisa una incidencia es necesario configurar las fuentes de cierta manera, entregamos una lista de estos ajustes, pero el cliente no realizó este trabajo. El resultado es el mismo: un incidente perdido.
Así que entendimos que es importante destacar explícitamente tanto al cliente como a nosotros mismos, qué vemos exactamente en su infraestructura, dónde hay "puntos ciegos" para nosotros, qué vectores de ataque se implementan con mayor frecuencia y en qué áreas, qué TI los activos son más susceptibles a los ataques y cómo esto puede afectar al negocio. Para ello, el sistema de visualización debe mostrar la situación real y ayudar en su análisis, y no solo ser un "efecto sorpresa" para el liderazgo (como suele ser el caso).
KPI para SOC: ¿qué y cómo medir?
En primer lugar, debe comprender: ¿por qué, por qué necesita este mismo sistema de métricas / KPI? ¿Quiere medir el desempeño de su departamento de seguridad de la información? ¿Comprende qué tan bien / exitosamente (o viceversa) se están desempeñando sus procesos? O tal vez simplemente mostrarle a la gerencia, "¿quién es genial?" ¿O quizás las bonificaciones de los departamentos dependen del rendimiento de los KPI? Sin comprender los objetivos de evaluar la eficacia, es imposible construir un sistema de KPI de la vida real.
Digamos que hemos decidido los objetivos, y ahora surge la pregunta más interesante: ¿cómo medir algo? No puedes ir al SOC con una regla, aquí todo es un poco más complicado. Después de todo, esto no es solo SIEM como un sistema para recopilar y correlacionar eventos de seguridad de la información, también es una gran variedad de sistemas que permiten que el servicio funcione correctamente. Hay una enorme cantidad de datos dentro del SOC, por lo que hay mucho que evaluar.
Y en este asunto, estamos tratando de alejarnos de los KPI subjetivos tanto como sea posible, es decir, aquellas métricas que no se pueden medir automáticamente. Por ejemplo, la métrica "Qué tan mal está todo con nosotros" es difícil de evaluar directamente, sin la participación de una persona (quien dará su
Al construir nuestro sistema de KPI, nos adherimos a los siguientes principios:
- El KPI debería ser realmente importante tanto para el SOC como para el cliente;
- el indicador debe ser medible, es decir se deben construir fórmulas de cálculo específicas y establecer valores de umbral;
- deberíamos poder influir en el valor del indicador (es decir, las métricas de la categoría "porcentaje de días soleados por año" no son adecuadas para nosotros).
También llegamos a la conclusión de que el sistema de KPI no puede ser plano y debe tener al menos tres niveles:
- "Estratégico": estos son los KPI que reflejan el panorama general del logro de los objetivos establecidos;
- "Investigación, análisis, identificación de conexiones": son KPIs, a partir de los cuales se forma el primer nivel y que contribuyen a la implementación del objetivo principal.
- « »: KPI, ( – ).
Cada uno de los indicadores afecta al superior. Dado que esta influencia no es la misma, a cada uno de los indicadores se le asigna un factor de ponderación.
Por supuesto, lo primero que queremos ver todo el tiempo es cuán efectivo es nuestro servicio para nuestros clientes. Y, por supuesto, esta información debe ser oportuna. Para ello, hemos desarrollado (y seguimos mejorando) un sistema de métricas que refleja la calidad de trabajo de cada uno de los servicios: 1ª y 2ª líneas, jefes de servicio, analistas, respuesta, administración, etc. Para cada una de estas áreas, Aproximadamente 10-15 KPI: se calcularon sobre la base de una base de datos de los sistemas en los que trabajan los chicos (si las solicitudes se cumplen a tiempo, qué tan rápido respondemos a la solicitud del cliente, cómo se conectan las fuentes y mucho más).
El SLA es bueno, pero la calidad real del servicio es más importante
Para nosotros es importante que la cobertura del servicio nos permita identificar el máximo número de incidentes y ataques, y no quedarnos ciegos. Para que podamos interpretar las incidencias del cliente en el formato de sus propios activos de TI, y no en IP abstractas. Para que nuestras notificaciones no se reduzcan al hecho de que "Mimikatz se encontró en el host 10.15.24.9", y no obligaría al cliente a averiguar de forma independiente qué tipo de host es, perdiendo el tiempo necesario para responder y eliminar las consecuencias.
En otras palabras, es importante que comprendamos qué tan bien están protegidos nuestros clientes de SOC. Entonces, es necesario determinar qué tan detallados y suficientes los "vemos":
- son todas fuentes importantes conectadas a nosotros;
- cuán eficientemente el sistema de seguridad de la información del cliente (también son fuentes de nuestro servicio) cubre su infraestructura;
- ¿Están todas las fuentes configuradas como recomendamos y cuáles son las desviaciones?
- si se han lanzado en las instalaciones del cliente todos los escenarios necesarios y suficientes para la detección de ataques e incidentes;
- si todas las fuentes conectadas nos envían eventos con una regularidad determinada;
- si el cliente reacciona a todas nuestras notificaciones y cuán oportuno lo hace.
Y también - qué "aterrador es vivir dentro de este cliente", es decir:
- con qué frecuencia es atacado, cuál es la gravedad de estos ataques (dirigidos o masivos), cuál es el nivel del atacante;
- qué tan efectiva es la protección del cliente (procesos y sistemas de seguridad de la información) y con qué frecuencia se actualiza;
- cuál es la criticidad de los activos involucrados en los incidentes, cuáles de los activos son utilizados por los atacantes con mayor frecuencia, etc.
Para calcular todos estos indicadores de alto nivel, primero debe dividirlos en indicadores más pequeños y esos en otros aún más pequeños, hasta que alcancemos el nivel
El ejemplo más simple: existe un indicador de alto nivel "Efectividad de los procesos de seguridad de la información", compuesto por otros más pequeños, como "Grado de protección frente a malware", "Grado de gestión de vulnerabilidades", "Grado de protección frente a incidentes de SI", "Eficiencia del control de acceso", etc. ... Como se implementan muchos procesos de seguridad de la información en una organización, habrá tantas métricas del segundo nivel. Pero para calcular la métrica de segundo nivel, debe recopilar métricas aún más precisas, por ejemplo, "El grado de cobertura de los hosts de la organización por antivirus", "El porcentaje de incidentes críticos con malware", "La cantidad de activos involucrados", "El porcentaje de falsos positivos", "El nivel de alfabetización cibernética de los usuarios". , "Porcentaje de hosts en una organización con protección antivirus desactivada", "Porcentaje de hosts con bases de datos antivirus desactualizadas": puede seguir y seguir.Y estas métricas de tercer nivel se pueden recopilar de herramientas de seguridad de la información y otros sistemas en modo automático, y el cálculo se puede realizar en el sistema de análisis de seguridad de la información.
La creación de KPI y la gestión del rendimiento de los SOC sigue siendo un desafío tanto para los desarrolladores de estas métricas como para el cliente (y este es un baile exclusivamente en pareja). Pero el juego vale la pena: como resultado, puede evaluar de manera completa, centralizada y rápida el estado de la seguridad de la información, encontrar debilidades, responder rápidamente a los incidentes y mantener actualizado el sistema de seguridad de la información.
Si el tema resulta interesante, hablaré más sobre métricas en artículos futuros. Entonces, si desea conocer algún aspecto específico de la medición del COS, escriba los comentarios; intentaré responder a todas las preguntas.
Elena Trescheva, analista principal de Solar JSOC