Dominio 1: Conceptos de software seguro

Peso en el examen: 12%.

Este dominio es el vocabulario y la gramática del CSSLP. Todo lo demás —requisitos, diseño, testing, cadena de suministro— se construye sobre estos conceptos. Si dominas este dominio, muchas preguntas de otros dominios se resuelven casi por descarte, porque reconoces qué principio o qué propiedad de seguridad está en juego.

Subdominios oficiales:

• 1.1 Conceptos fundamentales de seguridad (CIA, AAA, no repudio, privacidad, GRC, controles, riesgo).
• 1.2 Principios de diseño de seguridad (least privilege, defense in depth, fail secure, etc.).

mindmap
  root((Conceptos de<br/>software seguro))
    Propiedades
      Confidencialidad
      Integridad
      Disponibilidad
      Autenticidad
      No repudio
    AAA
      Autenticacion
      Autorizacion
      Accountability
    Principios de diseno
      Least privilege
      Defense in depth
      Fail secure
      Complete mediation
      Open design
    Gobernanza y riesgo
      GRC
      Controles
      Gestion de riesgo
      Privacidad

---

1.1 Conceptos fundamentales

La tríada CIA

La tríada CIA es el modelo base de la seguridad de la información. Toda medida de seguridad busca proteger una o más de estas tres propiedades.

Propiedad	Qué protege	Ejemplo en software	Lo destruye…
Confidencialidad	Que solo quien está autorizado vea la información	Cifrar datos en reposo y en tránsito (TLS, AES); control de acceso a un endpoint	Una fuga de datos, un log que expone PII
Integridad	Que los datos no se alteren de forma no autorizada	Hashes/firmas para verificar que un mensaje no cambió; validación de entrada; transacciones ACID	SQL injection que modifica registros; manipulación de un JWT
Disponibilidad	Que el sistema esté accesible cuando se necesita	Redundancia, balanceo, rate limiting anti-DoS, backups	Un ataque DoS; un deadlock; un ransomware

Estas tres propiedades entran en tensión entre sí. Cifrar todo maximiza confidencialidad pero puede afectar disponibilidad (rendimiento) o mantenibilidad. El profesional CSSLP equilibra las tres según el valor y la clasificación de los datos, no las maximiza a ciegas.

flowchart TD
    subgraph CIA[Triada CIA]
        C[Confidencialidad]
        I[Integridad]
        A[Disponibilidad]
    end
    C -.tension.- A
    C -.tension.- I
    I -.tension.- A

💡 Tip de examen: identifica cuál propiedad de la CIA ataca o protege un escenario. Un ataque de SQL injection que altera datos es un problema de integridad; una fuga de credenciales es de confidencialidad; un DoS es de disponibilidad. Muchas preguntas se resuelven nombrando correctamente la propiedad afectada.

Un ejercicio mental útil: para cada ataque conocido, pregúntate qué propiedad viola. Así entrenas el reflejo que el examen recompensa:

Ataque / evento	Propiedad(es) violada(s)
Fuga de una base de datos de usuarios	Confidencialidad
Manipulación de un precio en el carrito	Integridad
Ataque DDoS a una API	Disponibilidad
Man-in-the-middle que altera un mensaje en tránsito	Confidencialidad + Integridad
Ransomware que cifra los datos	Disponibilidad (y a veces confidencialidad si exfiltra)
Borrado de logs de auditoría por un insider	Integridad + accountability/no repudio

Más allá de CIA, el examen usa dos propiedades adicionales estrechamente relacionadas:

• Autenticidad: la garantía de que una entidad o dato es genuino y proviene de quien dice provenir.
• No repudio: la imposibilidad de negar haber realizado una acción (ver más abajo).

AAA: autenticación, autorización, accountability

AAA describe el flujo de control de acceso y rendición de cuentas de todo sistema seguro.

Componente	Pregunta que responde	Ejemplo en software
Autenticación	¿Quién eres?	Login con contraseña + MFA; validación de un token; certificado mutuo (mTLS)
Autorización	¿Qué puedes hacer?	RBAC/ABAC; comprobar que el usuario X puede leer el recurso Y
Accountability / Auditing	¿Qué hiciste?	Logs de auditoría inmutables que registran quién hizo qué y cuándo

