Modelado de amenazas para perfiles tech 2026: STRIDE más allá del corporate

Tabla de contenidos

• Por qué el threat modeling genérico falla para perfiles tech
• EFF SSD adaptado: activos, adversarios, capacidades
• STRIDE para perfiles no corporativos
• Matriz de riesgo: dev solo en Mac, iPhone, GitHub, AWS
• Mitigaciones por nivel
• Seis perfiles: activos, adversarios, mitigaciones prioritarias
• Revisión anual: checklist de reevaluación

¿Qué es el threat modeling para usuarios técnicos?

El threat modeling es un proceso estructurado para identificar qué activos posees, quién podría atacarlos, qué capacidades tienen y qué mitigaciones reducen primero los riesgos más altos. Para profesionales técnicos — desarrolladores, sysadmins, mantenedores OSS — la lista de activos incluye credenciales cloud, pipelines CI/CD y registrars de dominios, no solo cuentas personales. El objetivo son decisiones de seguridad priorizadas y basadas en evidencias.

Por qué el threat modeling genérico falla para perfiles tech

El NIST Cybersecurity Framework 2.0 (publicado en febrero de 2024) es un documento de gobernanza sólido. No te dice qué hacer cuando un mantenedor OSS descubre que una PR maliciosa acaba de aterrizar en un paquete con 40.000 descargas semanales. Los consejos de seguridad genéricos para consumidores — "usa un gestor de contraseñas, activa la 2FA" — son necesarios pero insuficientes para cualquiera cuya superficie digital se parece a: tres organizaciones de GitHub, una cuenta root de AWS, un pipeline CI con llaves de despliegue, un endpoint SSH público, DNS gestionado a través de Cloudflare, y una máquina de desarrollo que también accede a la banca personal.

El problema no es la sofisticación. Es la especificidad. Las guías para consumidores modelan un perfil de amenaza de "toma de control de cuenta por atacante oportunista". El perfil de amenaza realista de un desarrollador o sysadmin incluye: inyección dirigida en la cadena de suministro, exfiltración de secretos CI/CD, robo de clave SSH de un repositorio dotfiles comprometido, e ingeniería social de alguien que ha leído tu historial de commits y conoce tu stack de despliegue.

EFF Surveillance Self-Defense (ssd.eff.org) encuadra correctamente la seguridad como una función de tu situación específica — activos, adversarios, capacidades, probabilidad, consecuencias. Las guías para consumidores se saltan el primer paso: enumerar con precisión lo que realmente tienes que vale la pena atacar.

Por esta razón, la metodología que sigue comienza con la enumeración de activos específica para profesionales técnicos, luego mapea adversarios con evaluaciones realistas de sus capacidades, antes de abordar cualquier recomendación de mitigación.

Consulta la guía pillar sobre privacidad de navegadores en 2026 para el contexto más amplio de privacidad en el que se enmarca este modelo de amenazas.

EFF SSD adaptado: activos, adversarios, capacidades

Enumeración de activos para profesionales técnicos

Antes de categorizar amenazas, enumera lo que realmente posees. Para un desarrollador independiente o mantenedor OSS típico en 2026, el inventario de activos se desglosa en cinco categorías:

Activos de identidad: cuentas de GitHub/GitLab (vinculadas a una reputación pública y permisos organizativos), cuentas root de proveedores cloud (AWS, GCP, Azure), cuentas de registrars de dominios (la raíz de tu presencia web), cuentas de email (la ruta de recuperación de todo lo demás), y cuentas de registros de paquetes (npm, PyPI, crates.io — el radio de explosión de un compromiso aquí se extiende a cada consumidor downstream).

Activos de infraestructura: servidores y contenedores de producción, zonas DNS, certificados TLS y configuraciones de CA, llaves SSH (especialmente las llaves de despliegue con acceso de escritura a repositorios), roles IAM cloud y cuentas de servicio, secretos almacenados en archivos .env o gestores de secretos.

Activos de código: repositorios privados, configuraciones de pipelines CI/CD, archivos lockfile de dependencias, llaves de firma para commits o publicaciones de paquetes.

