Los Falsos Positivos en un SOC y 4 recomendaciones para evitarlos.

Hoy en día, los sistemas informáticos trabajan una gran cantidad de datos que viajan a través de la red. Es un hecho que el crecimiento de la información es exponencial en las últimas décadas, el solo hecho de querer automatizar los procesos operativos, o cumplir con regulaciones internas y externa implica un aumento en la generación de datos, por esta razón, las organizaciones se ven en la necesidad de definir un nuevo número de accesos, permisos, roles y políticas para la gestión de esos datos.

Estos nuevos accesos y permisos tienen como consecuencia un mayor número de amenazas y vulnerabilidades y también algo no menos importante un mayor tiempo de operación de los administradores de dichos sistemas informáticos.

Bajo esa premisa, el hecho de generar nuevos procedimientos, políticas, permisos, etc., provoca también el aumento del tamaño de la información, generando así un círculo vicioso al surgir la necesidad de gestionar lo que regula y mide a esos procedimientos, políticas y permisos.

En organizaciones donde se requiere estar monitoreando constantemente el flujo de toda esta información, generalmente se cuenta con una tecnología SIEM (Security Information & Event Management) el cual se encarga de colectar la información de todos los sistemas informáticos, llámese Anti Virus, IPS, Firewalls, Switches y los propios equipos de los usuarios.

Tomaremos de ejemplo, a los dispositivos IPS, Anti Virus y al SIEM, para darle sentido al título del artículo, estos dispositivos habitualmente forman parte de un centro de monitoreo de seguridad (SOC/NOC) donde los analistas se encargan de alertar/prevenir ataques y amenazas detectadas en este conjunto de soluciones de seguridad; la tendencia de estos dispositivos es la incorporación de inteligencia para reconocer nuevos ataques basado en patrones y comportamientos. El reconocimiento automático de patrones, permite identificar si hay tráfico malicioso o anomalías y variaciones del flujo de información habitual.

El problema surge en el reconocimiento automático de patrones; debido a esa inteligencia, las soluciones tienen que tomar decisiones en cada detección, que pueden ser verdaderas o falsas. Por lo tanto, son 2 los posibles resultados:

• Falso Positivo (FP).
• Falso Negativo (FN).

El dolor de cabeza de los operadores y analistas son los falsos positivos, que son los eventos detectados como alertas pero que en realidad no se trataban de algo malicioso sino de algo anómalo, estos falsos positivos de entrada se traducen en tiempo perdido para el analista del SOC/NOC que tendrá que documentar la amenaza o seguir ciertos procedimientos, además, también provoca la generación de tráfico, logs, alertas y reportes que al final día son innecesarios.

Por esa razón y en base a la experiencia obtenida estos últimos años en el área, propongo 4 simples recomendaciones para evitar en gran medida estos falsos positivos, y vernos beneficiados con menor pérdida de tiempo y menor generación de información basura.

1. Documentar con exactitud el flujo de la información.

Es indispensable un buen análisis y diseño de los flujos de información, pero sobre todo la priorización de los eventos considerados sensibles para la organización, antes de construir las Alertas /Reportes, más vale invertir tiempo en el análisis a que la alerta se esté disparando con la incertidumbre de la veracidad de su contenido.

2. Crear Exclusiones desde el inicio.

Recordar que la gran mayoría si no es que todas las aplicaciones adquiridas por una organización, de manera oficial presentan las exclusiones necesarias para su óptimo funcionamiento, las cuales deberán ser consideradas en la configuración de los Anti Virus, Firewall, etc. Si hay aplicaciones hechas en casa, considerar la definición del flujo exacto para definir también la o las exclusiones pertinentes y de igual manera aplicarlas en todos los dispositivos de seguridad.

3. Poner a prueba las alarmas construidas y simular ataques.

Probar, probar y probar, es importante la simulación de los posibles eventos indeseados con las Alertas/Reportes construidos, y hacer una buena afinación en los criterios de alertamiento.

4.Crear reglas o filtros de descarte.

La gran mayoría de las veces, enviamos toda la información que genera un dispositivo, y generalmente es el nivel de la criticidad del evento es configurable para su envió (critical, high, normal, debug), es indispensable hacer una valoración de los tipos de eventos que necesitamos auditar, eventos de categoría normal o de debug no siempre son de utilidad y son los que más información basura generan.

“La tecnología no se gestiona sola, el verdadero valor surge de su correcta y dedicada manipulación”

TrustDimension cuenta con la disposición de todo el equipo de trabajo, para apoyar y orientar en las necesidades de esta naturaleza incluyendo el apoyo de nuestros fabricantes RSA y LogRhythm expertos en tecnología de SIEM.