sequenceDiagram
    participant U as Usuario
    participant Sys as Sistema
    U->>Sys: 1. Credenciales
    Sys->>Sys: Autenticacion (quien eres)
    U->>Sys: 2. Solicita recurso
    Sys->>Sys: Autorizacion (que puedes hacer)
    Sys->>Sys: Accountability (registrar la accion)
    Sys-->>U: Respuesta + registro en log de auditoria

Un matiz de examen: la autenticación siempre precede a la autorización. No puedes decidir qué puede hacer alguien hasta saber quién es. Y la accountability depende de una autenticación fuerte: si varias personas comparten una cuenta, pierdes trazabilidad y no hay rendición de cuentas real.

💡 Tip de examen: las cuentas compartidas son el enemigo de la accountability y del no repudio. Si un escenario menciona una cuenta genérica usada por varias personas, el problema de seguridad casi siempre es la pérdida de trazabilidad/atribución.

No repudio

El no repudio garantiza que un actor no pueda negar haber realizado una acción. Se logra combinando autenticación fuerte, integridad y registro/auditoría. El mecanismo técnico clásico es la firma digital: como solo el titular posee la clave privada, una transacción firmada no puede ser negada de forma creíble.

El no repudio se apoya en las otras propiedades: sin integridad (que el registro no se pueda alterar) ni autenticación fuerte (saber que fue esa persona), el no repudio no se sostiene.

flowchart LR
    Auth[Autenticacion fuerte<br/>firma con clave privada] --> NR((No repudio))
    Int[Integridad<br/>el registro no se altera] --> NR
    Log[Auditoria<br/>registro con timestamp] --> NR
    NR --> Result[El actor no puede negar<br/>su accion de forma creible]

Privacidad como concepto

La privacidad es la propiedad ligada al tratamiento adecuado de la información personal identificable (PII). No es sinónimo de confidencialidad: la confidencialidad es cómo proteges el dato; la privacidad es si tienes derecho a recolectarlo, cuánto, para qué y por cuánto tiempo.

Principios de privacidad relevantes para el diseño de software:

• Minimización de datos: recolecta solo lo estrictamente necesario para la finalidad declarada. Menos datos = menos superficie de riesgo.
• Limitación de propósito: usa los datos solo para el fin por el que se recolectaron.
• Limitación de retención: no conserves PII más de lo necesario; define y aplica políticas de borrado.
• Consentimiento y transparencia: informar y, cuando aplique, obtener consentimiento.
• Privacy by design: la privacidad se construye en el diseño, no se añade después (concepto de Ann Cavoukian, adoptado por marcos regulatorios).

💡 Tip de examen: cuando un escenario mencione PII, piensa primero en minimización (“no recolectes lo que no necesitas”) y en retención (“no lo guardes más de lo necesario”). En el CSSLP, reducir la cantidad de datos suele ser una respuesta más fuerte que solo “cifrarlos”.

Gobernanza, riesgo y cumplimiento (GRC)

GRC (Governance, Risk, Compliance) es el marco organizacional dentro del cual vive la seguridad del software:

• Governance (gobernanza): las políticas, roles y estructura de decisión. Define quién es responsable de qué y alinea la seguridad con los objetivos del negocio. Establece el “deber ser”.
• Risk (riesgo): identificar, evaluar y tratar los riesgos de forma continua (ver 1.1 gestión de riesgos).
• Compliance (cumplimiento): satisfacer requisitos externos (leyes, regulaciones: GDPR, HIPAA, PCI DSS) e internos (políticas propias).

Una jerarquía útil de documentos de gobernanza:

flowchart TD
    P[Politica<br/>obligatoria - el 'que' y el 'porque'] --> S[Estandar<br/>obligatorio - tecnologias/config especificas]
    P --> Pr[Procedimiento<br/>obligatorio - pasos exactos]
    P --> G[Guideline / Directriz<br/>recomendada - buenas practicas]

• Política: de alto nivel y obligatoria; dice qué se debe lograr y por qué.
• Estándar: obligatorio; especifica tecnologías, configuraciones o niveles concretos.
• Procedimiento: obligatorio; paso a paso de cómo hacerlo.
• Guideline (directriz): recomendada, no obligatoria; sugiere buenas prácticas.

