glosario de términos de ciberseguridad explicado de forma clara, profesional y útil para cualquier usuario. Incluye conceptos básicos, avanzados y actuales (IA, phishing, ransomware, etc.),
Conceptos básicos
Ciberseguridad — Conjunto de medidas para proteger sistemas, redes y datos frente a ataques o accesos no autorizados.
Amenaza — Cualquier evento o acción que puede causar daño a un sistema o información.
Vulnerabilidad — Fallo o debilidad que un atacante puede aprovechar.
Exploit — Código o técnica que aprovecha una vulnerabilidad para atacar un sistema.
Malware — Software malicioso diseñado para dañar, robar o secuestrar información.
🦠 Tipos de malware
Virus — Se adjunta a archivos y se replica al ejecutarlos.
Troyano — Se hace pasar por software legítimo para entrar en el sistema.
Ransomware — Cifra los datos y exige un rescate para recuperarlos.
Spyware — Espía la actividad del usuario y roba información.
Adware — Muestra publicidad no deseada y puede recopilar datos.
Rootkit — Oculta procesos maliciosos para evitar ser detectado.
🎣 Ataques y técnicas de ingeniería social
Phishing — Engaño mediante correos o mensajes para robar datos.
Smishing — Phishing por SMS.
Vishing — Phishing por llamada telefónica.
Spear phishing — Ataque dirigido a una persona concreta.
Baiting — Engaño ofreciendo algo atractivo para que el usuario caiga.
Pretexting — El atacante inventa una historia para obtener información.
🧱 Protección y defensa
Firewall — Barrera que filtra el tráfico entre redes.
Antivirus — Software que detecta y elimina malware.
Autenticación multifactor (MFA) — Verificación con dos o más métodos (contraseña + código SMS + huella).
Cifrado — Técnica que convierte datos en información ilegible sin clave.
VPN — Conexión segura y cifrada entre el usuario y la red.
Backup — Copia de seguridad para recuperar datos en caso de ataque.
🌐 Redes y acceso
IP — Identificador único de un dispositivo en la red.
Proxy — Servidor intermediario entre el usuario y la web.
DNS — Sistema que traduce nombres de dominio a direcciones IP.
DDoS — Ataque que satura un servicio con tráfico masivo.
🧬 Identidad y acceso
Credenciales — Datos que identifican al usuario (usuario + contraseña).
Token — Código temporal para verificar identidad.
Zero Trust — Modelo que no confía en ningún dispositivo por defecto.
🧩 Seguridad en aplicaciones
SQL Injection — Ataque que inserta código malicioso en consultas SQL.
XSS — Inyección de scripts en páginas web.
CSRF — Ataque que fuerza acciones no deseadas en una sesión activa.
API Key — Clave que permite acceder a una API.
🤖 Ciberseguridad e Inteligencia Artificial
Deepfake — Video o audio falso generado con IA.
Botnet — Red de dispositivos infectados controlados por un atacante.
Machine Learning aplicado a seguridad — Sistemas que detectan amenazas analizando patrones.
Resumen visual
Categoría
Conceptos clave
Malware
Virus, troyano, ransomware, spyware
Ingeniería social
Phishing, smishing, vishing
Defensa
Firewall, antivirus, cifrado, MFA
Redes
IP, DNS, VPN, DDoS
Aplicaciones
SQL Injection, XSS, CSRF
IA
Deepfake, botnet
Glosario Avanzado de Ciberseguridad
Ataques avanzados
APT (Advanced Persistent Threat) — Grupo de atacantes altamente cualificados que infiltra una red durante largos periodos sin ser detectado.
Man-in-the-Middle (MITM) — El atacante intercepta comunicaciones entre dos partes para espiar o modificar datos.
SQL Injection — Inserción de código malicioso en consultas SQL para acceder o manipular bases de datos.
XSS (Cross-Site Scripting) — Inyección de scripts en páginas web para robar cookies o secuestrar sesiones.
CSRF (Cross-Site Request Forgery) — Fuerza acciones no deseadas en una sesión autenticada.
Privilege Escalation — Técnica para obtener permisos superiores dentro de un sistema.
Brute Force Attack — Intentos masivos de adivinar contraseñas o claves.
Supply Chain Attack — Ataque a proveedores o software externo para comprometer una organización.
Malware avanzado
Botnet — Red de dispositivos infectados controlados por un atacante.
Worm — Malware que se replica automáticamente sin intervención del usuario.
Keylogger — Registra pulsaciones del teclado para robar credenciales.
Fileless Malware — Malware que opera en memoria sin archivos, difícil de detectar.
RAT (Remote Access Trojan) — Troyano que permite control remoto total del sistema.
Polymorphic Malware — Cambia su código para evitar detección por antivirus.
Arquitecturas y modelos de seguridad
Zero Trust — Modelo donde ningún usuario o dispositivo se considera confiable por defecto.
Defense in Depth — Estrategia basada en múltiples capas de seguridad.
Least Privilege — Cada usuario solo tiene los permisos estrictamente necesarios.
Seguridad perimetral — Protección del borde de la red (firewalls, IDS, etc.).
Microsegmentación — División de la red en segmentos pequeños para limitar movimientos laterales.
Herramientas y tecnologías de defensa
SIEM (Security Information and Event Management) — Plataforma que centraliza logs y detecta incidentes.
SOC (Security Operations Center) — Equipo que monitoriza, detecta y responde a amenazas.
EDR (Endpoint Detection and Response) — Sistema que detecta y responde a amenazas en dispositivos finales.
XDR (Extended Detection and Response) — EDR ampliado a red, nube y aplicaciones.
IDS/IPS — Sistemas de detección y prevención de intrusiones.
Sandboxing — Ejecutar archivos sospechosos en entornos aislados.
DLP (Data Loss Prevention) — Prevención de fuga de datos sensibles.
Criptografía y autenticación
Hash — Función que convierte datos en una cadena irrepetible.
Salting — Añadir datos aleatorios a contraseñas antes de hashearlas.
PKI (Public Key Infrastructure) — Sistema de certificados digitales y claves públicas/privadas.
TLS/SSL — Protocolos que cifran comunicaciones en internet.
OAuth — Sistema de autorización para acceder a recursos sin compartir credenciales.
SAML — Protocolo para autenticación en entornos empresariales.
Seguridad en la nube
IAM (Identity and Access Management) — Gestión de identidades y permisos en la nube.
CSPM (Cloud Security Posture Management) — Herramientas que detectan configuraciones inseguras en la nube.
CASB (Cloud Access Security Broker) — Control de seguridad entre usuarios y servicios cloud.
Shared Responsibility Model — División de responsabilidades entre proveedor cloud y cliente.
Ingeniería social avanzada
Whaling — Phishing dirigido a altos cargos.
Business Email Compromise (BEC) — Suplantación de correos corporativos para fraude.
Social Engineering Toolkit (SET) — Herramienta usada para simular ataques de ingeniería social.
Ciberseguridad e Inteligencia Artificial
Deepfake — Contenido falso generado con IA.
ML-based Threat Detection — Sistemas que detectan amenazas analizando patrones.
Adversarial Attacks — Manipulación de modelos de IA para producir errores.
Automated Reconnaissance — Uso de IA para recopilar información de objetivos.
Resumen visual
Categoría
Conceptos clave
Ataques
APT, MITM, SQLi, XSS, CSRF
Malware
Botnet, fileless, RAT, keylogger
Arquitecturas
Zero Trust, microsegmentación
Defensa
SIEM, SOC, EDR, XDR, DLP
Criptografía
Hash, PKI, TLS, OAuth
Nube
IAM, CSPM, CASB
IA
Deepfake, adversarial attacks
Glosario SOC / Blue Team Avanzado
Conceptos clave del SOC
SOC (Security Operations Center) — Centro donde se monitoriza, detecta y responde a incidentes de seguridad.
NOC (Network Operations Center) — Centro que gestiona la infraestructura de red; trabaja junto al SOC.
Playbook — Procedimiento detallado para responder a un tipo de incidente.
Runbook — Guía técnica paso a paso para ejecutar tareas operativas.
Shift Handover — Proceso de transferencia de información entre turnos del SOC.
Detección y análisis
SIEM (Security Information and Event Management) — Plataforma que centraliza logs y genera alertas.
UEBA (User and Entity Behavior Analytics) — Detecta anomalías en el comportamiento de usuarios o sistemas.
Correlation Rule — Regla que combina eventos para detectar patrones sospechosos.
False Positive — Alerta que parece maliciosa pero no lo es.
False Negative — Amenaza real que no fue detectada.
Log Enrichment — Añadir contexto a los logs (geolocalización, reputación IP, etc.).
Threat Intelligence
Threat Intelligence — Información sobre amenazas, actores y técnicas.
IOC (Indicator of Compromise) — Señal de que un sistema puede estar comprometido (IP, hash, dominio).
IOA (Indicator of Attack) — Señal de que un ataque está en curso (comportamientos, patrones).
TTP (Tactics, Techniques and Procedures) — Forma de operar de un atacante.
Kill Chain — Modelo que describe las fases de un ataque.
MITRE ATT&CK — Marco que clasifica técnicas de ataque usadas por adversarios.
Defensa en endpoints
EDR (Endpoint Detection and Response) — Detecta y responde a amenazas en dispositivos.
XDR (Extended Detection and Response) — EDR ampliado a red, nube y aplicaciones.
Hardening — Reducir la superficie de ataque mediante configuración segura.
Application Whitelisting — Solo se permite ejecutar software autorizado.
Memory Forensics — Análisis de la memoria RAM para detectar malware avanzado.
Defensa en red
IDS/IPS — Detecta y bloquea intrusiones en la red.
Network Segmentation — Dividir la red para limitar movimientos laterales.
Lateral Movement — Movimiento del atacante entre sistemas dentro de la red.
Beaconing — Comunicación periódica de malware con su servidor de mando.
Command and Control (C2) — Infraestructura usada por atacantes para controlar malware.
Respuesta a incidentes
Incident Response (IR) — Proceso para gestionar y contener incidentes.
Containment — Aislar sistemas afectados para evitar propagación.
Eradication — Eliminar malware o accesos no autorizados.
Recovery — Restaurar sistemas a su estado normal.
Post-Incident Review — Análisis posterior para mejorar defensas.
Análisis forense
Digital Forensics — Investigación técnica de incidentes.
Chain of Custody — Documentación del manejo de evidencias.
Timeline Analysis — Reconstrucción cronológica de eventos.
Disk Imaging — Copia exacta de un disco para análisis.
Volatility — Herramienta para análisis de memoria RAM.
Seguridad en la nube (Blue Team Cloud)
CSPM — Detecta configuraciones inseguras en la nube.
CWPP — Protección de cargas de trabajo en la nube.
IAM — Gestión de identidades y permisos.
Secret Scanning — Detección de claves expuestas en repositorios.
Cloud Forensics — Investigación de incidentes en entornos cloud.
Un script en una página HTML es un bloque de código, normalmente JavaScript, que añade comportamiento dinámico al documento estático. Se inserta mediante la etiqueta <script> y puede estar embebido en el propio HTML o vinculado a un archivo externo. Su presencia transforma la página: desde validar formularios y manejar eventos hasta modificar el DOM en tiempo real y comunicarse con servidores.
Integración y ubicación
Los scripts pueden colocarse en el <head> para ejecutarse antes de que se renderice el contenido, o al final del <body> para no bloquear la carga visual. También pueden cargarse de forma asíncrona o diferida usando los atributos async y defer, lo que mejora la experiencia de carga. Un script externo se referencia con src y facilita la reutilización y el mantenimiento entre páginas.
Carga y rendimiento
El comportamiento de carga de un script afecta directamente al rendimiento. Bloqueo de renderizado ocurre cuando un script se ejecuta mientras el navegador construye la página; por eso es habitual usar defer para ejecutar después del parseo del HTML o async para ejecutar tan pronto como se descarga. Los scripts pueden agruparse, minificarse y servirse desde CDN para reducir latencia y mejorar tiempos de respuesta.
Interacción con el DOM y eventos
Un script puede leer, crear, modificar y eliminar nodos del DOM, cambiar estilos, insertar contenido y responder a eventos del usuario como clics, desplazamientos y teclas. Gracias a los manejadores de eventos y a la delegación de eventos, un único script puede controlar interacciones complejas en toda la página sin necesidad de múltiples fragmentos de código.
Comunicación y capacidades avanzadas
Los scripts permiten comunicación con servidores mediante AJAX o fetch, habilitando carga dinámica de datos, formularios sin recarga y APIs REST. También pueden usar WebSockets para comunicación en tiempo real, Service Workers para caching y funcionamiento offline, Web Workers para procesamiento en segundo plano, y APIs modernas como Geolocation, WebRTC o WebGL para multimedia y gráficos avanzados.
Seguridad y buenas prácticas
Los scripts introducen riesgos si no se gestionan correctamente. Es esencial evitar inyección de código y XSS sanitizando entradas, usar políticas de seguridad de contenido (CSP), y limitar permisos de terceros. Las buenas prácticas incluyen modularizar el código, usar control de versiones, escribir pruebas, manejar errores y excepciones, y aplicar técnicas de optimización como lazy loading y debouncing para eventos frecuentes.
Qué puede desarrollar un script en una web
Con un script bien diseñado se pueden crear interfaces interactivas completas: menús dinámicos, galerías y sliders, formularios inteligentes con validación en tiempo real, paneles de administración, dashboards con gráficos en vivo, aplicaciones de una sola página (SPA), experiencias offline, notificaciones push, editores en el navegador, y funcionalidades colaborativas en tiempo real. En resumen, convierte una página estática en una aplicación web rica y responsiva capaz de integrar servicios externos y ofrecer experiencias de usuario modernas.
Tipos de Scripts
Los scripts en páginas web se clasifican según dónde se ejecutan, cómo se cargan y qué propósito tienen; los tipos más relevantes son client‑side, server‑side, módulos, inline vs externo, workers y scripts especiales como import maps o JSON‑LD.
Tipos según lugar de ejecución
Client‑side (lado cliente): JavaScript que se ejecuta en el navegador para manejar DOM, eventos, animaciones y llamadas AJAX/fetch. Es el tipo más común en páginas interactivas.
Server‑side (lado servidor): Scripts que se ejecutan en el servidor (Node.js, PHP, Python, Ruby, etc.) y generan HTML o APIs que el cliente consume; no se envían al navegador. Permiten lógica segura, acceso a bases de datos y renderizado dinámico.
Tipos según forma y carga
Inline vs externo:Inline está embebido dentro de <script> en el HTML; externo se referencia con src. Los externos facilitan reutilización y caché. Atributos como async y defer controlan cuándo se ejecutan para mejorar rendimiento.
Classic vs module: Los classic scripts son el comportamiento tradicional; los módulos (<script type="module">) permiten import/export, scope por módulo y carga diferida por defecto. También existen import maps para controlar resolución de módulos.
Tipos por propósito o API
Service Workers y Web Workers:Web Workers ejecutan tareas en segundo plano para evitar bloquear la UI; Service Workers gestionan cache, offline y push notifications, actuando como proxy entre la web y la red.
Scripts de datos y metadatos: JSON‑LD y otros bloques <script type="application/ld+json"> contienen datos estructurados para motores de búsqueda; no se ejecutan como código.
Third‑party / analytics / ads: Scripts externos de terceros (analytics, trackers, widgets) que añaden funcionalidades pero implican riesgos de rendimiento y privacidad; conviene cargarlos de forma asíncrona y con políticas CSP.
Consideraciones prácticas
Rendimiento: usar defer/async, minificar y servir desde CDN reduce bloqueo de renderizado.
Seguridad: sanitizar entradas y aplicar CSP para prevenir XSS; limitar permisos de terceros.
Mantenibilidad: preferir módulos y archivos externos para código organizado y testeable.
Conclusión práctica
Para una web moderna conviene combinar módulos para lógica propia, Service Workers para offline, Web Workers para cálculos pesados y scripts externos asíncronos para terceros; siempre optimizando carga y aplicando medidas de seguridad.
Scripts más solicitados
Scripts de interacción y funcionalidad
Son los más populares porque mejoran la experiencia del visitante:
Validación de formularios: comprobar campos antes de enviar datos.
Menús desplegables y sticky: navegación fluida y moderna.
Carruseles o sliders: mostrar imágenes o testimonios de forma dinámica.
Scroll suave y animaciones: efectos visuales al desplazarse por la página.
Scripts de automatización y lógica
Muy usados por desarrolladores y empresas:
Scripts de carga diferida (lazy load) para optimizar rendimiento.
Scripts de seguimiento y analítica como Google Analytics o Pixel.
Scripts de integración con APIs para conectar servicios externos.
Scripts de seguridad y control
Solicitados en sitios con formularios o áreas privadas:
Protección contra spam (reCAPTCHA, honeypots).
Gestión de sesiones y cookies.
Encriptación básica de datos.
Un script embebido es un fragmento de código que se inserta directamente dentro del documento HTML, en lugar de estar en un archivo externo. Se coloca entre las etiquetas <script> y </script> y el navegador lo interpreta al cargar la página.
Por ejemplo:
html
<script>
alert("Bienvenido a mi sitio web");
</script>
Este código se ejecuta inmediatamente cuando el navegador procesa el HTML. Los scripts embebidos son útiles para tareas pequeñas o específicas, como inicializar variables, ejecutar funciones simples o probar comportamientos rápidos sin necesidad de crear archivos adicionales.
🔍 Características principales
Ubicación: dentro del propio archivo HTML, normalmente en el <head> o al final del <body>.
Ejecución inmediata: se interpreta en el momento en que el navegador lee el documento.
Acceso directo al DOM: puede manipular elementos del HTML sin necesidad de importar nada.
Mantenimiento limitado: si el código crece, es mejor moverlo a un archivo externo para facilitar la gestión y el rendimiento.
En resumen, un script embebido es la forma más directa de añadir lógica o interactividad a una página web sin depender de archivos externos.
NCIBE‑CERT es el Centro de Respuesta a Incidentes de Seguridad para ciudadanos y entidades privadas.
Es el CERT/CSIRT nacional encargado de prevenir, detectar y gestionar incidentes de ciberseguridad que afecten a usuarios, empresas y organizaciones privadas.
Un ciudadano o una empresa privada en España puede reportar un incidente de ciberseguridad siguiendo un proceso muy claro. INCIBE‑CERT actúa como el centro nacional que recibe, analiza y ayuda a gestionar estos incidentes cuando afectan a particulares o entidades privadas.
Qué tipo de incidentes se deben reportar
Los incidentes que se comunican a INCIBE‑CERT son aquellos que afectan a la seguridad de sistemas, datos o servicios digitales. Incluyen, entre otros:
Ataques de malware, como ransomware, troyanos o infecciones masivas.
Phishing o suplantación, tanto por correo como por SMS o web falsa.
Robo de credenciales o accesos no autorizados a cuentas.
Intrusiones en servidores, páginas web o redes internas.
Fugas o exposición de datos personales o corporativos.
Fraudes online, estafas de pago, compras fraudulentas o secuestro de cuentas.
Denegación de servicio (DDoS) que afecte a la actividad de una empresa.
Vulnerabilidades críticas detectadas en sistemas propios.
En resumen, cualquier incidente que comprometa confidencialidad, integridad o disponibilidad de la información debe ser reportado.
Cómo debe actuar un ciudadano
Un ciudadano que detecta un incidente debe recopilar la información básica: qué ha ocurrido, cuándo, qué dispositivo o cuenta está afectado y si hay capturas o pruebas. Después, debe contactar con el servicio de asistencia en ciberseguridad para ciudadanos, que ofrece orientación técnica, pasos de mitigación y, si es necesario, escalado al equipo de respuesta.
El ciudadano no necesita conocimientos técnicos avanzados. Basta con describir el problema con claridad. El equipo le indicará cómo proteger sus dispositivos, recuperar cuentas, bloquear accesos o denunciar si procede. También pueden guiarle para conservar evidencias en caso de fraude.
Cómo debe actuar una empresa privada
Una empresa debe actuar con más método. Lo primero es contener el incidente: aislar equipos afectados, cambiar contraseñas críticas, detener servicios comprometidos y evitar que el ataque se propague. Después, debe documentar el incidente: logs, direcciones IP, archivos sospechosos, fechas y cualquier indicio técnico.
Una vez recopilada la información, la empresa debe contactar con el equipo especializado de INCIBE‑CERT para empresas. Allí pueden analizar muestras de malware, revisar indicadores de compromiso, ayudar a evaluar el impacto y coordinar la respuesta si el incidente afecta a terceros. También pueden asesorar sobre notificaciones obligatorias, como las previstas en el Reglamento General de Protección de Datos (RGPD) o la Directiva NIS2.
Qué ocurre después de reportar
Tras recibir el aviso, INCIBE‑CERT analiza la información, determina la gravedad y ofrece recomendaciones técnicas personalizadas. Si el incidente es grave o afecta a más organizaciones, pueden coordinarse con otros CERT nacionales e internacionales. En casos de fraude o delito, orientan sobre cómo proceder con la denuncia ante las autoridades competentes.
Como conservar evidencias digitales
Conservar evidencias digitales es fundamental para que un incidente de ciberseguridad pueda investigarse correctamente, ya sea por un equipo técnico, por INCIBE‑CERT o por las fuerzas de seguridad. La regla de oro es no alterar nada y documentar cada acción que se realiza.
Preservar el dispositivo tal y como está
Lo primero es evitar manipular el equipo afectado. No se deben borrar archivos, cerrar ventanas, desinstalar programas ni reiniciar el sistema salvo que sea imprescindible. Cada acción puede modificar registros, fechas o rastros que son esenciales para reconstruir el incidente. Si el ataque está activo, lo adecuado es desconectar el dispositivo de Internet (cable o Wi‑Fi) sin apagarlo, para evitar que el atacante siga actuando pero sin destruir información en memoria.
Guardar capturas, mensajes y pantallas relevantes
En incidentes como phishing, estafas o accesos indebidos, las capturas de pantalla son una evidencia muy valiosa. Deben incluir la URL completa, el remitente del correo, la hora y cualquier detalle visible. También es importante conservar los mensajes originales sin modificarlos, ya que contienen metadatos que pueden ser analizados posteriormente.
Conservar archivos sospechosos y correos completos
Si se ha recibido un archivo malicioso o un correo fraudulento, debe guardarse sin abrirlo y sin modificar su contenido. En el caso de correos electrónicos, lo ideal es exportarlos en formato completo (con cabeceras), ya que estas contienen información sobre servidores, rutas y autenticación. Nunca se deben reenviar directamente, porque eso altera los metadatos.
Registrar fechas, horas y acciones realizadas
Es recomendable anotar en un documento aparte todo lo que se ha observado: cuándo empezó el problema, qué síntomas aparecieron, qué usuarios estaban conectados y qué acciones se realizaron antes y después del incidente. Esta cronología ayuda a los analistas a entender el alcance y la evolución del ataque.
Guardar logs y registros del sistema
En empresas, los logs de servidores, firewalls, routers y aplicaciones son esenciales. Deben copiarse de forma íntegra y almacenarse en un medio seguro. Si es posible, se recomienda hacer una copia forense del sistema afectado, pero sin herramientas improvisadas: lo ideal es que lo haga personal especializado o bajo indicación de un CERT.
Evitar sobrescribir información
No se deben instalar programas nuevos en el equipo afectado, ni copiar archivos dentro de él, ni ejecutar herramientas de limpieza. Cualquier escritura en disco puede destruir rastros importantes. Si se necesita analizar el equipo, lo adecuado es hacerlo desde un entorno externo o mediante una copia de la unidad.
Almacenar las evidencias en un soporte seguro
Las evidencias deben guardarse en un medio externo (USB, disco duro, almacenamiento cifrado) y protegerse con contraseña. También es recomendable hacer una segunda copia por si el soporte falla. En empresas, estas copias deben custodiarse siguiendo la política interna de seguridad.
No compartir las evidencias por canales inseguros
Nunca deben enviarse archivos sospechosos por correo normal o mensajería. Si se necesita compartirlos con un equipo técnico o con INCIBE‑CERT, se hará mediante los canales seguros que ellos indiquen. Esto evita que el malware se propague o que la información sensible quede expuesta.
Documentar incidente para INCIBE CERT
Documentar correctamente un incidente para INCIBE‑CERT es clave para que puedan analizarlo, determinar su gravedad y ayudarte con una respuesta técnica adecuada. La documentación debe ser clara, ordenada y basada en hechos, sin interpretaciones ni suposiciones.
Descripción clara del incidente
Lo primero es redactar un relato breve y objetivo de lo ocurrido: qué se ha detectado, cuándo empezó, qué síntomas aparecieron y qué sistemas parecen afectados. No hace falta entrar en detalles técnicos complejos, pero sí explicar el contexto: si se trata de un correo sospechoso, un cifrado de archivos, un acceso no autorizado o un comportamiento anómalo en la red. Esta descripción inicial permite a INCIBE‑CERT entender el tipo de amenaza y priorizar la respuesta.
Cronología detallada de los hechos
Es fundamental elaborar una línea temporal con fechas y horas aproximadas. Debe incluir cuándo se detectó el incidente, cuándo se observaron los primeros síntomas, qué acciones se realizaron antes y después, y si hubo cambios relevantes en la infraestructura. Esta cronología ayuda a reconstruir el ataque y a identificar el vector de entrada o la propagación.
Evidencias técnicas preservadas
La empresa debe adjuntar las evidencias sin modificarlas: archivos sospechosos, correos electrónicos completos con cabeceras, notas de rescate, logs de servidores, registros de firewall, eventos del sistema y cualquier archivo cifrado o afectado. También es útil incluir capturas de pantalla que muestren mensajes de error, ventanas emergentes o comportamientos anómalos. INCIBE‑CERT analiza estas evidencias para identificar el malware, los indicadores de compromiso y el alcance real del incidente.
Información del entorno afectado
Es importante describir el entorno técnico donde ha ocurrido el incidente: tipo de sistema operativo, versión, si el equipo está en dominio, si se trata de un servidor o un puesto de trabajo, qué aplicaciones estaban en uso y si existen copias de seguridad disponibles. Esta información permite orientar las recomendaciones de recuperación y evaluar el riesgo para otros sistemas.
Acciones realizadas hasta el momento
La empresa debe indicar qué medidas se han tomado desde la detección del incidente: aislamiento de equipos, desconexión de la red, cambios de contraseñas, detención de servicios o restauración de copias. INCIBE‑CERT necesita saber qué se ha hecho para evitar duplicar esfuerzos o generar efectos no deseados. También es importante aclarar si se ha contactado con otros organismos, como la AEPD o las fuerzas de seguridad.
Impacto conocido o estimado
Debe incluirse una valoración del impacto: qué sistemas están fuera de servicio, si hay datos cifrados o filtrados, si la actividad de la empresa está afectada y si existen riesgos para clientes o proveedores. No es necesario tener una estimación económica precisa, pero sí explicar el alcance operativo del incidente.
Datos de contacto del responsable
Finalmente, es esencial proporcionar los datos de la persona que coordina la gestión del incidente dentro de la empresa: nombre, cargo, correo y teléfono. INCIBE‑CERT suele necesitar aclaraciones rápidas, por lo que contar con un interlocutor único agiliza el análisis y la respuesta.
Checklist para enviar un incidente a INCIBE‑CERT
1. Descripción del incidente
Antes de nada, redacta un párrafo breve explicando qué ha ocurrido: qué se ha detectado, cuándo empezó, qué síntomas aparecieron y qué sistemas parecen afectados. Debe ser una descripción objetiva, sin interpretaciones. Esto permite a INCIBE‑CERT entender rápidamente el tipo de amenaza.
2. Cronología detallada
Elabora una línea temporal con fechas y horas aproximadas. Incluye cuándo se detectó el incidente, cuándo aparecieron los primeros síntomas, qué acciones se realizaron y si hubo cambios previos en la infraestructura. Esta cronología es esencial para reconstruir el ataque.
3. Evidencias técnicas preservadas
Reúne todos los elementos relevantes sin modificarlos: archivos sospechosos, correos completos con cabeceras, notas de rescate, logs de servidores, registros de firewall y capturas de pantalla. Estas evidencias permiten identificar el malware, los indicadores de compromiso y el alcance del incidente.
4. Información del entorno afectado
Describe el entorno técnico donde ocurrió el incidente: sistema operativo, versión, si el equipo está en dominio, si es un servidor o un puesto de trabajo, qué aplicaciones estaban en uso y si existen copias de seguridad disponibles. Esta información ayuda a orientar las recomendaciones de recuperación.
5. Acciones realizadas
Indica qué medidas se han tomado desde la detección del incidente: aislamiento de equipos, desconexión de la red, cambios de contraseñas, detención de servicios o restauración de copias. INCIBE‑CERT necesita saber qué se ha hecho para evitar duplicar esfuerzos o generar efectos no deseados.
6. Impacto conocido o estimado
Incluye una valoración del impacto: qué sistemas están fuera de servicio, si hay datos cifrados o filtrados, si la actividad de la empresa está afectada y si existen riesgos para clientes o proveedores. No hace falta una estimación económica precisa, pero sí explicar el alcance operativo.
7. Datos de contacto del responsable
Proporciona los datos de la persona que coordina la gestión del incidente dentro de la empresa: nombre, cargo, correo y teléfono. INCIBE‑CERT suele necesitar aclaraciones rápidas, por lo que contar con un interlocutor único agiliza el análisis y la respuesta.
Mythos es un sistema de inteligencia artificial aplicada a la ciberseguridad diseñado para detectar, analizar y responder a amenazas digitales en tiempo real. Su arquitectura combina modelos de aprendizaje automático, análisis semántico y monitorización de comportamiento para anticipar ataques antes de que se produzcan.
El Núcleo de IA adaptativa es el corazón de Mythos: la parte que aprende, evoluciona y modifica su comportamiento defensivo según las amenazas reales que observa en la red. No es un módulo estático, sino un sistema vivo que reescribe sus propias reglas en función del contexto.
Qué es exactamente el Núcleo de IA adaptativa
Es un motor de inteligencia que combina tres capacidades:
Aprendizaje continuo — analiza patrones de tráfico, procesos, usuarios y eventos para detectar cambios sutiles.
Modelado de comportamiento — crea perfiles dinámicos de “normalidad” para cada sistema, usuario o servicio.
Reacción autónoma — ejecuta acciones defensivas sin intervención humana cuando detecta riesgo real.
Por qué se llama “adaptativa”
Porque no usa reglas fijas. Cada vez que detecta un patrón nuevo, lo incorpora a su modelo. Si un atacante cambia de táctica, Mythos cambia también.
Ejemplo realista:
Día 1: detecta un patrón de escaneo lento.
Día 2: el atacante cambia a un escaneo distribuido.
Mythos correlaciona ambos comportamientos y los identifica como la misma amenaza, aunque sean distintos técnicamente.
Módulo de Simulación de Amenazas
El Módulo de simulación de amenazas en Mythos es la parte del sistema que se dedica a imaginar, recrear y probar ataques posibles antes de que ocurran en producción. Es, literalmente, un “campo de pruebas” de IA para ciberataques, tanto ofensivos como defensivos.
1. Objetivo del módulo
Anticipar vulnerabilidades: descubrir puntos débiles en infraestructuras, aplicaciones y configuraciones.
Probar defensas: verificar si las medidas de seguridad actuales resisten ataques modernos y combinados.
Generar inteligencia accionable: producir informes y métricas que se integran con el resto de Mythos (núcleo adaptativo, respuesta autónoma, etc.).
2. Qué hace en la práctica
Simula ataques automatizados
Escaneos de puertos, fuzzing de servicios, explotación de fallos conocidos y desconocidos.
Pruebas de intrusión sobre código, APIs, redes internas y externas.
Modela campañas complejas
Ataques en varias fases: reconocimiento → explotación → movimiento lateral → exfiltración.
Escenarios coordinados (por ejemplo, combinación de phishing + explotación de VPN + ransomware).
Los resultados de las simulaciones se usan como “entrenamiento” para que el núcleo aprenda patrones de ataque antes de verlos en el mundo real. También permite definir y probar playbooks automáticos: qué hacer si se detecta un patrón similar al de una simulación (aislar, bloquear, revertir, etc.).
Interfaz de respuesta autónoma
La Interfaz de respuesta autónoma es la parte de Mythos que toma decisiones defensivas sin intervención humana, ejecutando acciones inmediatas cuando detecta una amenaza real. Es el “músculo” del sistema: donde el núcleo adaptativo piensa, esta interfaz actúa.
Mythos Evalúa el riesgo calculado por el núcleo adaptativo y determina la acción adecuada. Ejemplo: “Este patrón coincide con un ransomware en fase inicial → bloquear ejecución + aislar endpoint”.
En ese sentido, también comprueba que la acción se ejecutó correctamente y monitoriza si la amenaza persiste.
En ataques como ransomware, donde cada segundo cuenta, esta interfaz marca la diferencia entre un incidente menor y una catástrofe.
Tipos de respuestas que puede ejecutar
Aquí tienes una tabla clara:
Acción autónoma
Descripción
Aislamiento de red
Desconecta un equipo o servicio del resto de la red.
Bloqueo de IP o dominio
Corta tráfico hacia/desde fuentes maliciosas.
Rollback de archivos
Restaura versiones previas de archivos alterados.
Detención de procesos
Mata procesos que coinciden con patrones de malware.
Activación de modo seguro
Reduce privilegios y congela configuraciones críticas.
Enfoque de inteligencia
Mythos no se limita a reaccionar: aprende del contexto. Su IA semántica interpreta relaciones entre eventos, usuarios y sistemas, construyendo un “mapa narrativo” de la infraestructura digital. Por eso se le llama “Mythos”: crea una historia coherente de cada amenaza, desde su origen hasta su impacto.
Aplicaciones prácticas
Seguridad en infraestructuras críticas (energía, transporte, defensa).
Protección de entornos corporativos distribuidos.
Integración con sistemas SIEM y firewalls inteligentes.
Uso en laboratorios de análisis forense digital.
Análisis de los Riesgos ante un uso no controlado de Mythos
Riesgo de escalada automática
La interfaz de respuesta autónoma puede:
aislar redes
bloquear tráfico
detener procesos críticos
Si un falso positivo ocurre en una infraestructura crítica (energía, transporte, sanidad), el daño sería real. Europa es extremadamente sensible a este tipo de riesgos.
Riesgo de uso ofensivo
El módulo de simulación de amenazas puede, en manos equivocadas:
generar ataques avanzados
automatizar campañas maliciosas
descubrir vulnerabilidades antes que los defensores
Es una herramienta dual: defiende, pero también podría atacar.
Europa regula muy estrictamente las tecnologías de doble uso.
Riesgo regulatorio
Europa tiene el AI Act, que exige transparencia, trazabilidad y control humano. Un sistema como Mythos:
toma decisiones autónomas
ejecuta acciones defensivas sin supervisión
modifica su propio comportamiento
Eso lo coloca en la categoría de alto riesgo. Si no se adapta a la normativa, puede ser ilegal o quedar fuera del mercado europeo.
Riesgo de escalada automática
La interfaz de respuesta autónoma puede:
aislar redes
bloquear tráfico
detener procesos críticos
Si un falso positivo ocurre en una infraestructura crítica (energía, transporte, sanidad), el daño sería real. Europa es extremadamente sensible a este tipo de riesgos.
¿Y cuáles son los beneficios para Europa?
Para ser justo, también tiene ventajas enormes:
refuerza la defensa de infraestructuras críticas
reduce dependencia de analistas humanos
detecta ataques avanzados antes de que ocurran
crea resiliencia frente a amenazas globales
El problema no es Mythos. El problema es cómo se integra en el marco europeo.
Un sitemap XML ayuda a los buscadores a descubrir las URL de un sitio web. Con este analizador de sitemaps online y gratuito puedes consultar las direcciones incluidas en el archivo, identificar sub-sitemaps y revisar las fechas de modificación declaradas, sin instalar programas.
La herramienta está pensada para propietarios de páginas web, administradores de WordPress y personas que desean comprobar la estructura de su sitemap. Su funcionamiento depende de que el servidor permita al navegador leer el archivo XML.
¿Qué es un sitemap XML?
Un sitemap XML es un archivo que enumera las URL que un sitio web quiere comunicar a los motores de búsqueda. Puede contener directamente las direcciones de las páginas o actuar como índice de otros sitemaps.
En WordPress, el sitemap nativo suele encontrarse en /wp-sitemap.xml. Los sitios que utilizan herramientas SEO pueden disponer de una dirección diferente, como /sitemap_index.xml, que agrupa varios archivos.
¿Qué información contiene?
<loc>: la dirección de una página o de otro sitemap.
<lastmod>: la fecha de última modificación declarada, si está disponible.
<sitemapindex>: identifica un índice que agrupa varios sitemaps.
<urlset>: contiene las entradas correspondientes a las URL enumeradas.
Un sitemap facilita el descubrimiento de contenido, pero incluir una URL no garantiza que Google la rastree, la indexe o la muestre en los resultados de búsqueda.
Analizador de sitemap XML online
Introduce la dirección completa de un sitemap público y pulsa el botón para consultar su estructura. Puedes utilizar el sitemap de tu propia web o probar con otro dominio que permita el acceso desde el navegador.
Analizador de Sitemap
Consulta las URL y los sub-sitemaps de un archivo XML. Los resultados muestran el contenido del archivo, no el estado de indexación en Google.
Cómo interpretar los resultados
El analizador muestra un resumen del XML que ha podido leer. Estos son los datos principales:
URL encontradas: número de direcciones válidas incluidas directamente en el archivo analizado.
Sub-sitemaps: número de archivos secundarios enumerados en el índice.
URL con lastmod: cantidad de direcciones que incluyen una fecha de modificación declarada.
Enlaces: permiten abrir las direcciones encontradas en otra pestaña.
Si analizas un índice de sitemaps, el recuento de URL puede ser cero aunque el archivo sea correcto. En ese caso, abre los sub-sitemaps para consultar las direcciones individuales.
¿Cómo utiliza Google los sitemaps?
Google puede utilizar un sitemap para descubrir URL y obtener información adicional, como la fecha de modificación cuando se proporciona. Sin embargo, el archivo no obliga al buscador a rastrear todas las direcciones ni determina por sí solo cuáles se indexarán.
¿Google distingue entre páginas y entradas?
En un sitemap, las direcciones se representan mediante URL, independientemente de que en WordPress correspondan a páginas, entradas u otros tipos de contenido. Google puede utilizar otras señales para comprender cada recurso y decidir cómo procesarlo.
Por tanto, no existe una regla general que establezca que Google rastrea primero las páginas o primero las entradas. Tampoco puede deducirse ese orden por la posición de las URL dentro del XML.
¿Qué importancia tiene el enlazado interno?
Los enlaces internos ayudan a Google a descubrir páginas y comprender cómo se relacionan dentro del sitio. Conviene enlazar desde páginas relevantes el contenido que realmente quieres destacar y evitar que las páginas importantes queden aisladas o sean difíciles de encontrar.
Los enlaces externos también pueden contribuir al descubrimiento y a la valoración de una página. No obstante, no existe un orden público y universal de señales que permita calcular con exactitud qué URL rastreará Google primero.
¿La fecha lastmod hace que Google rastree antes?
La etiqueta <lastmod> comunica la fecha de modificación del contenido cuando se proporciona de forma correcta y fiable. No garantiza un rastreo inmediato ni sirve para forzar una prioridad. Es preferible indicar fechas reales y mantenerlas actualizadas cuando el contenido cambia de manera significativa.
Qué comprobar si una URL no aparece en el sitemap
Si una página importante no figura en el archivo, revisa estos puntos:
Que la URL exista y responda correctamente.
Que no esté excluida del sitemap por la configuración de WordPress o de la herramienta SEO utilizada.
Que no tenga una directiva noindex si debe aparecer en los resultados de búsqueda.
Que la etiqueta canónica apunte a la versión correcta de la URL.
Que el sitemap enviado a Google Search Console sea el correcto y esté accesible.
Ten en cuenta que una URL puede estar fuera del sitemap y ser descubierta por otros medios. Del mismo modo, aparecer en el sitemap no garantiza su indexación.
Errores frecuentes al analizar un sitemap
El navegador no permite leer el archivo
Si aparece un error de conexión o CORS, el servidor puede estar impidiendo que una página web lea su respuesta desde otro origen. La herramienta no puede eludir esa restricción. Comprueba la URL y prueba con un sitemap del mismo dominio desde el que se ejecuta el analizador.
El archivo no contiene XML válido
Una página de error HTML, una redirección inesperada o un documento mal formado pueden impedir el análisis. Comprueba que has introducido la dirección del archivo XML y que este se abre correctamente.
El resultado muestra cero URL
Si has introducido un índice de sitemaps, puede ser normal que no contenga directamente las URL de las páginas. Abre los archivos secundarios que aparezcan en los resultados y analízalos individualmente.
Preguntas frecuentes sobre los sitemaps
¿Puedo analizar el sitemap de cualquier dominio?
Puedes intentarlo con cualquier dirección HTTP o HTTPS, pero el navegador solo podrá leer la respuesta si el servidor lo permite. Esta herramienta funciona sin un servicio intermedio y, por ello, no puede superar las restricciones CORS de otros dominios.
¿La herramienta comprueba si Google ha indexado mis páginas?
No. Analiza el contenido del sitemap, pero no consulta el índice de Google. Para revisar la indexación de una URL concreta, utiliza la inspección de URL de Google Search Console.
¿Tengo que instalar algún programa?
No. La herramienta se ejecuta en el navegador mediante JavaScript y no necesita que instales un programa o un plugin en WordPress.
¿Un sitemap mejora automáticamente el posicionamiento SEO?
No garantiza mejores posiciones. Su función principal es facilitar el descubrimiento de las URL. La calidad del contenido, la accesibilidad técnica, los enlaces y otros factores intervienen en el rendimiento orgánico de un sitio web.
Consulta también cómo ver el sitemap de un dominio
Si necesitas localizar el sitemap de una web antes de analizarlo, consulta nuestra guía complementaria:
Conclusión: un sitemap XML permite consultar las URL que un sitio comunica a los buscadores. Con este analizador puedes revisar su estructura y detectar qué direcciones contiene, siempre que el navegador tenga permiso para leer el archivo.
Los banners ilegales de cookies se han convertido en una presencia constante en Internet. Sin embargo, existe una realidad que muchos desconocen: la mayoría de banners no cumplen la ley cuando el sitio web utiliza cookies de terceros, como las que instalan YouTube, Meta, Google Analytics, AdSense, Google Maps, widgets sociales o cualquier script externo.
La razón es simple: un banner solo es legal si bloquea las cookies hasta que el usuario dé su consentimiento. Y la mayoría no lo hace.
Qué son las cookies de terceros
Las cookies de terceros son archivos que no instala tu web, sino servicios externos incrustados en ella. Ejemplos:
YouTube al insertar un vídeo
Google Analytics al medir visitas
AdSense al mostrar anuncios
Meta/Instagram al incrustar publicaciones
Google Maps al mostrar un mapa
Estas cookies pueden rastrear al usuario, crear perfiles y compartir datos con empresas externas.
El problema: los banners gratuitos NO bloquean cookies
La mayoría de banners populares —como CookieYes (gratis), Complianz (gratis), GDPR Cookie Consent, Cookie Notice— no bloquean las cookies de terceros. Por tanto:
Las cookies se instalan antes de que el usuario acepte
El consentimiento es falso
El banner no cumple la ley
El responsable del sitio queda expuesto legalmente
Esto significa que poner un banner no te protege si tu web sigue cargando scripts externos.
Qué exige la ley realmente
La normativa europea (RGPD + ePrivacy) exige que, si hay cookies de terceros:
El usuario debe poder aceptar o rechazar
Las cookies deben estar bloqueadas por defecto
El banner debe ser bloqueante
Debe existir un panel de configuración
Debe identificarse al titular del sitio (nombre, dirección, DNI o CIF)
Debe haber una política de cookies completa
Esto solo lo cumplen:
CMP certificadas TCF 2.2
Complianz PRO
Cookiebot
Real Cookie Banner
Pero incluso estas herramientas obligan a mostrar datos personales del titular, algo que muchos editores prefieren evitar.
Por qué un banner NO te sirve si tienes cookies de terceros
La clave es esta:
Si tu web instala cookies de terceros, necesitas un sistema profesional que bloquee esas cookies.Si no bloquea, no cumple. Y si no cumple, no te protege.
Por eso, un banner simple —o cualquier banner gratuito— no sirve.
La única solución si no quieres complicarte
Si no quieres:
pagar una CMP
mostrar tus datos personales
gestionar consentimiento avanzado
asumir riesgos legales
Entonces la única opción segura es:
👉 Eliminar todas las cookies de terceros 👉 Usar un aviso de cookies simplificado 👉 Evitar scripts externos que instalen cookies
Los banners de cookies solo sirven cuando:
el sitio no instala cookies de terceros, o
se usa una CMP profesional que bloquea cookies hasta el consentimiento.
En todos los demás casos:
El banner no cumple, no bloquea y no te protege.
Si tu objetivo es privacidad, simplicidad y cero riesgos, la estrategia ganadora es clara:
👉 Eliminar cookies de terceros y usar un aviso simplificado.
Reguladores que supervisan el uso de cookies
En España y en Europa, los sitios web oficiales que regulan y supervisan el uso de cookies y la protección de datos son los siguientes:
🇪🇸 España
Organismo
Función principal
Sitio web oficial
Agencia Española de Protección de Datos (AEPD)
Autoridad nacional que aplica el RGPD y la LSSI. Publica la Guía sobre el uso de cookies y sanciona incumplimientos.
