La brecha de 26M de registros de Conduent: por qué los seguros necesitan desarrollo de software con ciberseguridad como prioridad

La confirmación de Conduent de que 26 millones de registros fueron expuestos en su brecha de datos de enero de 2026 — incluyendo datos personales de asegurados, información de siniestros y registros de pagos de múltiples clientes aseguradores — es más que un incidente de ciberseguridad. Es una acusación estructural de cómo la industria aseguradora aborda el desarrollo de software. Cuando una sola brecha de un proveedor expone datos sensibles de docenas de aseguradoras, la pregunta pasa de "quién fue hackeado" a por qué los seguros necesitan el desarrollo de software con ciberseguridad como prioridad como principio fundamental.

La brecha, que explotó una vulnerabilidad conocida en la infraestructura heredada de procesamiento de siniestros de Conduent, se estima que costará más de $500 millones en remediación, multas regulatorias, litigios y pérdida de clientes. Para la industria aseguradora, es un toque de atención que se venía gestando desde hace décadas.

Anatomía de la brecha de Conduent

Entender lo que sucedió en Conduent ilumina las vulnerabilidades sistémicas que impregnan la infraestructura tecnológica de seguros.

Qué fue comprometido

Conduent actúa como administrador externo (TPA) y proveedor de externalización de procesos de negocio para docenas de aseguradoras estadounidenses. Sus sistemas procesan siniestros, gestionan comunicaciones con asegurados y manejan desembolsos de pagos. La brecha expuso:

• Datos personales de asegurados — nombres, direcciones, números de Seguro Social, fechas de nacimiento
• Datos de siniestros — historiales médicos, detalles de lesiones, importes de liquidación
• Información de pagos — números de cuentas bancarias, historiales de pagos

Los 26 millones de registros afectados abarcan líneas de seguros de salud, compensación laboral, discapacidad y propiedad.

Cómo ocurrió

El análisis forense preliminar apunta a una vulnerabilidad en una aplicación heredada de procesamiento de siniestros que no había sido parcheada a pesar de un aviso del proveedor emitido cuatro meses antes. La aplicación, construida sobre una arquitectura de décadas de antigüedad, carecía de controles de seguridad modernos: ninguna segmentación de red la aislaba de otros sistemas, los endpoints de API usaban autenticación básica sin limitación de tasa, y los datos en reposo estaban parcialmente sin cifrar. El atacante obtuvo acceso inicial a través de la vulnerabilidad no parcheada, se movió lateralmente a través de la red interna de Conduent y exfiltró datos durante un período de aproximadamente seis semanas antes de la detección.

El coste estimado

Basándose en brechas comparables y tendencias actuales de enforcement regulatorio, SectorPunk estima costes totales superiores a $500 millones:

• Remediación directa — $80-120M para investigación forense, reconstrucción de sistemas y monitorización de crédito
• Multas regulatorias — $100-200M de HHS/OCR por violaciones de HIPAA, reguladores estatales de seguros y posible acción de la FTC
• Litigios — $150-250M en acuerdos de acciones colectivas y demandas individuales
• Pérdida de clientes — varias aseguradoras ya han comenzado a migrar desde Conduent, representando $50-100M+ en ingresos anuales perdidos

Por qué los seguros son particularmente vulnerables a las brechas de ciberseguridad

La brecha de Conduent es sintomática de problemas estructurales más profundos en la tecnología de seguros. La vulnerabilidad de la industria no es accidental — es la consecuencia predecible de décadas de subinversión en tecnología core.

El problema de los sistemas heredados

La aseguradora grande promedio opera más de 15 sistemas core, muchos que datan de los años 80 y 90. Las aplicaciones COBOL que corren en mainframes IBM procesan miles de millones de dólares en primas y siniestros anualmente. Los sistemas AS/400 gestionan la administración de pólizas para millones de asegurados. Estos sistemas fueron diseñados en una era anterior a la conectividad por internet, la integración basada en APIs y las ciberamenazas sofisticadas.

Las implicaciones de seguridad son profundas:

• Los sistemas heredados típicamente carecen de mecanismos de autenticación modernos — son anteriores a OAuth, la autenticación multifactor y la autenticación basada en certificados
• Se comunican mediante protocolos que nunca fueron diseñados con la seguridad en mente — transferencias de archivos planos, procesamiento batch sin cifrar, formatos de mensajería propietarios
• Su código base ha evolucionado durante décadas a través de miles de modificaciones por desarrolladores que hace tiempo que se fueron, haciendo que la auditoría de seguridad sea efectivamente imposible sin herramientas especializadas y un profundo conocimiento institucional

La trampa del mantenimiento

