Mi objetivo es analizar los registros de red (p. Ej., Apache, syslog, auditoría de seguridad de Active Directory, etc.) utilizando la detección de agrupamiento / anomalías para fines de detección de intrusos.
De los registros tengo muchos campos de texto como dirección IP, nombre de usuario, nombre de host, puerto de destino, puerto de origen, etc. (en total 15-20 campos). No sé si hay algunos ataques en los registros, y quiero resaltar los eventos más sospechosos (valores atípicos).
Por lo general, la detección de anomalías marca los puntos con baja probabilidad / frecuencia como anomalías. Sin embargo, la mitad de los registros contienen una combinación única de campos. Entonces, la mitad de los registros en el conjunto de datos tendrá la frecuencia más baja posible.
Si uso la detección de anomalías basada en la agrupación (por ejemplo, encontrar grupos y luego seleccionar puntos que están lejos de todos los centros de grupos), necesito encontrar la distancia entre los diferentes puntos. Como tengo 15-20 campos, será un espacio multidimensional, donde las dimensiones son nombre de usuario, puerto, dirección IP, etc. Sin embargo, la distancia de Mahalanobis solo se puede aplicar a entidades distribuidas normalmente. Esto significa que no hay forma de encontrar la distancia entre los puntos de datos y construir grupos ...
Por ejemplo, imaginemos que tengo usuarios Alice, Bob, Carol, Dave, Eve y Frank en el conjunto de datos de 20 registros. Podrían tener el siguiente número de ocurrencias en la base de datos: 2,5,2,5,1,5. Si simplemente mapeo nombres de usuario a números, por ejemplo
Alice --> 1
Bob --> 2
Carol --> 3
Dave --> 4
Eve --> 5
Frank --> 6
Entonces, mi distribución de probabilidad para los nombres de usuario será la siguiente:
p (1) = 0.1, p (2) = 0.25, p (3) = 0.1, p (4) = 0.25, p (5) = 0.05, p (6) = 0.25
Por supuesto, esta no es una distribución normal, y esto tampoco tiene mucho sentido, ya que podría asignar nombres de usuario de cualquier manera diferente ...
Por lo tanto, la asignación simple de campos como nombre de usuario, acción, número de puerto, dirección IP, etc. a los números no aporta nada.
Por lo tanto, me gustaría preguntar, ¿cómo se procesan los campos de texto / características construidas generalmente para hacer posible la detección de anomalías / valores atípicos sin supervisión?
EDITAR: estructura de datos.
Tengo alrededor de 100 columnas en la tabla de la base de datos, que contiene información de eventos de Active Directory. De estas 100 columnas, selecciono la más importante (desde mi punto de vista): AsuntoUsuario, DestinoUsuario, SourceIPaddress, SourceHostName, SourcePort, Computadora, DestinationIPaddress, DestinationHostName, DestinationPort, Acción, Estado, FilePath, EventID, WeekDay, DayTime.
Los eventos son eventos de Active Directory, donde EventID define lo que se registró (por ejemplo, creación de un ticket Kerberos, inicio de sesión de usuario, cierre de sesión de usuario, etc.).
La muestra de datos tiene el siguiente aspecto:
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - + | ID | SubjectUser | TargetUser | SourceIPaddress | SourceHostName | SourcePort | Computadora | DestinationIPaddress | DestinationHostName | DestinationPort | Acción | Estado | FilePath | EventID | WeekDay | DayTime | + ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - + | 171390673 |? |? |? |? |? | domaincontroller1.domain.com | 1.1.1.1 | domaincontroller1.domain.com |? | / Autenticación / Verificar | / Éxito |? | 4624 | 1 | 61293 | + ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - + | 173348232 |? |? |? |? |? | domaincontroller2.domain.com | 2.2.2.2 | domaincontroller2.domain.com |? | / Autenticación / Verificar | / Éxito |? | 4624 | 1 | 61293 | + ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - + | 180176916 |? |? |? |? |? | domaincontroller2.domain.com | 2.2.2.2 | domaincontroller2.domain.com |? | / Autenticación / Verificar | / Éxito |? | 4624 | 1 | 61293 | + ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - + | 144144725 |? | John.Doe | 3.3.3.3 | domaincontroller3.domain.com | 2407 | domaincontroller3.domain.com | 3.3.3.4 | domaincontroller3.domain.com |? | / Autenticación / Verificar | / Éxito |? | 4624 | 3 | 12345 | + ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
En total, tengo alrededor de 150 millones de eventos. Los diferentes eventos tienen diferentes campos completados, y no todos los eventos están relacionados con el inicio / cierre de sesión del usuario.
fuente
Respuestas:
Definitivamente no soy un experto en detección de anomalías . Sin embargo, es un área interesante y aquí están mis dos centavos. Primero, teniendo en cuenta su nota de que "la distancia de Mahalanobis solo se puede aplicar a entidades distribuidas normalmente". Me encontré con algunas investigaciones que argumentan que todavía es posible usar esa métrica en casos de datos no normales . Eche un vistazo a este documento y este informe técnico .
También espero que encuentre útiles los siguientes recursos sobre detección de anomalías no supervisadas (AD) en el contexto de seguridad de la red de TI , utilizando varios enfoques y métodos: este documento , que presenta un marco geométrico para AD sin supervisión; este documento , que utiliza un enfoque de agrupamiento basado en la densidad y en la cuadrícula ; diapositivas de esta presentación , que mencionan el uso de mapas autoorganizados para AD.
Finalmente, le sugiero que eche un vistazo a las siguientes respuestas mías, que creo que son relevantes para el tema y, por lo tanto, podrían ser útiles: responder a los enfoques de agrupación , responder a la agrupación no basada en la distancia y responder a las opciones de software para AD .
fuente
En primer lugar, creo que hay algunas cosas a las que puede que tenga que resignarse.
Una restricción difícil que veo en este problema es que probablemente debería estar preparado para tener una tasa de falsos positivos bastante alta. Hasta donde yo sé, la tasa base de registros que forman parte de una anomalía de la red es bastante baja (cita requerida). Llamémosle cuotas 1000: 1, en aras de la discusión. Entonces, incluso si observa un patrón que es 100 veces más probable que ocurra si el registro es una intrusión, entonces si es legítimo, la regla de Bayes dice que las probabilidades posteriores son 10: 1 de que el tráfico aún es legítimo.
El otro problema es que algunas intrusiones son difíciles de detectar incluso en principio . Por ejemplo, si alguien socialmente me diseñó para que les diera mi computadora, y luego iniciaran sesión en este servicio y descargaran un archivo de alto secreto en el que había estado trabajando, sería bastante difícil de encontrar. Básicamente, un atacante suficientemente determinado puede hacer que su comportamiento intrusivo sea casi arbitrariamente cercano al comportamiento normal del sistema.
Además, sus adversarios son procesos inteligentes, no estadísticos, por lo que si comienza a detectar algún patrón y lo excluye, simplemente pueden responder al no seguir ese patrón. Por eso, por ejemplo, verá muchos mensajes de spam con espacios entre todas las letras (ofreciéndole "
V I A G R A" o lo que sea). Los filtros de spam descubrieron que la cadena "viagra" era spam, por lo que los atacantes comenzaron a hacer otra cosa.Debido a esto, creo que vale la pena pensar bastante en qué tipo de intrusiones crees que vale la pena el esfuerzo para poder detectar. Ciertamente, aquí hay fruta fácil, así que no dejes que lo perfecto sea enemigo de lo bueno y trata de encontrar un algoritmo que pueda detectar todas las intrusiones.
Aparte de eso, hablemos de la fruta baja. Aquí, creo que podría ser productivo para usted cambiar su unidad de análisis de registros individuales a un grupo de registros.
Por ejemplo, usted dijo que la mitad de todos los registros tienen combinaciones únicas de campos. Pero presumiblemente, por ejemplo, la mayoría de las IP de origen aparecen en más de un registro: son los otros campos en la solicitud los que están cambiando y haciendo que la combinación sea única. Si agrupa las solicitudes por IP, puede hacer preguntas como:
Puede hacer cosas similares para otras agrupaciones, como nombre de usuario:
No conozco ningún clasificador comercial que parezca particularmente adecuado para esto, porque el comportamiento potencial de sus usuarios es muy variado, y probablemente le interesen principalmente los cambios en el comportamiento a lo largo del tiempo. Eso significa que probablemente desee construir algún tipo de modelo de lo que cada usuario / IP / lo que sea que pueda hacer en el futuro, y marcar cualquier desviación de este modelo. ¡Pero ese es un proceso bastante intenso si sus usuarios tienen patrones de comportamiento diferentes!
Debido a esta dificultad, creo que por ahora podría ser más productivo hacer el tipo de análisis en modo exploratorio que describí anteriormente. Es probable que le informe sobre qué tipos de patrones son los más interesantes, y luego puede comenzar a usar algoritmos estadísticos sofisticados para detectar esos patrones.
fuente
Creo que, en primer lugar, debe tener un conjunto de datos que registre los datos durante un período sin ataques. Este conjunto de datos debe capturar las variaciones inherentes a un sistema que se comporta normalmente. Me gustaría enfatizar el punto de que no se trata de tener un conjunto de datos anotado.
A continuación, trataría de combinar todas (o subconjuntos) de métricas en una. Esta nueva métrica debería reflejar la cantidad de "sorpresa". Por ejemplo, un valor bajo significa que el sistema funciona normalmente, un valor alto / meseta significa que hay algún cambio rápido. Aquí estoy pensando en los gráficos de estilo CUSUM o Shewhart.
¿Puede proporcionar algunos ejemplos de los datos disponibles? ¿Son principalmente cadenas, números, indicadores 1/0?
fuente
Una posibilidad es aprender una red bayesiana entre las características dadas algunos datos de fondo sin ataques. Aprender una red bayesiana es útil porque resalta la independencia condicional entre las características. Por lo tanto, no está tratando con todas y cada una de las combinaciones posibles de características. Por ejemplo, si la característica A afecta a B y C y las características B y C juntas afectan a D, entonces solo aprenderá un modelo de cómo A afecta a B, cómo afecta a C y cómo B y C afectan conjuntamente a D. Este modelo requerirá mucho menos parámetros que la distribución de probabilidad completa y es la razón principal por la que se utilizan redes bayesianas en lugar de simplemente almacenar toda la distribución de probabilidad conjunta. Para probar la anomalía dada una red bayesiana, calcule la probabilidad del punto de datos entrante utilizando el modelo de red bayesiana aprendido. Si la probabilidad es muy baja,
fuente
Pensé que la respuesta de Ben Kuhn fue pragmática y perspicaz.
Ahora mi propia experiencia incluye clasificación de texto, sistemas expertos, agrupamiento y seguridad. Teniendo en cuenta estos antecedentes, me gustaría pensar que podría tener algo que agregar a la conversación. Pero las declaraciones anteriores de Ben Kuhn destacan que los enfoques directos podrían producir muchos falsos positivos. El personal de TI, cuando se enfrentan a muchos falsos positivos, generalmente se desconectan porque simplemente no tienen tiempo para perseguir falsos positivos todo el tiempo.
¿Entonces lo que hay que hacer?
Ciertamente, los registros con ataques en ellos podrían ser útiles, pero luego tenemos un catch-22 a menos que las compañías de alguna manera compartan datos de ataque. Si bien algunas empresas emergentes de Silicon Valley podrían estar buscando compartir amenazas, ¿qué más podríamos hacer?
Un enfoque posible es crear una simulación de la red y luego encontrar una manera de generar ataques contra la simulación. Es decir, supongamos que creamos una simulación en la que los sombreros negros (también simulados) no se conocen de antemano a los sombreros blancos. Dados estos ataques, podemos intentar crear algoritmos que deberían descubrir estos ataques. Si los sombreros negros operan independientemente de los sombreros blancos, entonces tenemos una batalla real que se desarrollará. Si los atacantes entran en el sistema o no son detectados, entonces los sombreros blancos han fallado, hasta cierto punto.
Incluso se podría tener una estructura de incentivos cuando los analistas de seguridad del equipo de sombrero negro son recompensados por sus éxitos (calzones o ataques no descubiertos). Del mismo modo, el grupo que comprende los sombreros blancos es recompensado por detener calzones y / o detectar ataques.
No hay nada perfecto en este arreglo. Obviamente, los sombreros negros reales pueden exceder los talentos del equipo "amistoso" de sombreros negros. Sin embargo, como persona que tiene una buena cantidad de análisis de datos, me parece que es muy difícil cuantificar el éxito de los sombreros blancos sin una mejor comprensión de los sombreros negros. La conclusión es esta. Si no podemos saber qué están haciendo los sombreros negros reales, lo mejor es usar sombreros negros amigables.
También tengo una idea bastante inusual. Supongamos que además de los simpáticos sombreros negros y los sombreros blancos, hay un equipo de sombreros grises. ¿Qué significa ser un sombrero gris? La idea es simple. Los sombreros grises pueden mirar lo que hacen los sombreros negros y los sombreros blancos. ¿Pero por qué?
Supongamos que los sombreros negros amigos lanzan ataques usando los enfoques A, B y C, y los sombreros blancos nunca descubren ninguno de estos tres enfoques. Bueno, los sombreros grises están facultados para ver lo que están haciendo tanto los sombreros negros amigos como los sombreros blancos, y tratan de considerar qué principios podrían usarse para descubrir estos ataques no detectados. Si el sombrero gris encuentra tales principios, el equipo de sombrero gris puede compartir estos principios con el equipo de sombrero blanco sin describir los ataques exactos en detalle.
La esperanza es que estas "pistas" proporcionadas por el equipo de sombrero gris den un empujón al equipo de sombrero blanco en la dirección correcta sin revelar demasiado.
En retrospectiva, me disculpo si mi respuesta realmente no se trata de técnicas específicas. Obviamente mi respuesta no se trata de técnicas específicas. Pero en mi experiencia, muchos problemas en el aprendizaje automático, incluidos los de seguridad, a menudo fallan porque los datos son inadecuados. Este enfoque, usando sombreros blancos, sombreros grises y sombreros negros, podría ayudar a producir los datos que permitirían a una empresa de seguridad (o personal de TI) no solo cuantificar la efectividad de sus defensas, sino también proporcionar una estructura organizativa que impulse al equipo de sombrero blanco para mejorar progresivamente sus defensas y su monitoreo.
Realmente no tengo idea si el enfoque que sugiero es original. Nunca he oído hablar de sombreros grises, pero en realidad creo que el papel de los sombreros grises podría ser crítico para impulsar al equipo blanco hacia adelante, sin revelar demasiado.
Nota: mi uso del término "sombrero gris" aquí no es estándar. Ver http://www.howtogeek.com/157460/hacker-hat-colors-explained-black-hats-white-hats-and-gray-hats/ . Entonces, algún otro término, quizás "sombrero rayado" debería usarse en su lugar.
Pero la idea sigue siendo la misma: un sombrero a rayas puede ayudar a mediar entre el trabajo de los sombreros negros y los defensores (sombreros blancos), de modo que ciertas ideas y sugerencias se puedan compartir juiciosamente con los sombreros blancos.
fuente
Desde que publiqué la pregunta original, he realizado una gran investigación sobre este tema y ahora puedo proporcionar mis resultados como respuesta.
En primer lugar, en nuestro laboratorio, desarrollamos un sistema SIEM que utiliza algoritmos de detección de anomalías. La descripción del sistema y los algoritmos está disponible en mi artículo Hacia un sistema para el análisis complejo de eventos de seguridad en redes a gran escala.
Además de eso, escribí un breve resumen sobre cómo tratar esos datos en mi respuesta a una pregunta similar sobre Cross Validated
fuente