Conceptos

Auditoría y monitorización de seguridad

#defense#governance#grc#logging#risk#soc

En operaciones y ciberseguridad suelen convivir cuatro conceptos que se apoyan entre sí:

Definición

En operaciones y ciberseguridad suelen convivir cuatro conceptos que se apoyan entre sí:

  • Registro (logging): captura de eventos cuando ocurren (p.ej., inicios de sesión, errores, cambios de configuración).
  • Monitoreo/monitorización: observación continua (casi en tiempo real) del estado y comportamiento de sistemas/redes, con alertas.
  • Auditoría: proceso sistemático, independiente y objetivo de recopilar/evaluar evidencia para verificar cumplimiento y eficacia de controles.
  • SIEM: plataforma que centraliza logs/eventos, los agrega/correlaciona y ayuda a detectar, alertar e investigar.

Nota importante sobre el RAW: aparecen términos (“Explotación florestal”, “Escucha”, “Revisión de cuentas”) usados como etiquetas para registro/monitoreo/auditoría. En esta nota se usan los nombres estándar y se conserva el texto original al final.

Contexto

  • Un programa de cumplimiento no se demuestra solo con formación. El RAW usa un ejemplo (hospital + protección de datos): aunque la formación sea necesaria, pueden existir desviaciones operativas (USBs, fotos de pantalla, eliminación incorrecta de papel) que requieren controles, monitoreo y auditoría.
  • La auditoría y el monitoreo conectan GRC y SOC:
  • Relación directa con IAAA: “Accountability” depende de logs de calidad e integridad (ver IAAA - Identification Authentication Authorization Accountability).

Desarrollo (MIT-style)

1) Auditoría (qué es y qué responde)

La auditoría responde preguntas como:

  • ¿Cumplimos leyes/estándares aplicables?
  • ¿Son eficaces los controles y la gestión de riesgos?
  • ¿Se detecta/previene uso indebido, fraude o abuso de recursos?

En términos prácticos: una auditoría no es “mirar papeles”; es evaluar evidencia (técnica y procedimental) contra criterios (política interna y/o estándar).

2) Tipos de auditoría

Según quién la realiza (RAW):

  • Interna: por personal propio o función de auditoría interna.
  • Externa: por terceros independientes (más imparcial; suele ser más costosa).
  • De terceros: para evaluar controles de proveedores/subcontratistas (supply chain).

Buenas prácticas:

  • Ejecutar auditorías internas antes de externas para reducir “sorpresas”.
  • Tratar auditoría de terceros como contrato de seguridad: alcance, evidencias, periodicidad y acciones correctivas.

3) Marcos (frameworks) de auditoría comunes

Del RAW:

  • COSO: control interno y gestión de riesgos empresariales.
  • COBIT: gobierno y gestión de TI.
  • ISAE 3402: aseguramiento de controles (entornos de servicios).
  • ISO 27001: SGSI (gestión de seguridad de la información).
  • ITIL: buenas prácticas de ITSM.
  • PCI DSS: requisitos para organizaciones que procesan tarjetas.
  • SOX: requisitos de auditoría/información financiera para empresas cotizadas (EE. UU.).

Cómo elegir marco (regla práctica):

  • Parte de obligación legal/contractual → mapea a estándares (p.ej., PCI DSS).
  • Parte de gobierno de TI → COBIT/ITIL.
  • Parte de seguridad de la información → ISO 27001.
  • Parte de control interno financiero → COSO/SOX/ISAE (según contexto).

4) Proceso de auditoría (end-to-end)

El RAW describe 7 etapas:

  1. Planificación: alcance, objetivos, plazos, riesgos y controles a evaluar.
  2. Recopilación de información: entrevistas, documentación, políticas, evidencias.
  3. Evaluación de riesgos y controles: identificar vulnerabilidades y eficacia de controles.
  4. Pruebas: muestreo, análisis de datos, escaneo, pentest (según alcance).
  5. Análisis y hallazgos: desviaciones/irregularidades e impacto.
  6. Informes: reporte formal + recomendaciones.
  7. Seguimiento: verificar implementación y efectividad de acciones correctivas.

Versión “operativa” (RAW): Planificación → Ejecución → Evaluación → Informes → Seguimiento.

Artefactos recomendados (para que la auditoría sea repetible):

  • Matriz control ↔ evidencia ↔ resultado.
  • Inventario de activos en alcance + owners.
  • Registro de entrevistas y muestras.
  • Reporte de hallazgos (formato tipo TEMPLATE__Audit).

5) Áreas típicas a auditar (Sistemas de Información)

Del RAW (ejemplos):

  • Hardware, sistema operativo, sistemas de archivos, bases de datos.
  • Infraestructura y operaciones de red (incluye controles operativos).
  • Operaciones de TI, operaciones sin intervención, gestión de problemas.
  • Operaciones de monitoreo.
  • Adquisiciones.
  • Continuidad de negocio y recuperación ante desastres.

6) Registro (logging): por qué existe

