Alertas distribuidas con el Elastic Stack

blog-security-radar-720x420.png

Los entornos informáticos modernos y las fuerzas de trabajo distribuidas han generado nuevos desafíos para los enfoques tradicionales de seguridad de la información. Muchas estrategias tradicionales de detección y respuesta a amenazas se basan en entornos homogéneos, líneas de base del sistema e implementaciones de control consistentes. Estas estrategias se han construido sobre suposiciones ambientales tradicionales que pueden no ser ciertas en su entorno con la evolución de la computación en el cloud, el trabajo remoto y la cultura moderna.

Elastic se distribuye por diseño, desde nuestra tecnología hasta nuestra fuerza laboral. Los Elasticians están facultados para trabajar donde quieran, cuando quieran y como quieran. Esto incluye qué tecnologías utilizan, qué configuraciones necesitan y qué software prefieren. Habilitar esta cultura moderna de productividad genera un nuevo desafío para la seguridad de la información. 

¿Cómo podemos proteger un entorno que permita actividades de alto riesgo, como la creación de nuevos usuarios, la configuración de servidores proxy de red y la instalación de nuevo software sin la participación de TI? ¿Cómo podemos aplicar detecciones a un entorno sin líneas base de actividades? ¿Cómo escalamos nuestra práctica de detección y respuesta en una empresa moderna que opera en muchas ubicaciones o incluso países diferentes? ¿Cómo hacemos esto sin un centro de operaciones de seguridad (SOC) tradicional?

Es simple. Enviamos la alerta a quienes están en la mejor posición para confirmar o rechazar la actividad a través de nuestro marco de trabajo de alertas distribuidas. 

Las alertas distribuidas permiten que nuestro equipo de Detección y respuesta ante amenazas identifique automáticamente actividades de riesgo, envíe un mensaje a nuestros empleados en lenguaje natural y solicite una confirmación de la actividad. Si el Elastician no reconoce la actividad, la alerta se puede derivar de inmediato a nuestro equipo de Respuesta a incidentes para su corrección. A continuación se muestra un ejemplo de una alerta distribuida enviada a nuestros empleados para un nuevo dispositivo MFA registrado en su cuenta:

Si reconocen la actividad, hacen clic en el botónYES: This Was Me . Se les muestra un mensaje para proporcionar cualquier información adicional que sería útil para explicar la actividad o las oportunidades de ajuste.

En el backend, se crea un nuevo caso de seguridad, se asocian alertas con el caso, se registran los detalles y el caso se cierra como "Sin impacto", con un resumen para el reporte diario.
Si no reconocen la actividad, hacen clic en el botónNO: Escalate to InfoSec. Esto generará un nuevo caso de seguridad, creará un nuevo canal de Slack, invitará al equipo de respuesta a incidentes y a quien mandó el reporte al canal y proporcionará cualquier información adicional al equipo.

Al enviar estas actividades directamente a quienes pueden confirmar mejor esta actividad, podemos mantener nuestras proporciones de verdaderos positivos/falsos positivos de las detecciones y reducir nuestro tiempo para remediar todas estas detecciones "difíciles" para actividades que representan un alto riesgo si son actores de amenazas, pero que ocurren regularmente en nuestro entorno. 

¿Qué hace a un buen candidato de alerta distribuida?

Los buenos candidatos para alertas distribuidas son actividades que presentan un alto riesgo para tu postura de seguridad pero que no tienen ningún contexto o indicación de actividad maliciosa. Por ejemplo, la activación de una única alerta para "Nuevo dispositivo MFA registrado" para un usuario no proporciona ningún contexto sobre la intención de la actividad. Los usuarios agregan rutinariamente nuevos dispositivos MFA a sus cuentas. Sin embargo, si se tratara del dispositivo de un actor de amenazas, la cuenta se consideraría comprometida ya que todas las autenticaciones posteriores se autenticarían con éxito con un dispositivo multifactor válido. Esta situación presenta una situación difícil para los equipos de Detección y respuesta a amenazas. ¿Cómo podemos validar estas actividades sin contexto y sin investigar cada detalle de estos eventos? Distribuimos estas alertas.

