OWASP Top Ten 2017 (es)

A10:2017-Registro y Monitoreo Insuficientes

Languages: en de [es]
Agente de amenaza / Vector de ataque Debilidades de seguridad Impacto
Específico
de la Apl.
Explotabilidad: 2 Prevalencia: 3 Detectabilidad: 1 Técnico: 2 ¿Negocio?
El registro y monitoreo insuficientes es la base de casi todos los grandes y mayores incidentes de seguridad. Los atacantes dependen de la falta de monitoreo y respuesta oportuna para lograr sus objetivos sin ser detectados.
Este punto se incluye en el Top 10 basado en la encuesta a la industria.
Una estrategia para determinar si usted no posee suficiente monitoreo es examinar los registros después de las pruebas de penetración. Las acciones de los evaluadores deben registrarse lo suficiente como para comprender los daños que podrían haber causado.
Los ataques más exitosos comienzan con la exploración de vulnerabilidades. Permitir que el sondeo de vulnerabilidades continúe puede aumentar la probabilidad de una explotación exitosa. En 2016, la identificación de brechas tardó una media de 191 días, un tiempo más que suficiente para inflingir daño.
¿La aplicación es vulnerable?
El registro y monitoreo insuficientes ocurren en cualquier momento:
* Eventos auditables, tales como los inicios de sesión, fallos en el inicio de sesión, y transacciones de alto valor no son registrados.
* Advertencias y errores generan registros poco claros, inadecuados o ninguno en absoluto.
* Los registros en aplicaciones o APIs no son monitoreados para detectar actividades sospechosas.
* Las bitácoras son almacenados únicamente de forma local.
* Los umbrales de alerta y de escalamiento de respuesta no están implementados o no son eficaces.
* Las pruebas de penetración y escaneos utilizando herramientas DAST (como OWASP ZAP) no generan alertas.
* La aplicación no logra detectar, escalar o alertar sobre ataques en tiempo real.
También es vulnerable a la fuga de información si registra y alerta eventos visibles para un usuario o un atacante (consulte A3:2017-Sensitive Data Exposure ).
Cómo se previene
Según el riesgo de los datos almacenados o procesados por la aplicación:
* Asegúrese de que todos los errores de inicio de sesión, de control de acceso y de validación de entradas de datos del lado del servidor se pueden registrar para identificar cuentas sospechosas. Mantenerlo durante el tiempo suficiente para permitir un eventual análisis forense.
* Asegure que las bitácoras se generan en un formato que pueda ser consumido con facilidad por una solución centralizada de gestión de bitácoras.
* Establezca monitoreo y alerta efectivos de tal manera que las actividades sospechosas sean detectadas y respondidas dentro de períodos de tiempo aceptables.
* Establezca o adopte un plan de respuesta o recuperación de incidentes, tales como NIST 800-61 rev 2 o posterior.
Existen marcos de trabajo de protección de aplicaciones comerciales y de código abierto tales como OWASP AppSensor, cortafuegos de aplicaciones web como ModSecurity utilizando el Juego de Reglas Fundamental de OWASP ModSecurity, y software de correlación de bitácoras con paneles personalizados y alertas.
Ejemplos de escenarios de ataque
Escenario #1: el software de un foro de código abierto es operado por un pequeño equipo que fue atacado utilizando una falla de seguridad. Los atacantes lograron eliminar el repositorio del código fuente interno que contenía la próxima versión, y todos los contenidos del foro. Aunque el código fuente pueda ser recuperado, la falta de monitorización, registro y alerta condujo a una brecha de seguridad peor.
Escenario #2: un atacante escanea usuarios utilizando una clave común. Pueden tomar el control de todas las cuentas utilizando esa clave. Para todos los demás usuarios, este proceso deja solo un registro de fallo de inicio de sesión. Luego de algunos días, esto puede repetirse con una contraseña distinta.
Escenario #3: De acuerdo a reportes, un importante minorista tiene una arenera de análisis de malware interno para los archivos adjuntos de correos electrónicos. Esta arenera había detectado software potencialmente indeseable, pero nadie respondió a esta detección. Se habían estado generando advertencias por algún tiempo antes de que la brecha de seguridad fuera detectada por un banco externo, debido a transacciones fraudulentas de tarjetas.
Referencias