Activos financieros: cuentas de Stripe/procesadores de pago, métodos de pago para renovaciones de dominio, wallets de criptomonedas si aplica.

Activos de reputación: tu historial de commits público, tu acceso de publicación de paquetes, tus cuentas sociales vinculadas a tu identidad profesional.

Taxonomía de adversarios

EFF SSD usa una taxonomía de adversarios de cinco niveles. Adaptada al perfil del profesional técnico:

Los atacantes oportunistas escanean internet en busca de credenciales expuestas, servicios sin parches y contraseñas reutilizadas. Son automatizados, de alto volumen y baja sofisticación. Encontrarán tu instancia EC2 con el puerto 22 abierto en minutos después del lanzamiento si está en un rango de IP residencial. Esta es la amenaza base que abordan los fundamentos de seguridad.

Los atacantes dirigidos (criminales o competidores) te han identificado específicamente como objetivo de valor financiero. Crearán spear-phishing contra tu stack específico, intentarán inyección en la cadena de suministro de tus dependencias, y monitorearán tu actividad pública para recopilar inteligencia operativa. Alcanzar este nivel requiere ingresos significativos, custodia de datos valiosos, o visibilidad en un espacio financieramente interesante.

Los actores estatales operan con una persistencia prácticamente ilimitada y un amplio conjunto de capacidades zero-day. Para la mayoría de los profesionales, este nivel de amenaza requiere circunstancias excepcionales: trabajar en infraestructura gubernamental sensible, ser un disidente político, o ser periodista cubriendo servicios de inteligencia. La existencia de este nivel importa para la calibración — no deberías diseñar todas las mitigaciones para la resiliencia contra actores estatales, porque la relación coste/complejidad es inviable para la mayoría de las situaciones.

Las amenazas internas son personas con acceso legítimo que actúan maliciosamente o por negligencia. Para profesionales en solitario es menos relevante; para mantenedores OSS con múltiples colaboradores, es significativo — una cuenta de mantenedor comprometida, un colaborador molesto con derechos de fusión, o un commit accidental de secreto por un colaborador de confianza caen todos aquí.

Matriz de capacidades — para cada tipo de adversario, evalúa qué recursos tienen: bases de datos de credenciales, infraestructura para phishing, exploits zero-day, compulsión legal, acceso físico. Cruzar el valor de los activos con las capacidades del adversario produce el espacio de amenazas realista que necesitas abordar.

¿Cómo aplicar el framework STRIDE como desarrollador individual?

STRIDE categoriza las amenazas en seis clases aplicables a la infraestructura personal:

1. Spoofing — toma de control de cuenta mediante phishing o credential stuffing (mitigar con llaves FIDO2 hardware)
2. Tampering — dependencia maliciosa o pipeline CI comprometido (mitigar con Sigstore, lockfiles fijados)
3. Repudiation — incapacidad para probar la autoría de un commit (mitigar con firma SSH/GPG de commits)
4. Information Disclosure — archivos .env o claves API filtrados (mitigar con escaneo de secretos en pre-commit)
5. Denial of Service — DDoS en tu API o agotamiento del presupuesto CI (mitigar con Cloudflare, rate limiting)
6. Elevation of Privilege — pipeline CI con acceso de escritura que acepta código de PRs no confiables (mitigar con federación OIDC)

El framework STRIDE de Microsoft (1999, Adam Shostack) categoriza las amenazas en seis clases. Los equipos de seguridad corporativos lo aplican a diagramas de flujo de datos de arquitecturas de aplicaciones. Para profesionales individuales, aplícalo a la topología de tu infraestructura personal.

Spoofing (toma de control de cuenta). La amenaza de spoofing para un desarrollador es principalmente la toma de control de cuenta: alguien te suplanta en GitHub, tu consola cloud o tu registrar para realizar acciones bajo tu identidad. Vectores de ataque: credential stuffing desde bases de datos violadas, proxies de phishing en tiempo real (Evilginx2 puede eludir la 2FA TOTP), SIM swapping (para interceptar la 2FA por SMS), y robo de tokens OAuth a través de GitHub Apps maliciosas. La mitigación es la autenticación resistente al phishing — llaves FIDO2 hardware — para cuentas donde un spoofing exitoso tiene alto radio de explosión.

