¿Debería mencionarse en el informe de vulnerabilidad una vulnerabilidad en un servicio que está presente en el dispositivo, pero que no se está ejecutando y no se usa en absoluto?

Depende de cómo su organización use este tipo de informes.

Si las personas responsables de la planificación y / o la implementación de los controles de seguridad leen estos documentos una vez y luego nunca los vuelven a mirar O los ven más como una guía que las reglas reales sobre cómo configurar un entorno, puedo ver que es posible desea abstenerse de agregar demasiada información en el informe. Simplemente porque desea asegurarse de que las vulnerabilidades que están presentes de forma aguda se cumplen con medidas de seguridad.

Por otro lado, si estos son documentos "vivos" que establecen reglas sobre cómo deben planificarse e implementarse los controles Y las personas responsables actualizan estos documentos si la infraestructura cambia en un momento determinado, definitivamente desea incluir estos vulnerabilidades

En mi humilde opinión, como persona que organiza la seguridad de la información en una institución, este es el tipo de cultura que debe impulsar.

Si tiene miedo de que su documento se llene demasiado, siempre puede trabajar con su estructura. Algo que se hizo en una organización con la que trabajé, fue que se agregaron vulnerabilidades como esta o posibles vulnerabilidades futuras en un anexo del documento principal. Si la infraestructura se modificó de alguna manera, los administradores podrían revisar el anexo primero, si alguno de los cambios traería las vulnerabilidades enumeradas allí.

Un último punto que me gustaría resaltar: aunque USTED no habilitó esas funciones, esto no significa que un atacante no lo hará después de que él / ella haya tenido acceso al enrutador. Así que la implementación de medidas de seguridad por si acaso puede ser razonable. Sin embargo, esto podría ser algo que debería evaluarse en un análisis de riesgo.

Para citar ISO / IEC 27005:

  

La presencia de una vulnerabilidad no causa daño en sí misma, como   Tiene que haber una amenaza presente para explotarla. Una vulnerabilidad que   no tiene amenaza correspondiente no puede requerir la implementación de un   control, pero debe ser reconocido y monitoreado por cambios.

Como cliente de informes de vulnerabilidad, diría que sí, pero sin duda es una pérdida de tiempo darle el mismo peso que otras vulnerabilidades. Por ejemplo, los orificios de acceso remoto masivo y explotable en vivo o las puertas traseras maliciosas activas no obtendrían la misma cobertura que algo así como una vulnerabilidad DoS o, en este caso, una vulnerabilidad en un bit de software deshabilitado.

En mi humilde opinión, el informe debe tener un resumen ejecutivo, hallazgos técnicos y luego entrar en detalles tediosos.

Algo así como lo que usted describe sería un comentario de una sola línea en los hallazgos técnicos y tendría información en la tediosa sección de detalles.

Sin embargo, CVE-2016-6380 significaría que no estás parcheando regularmente los dispositivos, o que tienes un ciclo de parches muy lento. Esto podría ser un riesgo aceptado por parte del cliente, pero debe revisarse. Merece la pena mencionar esto en el resumen ejecutivo. Sin CVE # cosas, a los ejecutivos no les importa.

Ver más en NIST 800-115 7.3

  

...

     

Si bien las vulnerabilidades individuales deben identificarse y resolverse,   identificar la causa raíz de las vulnerabilidades es clave para mejorar la   postura de seguridad general de la organización porque una causa raíz a menudo puede   ser rastreado a las debilidades a nivel de programa. Algunas causas comunes   incluye:

     

• Administración de parches insuficiente, como no aplicar   parches de manera oportuna o no aplicar parches a todos   sistemas vulnerables
  

...

En primer lugar, debe tener un alcance de lo que está escaneando y de lo que está informando.

Por ejemplo, el alcance del análisis para descubrir e informar sobre todas las vulnerabilidades, incluidas las vulnerabilidades de bajo riesgo, o solo una de alto riesgo, o tal vez solo las vulnerabilidades críticas. Esto debería haberse definido antes de que incluso comenzara el análisis de vulnerabilidades.

Si se trata de un falso positivo confirmado, elimínelo del informe.

Si es un servicio que está presente pero no se utiliza y está confirmado en su vulnerabilidad de alcance, entonces inclúyalo en el informe para que el servicio pueda eliminarse del objetivo.

Si alguien toma una decisión de compra, podría decir "este enrutador admite la resolución de DNS en el enrutador. No usamos esto ahora, pero podríamos hacerlo en el futuro, así que compramos este enrutador y no un poco más barato". uno sin la característica ".

Esa vulnerabilidad significa que el enrutador no se puede usar de esa manera, por lo que la característica no debe usarse para la decisión de compra. En otras palabras, debería estar en su informe por esta razón. Y si el servicio puede eliminarse del dispositivo, entonces debe eliminarse. (Podría descubrir que su suposición de que no se usó era realmente incorrecta si se elimina el servicio y la gente se queja).