Entre el 60% y el 70% de los presupuestos de TI de las aseguradoras se destinan a mantener los sistemas existentes en lugar de construir nuevos. Esta carga de mantenimiento crea un círculo vicioso: los parches de seguridad compiten con las solicitudes de funcionalidades y los cambios regulatorios por los escasos recursos de desarrollo, lo que significa que las vulnerabilidades conocidas a menudo quedan sin parchear durante meses o años. La vulnerabilidad no parcheada de Conduent no es un caso aislado — es la norma de la industria.

La cadena de proveedores externos

Las operaciones de seguros modernas dependen de extensas cadenas de proveedores. Un solo siniestro puede pasar por un TPA (Conduent), un proveedor de revisión de facturas médicas, un servicio de detección de fraude, un procesador de pagos y un sistema de gestión documental — cada uno representando una superficie de ataque potencial. La brecha de Conduent demuestra que la postura de seguridad de una aseguradora es tan fuerte como su eslabón más débil en la cadena de proveedores. La mayoría de las aseguradoras carecen de visibilidad sobre las prácticas de seguridad de sus proveedores más allá de informes SOC 2 anuales, que proporcionan una instantánea puntual en lugar de una garantía continua.

Qué significa el desarrollo de software con ciberseguridad como prioridad

El desarrollo de software con ciberseguridad como prioridad no consiste en añadir pruebas de seguridad al final del ciclo de desarrollo. Es una reorientación fundamental de cómo se diseña, construye, despliega y opera el software de seguros.

Modelado de amenazas desde el día uno

Cada proyecto de desarrollo debería comenzar con el modelado de amenazas — identificar sistemáticamente vectores de ataque potenciales, riesgos de exposición de datos y requisitos de seguridad antes de escribir una sola línea de código. Para las aplicaciones de seguros, el modelado de amenazas debe considerar los riesgos específicos de los datos que se procesan: datos personales de asegurados, información de salud protegida (PHI bajo HIPAA), datos financieros (alcance de PCI DSS) y datos de siniestros que podrían usarse para fraude. El modelo de amenazas informa las decisiones arquitectónicas, los requisitos de autenticación, las estrategias de cifrado y las necesidades de monitorización.

Arquitectura de confianza cero

La arquitectura de confianza cero asume que ninguna red, usuario o componente del sistema es inherentemente confiable. Para los sistemas de seguros, esto significa:

• Microsegmentación entre componentes de la aplicación para prevenir el movimiento lateral

• TLS mutuo para toda la comunicación servicio a servicio

• Provisión de acceso justo a tiempo para funciones administrativas

• Verificación continua de los niveles de confianza de dispositivos y usuarios

La confianza cero aborda directamente el problema de movimiento lateral que habilitó la brecha de Conduent — incluso si un atacante compromete un componente, no puede moverse libremente a otros.

Cifrado en cada capa

El desarrollo con ciberseguridad como prioridad exige cifrado en reposo (AES-256 para datos almacenados), en tránsito (TLS 1.3 para toda comunicación de red) y en uso (donde sea factible, utilizando técnicas como cifrado homomórfico o enclaves seguros para cómputos sensibles). Para datos de seguros, el cifrado a nivel de campo proporciona una capa adicional de protección: incluso si un atacante accede a una base de datos, los campos sensibles individuales (SSN, historiales médicos, cuentas bancarias) permanecen cifrados con claves separadas.

Gateways de API seguros

Los sistemas de seguros se comunican cada vez más a través de APIs, convirtiendo la superficie API en un vector de ataque principal. Los gateways de API seguros proporcionan:

• Aplicación de autenticación — OAuth 2.0 con validación de JWT

• Limitación de tasa y throttling — prevención de ataques de fuerza bruta y enumeración

• Validación de solicitudes — validación de esquema, verificación de tipo de contenido, sanitización de entrada

• Detección de amenazas específicas de API — identificación de patrones de acceso inusuales, intentos de exfiltración de datos y credential stuffing

Seguridad en los pipelines de CI/CD

El desarrollo con ciberseguridad como prioridad integra pruebas de seguridad a lo largo del pipeline de CI/CD:

• SAST (Pruebas estáticas de seguridad de aplicaciones) — analiza el código fuente en busca de vulnerabilidades durante la compilación

• DAST (Pruebas dinámicas de seguridad de aplicaciones) — prueba las aplicaciones en ejecución en busca de fallos explotables

• SCA (Análisis de composición de software) — identifica dependencias vulnerables

• Escaneo de contenedores — verifica las imágenes de ejecución en busca de CVEs conocidos

Cada punto de verificación bloquea el despliegue de código que no supere los umbrales de seguridad, asegurando que las vulnerabilidades se detecten antes de producción.

