¿Tu SGSI es real o sólo un adorno?

En el ecosistema de la ciberseguridad para PYMEs, muchas empresas invierten recursos en desplegar un sistema de gestión de seguridad de la información (SGSI) —por ejemplo basado en ISO 27001 o en NIST Cybersecurity Framework— pero muchas veces, obvian detalles relevantes que deberían considerarse en la fase de implantación; uno de ellos, corresponde a la ausencia de pruebas sobre el sistema de forma realista, regular y útil. Y eso es justamente lo que separa a las empresas que “tienen un SGSI” de aquellas que “realmente lo viven”.

La necesidad de probar o testear el SGSI no es un lujo, sino una exigencia operativa:

• Permite verificar que las políticas, los procesos y las tecnologías funcionan no solo “en papel”, sino de verdad.

• Revela debilidades humanas, organizativas y tecnológicas antes de que lo haga un atacante.

• En el contexto de las PYMEs —donde los recursos y el personal suelen estar más ajustados— testear el SGSI puede marcar la diferencia entre una respuesta un poco lenta y una brecha grave.

A continuación exploraremos por qué es clave hacer estas pruebas, qué aspectos conviene testear, y cómo acercarlo de forma realista (sin que sea un ejercicio exclusivo de “cumplimiento” sino además de mejora continua).

¿Por qué deberíamos testear el SGSI?

1. Porque un SGSI sin pruebas es casi un catálogo de buenas intenciones. Puedes tener políticas, procedimientos y controles definidos… pero si nunca ves si funcionan en condiciones reales, estás operando en un “modo optimista”.

2. Porque los atacantes aprovechan la parte humana, no sólo la técnica. Como menciona un estudio de Coalition, los ataques de ingeniería social explotan elementos psicológicos como la confianza, la urgencia o la curiosidad.

3. Porque los resultados de entrenamiento y simulaciones convencionales de phishing muestran limitaciones reales. Por ejemplo, una investigación académica realizada en Estados Unidos, que incluyó más de 19.000 empleados concluyó que los entrenamientos anuales de concienciación no tenían relación significativa con menor clic en campañas simuladas.

4. Porque para las PYMEs en particular, el margen de error es menor: una incidencia grave puede suponer un coste humano y reputacional que amenaza la continuidad del negocio.

¿Qué partes del SGSI son prioritarias para testear?

En general, se debería testear todas las capacidades de ciberseguridad que hacen parte del SGSI; no obstante, teniendo en cuenta que los recursos disponibles dentro de las PYMEs son reducidos, se debería considerar por lo menos lo siguiente:

• Capacidad del usuario final (y del personal operativo) para detectar ataques de tipo phishing: no basta con tener un filtro de correo, también se debe medir cuántos clics hacen los usuarios, cuántos reportan, y qué contexto los hace más vulnerables.

• Pruebas de escenarios de ataque realistas: simulaciones de phishing, vishing (llamadas), smishing (SMS), incluso ataques por redes sociales o mensajería.

• Evaluación del proceso de respuesta: cuando alguien reporta (o alguien cae), ¿qué se hace? ¿Se activa el procedimiento? ¿Se analiza, se mitiga?

• Controles técnicos y organizativos: configuración de perímetro, accesos, privilegios, parches, incidencias… se deben probar con ejercicios de “red team” ligeros (o pruebas de vulnerabilidad) para ver si el sistema realmente detecta y responde.

• Resiliencia continua: no se trata de “una vez al año y ya está”. Como advierte una investigación publicada en WJARR otra revisión, la formación y los tests deben ser periódicos, adaptados al contexto, y evolucionados.

El mercado actual

Hoy en día proliferan plataformas que permiten lanzar campañas de simulación de phishing de forma prácticamente “plug-and-play”. Si bien son útiles, es importante reconocer sus limitaciones cuando el objetivo es una verdadera mejora de la seguridad real:

• Muchas ofrecen métricas (clics, informes, tasas de caída) pero no abordan suficientemente el porqué un usuario hace clic, qué factores psicológicos, contextuales u organizativos están operando.

