Modelado de amenazas para una plataforma pequeña en un VPS offshore

El modelado de amenazas tiene fama de ser un ritual corporativo con diagramas que nadie lee. No tiene por qué serlo. Para una plataforma pequeña, la versión útil dura una hora, produce una lista ordenada, y su principal resultado es saber a qué riesgos afectan realmente sus decisiones de infraestructura — porque, para la mayoría, la respuesta honesta es a ninguno.

El orden importa más que la exhaustividad

El error clásico es una larga lista de todo lo que podría salir mal, tratada como si todo fuera igual de urgente. Eso produce parálisis, y al final una decisión tomada de todos modos por intuición. Una lista ordenada de siete elementos vale más que una lista exhaustiva de cuarenta, porque de todas formas actuará sobre los tres primeros y nunca llegará a los demás.

Ordénelos por probabilidad × coste para usted, no por lo alarmante que suene el escenario. Un adversario estatal es el elemento más aterrador de cualquier lista y, para casi cualquier plataforma pequeña, el menos probable — mientras que una filtración de credenciales por parte de un antiguo contratista es anodina, extremadamente frecuente y, por lo general, catastrófica.

Siete adversarios, ordenados por probabilidad

Adversarios por probabilidad y qué los mitiga

Adversario	Probabilidad	El alojamiento ayuda	Qué lo mitiga realmente
Usted, en un mal día	Segura	No	Copias de seguridad que realmente haya restaurado, y un proceso de cambios para todo lo que afecte a la autenticación o al DNS. La causa más probable de su peor caída es usted.
Escaneo automatizado	Constante	No	Aplicar parches, sin autenticación por contraseña, sin credenciales por defecto. Esto es ruido de fondo; no va dirigido contra usted y no se detiene nunca.
Compromiso de credenciales	Alta	No	Un segundo factor por hardware, tokens de API con alcance limitado, y revocar el acceso el mismo día en que alguien se marcha, en lugar de al trimestre siguiente.
Un denunciante con un formulario	Alta	Sí	Este es el único caso que la jurisdicción de alojamiento realmente afecta: si una simple correspondencia basta para tumbar su servicio.
Ataque volumétrico	Media	Parcialmente	Filtrado en el operador de tránsito, y en concreto un proveedor que filtra en lugar de aplicarle null-routing para protegerse a sí mismo.
Un intruso dirigido	Baja	No	Segmentación, mínimo privilegio, datos cifrados en reposo, y registros en un lugar donde el intruso no pueda modificarlos.
Un actor estatal	Muy baja	Parcialmente	La jurisdicción determina la vía legal, no la técnica. Si esto forma realmente parte de su modelo, busque asesoramiento en lugar de un plan de alojamiento.

A cuáles afecta una decisión de alojamiento

Dos de siete, y parcialmente un tercero. Esa proporción es, por sí sola, el resultado más útil del ejercicio, y por eso hacerlo antes de elegir un proveedor ahorra más dinero que cualquier tabla comparativa.

La versión de una hora

1. Enumere lo que realmente posee (10 min). No sistemas — datos. Direcciones de correo de los usuarios, registros de pago, mensajes privados, archivos subidos, credenciales de otros servicios. Anote qué sería peor perder y qué sería peor filtrar; casi nunca es lo mismo.
2. Enumere quién querría cada cosa (10 min). Sea concreto. «Hackers» no es un adversario; «alguien que compra volcados de credenciales para revender cuentas» sí lo es, e implica defensas distintas.
3. Ordénelos por probabilidad × coste (10 min). Ignore lo dramático que suene cada uno. Los anodinos dominan.
4. Para los tres primeros, escriba la primera hora (20 min). Qué haría en los primeros sesenta minutos de cada uno. Si no puede responder, ese es el hallazgo — y vale más que la propia clasificación.
5. Marque cuáles se ven afectados por las decisiones de infraestructura (10 min). Normalmente, dos de los cinco primeros. Ahora ya sabe qué le está comprando realmente su decisión de alojamiento.

Repítalo cuando cambie algo estructural — un nuevo tipo de dato, una nueva integración, alguien que se marcha — en lugar de hacerlo según un calendario. Las revisiones programadas por calendario se acaban saltando; las impulsadas por eventos se hacen, porque tiene un motivo concreto delante.

Tres errores que inutilizan todo el ejercicio

Modelar al adversario que le resulta interesante. Pensar en la capacidad de un Estado-nación es más divertido que pensar en un token de API filtrado en un repositorio público. Una de las dos cosas le ha pasado a casi todo el mundo que conoce. Ordénelos con honestidad y ganan los elementos aburridos, que es precisamente el objetivo.

Confundir un control con un resultado. «Usamos cifrado» no es una mitigación hasta que pueda decir qué impide y qué no. El cifrado de disco completo en un servidor en funcionamiento protege frente a que un disco salga del edificio; no hace nada frente a un intruso con una shell en la máquina en marcha, porque el volumen ya está desbloqueado.

Producir un documento en lugar de una decisión. Si nada cambió tras el ejercicio — ningún permiso revocado, ninguna copia de seguridad probada, ninguna pregunta planteada al proveedor —, no fue un modelado de amenazas, fue una tarde. El resultado debería ser tres acciones, cada una con un nombre asignado.

Si la fila del denunciante es la que domina su tabla, la siguiente pregunta es qué jurisdicción elegir y cómo verificar lo que un proveedor afirma sobre ella — seis preguntas, respondibles en una tarde. Si ni siquiera aparece entre sus cinco primeros, probablemente no nos necesita, y ese es un resultado perfectamente bueno para una hora de trabajo.

Escrito por los ingenieros que dirigen la plataforma, y revisado de nuevo hace 1 mes. Si algo aquí es incorrecto o ha quedado desactualizado, dígalo desde el panel — de ahí proviene más o menos la mitad de esto.