El cliente pide el informe en inglés, ¿cómo debemos preparar los documentos de gestión de vulnerabilidades?

En clientes corporativos, sobre todo los comités de auditoría, miran más los formatos estándar en inglés que el idioma local. Ni se les ocurra cometer el error de escribirlo en turco y mandarlo a una agencia de traducción; un traductor que no conozca los términos técnicos puede dejar incomprensibles las explicaciones de seguridad. El equipo se tiene que acostumbrar a documentar directamente en inglés.

Les recomiendo cumplir al pie de la letra estos cinco estándares al preparar el informe: 1) El executive summary debe estar orientado al riesgo sí o sí, 2) Cada hallazgo debe incluir la cadena de vector CVSS oficial, 3) Los pasos de Proof of Concept deben mostrarse claramente con capturas de pantalla, 4) La propuesta de solución no debe ser un consejo general sino un comando aplicable o corrección de código, 5) Se deben referenciar los números CWE y CVE correspondientes.

edit: arriba escribí mal, disculpad.

Donde más se falla en la terminología es en la clasificación del riesgo. En vez de poner medio o alto a criterio propio, especifiquen claramente los parámetros CVSS Base Score y Temporal Score. Dejar los componentes del vector en su formato original en el texto en inglés, como Attack Vector: Network o Privileges Required: Low, le facilita muchísimo la vida al auditor.

El año pasado nos encontramos con una petición parecida y al principio mandamos el informe en turco a traducción técnica profesional. La traducción de un solo informe de 40 páginas costó 850 euros y nuestro equipo perdió dos días enteros corrigiendo errores de términos. Después nos pasamos a una plantilla de seguridad en inglés ya hecha; al principio tardábamos un poco más en redactar, pero redujimos el coste a cero.

Ojo con el nivel de inglés de su equipo. Si a sus expertos en seguridad les cuesta escribir en inglés, el impacto del hallazgo técnico o la solución se pueden transmitir mal o de forma incompleta. Aunque la plantilla esté en inglés, es imprescindible que alguien senior de la empresa revise los textos de los hallazgos para comprobar la coherencia técnica y lingüística.

los jefes por lo general ni leen los detalles tecnicos. pones un grafico bonito de distribucion de riesgos en la primera pagina y un executive summary limpio de 3 parrafos y la direccion del cliente queda convencida, los detalles de abajo ya los revisa su propio equipo tecnico.

Se debe prestar atención al acuerdo de confidencialidad y a los protocolos de seguridad de datos firmados con el cliente. Transferir documentos sensibles que contienen fallos de seguridad y vulnerabilidades del sistema a herramientas de IA de terceros o a proveedores externos para traducirlos puede suponer un riesgo legal; toda la documentación debe prepararse en un entorno interno seguro.

¿En el informe en inglés estamos obligados a reportar cada pequeño fallo de configuración que detectemos? ¿O solo hay que incluir en el informe los hallazgos críticos y de nivel alto con un score CVSS de 7 o superior?

soy una pequeña empresa, os lo cuento desde mi lado luego si el camino de la notificación es largo la notificación no llega; una notificación que no llega significa un incidente detectado tarde.

por supuesto cambia si tu situación es diferente.

Hablaré desde el otro lado, yo estoy en el lado del proveedor. Al tomar decisiones escribe también el peor escenario no solo el mejor.

Eso es todo disculpa si me he extendido demasiado.

Entrando en detalle: Si el camino de la notificación es largo, la notificación no llega; una notificación que no llega significa un incidente detectado tarde.

Ánimo.

Voy a detallar un poco el aspecto técnico. La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación.

Comprobado por experiencia.

Hay un punto que me genera dudas. bueno si regañas las falsas alarmas, nadie volverá a reportar.

Espero que le sea útil.

si vas por ahí, resuelve esto desde el principio y en fin la mayor parte de la pérdida de tiepmo se acumula en los trabajos pendientes de aprobación.

todo lo que no está por escrito ambas partes lo recordarán de forma distinta en el futuro.

Yo pasé por esto, déjenme contarlo. Intentar hacerlo solo es la vía más cara.

Corrijanme si me equivoco.

Creo que es difícil hablar con tanta claridad sobre gestión de vulnerabilidades en inglés. Los entornos de prueba olvidados son una puerta de entrada más frecuente que el sistema en producción.

Por supuesto, cambia si tu situación es diferente.

Después de vivir eso, mi perspectiva cambió. La seguridad no es absoluta; significa hacer que el ataque no merezca la pena.

Por supuesto, cambia si tu situación es diferente.

Hablaré desde el otro lado, yo estoy en el lado del proveedor. Las decisiones apresuradas son las que hay que corregir seis meses después.

Intentar hacerlo solo es la vía más cara. Lo dejo como nota, por si sirve.