Entender y definir métricas prácticas en las operaciones de seguridad

En la industria de la ciberseguridad, la vinculación de las métricas de rendimiento con la estrategia se ha convertido en una buena práctica aceptada. Si la estrategia es el plano del proyecto para construir un centro de operaciones de seguridad (SOC), las métricas son la materia prima. Pero hay una trampa: una organización de seguridad puede perder fácilmente de vista su estrategia y centrarse estrictamente en las métricas que se supone que la representan. 

Una encuesta reciente de SANS mostró que el 77% de los centros de operaciones de seguridad indicaron que proporcionan métricas para medir el estado y la eficacia de las capacidades del SOC. Esto representa un aumento del 50% en los programas de métricas de los SOC en los últimos cinco años. Sin embargo, el 33% de los encuestados indicaron que no estaban satisfechos con sus métricas.

¿Por qué algunas métricas son buenas y otras no tanto? Todas las métricas son inherentemente imperfectas en algún nivel. En seguridad, al igual que en los negocios, la intención de las métricas suele ser captar algún objetivo intangible subyacente—y casi siempre no lo consiguen tan bien como se esperaba. Los sistemas de gestión del rendimiento están llenos de métricas que son representaciones defectuosas de lo que le importa. Evidentemente, esto se convierte pronto en un problema debido a las muchas formas de aumentar las puntuaciones y, al mismo tiempo, disgustar a las partes interesadas. Vincular los incentivos financieros a una métrica suele ser un error: a menudo sólo aumenta la atención sobre los números. 

Aunque es fácil caer en esta trampa de las métricas, las organizaciones de seguridad pueden tomar medidas para evitarlas. Por ejemplo, involucrar a las personas que van a aplicar una estrategia en su formulación significa que es más probable que la entiendan y menos probable que la sustituyan por una métrica. El uso de múltiples criterios también es un enfoque útil, dado que resalta el hecho de que ninguna métrica por si sola abarca toda una estrategia.

Los programas de medición eficaces aprovechan los datos a los que ya se tiene acceso. La mecánica de la medición es la parte fácil. También hay que definir con precisión las expectativas debidamente situadas que estén vinculadas a la estrategia de seguridad. Esta es la parte difícil. Debe haber un mecanismo de control de calidad para evitar las anclas mentales de verde/amarillo/rojo basadas en tiempo. Las métricas no deberían ser siempre objetivos de nivel de servicio (SLO).

Veamos con más detalle cómo medir e informar eficazmente de las métricas de un SOC típico.

Salud de las fuentes de datos

Al monitorear los datos, los activos y los usuarios con instrumentación, lo primero que hay que hacer es saber si están funcionando bien. Lo primero a revisar es qué puntos de monitoreo están caídos. Sin embargo, el hecho de que estén funcionando no significa que todo esté bien. Puede haber retrasos en la recepción, caídas u otras anomalías temporales o permanentes. Mídalas y revíselas regularmente.

Cobertura

Para sus mediciones de cobertura, el seguimiento del número absoluto y del porcentaje de cobertura por entorno informático/enclave/dominio es un punto de partida que merece la pena. A medida que se va obteniendo información más detallada sobre la red, el sistema operativo y las aplicaciones, surgen datos adicionales que muestran lo que puede funcionar o no en su estrategia. El seguimiento de la cobertura de alertas y detecciones en el marco de ATT&CK (o tácticas, técnicas y conocimientos comunes del adversario) es una forma ideal de informar holísticamente en cuanto a si su enfoque actual le protegerá contra las diversas tácticas utilizadas por los cibercriminales para atacarle. 

La cobertura es siempre un objetivo cambiante. Siempre habrá más piedras que voltear. Siempre hay otro entorno que cubrir o un cliente al que servir. No se debe apuntar al 100%, ya que en la cobertura no hay lugar para jactarse de los aciertos. En su lugar, concéntrese en el porcentaje de sistemas "administrados", es decir que activos están inventariados, se vincularon a un usuario y/o a una unidad de negocio, se comprobaron las configuraciones y se evaluó el riesgo. De este modo, su SOC sabe lo que está supervisando y puede identificar con mayor claridad las entidades no adecuadas en el entorno.

Escaneo y barrido