El RAW resume el logging como registro de eventos (errores/operaciones) y enumera usos:

  • Troubleshooting: localizar fallos.
  • Monitoreo: entender rendimiento (CPU, memoria, etc.).
  • Auditoría: quién hizo qué y cuándo.
  • Cumplimiento: evidencias exigidas por normativa.

Buenas prácticas (para que los logs sirvan de verdad):

  • Centralización (evitar que un atacante borre evidencias localmente).
  • Retención definida (por ley/riesgo).
  • Integridad (WORM/immutability cuando aplique) y sincronización de tiempo.
  • Normalización/parseo (campos consistentes) y alertas accionables.

Accountability (IAAA), no repudio y autenticidad de logs

El RAW conecta explícitamente logging con rendición de cuentas (accountability): si no puedes atribuir acciones a identidades (quién hizo qué, cuándo y desde dónde), fallan auditoría, investigación y respuesta a incidentes.

Puntos clave del RAW (ampliados):

  • Autenticidad e integridad: si no puedes demostrar que un log se conservó en su estado original, pierde valor para accountability (p.ej., en un proceso disciplinario, legal o de IR).
  • No repudio (non‑repudiation): capacidad de demostrar que una acción ocurrió y que el actor no puede negarla razonablemente; en threat modeling, esto se modela como la amenaza Repudiation en STRIDE.

Controles prácticos (defensivos) para soportar autenticidad/no repudio:

  • Centralizar fuera del host (syslog/forwarders) y limitar privilegios de borrado/modificación local.
  • Control de acceso fuerte a repositorios de logs (segregación de funciones: quien opera ≠ quien administra evidencias).
  • Inmutabilidad/retención cuando aplique (WORM/objetos inmutables/locks).
  • Sellado temporal: sincronización NTP y timestamps consistentes (sin tiempo, no hay línea temporal fiable).
  • Transporte seguro y verificación (TLS/mTLS según entorno) para evitar manipulación en tránsito.

7) Logs Linux (visión operativa)

Del RAW:

  • Ubicación típica: /var/log.
  • Daemons comunes: rsyslog, syslog-ng, journald.
  • Tipos: sistema, aplicaciones, seguridad.
  • Recomendaciones: centralizar, filtrar/analizar y configurar alertas.

Ejemplo del RAW (auditoría con auditd):

  • aureport --summary / aureport --failed para resúmenes.
  • ausearch -m USER_LOGIN -sv no -i para buscar intentos fallidos.
  • Conteo con grep + wc -l para cuantificar eventos (p.ej., intentos root).

8) Logs Windows (visión operativa)

Del RAW:

  • Tipos: System, Application, Security y Forwarded Events.
  • Política de auditoría (categorías ejemplo): logon, gestión de cuentas, uso de privilegios, acceso a directorio, cambios de política, eventos del sistema.
  • Ejemplos de Event IDs (logon): 4624, 4625, 4634, 4647, 4779.

Nota: para hardening operativo y uso en IR, ver también Windows System Hardening.

9) Monitoreo (monitoring)

El RAW define la monitorización como observación continua de métricas y comportamiento (procesos, transacciones, apps, servidores, red, etc.) para:

  • resolver problemas más rápido,
  • optimizar rendimiento,
  • prevenir fallos,
  • mitigar riesgos de seguridad,
  • demostrar cumplimiento.

Diferencia clave (RAW):

  • Logging = histórico para análisis posterior.
  • Monitoring = continuo/tiempo real para detectar y reaccionar.

10) SIEM (conceptos básicos)

Del RAW: un SIEM recopila/agrega logs de múltiples fuentes (red, sistemas, apps), los analiza/correlaciona y ayuda a:

  • alertas e informes,
  • investigación forense (histórico),
  • integración con threat intel,
  • automatización/orquestación (en casos avanzados).

Nota operativa: SIEM sin buena higiene de logs (fuentes incompletas, sin parseo, sin retención, sin owners) se convierte en “ruido caro”.

Qué aporta un SIEM (baseline)

El RAW lista capacidades típicas en su forma más básica:

  • Ingesta de logs en tiempo real.
  • Alertas ante actividades anómalas (reglas/correlaciones).
  • Monitoreo y visibilidad 24/7 (operación SOC).
  • Dashboards e informes para operación y cumplimiento.
  • Investigación histórica (búsqueda) para incidentes pasados.

Ejemplos mencionados en el RAW: Wazuh, Splunk, ELK, QRadar.

Tipos de registros y fuentes de datos (calidad vs ruido)

El RAW propone clasificar las fuentes (idea práctica para inventariar cobertura):

  • Fuentes manuales: registros escritos/compuestos por personas (p.ej., bitácoras de cambios).
  • Fuentes automatizadas: generadas por el sistema/app/herramienta (p.ej., logs de sistema, logs de aplicación).
  • Otros registros (a menudo por compliance): correo, mensajería/comunicación, etc.