• Como muestran los estudios de Carnegie Mellon University, la psicología y el contexto importan: por ejemplo, un usuario caerá más o menos según su nivel de reflexión cognitiva, su nivel de carga de tareas, su contexto laboral, y la alineación del mensaje con sus expectativas.

• Si se realizan simulaciones tan frecuentes o tan “visibles”, genera “fatiga de simulación”, lo cual puede reducir la eficacia real del entrenamiento.

• Automatizar sin personalizar puede generar falsas sensaciones de seguridad. Un sistema puede mostrar que “el 97 % de los usuarios no hicieron clic en la campaña X” y eso induce a pensar que estamos bien, cuando en realidad el escenario puede estar ya demasiado familiarizado o trivial.

Por tanto, la solución no está en abandonar las herramientas automatizadas —sino en adaptarlas: combinar simulaciones técnica y psicológicamente sofisticadas, con análisis cualitativo, feedback individualizado y diseño de intervención que tenga en cuenta los factores humanos.

Herramientas prácticas que una PYME puede implementar para testear su SGSI

Aquí van algunas sugerencias concretas y adaptadas a PYMEs

Simulaciones de phishing adaptadas

• Definir varios escenarios (correo ficticio interno, proveedor externo, urgencia de pago, renovación de licencia, etc.).

• Monitorizar no solo los clics, sino qué hacen los usuarios después del clic: ¿lo reportan? ¿lo notifican? ¿hablan con TI?

• Luego, hacer una sesión de feedback con los usuarios que clicaron para entender “por qué lo hicieron”: ¿era un correo que parecía urgente? ¿Estaban bajo presión de tiempo? ¿Confundieron el remitente?

Medir el conocimiento y la capacidad de detección real

• Realizar un breve cuestionario (quiz) previo al test sobre señales de phishing.

• Realizar luego una repetición (no exactamente igual) unos meses después para medir evolución.

• Evaluar si la formación se traduce en comportamiento y no solo en memoria.

Evaluar los incidentes reales como “lecciones”

• Cuando ocurre un incidente (o incluso un “casi incidente”), analizar: cómo entró, cuándo se detectó, qué controles fallaron, qué parte humana se aprovechó.

• Usar este análisis para actualizar simulaciones futuras.

Revisar procesos de detección y respuesta

• ¿Hay procedimiento claro para que un usuario reporte un correo sospechoso?

• ¿Ese procedimiento se prueba? (por ejemplo, se envía un correo simulado que pide respuesta y se mide si el usuario lo reporta o no).

• ¿Una vez reportado, qué pasa? ¿Se mitiga, se documenta, se comunica? Este “circuito de vida” debe testearse.

Incorporar factores humanos y contextuales en la simulación

• No todos los usuarios son iguales: estudios recientes muestran que rasgos de personalidad, contexto laboral, nivel de sobrecarga o distracción influyen en la susceptibilidad.

• Por ejemplo, simular ataques en momentos de carga de trabajo elevada (pero controlados), o tras una notificación interna que capte la atención de los usuarios.

• Introducir feedback cualitativo: tras la simulación, preguntar a los usuarios qué percibieron, qué les llamó la atención, qué no.

Conclusión

Para una PYME que desea no solo tener un SGSI “por libro”, sino que funcione de verdad, testear el sistema es imprescindible. Y dentro de ese testeo, la dimensión humana —y en especial, la capacidad del usuario de detectar y reaccionar ante ataques tipo phishing por cualquier medio— merece un lugar central.

Sin embargo, no basta con una campaña genérica de phishing al año. Diferentes estudios nos alertan de que los programas tradicionales de concienciación pueden no tener el impacto esperado. Por tanto, combinar tecnología, simulaciones inteligentes, enfoque psicológico, contexto realista y reporte-respuesta es la receta para que el “ring” donde el usuario final se convierte en la primera capa de defensa sea más sólido día a día.

En este sentido, la oferta de plataformas automatizadas de phishing es una herramienta útil, pero no la solución completa: cuidar el factor humano, el análisis posterior y adaptar a la realidad de la empresa marca la diferencia.