Ciberseguridad y seguridad de la información
Guías profesionales sobre carreras, roles y certificaciones en ciberseguridad.
Curso de ciberseguridad para principiantes: qué comprobar antes de inscribirse
Un buen curso de ciberseguridad para principiantes comienza con los fundamentos de redes, sistemas operativos y Linux, incluye práctica en laboratorios, prepara para certificaciones internacionales reconocidas y ofrece un acompañamiento laboral real sin prometer trabajo ni aprobar exámenes.
Cómo entrar en el campo de la ciberseguridad sin experiencia previa
Puedes entrar en ciberseguridad incluso sin experiencia previa: aprende los fundamentos de ordenadores y redes, domina Windows y Linux, entiende los principios de seguridad de la información, practica en laboratorios y con herramientas como SIEM, y construye un portafolio de proyectos y un perfil de LinkedIn antes de buscar un rol de entrada.
¿Qué hace un analista SOC en un día de trabajo real?
Un analista SOC monitorea las alertas de un sistema SIEM, realiza un triaje inicial, investiga usuarios y estaciones de trabajo, identifica falsos positivos, documenta cada incidente, escala según sea necesario a equipos avanzados y opera según Playbooks definidos. El puesto requiere comprender redes, sistemas operativos y procesos de respuesta a incidentes.
¿Qué es la ciberseguridad? Una guía completa para principiantes
La ciberseguridad (Cybersecurity) es la disciplina profesional que se ocupa de proteger los sistemas informáticos, redes, datos y usuarios contra la explotación, interrupción o acceso no autorizado. Su base es la gestión de riesgos según los activos, amenazas, vulnerabilidades y controles, y su eje central son los tres principios de la CIA: confidencialidad, integridad y disponibilidad.
¿Sustituirá la IA a los expertos en ciberseguridad? Así será la profesión en los próximos años
No se espera que la IA sustituya a los profesionales de la ciberseguridad, pero ya está cambiando la naturaleza de su trabajo. Acelera tareas como el resumen de logs, el triaje inicial, las consultas y la documentación, pero las tareas que requieren contexto, responsabilidad y juicio siguen siendo responsabilidad humana. Los profesionales de la ciberseguridad que aprendan a trabajar con la IA de forma segura tendrán una ventaja.
¿Qué profesiones hay en ciberseguridad? Funciones, áreas de especialización y trayectorias profesionales
El mundo de la ciberseguridad incluye familias de roles claras: SOC/Cyber Defense, Security Engineering, DFIR, Penetration Testing, Cloud Security, AppSec, GRC y Threat Intelligence. La entrada más común es a través de SOC, y desde allí se puede avanzar en diferentes direcciones según la personalidad y la experiencia profesional.
¿Cuánto cuesta un curso de ciberseguridad en España? Precios, itinerarios y qué incluyen
El precio de un curso de ciberseguridad en España varía entre academias, organismos de formación y programas privados, y depende de factores como la duración, las clases en vivo frente a grabadas, los laboratorios, el acompañamiento profesional y qué certificaciones se incluyen. En lugar de comparar solo un número, es recomendable comparar el valor: qué se recibe exactamente, qué no está incluido y cuál es el coste total hasta la entrada en el mercado laboral.
¿Cuánto tiempo lleva aprender ciberseguridad y conseguir el primer empleo?
Para un principiante sin experiencia tecnológica, un plazo de planificación realista suele ser de 6 a 12 meses desde el inicio de los estudios hasta estar bien preparado para un primer puesto, y a veces más dependiendo del ritmo de estudio y del tiempo de búsqueda de empleo. Quienes tienen experiencia en TI, redes o soporte técnico pueden progresar más rápido. Es importante diferenciar entre el tiempo de estudio, el tiempo necesario para la práctica y el tiempo que lleva conseguir un empleo; estas son tres etapas diferentes, y no hay una ruta que garantice un empleo en una fecha fija.
Curso de ciberseguridad online vs. presencial: ventajas, desventajas y para quién es cada modalidad
No hay un formato único que sirva para todos. Un curso de ciberseguridad online en vivo puede ser una excelente opción para aquellos que son capaces de estudiar de forma independiente, tienen un entorno de trabajo tranquilo y quieren evitar desplazamientos. Un curso presencial es más adecuado para quienes necesitan un marco físico, contacto directo con la clase y menos distracciones en casa. La calidad del programa, el instructor, los laboratorios, la retroalimentación y la constancia son más importantes que la elección entre una pantalla y un aula.
Programa de entrada a la ciberseguridad en 5 meses: qué aprender en cada etapa
Se puede construir una base profesional significativa en ciberseguridad en cinco meses, pero solo si se combina un estudio estructurado con una práctica semanal. En el primer mes se construyen los fundamentos de redes y sistemas operativos; en el segundo y tercer mes se aprende seguridad, logs y SOC; en el cuarto mes se trabaja en escenarios y herramientas; y en el quinto mes se construye un proyecto, el currículum vitae y se prepara para las entrevistas.
¿Quieres trabajar en ciberseguridad? 5 errores que pueden retrasar tu entrada en el campo
Los cinco errores más comunes son saltarse redes y sistemas operativos, perseguir certificaciones sin práctica, centrarse solo en herramientas de ataque, esperar a sentirse completamente preparado antes de postularse y esperar que el curso por sí solo consiga un trabajo. El camino correcto es construir una base sólida, practicar, documentar proyectos y empezar a moverse en el mercado laboral temprano.
¿Qué se aprende en un curso de ciberseguridad? Temas, herramientas, laboratorios y certificaciones
Un curso completo de ciberseguridad para principiantes debe enseñar redes, Windows, Linux, fundamentos de seguridad, nube, Firewall, monitoreo y SOC, análisis de logs, respuesta a incidentes, Python básico y práctica en entornos autorizados. Un buen curso no se conforma con presentaciones: incluye laboratorios, proyectos, feedback y preparación para puestos de nivel inicial y certificaciones relevantes.
¿Es necesario saber programar para estudiar y trabajar en ciberseguridad?
No es imprescindible saber programar para empezar a estudiar ciberseguridad o para acceder a algunos puestos iniciales, especialmente SOC, soporte, NOC, gestión de permisos y seguridad de infraestructuras. Sin embargo, conocer Python, Bash o PowerShell mejora la capacidad de automatizar, entender herramientas, analizar datos y progresar a puestos más técnicos.
Preguntas frecuentes en una entrevista de trabajo para analista SOC – Incluye ejemplos de respuestas
En una entrevista de SOC para principiantes, generalmente se evalúan los fundamentos de redes y sistemas, la capacidad de leer registros, la comprensión de Phishing y Malware, el proceso de investigación de alertas y la capacidad de explicar las decisiones. Una buena respuesta no es solo una definición: presenta un orden de verificación, los datos que recopilarías, acciones cautelosas y cuándo escalarías el incidente.
¿Cómo construir un laboratorio de ciberseguridad casero para principiantes? Guía paso a paso
Para construir un laboratorio de ciberseguridad casero se necesita un ordenador con la memoria y el almacenamiento adecuados, software de virtualización, una máquina Linux y una máquina Windows o un sistema vulnerable dedicado. Se debe configurar una red interna aislada, crear Snapshots y trabajar solo en máquinas de su propiedad o plataformas que hayan dado permiso explícito.
Salario de analista SOC en Israel: ¿Cuánto ganan los que tienen experiencia y los principiantes en 2026?
En 2026, los rangos salariales comunes en Israel para puestos de SOC/SIEM son Cerca de 11.000-13.000 shekels brutos al mes para empleados con hasta un año de experiencia, 14.000-16.000 shekels después de uno a dos años, y 17.000-21.000 shekels para aquellos con tres a cinco años de experiencia. El salario real varía según los turnos, la experiencia previa en IT, las herramientas SIEM y EDR, el nivel de inglés, la clasificación de seguridad, la ubicación y el tipo de organización.
Analista SOC vs. Penetration Tester: ¿Cuál es la diferencia y qué rol le conviene más?
Un Analista SOC protege a la organización en tiempo real mediante la monitorización, la investigación de logs, la priorización de alertas y la respuesta a incidentes. Un Penetration Tester prueba los sistemas de forma planificada y autorizada para identificar vulnerabilidades antes de que un atacante las explote. SOC es adecuado para quienes disfrutan de la investigación continua, las operaciones y el trabajo en equipo; Pentest es adecuado para quienes disfrutan de la investigación técnica, la experimentación, la redacción de informes y la profundización en las vulnerabilidades.
¿Es posible conseguir trabajo como Penetration Tester después de un curso de Ciberseguridad?
Es posible conseguir un puesto de Penetration Tester después de un curso, pero el curso por sí solo no suele ser suficiente. Un candidato Junior debe demostrar una base en redes, Linux, Windows y Web, práctica en entornos autorizados, capacidad para escribir informes y un portafolio que demuestre su forma de pensar. A veces, el camino más rápido pasa por SOC, IT, soporte u otro rol técnico de seguridad.
Las mejores certificaciones de ciberseguridad para principiantes: guía comparativa
Para los principiantes, no existe una certificación única que sirva para todos. Linux Essentials es adecuada para bases de Linux, Network+ para bases de redes, CCST Cybersecurity para una introducción amigable a los principios de defensa, Security+ para una base más amplia y reconocida, y eJPT para quienes desean práctica ofensiva. La elección debe adaptarse a la brecha de conocimiento y al rol objetivo.
Certificación eJPT: guía completa para el examen, el material de estudio y la preparación
eJPT es una certificación de Penetration Testing inicial y práctica de INE Security. Es idónea para quienes ya entienden de redes, Linux, servicios y web y quieren practicar la metodología de prueba en un entorno legal. La preparación debe incluir laboratorios, documentación, trabajo ordenado y gestión del tiempo, no solo ver las lecciones.
Security+ vs. eJPT: ¿Qué certificación es la adecuada para ti?
Security+ es una certificación más amplia y teórica, adecuada para fundamentos de seguridad, SOC y roles de defensa generales. eJPT es una certificación más práctica y enfocada en pruebas de penetración. Para quienes aún están construyendo una base o apuntan a SOC, Security+ suele ser más adecuada; para quienes ya comprenden redes, Linux y Web y apuntan a Pentest, eJPT puede ser más apropiada.
CCST Cybersecurity frente a Security+: ¿Cuál es la diferencia y por dónde empezar?
CCST Cybersecurity es una certificación de entrada más accesible diseñada para construir fundamentos. Security+ es más amplia y profunda, y requiere una mejor comprensión de redes, sistemas, arquitectura y respuesta a incidentes. Para un principiante absoluto, a veces es aconsejable comenzar con CCST, practicar y luego avanzar a Security+.
¿Es Network+ necesaria para una carrera en ciberseguridad?
La certificación Network+ no es un requisito formal para la mayoría de los puestos de ciberseguridad, pero el conocimiento que cubre es casi esencial. Un analista de SOC, un especialista en seguridad en la nube o un Penetration Tester necesitan comprender las direcciones IP, TCP y UDP, DNS, DHCP, enrutamiento, Switching, VPN, Firewall y la resolución de problemas. Es posible adquirir este conocimiento sin realizar un examen.
Linux Essentials para profesionales de la ciberseguridad: ¿Qué se estudia y merece la pena la certificación?
Linux Essentials es una certificación básica de LPI que trata sobre el sistema Linux, la línea de comandos, archivos, usuarios, permisos, procesos, software y redes básicas. Es adecuada para principiantes que buscan un marco estructurado. La certificación no es obligatoria, pero el conocimiento es muy importante para SOC, la nube, DevSecOps y Penetration Testing.
¿Cómo investigar una alerta de seguridad en un SOC de principio a fin?
La investigación de una alerta de seguridad en un SOC es un proceso ordenado que verifica el origen de la alerta, identifica al usuario y al activo involucrados, recopila contexto de fuentes adicionales, construye una línea de tiempo, busca explicaciones legítimas y decide si se trata de un evento real. Una buena investigación termina con una decisión justificada, una acción de respuesta adecuada y una documentación que permita a otra persona reproducir la conclusión.
Triage en el SOC: Cómo priorizar alertas sin perderse un incidente real
El Triage en el SOC es un proceso de filtrado y evaluación inicial de una alerta para determinar qué es urgente, qué requiere una investigación profunda y qué se puede cerrar. La decisión no se basa solo en la severidad que mostró el sistema, sino en una combinación de la criticidad del activo, la sensibilidad del usuario, la fiabilidad de la señal, la técnica detectada, el alcance de la actividad y el posible impacto.
False Positive en SOC: cómo identificarlos, documentarlos y reducirlos
Un False Positive en SOC es un caso en el que se generó una alerta debido a una lógica errónea o datos imprecisos, aunque no se produjo el comportamiento peligroso que la regla pretendía detectar. Para cerrar correctamente, es necesario demostrar la causa, distinguirla de una actividad sospechosa pero autorizada, documentar la Causa Raíz y proporcionar retroalimentación que reduzca alertas similares sin crear un Blind Spot.
Playbook para SOC: Cómo construir un proceso de respuesta consistente a una alerta
Un Playbook para SOC es un proceso documentado que define cómo manejar un tipo específico de alerta: cuál es la entrada, qué verificaciones se realizan, qué evidencias se recopilan, cuáles son los puntos de decisión, cuándo se escala y qué acciones están permitidas. Un buen Playbook crea consistencia sin anular el pensamiento analítico, y se prueba y actualiza según resultados reales y cambios en el entorno.
Cómo construir una línea de tiempo para la investigación de incidentes cibernéticos
Una línea de tiempo para la investigación de incidentes es una tabla cronológica que unifica eventos de diferentes fuentes en un tiempo estándar y los conecta a través de usuarios, estaciones, direcciones IP, procesos y sesiones. Una construcción correcta incluye mantener el tiempo original, convertir a UTC, especificar la fuente y la fiabilidad, identificar lagunas y distinguir entre hechos, interpretación e hipótesis.
¿Cuándo debe un analista de SOC escalar un incidente a Tier 2 o a IR?
Un analista de SOC debe escalar un incidente cuando el nivel de riesgo, incertidumbre o el alcance de las acciones requeridas exceden la autoridad y capacidad de Tier 1. Una buena escalada no es "pasar el problema", sino entregar un paquete de investigación ordenado que incluye hechos, evidencias, cronología, impacto estimado, acciones ya realizadas y una pregunta clara para el siguiente equipo. En caso de afectación activa, activo crítico o sospecha de fuga, se involucra a Incident Response rápidamente según los procedimientos.
¿Cómo escribir un ticket de investigación SOC profesional?
Un ticket de investigación SOC profesional debe permitir que otro analista entienda lo que sucedió, qué datos se examinaron, qué se encontró, qué aún se desconoce y cuál es la siguiente acción, sin una llamada de seguimiento. Una buena estructura incluye un resumen, alcance, línea de tiempo, evidencia, análisis, decisión, acciones de respuesta y recomendaciones. Es importante separar claramente los hechos, la interpretación y las suposiciones, y citar solo los campos de log relevantes.
Severity vs. Priority: Cómo clasificar incidentes de seguridad
La Severidad describe el impacto potencial y la gravedad del incidente; la Prioridad determina el orden y la velocidad del tratamiento real. Un incidente puede ser grave pero no urgente si está aislado y contenido, o de gravedad media pero de alta prioridad si está activo en un activo crítico. La clasificación profesional combina fiabilidad, alcance, criticidad del activo, identidad, exposición comercial, estado de contención y tiempo.
Alerta, Evento, Incidente y Ofensa: las diferencias que todo analista debe conocer
Un Evento es un registro o actividad observada; una Alerta es una notificación creada cuando un mecanismo de detección encuentra una coincidencia o anomalía; un Incidente es una colección de hallazgos que se ha determinado que requiere investigación y respuesta; una Ofensa es el objeto de investigación de IBM QRadar, creado a partir de la correlación de Eventos y Flujos según las Reglas. Los términos no son idénticos entre productos, por lo que un analista debe comprender tanto el significado general como el modelo de datos de la herramienta con la que trabaja.
Métricas de SOC: los indicadores que realmente mejoran la detección y respuesta
Las buenas métricas de SOC conectan velocidad, calidad, cobertura e impacto. Más allá de las medias de MTTD y MTTR, es aconsejable medir el tiempo de Triage y Cierre por percentiles, la tasa de falsos/benignos positivos, el tiempo sin propietario, la calidad de las escalaciones, la disponibilidad de las fuentes de logs, la cobertura de los casos de uso, los incidentes recurrentes y la carga por analista. Cada KPI debe conducir a una decisión; una métrica que se puede “mejorar” sin mejorar la protección es una métrica peligrosa.
¿Qué es SIEM y cómo funciona desde la recopilación de logs hasta el Incidente?
SIEM — Security Information and Event Management — es un sistema que centraliza los datos de seguridad de múltiples fuentes, convierte los diferentes registros en información que se puede buscar y comparar, ejecuta la lógica de detección y organiza los hallazgos como alertas o incidentes para su investigación. El valor no reside en el mero almacenamiento de los logs, sino en la capacidad de conectar el tiempo, el usuario, el activo, la dirección IP y el comportamiento en una historia que el analista puede verificar y sobre la cual puede actuar.
KQL para principiantes: Primeras consultas para la investigación de incidentes
KQL — Kusto Query Language — es un lenguaje de consulta para leer y analizar datos en productos como Azure Monitor y Microsoft Sentinel. Una consulta generalmente comienza con una tabla y continúa con una tubería de comandos: filtran tiempo y eventos, seleccionan o crean campos, resumen por usuario o activo y muestran los resultados relevantes para la investigación. La clave para aprender es comenzar con una pregunta y construir la consulta paso a paso.
Microsoft Sentinel: Guía de investigación de incidentes para analistas principiantes
La investigación de incidentes en Microsoft Sentinel comienza con la comprensión del caso: qué alertas se agruparon, quiénes son las entidades, cuál es la gravedad y cuál es el origen de la detección. Luego, el analista verifica usuarios y activos, examina la evidencia y la línea de tiempo, ejecuta KQL complementario, documenta decisiones y realiza escaladas o respuestas. Un incidente es un caso de trabajo, no una prueba de que el ataque tuvo éxito, por lo que la clasificación debe basarse en evidencia y contexto.
¿Cómo se escribe una regla de análisis en Microsoft Sentinel?
Una buena regla de análisis en Microsoft Sentinel comienza con el comportamiento que se desea detectar y las fuentes que pueden probarlo. Luego se escribe KQL que devuelve una unidad de investigación clara, se define la frecuencia y el período de búsqueda, se mapean las entidades, se determina la severidad y MITRE, se elige el agrupamiento y se realizan pruebas y ajustes. El objetivo de la regla no es generar muchas alertas, sino crear incidentes que puedan entenderse, verificarse y sobre los que se pueda actuar.
SPL para principiantes: búsqueda e investigación en Splunk
SPL — Search Processing Language — es el lenguaje de búsqueda de Splunk. La búsqueda comienza seleccionando datos por tiempo, índice, sourcetype y términos, y continúa con comandos Pipe que filtran, crean campos, resumen y muestran resultados. Para un analista SOC, es importante aprender primero la búsqueda precisa, stats y eval, y solo después consultas complejas. Cada resultado es un punto de investigación que debe validarse contra los eventos brutos.
Splunk Enterprise Security: de la detección a la investigación
La investigación de un incidente en Splunk Enterprise Security comienza con la comprensión de la detección y la entidad a la que apunta, continúa con la verificación de los eventos contribuyentes, el enriquecimiento de activos e identidades, la construcción de un Timeline y la búsqueda de actividad relacionada, y finaliza con la disposición, la documentación y la retroalimentación para la detección. En las versiones de Splunk ES 8, los términos Finding y Analyst Queue son más comunes; en versiones anteriores, a menudo verá Notable e Incident Review.
Offense de QRadar: Cómo leer e investigar un Offense
Un Offense en QRadar es un caso priorizado que se genera cuando el Custom Rules Engine correlaciona Events o Flows según una regla. Una investigación profesional no comienza y termina con la Magnitud: se debe comprender la regla que disparó el Offense, abrir los eventos y los flujos que contribuyen, verificar la Fuente, el Destino, los activos, el tiempo y el contexto empresarial, y luego documentar una decisión y una Razón de cierre.
Reglas y Building Blocks de QRadar: Guía práctica
En QRadar, una Regla es un conjunto de Tests que dispara una Respuesta cuando se cumplen las condiciones. Un Building Block utiliza los mismos Tests para describir un grupo o lógica recurrente, pero no dispara una Respuesta por sí mismo. Una buena planificación comienza con el Caso de Uso y los datos, ordena los Tests desde los más baratos y restrictivos hasta los más caros, utiliza el Estado y los conjuntos de referencia con precaución, y se prueba antes de su implementación en producción.
Elastic Security: Creación de Reglas de Detección y Guía de Investigación
Una buena Regla de Detección en Elastic Security comienza con el comportamiento a identificar y los datos disponibles, no con la elección de un lenguaje aleatorio. Se selecciona el tipo de regla adecuado, se validan ECS y los campos, se escribe la Query, se definen Schedule y Lookback, Risk y Severity, Suppression y Exceptions, y se adjunta una Guía de Investigación que guía al analista a través del Triage, Análisis y Respuesta.
EQL vs. ES|QL: Cuándo usar cada lenguaje en investigaciones de seguridad
EQL es adecuada cuando el orden de los eventos y su relación son el centro de la pregunta: un Proceso se inició, luego se creó una comunicación, o un evento esperado no apareció. ES|QL es adecuada cuando se necesita un Pipeline de filtrado, cálculo, modificación de campos, agregación y estadísticas. Si la coincidencia con un solo campo es suficiente, una Custom query puede ser más sencilla que ambas.
Cómo conectar un origen de logs a un SIEM y asegurar la fiabilidad de la información
La conexión de un origen de logs a un SIEM es un proceso en el que se definen casos de uso, se verifica la fuente de datos, se comprueba el parsing y la normalización, se ejecutan pruebas de calidad y se asegura que la salida permite la investigación y no solo la presentación de alertas.
Ajuste de SIEM: Cómo reducir la fatiga de alertas sin comprometer la cobertura
El ajuste de SIEM es un proceso en el que se define un caso de uso, se valida la fuente de datos, se verifica el análisis sintáctico y la normalización, se ejecutan pruebas de calidad y se asegura que la salida permita la investigación y no solo la presentación de alertas.
Windows Event Logs para analistas SOC: Por dónde empezar
Los Windows Event Logs para un analista SOC requieren la lectura del evento completo y no solo del Event ID: tiempo, ordenador, usuario, Logon ID, proceso, origen de la red y contexto organizacional. La conclusión se crea a partir de la correlación entre varias fuentes.
Event ID 4624 y 4625: Investigación de inicios de sesión exitosos y fallidos
Event ID 4624 y 4625 requiere leer el evento completo y no solo el Event ID: tiempo, computadora, usuario, Logon ID, Proceso, fuente de red y contexto organizacional. La conclusión se basa en la correlación entre varias fuentes.
Event ID 4688: Análisis de la creación de procesos en Windows
El Event ID 4688 requiere la lectura completa del evento, no solo del ID del evento: tiempo, equipo, usuario, ID de inicio de sesión, proceso, origen de red y contexto organizacional. La conclusión se basa en la correlación de varias fuentes.
Registro de PowerShell: cómo identificar actividad sospechosa
El registro de PowerShell requiere la lectura del evento completo y no solo del ID de evento: tiempo, ordenador, usuario, ID de inicio de sesión, proceso, origen de red y contexto organizacional. La conclusión se crea a partir de la correlación entre varias fuentes.
Sysmon para principiantes: instalación, eventos e integración en SIEM
Sysmon para principiantes requiere la lectura del evento completo y no solo del Event ID: tiempo, ordenador, usuario, Logon ID, proceso, origen de red y contexto organizacional. La conclusión se crea a partir de la correlación entre varias fuentes.
Sysmon Event ID 1: Construcción de un árbol de procesos para la investigación
Sysmon Event ID 1 requiere leer el evento completo y no solo el ID del evento: hora, equipo, usuario, ID de inicio de sesión, proceso, fuente de red y contexto organizacional. La conclusión se crea a partir de la correlación entre varias fuentes.
Sysmon Event ID 3 y 22: Conexiones de red y consultas DNS
Sysmon Event ID 3 y 22 requiere la lectura completa del evento y no solo del Event ID: hora, equipo, usuario, Logon ID, Proceso, fuente de red y contexto organizacional. La conclusión se genera por la correlación entre varias fuentes.
Registros de Active Directory: fuentes de información cruciales para la investigación
Los registros de Active Directory requieren la lectura del evento completo y no solo del ID de evento: tiempo, equipo, usuario, ID de inicio de sesión, proceso, fuente de red y contexto organizacional. La conclusión se crea a partir de la correlación de varias fuentes.
Investigación de Password Spray en Active Directory y Entra ID
La investigación de Password Spray requiere la lectura del evento completo y no solo del Event ID: tiempo, ordenador, usuario, Logon ID, proceso, origen de red y contexto organizacional. La conclusión se forma correlacionando varias fuentes.
Investigación de fuerza bruta: cómo diferenciar un fallo de un ataque
La investigación de fuerza bruta requiere la lectura completa del evento y no solo del Event ID: tiempo, ordenador, usuario, Logon ID, proceso, origen de red y contexto organizacional. La conclusión se basa en la correlación entre varias fuentes.
Investigación de escalada de privilegios en Windows mediante registros
La investigación de escalada de privilegios en Windows requiere leer el evento completo y no solo el ID de Evento: tiempo, ordenador, usuario, ID de inicio de sesión, proceso, origen de red y contexto organizacional. La conclusión se forma correlacionando varias fuentes.
Investigación de Movimiento Lateral en Entornos de Dominio de Windows
La investigación de Movimiento Lateral requiere leer el evento completo y no solo el ID del evento: tiempo, equipo, usuario, ID de inicio de sesión, proceso, origen de red y contexto organizacional. La conclusión se forma a partir de la correlación de varias fuentes.
Wireshark para principiantes: Un proceso estructurado para analizar archivos PCAP
El análisis de PCAP en Wireshark se realiza mapeando el flujo, los tiempos, los protocolos, DNS/TLS/HTTP y la conexión con el activo. Un solo paquete o conexión es una evidencia parcial, por lo que se construye una secuencia y se verifica con fuentes adicionales.
Wireshark Display Filters: filtros útiles para la investigación de eventos
Los Wireshark Display Filters se realizan mapeando el flujo, los tiempos, los protocolos, DNS/TLS/HTTP y la conexión al activo. Un paquete o una conexión única son pruebas parciales, por lo que se construye una secuencia y se verifica con fuentes adicionales.
Follow TCP Stream: Cómo reconstruir una conversación sospechosa
Follow TCP Stream se realiza mapeando el Flow, los tiempos, los protocolos, DNS/TLS/HTTP y la conexión al activo. Un solo paquete o conexión es una evidencia parcial, por lo que se construye una secuencia y se valida con fuentes adicionales.
Análisis de DNS malicioso: Tunneling, DGA y anomalías de dominio
El análisis de DNS malicioso se realiza mapeando el flujo, los tiempos, los protocolos, DNS/TLS/HTTP y la conexión con el activo. Un solo paquete o conexión es una evidencia parcial, por lo que se construye una secuencia y se verifica con fuentes adicionales.
Análisis de tráfico HTTP sospechoso en Wireshark
El análisis HTTP en Wireshark se realiza mapeando el flujo, los tiempos, los protocolos, DNS/TLS/HTTP y la conexión con el activo. Un solo paquete o conexión es una evidencia parcial, por lo que se construye una secuencia y se valida con fuentes adicionales.
Zeek Logs: Cómo investigar conn.log, dns.log y http.log
La investigación de Zeek Logs se realiza mapeando Flow, tiempos, protocolos, DNS/TLS/HTTP y el contexto del activo. Un solo paquete o conexión es una evidencia parcial, por lo que se construye una secuencia y se valida con fuentes adicionales.
Suricata EVE JSON: De la alerta a la PCAP y el flujo de red
Suricata EVE JSON se realiza mapeando el flujo, los tiempos, los protocolos, DNS/TLS/HTTP y el contexto del activo. Un único paquete o conexión es una evidencia parcial, por lo que se construye una secuencia y se verifica con fuentes adicionales.
IDS vs IPS vs NDR: ¿Cuál es la diferencia y qué información recibe el SOC?
IDS vs IPS vs NDR se realiza mapeando el flujo, los tiempos, los protocolos, DNS/TLS/HTTP y la conexión con el activo. Un paquete o una única conexión son pruebas parciales, por lo que se construye una secuencia y se verifica con fuentes adicionales.
Cómo identificar Command and Control en el tráfico de red
La identificación de Command and Control se realiza mediante el mapeo de Flujos, tiempos, protocolos, DNS/TLS/HTTP y el contexto del activo. Un paquete o una conexión única son pruebas parciales, por lo que se construye una secuencia y se verifica con fuentes adicionales.
Construcción de Network Timeline a partir de conexiones TCP, DNS, HTTP y TLS
Network Timeline se realiza mediante el mapeo de Flow, tiempos, protocolos, DNS/TLS/HTTP y la conexión con el activo. Un solo paquete o conexión es una evidencia parcial, por lo que se construye una secuencia y se verifica con fuentes adicionales.
Respuesta a Incidentes según NIST SP 800-61r3: Guía Práctica
Incident Response según NIST es un proceso controlado que equilibra la contención de daños con la preservación de evidencias. Se documenta la fuente, el tiempo y la herramienta, se guarda el Hash, se construye una línea de tiempo y se separa el hecho, la interpretación y la decisión.
Plan de Respuesta a Incidentes vs. Playbook: ¿Cuál es la diferencia?
El Plan de Respuesta a Incidentes frente al Playbook es un proceso controlado que equilibra la contención de daños con la preservación de pruebas. Se documenta la fuente, el tiempo y las herramientas, se guarda el Hash, se construye una línea de tiempo y se separa el hecho, la interpretación y la decisión.
Recopilación de pruebas digitales sin comprometer su integridad
La recopilación de pruebas digitales es un proceso controlado que equilibra la contención de daños con la preservación de pruebas. Se documenta la fuente, el tiempo y las herramientas, se guarda un Hash, se construye una línea de tiempo y se separa el hecho de la interpretación y la decisión.
Orden de volatilidad en la investigación digital: qué se recopila primero y por qué
El orden de volatilidad es un proceso controlado que equilibra la contención de daños con la preservación de pruebas. Se documenta la fuente, el tiempo y la herramienta, se guarda el Hash, se construye una línea de tiempo y se separa el hecho, la interpretación y la decisión.
Análisis forense de memoria para principiantes: qué se puede aprender de la memoria de un ordenador
El análisis forense de memoria para principiantes es un proceso controlado que equilibra la contención de daños con la preservación de pruebas. Se documentan la fuente, el tiempo y las herramientas, se guarda el hash, se construye una línea de tiempo y se separa el hecho, la interpretación y la decisión.
Análisis forense de disco para principiantes: Archivos, metadatos y cronología
El análisis forense de disco para principiantes es un proceso controlado que equilibra la contención del daño con la preservación de pruebas. Se documenta la fuente, el tiempo y la herramienta, se guarda el Hash, se construye una cronología y se distingue entre hecho, interpretación y decisión.
Malware Triage: Examen inicial seguro de un archivo sospechoso
Malware Triage es un proceso controlado que equilibra la contención del daño con la preservación de las pruebas. Se documenta el origen, la hora y las herramientas, se guarda el Hash, se construye una línea de tiempo y se separa el hecho, la interpretación y la decisión.
Análisis de Malware Estático vs. Dinámico: qué se prueba en cada método
El análisis de malware estático vs. dinámico es un proceso controlado que equilibra la contención de daños con la preservación de pruebas. Se documenta la fuente, el tiempo y las herramientas, se guarda el Hash, se construye una línea de tiempo y se separa el hecho, la interpretación y la decisión.
Escritura de la primera regla YARA para la detección de archivos sospechosos
La escritura de una regla YARA es un proceso controlado que equilibra la contención del daño con la preservación de pruebas. Se documentan la fuente, el tiempo y las herramientas, se guarda el Hash, se construye una línea de tiempo y se separa el hecho, la interpretación y la decisión.
Investigación de Phishing de extremo a extremo
La investigación de phishing es un proceso controlado que equilibra la contención de daños con la preservación de pruebas. Se documentan el origen, el tiempo y las herramientas, se guarda el Hash, se construye una línea de tiempo y se separa el hecho de la interpretación y la decisión.
Análisis de cabeceras de correo electrónico: SPF, DKIM, DMARC y Received
El análisis de cabeceras de correo electrónico es un proceso controlado que equilibra la contención de daños con la preservación de pruebas. Se documentan la fuente, el tiempo y las herramientas, se guarda el Hash, se construye una línea de tiempo y se separa entre hechos, interpretación y decisión.
Investigación de Business Email Compromise y Reglas de Bandeja de Entrada
La investigación de BEC es un proceso controlado que equilibra la contención de daños con la preservación de evidencias. Se documenta la fuente, el tiempo y las herramientas, se guarda el Hash, se construye una línea de tiempo y se separa el hecho de la interpretación y la decisión.
Investigación de Ransomware: Los primeros 60 minutos
La investigación de Ransomware es un proceso controlado que equilibra la contención del daño con la preservación de pruebas. Se documenta el origen, el tiempo y las herramientas, se guarda el Hash, se construye una línea de tiempo y se separa el hecho, la interpretación y la decisión.
Cómo elaborar un Post-Incident Review y Lecciones Aprendidas
Un Post-Incident Review es un proceso controlado que equilibra la contención de daños con la preservación de pruebas. Se documentan el origen, la hora y las herramientas, se guarda el Hash, se construye una línea de tiempo y se separa el hecho, la interpretación y la decisión.
Cadena de Custodia: Documentación de Evidencias en una Investigación de Ciberseguridad
La Cadena de Custodia en ciberseguridad es un proceso controlado que equilibra la contención del daño con la preservación de la evidencia. Se documentan la fuente, el tiempo y las herramientas, se guarda el Hash, se construye una línea de tiempo y se separa el hecho, la interpretación y la decisión.
Threat Hunting para principiantes: de la hipótesis a los hallazgos
El Threat Hunting para principiantes comienza con una pregunta o comportamiento a identificar, continúa con la definición de Telemetry y la lógica, y termina con pruebas, tuning, documentación y despliegue controlado. La calidad se mide por la cobertura y la capacidad de investigación.
IOC vs. IOA: Cuál es la diferencia y cómo utilizarlos
IOC vs. IOA comienza con una pregunta o comportamiento que se desea identificar, continúa con la definición de telemetría y lógica, y termina con pruebas, ajuste, documentación y despliegue controlado. La calidad se mide por la cobertura y la capacidad de investigación.
MITRE ATT&CK para analistas SOC: mapeo de alertas a técnicas
MITRE ATT&CK para analistas SOC comienza con una pregunta o comportamiento a identificar, continúa con la definición de Telemetry y lógica, y finaliza con pruebas, ajuste, documentación y despliegue controlado. La calidad se mide por la cobertura y la capacidad de investigación.
Ingeniería de Detección: Cómo convertir el comportamiento malicioso en una regla de detección
La Ingeniería de Detección comienza con una pregunta o comportamiento que se desea identificar, continúa con la definición de telemetría y lógica, y finaliza con pruebas, ajuste, documentación y un despliegue controlado. La calidad se mide por la cobertura y la capacidad de investigación.
Reglas Sigma: escritura, prueba y conversión a SIEM
Escribir reglas Sigma comienza con una pregunta o comportamiento a identificar, continúa con la definición de telemetría y lógica, y finaliza con pruebas, ajuste, documentación y despliegue controlado. La calidad se mide por la cobertura y la capacidad de investigación.
Detection as Code: Gestión de reglas de detección en Git
Detection as Code comienza con una pregunta o comportamiento que se desea detectar, continúa con la definición de telemetría y lógica, y finaliza con pruebas, ajuste, documentación y despliegue controlado. La calidad se mide por la cobertura y la capacidad de investigación.
Ciclo de vida de Threat Intelligence: de la recopilación a la acción
El ciclo de vida de Threat Intelligence comienza con una pregunta o comportamiento a identificar, continúa con la definición de Telemetry y lógica, y termina con pruebas, ajuste, documentación e implementación controlada. La calidad se mide por la cobertura y la capacidad de investigación.
STIX y TAXII: Cómo compartir inteligencia de amenazas
STIX y TAXII comienza con una pregunta o comportamiento a identificar, continúa con la definición de telemetría y lógica, y termina con pruebas, ajuste, documentación y despliegue controlado. La calidad se mide por la cobertura y la capacidad de investigación.
Threat Hunting en Windows con Sysmon
Threat Hunting con Sysmon comienza con una pregunta o comportamiento que se desea identificar, continúa con la definición de telemetría y lógica, y termina con pruebas, ajuste, documentación y despliegue controlado. La calidad se mide por la cobertura y la capacidad de investigación.
Purple Team: Cómo conectar PT para mejorar las capacidades del SOC
Purple Team comienza con una pregunta o comportamiento que se desea identificar, continúa con la definición de Telemetry y lógica, y termina con pruebas, ajuste, documentación y despliegue controlado. La calidad se mide por la cobertura y la capacidad de investigación.
Metodología de Penetration Testing: De Scope a Retest
La metodología de Penetration Testing debe realizarse únicamente dentro de un alcance (Scope) y reglas de compromiso (Rules of Engagement) aprobados. El proceso incluye la recopilación de información, validación controlada, evidencia, evaluación de riesgos, remediación y retest.
Rules of Engagement y Scope en pruebas de penetración
Las Rules of Engagement en las pruebas de penetración deben realizarse solo dentro de un Scope y unas Rules of Engagement aprobadas. El proceso incluye la recopilación de información, verificación controlada, evidencia, evaluación de riesgos, remediación y retest.
Reconocimiento pasivo frente a activo en pruebas de penetración autorizadas
El reconocimiento pasivo frente a activo debe realizarse únicamente dentro de un alcance y reglas de engagement aprobados. El proceso incluye recopilación de información, validación controlada, evidencia, evaluación de riesgos, remediación y retest.
Enumeración: Cómo mapear servicios y usuarios en un entorno de laboratorio
La enumeración en pruebas de penetración solo debe realizarse dentro de un alcance y reglas de compromiso aprobados. El proceso incluye recopilación de información, validación controlada, evidencia, evaluación de riesgos, remediación y nuevas pruebas.
Evaluación de vulnerabilidades frente a Pruebas de Penetración: ¿Cuál es la diferencia?
La Evaluación de Vulnerabilidades frente a las Pruebas de Penetración solo deben realizarse dentro de un Alcance y Reglas de Compromiso aprobados. El proceso incluye recopilación de información, validación controlada, evidencia, evaluación de riesgos, remediación y nuevas pruebas.
Network Penetration Testing: Proceso de prueba completo en laboratorio
El Network Penetration Testing debe realizarse solo dentro de un alcance (Scope) y reglas de compromiso (Rules of Engagement) aprobados. El proceso incluye recopilación de información, validación controlada, evidencia, evaluación de riesgos, remediación y retest.
Active Directory Penetration Testing: Guía de pruebas y defensa
Active Directory Penetration Testing debe realizarse únicamente dentro de un alcance y reglas de compromiso aprobados. El proceso incluye recopilación de información, verificación controlada, evidencia, evaluación de riesgos, remediación y retest.
Escalada de privilegios en Windows en un laboratorio autorizado: metodología de prueba
La escalada de privilegios en Windows debe realizarse únicamente dentro de un alcance y reglas de compromiso aprobados. El proceso incluye recopilación de información, verificación controlada, evidencia, evaluación de riesgos, remediación y nuevas pruebas.
Escalada de Privilegios en Linux en un Laboratorio Autorizado: Metodología de Pruebas
La escalada de privilegios en Linux debe realizarse únicamente dentro de un Scope y Rules of Engagement aprobados. El proceso incluye recopilación de información, verificación controlada, Evidence, evaluación de riesgos, remediación y Retest.
Redacción de un informe de prueba de penetración que conduzca a la corrección
La redacción de un informe de prueba de penetración debe realizarse solo dentro de un alcance y reglas de compromiso aprobados. El proceso incluye la recopilación de información, verificación controlada, evidencia, evaluación de riesgos, remediación y reevaluación.
Metodología de pruebas de penetración de aplicaciones web según OWASP WSTG
Las pruebas de penetración de aplicaciones web solo se realizan en un laboratorio o en un sistema autorizado. Se examinan Request/Response, el comportamiento del servidor, roles, estado e impacto, utilizando pruebas mínimas que no dañan los datos.
OWASP Top 10:2025 — Guía para Pen Testers
OWASP Top 10 2025 se prueba solo en un laboratorio o sistema autorizado. Se examinan Request/Response, comportamiento del servidor, Roles, State y el impacto, utilizando pruebas mínimas que no dañan los datos.
Burp Suite para principiantes: Proxy, Repeater e Intruder en laboratorio
Burp Suite para principiantes solo se prueba en un laboratorio o en un sistema autorizado. Se examinan Request/Response, el comportamiento del servidor, Roles, State y el impacto, utilizando pruebas mínimas que no dañen los datos.
Broken Access Control: Cómo probar los permisos en una aplicación
La prueba de Broken Access Control se realiza solo en laboratorio o en un sistema autorizado. Se examinan el Request/Response, el comportamiento del servidor, los Roles, el State y el impacto, utilizando pruebas mínimas que no dañan los datos.
IDOR y BOLA: Prueba de permisos a nivel de objeto
IDOR BOLA se prueba solo en laboratorio o en un sistema autorizado. Se examinan Request/Response, el comportamiento del servidor, los Roles, el Estado y el impacto, utilizando pruebas mínimas que no dañan los datos.
Authentication Failures: Pruebas de mecanismos de inicio de sesión
La prueba de Authentication Failures solo se realiza en un laboratorio o sistema autorizado. Se examina la Solicitud/Respuesta, el comportamiento del servidor, los Roles, el Estado y el impacto, utilizando pruebas mínimas que no dañen los datos.
Seguridad de Sesión: Cookies, Tokens y Fijación de Sesión
La seguridad de sesión solo se prueba en un laboratorio o en un sistema autorizado. Se examinan Request/Response, el comportamiento del servidor, los Roles, el State y el impacto, utilizando pruebas mínimas que no dañen los datos.
Inyección SQL: Detección y verificación segura en laboratorio
Las pruebas de inyección SQL solo se realizan en un laboratorio o en un sistema autorizado. Se examina la solicitud/respuesta, el comportamiento del servidor, los roles, el estado y el impacto, utilizando pruebas mínimas que no comprometen los datos.
Cross-Site Scripting: Stored, Reflected y DOM
La prueba de XSS solo se realiza en laboratorio o en un sistema autorizado. Se examina Request/Response, el comportamiento del servidor, los Roles, el State y el impacto, utilizando pruebas mínimas que no dañen los datos.
SSRF: Cómo identificar y verificar de forma segura
La prueba de SSRF solo se realiza en laboratorio o en un sistema autorizado. Se examinan Request/Response, comportamiento del servidor, Roles, State e impacto, utilizando pruebas mínimas que no comprometan los datos.
Vulnerabilidades de Carga de Archivos: Pruebas y Riesgos
La prueba de Carga de Archivos solo se realiza en un laboratorio o sistema autorizado. Se examinan el Request/Response, el comportamiento del servidor, los Roles, el State y el impacto, utilizando pruebas mínimas que no dañen los datos.
Path Traversal y Local File Inclusion: Cómo probar de forma segura
La prueba de Path Traversal solo se realiza en laboratorio o en un sistema autorizado. Se examinan Request/Response, el comportamiento del servidor, Roles, State e impacto, utilizando pruebas mínimas que no dañen los datos.
Inyección de Comandos: Identificación, Verificación y Prevención
La prueba de Inyección de Comandos solo se realiza en laboratorio o en un sistema autorizado. Se examina la Solicitud/Respuesta, el comportamiento del servidor, los Roles, el Estado y el impacto, utilizando pruebas mínimas que no dañen los datos.
API Penetration Testing: Proceso de trabajo completo
Las pruebas de API Penetration Testing solo se realizan en laboratorio o en un sistema autorizado. Se examinan Request/Response, el comportamiento del servidor, Roles, State e impacto, utilizando pruebas mínimas que no dañen los datos.
OWASP API Security Top 10:2023 para PenTesters
OWASP API Security Top 10 2023 se prueba solo en laboratorio o en un sistema autorizado. Se examinan Request/Response, comportamiento del servidor, Roles, State e impacto, utilizando pruebas mínimas que no dañan los datos.
Investigación de una cuenta sospechosa de Microsoft 365: Entra, Mailbox y Defender
La investigación de una cuenta de Microsoft 365 requiere la conexión entre Identity, Audit Logs, API actions, recursos, regiones y sesiones. Se comienza conservando la evidencia y construyendo una línea de tiempo, y solo después se realiza una contención documentada.
Investigación de credenciales de AWS sospechosas con CloudTrail y GuardDuty
La investigación de credenciales de AWS requiere conectar la identidad, los registros de auditoría, las acciones de la API, los recursos, las regiones y las sesiones. Se comienza conservando la evidencia y construyendo una línea de tiempo, y solo después se realiza una contención documentada.
Investigación de incidentes de seguridad en Azure: Sentinel, Entra y Defender
La investigación de incidentes de seguridad en Azure requiere la conexión entre Identidad, Registros de auditoría, acciones de API, recursos, Regiones y Sesiones. Se comienza conservando la evidencia y construyendo una línea de tiempo, y solo después se realiza una contención documentada.
Investigación de incidentes en Google Cloud con Audit Logs y Security Command Center
La investigación de incidentes en Google Cloud requiere conectar la identidad, los Audit Logs, las acciones de la API, los recursos, las regiones y las sesiones. Se comienza preservando la evidencia y construyendo una línea de tiempo, y solo después se realiza una contención documentada.
IA para analistas SOC: uso seguro para el resumen de registros, KQL y documentación
La IA para analistas SOC puede mejorar la velocidad y el orden, pero no reemplaza la experiencia o la visión. Es necesario minimizar la información, eliminar secretos, validar la salida frente a la fuente, documentar el Prompt y dejar la decisión final en manos de un profesional.
IA para Penetration Tester: Planificación, análisis e informe sin exponer información sensible
La IA para Penetration Tester puede mejorar la velocidad y la organización, pero no reemplaza la experiencia o la visión. Es necesario reducir la información, eliminar secretos, verificar la salida frente a la fuente, documentar el Prompt y dejar la decisión final en manos de un profesional.