Análisis de seguridad de ciertas alertas de la compañía sobre diferentes problemas no existentes. Y lo que es peor, sus resultados no son consistentes. ¿Cómo lidias con tales cosas? Solo dos ejemplos:
El hecho de que un análisis automatizado devuelva un resultado, no significa que sea una "auditoría". Es solo un escaneo.
Para cualquier hallazgo, debe ser
Para fines de documentación, es una buena idea anotar estas 4 cosas para poder comparar los hallazgos futuros, y se pueden revisar las justificaciones, mitigaciones y riesgos en el futuro para asegurarse de que sigan siendo relevantes.
Entonces, para sus dos hallazgos, reconozca que el módulo existe pero que no representa ningún riesgo porque no está activo, y confirme que ambos hallazgos en ambos servidores son verdaderos o no (hay todo tipo de razones por las cuales un análisis mostrar diferentes hallazgos en la misma configuración).
Tengo un problema con el uso del término "falso positivo"
alertas para el módulo mod_lua de Apache incluso cuando este módulo no está activo
¿No está activo? Qué significa eso? Si no necesita mod_lua, los archivos .so no deberían estar en el sistema de archivos a menos que no pueda eliminarlos sin romper algo. Si su servidor web está cargando el módulo pero no lo está utilizando, entonces este es un problema que debe solucionarse.
alertas para diferentes cosas en dos servidores web con configuración idéntica
O los sistemas que usted piensa que son idénticos no lo son, o la compañía de escaneo posiblemente no está haciendo su trabajo correctamente. El primero no es difícil de verificar.
Incluso si está absolutamente convencido de que la compañía que proporciona este servicio es un vaquero inútil, su primer puerto de escala es asegurarse de que tiene una base sólida para refutar sus hallazgos.
Primero, las exploraciones de seguridad son solo herramientas automatizadas. Como tales, los falsos positivos son bastante comunes.
Se debe analizar cada vulnerabilidad informada, lo que significa que un análisis humano debe primero confirmar que tiene sentido, luego evaluar el nivel de riesgo y definir por último la remediación apropiada con la priorización correcta. Este análisis debe considerar el contexto técnico y funcional.
En realidad, los falsos positivos son fáciles de manejar, ya que simplemente deben eliminarse en el primer paso del análisis. Eventualmente, la dificultad es confirmar que esto es un falso positivo o no. Tenga en cuenta que puede enfrentar un problema similar con los verdaderos positivos, por ejemplo, imagine que se ha informado correctamente una vulnerabilidad de divulgación de información, pero que concierne únicamente a la información pública, lo que significa que el nivel de riesgo es aproximadamente nulo. Tenga en cuenta también que los falsos positivos o los riesgos nulos pueden evolucionar en relación con el tiempo y el contexto: el módulo vulnerable deshabilitado podría activarse más tarde, la información confidencial podría almacenarse y la vulnerabilidad de la divulgación cobrará sentido repentinamente.
Por lo tanto, una forma de manejar los falsos positivos es registrarlos para facilitar el análisis futuro de los resultados del escaneo. Pero, en todos los sentidos, el análisis humano es la única forma de tener una evaluación integral de los riesgos. Se debe evitar ignorar sistemáticamente los tipos de vulnerabilidad.
El punto es probablemente informar la decisión con respecto a las vulnerabilidades informadas: si son falsos o verdaderos positivos y por qué, nivel de riesgo evaluado, remediaciones que deben tomarse. Las mejoras de seguridad comienzan con un análisis apropiado.
Veo los puntos de schroeder y de symcbean. Esto es lo que he discutido con los clientes durante los últimos 15 años aproximadamente.
El hecho de que su escáner de vulnerabilidad diga que algo es vulnerable no significa necesariamente que lo sea. Déjame explicarte.
En su ejemplo, las alertas en mod_lua probablemente se basen en la versión de Apache instalada y no en la detección real de mod_lua cargada en la memoria. En el mejor de los casos, sabe que el módulo está instalado y cargado en la memoria. Sin embargo, ¿su aplicación web realmente lo utiliza?
Un gran problema es que la mayoría de los escáneres de vulnerabilidad en el mercado proporcionan poca información sobre el método de detección, por no mencionar la evidencia real.
Aunque eso explica por qué obtuviste posibles falsos positivos, no resuelve tu problema. Honestamente, si estos son los servidores de su empresa, presione para realizar un análisis de vulnerabilidad con credenciales. Obtendrá datos mucho más precisos para trabajar.
Entonces, ¿qué sucede si realiza un análisis con credenciales y aún ve la vulnerabilidad mod_lua?
Parte de su programa de administración de vulnerabilidades debe incluir el uso de su metodología de evaluación de riesgos para evaluar si necesita mitigar (arreglar) o aceptar el riesgo de esa vulnerabilidad.
¿Qué sucede si no tiene una metodología de evaluación de riesgos?
Lo haces ... todos lo hacen. Es posible que no esté documentado y que toda la compañía no comparta su metodología, pero inherentemente, usted toma decisiones basadas en el riesgo todos los días. Si su empresa no tiene un programa formal de evaluación / gestión de riesgos, sugeriría insinuar a los superiores que es un ahorro de tiempo y dinero. Si está bien estructurado, dicta lo que se aborda y en qué orden.
Volver a mod_lua. Si mod_lua está en el servidor, actualice. Mejor aún, si el sitio web no utiliza el lenguaje de scripts Lua, elimine el módulo de la configuración de Apache y mod_lua.so del servidor.
Lea otras preguntas en las etiquetas audit