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

Dominio 3: Requisitos de software seguro

2 de julio de 2026 Por: Artiko

csslpisc2seguridadrequisitoscomplianceprivacidadsdlc

Dominio 3: Requisitos de software seguro

El Dominio 3 pesa 13% del examen y marca el momento del ciclo de vida donde la seguridad deja de ser una intención y se convierte en algo verificable. Un requisito de seguridad es una afirmación comprobable sobre qué debe hacer (o no hacer) el software. Si no está escrito, no se diseña; si no se diseña, no se prueba; y si no se prueba, no se puede afirmar que el sistema sea seguro.

La idea central que el examen quiere que interiorices es que el requisito es el punto de máximo apalancamiento. Corregir un defecto de seguridad detectado en requisitos cuesta órdenes de magnitud menos que corregirlo en producción. Por eso, cuando una pregunta te plantee “¿cuál es la forma más económica de asegurar una característica?”, la respuesta casi siempre apunta a definirlo correctamente como requisito desde el inicio.

flowchart LR
    N[Necesidad de negocio] --> R[Requisito de seguridad]
    RG[Análisis de riesgo] --> R
    C[Cumplimiento normativo] --> R
    R --> D[Diseño / control]
    D --> I[Implementación]
    I --> T[Caso de prueba]
    T -.trazabilidad SRTM.-> R

💡 Tip de examen: cuando dudes en qué fase del SDLC actuar, recuerda que el orden correcto es requisitos → diseño → implementación → pruebas. La opción “más temprana” que resuelva la causa raíz suele ser la correcta, no el parche tardío.

3.1 Definir requisitos de seguridad del software

Los requisitos de seguridad nacen de tres fuentes que debes saber distinguir:

Fuente	Descripción	Ejemplo
Negocio	Objetivos y reglas del negocio que implican protección	”Solo el titular puede ver su saldo”
Riesgo	Derivados del análisis de amenazas y tolerancia al riesgo	”Bloquear la cuenta tras 5 intentos fallidos”
Cumplimiento	Impuestos por leyes, regulaciones o contratos	”Cifrar PAN de tarjetas en reposo (PCI DSS)“

Funcionales vs. no funcionales

Requisitos funcionales de seguridad: describen una funcionalidad de seguridad concreta que el sistema hace. Por ejemplo: “el sistema debe exigir MFA para operaciones de transferencia”. Son observables como una característica.
Requisitos no funcionales de seguridad: describen atributos de calidad o restricciones transversales. Por ejemplo: “todas las comunicaciones deben usar TLS 1.2 o superior”, “el sistema debe soportar 10.000 sesiones concurrentes sin degradar los controles de autorización”. Aquí viven cualidades como resiliencia, rendimiento bajo carga, mantenibilidad de los controles.

Muchos requisitos de seguridad son no funcionales porque expresan cómo debe comportarse el sistema (confidencialidad, integridad, disponibilidad) más que una feature visible. El examen insiste en que la seguridad se expresa frecuentemente como atributos de calidad.

Requisitos derivados: general → específico

Un requisito de alto nivel (“proteger datos de clientes”) debe descomponerse en requisitos derivados concretos y comprobables: cifrado en reposo con AES-256, cifrado en tránsito con TLS, control de acceso por rol, registro de auditoría de accesos, retención máxima de 24 meses. A este proceso de descomponer una política o un objetivo de alto nivel en requisitos técnicos concretos se le llama policy decomposition.

Un buen requisito de seguridad es SMART: específico, medible, alcanzable, relevante y con un criterio de aceptación verificable. “El sistema debe ser seguro” no es un requisito; “el sistema debe rechazar contraseñas de menos de 12 caracteres” sí lo es.

💡 Tip de examen: distingue “requisito de seguridad” (lo que el sistema debe hacer) de “control de seguridad” (el mecanismo que lo implementa). El requisito precede al control. Si la pregunta mezcla ambos, la actividad de “requisitos” siempre es anterior.

3.2 Requisitos de cumplimiento normativo y regulatorio

El cumplimiento genera requisitos obligatorios: no son negociables por conveniencia técnica. El CSSLP no exige memorizar el articulado, pero sí saber qué protege cada marco y qué requisitos típicos impone.

