← Volver al listado de tecnologías ← Índice de ISC2 CSSLP

Dominio 6: Testing de software seguro

Por: Artiko
csslpisc2seguridadtestingdastpentestingfuzzing

Dominio 6: Testing de software seguro

El Dominio 6 — Secure Software Testing pesa un 14% del examen. Su objetivo es demostrar, con evidencia, que el software cumple sus requisitos de seguridad y resiste el abuso. No se trata de probar que “funciona” (functional testing tradicional), sino de probar que no hace lo que no debe y que resiste a un atacante.

ISC2 divide el dominio en ocho subdominios:

flowchart LR
    A[6.1 Estrategia<br/>y plan] --> B[6.2 Casos de<br/>prueba]
    B --> C[6.8 Ejecutar<br/>V&V]
    C --> D[6.5 Analizar<br/>resultados]
    D --> E[6.6 Clasificar y<br/>rastrear defectos]
    E -.retest.-> C
    B -.- G[6.7 Asegurar<br/>datos de prueba]
    A -.- F[6.3 V&V de<br/>documentación]
    C -.- H[6.4 Funcionalidad<br/>no documentada]

💡 Tip de examen: el testing de seguridad prueba presencia de resistencia, no solo ausencia de bugs funcionales. La prueba funcional confirma que existe lo que debe existir; la prueba de seguridad confirma que no ocurre lo que no debe (un usuario no autorizado no accede). Por eso los misuse/abuse cases son centrales.

1. Estrategia y plan de pruebas de seguridad (6.1)

1.1 Functional vs nonfunctional security testing

TipoQué verificaEjemplos
Functional security testingQue los controles de seguridad funcionan según lo especificado¿El login bloquea tras 5 intentos? ¿RBAC deniega al rol equivocado?
Nonfunctional security testingAtributos de calidad bajo condiciones adversasResistencia (pentest, fuzzing), rendimiento bajo DoS, resiliencia

El testing funcional de seguridad valida requisitos positivos (“el sistema debe cifrar los datos en reposo”); el no funcional explora el comportamiento negativo y adversario (“qué pasa si envío 10.000 peticiones malformadas”).

1.2 Integración en el plan general

La estrategia de pruebas de seguridad no es un documento aparte: se integra en el master test plan del proyecto. Debe derivar de los requisitos de seguridad y del threat model (Dominios 3 y 4), definir alcance, entornos, herramientas, criterios de entrada/salida y criterios de aceptación de seguridad. Se planifica temprano (shift left), no como una fase final apresurada.

💡 Tip de examen: los casos y criterios de prueba de seguridad se derivan de los requisitos de seguridad y del modelado de amenazas. Si una pregunta plantea “¿de dónde salen los casos de prueba de seguridad?”, la respuesta une requisitos + threat model, no la intuición del tester.

2. Casos de prueba de seguridad (6.2)

Los casos de prueba de seguridad se construyen a partir de tres insumos:

  1. Requisitos de seguridad → pruebas positivas de que el control existe y funciona.
  2. Misuse / abuse cases → cómo un actor malicioso intentaría subvertir el sistema (el negativo de los casos de uso).
  3. Attack surface → todos los puntos de entrada/salida y flujos de datos que un atacante puede tocar; el análisis de superficie de ataque prioriza dónde probar más.

2.1 Misuse y abuse cases

Un misuse case describe una interacción que un actor hostil realiza contra el sistema (inyectar SQL en un formulario, forzar un IDOR, saltarse el flujo de pago). Se derivan de los casos de uso invirtiéndolos: por cada “el usuario hace X”, se pregunta “¿cómo podría un atacante abusar de X?”. Alimentan directamente los casos de prueba negativos.

flowchart LR
    UC[Casos de uso] --> AC[Abuse / misuse cases]
    RE[Requisitos de seguridad] --> TC[Casos de prueba<br/>de seguridad]
    AC --> TC
    AS[Attack surface] --> TC
    TM[Threat model] --> AC

