En resumen: la concienciación en seguridad de los empleados del equipo web significa que cada persona que mantiene un sitio web conoce los tres o cuatro riesgos de su rol, reconoce las anomalías y las comunica rápido y sin miedo a reproches. Los redactores necesitan contenidos distintos que los administradores. Sesiones breves y recurrentes con ejemplos del propio CMS funcionan mejor que una formación obligatoria anual.
Por qué ahora el equipo web está en el centro
La situación en torno a PHP2Shell ha mostrado cuánto cae en pocos días sobre los operadores de sitios web: avisos del BSI (Oficina Federal alemana para la Seguridad de la Información), comunicados de proveedores de alojamiento, consejos en foros y redes sociales, también falsos. En semanas así no deciden solo los administradores, sino también los redactores, el marketing y la asistencia, qué correo abren y en qué enlace hacen clic.
Según la experiencia, las grandes noticias son una ocasión para los estafadores. Cuente con correos que se hacen pasar por el proveedor de alojamiento, el fabricante del CMS o el «departamento de TI» y exigen un inicio de sesión urgente o una supuesta actualización de seguridad. Quien conoce la situación real cae con menos frecuencia. Ningún redactor cierra la vulnerabilidad técnica, pero un acceso de administrador robado abre la puerta incluso sin vulnerabilidad.
Concienciación en seguridad de los empleados: ¿quién necesita qué?
Una formación para todos con las mismas diapositivas suele errar su objetivo. Es más sensato adaptarla a los roles. El siguiente resumen ayuda en la planificación:
| Rol | Riesgos típicos | Qué debería saber hacer la persona |
|---|---|---|
| Redactor, marketing | correos de phishing, subidas de archivos inseguras, accesos compartidos | comprobar el remitente, subir solo los tipos de archivo esperados, no pasar nunca sus propias credenciales |
| Administrador del CMS | plugins de origen desconocido, demasiadas cuentas de administrador, cuentas antiguas de exempleados | asignar los derechos con moderación, revisar las cuentas con regularidad, instalar extensiones solo con autorización |
| Administrador del servidor | consejos de la red sin verificar, cambios sin registro, archivos de prueba olvidados | valorar las fuentes, documentar los cambios, conocer la vía de emergencia |
| Dirección | presión para decidir rápido, responsabilidades poco claras | fijar las vías de decisión, tomar en serio los avisos, liberar presupuesto para la prevención |
| Agencia externa | accesos compartidos, falta de acuerdos | usar cuentas propias y personales, anunciar los cambios |
La tabla muestra también dónde debe ayudar la técnica. Las cuentas personales en lugar de accesos colectivos y una autenticación de dos factores para todos los que tienen permisos de escritura quitan mucha presión a la formación. Cómo hacerlo se explica en Autenticación de dos factores para los accesos de administración.
Lo que los redactores deben saber sin convertirse en técnicos
Los redactores no tienen que saber qué es un worker de PHP. Pero deberían dominar con seguridad tres cosas. Primera: una petición de volver a iniciar sesión «a causa de un incidente de seguridad» nunca se atiende con el enlace del correo, sino por la vía habitual de acceso al CMS o preguntando al administrador.
Segunda: comunicar las anomalías. Entre ellas están cuentas de usuario desconocidas en la lista de usuarios, páginas o entradas que nadie ha creado, redirecciones repentinas y advertencias en el navegador. Un redactor suele ver el sitio web con más frecuencia que el administrador y nota antes los cambios.
Tercera: tratar las subidas con conciencia. Las imágenes y los PDF son el día a día, pero un archivo con una extensión inusual, un archivo comprimido «para reenviar» o un documento con macros no pertenece al CMS. Si no se puede subir un archivo, suele ser a propósito y no un fallo que haya que sortear.
Lo que los administradores necesitan además
Para los administradores se trata menos de phishing que de criterio bajo presión de tiempo. En la semana de PHP2Shell circularon consejos que los autores especializados rechazan expresamente, como bloquear todas las peticiones con PHPSESSID. Una visión de conjunto de estos caminos equivocados la ofrece el artículo Consejos falsos y peligrosos sobre PHP2Shell. Los buenos administradores comprueban primero la fuente primaria, es decir, php.net, el BSI o el fabricante, antes de cambiar una configuración.
Forma parte de ello la disciplina en los cambios: ¿qué se cambió, cuándo y por qué, y cómo puede revertirse? Basta una breve entrada en el ticket o en la wiki. En caso de emergencia, esta lista vale oro, porque muestra qué cambio procede de usted y cuál no.
Por último, los administradores deberían saber en qué reconocen una posible intrusión y qué no hay que hacer entonces: no borrar con precipitación, no reinstalar de inmediato, sino asegurar y comunicar. Los indicios típicos los resume ¿Estoy ya comprometido?.
En 90 días hacia un equipo web alerta
Un programa no tiene que ser grande para funcionar. Estos pasos han dado buen resultado:
- Aclarar el inventario (semanas 1 a 2): ¿quién tiene qué accesos al CMS, al alojamiento, al dominio y al servidor? Disolver las cuentas colectivas, bloquear las cuentas antiguas.
- Fijar la vía de comunicación (semana 2): una dirección o un canal para «algo me parece raro». Cada aviso se contesta, aunque haya sido inofensivo.
- Primera sesión breve por rol (semanas 3 a 4): 20 minutos, ejemplos del propio CMS, capturas de pantalla de menús reales.
- Introducir la autenticación de dos factores (hasta la semana 6): para todos los que tienen permisos de escritura, con códigos de emergencia en un lugar seguro.
- Correo de prueba y evaluación (semana 8): una campaña de prueba anunciada, sin poner en evidencia a personas concretas. Se evalúa si se comunicó, no quién hizo clic.
- Segunda sesión sobre un caso de actualidad (semanas 10 a 12): por ejemplo, una situación de seguridad actual, escenificada en el propio sistema.
Mida el éxito por los avisos, no por las tasas de clics. Un equipo que comunica mucho está alerta. Un equipo que nunca comunica es o perfecto o inseguro, y lo primero es raro.
¿Cómo ayuda PHP SOS en concreto?
- Registramos con usted quién tiene qué accesos y mostramos cuentas colectivas, administradores sobrantes y accesos olvidados.
- Impartimos sesiones breves por rol de forma remota, con ejemplos de su CMS y de su entorno de servidores.
- Configuramos con usted la vía de comunicación y valoramos los avisos de sospecha que lleguen, si lo desea.
- En el marco de un contrato de mantenimiento de seguridad repetimos las sesiones con motivo de casos de actualidad y revisamos las cuentas con regularidad.
Conclusión
La concienciación en seguridad en el equipo web no nace del miedo, sino de la claridad: cada uno conoce su rol, sus riesgos típicos y el camino para comunicar anomalías. Combinada con cuentas personales y autenticación de dos factores, es una protección que resiste también en la próxima semana de crisis.
Preguntas frecuentes
¿Necesitan los redactores una formación en seguridad?
Sí. Los redactores tienen acceso al CMS, suben archivos y reciben correos que parecen mensajes del sistema. No tienen que entender la técnica, pero sí reconocer cuándo algo es inusual y saber a quién comunicarlo.
¿Con qué frecuencia debe formarse al equipo web?
Mejor breve y con regularidad que una vez al año y largo. Han dado buen resultado sesiones de 15 a 20 minutos con unas semanas de separación, complementadas con una ocasión como una situación de seguridad de actualidad.
¿Qué hacer si un empleado ha hecho clic en un enlace de phishing?
Que lo comunique de inmediato, sin reproches. Después, cambiar la contraseña afectada, cerrar las sesiones activas y comprobar si se ha modificado algo con la cuenta. Cuanto antes llegue el aviso, menor suele ser el daño.
¿Sustituye una formación a las medidas técnicas de protección?
No. Formación y técnica se complementan. La autenticación de dos factores, los roles separados y el software actualizado absorben errores que también cometen personas bien formadas.