Marco	Ámbito	Datos que protege	Requisitos típicos que genera
GDPR	UE (extraterritorial)	Datos personales de residentes de la UE	Base legal, consentimiento, derecho al olvido, portabilidad, DPO, notificación de brecha en 72h, privacy by design
HIPAA	EE.UU., salud	PHI (información de salud protegida)	Salvaguardas administrativas, físicas y técnicas; BAA con terceros; control de acceso y auditoría
PCI DSS	Global, tarjetas de pago	Datos del titular (PAN, CVV)	Cifrado de PAN, segmentación de red, no almacenar CVV, prueba de intrusión y escaneo regular
SOX	EE.UU., empresas cotizadas	Integridad de reportes financieros	Controles internos, segregación de funciones, trazabilidad de cambios, auditoría
CCPA/CPRA	California	Datos personales de consumidores	Derecho a saber, a borrar y a rechazar la venta de datos (opt-out)

Leyes locales y sectoriales: además de estos marcos globales, el software puede estar sujeto a leyes nacionales (por ejemplo, LGPD en Brasil, LFPDPPP en México) o sectoriales (GLBA en banca de EE.UU.). El requisito recurrente es la localización o soberanía de datos: dónde se pueden almacenar y procesar legalmente.

💡 Tip de examen: GDPR aplica por la residencia del sujeto de datos, no por dónde está la empresa. Una empresa fuera de la UE que trata datos de europeos está sujeta a GDPR. HIPAA es de salud, PCI DSS de tarjetas, SOX de reportes financieros. Asociar cada marco con su tipo de dato resuelve la mayoría de las preguntas.

Un punto que el examen valora: el cumplimiento es un mínimo, no un techo. Cumplir PCI DSS no significa “estar seguro”; significa cumplir un baseline. La gestión de riesgo puede exigir controles por encima de lo regulado.

3.3 Requisitos de clasificación de datos

No todos los datos merecen la misma protección. La clasificación asigna a cada tipo de dato un nivel de sensibilidad que determina los controles (cifrado, acceso, retención, destrucción). Sin clasificación, o se sobreprotege todo (caro) o se subprotege lo crítico (peligroso).

flowchart TD
    subgraph Ciclo de vida del dato
        A[Creación] --> B[Almacenamiento]
        B --> C[Uso]
        C --> D[Compartición]
        D --> E[Archivo]
        E --> F[Destrucción]
    end
    CL[Clasificación] -.define controles en cada fase.-> A

Niveles de clasificación

Los esquemas varían por organización, pero el examen usa dos referencias típicas:

Esquema comercial	Esquema gubernamental (EE.UU.)
Público	Unclassified
Interno / Sensitive	Confidential
Confidencial	Secret
Restringido / Highly confidential	Top Secret

Roles del dato

Data owner (dueño del dato): responsable de negocio; decide la clasificación y quién puede acceder. Rinde cuentas (accountable).
Data custodian (custodio): TI/operaciones; implementa y mantiene los controles (backups, cifrado, permisos) según lo que dictó el owner.
Data steward: cuida la calidad y el uso correcto del dato.
Data processor: procesa datos por cuenta de un controlador (terminología GDPR).

Etiquetado (labeling)

La clasificación solo es útil si el dato lleva su etiqueta consigo (marca, metadato, cabecera). El etiquetado permite que los controles automáticos (DLP, cifrado condicional) actúen según la sensibilidad. Requisito típico: “todo documento clasificado como Confidencial debe llevar marca de agua y encabezado de clasificación”.

💡 Tip de examen: el data owner clasifica, el data custodian implementa los controles. Es una distinción de “accountable vs. responsible” que ISC2 pregunta a menudo. El custodio nunca decide la clasificación.

3.4 Requisitos de privacidad

La privacidad no es sinónimo de seguridad: la seguridad protege el dato de accesos no autorizados; la privacidad gobierna el uso legítimo del dato personal incluso por quien tiene acceso autorizado.

Tipos de datos personales