Cumplimiento de DORA y el imperativo regulatorio

La Ley de Resiliencia Operativa Digital (DORA) de la UE, vigente desde enero de 2025, crea requisitos vinculantes para la gestión de riesgos TIC en servicios financieros, incluidos los seguros. El cumplimiento de DORA es ahora un prerrequisito para operar en mercados europeos, y sus requisitos se alinean directamente con los principios de desarrollo con ciberseguridad como prioridad.

• Gestión de riesgos TIC: Marco integral para identificar, proteger, detectar, responder y recuperarse de riesgos TIC
• Notificación de incidentes: Notificación obligatoria de incidentes TIC significativos a los reguladores dentro de plazos definidos
• Pruebas de resiliencia operativa digital: Pruebas regulares incluyendo pruebas de penetración guiadas por amenazas (TLPT) para entidades sistémicamente importantes
• Gestión de riesgos de terceros: Supervisión y gestión de proveedores de servicios TIC externos, incluyendo requisitos contractuales para controles de seguridad
• Intercambio de información: Participación en el intercambio de inteligencia sobre amenazas entre entidades financieras

Para las empresas de desarrollo de software que sirven a aseguradoras, DORA crea tanto una obligación como una oportunidad. Los socios de desarrollo deben demostrar prácticas conformes con DORA en sus propias operaciones, y pueden diferenciarse ayudando a las aseguradoras a lograr y mantener el cumplimiento de DORA en los sistemas que construyen.

Cómo evaluar socios de desarrollo por madurez en seguridad

Las aseguradoras que seleccionan socios de desarrollo de software deben evaluar la madurez en seguridad en varias dimensiones.

Postura de seguridad organizacional

Evaluar las propias certificaciones de seguridad del socio de desarrollo (ISO 27001, SOC 2 Type II), historial de incidentes de seguridad, programas de formación en seguridad para empleados y prácticas de contratación enfocadas en seguridad. Un socio de desarrollo que no mantiene una seguridad interna rigurosa no puede ser confiable para construir sistemas seguros para los clientes.

Prácticas de seguridad en el desarrollo

Evaluar el ciclo de vida de desarrollo seguro del socio: metodología de modelado de amenazas, procesos de revisión de código (incluyendo revisión enfocada en seguridad), integración de pruebas de seguridad automatizadas, prácticas de gestión de dependencias y procedimientos de respuesta a incidentes. Solicitar evidencias de estas prácticas — documentos de política de seguridad, modelos de amenazas de ejemplo, configuraciones del pipeline de CI/CD — en lugar de aceptar autocertificaciones.

Experiencia en seguridad específica del dominio de seguros

La experiencia general en ciberseguridad es necesaria pero insuficiente. Los socios de desarrollo deben entender los requisitos de seguridad específicos de seguros: HIPAA para datos de seguros de salud, leyes estatales de privacidad, requisitos del modelo de ley de ciberseguridad de la NAIC, y el panorama de amenazas específico que enfrenta la industria aseguradora (ataques dirigidos contra datos de siniestros, suplantación de identidad de asegurados, inyección de siniestros fraudulentos). Solicitar casos de estudio de implementaciones de seguridad en seguros y referencias de CISOs de aseguradoras.

El caso de negocio para sistemas modernos y seguros

La brecha de Conduent plantea el caso de negocio para el desarrollo de software con ciberseguridad como prioridad en términos financieros contundentes. El coste estimado de más de $500 millones de la brecha supera lo que habría costado un programa de modernización integral. En términos más amplios, las pérdidas anuales de ciberseguridad de la industria aseguradora — por brechas, fraude habilitado por sistemas débiles y multas regulatorias — superan los $10.000 millones a nivel global. Invertir en desarrollo con ciberseguridad como prioridad no es un centro de costes; es la estrategia de gestión de riesgos más efectiva disponible.

Para las aseguradoras que evalúan su estrategia tecnológica, el camino a seguir es claro. Los sistemas heredados deben modernizarse o reemplazarse con arquitecturas diseñadas para el panorama de amenazas moderno. Los proveedores externos deben cumplir requisitos de seguridad estrictos con validación continua. Los socios de desarrollo deben demostrar una madurez en seguridad acorde a la sensibilidad de los datos de seguros. Las mejores empresas de desarrollo de software de seguros son aquellas que han convertido la ciberseguridad en una competencia core, no en algo secundario.

La brecha de Conduent no será el último gran incidente de ciberseguridad en seguros. Pero debería ser el último que encuentre a la industria desprevenida. El desarrollo de software con ciberseguridad como prioridad ya no es una buena práctica — es el estándar mínimo para una tecnología de seguros responsable.

Publicado el 27 de febrero de 2026 · SectorPunk Research