Ciberseguridad para equipos en 2026: los controles que de verdad importan

¿Por qué fallan siempre los mismos fundamentos?

Porque la mayoría de equipos implanta la etiqueta, no el control. Tienen MFA, pero del tipo que se puede phishear. Parchean, pero con una cadencia mensual que ignora qué fallos se están explotando de verdad. Tienen copias de seguridad que nadie ha restaurado nunca. En ese hueco entre «lo tenemos» y «funciona» es donde vive casi cualquier incidente.

Esto no es una lista de todo lo que podrías hacer. Es una lista corta de lo que cambia el resultado, con el modo de fallo concreto de cada control y lo que recomienda la guía publicada. Cuando una afirmación viene de un estándar, cito el estándar para que puedas comprobarlo en vez de creerme.

¿Qué controles conviene abordar primero?

Ordenados por lo que evitan en relación con lo que cuestan. Si este trimestre solo llegas a los tres primeros, habrás avanzado más que un equipo que empezó todo a la vez y no terminó nada:

Fíjate en lo que no está: la formación anual de concienciación como control principal, la compra de antivirus, y las políticas de rotación de contraseñas. La primera tiene evidencia débil por sí sola, la segunda se da por supuesta, y la tercera está hoy expresamente desaconsejada —más abajo lo vemos.

¿Por qué casi todo el MFA sigue siendo phisheable?

Es el control peor entendido de la lista, así que conviene ser preciso. «MFA» no es una sola cosa, y los tipos habituales no sobreviven a un ataque de phishing competente.

Un kit de phishing con adversario en medio no roba tu código para usarlo después. Hace de intermediario en tiempo real: tú escribes la contraseña en el servidor del atacante, él la reenvía al sitio real, el sitio real pide el código de un solo uso, el atacante te traslada la petición, tú lo escribes y él lo reenvía. Acto seguido captura la cookie de sesión que emite el sitio legítimo. Tu segundo factor funcionó perfectamente y no sirvió de nada: el atacante ya tiene una sesión autenticada válida.

La razón de que FIDO2 aguante es estructural, no de grado: durante el registro el autenticador liga el par de claves al origen del sitio, y solo firmará un desafío para ese origen. Un sitio de phishing en otro dominio no puede obtener una firma válida, porque el navegador ni siquiera le pedirá al autenticador que la produzca. No hay código que el usuario pueda ser engañado para retransmitir, así que su atención deja de ser el control.

Sobre las contraseñas en sí, NIST SP 800-63B cambió la recomendación hace años y muchas políticas siguen sin enterarse: deja de forzar la rotación periódica, deja de exigir reglas de composición, y en su lugar comprueba las contraseñas nuevas contra listas de credenciales filtradas. La rotación forzada produce patrones predecibles, que es justo lo contrario del objetivo.

¿Cómo parcheas cuando no puedes parchearlo todo?

No puedes parchearlo todo, y tratar cada CVE como igual de urgente garantiza que los importantes se pierdan en la cola. Las puntuaciones de severidad describen lo malo que podría ser un fallo en teoría; no dicen nada sobre si alguien lo está explotando.

La solución práctica es dejar que mande la explotación observada. CISA mantiene el catálogo de vulnerabilidades explotadas conocidas, una lista pública de fallos confirmados como explotados de forma activa. Es gratuita, legible por máquina y una señal de priorización mucho mejor que la severidad por sí sola.

1. 1Lo primero, cualquier cosa del catálogo KEV que afecte a un sistema expuesto a Internet. Es la categoría con la que se compromete a organizaciones enteras a escala.
2. 2Después, cualquier sistema expuesto con exploit público: dispositivos de borde, concentradores VPN, pasarelas de correo, todo lo que sea accesible sin autenticar.
3. 3Todo lo demás, con una cadencia previsible, asumiendo que irá por detrás.

El segundo punto merece énfasis. Los dispositivos de borde resultan atractivos de forma sistemática porque están expuestos por definición, suelen ejecutar firmware del fabricante que nadie inventaría, y a menudo quedan fuera del proceso de parcheo que sí cubre portátiles y servidores. Si no sabes qué cosas tuyas son accesibles desde Internet, ese inventario es el requisito previo a todo lo demás de esta página.

