Dominio 7: Despliegue, operaciones y mantenimiento seguros
Dominio 7: Despliegue, operaciones y mantenimiento seguros
El Dominio 7 (Secure Software Deployment, Operations, Maintenance) pesa 11% del examen y cubre la fase donde el software deja de ser un artefacto de desarrollo y se convierte en un servicio en producción que debe operarse, monitorearse y mantenerse de forma segura durante todo su ciclo de vida útil.
Es un dominio donde el CSSLP quiere que pienses como operador y gestor de riesgo, no como programador. La pregunta recurrente no es “¿cómo escribo este código?” sino “¿qué cambia cuando el software pasa del entorno controlado de desarrollo al entorno hostil de producción?” y “¿qué haría PRIMERO cuando algo sale mal?“.
flowchart LR
A[Build validado] --> B[Hardening y config segura]
B --> C[Release controlado]
C --> D[ATO / aprobación]
D --> E[Operación monitoreada]
E --> F[Mantenimiento: parches y vulns]
F -.retroalimenta.-> B
E -.incidente.-> G[Respuesta a incidentes]
G -.lecciones.-> B7.1 Análisis de riesgo operacional
El software que fue “seguro” en desarrollo puede dejar de serlo en producción porque el contexto cambia. El análisis de riesgo operacional evalúa el riesgo introducido por el entorno de despliegue real, no por el código en sí.
Cambios de contexto que introducen riesgo
| Cambio de contexto | Riesgo que introduce |
|---|---|
| De red interna a Internet | Superficie de ataque expuesta, escaneo automatizado, bots |
| De datos sintéticos a datos reales | Exposición de PII, cumplimiento regulatorio |
| De single-tenant a multi-tenant | Aislamiento de datos, escalamiento entre inquilinos |
| De on-premise a cloud | Modelo de responsabilidad compartida, configuración del proveedor |
| De baja carga a alta carga | Condiciones de carrera, agotamiento de recursos que no aparecían en pruebas |
| De permisos amplios de dev a producción | Necesidad de mínimo privilegio real |
El punto conceptual clave: el mismo binario tiene un perfil de riesgo distinto según dónde y cómo se despliega. Por eso el riesgo se reevalúa en el despliegue, no solo en diseño.
💡 Tip de examen: Cuando una pregunta describe software que “funcionaba bien en pruebas” pero falla en producción, la causa que ISC2 busca casi siempre es un cambio de contexto del entorno (datos reales, exposición de red, escala, configuración), no un bug de código. La respuesta correcta suele ser reevaluar el riesgo del entorno de despliegue.
7.2 Gestión segura de configuración y hardening
La configuración es tan importante como el código. Un software impecable con una configuración por defecto insegura es un software vulnerable. La gestión de configuración segura establece baselines (líneas base) conocidas, controladas y verificables.
Conceptos centrales
- Baseline de configuración segura: estado conocido y aprobado de una configuración. Todo lo que se desvíe (drift) debe detectarse y justificarse o corregirse.
- Hardening: reducir la superficie de ataque desactivando servicios, puertos, cuentas y funciones innecesarias. Aplicar el principio de menor funcionalidad.
- Configuration drift: la desviación gradual del sistema real respecto a su baseline aprobada. Es un enemigo silencioso; se combate con detección continua y remediación automatizada.
- Immutable infrastructure: en lugar de parchear servidores en sitio, se reemplazan por instancias nuevas construidas desde una imagen dorada. Elimina el drift por diseño.
Estándares de hardening de referencia
| Estándar | Emisor | Uso típico |
|---|---|---|
| CIS Benchmarks | Center for Internet Security | Guías de configuración segura por producto (OS, DB, contenedores, cloud). Consenso de la comunidad |
| DISA STIGs | Defense Information Systems Agency (DoD) | Security Technical Implementation Guides, obligatorios en entornos del gobierno de EE.UU. Más estrictos |
| CIS-CAT / SCAP | CIS / NIST | Herramientas para auditar automáticamente el cumplimiento de benchmarks |
Infrastructure as Code (IaC)
Definir la infraestructura como código (Terraform, CloudFormation, Ansible, etc.) hace la configuración versionable, revisable, repetible y auditable. Los beneficios de seguridad:
- El estado de la infraestructura queda en control de versiones (Git), con historial y revisión por pares.
- Se puede escanear la configuración antes de aplicarla (IaC scanning: Checkov, tfsec, KICS) para detectar buckets públicos, security groups abiertos, cifrado desactivado, etc.
- Reproducibilidad: los entornos dev/staging/prod se construyen desde la misma definición, reduciendo el “funciona en mi entorno”.
💡 Tip de examen: IaC no solo automatiza; su valor de seguridad principal es que convierte la configuración en un artefacto versionable y revisable que se puede escanear antes del despliegue. Si una pregunta contrasta configuración manual vs. IaC, la ventaja de seguridad es la auditabilidad y detección de errores antes de producción, no la velocidad.
7.3 Liberar software de forma segura (release management)
El release management controla cómo el software llega a producción minimizando el riesgo de que un despliegue rompa el servicio o introduzca una vulnerabilidad. La clave es poder revertir y limitar el radio de impacto.
Estrategias de despliegue
| Estrategia | Cómo funciona | Ventaja de seguridad/disponibilidad |
|---|---|---|
| Blue/Green | Dos entornos idénticos; se cambia el tráfico del “azul” (actual) al “verde” (nuevo) de golpe | Rollback instantáneo devolviendo el tráfico al entorno anterior |
| Canary | Se libera a un pequeño porcentaje de usuarios primero; se monitorea; se expande gradualmente | Limita el radio de impacto de un fallo; detección temprana |
| Rolling | Se actualizan instancias por lotes hasta cubrir toda la flota | Sin downtime, pero conviven dos versiones durante la transición |
| Feature flags | El código se despliega apagado y se activa por configuración | Desacopla despliegue de activación; kill switch inmediato |
Principios de release seguro
- Rollback plan: toda liberación debe tener un camino de reversión probado antes de desplegar. “No sabemos cómo revertir” es un riesgo inaceptable.
- Separación de despliegue y activación: desplegar código apagado (feature flags) reduce el riesgo del momento del release.
- Aprobaciones y segregación de funciones: quien desarrolla no debería ser quien aprueba el paso a producción sin control (evita cambios no autorizados).
- Integridad del artefacto liberado: el binario que se despliega debe ser exactamente el que se probó y firmó, no uno recompilado (ver 8.3, provenance).
💡 Tip de examen: Ante “¿qué estrategia limita el impacto de un despliegue defectuoso a la menor cantidad de usuarios?” la respuesta es canary. Ante “¿cuál permite el rollback más rápido y completo?” es blue/green. No las confundas: canary = exposición gradual, blue/green = conmutación instantánea.
7.4 Almacenar y gestionar datos de seguridad (secretos en operación)
En operación, la aplicación necesita credenciales, llaves criptográficas, certificados y tokens para funcionar. Gestionarlos mal es una de las causas más frecuentes de brechas.
Reglas de gestión de secretos
- Nunca en código ni en repositorios: los secretos hardcodeados o en archivos de configuración versionados son un fallo crítico (relacionado con OWASP y el D5).
- Secret managers: usar bóvedas dedicadas (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) que ofrecen cifrado en reposo, control de acceso y auditoría.
- Rotación: los secretos deben rotarse periódicamente y automáticamente. Un secreto que nunca cambia es un secreto que eventualmente se filtra.
- Secretos dinámicos / efímeros: generar credenciales de vida corta bajo demanda (p. ej. credenciales de DB que expiran en minutos) reduce drásticamente la ventana de abuso.
- Cifrado de llaves — jerarquía: las llaves de datos se cifran con llaves maestras (KEK/DEK), y las maestras se protegen en un HSM (Hardware Security Module) o KMS.
- Ciclo de vida de certificados: emisión, renovación automatizada (evitar expiraciones que causan caídas), y revocación (CRL/OCSP) cuando se comprometen.
💡 Tip de examen: La mejor práctica que ISC2 premia para secretos en operación es la combinación de bóveda centralizada + rotación automática + secretos efímeros. Si ves “credenciales almacenadas en un archivo de configuración cifrado en el servidor”, sigue siendo inferior a una bóveda con rotación: el objetivo es minimizar la exposición y el tiempo de vida, no solo cifrar el archivo.
7.5 Asegurar la instalación segura
El proceso de instalación y arranque (bootstrapping) es un momento vulnerable: es cuando el software adquiere su configuración inicial, sus secretos y su confianza.
- Secure defaults: el software debe instalarse en su estado más seguro por defecto (fail-safe defaults). Todo lo que aumente el riesgo debe requerir una acción explícita del administrador. Nada de cuentas por defecto activas, contraseñas conocidas o funciones peligrosas encendidas.
- Integridad del instalador: el paquete de instalación debe estar firmado, y su firma verificada antes de ejecutarse, para evitar instaladores manipulados (relacionado con la cadena de suministro, D8).
- Bootstrapping de confianza: cómo obtiene el sistema su primer secreto sin exponerlo (el “secret zero problem”). Se resuelve con identidades de plataforma (instance identity, workload identity) en lugar de credenciales embebidas.
- Mínimo privilegio en instalación: la instalación no debería requerir más privilegios de los estrictamente necesarios.
💡 Tip de examen: “Secure by default” significa que el estado seguro es el estado inicial y que la inseguridad requiere una decisión consciente. Un instalador que crea una cuenta admin con contraseña conocida “para facilitar la configuración” viola este principio, aunque luego pida cambiarla.
7.6 Obtener aprobación de seguridad para operar (ATO)
Antes de que un sistema entre en producción en entornos formales (especialmente gobierno y sectores regulados), debe obtener una autorización para operar. Esto es gobernanza de riesgo, y ISC2 lo trata como una decisión gerencial, no técnica.
Certification & Accreditation → RMF
| Concepto | Significado |
|---|---|
| Certification | Evaluación técnica de que los controles de seguridad están implementados y funcionan (antes) |
| Accreditation | Decisión de gestión de aceptar el riesgo residual y autorizar la operación |
| ATO (Authorization to Operate) | El resultado formal: el sistema está aprobado para operar bajo condiciones definidas |
| Authorizing Official (AO) | El ejecutivo que firma y asume la responsabilidad del riesgo residual |
| Risk acceptance | Reconocer formalmente un riesgo residual y decidir vivir con él (documentado) |
| POA&M | Plan of Action and Milestones: plan documentado para remediar debilidades pendientes |
El modelo clásico C&A evolucionó al NIST Risk Management Framework (RMF), cuyos pasos son: Categorize → Select → Implement → Assess → Authorize → Monitor. El paso Authorize es donde se otorga el ATO, y Monitor conecta con el monitoreo continuo (7.7).
💡 Tip de examen: La aceptación del riesgo residual siempre corresponde a un rol de negocio/gestión (el Authorizing Official o el data/system owner), NUNCA al equipo de seguridad o de desarrollo. Si una pregunta te ofrece “el equipo de seguridad acepta el riesgo”, es distractor. El equipo de seguridad informa y recomienda; el negocio acepta.
7.7 Monitoreo continuo
Una vez en producción, el sistema debe observarse continuamente para detectar anomalías, ataques y desviaciones de la baseline. El monitoreo continuo es también el paso final del RMF: la autorización no es un evento único, es un estado que se mantiene con evidencia.
Componentes
- Logging centralizado: los registros de todas las aplicaciones y sistemas se agregan en un punto central (no dispersos por servidores donde un atacante puede borrarlos). Los logs deben ser inmutables/append-only y protegidos.
- SIEM (Security Information and Event Management): correlaciona eventos de múltiples fuentes para detectar patrones de ataque que un log aislado no revela.
- Detección de anomalías: establecer una línea base de comportamiento normal y alertar sobre desviaciones (picos de tráfico, accesos inusuales, exfiltración).
- Telemetría de aplicación: métricas, trazas y eventos de seguridad que la propia app emite (intentos de login fallidos, errores de autorización, uso de funciones sensibles).
- Qué registrar: eventos de seguridad relevantes (autenticación, autorización, cambios de datos sensibles) sin registrar secretos ni PII innecesaria en los logs.
flowchart LR
A[Apps y sistemas] -->|logs| B[Logging centralizado]
C[Red / infra] -->|eventos| B
B --> D[SIEM: correlación]
D --> E{Anomalía?}
E -->|sí| F[Alerta al SOC]
E -->|no| G[Baseline]
F --> H[Respuesta a incidentes]💡 Tip de examen: Un requisito recurrente de ISC2 es que los logs sean completos, protegidos contra manipulación y no contengan datos sensibles. Registrar contraseñas o números de tarjeta “para depurar” es un antipatrón. Y si un incidente ocurre y “no hay evidencia”, la falla de fondo suele ser logging insuficiente o no centralizado — mapea a OWASP A09:2021 (Security Logging and Monitoring Failures).
7.8 Ejecutar el plan de respuesta a incidentes
Cuando la prevención falla, la organización necesita un plan de respuesta a incidentes (IR) ensayado. ISC2 sigue el ciclo de NIST SP 800-61. Memoriza sus fases y su orden.
flowchart LR
A[Preparación] --> B[Detección y análisis]
B --> C[Contención]
C --> D[Erradicación]
D --> E[Recuperación]
E --> F[Lecciones aprendidas]
F -.mejora.-> ALas fases del ciclo NIST
| Fase | Qué ocurre | Rol del equipo de software |
|---|---|---|
| Preparación | Playbooks, herramientas, contactos, entrenamiento antes del incidente | Instrumentar la app para forense; documentar arquitectura |
| Detección y análisis | Identificar que hay un incidente, determinar alcance e impacto | Interpretar logs de la app, confirmar si es explotación de una vuln conocida |
| Contención | Limitar la propagación (aislar sistemas, cortar accesos) | Desactivar la función afectada (feature flag), aplicar virtual patching |
| Erradicación | Eliminar la causa raíz (malware, cuenta comprometida, vuln) | Corregir el defecto de código, rotar secretos comprometidos |
| Recuperación | Restaurar operación normal y verificar que no reaparezca | Desplegar el fix, monitorear intensivamente el retorno |
| Lecciones aprendidas | Post-mortem: qué pasó, qué mejorar; retroalimenta la preparación | Alimentar el modelado de amenazas y los casos de abuso con lo aprendido |
Rol del software y el PSIRT
- Contención antes que erradicación: PRIMERO se contiene (detener el sangrado), LUEGO se erradica la causa raíz. Erradicar sin contener deja la puerta abierta mientras investigas.
- PSIRT (Product Security Incident Response Team): equipo especializado en incidentes que afectan a un producto de software (a diferencia del CSIRT/SOC, orientado a la infraestructura de TI de la propia organización). El PSIRT coordina la respuesta a vulnerabilidades del producto y la comunicación con clientes afectados.
- Preservación de evidencia: durante la contención, preservar la cadena de custodia y evitar destruir evidencia forense necesaria para el análisis o para acciones legales.
💡 Tip de examen: Dos anclas para el examen. (1) La respuesta a “¿qué se hace PRIMERO tras detectar un incidente activo?” es contener, no erradicar ni reconstruir. (2) La fase que muchos omiten y que ISC2 valora es lecciones aprendidas: cierra el ciclo alimentando la preparación futura. Un IR sin post-mortem repite los mismos errores.
7.9 Gestión de parches
Los parches corrigen defectos, pero aplicarlos también es un riesgo (pueden romper compatibilidad). La gestión de parches balancea la urgencia de cerrar una vulnerabilidad contra la estabilidad operativa.
Elementos de un proceso de parcheo
- Priorización basada en riesgo: no todos los parches son iguales. Se prioriza por severidad (CVSS), explotabilidad real (EPSS, KEV — ver 7.10) y criticidad del activo.
- Testing antes de desplegar: los parches se prueban en staging para evitar que la cura sea peor que la enfermedad. Excepción: parches de emergencia bajo criterio de riesgo.
- Ventanas de mantenimiento: cambios programados en periodos de bajo impacto, con aprobación de cambio (change management).
- Parches de emergencia (out-of-band): para vulnerabilidades críticas activamente explotadas, se salta el ciclo normal con un proceso acelerado de cambio de emergencia.
- Virtual patching: cuando no se puede aplicar el parche real de inmediato (sistema legacy, ventana no disponible), un WAF o IPS bloquea la explotación de la vulnerabilidad como mitigación temporal. No corrige el código; compra tiempo.
💡 Tip de examen: Virtual patching es una mitigación compensatoria y temporal (típicamente con WAF/IPS) cuando no puedes parchear el código de inmediato. No sustituye al parche real. Si una pregunta describe un sistema legacy crítico con una vuln conocida que no puede detenerse para parchear, la respuesta correcta suele ser virtual patching mientras se planifica la corrección definitiva.
7.10 Gestión de vulnerabilidades
Mientras el parcheo aplica correcciones, la gestión de vulnerabilidades es el proceso continuo de descubrir, evaluar, priorizar y rastrear las vulnerabilidades a lo largo del tiempo.
flowchart LR
A[Scanning continuo] --> B[Identificación: CVE]
B --> C[Evaluación: CVSS]
C --> D[Priorización: EPSS + KEV]
D --> E{Explotada / crítica?}
E -->|sí| F[Remediación urgente]
E -->|no| G[Backlog priorizado]
F --> H[Verificación]
G --> H
H --> AEl vocabulario que el examen espera
| Sigla | Qué es | Para qué sirve |
|---|---|---|
| CVE | Common Vulnerabilities and Exposures | Identificador único de una vulnerabilidad conocida |
| CVSS | Common Vulnerability Scoring System | Puntúa la severidad técnica (0-10). NO mide probabilidad de explotación |
| EPSS | Exploit Prediction Scoring System | Estima la probabilidad de que una vuln sea explotada en los próximos 30 días |
| KEV | Known Exploited Vulnerabilities (catálogo de CISA) | Lista de vulns confirmadas como explotadas en el mundo real. Máxima prioridad |
| CWE | Common Weakness Enumeration | Clasifica el tipo de debilidad (la causa), no la instancia |
Priorización moderna
CVSS solo dice qué tan grave sería la explotación, no qué tan probable es. La priorización moderna combina las tres señales: una vuln en el catálogo KEV (explotada activamente) o con EPSS alto debe priorizarse sobre una con CVSS alto pero sin evidencia de explotación.
Divulgación de vulnerabilidades
- Coordinated Vulnerability Disclosure (CVD): proceso ordenado donde un investigador reporta una vuln en privado, el proveedor la corrige, y se divulga públicamente de forma coordinada. Balancea transparencia y protección de usuarios.
- Responsible disclosure: el investigador da tiempo al proveedor antes de publicar.
- Bug bounty: programa que incentiva económicamente la divulgación responsable de vulnerabilidades por parte de investigadores externos.
- VDP (Vulnerability Disclosure Program): política pública que le dice al mundo cómo reportar vulnerabilidades de forma segura (el “security.txt” y el buzón).
💡 Tip de examen: No confundas CVSS (severidad — qué tan malo sería) con EPSS/KEV (probabilidad/realidad de explotación — qué tan probable es). ISC2 empuja hacia la priorización basada en riesgo real: una vulnerabilidad de CVSS medio pero en el catálogo KEV supera en prioridad a una de CVSS alto sin evidencia de explotación.
7.11 Protección en runtime
Además de escribir código seguro, se despliegan controles que protegen la aplicación en tiempo de ejecución, detectando y bloqueando ataques mientras ocurren.
| Control | Qué es | Dónde actúa |
|---|---|---|
| WAF (Web Application Firewall) | Filtra tráfico HTTP malicioso antes de llegar a la app | Perímetro/red, fuera de la aplicación |
| RASP (Runtime Application Self-Protection) | Se integra dentro de la app y observa su ejecución con contexto interno | Dentro del runtime de la aplicación |
| EDR (Endpoint Detection and Response) | Detecta y responde a amenazas en el host/endpoint | Sistema operativo / host |
WAF vs. RASP — la distinción clave
- El WAF ve el tráfico desde fuera; no conoce el estado interno de la app, por lo que puede generar falsos positivos y ser evadido con ofuscación. Es el vehículo típico del virtual patching.
- El RASP vive dentro de la aplicación y tiene contexto de ejecución (qué consulta SQL se va a ejecutar realmente, qué parámetro llega a un sink peligroso), por lo que es más preciso y difícil de evadir, a costa de mayor acoplamiento y overhead.
💡 Tip de examen: La diferencia examinable entre WAF y RASP es la posición y el contexto: WAF filtra en el perímetro sin conocer el estado interno; RASP se ejecuta dentro de la aplicación con contexto completo. Ambos son controles detectivos/preventivos en runtime, complementarios a la codificación segura — nunca un sustituto de ella.
7.12 Continuidad de operaciones (BCP/DRP)
La seguridad incluye la disponibilidad (la A de CIA). La continuidad de operaciones asegura que el software y sus datos sobrevivan a fallos, desastres y ataques como ransomware.
| Concepto | Significado |
|---|---|
| BCP (Business Continuity Plan) | Cómo el negocio sigue operando durante una disrupción (alcance amplio, procesos) |
| DRP (Disaster Recovery Plan) | Cómo se recupera la tecnología específicamente (subconjunto técnico del BCP) |
| RTO (Recovery Time Objective) | Cuánto tiempo máximo puede estar caído un sistema. Responde “¿qué tan rápido debo volver?” |
| RPO (Recovery Point Objective) | Cuántos datos máximos se pueden perder, medido en tiempo. Responde “¿cada cuánto respaldo?” |
| BIA (Business Impact Analysis) | Análisis que determina la criticidad de cada sistema y de ahí deriva RTO/RPO |
Backups y resiliencia
- Regla 3-2-1: 3 copias, en 2 medios distintos, 1 fuera de sitio (offsite/offline).
- Backups inmutables/offline: defensa clave contra ransomware, que busca cifrar también los respaldos accesibles.
- Probar la restauración: un backup que nunca se ha restaurado no es un backup, es una esperanza. La prueba de restauración valida el RTO real.
- Resiliencia por diseño: redundancia, degradación elegante, tolerancia a fallos y circuit breakers para que un fallo parcial no derribe todo el sistema.
💡 Tip de examen: No confundas RTO (tiempo — cuán rápido recuperas) con RPO (datos — cuánto puedes perder). Regla mnemotécnica: T de Time = Tiempo de recuperación; P de Point = Punto en el tiempo del último dato bueno. Ambos se derivan del BIA, que es lo que ISC2 quiere que hagas PRIMERO antes de fijar objetivos de recuperación.
7.13 Objetivos de nivel de servicio (SLA/SLO/SLI)
La operación segura también se mide y se compromete contractualmente. Estos tres términos se confunden constantemente; el examen distingue entre ellos.
| Término | Qué es | Ejemplo |
|---|---|---|
| SLI (Service Level Indicator) | La métrica real medida | Porcentaje de peticiones exitosas: 99.95% |
| SLO (Service Level Objective) | El objetivo interno que se busca cumplir | ”Mantener disponibilidad ≥ 99.9%“ |
| SLA (Service Level Agreement) | El compromiso contractual con el cliente, con penalizaciones | ”Garantizamos 99.9% o compensamos” |
La relación jerárquica: el SLI mide, el SLO es la meta que la organización se pone (más estricta que el SLA para tener margen), y el SLA es la promesa legal externa. Existen SLOs/SLAs de seguridad, no solo de disponibilidad: por ejemplo, tiempo máximo para aplicar un parche crítico, o tiempo de respuesta ante un incidente reportado.
💡 Tip de examen: Ordena la jerarquía: SLI (indicador medido) → SLO (objetivo interno) → SLA (acuerdo contractual con penalización). El SLA es el único con consecuencias legales/contractuales. El SLO suele ser más estricto que el SLA para dar colchón. Y recuerda que la seguridad también tiene SLOs (p. ej., MTTR de parches críticos).
Roles y responsabilidades en operaciones
Una parte importante de este dominio es saber quién decide qué. ISC2 evalúa constantemente la separación de responsabilidades entre roles técnicos y de negocio.
| Rol | Responsabilidad en operaciones | Qué NO le corresponde |
|---|---|---|
| Data / System Owner | Clasificar datos, definir requisitos de protección, aceptar riesgo residual | Implementar los controles técnicos |
| Authorizing Official (AO) | Firmar el ATO, asumir formalmente el riesgo | Operar el sistema día a día |
| Equipo de seguridad / SOC | Monitorear, detectar, recomendar, evaluar controles | Aceptar el riesgo en nombre del negocio |
| Equipo de desarrollo / software | Corregir defectos, aportar contexto en incidentes, instrumentar la app | Autorizar cambios de emergencia sin aprobación |
| Operaciones / SRE | Ejecutar despliegues, mantener disponibilidad, aplicar parches | Decidir clasificación de datos |
| PSIRT | Coordinar respuesta a vulnerabilidades del producto | Gestionar la infraestructura corporativa (eso es el CSIRT) |
El patrón que se repite: el equipo técnico informa y recomienda; el negocio decide y acepta el riesgo. Confundir estos roles es la trampa más común del dominio.
💡 Tip de examen: Ante cualquier pregunta de “¿quién debe X?”, separa siempre decisión de negocio (dueño de datos/AO: aceptar riesgo, clasificar, autorizar) de ejecución técnica (seguridad/dev/ops: implementar, monitorear, remediar). El error clásico es hacer que el equipo de seguridad “acepte” un riesgo que solo el negocio puede aceptar.
El mantenimiento como fase del ciclo de vida
El software en producción no es estático: evoluciona. El mantenimiento seguro distingue cuatro tipos clásicos, y cada uno tiene implicaciones de seguridad.
| Tipo de mantenimiento | Qué es | Riesgo de seguridad asociado |
|---|---|---|
| Correctivo | Corregir defectos (incluidas vulnerabilidades) | El parche puede introducir regresiones; requiere testing |
| Adaptativo | Ajustar a cambios del entorno (nuevo OS, nueva API) | El nuevo contexto puede reactivar riesgos mitigados |
| Perfectivo | Mejorar funcionalidad o rendimiento | Nueva funcionalidad = nueva superficie de ataque |
| Preventivo | Reducir deuda técnica antes de que cause fallos | Requiere re-validar controles al refactorizar |
Cada cambio, sin importar su tipo, debe pasar por gestión de cambios (change management): registro, evaluación de impacto de seguridad, aprobación y trazabilidad. Un cambio “pequeño” sin control es una vía frecuente de introducción de vulnerabilidades.
Decomisionado seguro (secure retirement)
Al final de la vida del software, el retiro también es una actividad de seguridad: sanitización de datos (borrado seguro de PII y secretos), revocación de credenciales y certificados asociados, desconexión ordenada de integraciones, y archivado seguro de datos que deban retenerse por cumplimiento. Un sistema “apagado” pero con datos accesibles sigue siendo un riesgo.
💡 Tip de examen: El decomisionado es parte del ciclo de vida seguro, no un afterthought. La actividad crítica al retirar un sistema es la sanitización/borrado seguro de datos sensibles y la revocación de credenciales. Dejar datos residuales o secretos activos tras el retiro es una falla que ISC2 penaliza.
Despliegue sin tiempo de inactividad (zero-downtime) y seguridad
Las estrategias de release (7.3) permiten desplegar sin caídas, pero introducen un reto de seguridad: durante la transición conviven dos versiones. Consideraciones:
- Compatibilidad de esquema: los cambios de base de datos deben ser compatibles hacia atrás (expand/contract) para que ambas versiones funcionen durante la transición.
- Compatibilidad de sesiones y tokens: los tokens emitidos por la versión antigua deben seguir siendo válidos, y viceversa, sin degradar la seguridad.
- Rollback seguro: revertir no debe dejar datos en un estado inseguro ni exponer migraciones a medio aplicar.
- Health checks de seguridad: la nueva versión no recibe tráfico hasta pasar chequeos que incluyan verificación de configuración segura, no solo “responde 200”.
Escenario integrado: de la vulnerabilidad al cierre
Para consolidar el dominio, un flujo típico que el examen puede presentar por partes:
sequenceDiagram
participant Scan as Scanning continuo
participant VM as Gestión de vulns
participant PSIRT
participant Ops as Operaciones
participant AO as Authorizing Official
Scan->>VM: Detecta CVE en componente (7.10)
VM->>VM: Evalúa CVSS + EPSS + KEV
VM->>PSIRT: Vuln crítica, explotada activamente
PSIRT->>Ops: Contención: virtual patching en WAF (7.9/7.11)
Ops->>Ops: Prepara parche, prueba en staging
Ops->>AO: Solicita cambio de emergencia
AO->>Ops: Aprueba ventana out-of-band
Ops->>Ops: Despliegue canary + rollback listo (7.3)
Ops->>VM: Verifica remediación
PSIRT->>PSIRT: Post-mortem, lecciones aprendidas (7.8)Este flujo entrelaza priorización por riesgo (7.10), virtual patching como contención temporal (7.9/7.11), aprobación de cambio de emergencia por el rol correcto (7.6), despliegue controlado con rollback (7.3) y cierre con lecciones aprendidas (7.8). La habilidad que el examen evalúa es encadenar estas decisiones en el orden correcto.
💡 Tip de examen: Cuando una vulnerabilidad crítica está siendo explotada y no puedes parchear de inmediato, la secuencia correcta es: contener primero (virtual patching), aprobar el cambio por el rol adecuado, desplegar con rollback listo y cerrar con post-mortem. Saltarse la contención para “arreglarlo bien” deja el sistema expuesto durante la preparación del parche.
Puntos clave
- El Dominio 7 (11%) cubre lo que pasa cuando el software llega a producción: la seguridad ahora es un problema de operación y gestión de riesgo continuo, no de código.
- El análisis de riesgo operacional parte de que el perfil de riesgo cambia con el contexto de despliegue (exposición, datos reales, escala), no con el binario.
- El hardening con baselines (CIS Benchmarks, DISA STIGs) e IaC (versionable, escaneable antes de aplicar) reduce y controla la superficie de ataque; el enemigo es el configuration drift.
- Las releases seguras dependen de poder revertir y limitar impacto: canary = exposición gradual, blue/green = conmutación con rollback instantáneo.
- Los secretos en operación van en bóvedas centralizadas con rotación automática y credenciales efímeras, nunca en código.
- El ATO es una decisión de gestión: solo el Authorizing Official / dueño del negocio acepta el riesgo residual, nunca el equipo técnico. Modelo actual: NIST RMF.
- El monitoreo continuo (logging centralizado protegido + SIEM + detección de anomalías) es tanto un control operativo como el paso final del RMF.
- En respuesta a incidentes (ciclo NIST): PRIMERO contener, luego erradicar y recuperar, y cerrar con lecciones aprendidas. El PSIRT atiende incidentes del producto de software.
- Prioriza vulnerabilidades por riesgo real: CVSS (severidad) combinado con EPSS/KEV (probabilidad/explotación activa). Virtual patching es mitigación temporal, no cura.
- La continuidad distingue RTO (tiempo de recuperación) de RPO (pérdida de datos aceptable), ambos derivados del BIA; backups inmutables/offline contra ransomware.
- SLI → SLO → SLA: indicador medido, objetivo interno y compromiso contractual; la seguridad también se mide con SLOs.