Regla práctica del RAW: una “buena fuente” rara vez es un único log; se combinan fuentes para validarse entre sí (consistencia).
Riesgo complementario: múltiples fuentes duplicando lo mismo pueden aumentar ruido, coste de almacenamiento y fatiga operacional.

Ingesta, indexación y almacenamiento (hot/warm/cold)

El RAW introduce el lifecycle de almacenamiento por coste/rendimiento:

  • Hot storage (caliente): acceso frecuente, alto rendimiento (p.ej., SSD) para investigación reciente y detección.
  • Warm storage (templado): capa intermedia para datos menos consultados.
  • Cold storage (frío): acceso raro, barato (p.ej., discos económicos/cinta) para retención larga.

Ejemplo de política (ilustrativa, adaptar a riesgo/regulación): 6 meses hot → 3 meses warm → 3 años cold.

Nota de cumplimiento del RAW: PCI DSS exige almacenar logs de auditoría durante 1 año y que estén inmediatamente disponibles durante 90 días.

Correlación y enriquecimiento

El RAW describe la correlación como crear relaciones entre eventos/datos para construir hipótesis y contexto.

Ejemplo (RAW, reexplicado):

  • Señal 1: el endpoint registra creación de un archivo DLL sospechoso.
  • Señal 2: el navegador registra búsquedas/descargas relacionadas (posible instalación/“troubleshooting”).
  • Señal 3: registros de correo muestran un phishing cercano en el tiempo. → La combinación permite decidir si fue comportamiento benigno, error operativo o compromiso.

En entornos maduros, la correlación suele apoyarse en enriquecimiento (asset owner, criticidad, geolocalización, inteligencia de amenazas, mapeo a MITRE ATT&CK) para priorizar y reducir falsos positivos.

Ejemplos

  • Hospital + protección de datos (RAW): formación ≠ cumplimiento; se necesitan controles + auditoría periódica para detectar desviaciones (USB, fotos, destrucción incorrecta).
  • Linux: detectar “spraying” de autenticación mediante conteo de eventos fallidos.
  • Windows: revisar eventos 4624/4625 para entender patrones de login (y alimentar correlaciones en SIEM).
  • Correlación multi‑fuente (RAW): combinar endpoint + navegador + correo para explicar un evento sospechoso y priorizar la investigación.

Pitfalls / Errores comunes

  • Confundir “auditar” con “tener documentos”: sin evidencia técnica, la auditoría es cosmética.
  • Logs locales sin centralización/retención: tras un incidente, no hay trazabilidad.
  • Monitoreo sin umbrales y sin respuesta (alertas sin owner/runbook).
  • SIEM sin objetivos de detección ni tuning: demasiados falsos positivos o ceguera.
  • Auditorías de terceros sin alcance claro ni derecho a evidencias: riesgo de supply chain.
  • Tener logs “sin garantías” (sin controles de integridad/AC): el actor puede repudiar acciones o el adversario puede manipular evidencias.
  • Retención definida solo por coste (sin requirements): investigaciones que “llegan tarde” se quedan sin histórico.

Diagrama

flowchart LR
  L[Logging\n(eventos)] --> M[Monitoring\n(alertas/estado)]
  L --> A[Auditoría\n(evidencia vs criterios)]
  L --> S[SIEM\n(agrega/correlaciona)]
  M --> S
  S --> IR[Detección\n+ Investigación]\n
  A --> GRC[Cumplimiento\n+ Mejora continua]
  IR --> GRC

flowchart LR
  SRC[Fuentes\n(endpoints, red, apps, cloud)] --> COL[Collectors/Forwarders]
  COL --> IDX[Indexación/SIEM]
  IDX --> HOT[Hot]
  HOT --> WARM[Warm]
  WARM --> COLD[Cold]

Referencias

  1. TryHackMe — IAAA (pre-requisito recomendado): https://tryhackme.com/room/iaaaidm
  2. Microsoft Learn — Audit Policy (Windows): https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/audit-policy
  3. COSO — Internal Control Framework: https://www.coso.org/sitepages/internal-control.aspx
  4. ISACA — COBIT: https://www.isaca.org/resources/cobit
  5. ISAE 3402 overview: https://isae3402.com/ISAE3402_overview.html
  6. ISO 27001: https://www.iso.org/standard/27001
  7. PCI DSS (Document Library): https://www.pcisecuritystandards.org/document_library/?document=pci_dss
  8. TryHackMe — Wazuh (práctica SIEM): https://tryhackme.com/room/wazuhct
  9. TryHackMe — Splunk 101 (práctica SIEM): https://tryhackme.com/room/splunk101
  10. TryHackMe — Intro to Logs: https://tryhackme.com/room/introtologs
  11. TryHackMe — Auditing and Monitoring: https://tryhackme.com/room/auditingandmonitoringse
  12. MITRE ATT&CK: https://attack.mitre.org/
  13. Microsoft — STRIDE chart: https://www.microsoft.com/en-us/security/blog/2007/09/11/stride-chart/
Título original en mis apuntes: Security Auditing and Monitoring