En agosto de 2026, más de 150 organizaciones —Anthropic, Microsoft, Google, AWS, Cisco, bancos, gobiernos y empresas de ciberseguridad de todo el mundo, incluido nuestro propio equipo en Faraday — firmado una carta abierta impulsada por OpenAI con un mensaje incómodo pero necesario: la seguridad "status quo" ya no alcanzaEl texto es explícito sobre dónde está el problema real:
“Los errores de larga data, los permisos excesivos, las malas configuraciones, el software inseguro y sin parches, la autenticación débil y la deuda técnica en los sistemas heredados han dejado a los sistemas expuestos.”
No es un problema de falta de herramientas nuevas. Es deuda técnica acumulada durante años que nadie priorizó. Esta guía te da un método concreto para auditarla y empezar a pagarla.
Por qué esto no es "otro checklist de seguridad"
La mayoría de los checklists de seguridad fallan porque tratan todos los hallazgos como igual de urgentes. El objetivo acá es lo opuesto: priorizar sin piedad, porque los equipos de seguridad —según la misma carta— están históricamente subdimensionados. No vas a arreglar todo. Vas a arreglar lo que más importa, en el orden correcto.
Paso 1: Inventario de superficie real (no la que creés tener)
Antes de auditar nada, debes saber qué existe realmente:
- Activos:servidores, contenedores, funciones serverless, dispositivos IoT/OT si corresponde.
- Identidades:usuarios humanos, cuentas de servicio, claves de API, tokens de CI/CD y ahora también Identidades de agentes de IA (más sobre esto en la publicación sobre trazabilidad de la identidad de agentes).
- Software de terceros: dependencias directas e indirectas (SBOM si lo tenés; si no, este es el momento de generarlo).
Herramientas útiles: osquery para el inventario en tiempo real, los escáneres de SBOM como Syft, y tu CMDB si existe (aunque probablemente esté desactualizada; asume que lo está).
Paso 2: Las cinco categorías de deuda, en orden de impacto
La carta nombra cinco categorías explícitas. Auditalas en este orden porque reflejan explotabilidad real observada en incidentes:
- Autenticación débil — MFA no aplicada, contraseñas sin rotación forzada, tokens de larga duración nunca revisados.
- Permisos excesivos — cuentas de servicio con roles de administrador “porque era más fácil”, políticas de IAM wildcards (
*:*). - Software sin parches — CVEs conocidos con exploit público (known exploited vulnerabilities de CISA es tu primera fuente).
- Errores de configuración — buckets S3 públicos, puertos de gestión expuestos, logging deshabilitado.
- Deuda técnica de sistemas heredados — sistemas que no se pueden parchear sin downtime (este caso se trata en profundidad en el post de compensating controls).
Paso 3: Scoring de riesgo (plantilla)
Para cada hallazgo, calculá un score simple de 3 factores (1-5 cada uno):
| Factorizar | Pregunta |
|---|---|
| Exposición | ¿Es accesible desde internet o requiere acceso interno? |
| Explotabilidad | ¿Hay exploit público / se explota en el mundo real hoy? |
| Impacto | ¿Qué tan crítico es el activo (producción, datos sensibles, infraestructura esencial)? |
Score = Exposición × Explotabilidad × Impacto (rango 1-125). Todo lo que supere 60 entra en la cola de "arreglar esta semana, no este trimestre".
Paso 4: Verificación, no solo remediación
Un punto que la carta enfatiza y que muchos equipos omiten: “verificar los resultados sin interrumpir los servicios esenciales.” Aplicar el parche o cambiar el permiso no es suficiente; debes confirmar que la solución realmente funcionó y no rompió nada:
- Nuevo escaneo automatizado posterior a la corrección (mismo escáner, mismo alcance).
- Prueba funcional del servicio afectado antes de cerrar el ticket.
- Registro de antes y después para futuras auditorías.
Paso 5: Conviértalo en un proceso, no en una auditoría única
Una auditoría única es un parche cosmético. Lo que pide la carta es tratar esto “con la urgencia y la coordinación de un incidente”. Eso significa:
- La auditoría de 5 categorías que se ejecuta en CI/CD o como un trabajo recurrente (semanal, no anual).
- Un propietario de negocio (no solo de seguridad) para cada sistema heredado que no se pueda actualizar.
- Informes sobre la “deuda pendiente” con el mismo nivel de visibilidad ejecutiva que un incidente activo.
Lista de verificación rápida para empezar hoy
- ☐ Generar/actualizar un inventario de activos e identidades (incluidos los agentes de IA)
- ☐ Ejecutar un escáner contra CVEs explotados conocidos (CISA KEV)
- ☐ Auditar las políticas de IAM en busca de comodines y permisos de administrador innecesarios
- ☐ Confirmar MFA aplicado en el 100% de cuentas privilegiadas
- ☐ Califica los resultados y clasifica por orden de prioridad los 20% con mayor puntuación
- ☐ Scorear los hallazgos y priorizar top 20% por score
- ☐ Programar la próxima auditoría (no esperar a la siguiente incidencia para acordarte)
Parte de una serie sobre cómo poner en práctica los principios de Carta abierta de OpenAI sobre la defensa cibernética colectiva (Agosto de 2026). Volver a la guía completa.
