CompTIA SY0-701: Operaciones de Seguridad, Monitoreo y Detección — Guía de estudio

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Forma parte de la CompTIA Security+ SY0-701 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de CompTIA, o realiza tests cronometrados en ExamRoll.io.

Las operaciones de seguridad modernas dependen de la capacidad de observar, correlacionar y actuar sobre las señales que surgen de todos los rincones de la empresa: endpoints, dispositivos de red, proveedores de identidad, cargas de trabajo en la nube y aplicaciones. Un programa de detección maduro no es un único producto, sino un ecosistema de canalizaciones de telemetría, motores de análisis, analistas humanos y flujos de trabajo de respuesta automatizada, diseñados para comprimir el tiempo entre la intrusión y la contención.

SIEM y Agregación Centralizada de Logs

Una plataforma de Gestión de Información y Eventos de Seguridad (SIEM, por sus siglas en inglés) es el tejido conectivo del centro de operaciones de seguridad. Ingiere logs de fuentes dispares —registros de eventos de Windows, syslog de Linux, datos de flujo de firewall, resolutores de DNS, Active Directory, agentes de endpoint, registros de auditoría de SaaS—, los normaliza en un esquema común y aplica reglas de correlación sobre el flujo agregado. El valor no reside simplemente en el almacenamiento, sino en la capacidad de correlacionar una autenticación VPN fallida en una fuente de logs con un inicio de sesión privilegiado exitoso y un acceso SMB lateral en otra, produciendo una única alerta de alta fidelidad donde tres eventos aislados habrían sido ruido.

Las plataformas comunes incluyen Splunk, Microsoft Sentinel, IBM QRadar, Elastic Security y Chronicle. En entornos de nube, herramientas nativas como AWS CloudTrail combinadas con CloudWatch y GuardDuty, o Azure Monitor con espacios de trabajo de Log Analytics, sirven como la columna vertebral del registro y a menudo alimentan a un SIEM de nivel superior.

Una búsqueda de correlación típica de Splunk que ilustra la lógica entre fuentes:

index=wineventlog EventCode=4625
| stats count by src_ip, user
| where count > 10
| join user [search index=vpn action=success]
| table _time, user, src_ip, count

La trampa aquí es sutil: una organización puede desplegar un SIEM, ingerir terabytes de datos y aun así pasar por alto intrusiones porque faltan fuentes de logs críticas. Si los eventos de creación de procesos en los endpoints (ID de evento de Windows 4688 o ID de evento de Sysmon 1) no se reenvían, o si los logs de denegación del firewall se truncan, fases enteras del ataque se vuelven invisibles. La cobertura de las fuentes de logs —mapeada explícitamente contra un marco como MITRE ATT&CK— es un prerrequisito para una detección significativa.

Detección y Respuesta en Endpoints (EDR)

El EDR extiende la visibilidad al host, donde la mayor parte de la actividad del atacante se manifiesta finalmente. A diferencia del antivirus tradicional, que compara hashes de archivos y firmas, las plataformas de EDR como CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint y Carbon Black registran telemetría continua: árboles de procesos, argumentos de línea de comandos, modificaciones del registro, conexiones de red y cargas de DLL. Estos datos permiten tanto la detección de comportamiento en tiempo real como la búsqueda retrospectiva de amenazas (threat hunting).

Una idea errónea común es tratar el EDR como un control preventivo equivalente a un firewall. El EDR principalmente detecta y asiste en la respuesta; puede bloquear comportamientos maliciosos conocidos, pero su mayor valor reside en proporcionar el rastro forense que permite a un analista determinar qué hizo un proceso comprometido, a qué credenciales accedió y hacia dónde se movió lateralmente. Las acciones de respuesta, como el aislamiento del host, la terminación de procesos y la cuarentena de archivos, suelen ser iniciadas por un analista o un playbook de SOAR, no por el EDR por sí solo.

IDS/IPS, Firmas y Cumplimiento de Líneas Base

Los sistemas de detección y prevención de intrusiones basados en la red (IDS/IPS) inspeccionan el tráfico comparándolo con firmas y modelos de comportamiento. Un IDS (como Snort o Suricata en modo de monitoreo) alerta sobre patrones sospechosos; un IPS se sitúa en línea y descarta el tráfico coincidente. Una regla de Snort para detectar un patrón de exploit específico demuestra la lógica basada en firmas:

alert tcp any any -> $HOME_NET 445 (
  msg:"SMB Exploit Attempt";
  content:"|ff|SMB"; offset:4; depth:4;
  content:"|72 00|"; distance:0;
  sid:9000001; rev:1;
)

La detección basada en anomalías establece una línea base de comportamiento y alerta sobre las desviaciones: una estación de trabajo que de repente comienza a realizar consultas DNS a una tasa 10 veces superior a la normal, o un servidor que abre conexiones salientes en el puerto 4444 por primera vez, ambos casos ameritan una investigación independientemente de si coincide con una firma.

Inteligencia de Amenazas y Gestión de Indicadores

La inteligencia de amenazas transforma datos brutos en conocimiento procesable sobre las tácticas, técnicas y procedimientos (TTPs) del adversario. STIX (Structured Threat Information eXpression) es el formato estándar para representar objetos de inteligencia de amenazas —indicadores, campañas, actores de amenazas, patrones de ataque— mientras que TAXII (Trusted Automated eXchange of Indicator Information) es el protocolo de transporte para compartirlos. Fuentes de inteligencia comerciales y de código abierto (VirusTotal, AlienVault OTX, MISP, Recorded Future) proporcionan reputación de IP, listas de bloqueo de dominios, hashes de archivos y reglas YARA que pueden ser ingeridas directamente en las plataformas SIEM y de firewall.

Los Indicadores de Compromiso (IoCs) —direcciones IP maliciosas, hashes de archivos, nombres de dominio, claves de registro— son la inteligencia más inmediatamente procesable, pero también la más efímera; los atacantes rotan su infraestructura rápidamente. Los Indicadores de Ataque (IoAs) se centran en comportamientos en lugar de artefactos: un proceso que genera un shell hijo, un comando de PowerShell codificado o un servicio creado con un nombre aleatorio. La detección basada en IoA es más difícil de evadir porque se dirige a la técnica, no a la herramienta específica.

Escenario Práctico: Brecha de Detección por Falta de Fuentes de Logs

Una empresa de servicios financieros desplegó un SIEM e ingirió logs del firewall perimetral, registros de eventos de seguridad de Windows y logs del gateway de correo electrónico. Durante un ejercicio de red team, el equipo obtuvo acceso inicial a través de un correo electrónico de phishing (detectado), pero luego utilizó WMI para el movimiento lateral y PowerShell remoting para la ejecución de comandos, ninguno de los cuales generó eventos de seguridad de Windows en la configuración por defecto. El red team llegó a la estación de trabajo de tesorería y exfiltró un archivo de transferencia bancaria simulada sin activar una sola alerta del SIEM después de la detección inicial del phishing. La brecha: Sysmon no estaba desplegado, el registro de bloques de scripts de PowerShell no estaba habilitado y el registro de actividad de WMI requería una configuración adicional. El ejercicio demostró que la cobertura del SIEM es tan buena como las fuentes de logs que lo alimentan, una lección que debe ser validada a través de ejercicios de purple team, no asumida a partir de la documentación del proveedor.

← Seguridad y Arquitectura de Red · Todos los dominios · Respuesta a Incidentes →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →