1. Desarrollo de planes de prevención y concienciación en ciberseguridad
La ciberseguridad no depende únicamente de disponer de sistemas de protección tecnológica. Una parte importante de los incidentes tiene su origen en errores humanos, configuraciones incorrectas, desconocimiento de los procedimientos o falta de concienciación.
Por este motivo, una organización debe establecer planes de prevención y concienciación en ciberseguridad destinados a reducir la probabilidad de que se produzcan incidentes y a mejorar la capacidad de respuesta de los empleados.
Un plan de prevención debe definir:
- Qué riesgos existen.
- Qué medidas preventivas se aplicarán.
- Quién es responsable de cada medida.
- Qué formación recibirá el personal.
- Cómo se comprobará el cumplimiento.
- Cómo se evaluará la eficacia del plan.
- Qué medidas se adoptarán cuando se detecten deficiencias.
Un buen programa combina personas, procesos y tecnología.
1.1. Principios generales en materia de ciberseguridad
Los principios de ciberseguridad constituyen las reglas básicas que deben guiar la protección de los sistemas de información.
Confidencialidad
Garantiza que la información solamente pueda ser consultada por personas, aplicaciones o sistemas autorizados.
Ejemplos:
- Control de acceso.
- Contraseñas.
- Autenticación multifactor.
- Cifrado.
- Gestión de permisos.
Por ejemplo, un empleado del departamento comercial no debería poder acceder a la información salarial del departamento de recursos humanos si no necesita dicha información para desarrollar sus funciones.
Integridad
Garantiza que los datos no sean modificados de forma no autorizada.
Las modificaciones pueden producirse accidentalmente o como consecuencia de un ataque.
Algunas medidas utilizadas son:
- Hashes.
- Firmas digitales.
- Control de versiones.
- Permisos de escritura.
- Registros de auditoría.
- Sistemas de detección de modificaciones.
Por ejemplo, si un atacante modifica una factura almacenada en un sistema corporativo, se habrá producido una pérdida de integridad.
Disponibilidad
Garantiza que los sistemas y la información estén disponibles cuando sean necesarios.
Algunas amenazas contra la disponibilidad son:
- Ataques de denegación de servicio.
- Ransomware.
- Fallos eléctricos.
- Fallos de hardware.
- Incendios.
- Errores humanos.
- Fallos de comunicaciones.
Las medidas preventivas pueden incluir:
- Copias de seguridad.
- Sistemas redundantes.
- Clústeres.
- Sistemas de alimentación ininterrumpida.
- Planes de continuidad.
- Planes de recuperación ante desastres.
Autenticidad
Permite comprobar que una persona, dispositivo, servicio o información es realmente quien dice ser.
Ejemplos:
- Certificados digitales.
- Autenticación multifactor.
- Firmas digitales.
- Sistemas de identidad corporativa.
Trazabilidad
Consiste en poder determinar qué ocurrió en un sistema y, cuando sea posible, quién realizó una determinada acción.
Para ello son fundamentales los logs o registros de actividad.
Por ejemplo:
30/09/2026 10:15:32
Usuario: jlopez
IP: 192.168.10.45
Acción: acceso al servidor
Resultado: correctoLa trazabilidad permite reconstruir posteriormente la actividad relacionada con un incidente.
Principio de mínimo privilegio
Cada usuario debe disponer únicamente de los permisos necesarios para realizar sus funciones.
Un usuario que solamente necesita consultar documentos no debería disponer de permisos administrativos.
Este principio reduce el impacto de:
- Robo de credenciales.
- Malware.
- Errores humanos.
- Ataques internos.
- Escaladas de privilegios.
Defensa en profundidad
La seguridad no debe depender de una única medida.
La organización debe establecer diferentes capas de protección:
Internet
↓
Firewall
↓
IDS/IPS
↓
Segmentación de red
↓
Autenticación
↓
Endpoint Security
↓
Aplicación
↓
DatosSi una capa falla, otras pueden impedir o limitar el ataque.
Seguridad desde el diseño
La seguridad debe incorporarse desde las primeras fases de diseño de un sistema.
No debería esperarse a que aparezca una vulnerabilidad para comenzar a protegerlo.
Gestión del riesgo
La organización debe identificar:
- Activos.
- Amenazas.
- Vulnerabilidades.
- Impactos.
- Probabilidad de ocurrencia.
- Medidas de protección.
Una representación sencilla es:
Riesgo = Probabilidad × Impacto
Por ejemplo, una vulnerabilidad crítica en un servidor que contiene información sensible tendrá una prioridad elevada.
1.2. Normativa de protección del puesto de trabajo
El puesto de trabajo constituye uno de los principales puntos de entrada de amenazas.
Puede incluir:
- Ordenadores.
- Portátiles.
- Teléfonos móviles.
- Tablets.
- Sistemas virtuales.
- Dispositivos IoT.
- Equipos conectados a la red corporativa.
La organización debe establecer normas de uso seguro.
Medidas básicas
Bloqueo de pantalla
El usuario debe bloquear el equipo cuando se ausente.
Actualizaciones
Los sistemas operativos y aplicaciones deben mantenerse actualizados.
Antivirus o EDR
Los dispositivos deben disponer de mecanismos de protección y detección.
Control de dispositivos externos
Debe controlarse el uso de:
- USB.
- Discos externos.
- Dispositivos móviles.
Software autorizado
Los usuarios no deberían instalar aplicaciones sin autorización.
Contraseñas
Deben existir políticas sobre:
- Longitud.
- Complejidad.
- Reutilización.
- Almacenamiento.
- MFA.
Correo electrónico
Los empleados deben saber identificar:
- Phishing.
- Spear phishing.
- Archivos maliciosos.
- Enlaces sospechosos.
- Suplantaciones.
1.3. Plan de formación y concienciación en ciberseguridad
Un plan de formación debe adaptarse a las características de la organización.
No todos los trabajadores necesitan exactamente la misma formación.
Por ejemplo:
| Perfil | Formación |
|---|---|
| Usuario general | Phishing, contraseñas, navegación segura |
| Administrador | Hardening, privilegios, monitorización |
| Recursos humanos | Protección de información personal |
| Dirección | Riesgo, continuidad y gestión de incidentes |
| Técnicos | Respuesta a incidentes y análisis |
| Desarrolladores | Desarrollo seguro |
Fases del plan
1. Análisis inicial
Se determina el nivel de conocimiento de los empleados.
Puede realizarse mediante:
- Encuestas.
- Entrevistas.
- Tests.
- Simulaciones de phishing.
2. Definición de objetivos
Por ejemplo:
Reducir el número de empleados que introducen sus credenciales en campañas simuladas de phishing.
3. Diseño de contenidos
Se seleccionan los temas que deben impartirse.
4. Formación
Puede realizarse mediante:
- Cursos online.
- Sesiones presenciales.
- Vídeos.
- Talleres.
- Simulaciones.
- Ejercicios prácticos.
5. Evaluación
Se comprueba si los conocimientos han sido adquiridos.
6. Mejora continua
Los resultados obtenidos sirven para modificar el programa.
1.4. Materiales de formación y concienciación
Los materiales deben ser claros y adaptados al público.
Algunos ejemplos:
- Manuales.
- Guías rápidas.
- Infografías.
- Vídeos.
- Presentaciones.
- Carteles.
- Cuestionarios.
- Simulaciones.
- Casos prácticos.
- Boletines de seguridad.
Ejemplo de cartel
¿Has recibido un correo sospechoso?
- No abras los enlaces.
- No descargues archivos.
- Comprueba el remitente.
- No introduzcas tus credenciales.
- Comunícalo al departamento de seguridad.
La concienciación debe ser continua, no limitarse a una formación anual.
1.5. Auditorías internas de cumplimiento en materia de prevención
Una auditoría interna permite comprobar si las medidas de seguridad establecidas realmente se están aplicando.
Puede analizar:
- Políticas.
- Configuraciones.
- Permisos.
- Actualizaciones.
- Copias de seguridad.
- Formación.
- Gestión de contraseñas.
- Registros.
- Procedimientos.
Proceso de auditoría
Planificación
↓
Recopilación de información
↓
Comprobación
↓
Identificación de incumplimientos
↓
Informe
↓
Plan de acciones correctivas
↓
SeguimientoUna auditoría no debería limitarse a señalar problemas. Debe permitir establecer acciones correctoras y comprobar posteriormente su aplicación.
2. Auditoría de incidentes de ciberseguridad
Una auditoría de incidentes permite analizar los acontecimientos relacionados con la seguridad para determinar:
- Qué ocurrió.
- Cuándo ocurrió.
- Cómo ocurrió.
- Qué sistemas fueron afectados.
- Qué información pudo verse comprometida.
- Qué medidas se adoptaron.
- Cómo evitar que vuelva a suceder.
2.1. Taxonomía de incidentes de ciberseguridad
La taxonomía permite clasificar los incidentes.
Una posible clasificación es:
Malware
Software diseñado para realizar acciones no autorizadas.
Tipos:
- Virus.
- Gusanos.
- Troyanos.
- Ransomware.
- Spyware.
- Rootkits.
Phishing
Intento de engañar al usuario para conseguir información o provocar una acción.
Ataques de credenciales
Por ejemplo:
- Credential stuffing.
- Password spraying.
- Fuerza bruta.
- Robo de contraseñas.
Denegación de servicio
Ataques destinados a impedir o degradar el funcionamiento de un servicio.
Explotación de vulnerabilidades
Aprovechamiento de una vulnerabilidad existente en software o hardware.
Acceso no autorizado
Entrada en un sistema sin autorización.
Fuga de información
Acceso o divulgación no autorizada de información.
Incidentes internos
Provocados accidental o intencionadamente por personas pertenecientes a la organización.
Incidentes físicos
Por ejemplo:
- Robo de equipos.
- Incendio.
- Inundación.
- Manipulación física.
- Acceso no autorizado a instalaciones.
2.2. Controles, herramientas y mecanismos de monitorización, identificación, detección y alerta
La organización debe disponer de mecanismos capaces de detectar comportamientos anómalos.
Fuentes de información
Logs
Los registros pueden proceder de:
- Servidores.
- Firewalls.
- Routers.
- Sistemas operativos.
- Aplicaciones.
- Bases de datos.
- Sistemas de autenticación.
IDS
Un Intrusion Detection System detecta posibles actividades maliciosas.
IPS
Un Intrusion Prevention System puede detectar y bloquear determinados ataques.
SIEM
Un SIEM recopila y correlaciona eventos procedentes de diferentes sistemas.
Ejemplo:
Firewall
↓
Servidor
↓
Antivirus
↓
Active Directory
↓
SIEM
↓
Correlación
↓
AlertaUna única actividad puede parecer normal, pero varias actividades relacionadas pueden indicar un ataque.
EDR
Los sistemas Endpoint Detection and Response monitorizan los dispositivos finales y permiten investigar comportamientos sospechosos.
Pueden detectar:
- Procesos anómalos.
- Ejecución de scripts.
- Modificaciones del sistema.
- Comunicaciones sospechosas.
- Actividad de malware.
2.3. Detección e identificación de incidentes de seguridad física
La ciberseguridad también depende de la seguridad física.
Un atacante que consigue acceso físico a un servidor puede intentar comprometerlo directamente.
Los mecanismos de protección incluyen:
- Cámaras CCTV.
- Control de acceso.
- Tarjetas identificativas.
- Sistemas biométricos.
- Alarmas.
- Sensores.
- Cerraduras electrónicas.
- Sistemas de detección de incendios.
- Sensores de temperatura.
- Sistemas antiintrusión.
Por ejemplo:
Sensor de puerta
↓
Sistema de seguridad
↓
Evento
↓
Alerta
↓
Personal de seguridad
↓
Investigación2.4. OSINT aplicado a la detección de incidentes
OSINT (Open Source Intelligence) consiste en obtener y analizar información procedente de fuentes abiertas.
Puede utilizarse para identificar información relacionada con una organización, dominios, infraestructura, amenazas o incidentes.
Fuentes posibles:
- Sitios web.
- Redes sociales.
- Blogs.
- Noticias.
- Repositorios públicos.
- CERT/CSIRT.
- Bases de datos públicas.
- Información DNS.
- Certificados digitales.
- Registros de dominios.
Por ejemplo, ante una campaña de phishing contra una empresa, OSINT puede utilizarse para investigar:
- Dominios similares.
- Dominios registrados recientemente.
- Infraestructura utilizada.
- Direcciones IP relacionadas.
- Información publicada sobre el ataque.
Es importante diferenciar recopilación de información de intrusión. OSINT trabaja con información obtenida legalmente de fuentes abiertas.
2.5. Clasificación, valoración, documentación y seguimiento inicial
Cuando se detecta un incidente debe registrarse.
Un registro podría contener:
ID: INC-2026-0015
Fecha: 30/09/2026
Tipo: Phishing
Origen: Correo electrónico
Usuario afectado: usuario01
Sistema afectado: Equipo-PC-24
Impacto: Bajo
Estado: En investigación
Responsable: SOCValoración
Puede utilizarse una escala:
- Bajo.
- Medio.
- Alto.
- Crítico.
También pueden utilizarse criterios más detallados basados en:
- Número de sistemas afectados.
- Sensibilidad de los datos.
- Duración.
- Impacto económico.
- Impacto operativo.
- Impacto reputacional.
- Alcance del incidente.
3. Investigación de los incidentes de ciberseguridad
La investigación busca determinar qué ocurrió y obtener evidencias que permitan comprender el incidente.
Debe realizarse de manera organizada para evitar perder información.
3.1. Recopilación de evidencias
Las evidencias pueden ser:
Digitales
- Logs.
- Correos electrónicos.
- Imágenes de discos.
- Memoria RAM.
- Archivos.
- Metadatos.
- Registros de red.
- Capturas de pantalla.
- Alertas de seguridad.
Físicas
- Ordenadores.
- Discos.
- USB.
- Teléfonos.
- Documentación.
- Dispositivos de red.
Cadena de custodia
Cuando las evidencias pueden utilizarse en procesos disciplinarios o judiciales es fundamental garantizar su integridad.
La cadena de custodia permite documentar:
- Quién obtuvo la evidencia.
- Cuándo.
- Dónde.
- Cómo.
- Quién la almacenó.
- Quién accedió posteriormente.
También pueden calcularse hashes:
SHA-256:
a4f8c7............Si posteriormente el hash cambia, la evidencia ha sido modificada.
3.2. Análisis de evidencias
Una vez recopiladas las evidencias se analizan.
Puede estudiarse:
- Línea temporal.
- Usuarios.
- Direcciones IP.
- Procesos.
- Archivos.
- Comunicaciones.
- Eventos de autenticación.
- Cambios realizados.
Un objetivo fundamental es construir una timeline.
Ejemplo:
08:41:12 Inicio de sesión
08:43:10 Ejecución de archivo
08:43:15 Conexión externa
08:44:02 Creación de proceso
08:45:33 Modificación de archivo
08:46:20 Alerta EDRLa línea temporal permite relacionar diferentes eventos.
3.3. Investigación del incidente
La investigación debe responder a preguntas como:
- ¿Cuándo comenzó?
- ¿Cuál fue el origen?
- ¿Qué vulnerabilidad o mecanismo se utilizó?
- ¿Qué sistemas fueron afectados?
- ¿Qué cuentas estuvieron implicadas?
- ¿Se produjo movimiento lateral?
- ¿Se accedió a información?
- ¿Se produjo exfiltración?
- ¿Continúa el atacante dentro de la infraestructura?
- ¿Qué medidas deben adoptarse?
3.4. Intercambio de información con proveedores u organismos competentes
Dependiendo de la naturaleza del incidente puede ser necesario contactar con:
- Proveedores tecnológicos.
- Proveedores de servicios.
- CERT/CSIRT.
- Fuerzas y Cuerpos de Seguridad.
- Autoridades competentes.
- Entidades afectadas.
La información compartida debe ser la necesaria y adecuada para gestionar el incidente, teniendo en cuenta las obligaciones legales y de protección de la información.
3.5. Medidas de contención
El objetivo de la contención es impedir que el incidente continúe propagándose.
Algunas medidas:
- Aislar un equipo.
- Deshabilitar una cuenta comprometida.
- Bloquear una dirección IP.
- Bloquear un dominio malicioso.
- Segmentar una red.
- Desconectar un servidor.
- Revocar credenciales.
- Detener determinados servicios.
La contención debe realizarse valorando también el impacto sobre la actividad de la organización.
4. Implementación de medidas de ciberseguridad
Una vez identificado el incidente es necesario aplicar las medidas necesarias para responder y recuperar los servicios.
4.1. Procedimientos de actuación
La organización debe disponer de procedimientos previamente definidos.
Un procedimiento puede contener:
Detección
↓
Registro
↓
Clasificación
↓
Valoración
↓
Contención
↓
Erradicación
↓
Recuperación
↓
Verificación
↓
CierreEstos procedimientos pueden adaptarse al tipo de incidente.
Por ejemplo:
Ransomware
- Aislar equipos afectados.
- Identificar sistemas comprometidos.
- Evitar la propagación.
- Preservar evidencias.
- Analizar el malware.
- Determinar el alcance.
- Erradicar.
- Recuperar desde copias seguras.
- Verificar sistemas.
- Documentar el incidente.
4.2. Implantación de capacidades de ciberresiliencia
La ciberresiliencia es la capacidad de una organización para prepararse, resistir, responder y recuperarse frente a incidentes.
No se trata únicamente de evitar ataques.
Un sistema resiliente debe ser capaz de continuar funcionando o recuperarse rápidamente.
Elementos importantes:
- Copias de seguridad.
- Redundancia.
- Planes de continuidad.
- Planes de recuperación.
- Sistemas alternativos.
- Segmentación.
- Monitorización.
- Procedimientos de emergencia.
- Simulacros.
4.3. Flujos de toma de decisiones y escalado
No todos los incidentes deben ser tratados de la misma manera.
Puede establecerse un esquema:
Incidente detectado
↓
¿Impacto bajo?
↙ ↘
Sí No
↓ ↓
Equipo TI Escalado
↓
Seguridad / CISO
↓
Dirección / Legal
↓
Organismos externosEl escalado puede producirse por:
- Gravedad.
- Sensibilidad de la información.
- Número de usuarios afectados.
- Impacto económico.
- Duración.
- Afectación a servicios críticos.
- Obligaciones legales.
4.4. Restauración de servicios
Después de contener y eliminar la amenaza comienza la recuperación.
Puede incluir:
- Restauración de copias de seguridad.
- Reinstalación de sistemas.
- Recuperación de bases de datos.
- Cambio de credenciales.
- Aplicación de parches.
- Reconfiguración.
- Verificación de integridad.
La recuperación debe realizarse progresivamente.
Antes de devolver un sistema a producción debe comprobarse que:
- Está actualizado.
- Está correctamente configurado.
- No contiene malware.
- Las cuentas comprometidas han sido protegidas.
- Las vulnerabilidades utilizadas han sido corregidas.
4.5. Documentación
Todo incidente debe quedar documentado.
El informe puede contener:
Identificación
- Código del incidente.
- Fecha.
- Responsable.
Descripción
- Qué ocurrió.
- Cómo se detectó.
Impacto
- Sistemas afectados.
- Usuarios afectados.
- Información afectada.
Investigación
- Evidencias.
- Línea temporal.
- Causa.
Respuesta
- Medidas aplicadas.
- Contención.
- Erradicación.
Recuperación
- Sistemas restaurados.
- Servicios recuperados.
Lecciones aprendidas
- Qué funcionó.
- Qué falló.
- Qué debe modificarse.
4.6. Seguimiento para evitar incidentes similares
La gestión del incidente no termina cuando el sistema vuelve a funcionar.
Debe realizarse un análisis posterior.
Este análisis se conoce habitualmente como post-incident review o lecciones aprendidas.
Preguntas:
- ¿Por qué ocurrió?
- ¿Qué control falló?
- ¿Se detectó rápidamente?
- ¿La respuesta fue adecuada?
- ¿Existían procedimientos?
- ¿Los empleados estaban correctamente formados?
- ¿Qué medidas deben implantarse?
Por ejemplo, si un ataque de phishing tuvo éxito porque varios usuarios no reconocieron el correo, puede ser necesario reforzar la formación y realizar nuevas campañas de concienciación.
5. Detección y documentación de incidentes de ciberseguridad
La organización debe establecer procedimientos específicos para comunicar los incidentes.
La detección solamente es útil si existe un mecanismo para comunicar y gestionar aquello que se detecta.
5.1. Procedimientos de actuación para la notificación
El procedimiento debe indicar:
- Qué debe notificarse.
- Quién debe notificar.
- A quién.
- Por qué canal.
- En qué plazo.
- Qué información debe incluirse.
- Qué nivel de urgencia tiene.
Por ejemplo:
Empleado detecta incidente
↓
Comunicación al soporte/SOC
↓
Registro del incidente
↓
Clasificación
↓
Evaluación
↓
Escalado
↓
Respuesta5.2. Notificación interna
La organización debe establecer canales internos.
Por ejemplo:
- Correo corporativo.
- Teléfono de emergencia.
- Sistema de tickets.
- Plataforma de gestión de incidentes.
- Canal específico del SOC.
Los empleados deben conocer claramente cómo comunicar un incidente.
Un procedimiento sencillo puede ser:
Si sospecha que su equipo ha sido comprometido, no continúe trabajando normalmente, no elimine archivos ni evidencias y comuníquelo inmediatamente al departamento correspondiente.
5.3. Notificación a las personas u organismos correspondientes
Dependiendo del incidente, puede ser necesario comunicarlo a determinadas partes.
Por ejemplo:
- Responsable de seguridad.
- Responsable de sistemas.
- Responsable de protección de datos.
- Dirección.
- Proveedores.
- Clientes afectados.
- CERT/CSIRT.
- Autoridades competentes.
- Fuerzas y Cuerpos de Seguridad.
La decisión debe basarse en:
- Naturaleza del incidente.
- Información afectada.
- Impacto.
- Obligaciones contractuales.
- Obligaciones legales.
- Características del sector.
6. Modelo completo de gestión de un incidente
Todos los contenidos anteriores pueden integrarse en un único ciclo:
PREVENCIÓN
│
▼
Concienciación
│
▼
MONITORIZACIÓN
│
▼
DETECCIÓN
│
▼
IDENTIFICACIÓN
│
▼
CLASIFICACIÓN
│
▼
ANÁLISIS
│
▼
CONTENCIÓN
│
▼
ERRADICACIÓN
│
▼
RECUPERACIÓN
│
▼
VERIFICACIÓN
│
▼
DOCUMENTACIÓN
│
▼
LECCIONES APRENDIDAS
│
▼
MEJORA
│
└──────────────► PREVENCIÓN
Este ciclo refleja una idea fundamental: la gestión de incidentes es un proceso continuo.
Una organización madura no se limita a solucionar el incidente concreto. Utiliza la información obtenida durante la investigación para mejorar sus controles, procedimientos, formación y capacidad de respuesta.
Ejemplo práctico completo
Supongamos que un empleado recibe un correo aparentemente enviado por el departamento de administración.
El mensaje contiene un enlace que conduce a una página falsa de inicio de sesión.
1. Prevención
La organización dispone de:
- Formación antiphishing.
- MFA.
- Filtros de correo.
- EDR.
- SIEM.
2. Detección
El empleado introduce sus credenciales y posteriormente el sistema detecta un inicio de sesión anómalo.
3. Identificación
El SOC determina que:
- La cuenta ha sido utilizada desde una ubicación inusual.
- Existe un inicio de sesión sospechoso.
- El correo recibido era fraudulento.
4. Clasificación
Se clasifica como:
Incidente de compromiso de credenciales.
5. Contención
Se:
- Bloquea temporalmente la cuenta.
- Revocan sesiones activas.
- Fuerzan el cambio de contraseña.
- Revisan los accesos recientes.
6. Investigación
Se analizan:
- Logs.
- Correo.
- IP.
- Horarios.
- Actividad de la cuenta.
- Sistemas consultados.
7. Erradicación
Se elimina el correo malicioso y se bloquean los indicadores relacionados con la campaña.
8. Recuperación
Se restablece el acceso del usuario después de comprobar que la cuenta está protegida.
9. Documentación
Se registra:
- Cronología.
- Sistemas afectados.
- Acciones realizadas.
- Evidencias.
- Impacto.
10. Lecciones aprendidas
La organización puede determinar que necesita:
- Mejorar el filtrado de correo.
- Reforzar la formación.
- Revisar políticas de autenticación.
- Mejorar las reglas del SIEM.
- Realizar una nueva simulación de phishing.
De esta forma, un incidente se convierte también en una fuente de información para mejorar la seguridad de toda la organización.