Taller de proyecto: Análisis de riesgos y modelado de amenazas
Objetivos: Al terminar este tema, podrás…
- Aplicar metodologías de análisis de riesgos a sistemas de software
- Identificar activos, amenazas y vulnerabilidades en propuestas tecnológicas
- Evaluar y priorizar riesgos según probabilidad e impacto
- Documentar hallazgos en formato profesional
El ingeniero de seguridad en proyectos de software
En el ciclo de desarrollo de software, el ingeniero de seguridad participa desde las primeras etapas. Tu rol es:
- Analizar la arquitectura propuesta — Identificar superficies de ataque
- Modelar amenazas — Anticipar cómo podría ser atacado el sistema
- Evaluar riesgos — Priorizar por probabilidad e impacto
- Proponer controles — Diseñar mitigaciones técnicas específicas
- Documentar decisiones — Justificar cada control con la amenaza que mitiga
Este análisis se realiza antes de escribir código. Es más barato corregir un diseño que reescribir un sistema.
Metodología de análisis de riesgos
Paso 1: Identificar activos
Un activo es cualquier recurso que tiene valor y requiere protección. Clasifica los activos por tipo:
| Categoría | Ejemplos | Valor típico |
|---|---|---|
| Datos de usuarios | PII, credenciales, preferencias | Alto (regulaciones, privacidad) |
| Datos de negocio | Transacciones, contratos, estrategias | Alto (ventaja competitiva) |
| Infraestructura | Servidores, bases de datos, APIs | Medio-Alto (continuidad operativa) |
| Código fuente | Algoritmos, lógica de negocio | Variable (propiedad intelectual) |
| Reputación | Confianza de usuarios, marca | Alto (difícil de recuperar) |
Paso 2: Identificar amenazas con STRIDE
STRIDE es un modelo de Microsoft para categorizar amenazas sistemáticamente:
| Categoría | Descripción | Principio CIAAN afectado |
|---|---|---|
| Spoofing | Suplantar identidad de usuario o sistema | Autenticación |
| Tampering | Modificar datos sin autorización | Integridad |
| Repudiation | Negar haber realizado una acción | No repudio |
| Information Disclosure | Exponer información a no autorizados | Confidencialidad |
| Denial of Service | Impedir acceso al servicio | Disponibilidad |
| Elevation of Privilege | Obtener permisos no autorizados | Autenticación/Autorización |
Paso 3: Identificar vulnerabilidades
Para cada componente del sistema, pregunta:
- ¿Qué entradas acepta? ¿Están validadas?
- ¿Qué datos almacena? ¿Están cifrados?
- ¿Con qué otros sistemas se comunica? ¿Cómo se autentica?
- ¿Qué privilegios tiene? ¿Son los mínimos necesarios?
Paso 4: Evaluar riesgos
Usa una matriz de riesgos para priorizar:
| Impacto Bajo | Impacto Medio | Impacto Alto | Impacto Crítico | |
|---|---|---|---|---|
| Probabilidad Alta | Medio | Alto | Crítico | Crítico |
| Probabilidad Media | Bajo | Medio | Alto | Crítico |
| Probabilidad Baja | Bajo | Bajo | Medio | Alto |
Paso 5: Diseñar controles
Para cada riesgo priorizado, propón controles específicos:
| Riesgo | Control propuesto | Tipo | Costo relativo |
|---|---|---|---|
| SQL Injection | Prepared statements, ORM | Preventivo | Bajo |
| Fuerza bruta | Rate limiting, MFA | Preventivo/Detectivo | Medio |
| Filtración de datos | Cifrado en reposo y tránsito | Preventivo | Medio |
| DDoS | CDN, WAF, auto-scaling | Preventivo/Correctivo | Alto |
Casos de estudio para análisis
Caso A: Sistema de alertas de emergencias
Descripción: Plataforma que envía notificaciones de desastres naturales a ciudadanos. Integra sensores gubernamentales, APIs meteorológicas y geolocalización de usuarios.
Arquitectura simplificada:
[Sensores] → [API Gateway] → [Motor de alertas] → [Push notifications]
↓ ↓
[Base de datos] [Dashboard admin]
Análisis STRIDE:
| Componente | Amenaza STRIDE | Riesgo específico | Impacto |
|---|---|---|---|
| API Gateway | Spoofing | Inyección de alertas falsas | Crítico (pánico) |
| API Gateway | DoS | Sistema caído durante emergencia | Crítico (vidas) |
| Base de datos | Information Disclosure | Filtración de ubicaciones | Alto (privacidad) |
| Motor de alertas | Tampering | Modificación de zonas de alerta | Crítico |
| Dashboard | Elevation of Privilege | Operador malicioso | Crítico |
Controles propuestos:
- Autenticación mutual (mTLS) con fuentes oficiales
- Firma digital de todas las alertas
- Infraestructura multi-región con failover automático
- Minimización de datos de ubicación (retención máxima 24h)
- Control de acceso basado en roles con MFA para operadores
Caso B: Plataforma de transporte público inteligente
Descripción: Sistema que optimiza rutas usando GPS de vehículos, datos de tráfico y patrones de uso. Incluye app para usuarios, app para conductores y panel de control.
Activos identificados:
- Ubicación en tiempo real de usuarios
- Historial de viajes y patrones de movimiento
- Datos de pago (tarjetas, saldo)
- Credenciales de conductores y operadores
- Algoritmos de optimización (IP)
Análisis de riesgos:
| Riesgo | Probabilidad | Impacto | Prioridad | Control |
|---|---|---|---|---|
| Rastreo de usuarios por terceros | Media | Alto | Alto | Anonimización de datos, retención mínima |
| Manipulación de rutas | Baja | Alto | Medio | Firmas digitales, validación server-side |
| Fraude en pagos | Alta | Medio | Alto | Tokenización, 3D Secure |
| Suplantación de conductor | Media | Alto | Alto | Verificación biométrica, device binding |
| DDoS en hora pico | Media | Alto | Alto | CDN, rate limiting, capacidad reservada |
Caso C: Sistema de salud para monitoreo remoto
Descripción: Aplicación que conecta pacientes con profesionales de salud. Integra dispositivos IoT (tensiómetros, glucómetros), almacena historiales y genera alertas médicas.
Consideraciones especiales:
- Datos de salud son categoría especial bajo Ley 1581 (Colombia) y GDPR
- Dispositivos IoT tienen capacidades de seguridad limitadas
- Usuarios pueden tener baja competencia técnica
- Fallos pueden tener consecuencias fatales
Análisis de riesgos críticos:
| Riesgo | Consecuencia | Control |
|---|---|---|
| Modificación de dosis recomendadas | Daño físico o muerte | Firmas digitales, validación por médico, límites de dosis |
| Filtración de historial médico | Discriminación, daño reputacional | Cifrado E2E, acceso basado en consentimiento |
| Dispositivo IoT comprometido | Lecturas falsas, acceso a red | Segmentación de red, firmware firmado |
| Acceso no autorizado a cuenta | Violación de privacidad | MFA, notificaciones de acceso, sesiones limitadas |
Caso D: Sistema de videovigilancia urbana
Descripción: Red de cámaras con análisis de video en tiempo real para seguridad pública. Detecta incidentes, reconoce patrones y alerta a autoridades.
Dilemas de diseño:
| Decisión | Opción A (más seguridad) | Opción B (más privacidad) |
|---|---|---|
| Reconocimiento facial | Activado para identificar sospechosos | Desactivado o anonimizado |
| Retención de video | 90 días para investigaciones | 24-48 horas máximo |
| Acceso en tiempo real | Cualquier oficial autorizado | Solo bajo orden judicial |
Riesgos específicos de este dominio:
- Uso para vigilancia masiva no justificada
- Manipulación de evidencia para incriminación falsa
- Acceso de actores maliciosos (chantaje, voyeurismo)
- Sesgo algorítmico en reconocimiento facial
Documentación de análisis de riesgos
Un análisis profesional incluye:
1. Resumen ejecutivo
- Descripción del sistema analizado
- Principales riesgos identificados
- Recomendaciones prioritarias
2. Inventario de activos
- Lista de activos con clasificación de sensibilidad
- Propietario de cada activo
- Requisitos de protección (CIAAN)
3. Modelo de amenazas
- Diagrama de flujo de datos (DFD)
- Superficie de ataque identificada
- Actores maliciosos considerados (del tema 02)
- Análisis STRIDE por componente
4. Evaluación de riesgos
- Matriz de riesgos con probabilidad e impacto
- Priorización de riesgos
- Riesgos residuales aceptados
5. Controles propuestos
- Control técnico para cada riesgo prioritario
- Justificación de cada control
- Costo estimado de implementación
- Riesgos mitigados vs. residuales
Preparación para la primera sustentación
Para tu primera evaluación de proyecto, deberás presentar:
- Contexto del proyecto — ¿Qué sistema estás analizando?
- Inventario de activos — ¿Qué datos y sistemas requieren protección?
- Modelo de amenazas — ¿Quién atacaría? ¿Con qué técnicas?
- Análisis CIAAN — ¿Qué principios están en riesgo?
- Matriz de riesgos — ¿Cuáles son los riesgos prioritarios?
- Propuesta inicial de controles — ¿Cómo mitigarías los riesgos principales?
Consulta los criterios de evaluación para más detalles.
Conceptos clave
| Término | Definición |
|---|---|
| Activo | Recurso con valor que requiere protección |
| Vulnerabilidad | Debilidad explotable en un sistema |
| STRIDE | Modelo de categorización de amenazas (Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege) |
| Superficie de ataque | Conjunto de puntos donde un atacante puede intentar acceder |
| DFD | Diagrama que muestra cómo fluyen los datos en un sistema |
| Riesgo residual | Riesgo que permanece después de aplicar controles |
Ponte a prueba
-
Análisis STRIDE: Para un sistema de banca en línea, identifica al menos una amenaza de cada categoría STRIDE y propón un control para mitigarla.
-
Priorización: Tienes presupuesto para implementar solo 3 controles en una app de delivery de comida. ¿Cuáles priorizarías? Justifica usando probabilidad e impacto.
-
Documentación: Selecciona una aplicación real (puede ser el proyecto de tu equipo) y crea un inventario de activos con clasificación de sensibilidad.
-
Trade-offs: En el sistema de videovigilancia, ¿cómo balancearías seguridad pública vs. privacidad individual? Propón controles técnicos que permitan ambos.
Laboratorio práctico: Modelado de amenazas con OWASP Threat Dragon
Tiempo estimado: 120 minutos Requisitos: Docker o navegador web Herramienta: OWASP Threat Dragon
Objetivo
Crear un modelo de amenazas profesional utilizando herramientas estándar de la industria, generando documentación lista para revisión técnica.
Instalación
Opción A - Docker (recomendada):
docker run -p 3000:3000 owasp/threat-dragon:stable
# Accede a http://localhost:3000Opción B - Aplicación web: Visita https://www.threatdragon.com/ (requiere cuenta GitHub)
Parte 1: Crear el diagrama de flujo de datos (40 min)
Modela el siguiente sistema: Plataforma de préstamos universitarios
Descripción del sistema:
- Estudiantes solicitan préstamos a través de una app móvil
- El backend valida identidad con una API gubernamental
- Un motor de decisión evalúa riesgo crediticio
- Los administradores aprueban/rechazan solicitudes desde un portal web
- Los fondos se desembolsan a través de integración bancaria
Componentes a modelar:
-
Procesos:
- App móvil estudiante
- API Gateway
- Servicio de autenticación
- Motor de decisión crediticia
- Portal administrativo
- Servicio de desembolso
-
Almacenes de datos:
- Base de datos de solicitudes
- Base de datos de usuarios
- Logs de auditoría
-
Entidades externas:
- Estudiante (usuario)
- Administrador
- API gubernamental (validación de identidad)
- Sistema bancario (desembolsos)
-
Flujos de datos:
- Conecta los componentes mostrando qué datos fluyen entre ellos
- Marca los límites de confianza (trust boundaries)
Guía en Threat Dragon:
1. Crear nuevo modelo → "Préstamos Universitarios"
2. Agregar diagrama → "Diagrama Principal"
3. Arrastrar componentes desde la paleta:
- Process (círculos) para servicios
- Store (cilindros) para bases de datos
- Actor (rectángulos) para entidades externas
4. Conectar con flechas de flujo de datos
5. Agregar Trust Boundary (líneas punteadas) para separar:
- Red pública (app, usuarios)
- DMZ (API Gateway)
- Red interna (servicios, bases de datos)
- Sistemas externos (banco, gobierno)
Parte 2: Identificar amenazas STRIDE (30 min)
Para cada componente principal, usa Threat Dragon para agregar amenazas:
API Gateway:
| STRIDE | Amenaza específica | Severidad |
|---|---|---|
| Spoofing | Solicitudes desde app falsificada | Alta |
| Tampering | Modificación de montos en tránsito | Crítica |
| DoS | Sobrecarga durante período de matrícula | Alta |
Motor de decisión crediticia:
| STRIDE | Amenaza específica | Severidad |
|---|---|---|
| Tampering | Manipulación de reglas de aprobación | Crítica |
| Information Disclosure | Filtración de scores crediticios | Alta |
| Elevation of Privilege | Aprobación sin autorización | Crítica |
Base de datos de solicitudes:
| STRIDE | Amenaza específica | Severidad |
|---|---|---|
| Information Disclosure | Exposición de datos financieros | Crítica |
| Tampering | Modificación de estados de solicitud | Crítica |
| Repudiation | Borrado de logs de aprobaciones | Alta |
Ejercicio: Completa el análisis STRIDE para los componentes restantes.
Parte 3: Proponer mitigaciones (30 min)
En Threat Dragon, agrega mitigaciones para cada amenaza identificada:
Ejemplo de documentación en la herramienta:
Amenaza: Modificación de montos en tránsito
Categoría: Tampering
Componente: API Gateway → Motor de decisión
Severidad: Crítica
Mitigación propuesta:
1. TLS 1.3 con certificate pinning
2. Firma digital (HMAC-SHA256) de cada solicitud
3. Validación de montos contra límites del programa
4. Verificación cruzada con solicitud original
Estado: Mitigado
Riesgo residual: Bajo
Parte 4: Generar reporte (20 min)
Threat Dragon permite exportar el modelo completo:
- Exportar diagrama: File → Export → PNG/SVG
- Exportar modelo: File → Export → JSON
- Generar reporte: Report → Generate
Estructura del reporte esperado:
# Modelo de Amenazas: Plataforma de Préstamos Universitarios
## 1. Resumen Ejecutivo
- Sistema analizado
- Fecha del análisis
- Equipo de análisis
- Principales hallazgos
## 2. Diagrama de Flujo de Datos
[Insertar imagen exportada]
## 3. Límites de Confianza
- Trust Boundary 1: Red Pública / DMZ
- Trust Boundary 2: DMZ / Red Interna
- Trust Boundary 3: Red Interna / Sistemas Externos
## 4. Inventario de Amenazas
| ID | Componente | Categoría | Amenaza | Severidad | Estado |
|----|------------|-----------|---------|-----------|--------|
| T-001 | API Gateway | Tampering | Modificación de montos | Crítica | Mitigado |
| T-002 | ... | ... | ... | ... | ... |
## 5. Mitigaciones Propuestas
[Tabla de mitigaciones con costo y responsable]
## 6. Riesgos Residuales
[Riesgos aceptados con justificación]Entregable
Entrega los siguientes archivos:
- Modelo Threat Dragon (
.json): El archivo del proyecto exportado - Diagrama DFD (
.png): Imagen del diagrama de flujo de datos - Reporte de amenazas (
.mdo.pdf): Documento con:- Mínimo 10 amenazas identificadas
- Mínimo 8 mitigaciones propuestas
- Análisis de riesgos residuales
- Recomendaciones priorizadas
Criterios de evaluación
| Criterio | Puntos |
|---|---|
| DFD completo y correcto | 25 |
| Límites de confianza bien definidos | 15 |
| Amenazas STRIDE identificadas (cobertura) | 25 |
| Mitigaciones técnicamente apropiadas | 25 |
| Calidad de documentación | 10 |
Reflexión
Después de completar el laboratorio:
- ¿Qué amenazas te sorprendió descubrir al mapear el sistema?
- ¿Cómo priorizarías las mitigaciones si tuvieras presupuesto limitado?
- ¿Qué diferencia hay entre este análisis sistemático y simplemente “pensar en seguridad”?
Navegación: ← Anterior | Inicio | Siguiente: Evaluación →