Tampering (cadena de suministro). Un artefacto alterado significa que código modificado llega a producción o a usuarios finales. Para un desarrollador esto se manifiesta como: una PR maliciosa fusionada sin revisión adecuada, una actualización de versión de dependencia que introduce una backdoor (xz utils, event-stream), un entorno de build comprometido que firma un binario modificado, o un token de publicación npm robado. La pila de mitigaciones incluye: Sigstore/cosign para firma de artefactos, lockfiles fijados con verificación de hash, puertas de revisión de código que no confían en bots automatizados, y niveles de procedencia SLSA.

Repudiation (pistas de auditoría). ¿Puedes demostrar qué ocurrió y quién lo hizo? La firma de commits git con llaves SSH o GPG establece un registro a prueba de manipulaciones de los cambios de código. Los commits firmados no previenen ataques pero sí establecen responsabilidad — crítico si necesitas demostrar a usuarios downstream que un commit específico no fue escrito por ti. CloudTrail y los registros de auditoría equivalentes para acciones cloud cumplen la misma función.

Information Disclosure (secretos filtrados). El incidente de alto impacto más frecuente en el mundo del desarrollo. Un archivo .env commiteado en un repositorio público, una clave AWS en un log de GitHub Actions, una cadena de conexión a la base de datos en un mensaje de error, o una clave privada integrada en una capa de imagen Docker. git-secrets, truffleHog y el secret scanning de GitHub detectan secretos commiteados; los hooks pre-commit los previenen. Rotar credenciales inmediatamente tras cualquier divulgación sospechada es innegociable.

Denial of Service (disponibilidad). Para un desarrollador en solitario que gestiona un producto SaaS, un DDoS sostenido puede eliminar ingresos. Más sutil: el rate limiting en tus llamadas a la API de GitHub o el agotamiento del pipeline CI/CD a través de una dependencia diseñada que dispara tiempos de build excesivos. La mitigación a nivel base es Cloudflare o protección DDoS/CDN equivalente delante de endpoints públicos. A nivel de infraestructura, asegúrate de que una sola dependencia comprometida no tenga la capacidad de agotar tu presupuesto CI.

Elevation of Privilege (pipelines CI/CD). Un pipeline CI que se ejecuta con acceso de escritura al entorno de producción y acepta código arbitrario de pull requests es un vector EoP: un atacante envía una PR que exfiltra llaves de despliegue o escribe código malicioso en producción. GitHub Actions mitiga esto con el evento pull_request teniendo un GITHUB_TOKEN de solo lectura por defecto, pero muchos repositorios anulan esto. Separar workflows para PRs no confiables (solo lectura, sin secretos) de fusiones de confianza (acceso de despliegue) es la arquitectura correcta. La federación OIDC elimina completamente las credenciales long-lived en CI.

Matriz de riesgo: dev solo en Mac, iPhone, GitHub, AWS

Un ejemplo concreto: un desarrollador en solitario gestionando un producto SaaS en Mac (estación de trabajo principal), iPhone (dispositivo 2FA y comunicación personal), GitHub (código y CI/CD), y AWS (infraestructura de producción). Puntuando cada vector usando una escala simplificada de probabilidad × impacto (1-5):

Esta matriz indica dónde concentrar el esfuerzo primero: protección de la cuenta de GitHub y cuenta root de AWS, más prevención de fugas de archivos .env. Todo lo demás es importante pero no tiene prioridad.

Para referencia sobre la puntuación CVSS 3.1 de vulnerabilidades específicas en tus dependencias, la base de datos NVD (nvd.nist.gov) proporciona puntuaciones base para CVEs; los modificadores ambientales y temporales permiten ajustar las puntuaciones a tu contexto de despliegue.

Mitigaciones por nivel

Nivel base (todos los profesionales tech, sin excepciones)