Para algunos antecedentes adicionales, esta es nuestra estrategia de detección de amenazas. Tenemos algunas ideas diferentes que brindan una cobertura completa de las actividades del sistema.

Dividimos nuestros eventos en tres categorías diferentes:

  • Logs: Todos los eventos que ocurren en un sistema. Los logs a menudo se incluyen en las investigaciones para comprender lo que ocurrió. Un evento de log no es indicativo de ninguna actividad sospechosa. Es simplemente un registro de lo que sucedió.
  • Señales: Utilizamos la aplicación Elastic Security para generar señales. Las reglas de detección están escritas para identificar la actividad que puede indicar actividad sospechosa; sin embargo, la actividad también puede ser benigna. El contexto de estos eventos es difícil de determinar a partir de un solo evento, por lo que no es una alerta inmediata. Las búsquedas de amenazas están diseñadas en torno a señales para identificar actividades relacionadas que podrían utilizarse para identificar contenido malicioso o benigno, para ajustar la regla de detección de una señal a una alerta.
  • Alertas: Promovemos las señales a la categoría de alertas cuando tenemos mucha confianza en que la señal indica actividad maliciosa (es decir, probabilidad de actividad maliciosa) o cuando una actividad tiene un impacto tan alto que todos los eventos deben validarse para reducir la probabilidad del impacto (es decir, impacto si es malicioso).

Las alertas con un alto impacto pero baja probabilidad de intención maliciosa crean una gran oportunidad para la distribución de alertas. Esto nos permite validar actividades administrativas, actividad nueva, actividad de usuario anómala y todas las demás actividades a escala empresarial sin necesidad de un SOC tradicional.

¿Cómo distribuimos las alertas?

Como Cliente Cero de productos Elastic, nuestro Elastic Stack está en el centro de nuestra arquitectura SIEM y SOAR. Para obtener detalles sobre cómo se incorporan todos nuestros datos en el Elastic Stack, consulta nuestra publicación de blog Elastic sobre Elastic: datos recopilados en SIEM de InfoSec (Elastic on Elastic: Data Collected to the InfoSec SIEM).

Hemos realizado algunas actualizaciones en nuestra arquitectura para permitir esta nueva capacidad de alerta distribuida.

Hemos introducido una plataforma de automatización para centralizar nuestros flujos de trabajo en la plataforma de automatización sin código Tines. Mediante el uso de flujos de trabajo integrados en Tines, las alertas del Elastic Stack se clasifican y distribuyen según la lógica predefinida en las historias de Tines.

Cuando se etiqueta una regla de detección para su distribución como DISTRIBUTE_ALERT, Tines redirigirá la alerta desde la cola de clasificación de alertas hacia el flujo de trabajo de alertas distribuidas.

Todas las alertas que contengan la etiqueta DISTRIBUTE_ALERT se ejecutarán a través de nuestro flujo de trabajo de alertas distribuidas. El flujo de trabajo de Tines identifica al usuario en la base de datos de activos y luego envía la alerta al usuario a través de Slack para su confirmación.

Cuando el usuario hace clic en el botón de la alerta, ingresará al siguiente flujo de trabajo para solicitar información adicional o escalar la alerta a Respuesta a incidentes.

Estas alertas abren automáticamente un nuevo caso en Elastic Cases con toda la información relevante. Utilizamos automatizaciones adicionales para proporcionar a los analistas enriquecimientos como GreyNoise y alertas relacionadas de Elastic Security. Los últimos 30 días de actividad para la dirección IP también se proporcionan en una línea de tiempo de Elastic para que el analista la revise.

Cuando el usuario proporciona sus comentarios y confirma la actividad, sus comentarios se registran en el caso y se cierra el caso. 

¿Cómo doy los primeros pasos?

Puedes comenzar con una prueba gratuita de 14 días de Elastic Cloud y utilizar la historia de ejemplo de Tines Alertas de clasificación de Elastic Security y bloquear direcciones IP maliciosas para comenzar a ingestar alertas de Elastic Security en tus flujos de trabajo de automatización. Luego deberás hacer la integración con el cliente de mensajería de tu elección. Tines ofrece historias de ejemplo en su biblioteca para Slack y Microsoft Teams.