💡 Tip de examen: distingue política (obligatoria, alto nivel) de guideline (recomendada, flexible). Si una pregunta describe algo “obligatorio y de alto nivel”, es una política; si es “recomendado pero no forzoso”, es una guideline/directriz.

Tipos de controles de seguridad

Los controles se clasifican por función y por naturaleza. El examen espera que reconozcas ambas clasificaciones.

Por función (qué hacen respecto al ataque):

Tipo	Función	Ejemplo en software
Preventivo	Impide que el incidente ocurra	Validación de entrada, control de acceso, cifrado
Detectivo	Descubre que ocurrió	Logs de auditoría, IDS, monitoreo, alertas
Correctivo	Repara/restaura tras el incidente	Restaurar backup, aplicar un parche, rollback
Disuasivo (deterrent)	Desalienta al atacante	Banner legal de advertencia, aviso de monitoreo
Compensatorio	Sustituye a un control primario que no se puede implementar	MFA reforzado cuando no se puede segmentar la red
Recuperativo (recovery)	Devuelve el sistema a operación normal	Sitio alterno, procedimientos de continuidad

Por naturaleza (cómo se implementan):

Categoría	Descripción	Ejemplo
Administrativo (de gestión)	Políticas, procedimientos, formación	Política de codificación segura, training AppSec
Técnico (lógico)	Implementado en/por el sistema	Firewall, cifrado, IAM, WAF
Físico	Protección del entorno físico	Cerraduras, control de acceso al datacenter, cámaras

flowchart LR
    subgraph T[Linea de tiempo de un incidente]
        A[Disuasivo] --> B[Preventivo] --> C[Detectivo] --> D[Correctivo] --> E[Recuperativo]
    end

💡 Tip de examen: un mismo mecanismo puede pertenecer a varias categorías según el ángulo. Un log de auditoría es detectivo (por función) y técnico (por naturaleza), y sostiene el no repudio. Lee la pregunta para saber qué eje te están pidiendo. El control compensatorio aparece cuando “no se puede aplicar el control ideal”: es la alternativa que provee protección equivalente.

Gestión de riesgos

La gestión de riesgos es el motor de decisión de todo el CSSLP. La seguridad no se hace “porque sí”: se hace para tratar riesgos de forma proporcional a su severidad y al valor del activo.

Términos fundamentales:

Término	Definición
Activo (asset)	Lo que tiene valor y quieres proteger (datos, servicio, reputación)
Amenaza (threat)	Un evento o actor potencial que puede causar daño (un atacante, un fallo)
Vulnerabilidad	Una debilidad que una amenaza puede explotar (un input sin validar)
Probabilidad (likelihood)	Qué tan factible es que la amenaza explote la vulnerabilidad
Impacto	La magnitud del daño si ocurre
Riesgo	La combinación: Riesgo ≈ Amenaza × Vulnerabilidad × Impacto (o probabilidad × impacto)
Riesgo residual	El riesgo que queda después de aplicar los controles
Apetito de riesgo	Cuánto riesgo la organización está dispuesta a asumir para lograr sus objetivos
Tolerancia de riesgo	La variación aceptable alrededor del apetito para un objetivo concreto

flowchart LR
    Th[Amenaza] --> R((Riesgo))
    V[Vulnerabilidad] --> R
    Im[Impacto] --> R
    R --> Ctrl[Aplicar controles]
    Ctrl --> Res[Riesgo residual]
    Res --> Dec{Dentro del<br/>apetito de riesgo?}
    Dec -->|Si| Acc[Aceptar]
    Dec -->|No| More[Mas tratamiento]

Estrategias de tratamiento del riesgo (memorízalas, son omnipresentes en el examen):

Estrategia	Qué haces	Ejemplo
Mitigar (reducir)	Aplicar controles para bajar probabilidad o impacto	Añadir validación de entrada y WAF
Transferir	Pasar el impacto financiero a un tercero	Contratar un ciberseguro; tercerizar con SLA
Aceptar	Asumir el riesgo conscientemente (cuando está dentro del apetito)	Documentar y aceptar un riesgo bajo de un módulo interno
Evitar	Eliminar la actividad que genera el riesgo	No lanzar una feature que expone datos sensibles innecesariamente