En el nivel básico, probablemente usted esté escaneando los activos locales y en la nube en busca de vulnerabilidades. Debería medir el número y el porcentaje de errores conocidos, así como la cantidad de tiempo que le llevó recopilar el estado de las vulnerabilidades y los riesgos durante su último simulacro de un evento de seguridad de CVE para los titulares. A medida que avanza, empiece a medir el tiempo que se tarda en barrer y compilar los resultados de una determinada vulnerabilidad o indicador de compromiso (IOC), y entre estaciones de trabajo versus servidores. Desglóselo aún más para obtener información específica de un determinado dominio o plano de identidad. A continuación, concéntrese en todo lo que se refiere a Internet.

Al final, debería tener un número y un porcentaje precisos de los activos que no puede cubrir o que no cubre y poder responder a las preguntas: "¿Qué tan fructífero es nuestro escaneo?" y "¿Qué tan efectivo es nuestro parcheo?".

Rendimiento de los análisis y de los analistas

A continuación, es necesario conocer qué tan bien nos está funcionando la instrumentación—o mejor aún, qué tan bien se está utilizando— En este punto es conveniente vincular nuestros esfuerzos en MITRE ATT&CK. Hay que ser minucioso en la cobertura, la documentación y los estándares de salida. Todo el esfuerzo de diagnóstico del mundo es inútil si algo se pasa por alto, o peor aún, si se encuentra, pero no se comunica de forma completa y precisa.

Más adelante, podrá realizar revisiones periódicas de los resultados de los análisis para determinar la exactitud de los mismos en función de quién ha analizado qué y cuándo, y en qué clases de activos. Tenga cuidado con la objetividad también en este caso, e introduzca controles y equilibrios contra el uso de prácticas poco ortodoxas en este “juego”. Con el tiempo, debería ser capaz de responder a las preguntas: "¿Cómo de fructíferas son las detecciones de cada autor?" y "¿Cómo de bien está apoyando a sus clientes?"

Gestión de incidentes

La siguiente categoría de métricas incluye el rendimiento de los analistas y las medidas de gestión de incidentes que suelen estar basadas en el tiempo. Reitero mi recomendación anterior sobre las métricas basadas en el tiempo: estas analíticas deben tener un mecanismo de control de calidad para garantizar que el trabajo se hace bien y que las métricas no se manipulan. Las inversiones en automatización también pueden demostrarse aquí ilustrando las eficiencias y consistencias obtenidas.

El tiempo medio de permanencia del adversario es el rey de las métricas. Como defensores, queremos reducirlo. Los componentes de esta métrica fundamental son los tiempos medios de clasificación, escalado, identificación, contención, erradicación y recuperación. Obtenga información sobre sus principales fuentes de incidentes confirmados. Compárelo con las fuentes que generan más falsos positivos (y, por tanto, fatiga de alertas). Estos esfuerzos deberían abrir debates sobre si se están sacando conclusiones incorrectas o ambiguas, y si esos errores están correlacionados con datos o procesos deficientes.

Áreas de mayor riesgo e higiene

Por último, elija los elementos de riesgo más importantes de sus propias métricas de evasión de incidentes y de los informes públicos de inteligencia para centrarse en ellos cada año, semestre o trimestre. ¿Qué puede decir a los administradores de sistemas sobre los resultados de sus esfuerzos de escaneo y parcheo? ¿Qué riesgos y mitigaciones de la aplicación de la firma de código le gustaría transmitir a los desarrolladores? Socialice estos resultados con las partes interesadas internas, pero hágalo digerible y no se exceda. Ellos ya tienen un interés en el trabajo que está haciendo en materia de seguridad. Depende de usted abrir sus corazones y mentes a ello.

Conclusión

Aunque los programas sobre métricas están creciendo en las organizaciones de seguridad, es importante asegurarse de que esas métricas se construyan y se utilicen con eficacia. Como la estrategia es abstracta, los empleados a menudo la sustituyen mentalmente por las rígidas métricas destinadas a evaluar si la organización está teniendo éxito. La estrategia de seguridad no debe ser secuestrada por los números. En su lugar, las métricas de seguridad deben ayudar a examinar, diagnosticar y evaluar el rendimiento con respecto a la estrategia de seguridad.