Cómo hablar con su desarrollador sobre la seguridad de su web

Tiene delante un informe de seguridad, un correo de su empresa de alojamiento o el mensaje de un cliente que dice que algo se ve raro. No sabe bien hasta qué punto es grave. No quiere parecer que no tiene ni idea, y tampoco quiere pagar un trabajo que nunca hizo falta.

Para tener una buena conversación con su desarrollador no necesita conocimientos técnicos. Necesita estructura: una petición clara, una fecha firme y una forma de comprobar que el trabajo se hizo. Así se prepara.

Qué enviar en el primer mensaje

Un desarrollador trabaja más rápido cuando recibe tres cosas desde el principio.

El hallazgo con las palabras de la fuente. Copie el nombre del problema exactamente como lo escribió el informe o el proveedor de alojamiento. No lo reformule. «Archivo de copia de seguridad accesible públicamente» le dice a un desarrollador mucho más que «algo pasa con las copias de seguridad».

La dirección exacta. No «en la web», sino la dirección completa de la página o del archivo, por ejemplo https://sudominio.com/backup.zip.

Las pruebas. Una captura de pantalla con la fecha visible, el informe completo adjunto, el correo de su proveedor reenviado. Así nadie tiene que adivinar lo que usted vio.

El mensaje entero puede ser así de corto:

Asunto: sudominio.com, archivo de copia de seguridad accesible públicamente

Hola, Marcos: una revisión de seguridad del 2 de septiembre mostró que se puede descargar una copia de seguridad del sitio desde https://sudominio.com/backup.zip. Adjunto la captura y el informe completo. ¿Puedes confirmar si es correcto y enviarme un presupuesto y una fecha para la corrección? Si crees que es una falsa alarma, dime por qué en un par de frases.

Algo que no debe enviar: contraseñas en el cuerpo de un correo. Si su desarrollador necesita acceder al panel de administración, créele una cuenta propia que sea fácil de eliminar después.

Pida un presupuesto y una fecha, no «que le eche un vistazo»

«Échale un vistazo cuando tengas un momento» es una petición que puede esperar meses. Pida en su lugar cuatro cosas concretas: qué se hará exactamente, cuánto cuesta o cuántas horas lleva, para cuándo, y si algo podría dejar de funcionar por el camino.

Esa última pregunta importa más de lo que parece. Actualizar un plugin antiguo puede ser sencillo o puede arrastrar cambios en el tema. Mejor saberlo antes que descubrir un viernes por la noche que el formulario de pedidos no funciona.

Si paga a su desarrollador una cuota mensual, pregunte si la corrección está incluida o cuenta como trabajo aparte. Para cualquier cosa seria, pídale que separe dos cosas: eliminar el síntoma y cerrar la causa. Borrar un archivo malicioso sin averiguar cómo llegó al servidor es una corrección que dura más o menos una semana.

Acuerde qué se hace esta semana, este mes y más adelante

No todo es urgente, y querer arreglarlo todo a la vez suele acabar en que nada se hace bien. Tres plazos funcionan bien.

Esta semana incluye lo que alguien podría aprovechar ahora mismo o lo que expone datos: un archivo de copia de seguridad o de configuración que cualquiera puede descargar, un plugin con un fallo conocido que se está explotando activamente, una advertencia de Google, un certificado caducado, una cuenta de administrador que nadie reconoce, un formulario que envía datos sin cifrar.

Este mes incluye las actualizaciones atrasadas sin ataque activo conocido, un registro DMARC que falta o que está en p=none, las cabeceras de seguridad que faltan y las cuentas antiguas de exempleados o colaboradores.

Más adelante incluye lo que sube el listón pero no perjudicará a nadie si espera unas semanas: ocultar los números de versión, afinar una política de seguridad de contenidos, cambiar a un alojamiento mejor.

Su desarrollador puede ver el orden de otra manera, y conviene escuchar por qué. Pero la decisión final es suya, porque usted asume el riesgo y paga las consecuencias.

Cómo comprobar que la corrección se hizo

Un «hecho» en un correo no basta. Pida una nota breve: qué se cambió, dónde y cuándo. Bastan dos frases, siempre que estén por escrito.

Algunas cosas puede comprobarlas usted mismo. Si el problema era un archivo de copia de seguridad, su dirección debería mostrar ahora un error en lugar de iniciar una descarga. Si era el certificado, el candado del navegador mostrará una nueva fecha de caducidad. Si eran las actualizaciones, no debería quedar nada pendiente en la página Plugins de WordPress.

La comprobación más sencilla es repetir la misma prueba que encontró el problema y comparar los resultados. Si el hallazgo ha desaparecido del informe, ya tiene la confirmación. Si no, tiene un motivo concreto para retomar la conversación.

Guarde toda la correspondencia en una carpeta. Ayuda en la siguiente corrección y, si alguna vez se filtran datos, demuestra que se ocupó de la seguridad, algo que el RGPD espera que usted pueda probar.

Qué incluye un plan de mantenimiento sensato

Las correcciones puntuales apagan incendios. Para que no empiecen, un sitio web necesita un cuidado regular. Un alcance mensual sensato para el sitio de una pequeña empresa es este:

• actualizaciones del CMS, el tema y los plugins al menos una vez al mes, los parches de seguridad urgentes antes, y una revisión del sitio después de cada actualización,
• copias de seguridad guardadas fuera del servidor, con una restauración de prueba de vez en cuando,
• vigilancia de que el sitio está en línea y de que el certificado no está a punto de caducar,
• una revisión de las cuentas que pueden entrar en el panel de administración,
• una revisión de seguridad periódica desde fuera,
• un breve resumen mensual: qué se hizo y qué necesita su decisión,
• un tiempo de respuesta y un canal de contacto acordados en caso de intrusión.

Los precios varían mucho, así que compare lo que incluye cada oferta y no solo la cifra mensual. Y asegúrese de una cosa, diga lo que diga el contrato: el dominio y el alojamiento deben estar registrados a nombre de su empresa, y usted debe tener su propia cuenta de administrador. Si la relación termina, no puede quedarse sin acceso a su propio sitio web.

Señales de alarma en las respuestas

No necesita juzgar el sitio técnicamente para detectar respuestas que deberían preocuparle:

• «WordPress es seguro, no hay nada que hacer».
• «No actualizamos porque algo podría romperse». A veces es cierto, pero entonces la respuesta es una copia de pruebas del sitio donde se prueban primero las actualizaciones, no saltarse las actualizaciones.
• «Las copias de seguridad están en el servidor». Si eso significa el mismo servidor donde funciona el sitio, una intrusión o una avería se las lleva junto con el sitio.
• «Mándame tu contraseña». Cada persona debe tener su propia cuenta.
• «Es un falso positivo», sin ninguna explicación.
• «Ya me pondré», sin fecha.
• Reticencia a darle acceso a su propio alojamiento, dominio o panel de administración.

Un buen desarrollador no se toma las preguntas como algo personal, porque las preguntas claras facilitan acordar el alcance y cobrar por él. Si las respuestas llegan vagas o a la defensiva, eso también le dice algo, y conviene tenerlo presente antes del próximo contrato.