Un punto clave de mentalidad: la aceptación del riesgo es una decisión del negocio, del dueño del riesgo (data/system owner), no del ingeniero de seguridad. El especialista informa y recomienda; el propietario acepta formalmente.

💡 Tip de examen: el riesgo residual siempre existe —nunca llega a cero— y quien lo acepta es el propietario del sistema/dato (business owner), no el equipo de seguridad. Si una pregunta dice “el riesgo restante tras los controles… ¿quién decide aceptarlo?”, la respuesta es el dueño del negocio/dato, con la decisión documentada.

---

1.2 Principios de diseño de seguridad

Estos principios son criterios atemporales para diseñar sistemas seguros (muchos provienen de Saltzer y Schroeder, 1975). El examen los evalúa constantemente: te da un escenario y te pide qué principio aplica o cuál se está violando.

Principio	Idea central	Aplicación en software
Least privilege (mínimo privilegio)	Cada sujeto tiene solo los permisos que necesita, ni más	El servicio corre con una cuenta sin admin; un token con scopes mínimos
Separation of duties (SoD)	Ninguna persona controla todo un proceso crítico	Quien escribe el código no aprueba su propio despliegue a producción
Defense in depth	Múltiples capas de control; si una falla, otra protege	WAF + validación + parametrización + mínimo privilegio en la DB
Fail secure / fail safe	Ante un fallo, el sistema queda en estado seguro	Si la autorización falla, deniega por defecto (fail secure)
Economy of mechanism (KISS)	Mantén el diseño simple; la simplicidad es auditable y segura	Menos código, menos features innecesarias, menos superficie de ataque
Complete mediation	Verifica la autorización en cada acceso, sin cachear decisiones inseguras	Revalidar permisos en cada request, no solo al iniciar sesión
Open design	La seguridad no depende del secreto del diseño, sino de las claves	Algoritmos públicos y revisados vs “security by obscurity”
Least common mechanism	Minimiza mecanismos/recursos compartidos entre usuarios	Aislar tenants; no compartir estado sensible entre sesiones
Psychological acceptability	La seguridad debe ser usable; si estorba, la evaden	MFA fluido, mensajes de error claros, defaults seguros y cómodos
Weakest link (eslabón más débil)	La seguridad es tan fuerte como su punto más débil	De nada sirve cifrado fuerte si las credenciales están en el código
Leveraging existing components	Reutiliza componentes probados y mantenidos	Usar una librería criptográfica madura en vez de “rodar la tuya”
Single point of failure (evitarlo)	Ningún componente único debe poder tumbar todo el sistema	Redundancia, degradación elegante, sin dependencias únicas críticas

Fail secure vs fail safe

Un matiz que el examen adora: ambos describen el comportamiento ante un fallo, pero priorizan cosas distintas.

• Fail secure (fail closed): prioriza la seguridad/confidencialidad. Ante el fallo, el sistema deniega el acceso. Ejemplo: si el servicio de autorización cae, nadie entra.
• Fail safe (fail open): prioriza la seguridad de las personas o la disponibilidad. Ante el fallo, el sistema queda en el estado que protege la vida o mantiene el servicio. Ejemplo clásico: una puerta eléctrica que se abre ante un incendio para que la gente pueda salir.

flowchart TD
    F[Ocurre un fallo] --> Q{Que priorizamos?}
    Q -->|Confidencialidad<br/>y control de acceso| FS[Fail secure:<br/>DENEGAR por defecto]
    Q -->|Vida humana o<br/>disponibilidad| FSafe[Fail safe:<br/>estado seguro/abierto]

En software de control de acceso, lo correcto casi siempre es fail secure: si no puedes verificar los permisos, deniega. “Default deny” es la regla.

💡 Tip de examen: para control de acceso en software, la respuesta por defecto es fail secure / default deny: si algo falla o es ambiguo, niega. El fail safe (abrir) se reserva a contextos donde la vida humana o la disponibilidad manda (puertas físicas, sistemas de seguridad industrial).

Open design vs security by obscurity