Passkeys y llaves de seguridad FIDO2 hardware para GitHub, consolas cloud, registrars de dominios y email. Estas son las cuentas donde la toma de control tiene el mayor radio de explosión. Una cuenta de registrar comprometida permite a un atacante tomar el control de cada dominio y certificado asociado. Una cuenta de GitHub comprometida les permite empujar código malicioso y exfiltrar todos los secretos de repositorios.

2FA basada en TOTP (Ente Auth, Aegis, 1Password TOTP) para cada cuenta que no soporta passkeys. TOTP no es resistente al phishing pero derrota el credential stuffing a escala. La 2FA por SMS es peor que TOTP para cuentas asociadas a un número de teléfono conocido — el SIM swapping es un vector de ataque documentado.

Gestor de contraseñas con credenciales únicas generadas aleatoriamente para cada cuenta. Bitwarden y 1Password integran herramientas CLI para uso en automatización. Consulta la guía de gestores de contraseñas para ingenieros para detalles de integración CLI.

Hook pre-commit de escaneo de secretos. Instala truffleHog o git-secrets como hook pre-commit. Ejecuta git log --all --full-history contra tus repositorios existentes para auditar filtraciones históricas.

Bloqueo de cuenta root de AWS. Las credenciales root de AWS deben tener MFA activado con una llave hardware, y la cuenta root no debe tener llaves de acceso generadas. Todo el acceso operacional debe usar roles IAM con políticas de mínimo privilegio.

Nivel intermedio

Llave de seguridad hardware dedicada (YubiKey 5 NFC o equivalente). La YubiKey 5 soporta FIDO2, PIV, OpenPGP y OTP en un solo dispositivo. Para FIDO2, registra dos llaves y almacena la de respaldo en una ubicación físicamente separada.

Máquina de desarrollo o VM dedicada para las operaciones más sensibles. Si tu máquina de uso diario ejecuta npm install arbitrarios de muchos proyectos, su almacén de credenciales está expuesto a cualquier paquete que ejecute un script de instalación malicioso. Una VM dedicada y reforzada con solo las herramientas necesarias para el acceso a cuentas financieras o gestión de infraestructura sensible limita el radio de explosión de un compromiso de la estación de trabajo.

Firma de commits. Configura la firma de commits SSH (soportada por GitHub desde 2022) o firma GPG para todos los commits. Habilita reglas de protección de ramas que requieran commits firmados en ramas main/release.

Cron de auditoría. Una verificación automatizada semanal: aws iam generate-credential-report para revisar credenciales IAM, gh api /user/installations para auditar permisos de GitHub Apps, verificaciones equivalentes para cambios DNS no autorizados. Estas son señales detectables de compromiso de cuenta que ocurren antes de que un atacante logre su objetivo.

Fijación de dependencias con verificación de hash. Bloquea las dependencias a SHAs de commit específicos o hashes de dirección por contenido, no a rangos de versiones semánticas flotantes. Para npm, npm ci con un package-lock.json commiteado; para Python, pip-compile con requirements hasheados; para Go, go.sum ya está basado en hashes.

Nivel avanzado

Tailscale (o Headscale) para acceso a infraestructura. No expongas nada en internet público que no necesite ser público. SSH, paneles de administración, dashboards de monitoreo y entornos de staging pertenecen a un mesh Tailscale. Combina con ACLs de Tailscale para aplicar acceso de red de mínimo privilegio entre dispositivos. Headscale (servidor de coordinación auto-hospedado) elimina la dependencia de la infraestructura de coordinación de Tailscale.

Perfiles de navegador separados por contexto. Las cuentas financieras, el trabajo de desarrollo, la navegación general y las redes sociales deben ejecutarse en perfiles de navegador aislados o binarios de navegador separados. Firefox con Multi-Account Containers logra aislamiento a nivel de contenedor dentro de un solo binario. Esto previene la correlación de cookies y sesiones entre contextos. Consulta la guía de detección de fugas de red para la metodología de detección, y usa nuestra herramienta de prueba de huella del navegador para verificar cuánto de tu identidad canvas y WebGL persiste entre cambios de perfil.