💡 Tip de examen: distingue positive testing (el control funciona con entrada válida) de negative testing (el sistema resiste entrada maliciosa/inesperada). Los misuse/abuse cases producen los casos negativos y son el vínculo directo entre el threat modeling y el testing.

3. Tipos de pruebas de seguridad

El dominio exige conocer el ecosistema de técnicas, qué encuentra cada una y en qué etapa aplica.

3.1 DAST

DAST (Dynamic Application Security Testing) prueba la aplicación en ejecución, desde fuera, sin acceso al código (black-box). Envía peticiones y observa respuestas para detectar vulnerabilidades explotables en runtime: XSS, inyección, misconfiguraciones, problemas de sesión. Complementa a SAST: encuentra lo que solo se manifiesta al ejecutar, con menos falsos positivos (si lo explota, existe) pero menor cobertura de código.

3.2 IAST

IAST (Interactive Application Security Testing) instrumenta la aplicación con agentes internos que observan el comportamiento mientras se ejecutan las pruebas (funcionales, DAST). Combina visibilidad interna (como SAST) con ejecución real (como DAST), logrando alta precisión y baja tasa de falsos positivos. Requiere desplegar el agente en la app.

3.3 RASP (complemento en producción)

RASP (Runtime Application Self-Protection) no es propiamente una prueba, sino un control de protección en runtime: se integra en la aplicación en producción y bloquea ataques en tiempo real al detectarlos. Se menciona aquí como complemento defensivo de las técnicas de testing.

3.4 Fuzzing

El fuzzing envía a la aplicación grandes volúmenes de entradas malformadas, aleatorias o inesperadas para provocar fallos (crashes, cuelgues, corrupción de memoria) que revelen vulnerabilidades. Es especialmente eficaz para hallar bugs de manejo de memoria y parsers frágiles.

VarianteCómo genera entradas
Mutation-basedMuta muestras válidas existentes (tuerce datos reales)
Generation-basedConstruye entradas desde cero según un modelo/gramática del formato

El generation-based es más preciso pero requiere conocer el formato; el mutation-based es más fácil de montar. El coverage-guided fuzzing (p. ej. AFL) usa la cobertura de código para dirigir la mutación hacia rutas nuevas.

3.5 Penetration testing

El penetration testing es una evaluación manual y dirigida por expertos que simula un atacante real para explotar vulnerabilidades y demostrar impacto de negocio. Se clasifica por el conocimiento previo del tester:

ModalidadConocimiento del testerPerspectiva simulada
Black-boxNinguno (como un externo)Atacante externo sin información
Grey-boxParcial (credenciales, algo de arquitectura)Insider o atacante con foothold
White-boxTotal (código, diseño, arquitectura)Revisión exhaustiva con toda la info

Las reglas de engagement (rules of engagement) son obligatorias: definen alcance, sistemas dentro/fuera, ventanas de tiempo, técnicas permitidas, contactos de emergencia y autorización escrita. Sin autorización formal, un pentest es un delito.

3.6 Simulación: red team y misuse case testing

3.7 Otras técnicas

💡 Tip de examen: no confundas vulnerability scanning (automatizado, identifica, no explota, amplio) con penetration testing (manual, explota, demuestra impacto, profundo). Y DAST/pentest = runtime/black-box frente a SAST = código/white-box. IAST combina ambos mundos con baja tasa de falsos positivos.

4. Tabla comparativa de técnicas

Esta tabla condensa lo más preguntado del dominio:

TécnicaCoberturaEtapa del SDLCCostoFalsos positivosRequiere ejecución
SASTCódigo propio, amplioTemprana (dev/CI)BajoAltosNo
DASTApp en runtime, black-boxTardía (staging/QA)MedioBajosSí
IASTInterno + runtimeDurante pruebasMedioMuy bajosSí
FuzzingEntradas/parsersDev/QA continuoMedio–altoBajosSí
PentestObjetivo, profundoTardía / periódicaAltoMuy bajosSí
flowchart LR
    subgraph Estático
        SAST[SAST<br/>white-box]
    end
    subgraph Dinámico
        DAST[DAST<br/>black-box]
        IAST[IAST<br/>instrumentado]
        FUZZ[Fuzzing]
        PEN[Pentest manual]
    end
    SAST -->|complementa| DAST
    DAST -->|precisión| IAST

