La carta abierta sobre la ciberdefensa colectiva sitúa el intercambio de información en el centro de su propuesta, tanto para las empresas de ciberseguridad como para los gobiernos y las empresas de inteligencia artificial de frontera:
“Compartir inteligencia de amenazas y manuales probados... compartir herramientas, manuales y evaluaciones de amenazas creíbles con gobiernos, socios de seguridad y mantenedores de código abierto.”
La objeción más común que escuchamos de los equipos de seguridad cuando se les pide que se unan a un ISAC (Centro de Análisis e Intercambio de Información) o mecanismo similar es: “No podemos compartir nuestra telemetría, contiene datos sensibles.” Es una preocupación legítima, pero no es una razón válida para dejar de participar. Es una razón para diseñar adecuadamente el proceso de anonimización antes de compartir. Esta guía trata sobre ese proceso.
Lo que se comparte y lo que nunca se comparte
Antes del “cómo”, define el “qué”. Estas categorías casi nunca deben salir de tu organización, ni siquiera anonimizadas:
- Datos personales pertenecientes a clientes o empleados.
- Información comercial confidencial (contratos, precios, hoja de ruta).
- Detalles que permitirían identificar sistemas específicos por su configuración exacta (versiones de software interno muy específicas, nombres de host reales).
Qué es verdaderamente valioso compartir y en qué se centra esta guía:
- Indicadores de compromisohashes de malware, IPs y dominios maliciosos, patrones de C2.
- Tácticas, técnicas y procedimientos (TTP) observado, mapeado a MITRE ATT&CK.
- patrones de ataques asistidos por IA (por ejemplo, phishing generado por LLM con característicasdetectables, uso de agentes maliciosos).
- Libros de jugadas de respuesta que funcionaron, sin datos identificables del incidente original.
Paso 1: Canalización de anonimización antes de compartir
Nunca compartas telemetría sin procesar. Define una tubería con al menos estas etapas:
- Extracción selectivaextraer únicamente los campos relevantes para el IOC/TTP (no todo el registro del sistema).
- Generalización de identificadoresreemplazar las IP internas, los nombres de host y los nombres de usuario con marcadores de posición consistentes
host-interno-A, no es el nombre real), preservando la estructura relacional solo si es necesaria para el análisis. - Agregación temporalen lugar de “este ataque ocurrió a las 14:32:07 del 30/8”, utilice ventanas más amplias (“tarde del 30/8”) a menos que la precisión temporal sea fundamental para las TTP.
- Revisión legal y de cumplimientoun paso obligatorio, no opcional, antes de que nada salga de la organización, especialmente en sectores regulados (finanzas, salud).
Paso 2: Formato estándar para que sea útil para otros
Compartir información en un formato ad hoc reduce su utilidad. Utilice estándares reconocidos:
- STIX/TAXII para IOCs y TTPs estructurados; este es el formato que la mayoría de los ISAC y plataformas (incluido MISP) consumen de forma nativa.
- Mapeo a MITRE ATT&CK de modo que el TTP sea comparable entre organizaciones con diferentes contextos.
- Avistamientos, no solo indicadores: si puedes, indica cuántas veces observaste el patrón y en qué contexto general (sector, tipo de sistema), no solo el indicador aislado.
Paso 3: Elija el mecanismo de compartir adecuado
No todos los mecanismos de intercambio son iguales en términos del nivel de confianza y la sensibilidad que pueden manejar:
| Mecanismo | Nivel de confianza | Qué compartir ahí |
|---|---|---|
| ISAC específico del sector | Alto (membresía verificada) | TTP detallados, libros de jugadas completos |
| Plataformas abiertas (comunidades MISP públicas) | Medio-bajo | IOC genéricos, sin contexto confidencial |
| Canales bilaterales con socios de confianza | Muy alto | Detalles específicos del incidente compartidos bajo acuerdo de confidencialidad |
| Reportar al CERT gubernamental/nacional | Alta (obligación reglamentaria en algunos sectores) | Todo lo requerido por la normativa aplicable |
Paso 4 — Recibir, no solo dar
El valor de unirse a un ISAC es bidireccional. Defina un proceso interno para consumiendo inteligencia compartida por otros:
- Ingesta automatizada de feeds STIX/TAXII en su SIEM o plataforma de inteligencia de amenazas.
- Un proceso de triaje para determinar qué IOCs/TTPs recibidos se aplican a su pila tecnológica específica (no todo se aplica a todos).
- Retroalimentación al ISAC cuando un indicador compartido por otro miembro realmente le ayudó a detectar algo: esto refuerza la confianza en el mecanismo colectivo.
Paso 5: Mide el valor de participar
Para justificar el esfuerzo internamente (tiempo del equipo legal, de ingeniería y de seguridad):
- Número de detecciones propias que se originaron a partir de IOCs recibidos a través del ISAC.
- Tiempo de investigación ahorrado gracias a las TTP ya documentadas por otros miembros.
- Comentarios recibidos sobre la utilidad de lo que compartió su organización.
Lista de verificación
- ☐ Definir las categorías de datos que nunca se comparten, sin excepciones
- ☐ Diseñar una tubería de anonimización (extracción → generalización → agregación → revisión legal)
- ☐ Adoptar el formato STIX/TAXII y el mapeo de MITRE ATT&CK
- ☐ Elija el(los) mecanismo(s) de compartición según el nivel de confianza y la sensibilidad de la información
- ☐ Automatizar la ingesta de inteligencia de amenazas externa en su SIEM
- ☐ Medir el valor bidireccional (lo que diste, lo que recibiste, lo que realmente ayudó)
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.
