Del hallazgo al aviso

Un informe de vulnerabilidad llega al buzón de seguridad de un fabricante. Las normas ISO/IEC 29147 y 30111 reparten el trabajo en dos mitades: la primera describe cómo recibir informes y publicar avisos hacia fuera; la segunda, cómo tratar la vulnerabilidad por dentro, investigarla y corregirla. La parte que ve quien reporta empieza siempre igual: alguien responde que el informe llegó.

Ese primer paso, el acuse de recibo, no dice que el fallo sea real ni cuándo estará corregido. Solo evita que quien reporta se quede sin saber si su mensaje cayó en el vacío, que es la causa más común de que alguien acabe publicando por su cuenta.

Abre las tablas registro y aviso del caso HOR-R-014 de Hornacina Software. El registro cuenta lo que pasó por dentro, hito por hito; el aviso es lo que el fabricante dice hacia fuera. Un cliente que busque ese aviso en su gestor de vulnerabilidades o en la web del fabricante lo hará por su identificador, así que es lo primero que conviene anotar.

Cada hito del registro lleva su fecha, y las fechas permiten medir. Para el analista, la distancia entre el informe y el aviso es el tiempo durante el cual el fabricante sabía algo que sus clientes no. No es una acusación: arreglar bien lleva tiempo. Es un dato para entender el caso.

Cuenta en días naturales, de la fecha del informe a la del aviso, sin contar el día de partida.

Un aviso sirve si el cliente puede decidir con él. Para eso tiene que decir qué producto y qué versiones están afectados, en cuál queda corregido y qué hacer mientras tanto. Compáralo con la tabla aviso: están esos campos y también el crédito a quien reportó.

Lo que no debe llevar es información que ayude a atacar a quien aún no ha parchado, ni datos de otros clientes.