PII (Personally Identifiable Information): identifica a una persona (nombre, DNI, email, IP en algunos marcos).
PHI (Protected Health Information): PII en contexto de salud, protegida por HIPAA.
SPI / datos sensibles: origen racial, salud, orientación, biometría; requieren protección reforzada bajo GDPR.

Privacy by Design

Principio, popularizado por Ann Cavoukian y consagrado en GDPR (art. 25), de incorporar la privacidad desde el diseño y por defecto, no como un añadido posterior. Sus ideas rectoras: proactivo no reactivo, privacidad como configuración por defecto, privacidad embebida en el diseño, funcionalidad completa (no suma cero), seguridad de extremo a extremo, visibilidad/transparencia y respeto por el usuario.

Requisitos de privacidad recurrentes

Requisito	Descripción
Minimización de datos	Recolectar solo lo estrictamente necesario para el fin declarado
Limitación de propósito	Usar el dato solo para el fin por el que se recolectó
Consentimiento	Obtener permiso informado, específico y revocable
Retención	Conservar el dato solo el tiempo necesario; borrarlo después
Transferencias internacionales	Restringir o controlar el envío de datos fuera de la jurisdicción (cláusulas contractuales, adecuación)
Derechos del sujeto	Acceso, rectificación, borrado (derecho al olvido), portabilidad
PIA / DPIA	Evaluación de impacto en la privacidad antes de un tratamiento de riesgo

Una técnica de diseño clave es la desidentificación: anonimización (irreversible) y seudonimización (reversible con clave separada). GDPR favorece la seudonimización como medida de reducción de riesgo.

💡 Tip de examen: minimización es el principio que más aparece: si una opción propone “recolectar todos los datos posibles por si acaso”, es incorrecta. Recolecta lo mínimo, retén lo mínimo, comparte lo mínimo.

3.5 Aprovisionamiento de acceso a datos

A nivel de requisitos —no todavía de implementación— se define quién debe poder acceder a qué. Los principios rectores:

Need-to-know: acceso solo a la información necesaria para la tarea, independientemente del nivel de autorización.
Least privilege: los mínimos permisos necesarios, durante el mínimo tiempo.
Separation of duties: ninguna persona controla un proceso crítico de extremo a extremo (evita fraude).

Modelos de control de acceso como requisito

Aunque el diseño detallado corresponde al Dominio 4, en requisitos ya se especifica el modelo:

Modelo	Decide el acceso según…	Cuándo se prefiere
RBAC	El rol del usuario	Organizaciones con roles estables y bien definidos
ABAC	Atributos (usuario, recurso, entorno, acción)	Reglas dinámicas y contextuales (hora, ubicación, sensibilidad)
MAC	Etiquetas de clasificación y clearance	Entornos de alta seguridad (defensa)
DAC	El dueño del recurso concede permisos	Flexibilidad, sistemas de propósito general

Un requisito bien formado podría ser: “el acceso a expedientes clínicos se otorgará por RBAC con verificación adicional de relación asistencial activa (need-to-know)”.

💡 Tip de examen: RBAC = rol, ABAC = atributos. ABAC es más granular y contextual; RBAC es más simple de administrar. Si la pregunta enfatiza reglas dinámicas por contexto (hora, ubicación, riesgo), la respuesta es ABAC.

3.6 Misuse cases y abuse cases

Los casos de uso describen cómo un usuario legítimo alcanza un objetivo. Los misuse cases (y su variante más agresiva, abuse cases) invierten la perspectiva: describen cómo un actor hostil intenta subvertir el sistema. Son el puente entre “qué debe hacer el sistema” y “contra qué debemos defendernos”.

Misuse case: uso no intencionado o negligente que provoca daño (puede ser un usuario legítimo cometiendo un error). Se representa como un caso de uso negativo asociado a los casos legítimos que amenaza y a los requisitos de seguridad que lo mitigan.
Abuse case: uso deliberadamente malicioso por un atacante. Popularizados por McDermott y Fox; se centran en interacciones hostiles completas.

flowchart LR
    U[Usuario legítimo] -->|realiza| UC[Caso de uso: Iniciar sesión]
    A[Atacante] -->|ejecuta| MC[Misuse case: Fuerza bruta de credenciales]
    MC -.amenaza.-> UC
    SR[Requisito: bloqueo tras 5 intentos] -.mitiga.-> MC

