Introducción
Los equipos de seguridad y DevOps invierten millones en herramientas de monitoreo, cifrado y hardening de infraestructura, pero los ataques más efectivos suelen explota fallas humanAS: ingeniería social, sesgos cognitivos y abuso de confianza. How to Steal a Galaxy, la secuela de Full Speed to a Crash Landing de Beth Revis, es una novela corta de ciencia ficción que, bajo su trama de robo en una gala interplanetaria, desmenuza técnicas de deception que cualquier red team podría envidiar.
La narrativa en primera persona de Ada Lamarr —ladrona profesional— muestra cómo manipular percepciones, explotar arrogancia y moverse sin llamar la atención en entornos de alta seguridad. Si bien el escenario es futurista, las tácticas son reconocibles: pretexting, camuflaje entre usuarios legítimos y abuso de privilegios implícitos. Para los profesionales de infraestructura y seguridad, la novela funciona como un caso de estudio informal sobre el lado humano de la seguridad.
Qué ocurrió
La trama transcurre en una gala benéfica en Rigel-Earth, organizada por Strom Fetor, un magnate tecnológico con una fortuna equivalente a un trillón de créditos. Ada Lamarr es contratada para infiltrarse y robar un objeto no especificado (revelado recién al final). Rian White, agente gubernamental encubierto como seguridad del evento, sabe que Ada estará allí y intenta frustrar su plan, pero la falta de claridad sobre su objetivo lo deja en desventaja.
El conflicto central no es tecnológico, sino psicológico. Ada exploita sistemáticamente los sesgos de Fetor: su narcisismo (asume que todos lo admiran), su desdén por los «inferiores» (no considera que una mujer en un vestido pueda ser una amenaza) y su sense of entitlement (cree que el dinero puede comprar cualquier lealtad). Estas son vulnerabilidades que, en el mundo real, han permitido brechas como el ataque a Twitter en 2020 (CVE-2020-15364), donde empleados fueron manipulados mediante ingeniería social para otorgar acceso a cuentas de alto perfil.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El valor de esta novela para los equipos técnicos radica en su ilustración de principios de seguridad no técnica que suelen pasarse por alto:
1. El factor humano como superficie de ataque
El 82% de las brechas involucran un componente humano, según el Verizon DBIR 2023. Ada demuestra cómo un atacante paciente puede recopilar información contextual (nombres de empleados, jerarquías, costumbres) para craftear un pretexto creíble. En entornos cloud, esto se traduce en ataques como cloud account takeover mediante phishing dirigido a administradores con acceso a IAM.
2. Privilegio excessivo y abuso de confianza
Fetor otorga acceso físico y lógico a su círculo interno basándose en estatus social, no en principio de mínimo privilegio. En infraestructura, esto équivale a cuentas de servicio con permisos wildcard (ej: * en AWS IAM) o usuarios con sudo sin restricciones. El Capital One breach (2019) fue posible porque una cuenta de service Had permisos excesivos para acceder a buckets S3.
3. Detección basada en comportamientos anómalos
Rian, el «defensor», falla porque busca amenazas obvias (armas, movimiento sospechoso) y no analiza patrones de interacción. En seguridad moderna, esto subraya la importancia de User and Entity Behavior Analytics (UEBA): herramientas como Elastic SIEM o Splunk pueden detectar anomalies como un usuario que accede a recursos fuera de su horario habitual o una secuencia inusual de comandos.
Detalles técnicos
Aunque la novela no describe tecnologías específicas, sus estrategias de deception tienen paralelos directos con técnicas reales:
- Pretexting: Ada usa identidades falsas (ej: «una socialite desinteresada») para ganarse la confianza. En el mundo real, los atacantes impostan a IT support (como en el Mimecast breach de 2021) o a колеgas para solicitar credenciales.
- Camuflaje en el ruido: Ada realiza acciones maliciosas durante momentos de alta actividad (ej: subastas, discursos), cuando el comportamiento anómalo se mezcla con el tráfico legítimo. Esto es similar a living off the land (LotL), donde se usan herramientas legítimas (como PowerShell o kubectl) para actividades maliciosas.
- Explotación de sesgos cognitivos:
– Authority bias: Fetor asume que Ada no es una amenaza porque es una invitada.
– Halo effect: su atractivo físico hace que otros subestimen su capacidad técnica.
– Confirmation bias: Rian descarta pistas que contradicen su suposición de que Ada busca robar un objeto valioso (como una joya).
En entornos cloud, estas tácticas se adaptan a:
- Phishing para credenciales cloud: Mensajes que imitan notificaciones de AWS/Azure/GCP (ej: «Su cuenta será suspendida») para robar tokens de autenticación.
- Shadow IT: Empleados que usan servicios no autorizados (como Dropbox para almacenar backups) y se convierten en vectores de entrada.
- Abuso de OAuth: Aplicaciones maliciosas que solicitan permisos excesivos a usuarios (ej: Google OAuth phishing usado en campañas contra criptomoneda en 2022).
Qué deberían hacer los administradores y equipos técnicos
- Capacitación en ingeniería social:
– Realizar simulaciones de phishing con herramientas como GoPhish o KnowBe4. Medir no solo la tasa de clics, sino el tiempo de reporte por parte de los empleados.
– Incluir ejemplos específicos del entorno: si usan Slack, simular mensajes de «IT support» pidiendo credenciales via DM.
- Implementar mínimo privilegio:
– Auditar permisos en IAM (AWS/GCP/Azure) con herramientas como CloudTrail, Access Advisor (AWS) o Recommender (GCP). Eliminar roles y políticas no usados.
– Para Kubernetes, usar Role Based Access Control (RBAC) y herramientas como Open Policy Agent (OPA) para enforcement.
– En sistemas Linux, evitar sudo sin restricciones; usar visudo para definir comandos específicos por usuario.
- Monitoreo de comportamientos anómalos:
– Configurar alertas en SIEM para:
– Accesos desde ubicaciones geográficas inusuales.
– Uso de commands como aws sts assume-role fuera de horarios habituales.
– Cambios en configuración de infraestructura (ej: modificaciones en security groups o firewall rules).
– En cloud, habilitar Cloud Trail (AWS), Audit Logs (GCP) y Microsoft Defender for Cloud.
- Segmentación de red:
– Usar VPCs separados para diferentes entornos (dev/staging/prod) y restringir el tráfico entre ellos con security groups y NACLs.
– En Kubernetes, aislar namespaces con Network Policies.
- Procesos para cambios sensibles:
– Requerir approval de dos personas para acciones como:
– Modificación de DNS (evita domain hijacking).
– Cambios en políticas de IAM.
– Despliegues a producción.
– Usar herramientas como Terraform con approve workflows o GitHub Actions con required reviewers.
Conclusión
How to Steal a Galaxy es una lectura entretenida que, más allá de su valor como ciencia ficción, ofrece un recordatorio poderoso: la seguridad no depende solo de firewalls y cifrado, sino de entender cómo los atacantes piensan y cómo explotar las debilidades humanAS. Para los equipos de DevOps e infraestructura, la novela es un caso de estudio informal sobre ingeniería social y deception en entornos de alta confianza.
Las lecciones son directas: reducí la superficie de ataque limitando permisos, monitoreá comportamientos no solo firmas de malware, y capacitá a tu equipo para reconocer tácticas de manipulación. Como dice Ada Lamarr: «La gente ve lo que quiere ver». En seguridad, eso puede ser la diferencia entre detectar una intrusión o convertirte en el próximo titular.
Fuentes
https://www.eyrie.org/~eagle/reviews/books/0-7564-1949-2.html