5. Verificar documentación y funcionalidad no documentada

5.1 Verificar y validar documentación (6.3)

La documentación (manuales, guías de configuración segura, especificaciones) también se prueba: debe ser precisa, completa y consistente con el sistema real. Documentación incorrecta lleva a misconfiguraciones en producción. Se verifica (¿está bien construida según el estándar?) y se valida (¿describe el sistema que realmente se entregó?).

5.2 Identificar funcionalidad no documentada (6.4)

Es una tarea explícita del CSSLP: buscar y eliminar funcionalidad que no está en las especificaciones:

Toda funcionalidad no documentada es no confiable por definición —no pasó por requisitos, diseño ni revisión— y debe removerse o, si es legítima, documentarse y controlarse.

💡 Tip de examen: los debug endpoints activos en producción y las backdoors son hallazgos clásicos del subdominio 6.4. La regla: funcionalidad no documentada = riesgo que debe eliminarse, aunque parezca inocua (un easter egg es código no auditado).

6. Analizar los resultados y gestionar los defectos

6.1 Analizar implicaciones de seguridad de los resultados (6.5)

No basta con listar hallazgos: hay que interpretar su significado de seguridad. Un resultado que “parece” un fallo funcional puede ser una vulnerabilidad seria; un aparente falso positivo puede ser explotable en combinación con otro. El análisis distingue falsos positivos de hallazgos reales, evalúa el impacto de negocio y decide el tratamiento del riesgo (remediar, mitigar, aceptar; ver capítulo 7 §13).

6.2 Clasificar y rastrear errores de seguridad (6.6)

Los defectos de seguridad se gestionan con el mismo rigor que cualquier bug, pero con priorización basada en riesgo:

flowchart LR
    A[Hallazgo] --> B[Triage:<br/>severidad CVSS]
    B --> C{¿Real o falso<br/>positivo?}
    C -->|Falso positivo| D[Documentar y cerrar]
    C -->|Real| E[Priorizar por riesgo<br/>+ SLA]
    E --> F[Asignar y corregir]
    F --> G[Retest / regresión]
    G -->|Falla| F
    G -->|Pasa| H[Cerrar + caso de<br/>regresión]

💡 Tip de examen: CVSS es el estándar para puntuar la severidad de una vulnerabilidad y priorizar la remediación; no mide probabilidad de negocio por sí solo. El ciclo correcto es hallazgo → triage → fix → retest: un defecto no se cierra hasta que el retest confirma la corrección.

6.3 Anatomía de CVSS

Conviene conocer la estructura de CVSS porque explica por qué una vulnerabilidad puntúa alto o bajo. Se compone de tres grupos de métricas:

Grupo de métricasQué captura¿Cambia con el tiempo?
BaseCaracterísticas intrínsecas y constantes (vector de ataque, complejidad, privilegios requeridos, interacción del usuario, impacto en CIA)No
Temporal / ThreatMadurez del exploit, disponibilidad de parcheSí
EnvironmentalAjuste al contexto concreto de la organización (criticidad del activo, controles compensatorios)Sí, por entorno

La puntuación base (0–10) es la que suele publicarse en los CVE. Traducirla a prioridad real requiere el contexto ambiental: una vulnerabilidad “crítica” en un sistema aislado sin datos sensibles puede ser menos urgente que una “media” en un servicio expuesto que procesa PII.

Rango CVSSSeveridad
9.0 – 10.0Crítica
7.0 – 8.9Alta
4.0 – 6.9Media
0.1 – 3.9Baja

