El Dominio 2 es Vulnerability Management. Identificar, evaluar, priorizar y remediar debilidades antes de que el atacante las aproveche.
Pasar Nessus cada mes y sacar un PDF no es un programa de VM. El valor real está en priorizar con contexto: un CVSS 9.0 en un servidor aislado puede ser menos crítico que un 7.2 en el que procesa tarjetas de crédito.
Desde el diseño del programa hasta controles de mitigación, escaneo, CVSS y desarrollo seguro.
Arquitectura del Programa de Vulnerability Management
Un programa de Vulnerability Management no es solo “pasar Nessus cada mes”.
Es un ciclo de vida continuo con tres fases interconectadas:
CICLO DE VIDA DEL VM PROGRAM
Detection - Escaneo continuo de activos para identificar vulnerabilidades
Remediation - Aplicar parches, controles compensatorios o aceptación documentada
Testing - Re-escaneo para verificar que la remediacion fue efectiva
Flujo completo: Detect → Remediate → Rescan → Update Baseline → Continuous Monitoring
Gobernanza y Stakeholders
El programa requiere gobernanza formal, es decir:
Las políticas que definan frecuencia de escaneo, niveles de riesgo aceptables y flujos de trabajo de remediación.
Los stakeholders clave incluyen al CISO (dirección estratégica) IT Operations (ejecución de parches) y los dueños de negocio (priorización de activos).
La integración con ITSM (IT Service Management) como tenemos en mi trabajo (Helix principalmente) es crítica.
Los tickets de incidencia deben enlazarse con el sistema de gestión de cambios (CRQ) y los escaneos continuos deben diferenciarse del monitoreo continuo.
El escaneo continuo ejecuta evaluaciones periódicas tanto como el monitoreo continuo observa el estado en tiempo real.
Barreras Comunes y Priorización
Las objeciones al escaneo son frecuentes en entornos reales, a tener en cuenta:
- Degradación del servicio.
- Restricciones por MOU (Memorandum of Understanding).
- SLA que prohíben interrupciones.
- Governance de TI que limita las ventanas de mantenimiento.
El analista debe negociar ventanas de escaneo, usar intensidad progresiva y documentar excepciones.
La priorización de vulnerabilidades utiliza cuatro factores:
FACTORES DE PRIORIZACION
Criticality - Importancia del sistema (CIA triad)
Difficulty - Facilidad de explotacion por el atacante
Severity - Puntuacion CVSS de la vulnerabilidad
Exposure - Si el sistema esta expuesto a Internet o es interno
TRAMPA DEL EXAMEN
Un Compensating Control NO es lo mismo que Risk Acceptance.
El control compensatorio reduce activamente el riesgo (ej: WAF para SQLi cuando no se puede parchar) la aceptación reconoce que el riesgo existe y lo documenta como decisión deliberada. El examen te pondrá escenarios donde confundirás uno con otro.
Tipos de Escaneo
Escaneo Activo vs Pasivo
La distinción fundamental que el examen prueba una y otra vez:
ACTIVE vs PASSIVE SCANNING
Activo
Envía paquetes al objetivo.
Ruidoso → puede ser bloqueado por IPS/IDS.
Similar a un atacante real.
Pasivo
Observa trafico sin interactuar.
Silencioso y limitado (solo ve lo que cruza la red).
Funciona como un IDS basado en firmas.
Una cosa clara → Passive scanning es complemento, NO reemplazo del Active scanning.
TRAMPA DEL EXAMEN
El escaneo pasivo NO puede reemplazar al escaneo activo.
Solo detecta lo que es visible en la red en ese momento. Si un servicio no genera trafico durante el periodo de observación, el escaneo pasivo no lo detectara. El examen intentara tentarte con “reemplazar escaneos activos con pasivos para reducir ruido” no caigas, eso es incorrecto.
Escaneo Credentialed vs Non-Credentialed
El escaneo non-credentialed ve la infraestructura desde la perspectiva del atacante: descubre puertos abiertos, servicios expuestos y vulnerabilidades accesibles sin autenticación.
Produce más falsos positivos porque no puede verificar el estado real del parche internamente.
El escaneo credentialed se autentica en el sistema con una cuenta de solo lectura, verificando parches instalados, configuraciones y software desde dentro.
Requiere principio de mínimo privilegio osea la cuenta de escaneo debe ser read-only, sin derechos administrativos.
Escaneo Agent-Based y Perspectivas
El escaneo agent-based instala un agente ligero en cada host que reporta desde dentro, similar al credentialed pero sin requerir credenciales de red.
No es bloqueado por firewalls y permite monitoreo continuo.
Se recomienda despliegue piloto antes de escalar a producción.
Las perspectivas de escaneo determinan que controles afectan los resultados
PERSPECTIVAS DE ESCANEO
External
- Desde fuera del perímetro.
- Atraviesa firewall, IDS/IPS.
- Simula al atacante.
Internal
- Dentro de la red corporativa.
- Ve segmentación interna.
Data Center
Ubicación específica con controles de red dedicados.
TRAMPA DEL EXAMEN
La cuenta de escaneo credentialed debe usar principio de least privilege (solo lectura).
Si el examen muestra un escenario donde la cuenta de escaneo tiene privilegios de administrador, eso es un riesgo de seguridad que debe corregirse, no una prá ctica aceptable.
Herramientas y Configuración
Tipos de Escáneres
CLASIFICACIÓN DE HERRAMIENTAS
Infraestructura
- Nessus - Tenable, scanner comercial más popular
- Qualys - SaaS, sin infraestructura local
- Nexpose - Rapid7, integracion con SIEM
- OpenVAS - Open source, base de Greenbone
Aplicaciones Web
- Nikto - CLI, open source, escaneo rápido
- Arachni - Empaquetado, framework completo
Proxies de Intercepción:
- ZAP - OWASP, open source
- Burp Suite - PortSwigger, free + commercial
Nube:
- AWS Inspector - Nativo AWS
- Scout Suite - Multi-cloud audit (AWS/Azure/GCP)
- Prowler - AWS/Azure/GCP, compliance audit
- Pacu - Framework de EXPLOTACION AWS, NO es scanner
TRAMPA DEL EXAMEN
Pacu es un framework de explotación para AWS, NO un escaner de vulnerabilidades. El examen te pondra Pacu junto a Scout Suite y Prowler esperaran que identifiques cual NO pertenece al grupo de herramientas de auditoría/escaneo.
Configuración de Escaneos y Mantenimiento
La configuración del scanner es crítica
Templates predefinidos vs personalizados, plugin families que determinan que se evalua odangerous plugins que pueden causar denegación de servicio deben probarse primero en entorno de test antes de producción.
El mantenimiento del scanner incluye dos tareas criticas:
Actualizar el software del scanner
Actualizar diariamente el feed de plugins para tener las últimas detecciones.
Requisitos Regulatorios
Dos marcos regulatorios exigen específicamente programas de gestión de vulnerabilidades
PCI DSS vs FISMA
PCI DSS Contractual (NO ley).
Exige: escaneos internos + externos trimestrales, ASV para externos, remediacion de high-risk hasta informe “limpio”, segmentation reduce scope (CDE).
FISMA Ley federal. NIST SP 800-53 RA-5
Monitorrizar vulnerabilidades, herramientas SCAP, analizar reportes, remediar según riesgo, compartir info, actualizar feeds.
TRAMPA DEL EXAMEN
PCI DSS es contractual , no una ley. Muchos creen que es legislacion gubernamental pero no lo es. Lo impone el PCI SSC financiado por la industria de tarjetas de pago. Además, los escaneos externos deben ser realizados por un ASV (Approved Scanning Vendor) autorizado, pero los internos pueden ser realizados por personal cualificado interno.
Los estándares de la industria complementan los requisitos regulatorios:
- CIS Benchmarks (configuraciones consensuadas)
- ISO 27001 (framework del ISMS)
- ISO 27002 (detalles de controles)
- OWASP Top 10
Activos e Identificadores
Asset Discovery y Clasificación
La gestión de vulnerabilidades comienza por saber que tienes.
El Asset Discovery identifica todos los sistemas en la red, incluyendo Shadow IT (sistemas desplegados sin aprobación de TI).
La clasificación determina la frecuencia de escaneo y prioridad de remediación según cuatro criterios
CRITERIOS DE CLASIFICACIÓN DE ACTIVOS
Data Classification - Nivel de sensibilidad de los datos que procesa
Internet Exposure - Expuesto a Internet o solo interno
Services Offered - Que servicios ejecuta (HTTP, SSH, DB…)
Environment Status - Producción, test, desarrollo
El scoping para cumplimiento determina que sistemas caen dentro del alcance regulatorio.
La segmentación de red reduce el alcance de PCI DSS: si el CDE (Cardholder Data Environment) esta aislado correctamente, solo los sistemas dentro del CDE necesitan escaneos ASV.
CVSS v3.1 Métricas y Calculo Completo
El CVSS (Common Vulnerability Scoring System) v3.1 es el estandar para medir la severidad de vulnerabilidades.
El examen requiere conocer las 8 métricas base y como se combinan
CVSS v3.1 - Metricas Base
| Metrica | Valores |
|---|---|
| Attack Vector (AV) | Network (0.85), Adjacent (0.62), Local (0.55), Physical (0.20) |
| Attack Complexity (AC) | Low (0.77), High (0.44) |
| Privileges Required (PR) | None (0.85), Low (0.62/0.68*), High (0.27/0.50*) |
| User Interaction (UI) | None (0.85), Required (0.62) |
| Scope (S) | Unchanged / Changed |
| Confidentiality (C) | High (0.56), Low (0.22), None (0) |
| Integrity (I) | High (0.56), Low (0.22), None (0) |
| Availability (A) | High (0.56), Low (0.22), None (0) |
PR varia según Scope: los valores marcados con * cambian entre Unchanged (0.62/0.27) y Changed (0.68/0.50).
Formulas CVSS v3.1
| Componente | Formula |
|---|---|
| ISS | 1 - [(1-C) x (1-I) x (1-A)] |
| Impact (Scope Unchanged) | 6.42 x ISS |
| Impact (Scope Changed) | 7.52 x [ISS - 0.029] - 3.25 x [ISS - 0.02]^15 |
| Exploitability | 8.22 x AV x AC x PR x UI |
| Base Score (Unchanged) | Si Impact ⇐ 0: 0. Si > 0: Roundup(min(Impact + Exploitability, 10)) |
| Base Score (Changed) | Si Impact ⇐ 0: 0. Si > 0: Roundup(min(1.08 x (Impact + Exploitability), 10)) |
| Roundup | Redondear al decimal superior (ej: 4.015 → 4.1) |
Escala de Severidad CVSS
| Rango | Severidad |
|---|---|
| 0.0 | None |
| 0.1 - 3.9 | Low |
| 4.0 - 6.9 | Medium |
| 7.0 - 8.9 | High |
| 9.0 - 10.0 | Critical |
TRAMPA DEL EXAMEN
Un CVSS de 6.5 es Medium, NO High. La frontera entre Medium y High esta en 7.0, no en 6.0. Además, cuando Scope es Changed, el Base Score se multiplica por 1.08 — esto eleva el score final. Es la única situación donde un multiplicador afecta el resultado.
Identificadores CVE, NVD, CPE, CCE y SCAP
El ecosistema de identificadores permite la interoperabilidad entre herramientas
ECOSISTEMA SCAP
CVE - Nombre estándar de la vulnerabilidad
NVD - Repositorio nacional de vulnerabilidades (NIST)
CPE - Identificación de plataforma/producto
CCE - Problemas de configuración
CVSS - Medición del impacto
XCCDF - Que comprobar (listas de verificación)
OVAL - Como comprobar (lenguaje de pruebas)
Flujo práctico
Scanner detecta CVE → Consulta NVD para CVSS → Usa CPE para identificar producto → Aplica XCCDF/OVAL para verificar configuración → Genera reporte con todos los identificadores
Vulnerabilidades por Categoría
Vulnerabilidades del Servidor
Las vulnerabilidades del lado del servidor representan el objetivo principal de atacantes remotos
VULNERABILIDADES DE SERVIDOR CLAVE
RCE - Remote Code Execution. CVSS 10. Catastrófico. El atacante ejecuta código arbitrario
Insecure Design - Protocolos heredados sin cifrado (Telnet → SSH, FTP → SFTP/FTPS)
Security Misconfiguration - Debug mode en producción, permisos excesivos, credenciales por defecto
Missing Patches - Causa principal según Verizon DBIR: vulnerabilidades antiguas sin parchear
EOL/Outdated Components - Aislar + compensating controls. No se puede parchar lo que ya no tiene soporte
Buffer Overflow
- Stack - Sobrescribe la pila de llamadas. Clásico, predecible.
- Heap - Corrompe la memoria dinámica. Mas dificil de explotar.
- Integer - Error aritmetico que causa desbordamiento. Sutil, subestimado.
Privilege Escalation - Ej: Dirty COW (CVE-2016-5195), rootkits que elevan privilegios
On-Path/MITM - Interceptación de comunicación entre extremos
TRAMPA DEL EXAMEN
Los componentes EOL (End of Life) NO se pueden parchar.
La respuesta correcta es aislarlos + aplicar compensating controls , no “instalar el último parche disponible” (porque ya no hay parches). El examen intentara tentarte con “actualizar a la última version” para un producto EOL.
Vulnerabilidades de Red y Web
VULNERABILIDADES WEB CRITICAS
SQLi - Inyección SQL. input validation + parameterized queries
XSS - Persistent/Stored (persiste en servidor) vs Reflected (en URL, temporal)
CSRF vs SSRF — DISTINCION CRITICA
CSRF - Explota la confianza sitio→usuario. El sitio confia en el usuario autenticado.
SSRF - El servidor visita URLs internas por request del atacante. Acceso a metadata cloud.
Directory Traversal / LFI vs RFI
Directory Traversal - Navega con ../ fuera del directorio
LFI - Local File Inclusión.
Ejecuta archivos locales del servidor (web shells)
RFI - Remote File Inclusión. Carga código remoto del atacante. Más peligroso.
Broken Access Control / IDOR - Acceder a recursos de otros usuarios manipulando IDs
Las vulnerabilidades de red incluyen firmware sin actualizar, fallos criptográficos (SSL vs TLS)
Cifrados inseguros como RC4, errores de certificado (3 tipos: name mismatch, expiración, CA desconocida)
Disclosure de IP interna (NAT leakage que revela topología)
TRAMPA DEL EXAMEN
XSS explota la confianza usuario→sitio (inyecta código que el navegador ejecuta). CSRF explota la confianza sitio→usuario (el sitio ejecuta.action porque confía en la sesión). Son direcciones de confianza inversas. El examen te pedirá identificar cual es cual en un escenario.
Vulnerabilidades del Cliente e Infraestructura Critica
En el lado del cliente, la distinción clave entre técnicas de ataque contra credenciales:
PASSWORD SPRAYING vs CREDENTIAL STUFFING
Password Spraying - Pocas contraseñas comunes contra MUCHAS cuentas. Evita lockout.
Credential Stuffing - MUCHAS contraseñas (filtradas) contra una cuenta. Usa listas de breaches previos.
Otras vulnerabilidades de cliente:
Session hijacking (robo de sesión activa),
Impersonation (suplantación vía OAuth),
Data poisoning (ataques contra modelos de ML entrenados con datos manipulados) y la necesidad de MDM para gestionar dispositivos móviles.
La infraestructura crítica (SCADA/ICS) opera 24/7 y no se puede parchar directamente
SCADA/ICS vs IoT
SCADA/ICS - Opera 24/7, NO se puede parchar en vivo. Protocolos: Modbus, DNP3. Ej: Stuxnet ataco PLCs iraníes.
IoT - Dispositivos con parcheo difícil.
Ej: Mirai botnet infectó cámaras IP. BAS (Building Automation).
Vehículos/drones. Data poisoning posible.
TRAMPA DEL EXAMEN
Para sistemas
SCADA/ICS , la respuesta NO es “aplicar parches inmediatamente”. La operación continua es más crítica que el parche. La solución correcta es aislar + compensating controls + plan de parcheo en ventanas de mantenimiento programadas.
Análisis y Priorización
Falsos Positivos y Negativos
Cada resultado de escaneo cae en una de cuatro categorías:
CUATRO RESULTADOS DE ESCANEO
- True Positive - Vulnerabilidad real encontrada. Accion: remediar.
- False Positive - Falsa alarma. Accion: documentar excepcion, ajustar scanner.
- True Negative - No hay vulnerabilidad y el scanner no la reporta. Correcto.
- False Negative - Vulnerabilidad existe pero el scanner no la detecta. El más peligroso.
La validación de resultados incluye
- Documented exceptions (falsos positivos conocidos),
- Informacional results (no son vulnerabilidades pero informativo), reconciliación con SIEM/logs/config management.
- Trend analysis (comparar histórico), context awareness (exposición red + valor activo) y detección de zero-day (sin firma conocida, comportamiento anomalo). La suppression (suprimir un resultado) es temporal, el tuning (ajustar el scanner) es permanente y previene que el resultado aparezca de nuevo.
Interpretación de Reportes de Escaneo
Un reporte de escaneo contiene múltiples secciones que el analista debe conocer
ANATOMIA DE UN REPORTE NESSUS
- Name - Título de la vulnerabilidad
- Severity - Nivel de riesgo (Critical/High/Medium/Low/Info)
- Description - Detalle tecnico
- Solution - Como remediar
- See Also - Referencias (CVE, vendor advisories)
- Output - Lo que el scanner encontró específicamente
- Ports/Hosts - Donde se encontró
- Risk Info - CVSS vector + score
- Plugin Details - Que plugin la detecto
La priorización sigue un orden
Critical → High → Medium → Low → Info.
Pero el contexto puede sobreponerse al CVSS por ejemplo un High en el servidor de pagos puede tener más prioridad que un Critical en un servidor de test aislado.
TRAMPA DEL EXAMEN
La priorizacion por CVSS NO es absoluta.
El contexto (exposición de red, valor del activo, función en el negocio) puede justificar priorizar una vulnerabilidad de score inferior sobre una de score superior si el activo afectado es más crítico.
Evaluación de Riesgos Cualitativa vs Cuantitativa
La formula fundamental →Risk Severity = Probability x Magnitude
La evaluación cuantitativa usa formulas con valores monetarios
FORMULAS CUANTITATIVAS - EJEMPLO COMPLETO (dólares)
AV (Asset Value) = Valor del activo
EF (Exposure Factor) = % de perdida si el riesgo se materializa
SLE (Single Loss Expectancy) = AV x EF
ARO (Annual Rate of Occurrence) = Veces por ano
ALE (Annual Loss Expectancy) = SLE x ARO
Ejemplo trabajado:
Servidor de email: AV = $10,000
Si falla, se pierde el 90% del valor: EF = 0.90
SLE = 9,000
Falla 0.9 veces por ano: ARO = 0.9
ALE = 8,100
Regla de inversión: El coste máximo de controles = ALE. No gastes más de 8,100/ano.
La evaluación cualitativa usa una matriz Low/Medium/High sin valores monetarios.
Se combina con la cuantitativa para decisiones completas.
El BIA (Business Impact Analysis) evalúa el impacto en el negocio más allá del valor del activo.
Estrategias de Respuesta al Riesgo
CUATRO ESTRATEGIAS DE RESPUESTA
- Mitigación - Reducir probabilidad o magnitud con controles. Ej: firewall + DDoS protection.
- Evitación - Eliminar la actividad que genera el riesgo. Impacto de negocio alto.
- Transferencia - Seguro cibernético. Ojo: property insurance vs cybersecurity insurance (poliza vs endorsement).
- Aceptación - Decisión deliberada y documentada. No es inacción por defecto.
El riesgo residual es el riesgo que queda después de aplicar controles.
Las estrategias se pueden combinar: mitigar parcialmente + transferir el residual vía seguro.
TRAMPA DEL EXAMEN
Risk Acceptance es una decisión deliberada después de analizar el riesgo, NO la inaccion por defecto. Si el examen muestra un escenario donde nadie evaluó el riesgo y simplemente “no hicieron nada”, eso es negligencia , no aceptación de riesgo.
Amenazas y Respuesta
Clasificación de Amenazas
Las amenazas se clasifican en conocidas (firmas disponibles, detectables por tools) y desconocidas (zero-day, sin firma).
Los APT (Advanced Persistent Threats) son actores que combinan ambas
Exploits zero-day + tácticas conocidas, manteniendo acceso prolongado.
El modelo STRIDE clasifica amenazas por categoría:
STRIDE - MODELO DE CLASIFICACIÓN
S - Spoofing (Suplantacion de identidad)
T - Tampering (Modificación no autorizada de datos)
R - Repudiation (Negar haber realizado una accion)
I - Information Disclosure (Exposición de datos sensibles)
D - Denial of Service (Impedir acceso al servicio)
E - Elevation of Privilege (Obtener privilegios superiores)
Otros modelos de threat modeling
- PASTA (Process for Attack Simulation and Threat Analysis)
- LINDDUN (enfoque en privacidad)
- Attack trees (ramas AND/OR)
- Security cards
La investigación de amenazas incluye:
- Threat reputation (servicios como Cisco Talos)
- Behavioral assessments (detección de insider threats)
- IOCs (Indicators of Compromise — evidencia forense post-ataque)
Controles de Mitigación y Vulnerability Response
Los controles se organizan en 3 categorías y 5 tipos:
CATEGORÍAS DE CONTROLES
- Technical - Implementados en hardware/software (firewall, IDS, cifrado)
- Operational - Procedimientos y procesos humanos (entrenamiento, respuestas a incidentes)
- Managerial - Políticas y gobernanza (políticas de seguridad, revisiones de riesgo)
TIPOS DE CONTROLES
- Preventive - Impide el incidente (firewall, cifrado, training)
- Detective - Detecta el incidente (IDS, SIEM, CCTV)
- Responsive - Responde al incidente (IR plan, alertas)
- Corrective - Corrige después del incidente (restaurar backup, parche post-incidente)
- Compensating - Alternativa cuando el control principal no es posible (WAF para SQLi)
Los compensating controls según PCI DSS deben cumplir 3 criterios
(1) tener un nivel de riesgo equivalente o superior al control original.
(2) ser consistente con el espiritu del requisito.
(3) no debilitar otros controles existentes.
La respuesta a vulnerabilidades incluye
- Patch management
- Change management (baselines, version control, diagramas de sistema)
- Configuration management
- Maintenance windows (ventanas programadas supervisadas por un change manager)
TRAMPA DEL EXAMEN
Corrective Control actua DESPUÉS del incidente (restaurar sistemas). Compensating Control es una ALTERNATIVA cuando el control principal no aplica (WAF cuando no hay parche). No los confundas: corrective restaura, compensating sustituye.
Desarrollo Seguro
SDLC - Fases y Modelos
El SDLC (Software Development Life Cycle) tiene 8 fases:
8 FASES DEL SDLC
-
Feasibility - Viabilidad del proyecto
-
Requirements - Requisitos funcionales y de seguridad
-
Design - Arquitectura, threat modeling
-
Development - Codificación + secure coding
-
Testing - UAT, SAST/DAST/IAST, fuzzing
-
Training - Formación de usuarios
-
Operations - Despliegue + monitoreo
-
Disposition - Retiro seguro del software
Los modelos de desarrollo determinan como se recorren estas fases
MODELOS SDLC
- Waterfall - Secuencial. Cada fase termina antes de iniciar la siguiente. Rígido pero predecible.
- Spiral - Iterativo con evaluación de riesgo en cada vuelta. 4 fases repetidas: planificar, analizar riesgo, ingenieria, evaluar.
- Agile - Sprints cortos, backlogs, planning poker, timeboxing, user stories, velocity o lo 12 principios.
- RAD - Rapid Application Development. 5 fases, orientado a prototipos, desarrollo paralelo.
DevSecOps, SAST vs DAST vs IAST
SAST vs DAST vs IAST
SAST - White-box.
- Analiza código fuente SIN ejecutarlo.
- Encuentra vulnerabilidades temprano.
DAST - Black-box.
- Prueba la app ENECUTANDOLA.
- Simula atacante externo.
- Sin acceso al código.
IAST - Instrumentado dentro de la app.
Combina precisión de SAST con realismo de DAST.
DevSecOps integra seguridad en el pipeline CI/CDautomatiza SAST en cada commit, DAST en staging y controla que los despliegues automáticos no introduzcan vulnerabilidades.
El riesgo del CI/CD es un rogue developer que introduce código malicioso — los controles deben incluir revisión de código y firmas de commit.
Fuzzing, Fault Injection y Problemas de Seguridad
Fuzzing envia datos aleatorios/invalidos para encontrar crashes.
Fault Injection tiene 3 métodos:
(1) Fault injection propiamente dicho (inyectar errores en el código)
(2) Stress testing (carga extrema)
(3) Mutation testing (modificar código para verificar que los tests detectan el cambio).
Los 8 problemas comunes de seguridad en software:
PROBLEMAS COMUNES DE SEGURIDAD EN SOFTWARE
-
Error Handling - Mensajes de error que exponen información interna
-
Dereferencing - Acceso a punteros nulos o inválidos
-
Object References - IDOR, referencias directas a objetos sin autorización
-
Race Conditions - Condiciones de carrera entre hilos
-
Broken Authentication - Sistemas de autenticación débiles
-
Data Exposure - Datos sensibles sin cifrar o expuestos en respuestas API
-
Insecure Components - Librerías de terceros con vulnerabilidades conocidas
-
Insufficient Logging - Falta de registros que impide detectar e investigar incidentes
Las practicas de secure coding clave:
- Input validation
- Parameterized queries (previene SQLi)
- Output encoding (previene XSS)
- MFA (no depender solo de contrasenas)
TRAMPA DEL EXAMEN
SAST analiza el código fuente sin ejecutar (white-box, shift-left). DAST prueba la app ejecutándola (black-box, detecta vulnerabilidades en runtime). El examen te pondrá un escenario donde una herramienta detecta SQLi sin acceder al código fuente —> eso es DAST , no SAST.
Gobernanza y Modelado
Jerarquía Documental: Policy, Standard, Procedure, Guideline
La infraestructura de gobernanza de seguridad sigue una jerarquía estricta:
JERARQUÍA DOCUMENTAL
- Policy - OBLIGATORIO. Declaracion de alto nivel. “Debemos escanear trimestralmente.”
- Standard - OBLIGATORIO. Requisitos especificos. “Usar Nessus con template PCI.”
- Procedure - OBLIGATORIO. Pasos detallados. “1. Abrir Nessus, 2. Crear scan, 3…”
- Guideline - OPCIONAL. Recomendaciones. “Se sugiere usar credentialed scanning.”
SLA, SLO y Excepciones
La diferencia entre SLO (Service Level Objective — meta interna, medible) y SLA (Service Level Agreement — contrato con consecuencias financieras por incumplimiento).
Los SLOs de uptime se miden en “nueves”
UPTIME TIERS
99.9% (3 nueves) = 8.76 horas de downtime/ano
99.99% (4 nueves) = 52.6 minutos/ano
99.999% (5 nueves) = 5.26 minutos/ano
El proceso de excepciones documenta 8 elementos:
(1) Vulnerabilidad
(2) Razón de la excepcion
(3) Riesgo residual
(4) Compensating controls
(5) Duración
(6) Aprobador
(7) Plan de remediación
(8) Revisión periódica
Threat Modeling y Attack Surface Management
El threat modeling sistematiza la identificación de amenazas usando 5 elementos:
(1) Adversary capability
(2) Attack surface
(3) Vectors
(4) Impact
(5) Likelihood
El framework DREAD cuantifíca el riesgo:
DREAD SCORING
D - Damage potential (0-10)
R - Reproducibility (0-10)
E - Exploitability (0-10)
A - Affected users (0-10)
D - Discoverability (0-10)
DREAD Score = (D+R+E+A+D) / 5
La Attack Surface Management incluye:
(1) Edge discovery (perimeter scanning)
(2) Passive discovery (observación sin interacción)
(3) Security controls testing
(4) Penetration testing / adversary emulation
Bug Bounty y Supply Chain
Los Bug Bounty Programs incentivan la responsible disclosure: el descubridor reporta la vulnerabilidad al vendor antes de publicarla, recibiendo una recompensa financiera.
El descubridor puede elegir: reportar al vendor, vender a un broker, o publicar.
La divulgación responsable prioriza la seguridad del ecosistema.
La evaluación de la cadena de suministro evalúa tres riesgos
- Proveedores cloud (dependencia de seguridad del tercero)
- Intercepción de hardware (modificación física antes de llegar al cliente)
- Autenticidad de origen (verificar que el hardware proviene del fabricante legítimo).
TRAMPA DEL EXAMEN
Policy y Standard son OBLIGATORIOS. Guideline es OPCIONAL. El examen te mostrara un documento que dice “se recomienda” en lugar de “se requiere” y esperara que identifiques que es un guideline , no un standard.
Resumen: Los 10 Conceptos Mas Críticos
CHECKLIST CRITICO DEL DOMINIO 2
-
Compensating Control sustituye, Risk Acceptance documenta. No los confundas.
-
Active vs Passive: Passive NO reemplaza Active, solo complementa.
-
Credentialed vs Non-Credentialed: Credentialed = read-only, least privilege.
-
CVSS 4.0-6.9 = Medium (NO High). 7.0+ = High. 9.0+ = Critical.
-
Pacu = framework de explotacion, NO escaner.
-
PCI DSS = contractual, no ley. ASV para externos, interno = cualificado.
-
XSS = usuario→sitio. CSRF = sitio→usuario. Direcciones inversas de confianza.
-
SAST = white-box (codigo). DAST = black-box (runtime).
-
Policy/Standard/Procedure = obligatorio. Guideline = opcional.
-
Contexto puede sobreponerse al CVSS para priorizacion.
[ EOF ] “Logs do not explain themselves. Correlation does.”