Entorno de build aislado. El CI debe ejecutarse en entornos efímeros sin credenciales persistentes. Para builds locales, un contenedor o VM sin montaje de credenciales del host asegura que un script de build malicioso no pueda cosechar el agente SSH del host, credenciales cloud o el keychain.

VPN para contextos de red sensibles. Una VPN sin registros y auditada en redes no confiables (Wi-Fi público, ethernet de hotel) previene la interceptación pasiva del tráfico no cifrado y oculta tu IP de los servidores de destino. La guía de VPN para perfiles tech cubre la metodología de evaluación de proveedores. Combina con nuestro verificador de cabeceras de seguridad HTTP para auditar las cabeceras que tus propios servicios web exponen a observadores pasivos.

Seis perfiles: activos, adversarios, mitigaciones prioritarias

Revisión anual: checklist de reevaluación

Un modelo de amenazas no es un documento que produces una vez y archivas. La superficie de amenazas cambia a medida que cambia tu actividad. Los siguientes eventos requieren cada uno una reevaluación inmediata:

Eventos desencadenantes que requieren reevaluación inmediata:

• Un nuevo proyecto se vuelve públicamente visible (lanzamiento en ProductHunt, stars de GitHub superando los 1.000, mención en prensa)
• Obtienes acceso administrativo a infraestructura que no controlabas antes
• Un incidente de seguridad toca alguna cuenta de tu ecosistema, incluso indirectamente
• Tus ingresos superan un umbral que hace que un ataque financiero sea económicamente racional
• Recibes un mensaje que podría ser ingeniería social dirigida
• Tu nombre aparece en un contexto que aumenta el riesgo de doxxing

Checklist de reevaluación anual:

1. Re-enumera todos los activos. ¿Qué cuentas existen que no existían hace seis meses? ¿Qué servicios has añadido a tu stack?
2. Audita los tokens de acceso. Ejecuta gh auth list, aws iam list-access-keys --user-name <todos los usuarios>, gcloud auth list. Revoca todo lo que no se use activamente.
3. Revisa los métodos de 2FA. ¿Alguna cuenta ha sido degradada de llave hardware a TOTP, o de TOTP a SMS? Corrige las regresiones.
4. Comprueba secretos expuestos. Ejecuta truffleHog en todos los repositorios incluyendo los privados. Ejecuta Grype o equivalente contra imágenes de contenedores.
5. Actualiza los lockfiles de dependencias. Fija a versiones actuales conocidas como buenas, revisa el changelog para cambios relevantes de seguridad.
6. Revisa las políticas IAM cloud. El principio de mínimo privilegio se erosiona con el tiempo a medida que se añaden permisos por conveniencia y nunca se eliminan.
7. Prueba la restauración de backups. Un backup no probado no es un backup. Verifica que tus imágenes de disco cifradas, snapshots de base de datos y backups de frase seed estén intactos y sean recuperables.
8. Reevalúa el nivel de adversario. ¿Ha cambiado algo en tu perfil profesional o público que te elevaría a un nivel de objetivo más valioso?

La función de Gobernanza del NIST CSF 2.0 formaliza este tipo de bucle de mejora continua a nivel organizativo. Para individuos, el equivalente es un recordatorio de calendario, una checklist estructurada y la disciplina de ejecutarla incluso cuando nada ha salido visiblemente mal.

La EFF publica guías actualizadas en ssd.eff.org de forma continua. La MITRE ATT&CK Matrix (attack.mitre.org) se actualiza trimestralmente con nuevas técnicas de adversarios derivadas de incidentes reales — útil para verificar si nuevas TTPs son relevantes para tu perfil.

Construir un modelo de amenazas fiable no es un ejercicio de una tarde. Es el hábito de preguntar sistemáticamente, ante cada cambio significativo en tu superficie de ataque: ¿qué podría hacer un adversario con esto, y es el coste de prevenirlo menor que el coste del incidente? Los frameworks anteriores — EFF SSD, STRIDE, puntuación CVSS 3.1 — te dan lenguaje reproducible para esa conversación, ya sea contigo mismo, con tus colaboradores, o con un profesional de seguridad al que consultas cuando las apuestas son lo suficientemente altas como para justificar una opinión externa.