Administrar registros de errores excesivos de autenticación de miembros y servidores

1

Actualmente, en nuestro entorno SIEM, intentamos reducir el ruido y cualquier elemento no accionable. Uno de los elementos más frecuentes que recibimos semanalmente es un informe basado en fallas excesivas de autenticación de miembros y servidores.

El concepto general es informarnos de cualquier cuenta que constantemente falla en la autenticación en un host durante un período de 24 horas, donde no se ven eventos exitosos dentro del mismo período de 24 horas. A menudo determinamos el tipo de falla en función del código de evento que está produciendo, así como la identificación de la firma.

Nuestro proceso estándar es ponerse en contacto con el propietario de la cuenta o el servidor y pedirle que investigue qué está causando las fallas excesivas. Este proceso puede ser bastante largo y lento, y depende de la comunicación del analista con el propietario de la cuenta. Yo diría que el 95% de estas alertas no son procesables o se cierran después de una búsqueda de seguimiento de SIEM.

Para evitar un posible ataque de fuerza bruta, hacemos un seguimiento de estos registros. Mi pregunta es; ¿Existe una capa adicional de filtrado o reglas que se modifiquen para reducir estos registros?

Códigos de evento comunes:

4625 
4776

También existe un proceso diferente que puede ser utilizado para monitorear y reportar tales cuentas excesivas. En este momento, debemos crear un nuevo ticket de seguimiento para cada cuenta que cumpla con nuestro estándar y / o umbral actual.

A través del análisis, creo que si un analista puede determinar si el fallo es realmente una fuerza bruta es accionable de lo que luego completaríamos los pasos necesarios. De lo contrario, estas fallas excesivas se pueden revisar y enviar al propietario de la cuenta respetada según sea necesario.

¿Alguna idea al respecto? ¡Gracias!

    
pregunta Curious Analyst 14.10.2018 - 19:25
fuente

1 respuesta

1
  

Es cierto, como dijiste, que ambas ID de eventos pueden ser muy ruidosas   (Especialmente ID 4625). Sin embargo, la forma de manejar esos eventos puede ser,   Desde mi experiencia, mejorado con las siguientes sugerencias.

De primera mano, y si su objetivo es mejorar su proceso , le sugeriría que revise la forma en que agrupa y administra esos eventos en su SIEM (sea el que sea). En realidad, analizar cada evento como un solo evento puede resultar en una pérdida de tiempo y pérdida total de visibilidad. Lo que sería interesante es que agrupe eventos y cuente (con umbrales), por ejemplo, la cantidad de tiempo que se ve una IP de origen, un usuario o un destino durante un intento de inicio de sesión fallido. Esto se puede hacer creando algunas reglas / escenarios / caso de uso de brutforce avanzado. A continuación les proporciono un concepto que he hecho y que he implementado. A la izquierda tiene los diferentes parámetros que pueden ajustarse y en los que debe agrupar o no. Riesgo significa el nivel de criticidad de los escenarios cuando alerta y crea un umbral de la variable que debe ajustar para el escenario / caso de uso.

Notarásquenoagruposobreelcódigodeerror.Estosedebeaqueconsideroqueunatacantepuedeproducirresultadosdiferentesduranteunataquedefuerzabrutal.Sinembargo,todavíapuedecrearcasosdeusoespecíficosparaerroresespecíficos(bloqueo,deshabilitado,caducado,cuentasnoexistentes...).

Porotraparte,sisuobjetivoestambiénreducirlacantidaddeesoseventos,puedosugerirlassiguientesacciones:

  • Aumentelaprioridadenlosintentosfallidosdeiniciodesesiónenactivosespecíficos(servidoressensibles,servidoresDMZ,basesdedatos,controladoresdedominio,PKI,...)
  • Enfocarseeniniciosdesesiónfallidosencuentasconfidenciales(porejemplo:cuentasdeservicioodeadministración)
  • Ignorarloserroresdebloqueoenlascuentasdeusuariohastaquepermanezcanbajosusumbralesdepolíticadebloqueo
  • Correlacioneloseventosdefalla(ID4625y4776)conloseventosproducidosenlamáquinafuente(ID4648).EstopuedepermitirdetectarPthoataquesdemovimientolateral.Puedeusarlasiguientetabladeeventosdefalla/éxitoparahacerelenlaceentrelafuenteyeldestinoyenriquecersusalidaparasuanalista.

  • CorrelacionelosIDdeloseventosdefalla4625conloseventosdeKerberos(ID4771,4768)paraenriquecerlosresultadosqueelanalistadeberáverificar

  • Ignorealgunoscódigosdeerrorespecíficosensusprincipalescasosdeuso,PEROhagadeellosnuevoscasosdeusoconmenorprioridad.Comprobarásesosincidentesmástarde.Comoentrada,puedoproporcionarleelsiguienteextractodecódigosdeerrorpara4625parafiltrarloquenecesita:

  

Así que espero que este montón de información te ayude. Pero tenga en cuenta la correlación en la clave para reducir la carga, los falsos positivos y aumentar la visibilidad.

    
respondido por el Michel de Crevoisier 18.10.2018 - 17:02
fuente

Lea otras preguntas en las etiquetas