6.4 Bug bar y clasificación de severidad

Muchas organizaciones complementan CVSS con un security bug bar: una definición acordada de qué severidad tiene cada clase de defecto y qué SLA de remediación le corresponde. El bug bar da consistencia al triage y evita discusiones caso por caso.

💡 Tip de examen: distingue la puntuación base de CVSS (intrínseca, en el CVE) del ajuste ambiental (contexto de tu organización). Priorizar solo por la base, ignorando la criticidad del activo y la exposición, es un error de gestión de riesgos.

7. Asegurar los datos de prueba (6.7)

Los entornos de prueba suelen ser menos protegidos que producción, así que usar datos reales de producción en ellos es una fuga esperando a suceder (y viola GDPR, HIPAA, PCI DSS). El subdominio 6.7 exige proteger los datos de prueba:

TécnicaQué hace
Data maskingReemplaza datos sensibles por valores ficticios manteniendo el formato
AnonimizaciónElimina de forma irreversible la posibilidad de reidentificar a la persona
SeudonimizaciónSustituye identificadores por seudónimos (reversible con clave separada)
Datos sintéticosGenera datos artificiales que imitan las propiedades de los reales

💡 Tip de examen: ante “cómo probar con datos realistas sin exponer PII”, las respuestas correctas son masking, anonimización o datos sintéticos. Copiar la base de producción a QA “porque es más real” es la opción incorrecta clásica.

8. Verificación y validación (6.8)

V&V son dos conceptos distintos que ISC2 evalúa con frecuencia:

Pregunta que respondeEnfoque
Verificación¿Construimos el producto correctamente?Cumple las especificaciones/estándares (revisiones, análisis, pruebas contra spec)
Validación¿Construimos el producto correcto?Satisface las necesidades reales del usuario/negocio

Las pruebas de V&V confirman contra los criterios de aceptación (incluidos los de seguridad) que el software es correcto y adecuado. La V&V independiente (IV&V), realizada por un tercero sin conflicto de interés, aporta objetividad en sistemas críticos.

💡 Tip de examen: memoriza la distinción con la mnemónica: Verificación = “¿bien construido?” (contra la spec), Validación = “¿el producto correcto?” (contra la necesidad real). Es un par muy preguntado; no los confundas.

8.1 Criterios de aceptación y regression testing de seguridad

Las pruebas de V&V se miden contra criterios de aceptación que deben incluir requisitos de seguridad explícitos (no solo funcionales): “ningún hallazgo crítico o alto abierto”, “todos los controles del threat model verificados”, “cobertura de los abuse cases prioritarios”. Un producto no se acepta si incumple los criterios de seguridad, por muy completa que esté la funcionalidad.

El regression testing de seguridad cierra el ciclo: cada vulnerabilidad corregida genera un caso de prueba de regresión que se reejecuta en cada release. Así se garantiza que una corrección no se revierte por un cambio posterior y que la superficie corregida permanece cerrada.

9. Automatización del testing de seguridad continuo

El testing de seguridad no es un evento único previo al lanzamiento, sino una actividad continua integrada en el pipeline (enlaza con el capítulo 8). Cada técnica se ubica donde es más eficaz:

flowchart LR
    A[Commit] --> B[SAST + secret scan<br/>en CI]
    B --> C[SCA de dependencias]
    C --> D[Build]
    D --> E[DAST / IAST<br/>en staging]
    E --> F[Fuzzing / pruebas<br/>de abuso]
    F --> G[Pentest periódico<br/>fuera de banda]
    G --> H[Regresión de<br/>seguridad continua]

💡 Tip de examen: no todo el testing de seguridad cabe en cada commit. Las pruebas automatizadas y rápidas son gates continuos; el pentest manual es periódico. Colocar cada técnica en su etapa correcta del pipeline es una decisión de estrategia (subdominio 6.1).

Puntos clave

← Volver al listado de tecnologías ← Índice de ISC2 CSSLP