Cómo escribir un misuse/abuse case

Identifica el actor hostil y su motivación.
Describe la interacción maliciosa (el “camino de ataque”).
Enlázalo con el caso de uso legítimo que amenaza.
Deriva el requisito de seguridad que lo mitiga.

Evil user stories en Agile

En metodologías ágiles, el equivalente es la evil user story (historia de usuario malvada): se escribe con la misma plantilla que una user story, pero desde la voz del atacante.

Como atacante, quiero inyectar SQL en el buscador para extraer la tabla de usuarios.

De cada evil user story se derivan criterios de aceptación de seguridad (por ejemplo, “todas las consultas usan sentencias parametrizadas”) que se añaden a la definición de “hecho” (Definition of Done) del backlog. Así la seguridad entra en el flujo ágil sin romperlo.

💡 Tip de examen: los misuse/abuse cases se escriben durante los requisitos, no durante el testing. Su propósito es anticipar el abuso para derivar requisitos, alimentando después el modelado de amenazas del diseño.

3.7 Security Requirements Traceability Matrix (SRTM)

La SRTM es el artefacto que garantiza que cada requisito de seguridad se diseña, implementa y prueba —y que no aparecen controles huérfanos sin requisito que los justifique. Es una herramienta de trazabilidad bidireccional: del requisito hacia adelante (¿se probó?) y de la prueba hacia atrás (¿qué requisito valida?).

Ejemplo de SRTM

ID	Requisito de seguridad	Fuente	Control de diseño	Método de prueba	Estado
SR-01	Contraseñas ≥ 12 caracteres, con complejidad	Política interna	Validador en registro/cambio	Test unitario + revisión	✔ Verificado
SR-02	Cifrar PAN en reposo (AES-256)	PCI DSS 3.4	Cifrado a nivel de columna	Revisión de config + DAST	✔ Verificado
SR-03	Bloqueo tras 5 intentos fallidos	Análisis de riesgo	Contador + lockout temporal	Caso de abuso automatizado	⚙ En progreso
SR-04	MFA para transferencias	Negocio	Servicio de autenticación	Test de integración	✔ Verificado
SR-05	Registro de auditoría de accesos a PHI	HIPAA	Middleware de logging	Revisión de logs + prueba	⚙ En progreso

La SRTM se inicia en requisitos y se mantiene viva durante todo el SDLC: es la evidencia auditable de que “lo que dijimos que protegeríamos, lo protegimos y lo verificamos”.

💡 Tip de examen: la SRTM sirve para detectar requisitos sin probar (gaps) y controles sin requisito (gold-plating). Si una pregunta busca cómo demostrar cobertura de seguridad ante un auditor, la respuesta es la matriz de trazabilidad.

3.8 Requisitos de seguridad para proveedores y terceros

El software moderno se ensambla con componentes, servicios y datos de terceros. Los requisitos de seguridad deben extenderse a la cadena: un proveedor débil es un riesgo propio (este tema conecta con el Dominio 8, cadena de suministro).

Requisitos típicos a imponer contractualmente:

Cláusulas de seguridad en el contrato: derecho de auditoría, obligación de notificar brechas, cumplimiento de estándares (ISO 27001, SOC 2).
SLA de seguridad: tiempos de parcheo, disponibilidad, respuesta a incidentes.
Requisitos de datos: dónde se almacenan, quién accede, cómo se destruyen al finalizar el contrato.
BAA (Business Associate Agreement): obligatorio bajo HIPAA cuando un tercero maneja PHI.
Evidencia de prácticas seguras: resultados de pentest, SBOM, certificaciones.
Cláusula de subcontratación: control sobre los “cuartos niveles” (los proveedores de tu proveedor).

💡 Tip de examen: la responsabilidad del riesgo no se transfiere al proveedor por contrato; el contrato transfiere parte de la responsabilidad operativa, pero tu organización sigue siendo accountable ante el regulador. Por eso los requisitos y el derecho de auditoría son esenciales.

Técnicas de elicitación de requisitos

