jonrau1/syntheticsunMarco de automatización de seguridad sin servidor para AWS que ingiere inteligencia de amenazas, aplica detección de anomalías basada en ML (RCF, IP Insights) y enriquece la telemetría de seguridad en Kibana para la prevención, detección y respuesta automatizada de amenazas.
SyntheticSun es un marco de automatización y monitoreo de seguridad en profundidad que utiliza inteligencia de amenazas, aprendizaje automático, servicios de seguridad administrados de AWS y tecnologías sin servidor para prevenir, detectar y responder continuamente a las amenazas.
Duermes en vidrio fragmentado
Con reflejos de ti,
¿Pero te sientes vivo?
Sí, déjame preguntarte,
¿Te sientes vivo?
- Norma Jean, 2016
SyntheticSun se construye en torno al uso de la Plataforma de Compartición de Información de Malware (MISP) y LIMO de Anomali, que son plataformas de inteligencia de amenazas (TIP) impulsadas por la comunidad que proporcionan varios tipos de indicadores de compromiso (IoC). La inteligencia de amenazas normalizada y deduplicada se consulta en tiempo casi real para identificar rápidamente amenazas conocidas en varios tipos de tráfico de red. Para añadir dinamismo a la identificación de amenazas potenciales, se implementan modelos de IP Insights para encontrar anomalías (y amenazas potenciales dentro de ellas) entre el emparejamiento de direcciones IP y entidades (como ID de principal de IAM, user-agents, etc.), también se utilizan detectores RCF nativos en Elasticsearch para encontrar anomalías en la telemetría de seguridad en tiempo casi real a medida que se transmite a Kibana. Para democratizar el uso y ajuste de modelos de ML dentro de los equipos de seguridad, se proporcionan utilidades para entrenar modelos de IP Insights como complemento a la solución principal.
Para realizar tanto la orquestación y automatización como la extracción, transformación y carga (ETL) de la telemetría de seguridad en Kibana, se utilizan diversas tecnologías sin servidor de AWS como AWS Lambda, Amazon DynamoDB y AWS CodeBuild. Tecnologías sin servidor como estas se utilizan por su escalabilidad, facilidad de uso y costos relativamente bajos en comparación con soluciones pesadas basadas en MapReduce o Glue ETL. La mayor parte de la solución se implementa a través de CloudFormation con scripts auxiliares en Python y shell proporcionados a lo largo de las diversas Etapas para promover la adopción y la posible implementación en tuberías de integración continua.
Para que las "entrañas" de la solución sean lo más ligeras posible, módulos básicos de Python como boto3, requests, json, ipaddress, socket y re realizan la mayor parte de la extracción, transformación y carga (ETL) en los servicios posteriores. Debido a que toda la información de geolocalización es proporcionada por ip-api.com, no requiere una cuenta ni niveles pagados y tiene una excelente API que incluye información de limitación en sus encabezados de respuesta. La mayoría de las dependencias de Elasticsearch y Kibana también se proporcionan en código (índices, mapeos, visualizaciones, etc.) para evitar una configuración manual pesada.
SyntheticSun está distribuido en tres Etapas debido al tamaño de la solución y las dependencias requeridas. Toda la arquitectura e instrucciones de instalación (y preguntas frecuentes cuando corresponda) viven dentro de su propia Etapa. También se proporcionan módulos complementarios (llamados Apéndice) para extender la funcionalidad, que tienen su propia arquitectura e instrucciones de instalación localizadas.
SyntheticSun, por ser algo que encontraste en GitHub, es una prueba de concepto y por lo tanto no me esforcé al máximo en la primera versión para endurecer absolutamente todo. Suponiendo que estás leyendo esto en un momento en que no he realizado los cambios necesarios, considera lo siguiente antes de implementar esta solución en un entorno de producción (o cualquier entorno con necesidades de seguridad elevadas). Pondré estos elementos en una hoja de ruta y los actualizaré según corresponda.
SyntheticSun es una forma fácil de comenzar a usar inteligencia de amenazas cibernéticas y aprendizaje automático para tus casos de uso de seguridad perimetral en la Nube de AWS sin tener que invertir en una o más herramientas comerciales, o contratar a un científico de datos para tu equipo de seguridad (aunque idealmente deberías hacer esto último). Esta solución, después de la configuración inicial, está completamente automatizada, lo que te permite identificar y responder a amenazas a velocidad de máquina. Finalmente, esta solución proporciona visualizaciones básicas para que tu equipo de respuesta a incidentes las use para la respuesta a amenazas, como conexiones entrantes o salientes permitidas o consultas DNS a direcciones IP o dominios considerados maliciosos. El núcleo de la solución se basa en tuberías de automatización e ingeniería de datos muy ligeras que, en teoría, pueden reutilizarse para otros fines donde se necesiten normalización y enriquecimiento en múltiples etapas o trabajos por lotes programados y de ritmo rápido.
En primer lugar, si estás utilizando Amazon GuardDuty y/o AWS WAF, puede tener sentido evaluar esta solución, pero también es un requisito. Las personas obvias que pueden aprovecharla son los equipos de producto responsables de asegurar su pila completa y carecen del capital o la experiencia para modelar, entrenar e implementar algoritmos de aprendizaje automático u operacionalizar fuentes de inteligencia de amenazas cibernéticas de manera significativa. Esas personas mencionadas probablemente son ingenieros de seguridad, analistas e ingenieros de SecOps / SOC, o un ingeniero DevSecOps; sin embargo, esta lista no es exhaustiva, y no necesitan estar alineados con productos/aplicaciones, ya que los equipos centrales también pueden usarla. Otro uso es para esas mismas personas (SecOps, ingeniería de seguridad) que trabajan para un equipo centralizado y quieren crear una lista de bloqueo dinámica para firewalls y sistemas de prevención de intrusiones; los proyectos de CodeBuild pueden reutilizarse para colocar archivos CSV o planos en casi cualquier ubicación (por ejemplo, firewalls de Palo Alto, filtros de URL de proxy directo Squid, etc.).
SyntheticSun actualmente carece de cobertura completa en todas las principales fuentes de registros, es decir, registros de acceso de S3 y registros de acceso de CloudFront, que son integrales para la forma en que muchas personas entregan servicios (especialmente para SPAs en buckets de S3). La detección de anomalías no se extiende más allá de WAF, registros de acceso de API Gateway o CloudTrail debido a mi obsesión con IP Insights y la falta total de formación en ciencia de datos (en serio, ni siquiera sé usar pandas o numpy). No hay un análisis en profundidad de los IoCs de inteligencia de amenazas brutos aparte de intentar coincidirlos en los registros.
La forma más fácil de implementar esta solución para una organización es implementarla en una cuenta centralizada de servicios de seguridad. Para la telemetría de nivel inferior como VPC Flow Logs y registros de WAF, deberías considerar proporcionar scripts auxiliares o plantillas de CloudFormation a través de AWS Service Catalog para promover la habilitación en entornos inferiores. Deberás evaluar el consumo de shards y la rotación de índices de Elasticsearch Service, así como los permisos, si vas a tener flujos de entrega de Kinesis Data Firehose entre cuentas publicando en una ubicación centralizada. Construí esta solución en mi cuenta de sandbox personal, por lo que no incorporé ninguna de las consideraciones anteriores en la solución; estaré encantado de trabajar en un PR con esto en mente y puedo hacerlo yo mismo en el futuro.
A partir del 31 DE JULIO DE 2020, las Políticas de AWS Firewall Manager admiten la agregación multi-cuenta de registro de WAF, lo que te acerca un paso más a hacer esto mucho menos doloroso...
ADVERTENCIAS: No soy un científico de datos y esta va a ser una respuesta larga. Resumen: Es un buscador de anomalías y ¿creo?
Dado que no estoy ni remotamente cerca de ser un científico de datos ni tengo formación, estás mejor servido leyendo la documentación sobre esto. Dicho esto, aquí está mi intento profano: IP Insights es un algoritmo de aprendizaje automático no supervisado que aprende la relación entre una dirección IPv4 y una entidad (por ejemplo, número de cuenta, nombre de usuario, user-agent). IP Insights luego intenta determinar cuán probable es que la entidad use esa dirección IPv4. Detrás de las cortinas de IP Insights hay una red neuronal que aprende la representación vectorial latente de estas entidades y direcciones IPv4. La distancia entre estas representaciones vectorizadas es emblemática de cuán anómalo (o no) es que una entidad esté asociada con (por ejemplo, enviar una solicitud desde) una dirección IPv4.
Las redes neuronales son casi exactamente como suenan; forman un sistema de aprendizaje automático diseñado para comportarse de manera similar al cerebro humano, completo con neuronas y sinapsis computarizadas. En el aprendizaje automático no supervisado, el algoritmo puede discernir cómo se ve "bueno" (es decir, Verdadero Negativo) versus "malo" (es decir, Verdadero Positivo) al observar la asociación entre todas las direcciones IPv4 y sus entidades emparejadas. Esta asociación se evalúa para identificar qué vectores son similares a otros por su "distancia". En el caso de IP Insights, se proporciona un codificador preconstruido que busca direcciones IPv4 y luego agrupa todas las entidades en clusters. Luego itera sobre ellas utilizando vectorización. La vectorización es una forma de realizar cálculos como una matriz en lugar de iterar sobre ellos (piensa en un bucle "For" para una lista que contiene decenas de millones de valores).
Cuando entrenas un modelo de IP Insights, en realidad se crea falsos positivos al emparejar direcciones IPv4 con entidades que tienen una distancia lejana (es decir, altamente anómala) y que es menos probable que ocurran en la realidad; el modelo ahora puede discriminar entre Verdaderos Positivos, Falsos Positivos y Verdaderos Negativos. Esto se hace para prevenir otro término loco llamado "entropía cruzada" (también conocido como "pérdida logarítmica" como si eso lo hiciera mejor), e introduce otro término, clasificación binaria. IP Insights esencialmente pregunta: "¿Cuál es la probabilidad de que esta dirección IP emparejada con esta entidad sea anómala?" Esto es lo que lo hace binario, creo, así que "sí, es malo" o "no, no lo es". La probabilidad se representa como un valor entre 0 y 1; el objetivo de todos los modelos de aprendizaje automático es hacer que esto sea lo más cercano a 0 posible, por lo que predecir un valor de 0.01 para algo que realmente es 1 (Verdadero Positivo conocido) resultaría en una pérdida logarítmica muy alta. Entonces, con todo eso dicho, al crear datos deliberadamente basura, IP Insights ayuda a reducir esa pérdida logarítmica (es decir, malas predicciones) durante el entrenamiento.
Eso nos lleva a la salida del endpoint. Cuando lo consultas (ya sea por lotes o en tiempo casi real usando la API InvokeEndpoint), la respuesta es un flotante sin límite que puede ser negativo o positivo. Cuanto más por encima de 0 esté, más probable es que sea anómalo, que es donde comienza tu trabajo. Para esta solución elegí cualquier valor por encima de 0.03, que es en gran medida notional; para acercarte más a la verdad, debes proporcionar Verdaderos Positivos al endpoint y ver cuál es tu respuesta. Basándote en esos hallazgos, podrías configurar un enfoque escalonado donde tu aplicación pueda emitir un desafío de segundo factor, generar una alerta o bloquearlo directamente dependiendo de la puntuación. La respuesta a la segunda parte de la pregunta es "Sí, creo que sí"; entrenar el modelo con user-agents emparejados con una IP es bastante arriesgado. Ahora para otras entidades menos volátiles (número de cuenta, nombre de usuario, usuario de IAM) parece el uso previsto.
En la solución proporciono algunas fuentes de ejemplo que deberías usar; algunas son bastante obvias como la fuente de dominio de ciberdelincuencia, Emerging Threats y CI-badguys. En mi trabajo real trabajo con uno de los especialistas en inteligencia de amenazas cibernéticas más talentosos del mundo (¡no es broma, es increíble!), quien también influyó en las elecciones. Al igual que los modelos de aprendizaje automático y cualquier otra cosa que construyas, debes adaptar tus fuentes de inteligencia de amenazas y agregación para que coincidan con tu entorno de amenazas actual. Los duplicados se identifican en MISP y solo se especifica una clave hash en las tablas de DynamoDB para imponer la unicidad, por lo que incluso si hay 5 fuentes informando sobre la misma dirección IPv4, solo una llegará a la tabla.
También puedes traer tus propias plataformas y fuentes de inteligencia de amenazas comerciales como InfoBlox o Recorded Future a esta solución apuntándolas a las tablas de DynamoDB con una sintaxis similar.
La mayoría de la entrega de registros de AWS es "mejor esfuerzo", por lo que no hay un SLA oficial publicado; sin embargo, supongo que está alrededor del 99.5 - 99.9%, donde cualquier cosa en ese último 0.5 - 0.1% no se entregará. El tráfico de "producción" también es de primera clase en AWS; si hay restricciones de ancho de banda de red, por defecto priorizará la entrega de conectividad a los clientes en lugar de enviar registros. El evento más probable es que el archivo de registro bruto era demasiado grande para que Lambda lo procesara por completo a tiempo; ves esto mucho cuando estás siendo atacado con un DOS o un rastreador desde la misma IP de cliente. WAF y ALB agrupan archivos de registro por el llamante (por lo que puedo decir), por lo que si absorbes cientos de solicitudes, el archivo de registro puede ser muy grande.
Sí, sin embargo, deberás realizar una de las siguientes acciones:
Hay costos adicionales por esto. Lambda en una VPC, especialmente para docenas de invocaciones concurrentes, probablemente conducirá a más problemas debido a que las ENIs se quedan y consumen tu espacio RFC1918. A menos que sea absolutamente necesario aislar todo el tráfico dentro de tu VPC para cumplir con los requisitos de cumplimiento, no recomendaría ese camino.
Sí, esto es posible modificando la solución para publicar los registros formateados finales en Kinesis Data Firehose y apuntarlos a Splunk.
Espero tener soporte para registros de DNS de Route 53, registros de acceso de S3, registros de acceso de CloudFront y registros de acceso de API Gateway y quizás algunos otros registros basados en host en el futuro.
Honestamente, habría preferido usar el Agente de Kinesis Data, pero encontré muchos problemas con él: No está incluido por defecto en Amazon Linux 2 y ahora que las AMI de Ubuntu 18.04 LTS vienen con Java 11 preinstalado, encontré problemas de compatibilidad hacia atrás con el Agente, ya que falla la compilación a menos que tengas OpenJDK 8 o 9. Fue mucho más fácil instalar el Agente de CloudWatch, ya que se actualiza con frecuencia con nuevas características y hay soporte de Documentos de Systems Manager para la configuración; incluso tiene un asistente para la instalación. Si AWS alguna vez toma el soporte del Agente de Kinesis Data tan en serio como el Agente de CloudWatch, podría cambiarme a él, ya que preferiría publicar directamente en Kinesis Data Firehose para ciertos registros basados en host (Suricata, Squid, Nginx, Apache) en lugar de usar CloudWatch Logs como intermediario.
Estoy feliz de aceptar PRs para elementos etiquetados como "Se necesita ayuda" en Issues o en el Tablero del Proyecto. También revisaré cualquier otro PR propuesto si cumple con el espíritu del proyecto.
Agradecimientos especiales a David Dorsey y Ryan Nolette quienes proporcionaron valiosos comentarios, pruebas y contribuciones para ayudar a afinar SyntheticSun.
Esta librería está licenciada bajo la Licencia Pública General de GNU v3.0 (GPL-3.0). Consulte el archivo LICENSE.
