Consideraciones para las notas de la versión de seguridad

6

Necesito ayuda para comprender cómo administrar las notas de la versión de seguridad de nuestro producto. Creamos la versión principal de nuestro producto cada medio año y las versiones de seguridad o mantenimiento cada mes.

¿Qué debo considerar con respecto a lo que les decimos a nuestros clientes sobre la seguridad?

  • ¿Deberíamos decirles que actualizamos nuestro software 3-d party?
    P.ej. ¿Deberíamos decirles que actualizamos la versión del servidor HTTP Apache?
  • ¿Deberíamos enumerar las vulnerabilidades corregidas en Apache Httpd?
    ¿O es suficiente para enlazar al sitio de Apache?
  • ¿Debemos gestionar la lista de software de terceros con versiones?
  • ¿Qué pasa con nuestras vulnerabilidades de seguridad internas?
    ¿Debemos enumerar la lista de vulnerabilidades de seguridad fijas? Esto puede poner en peligro a los clientes que no se actualicen a la última versión.
  • ¿Cómo debemos anunciar las vulnerabilidades de seguridad?
    ¿Deberíamos agregar nuestra compañía como proveedor a la base de datos de CVE enlace (como Apache) y crear un nuevo CVE cada vez que lo encontremos? ¿O es suficiente para enumerar nuestro número de error interno?
  • ¿Deberíamos agregar a la base de datos CVE solo las vulnerabilidades descubiertas por nuestros clientes? ¿O deberíamos agregar a la base de datos CVE también las vulnerabilidades descubiertas por el control de calidad?

(Nuestro producto es una aplicación web Java que se ejecuta en Apache y Tomcat).

    
pregunta Michael 23.12.2013 - 15:26
fuente

1 respuesta

5

¡Gran pregunta! He escrito algunos de estos, pero siempre tuve una forma muy formal de hacerlo, de modo que nunca tuve la opción de pensar en lo que realmente se necesita ...

Desde la perspectiva de las personas que tienen que usar, respaldar y actualizar su producto, creo que debe cubrir:

  • Información de alto nivel (y un puntero, si es posible, a los detalles), sobre por qué fue necesaria la corrección. Algo así como "el manejo del buffer de cadena corregido en el componente XYZ" es útil.

  • Problemas conocidos: cualquier cosa que no haya podido solucionar y que todavía esté allí.

  • Actualizaciones de software de terceros y un lugar para encontrar la línea de base actual de todo el software de terceros, ya sea que se haya actualizado o no.

En esencia, necesitan saber qué es lo que arreglaste y cuál es tu línea de base. Particularmente en el mundo de Java, puede haber suficientes conflictos y problemas, por lo que una compañía inteligente debe mantener un registro de qué servidores ejecutan qué versiones de las JVM y otros componentes.

Algunas otras respuestas específicas para sus preguntas:

  • ¿Deberíamos enumerar las vulnerabilidades corregidas en Apache Httpd? ¿O suficiente enlace al sitio de Apache?

    • Un enlace sería una amabilidad. No desordene SUS notas de publicación con los detalles de otros productos.
  • ¿Debemos gestionar la lista de software de terceros con versiones?

    • Debería estar disponible en algún lugar, no estoy seguro de que tenga que estar en las notas de la versión, pero si no, debería estar en su sitio web en algún lugar.
  • ¿Qué pasa con nuestras vulnerabilidades de seguridad internas? ¿Debemos enumerar la lista de vulnerabilidades de seguridad fijas? Puede poner en peligro a aquellos clientes que no se actualicen a la última versión.

    • Tenga en cuenta que el hecho de no divulgar vulnerabilidades conocidas podría considerarse una responsabilidad legal. Este es uno para sus abogados. En mi opinión, decirles a los clientes que sepan por qué que una solución de seguridad es tan importante es más que compensar el valor de ocultarla por la seguridad de aquellos que no pueden realizar la actualización lo suficientemente rápido. Dicho esto, no tiene que decir "si X, Y, Z obtendrá privilegios de administrador". Decir "vulnerabilidad dañada en el sistema de control de acceso" debería ser lo suficientemente bueno.
  • ¿Cómo debemos anunciar las vulnerabilidades de seguridad? ¿Deberíamos agregar nuestro proveedor a la base de datos de CVE enlace y crear un nuevo CVE cada vez que lo encontremos? ¿O es suficiente para enumerar nuestro número de error interno?

    • No estoy realmente seguro de lo que quiere decir con "nuestro proveedor". Personalmente, no registraría a un tercero para los hallazgos de CVE sin estar de acuerdo con ellos.
  • ¿Deberíamos agregar a la base de datos CVE solo las vulnerabilidades descubiertas por nuestros clientes? ¿Deberíamos agregar a la base de datos CVE también las vulnerabilidades descubiertas por el control de calidad?

    • Todavía no he oído hablar de ningún proveedor que utilice CVE para la documentación de prueba / corrección interna. Creo que si lo encontraste primero, enlazar a tu propio repositorio de errores corregidos debería estar bien, pero no he hecho tanto software comercial.
respondido por el bethlakshmi 23.12.2013 - 17:04
fuente

Lea otras preguntas en las etiquetas