Elicitar es descubrir los requisitos junto a los stakeholders. Las técnicas más relevantes para el examen:

Técnica	En qué consiste	Fortaleza
Entrevistas	Conversaciones dirigidas con stakeholders	Profundidad, matices, contexto
Encuestas/cuestionarios	Preguntas estructuradas a muchos participantes	Escala, cobertura amplia
Talleres (JAD)	Sesiones colaborativas de diseño conjunto	Consenso rápido entre áreas
Observación	Ver a los usuarios operar el sistema actual	Descubre requisitos tácitos
Análisis de documentos	Revisar políticas, regulaciones, contratos	Fuente de requisitos de cumplimiento
Policy decomposition	Descomponer políticas de alto nivel en requisitos técnicos concretos	Traza cumplimiento a implementación
Prototipado	Maqueta para validar entendimiento	Reduce ambigüedad temprano

La elicitación de requisitos de seguridad se apoya especialmente en análisis de documentos (leyes, políticas) y en policy decomposition, porque muchos requisitos de seguridad no los “pide” el usuario: los impone la normativa y el análisis de riesgo.

sequenceDiagram
    participant B as Negocio/Stakeholders
    participant A as Analista de seguridad
    participant P as Políticas/Regulación
    participant S as SRTM
    A->>B: Entrevistas y talleres
    A->>P: Análisis y policy decomposition
    A->>A: Escribe misuse/abuse cases
    A->>S: Registra cada requisito derivado
    S-->>A: Traza a diseño y pruebas

💡 Tip de examen: ante “¿cómo obtener requisitos de seguridad que el cliente no menciona?”, la respuesta es analizar políticas, regulaciones y riesgos (policy decomposition) y escribir misuse/abuse cases, no solo preguntar al usuario lo que quiere.

Del requisito al diseño y la prueba

El valor de este dominio se realiza cuando el requisito fluye hacia las fases siguientes. La SRTM es el hilo conductor: un requisito bien escrito genera un control de diseño (Dominio 4), una práctica de implementación (Dominio 5) y un caso de prueba (Dominio 6), todos rastreables entre sí.

flowchart LR
    R[Requisito de seguridad SR-03] --> D[Diseño: mecanismo de lockout]
    D --> I[Implementación: contador seguro]
    I --> T[Prueba: caso de abuso de fuerza bruta]
    T --> V[Verificación en SRTM]
    V -.evidencia auditable.-> R

Este flujo es la razón de ser del CSSLP: la seguridad no es una fase, es una propiedad trazable a lo largo de todo el ciclo.

Puntos clave

El requisito es el punto de máximo apalancamiento: corregir seguridad en requisitos es mucho más barato que en producción. Ante “la forma más económica de asegurar algo”, piensa en definirlo bien desde el inicio.
Los requisitos de seguridad vienen de negocio, riesgo y cumplimiento; se expresan a menudo como no funcionales (atributos de calidad) y deben ser verificables.
Policy decomposition descompone políticas y regulaciones de alto nivel en requisitos técnicos concretos.
Cada marco protege un tipo de dato: GDPR (personales UE, por residencia del sujeto), HIPAA (salud), PCI DSS (tarjetas), SOX (reportes financieros), CCPA/CPRA (consumidores de California). El cumplimiento es un mínimo, no un techo.
El data owner clasifica y decide accesos; el data custodian implementa los controles. La clasificación define los controles a lo largo del ciclo de vida del dato.
Privacy by design, minimización, limitación de propósito, consentimiento y retención son los pilares de privacidad. Recolecta y conserva lo mínimo.
Need-to-know y least privilege rigen el aprovisionamiento de acceso; a nivel de requisitos se elige el modelo (RBAC = rol, ABAC = atributos).
Los misuse/abuse cases y las evil user stories se escriben en la fase de requisitos para anticipar el abuso y derivar requisitos de seguridad.
La SRTM garantiza trazabilidad bidireccional: ningún requisito sin probar, ningún control sin requisito. Es la evidencia auditable de cobertura.
Los requisitos de seguridad se extienden a terceros por contrato (derecho de auditoría, notificación de brechas, BAA), pero la accountability no se transfiere.