Open design sostiene que la seguridad de un sistema no debe depender de que su diseño sea secreto. La fortaleza debe residir en las claves y en controles robustos, no en “que nadie sepa cómo funciona”. El contraejemplo es security by obscurity (ocultar el algoritmo, esconder un endpoint), una práctica frágil: en cuanto el secreto se filtra, la seguridad colapsa.

Esto se conecta con el principio de Kerckhoffs en criptografía: un sistema debe ser seguro aunque todo, salvo la clave, sea de conocimiento público. Por eso preferimos algoritmos estándar, públicos y revisados por la comunidad.

💡 Tip de examen: la ofuscación puede ser una capa adicional (defense in depth), pero NUNCA el control primario. Si una respuesta propone “esconder” algo como la medida de seguridad, casi siempre es incorrecta frente a una que usa criptografía estándar o control de acceso real.

Least privilege vs need to know

Se confunden pero no son iguales:

• Least privilege limita las acciones/permisos que un sujeto puede ejecutar.
• Need to know limita el acceso a la información a quienes la necesitan para su función.

Ambos convergen en la misma filosofía: dar lo mínimo indispensable.

Aplicando los principios a un escenario

Para fijar los principios, veamos cómo varios se combinan en un caso concreto: una API que expone datos de clientes.

flowchart TD
    Req[Request a la API] --> CM[Complete mediation:<br/>revalidar permisos en CADA request]
    CM --> LP[Least privilege:<br/>el token solo tiene el scope necesario]
    LP --> Val{Validacion ok?}
    Val -->|No| FS[Fail secure:<br/>denegar por defecto]
    Val -->|Si| DD[Defense in depth:<br/>WAF + validacion + DB con permisos minimos]
    DD --> Resp[Respuesta + log de auditoria]

Observa cómo ningún principio basta solo: complete mediation revalida cada acceso, least privilege limita el alcance del token, fail secure deniega ante la duda, y defense in depth garantiza que si una capa falla, otra protege. Esa combinación es la marca del diseño seguro que el examen premia.

Trust boundaries (fronteras de confianza)

Un concepto que conecta los principios con el diseño real es la frontera de confianza (trust boundary): el punto donde los datos o el control pasan de una zona con un nivel de confianza a otra distinta (por ejemplo, de internet a tu backend, o de tu app a una base de datos). En cada frontera de confianza debes validar, autenticar y autorizar, porque no puedes asumir que lo que viene del otro lado es confiable. Identificar estas fronteras es la base del modelado de amenazas (Dominio 4) y una aplicación directa del principio de complete mediation.

💡 Tip de examen: “nunca confíes en la entrada del cliente” es un mantra del CSSLP. Toda validación de seguridad crítica debe ocurrir del lado del servidor, en la frontera de confianza. La validación solo en el cliente (JavaScript en el navegador) es usabilidad, no seguridad, porque el atacante controla su lado.

---

Secure by design, default y deployment

El CSSLP enfatiza tres momentos donde “lo seguro” debe ser la norma, no la excepción:

Concepto	Significado	Ejemplo
Secure by design	La seguridad se piensa desde la arquitectura, no se añade después	Threat modeling en la fase de diseño; elegir patrones seguros
Secure by default	La configuración de fábrica ya es la más segura; el usuario no tiene que “activar” la seguridad	Sin credenciales por defecto; features peligrosas desactivadas; TLS obligatorio
Secure by deployment	Se despliega de forma segura: hardening, configuración endurecida, secretos gestionados	Baseline de configuración endurecida; secretos fuera del código; permisos mínimos en el entorno

flowchart LR
    A[Secure by DESIGN<br/>arquitectura] --> B[Secure by DEFAULT<br/>configuracion de fabrica] --> C[Secure by DEPLOYMENT<br/>entorno endurecido]

Esta idea —que popularizó también CISA en sus guías de “Secure by Design”— traslada la carga de la seguridad del usuario final al fabricante del software. Un producto que exige al usuario configurar la seguridad manualmente está mal diseñado desde la óptica del CSSLP.

💡 Tip de examen: secure by default significa que la opción más segura viene activada de fábrica y las inseguras están desactivadas. Credenciales por defecto, puertos abiertos innecesarios o funciones peligrosas habilitadas “de serie” son violaciones directas de este principio.

