Un desconocido ha notificado una vulnerabilidad: plan de respuesta

El mensaje suele llegar a la dirección equivocada: soporte, ventas, el buzón personal del fundador. Dice que el remitente ha encontrado una vulnerabilidad en su producto. A veces incluye detalles, a veces pregunta si tiene usted un programa de bug bounty, a veces menciona el dinero en la primera línea.

Lo que haga a continuación decide dos cosas: si esta vulnerabilidad se corrige sin ruido y si el próximo investigador le escribirá a usted o escribirá sobre usted.

Quién escribe estos mensajes

• Investigadores que actúan de buena fe. Han encontrado algo, a menudo por casualidad o al probar toda una categoría de productos, y quieren que se corrija. Muchos esperan una recompensa o un agradecimiento; pocos insisten.
• Remitentes de hallazgos automatizados. Un escáner ha encontrado una cabecera que falta o una biblioteca desactualizada, y el informe se ha enviado a cientos de empresas. El hallazgo puede ser real y suele ser menor.
• Extorsionadores. El mensaje contiene una amenaza: pague o se publican los datos. Esto es un delito y se gestiona como un incidente, no como un informe.

A menudo, por el primer mensaje, usted no puede saber cuál de ellos tiene delante. El plan siguiente sirve para los tres hasta que pueda saberlo.

La primera hora

1. No responda con enfado ni amenace. Una amenaza de acciones legales convierte un informe privado en una historia pública.
2. No pague ni prometa un pago. Todavía no sabe por qué estaría pagando.
3. No haga clic en los enlaces ni abra los archivos adjuntos del mensaje en un equipo de trabajo. Páselo a quien se ocupe de la seguridad.
4. Avise a la persona a cargo de la seguridad. Si no hay nadie, ese es el primer hallazgo.

El primer día

Acuse recibo. Bastan dos frases: el informe se ha recibido, se está examinando y esta es la persona con la que hablar. El silencio es lo que lleva a los investigadores a hacerlo público.

Pida los detalles a través de un canal que usted controle. Un buzón específico, idealmente con una clave de cifrado. Pida la dirección afectada, los pasos para reproducir el problema y a qué ha podido acceder el autor del informe.

Verifique por su parte. Reproduzca el problema por su cuenta, en un entorno de pruebas si es posible. Revise los registros del periodo que indica el autor del informe: a qué se accedió, desde dónde, con qué frecuencia. Los registros le indican si el autor del informe se detuvo en la demostración.

La primera semana

Evalúe la gravedad. ¿Qué puede hacer un atacante con ella y qué dificultad tiene? Una puntuación CVSS ofrece un lenguaje común para la respuesta.

Decida si se trata de un incidente. Si la vulnerabilidad daba acceso a datos personales y no puede descartar que se haya utilizado, pueden aplicarse las obligaciones de notificación de la normativa de protección de datos, con plazos breves. Es una pregunta para sus abogados el primer día, no el último.

Corrija y después comuníqueselo al autor del informe. Indique qué se ha corregido y cuándo. Si no está de acuerdo con el informe, dígalo y explique por qué.

Dele las gracias. Un agradecimiento público, con el consentimiento del autor del informe, no cuesta nada. La recompensa es decisión suya; si la paga, páguela por el hallazgo y no bajo presión, y deje claro que es voluntaria.

Cuando lo primero que se menciona es el dinero

Un investigador que pregunta si tiene usted un programa de bug bounty hace una pregunta normal. La respuesta puede ser «no, pero le agradecemos el informe».

Un remitente que se niega a dar ningún detalle antes del pago, fija un plazo o amenaza con publicar datos no está notificando una vulnerabilidad. Conserve los mensajes, no negocie por su cuenta, implique a sus abogados y valore implicar a las autoridades policiales.

Para que el próximo informe llegue por el cauce correcto

El informe llegó al buzón equivocado porque no había uno correcto. Tres cosas lo resuelven:

• Una política de divulgación en su sitio web: qué se puede probar, cómo notificar, qué puede esperar el autor del informe y su compromiso de no emprender acciones contra quienes cumplan las reglas.
• Un archivo security.txt en /.well-known/security.txt, el lugar donde los investigadores miran primero. El RFC 9116 exige dos campos, Contact y Expires; pasada la fecha de Expires, el archivo se considera obsoleto.
• Un proceso detrás del buzón: quién lo lee, quién verifica, quién decide y en qué plazo.

En esto consiste un programa de divulgación de vulnerabilidades. Si ahora mismo hay un informe esperando respuesta, envíenos una solicitud e indíquelo: estas solicitudes se responden primero.