A09:2021 – Fallos de Registro y Monitoreo de Seguridad

Registro y monitoreo de seguridad

Resumen

El registro y monitoreo de seguridad surgió del #3 en la encuesta comunitaria, subiendo ligeramente desde la décima posición en el OWASP Top 10 2017. El registro y monitoreo pueden ser difíciles de probar, a menudo involucrando entrevistas o preguntando si se detectaron ataques durante una prueba de penetración. No hay muchos datos CVE/CVSS para esta categoría, pero detectar y responder a brechas es crucial. Aún así, puede ser muy impactante para la responsabilidad, visibilidad, alertas de incidentes y forenses. Esta categoría se expande más allá de CWE-778 Registro Insuficiente para incluir CWE-117 Neutralización Incorrecta de Salida para Registros, CWE-223 Omisión de Información Relevante para la Seguridad y CWE-532 Inserción de Información Sensible en el Archivo de Registros.

Descripción

Regresando al OWASP Top 10 2021, esta categoría ayuda a detectar, escalar y responder a brechas activas. Sin registro y monitoreo, las brechas no pueden ser detectadas. El registro, detección, monitoreo y respuesta activa insuficientes ocurren en cualquier momento que:

  • Los eventos auditable, como inicios de sesión, inicios de sesión fallidos y transacciones de alto valor, no se registren.
  • Las advertencias y errores no generen mensajes de registro o generen mensajes de registro inadecuados o poco claros.
  • Los registros de aplicaciones y APIs no se monitoricen en busca de actividad sospechosa.
  • Los registros solo se almacenan localmente.
  • No se encuentran en su lugar o son ineficaces los umbrales de alerta apropiados y los procesos de escalación de respuesta.
  • Las pruebas de penetración y los análisis por herramientas de pruebas de seguridad de aplicaciones dinámicas (DAST) (como OWASP ZAP) no generan alertas.
  • La aplicación no puede detectar, escalar o alertar sobre ataques activos en tiempo real o casi en tiempo real.

Eres vulnerable a la filtración de información al hacer visibles los eventos de registro y alerta a un usuario o atacante (ver A01:2021-Control de Acceso Roto).

Cómo prevenir

Los desarrolladores deben implementar algunos o todos los siguientes controles, dependiendo del riesgo de la aplicación:

  • Asegúrate de que todos los fallos de inicio de sesión, control de acceso y validación de entrada del lado del servidor puedan ser registrados con el suficiente contexto del usuario para identificar cuentas sospechosas o maliciosas, y que se mantengan durante el tiempo necesario para permitir un análisis forense retrasado.
  • Asegúrate de que los registros se generen en un formato que las soluciones de gestión de registros puedan consumir fácilmente.
  • Asegúrate de que los datos de registro estén codificados correctamente para prevenir inyecciones o ataques en los sistemas de registro o monitoreo.
  • Asegúrate de que las transacciones de alto valor tengan una pista de auditoría con controles de integridad para prevenir manipulaciones o eliminaciones, como tablas de base de datos solo de adición o similares.
  • Los equipos de DevSecOps deben establecer un monitoreo y alertas efectivas para que las actividades sospechosas sean detectadas y respondidas rápidamente.
  • Establece o adopta un plan de respuesta y recuperación ante incidentes, como el NIST 800-61r2 o versiones posteriores.

Existen marcos de protección de aplicaciones comerciales y de código abierto como el OWASP ModSecurity Core Rule Set, y software de correlación de registros de código abierto, como el stack Elasticsearch, Logstash, Kibana (ELK), que presentan paneles personalizados y alertas.

Ejemplos de escenarios de Ataque

Escenario #1: El operador del sitio web de un proveedor de planes de salud infantil no pudo detectar una brecha debido a la falta de monitoreo y registro. Una parte externa informó al proveedor de planes de salud que un atacante había accedido y modificado miles de registros de salud sensibles de más de 3.5 millones de niños. Una revisión posterior al incidente descubrió que los desarrolladores del sitio web no habían abordado vulnerabilidades significativas. Dado que no había registro ni monitoreo del sistema, la brecha de datos podría haber estado en curso desde 2013, un período de más de siete años.

Escenario #2: Una importante aerolínea india sufrió una brecha de datos que involucró más de diez años de datos personales de millones de pasajeros, incluidos datos de pasaportes y tarjetas de crédito. La brecha de datos ocurrió en un proveedor de servicios en la nube de terceros, quien notificó a la aerolínea de la brecha después de algún tiempo.

Escenario #3: Una importante aerolínea europea sufrió una brecha reportable bajo el GDPR. Se informó que la brecha fue causada por vulnerabilidades de seguridad en una aplicación de pagos explotadas por atacantes, quienes recolectaron más de 400,000 registros de pagos de clientes. Como resultado, la aerolínea fue multada con 20 millones de libras por el regulador de privacidad.

Referencias