---

Cómo se conectan los conceptos

Estos conceptos no viven aislados. Un buen diseño los teje juntos:

flowchart TD
    Risk[Gestion de riesgo<br/>define QUE proteger y CUANTO] --> Princ[Principios de diseno<br/>definen COMO]
    Princ --> CIA[Propiedades CIA + AAA<br/>lo que buscamos garantizar]
    CIA --> Ctrl[Controles<br/>preventivos/detectivos/correctivos]
    Ctrl --> Res[Riesgo residual]
    Res --> Own[El dueno del negocio acepta<br/>o pide mas tratamiento]
    Own -.retroalimenta.-> Risk

El riesgo dice qué y cuánto; los principios dicen cómo diseñar; las propiedades (CIA/AAA) son las garantías que persigues; los controles son la implementación; y el propietario del negocio acepta el riesgo residual. Ese circuito es la esencia del pensamiento CSSLP.

Errores conceptuales que penaliza el examen

Reconocer los antipatrones te ayuda a descartar respuestas incorrectas rápidamente:

Antipatrón	Por qué está mal	Qué esperaría el examen
Security by obscurity como control primario	Colapsa cuando el secreto se filtra	Criptografía estándar + control de acceso real
Fail open en control de acceso de software	Ante un fallo, deja entrar a todos	Fail secure / default deny
Validar solo en el cliente	El atacante controla su lado	Validar en el servidor, en la frontera de confianza
Cuentas compartidas	Rompen accountability y no repudio	Cuentas individuales con auditoría
”Rodar tu propia criptografía”	Es frágil y raramente revisada	Reutilizar librerías criptográficas probadas
Máximo privilegio “por si acaso”	Amplía la superficie de ataque	Least privilege / need to know
Seguridad añadida al final	Cara e incompleta	Secure by design, desde la arquitectura

Un marco mental para decidir

Cuando una pregunta de este dominio te presente varias opciones, aplica este filtro en orden:

flowchart TD
    A[Cual es el riesgo real<br/>y que activo protege?] --> B[Que propiedad CIA/AAA<br/>esta en juego?]
    B --> C[Que principio de diseno<br/>aplica o se viola?]
    C --> D[La opcion es preventiva<br/>y temprana?]
    D --> E[Prefiere proceso/diseno<br/>sobre truco tecnico]

Este orden —riesgo, propiedad, principio, prevención temprana, proceso— reproduce la mentalidad ISC2 y resuelve la mayoría de preguntas conceptuales por eliminación.

---

Puntos clave

• La tríada CIA (confidencialidad, integridad, disponibilidad) es la base; sus propiedades se equilibran, no se maximizan a ciegas. Añade autenticidad y no repudio.
• AAA: autenticación (quién eres) precede a autorización (qué puedes) y se cierra con accountability/auditing (qué hiciste). Las cuentas compartidas rompen la trazabilidad y el no repudio.
• No repudio = autenticación fuerte + integridad + registro; su mecanismo típico es la firma digital.
• Privacidad ≠ confidencialidad: gira en torno a la PII, con minimización y limitación de retención como respuestas preferentes.
• GRC: la política es obligatoria y de alto nivel; la guideline es recomendada. Jerarquía política → estándar → procedimiento → guideline.
• Controles: por función (preventivo, detectivo, correctivo, disuasivo, compensatorio, recuperativo) y por naturaleza (administrativo, técnico, físico). El compensatorio sustituye a un control ideal inviable.
• Gestión de riesgo: Riesgo ≈ amenaza × vulnerabilidad × impacto. El riesgo residual nunca es cero y lo acepta el dueño del negocio/dato, formalmente y por escrito. Tratamiento: mitigar, transferir, aceptar, evitar.
• Principios de diseño: least privilege, separation of duties, defense in depth, fail secure (default deny), economy of mechanism (KISS), complete mediation, open design (no security by obscurity), least common mechanism, psychological acceptability, weakest link, reutilizar componentes probados, evitar single points of failure.
• Secure by design / default / deployment: la seguridad se piensa desde la arquitectura, viene activada de fábrica y se despliega en un entorno endurecido; la carga es del fabricante, no del usuario.