¿Qué hace que una copia de seguridad sobreviva al ransomware?

La convención 3-2-1 —tres copias, dos soportes, una fuera— sigue siendo una base razonable, pero el ransomware cambió qué parte importa. Los operadores actuales buscan las copias de seguridad antes de cifrar, precisamente porque destruirlas es lo que hace probable el pago.

Así que la propiedad que cuenta no es estar fuera. Es si la copia puede alcanzarse y destruirse usando credenciales que existen en la red de producción. Si tu servidor de copias está unido al dominio y la cuenta de respaldo es una cuenta de dominio corriente, un atacante con administrador de dominio ya es dueño de tu plan de recuperación.

• Al menos una copia desconectada o inmutable: almacenamiento de escritura única, bloqueo de objetos, o soporte realmente desconectado.
• Credenciales de respaldo separadas de la identidad de producción: ni el mismo directorio ni el mismo administrador.
• Prueba la restauración, con periodicidad y de principio a fin. Una copia sin probar es una suposición, no un control.
• Mide cuánto tarda de verdad una restauración completa. Los equipos suelen descubrir la cifra real durante el incidente, que es el peor momento posible.
• Respalda lo que nadie recuerda: configuración de identidad, reglas del cortafuegos y la documentación de cómo se reconstruye todo.

¿Qué deberías registrar si solo puedes registrar un poco?

El registro no previene nada. Determina si, después de un incidente, puedes responder a qué se accedió y cuándo, que es la pregunta que harán los reguladores, los clientes y tu propia dirección, y la única que no se puede responder de forma retroactiva.

En Windows, un puñado pequeño de fuentes de eventos concentra casi todo el valor para investigar:

Dos ajustes importan más que la lista. La captura de la línea de comandos en el evento 4688 viene desactivada por defecto y el evento es casi inútil sin ella. Y la retención tiene que superar el tiempo que una intrusión suele pasar inadvertida: si guardas treinta días y la intrusión empezó hace tres meses, la evidencia ha desaparecido antes de que empieces a mirar.

¿Qué haces en la primera hora de un incidente?

El plan no tiene por qué ser elaborado. Tiene que existir antes de necesitarlo y estar escrito en algún sitio al que se pueda llegar cuando la red no esté disponible.

1. 1Contén sin destruir evidencia. Aísla de la red las máquinas afectadas, pero no las apagues: la evidencia que reside en memoria desaparece al hacerlo, y a menudo es el único registro de qué se ejecutó.
2. 2Preserva los registros de inmediato. Expórtalos antes de que roten, antes de que caduque la retención y antes de que un atacante con acceso los borre.
3. 3Ten claro a quién llamar. Asesoría legal, aseguradora y cualquier servicio de respuesta contratado. Esos teléfonos deben estar en papel, no solo en los sistemas que pueden estar caídos.
4. 4Da por comprometida la identidad. Revoca sesiones y rota credenciales de las cuentas afectadas: cambiar la contraseña no invalida por sí solo una cookie de sesión robada.
5. 5Lleva una cronología desde el primer minuto. Reconstruir días después qué hiciste y cuándo es mucho más difícil que apuntarlo sobre la marcha.

Lo que hay que llevarse

• El MFA no es una casilla. Solo FIDO2 o WebAuthn sobreviven a la retransmisión en tiempo real; los códigos y las notificaciones no.
• Que mande la explotación observada al parchear, no la puntuación de severidad ni el calendario. El catálogo KEV de CISA es gratuito y está hecho para esto.
• Una copia de seguridad solo es un control cuando has restaurado desde ella y has medido cuánto tardó.
• Registra autenticación y creación de procesos, activa la captura de línea de comandos y guárdalo el tiempo suficiente.
• Deja escrita la primera hora antes de necesitarla, con teléfonos que funcionen aunque la red no.
• Deja de rotar contraseñas por calendario. NIST dejó de recomendarlo; la práctica produce contraseñas predecibles.

Nada de esto exige un equipo grande ni un presupuesto grande. Exige elegir las pocas cosas correctas y terminarlas. Si quieres construir la parte práctica —reconocer una campaña de phishing, reconstruir lo ocurrido a partir de los registros—, es justo lo que trabajan con laboratorios nuestras rutas de Phishing con OSINT y Threat Hunting.