Antes de elegir el tema del diploma, noté que una situación se generaliza cuando, durante los ataques informáticos, se considera a una persona solo desde un lado: el que está siendo atacado como una vulnerabilidad.
Durante el ataque, todos están interesados solo en las herramientas y acciones de los delincuentes, y solo después de que sucedió todo: quién estuvo detrás del ataque y qué objetivos querían alcanzar.
Pasaron los años (casi seis años ya), pero este tema todavía no me deja solo.
Al escribir un diploma, quedó claro que sobreestimé enormemente mi fortaleza y que no podía crear un proyecto de esta escala para una persona en seis meses. Al menos no tuve éxito.
La falta de experiencia en sistemas reales también tuvo un impacto, y algunas decisiones de diseño se repensaron al escribir un diploma, pero llegué a algunos puntos solo después de años.
Este artículo trata sobre un diseño preliminar y las deficiencias y preguntas que surgieron durante el proceso de diseño.
Me alegraría si alguien estuviera interesado en este lado de los ataques informáticos y pudiera usar mis modestos logros.
Y sí, el "hacker" en el título del artículo se usa solo en un significado estrictamente definido: un infractor de seguridad de la información.
Tema del diploma: diseño de un sistema para determinar dinámicamente el objetivo potencial de un infractor de la seguridad de la red informática.
La idea general: cuando de alguna manera arreglamos un ataque (por ejemplo, usando
SIEM ), luego, en base a estos datos, asumimos lo que el intruso quiere hacer al final.
Cuando escribí el diploma, quedó claro que algunos de los puntos del diploma pueden y deben mejorarse.
Ya hablé sobre parte de mi diploma, o más bien sobre uno de los problemas que encontré en el proceso de escritura,
aquí . Mi artículo no es el mejor, pero aprendí algo útil para mí en los comentarios, gracias a todos los comentaristas.
Sobre diseños
Lo primero que me gustaría llamar la atención, en primer lugar, de los graduados es el diseño.
Todo y constantemente. Quedará claro dónde y qué sale mal. Y si no está claro, aumenta tus habilidades. Por desgracia, no soy un programador o desarrollador, y con la administración no lo hago realmente. Realmente me gusta inventar algo nuevo o buscar cuellos de botella en las ideas. Por lo tanto, la creación de prototipos y la realización del experimento recayeron casi por completo en mi supervisor graduado, por lo que muchas gracias a ella.
No tenía mi propia infraestructura.
Puedes unirte con alguien y romper el hierro. Tomemos, por ejemplo, varias computadoras portátiles, un enrutador y en este sistema en miniatura.
También puede comprar en los sitios de anuncios clasificados gratuitos viejos, no muy animados, pero de hierro vivo. A veces se venden por "1,000 rublos, pero recogen".
Llegar al punto
¿Dónde comenzar a predecir?
Para entender lo que está sucediendo en el presente.
El SIEM OSSIM fue responsable de esto. Al mismo tiempo, el desarrollador declaró que podía determinar ataques y crear cadenas de ataque CVE. Para esto me enganché: no necesito determinar los ataques por mí mismo y puedo concentrarme directamente en determinar el objetivo potencial. Cómo SIEM OSSIM define ataques y asigna CVE no fue muy interesante para mí, para ser honesto. No hace mucho tiempo, intenté resolverlo, pero no pude encontrar los detalles.
Además,
CAPEC podría usarse para la
predicción . Sin embargo, estaba mucho más interesado en usar CVE / CVSS y CAPEC. No presté una atención decente.
Pero antes de eso, nos encargaremos de todo lo que amamos: la clasificación de los infractores.
Clasificación de los infractores.
Ya he planteado este tema, pero analicémoslo de nuevo, solo rápidamente.
SIEM recoge un ataque en una cadena CVE. Desde CVE / CVSS tomamos el vector AccessComplexity. Se utilizó la segunda versión de CVSS, por lo que hay tres gradaciones, y no dos, como lo es ahora.
De alguna manera no es impresionante, ¿verdad? Será más interesante aún más. Además, este no fue el caso en el último artículo.
La seguridad de la información es el proceso de garantizar la disponibilidad, integridad y confidencialidad de la información.
Esta es una de las definiciones generalmente aceptadas.
Pero, ¿qué pasa si clasificamos a los infractores por violación de estas propiedades de información?
Entonces la siguiente clasificación ha resultado:
“Scout”: su objetivo principal es divulgar información sobre el sistema u obtener información (datos, archivos, etc.) del mismo.
"Destructor" (Destructor): su objetivo principal es interrumpir el sistema o sus componentes, hasta el fallo.
"Invader": su objetivo principal es obtener control sobre el sistema o sus componentes.
Tal distribución de "roles" me pareció hace cinco años como una buena idea. Sin embargo, mucho me pareció una buena idea entonces.
Para clasificar a los infractores por estas clases, tomamos de CVE / CVSS ConfImpact ("Impacto en la confidencialidad"), IntegImpact ("Impacto en la accesibilidad"), AvailImpact ("Impacto en la integridad").
En un vector, una influencia puede tomar los siguientes valores: sin influencia en un recurso (
N ), influencia parcial en un recurso (
P ), control total sobre un recurso (
C ).
Bueno, para concluir, señalamos que las clases tienen diferentes efectos en el sistema: menos que nada, "Scout" y sobre todo "Invader".
Por lo tanto, habiendo obtenido una cadena de ataques de SIEM, podemos clasificar al intruso. Y ya sobre esto podemos sacar algunas conclusiones sobre los objetivos del infractor.
Al pasar una cadena de ataques, un intruso solo puede aumentar sus habilidades y clase, pero no reducirlas. Bajo → Medio → Alto y Scout → Destructor → Invader.
La clasificación se usa para predecir la intención del intruso indirectamente.
Pero clasificando a los infractores uno puede asumir por lo que se esfuerzan.
Quizás podamos decir que la clasificación es el lugar que mejor funciona en el diploma.
Todos esos matices que me confunden generalmente se describen en un artículo anterior.
Arquitectura
Primero veamos la arquitectura de la solución.
Los componentes principales del subsistema del sistema para determinar dinámicamente el objetivo potencial de un intruso de seguridad son tres módulos que llevan el nombre de las tres brujas escandinavas míticas norn que determinan el destino de una persona: Urd, Verdandi y Skuld.
Hablando de las "hechiceras escandinavas" en defensa del diploma, estaba seguro de que esta es una gran idea y que de alguna manera ayudará a "calmar la situación". No Parece que el efecto es lo contrario. Pero después de todo lo sentí expresado. Quizás este enfoque sea adecuado si usted es un orador en algún lugar los días laborables, pero no ante la comisión estatal.
Sin embargo, dar esos nombres a los subsistemas me ayudó a entender cómo debería funcionar el sistema.
El sistema se divide funcionalmente en tres subsistemas principales:
- Base de conocimiento (Urd - Pasado);
- Sistema de recopilación de información (Verdandi - Presente);
- Sistema de pronóstico de objetivos (Skuld - Futuro).
El lugar central se otorga a DBMS, una base de datos del servidor incluida en la base de conocimiento.
Se suponía que habría una especie de base de datos global en la que los usuarios grabarían y recibirían gráficos de ataque. Deberían verse así.
Entonces, ¿cómo almacenar gráficos en una base de datos y trabajar con ellos como gráficos? Es simple: hay
bases de datos de gráficos .
Pero fue en ese momento cuando me di cuenta de que no podía hacerlo por mi cuenta y el diploma se había movido específicamente hacia el concepto, en lugar de un sistema realmente desarrollado y de trabajo.
Necesitaba encontrar en la base de datos SIEM donde se almacenan los ataques, y luego escribir un analizador que transfiera esta información a la base de datos gráfica.
Cómo se llena la base: SIEM detecta un ataque, me da CVE, agrego un nuevo vértice a la base o, si ya existe dicho vértice, aumento el número de transiciones entre los vértices en una unidad. Si el ataque continúa, agrego un vértice / transición.
Este enfoque tiene ventajas, tales como:
- autocompletado, es decir no se requieren pasos adicionales para crear nuevos gráficos de ataque, ya que los atacantes lo hacen;
- baja redundancia, es decir solo los gráficos de ataque que los atacantes realmente usan están en el gráfico.
El principal inconveniente del enfoque es que si un atacante usa un ataque que no se usó anteriormente, entonces es imposible predecir sus acciones.
Este método puede mejorarse agregando gráficos de ataque modelados de otras maneras a la base de datos, estableciendo las transiciones en "0".
Además, este método que utiliza una base de datos gráfica tiene dos dificultades puramente prácticas:
- Escribe en la base de datos.
- Leer de la base de datos.
El problema con la grabación es la detección de ataques. ¿En qué punto necesitas escribir un ataque a la base?
¿Cuándo se completa el ataque? El ataque puede ser largo. ¿En qué momento te das cuenta de que está completo? ¿De repente, el intruso no tiene las habilidades necesarias y dejó de desarrollar un ataque? Y si el ataque se completa, entonces la infraestructura para enviar datos sobre el ataque puede que ya no lo sea.
En el proceso? ¿Escribir cada transición en CVE? Bueno, no es una mala elección, pero me parece que aquí también habrá dificultades.
El problema con la lectura son los volúmenes estimados de árboles que deben tomarse del servidor. En términos de recursos y tiempo de entrega, esta operación parece ser un desastre.
Puede intentar no hacer una selección para cada detección de transición mediante el gráfico de ataque (más sobre eso más adelante), sino sincronizar toda la base de datos. Pero ni siquiera puedo imaginar aproximadamente cuánto ocupará la base en ese momento cuando comience a escribirse con datos reales.
Además de la base de datos del servidor, utilicé una local, que recopilará estadísticas sobre los ataques en un sistema específico.
También puede decir que los ataques sin conexión no se pueden agregar a la base de datos. El phishing, y de hecho toda la ingeniería social, nos pasará de largo. Solo podremos determinar qué tan lejos se ha movido el asesino a lo largo de la cadena de asesinatos cuando ya está tratando de matarnos.
Magia
Ahora queda pasar a lo más importante e interesante. A la previsión.
Algoritmo de pronóstico histórico
Ahora me parece que el "algoritmo estadístico" sería un nombre más adecuado. Pero luego consideré que es mejor no usar la palabra "estadística" en un diploma.
El algoritmo que se inventó es probablemente el más valioso en mi diploma (nuevamente, gracias por escribir el pseudocódigo, gracias a mi supervisor de diploma).
1. Obtenga CVE_ID, HOST_ID de un evento de seguridad
2. Dgraph = DirectedGraph (CVE_ID)
if DirectedGraph == 0 return
3. Set_Edges: = DirectedGraph.getOutEdges (CVE_ID, HOST_ID, DirectedGraph.getRoot ())
4. Set_Edges: = MAX_EXPLOIT_FREQUENCY (SET_EDGES)
If (SET_EDGES) == retorno nulo
if (SET_EDGES.SIZE ()> 1)
SET_EDGES: = MIN_ACCESS.COMPLEXITY (SET_EDGES)
if (SET_EDGES.SIZE ()> 1)
SET_EDGES: = MIN_IMPACT_GOAL (SET_EDGES)
para cada EDGES ∈ SET_EDGES
edge.Exploit_Probability == ((edge.AttackFrequency) / (1 + ∑edge.AttackFrequency))
5. Vaya al paso 3.
Con los años, no es fácil para mí leer este algoritmo yo mismo, así que vamos a simplificarnos un poco.
Obtenemos el nombre de host, CVE-id del evento de seguridad que nos da SIEM, y de la base de datos seleccionamos el subárbol que comienza con la vulnerabilidad cuyo CVE-id recibimos.
Entre las vulnerabilidades más cercanas, seleccionamos una con la mayor frecuencia de uso.
Si hay varias vulnerabilidades con la misma frecuencia, entonces tomamos la que tiene menos complejidad de acceso.
Si hay varias vulnerabilidades con la misma complejidad de acceso, entonces se toma una vulnerabilidad con menos impacto ImpactGoal (de la clasificación).
Si en este caso hay varias vulnerabilidades, estas vulnerabilidades se consideran igualmente probables y se utilizan varias formas para determinar el objetivo potencial.
Para cada vulnerabilidad, se calcula la probabilidad de explotar la vulnerabilidad: la frecuencia de usar la ruta a la vulnerabilidad que consideramos probable se divide por la suma de las frecuencias de usar todas las caras salientes de este nodo.
Después de completar estos pasos, nuevamente observamos las vulnerabilidades que nos rodean, es decir, Rodeamos el árbol hasta el final.
Visualización del algoritmo de pronóstico histórico.
Tenemos una cierta base de ataques ya formada.
Recibimos el ataque y el primer CVE de SIEM.
El rojo indica vulnerabilidades obtenidas de SIEM. Gris: vulnerabilidades descartadas durante el algoritmo, ya que ya no hay una forma de solucionarlas. Negro: vulnerabilidades y frecuencia de uso de rutas, que todavía se consideran posibles rutas en el árbol de ataque. Naranja: vulnerabilidades y frecuencia de uso de rutas, identificadas por el algoritmo como las más probables.
En este caso, obtenemos el siguiente CVE potencial por el número de transiciones.
Obtenga el próximo CVE de SIEM.
No lo adivines. Sí, y en la siguiente etapa solo hay dos caminos y tienen el mismo número de transiciones. Nos fijamos en la complejidad de la operación.
De nuevo no lo adiviné. Las transiciones son las mismas otra vez. Sí, y la complejidad de la operación coincidió. Nos fijamos en los vectores de influencia.
Problemas del algoritmo de pronóstico histórico
Este es un enfoque frontal. No muy elegante Pero sin experiencia real investigando ataques informáticos, este es el máximo que podría exprimir.
También se debe mencionar que, en realidad, solo se usará la condición en el número de transiciones, porque la probabilidad de que el número de transiciones coincida es muy pequeña.
Y también las dificultades comienzan con el hecho de que, por ejemplo, hay un ataque del Destructor y un ataque del Invader. Se cruzan en una CVE. Si con mayor frecuencia siguen el camino del Destructor, entonces el ataque del Invader después de cambiar a este CVE no se predecirá correctamente.
Hay un matiz más que en la descripción del algoritmo se dijo que se calcula la probabilidad del objetivo final. Pero la fórmula que propuse se rompió tan mal en tales intersecciones. El cálculo de la probabilidad permanece, pero se ha vuelto más fácil, pero es poco probable que funcione correctamente.
Y lo más importante, eso ... yo, por supuesto, no soy especialista en la investigación de ataques informáticos (como he dicho más de una vez), pero algo me dice que en realidad mi base de datos se vería así.
Es decir Un poco de caos. Y esta es una opción aún más o menos buena, según me parece.
Dicha base de datos funcionará más o menos bien dentro del mismo host (e incluso CVE en el software de la aplicación puede no calcularse correctamente). Pero, ¿cómo predecir correctamente el movimiento del intruso entre las estaciones? Es necesario filtrar CVE de la base de datos en función de una auditoría de seguridad.
Algoritmo analítico
El punto era construir una base de datos de ataques CVE usando CAPEC / CWE. Solo en las transiciones no habrá información.
Obtenemos el CVE de SIEM, lo usamos para clasificar al intruso y luego seleccionamos los CVE en la base de datos que son más consistentes con la clase y las habilidades del intruso.
Desafortunadamente, esta es una de las partes menos desarrolladas en mi diploma.
Resumen de diseño
Es difícil evaluar qué recursos se necesitan para mantener una base de datos. Al menos es difícil para mí.
Existen ciertas dificultades tanto para escribir nuevos datos en la base de datos como para descargar datos de la misma.
El sistema no se implementó de ninguna manera, excepto en papel, pero el experimento tuvo que hacerse "a mano". Ni siquiera puedo imaginar cuánto tiempo me llevaría implementar algún tipo de demostración. Probablemente, si hubiera comenzado la implementación mientras escribía un diploma, entonces lo habría terminado.
La clasificación de los infractores sirve como una herramienta adicional para determinar los objetivos.
El sistema en sí puede actuar como una fuente de datos para algunos
DSS . Por ejemplo, si hubo intentos de ataque del Invader, y luego cesó abruptamente, entonces DSS podría recomendar una auditoría porque el Invader podría lograr su objetivo.
Además, si aprende a determinar quién realiza el ataque, puede intentar determinar los objetivos de un delincuente en particular. También puede intentar hacer lo contrario: decir quién está llevando a cabo el ataque al ataque.
El sistema debe integrarse no solo con SIEM, sino también con los sistemas de análisis de seguridad.
El "algoritmo histórico" es una herramienta de trabajo con la que puede definir objetivos, pero hay muchas advertencias. Esta no es la solución más elegante, pero hasta ahora. Necesitamos seguir pensando, para refinar. O rechazar y tomar un algoritmo completamente diferente.
Usar CAPEC tiene sus ventajas y desventajas, pero requiere trabajo adicional.
Probablemente lo más ofensivo para este sistema desde un punto de vista conceptual puede ser si el intruso ... no tiene ningún propósito. Obtiene acceso al sistema porque simplemente podría hacerlo. Quizás no planeó este truco. Y luego simplemente no sabe qué hacer a continuación. O comienza a comportarse como un zorro en un gallinero.
El sistema está muy relacionado con la capacidad de SIEM para detectar ataques, así como para determinar qué ataque CVE se está utilizando. Frente a un sistema de 0 días se desvanece en los tres métodos de pronóstico. Y tienes que vivir con eso, pero nunca lo olvides.
El sistema le permite recibir información adicional sobre el intruso, ya que la mayoría de los sistemas proporcionan solo información técnica sobre el ataque, mientras que la información sobre los motivadores, los objetivos y el nivel de habilidad del intruso también es importante y es su sistema el que trato de obtener.
Gracias por su atencion