24 mil millones de credenciales expuestas están en manos de atacantes. ¿Está tu plano de control preparado?
El 15 de junio de 2026, investigadores de Cybernews revelaron la eliminación responsable de un clúster de Elasticsearch sin protección que contenía 8,3 terabytes de datos: 24 mil millones de registros de nombres de usuario y contraseñas, agregados de 36 fuentes diferentes, compuestos en su mayoría por canales de Telegram donde conjuntos de credenciales robadas circulan entre comunidades criminales. Aproximadamente 22,6 mil millones de esos registros provenían de «colecciones»: conjuntos compilados de credenciales de eventos de filtraciones históricas que los equipos de seguridad de la mayoría de las organizaciones ya han gestionado mediante rotación de contraseñas o desmantelamiento de sistemas. Sin embargo, los registros restantes provenían de una fuente completamente distinta: registros de malware infostealer que capturan credenciales extraídas activamente de entornos empresariales en funcionamiento.
Esa distinción – colección histórica frente a registros de infostealer en vivo – es la diferencia entre una amenaza de fondo y un riesgo operativo activo. Infostealers como RedLine, Lumma y Vidar extraen credenciales directamente de las máquinas donde los empleados se autentican a diario: navegadores, aplicaciones de escritorio, gestores de contraseñas y portales SaaS empresariales. Las credenciales en esos registros no provienen de una filtración de hace cinco años. Son de endpoints que actualmente están en producción, y los datos de autenticación capturados siguen siendo válidos hasta que se roten.
Para organizaciones que operan bajo requisitos de cumplimiento de la ley HIPAA, cumplimiento CMMC 2.0, autorización FedRAMP o marcos regulatorios comparables, el cálculo es directo y contundente. Una plantilla de varios miles de empleados tendrá, con casi total certeza estadística, alguna fracción de sus credenciales presente en un agregado de 24 mil millones de registros. La pregunta que los responsables de cumplimiento y los equipos de seguridad deben hacerse no es si esas credenciales existen en la base de datos. Es: ¿qué puede lograr un atacante si las utiliza con éxito, y tu arquitectura actual limita ese resultado?
Este artículo responde directamente a esa pregunta: cómo funciona la exposición de credenciales impulsada por infostealers, por qué las industrias reguladas enfrentan consecuencias asimétricas y qué debe hacer un plano de control de Kiteworks para el intercambio seguro de datos que una defensa perimetral no puede lograr.
Puntos Clave
1. Los registros derivados de infostealers son la amenaza accionable, no las colecciones históricas
La mayoría de los 24 mil millones de registros son datos reciclados de filtraciones históricas. Los registros de infostealer son distintos: esas credenciales se extrajeron de máquinas empresariales activas y pueden seguir siendo válidas, convirtiéndose en el subconjunto accionable que los atacantes priorizan.
2. Las industrias reguladas asumen una responsabilidad asimétrica por cada inicio de sesión exitoso
Un solo caso de apropiación de cuenta que acceda a información de salud protegida, información no clasificada controlada o datos financieros regulados activa la notificación obligatoria de la filtración y expone a la organización a sanciones, sin importar cuántos datos se hayan accedido.
3. La seguridad basada en contraseñas ya ha fallado ante la magnitud de 24 mil millones de registros
La suposición de que los controles de contraseña protegen adecuadamente los datos empresariales ya no es defendible. La autenticación multifactor, los controles de acceso basados en atributos y el registro de auditoría continuo no son capas opcionales: son el mínimo requerido para entornos que manejan datos sensibles.
4. El plano de control para el intercambio seguro de datos es la última defensa significativa tras el robo de credenciales
Los atacantes que se autentican con credenciales robadas apuntan a portales de transferencia de archivos, plataformas de correo electrónico seguro y entornos de colaboración donde realmente reside la información sensible. Un plano de control unificado – un motor de políticas, un registro de auditoría, una postura de seguridad en todos los canales – es lo que limita lo que pueden alcanzar y lo que queda registrado.
5. El riesgo de credential stuffing debe estar en los registros de riesgos de cumplimiento y en los informes a la junta directiva
La combinación del agregado de 24 mil millones de registros, campañas activas de infostealer y el enfoque de cumplimiento en salud, defensa y servicios financieros significa que la apropiación de cuentas basada en credenciales ya no es solo una preocupación técnica: es una prioridad de gobernanza.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Leer ahora
Las dos poblaciones en ese conteo de 24 mil millones de registros
Los profesionales de seguridad que descartan grandes agregados de credenciales como «noticias viejas» no están del todo equivocados – al menos en lo que respecta a la parte de colecciones. La mayoría de los 24 mil millones de registros identificados por Cybernews provienen de conjuntos de datos de filtraciones compilados que llevan años circulando por mercados clandestinos. Muchas de esas credenciales ya se han rotado. Muchos de los sistemas a los que daban acceso ya no existen. Los equipos de seguridad que aplican una higiene de contraseñas constante, monitorean servicios de notificación de filtraciones y exigen la rotación periódica de credenciales probablemente ya han gestionado buena parte de esa exposición.
Los registros derivados de infostealers representan un problema fundamentalmente distinto.
Los infostealers son una categoría de malware diseñada específicamente para extraer datos de autenticación de las máquinas que infectan. Funcionan leyendo contraseñas guardadas en el almacenamiento del navegador, extrayendo cookies de sesión que permiten autenticación sin contraseña, capturando pulsaciones de teclado en los campos de inicio de sesión y recolectando credenciales de gestores de contraseñas de escritorio. El resultado – un «registro» estructurado con nombres de usuario, contraseñas y tokens de sesión organizados por sitio y aplicación – se empaqueta y vende en mercados clandestinos, normalmente en cuestión de horas o días tras la infección original.
Las implicaciones para los entornos empresariales son directas. Un empleado cuya máquina es infectada por un infostealer, en la práctica, ha entregado toda su huella de autenticación a un atacante. Cada aplicación empresarial a la que accede, cada portal de uso compartido de archivos al que inicia sesión, cada plataforma de correo electrónico seguro que utiliza – todo eso está en el registro. La empresa no tiene visibilidad de esto hasta que el dispositivo del empleado dispara una alerta de detección de endpoint o el atacante intenta usar las credenciales robadas.
Lo que hace que la campaña FortiBleed revelada la misma semana – en la que se agregaron y publicaron 86.000 credenciales confirmadas de dispositivos FortiGate en 194 países – sea un dato relevante es que utilizó inteligencia artificial para identificar objetivos y automatizar ataques de password spraying, ampliando y validando ese conjunto de credenciales. La combinación de grandes agregados de credenciales y validación asistida por IA está acelerando la conversión de credenciales robadas en accesos funcionales confirmados. Las organizaciones que no aplican MFA de forma consistente en todas las aplicaciones empresariales están operando frente a esta realidad sin controles suficientes.
Por qué las industrias reguladas enfrentan un cálculo diferente
Toda organización enfrenta riesgo por credential stuffing. Pero las que están sujetas a HIPAA, CMMC, FedRAMP, ITAR u otros marcos similares enfrentan un perfil de riesgo cualitativamente diferente porque la consecuencia de un solo evento de autenticación exitoso depende completamente de a qué puede acceder la cuenta comprometida – y qué obligaciones de reporte activa ese acceso.
Bajo los requisitos de cumplimiento de la ley HIPAA, el acceso no autorizado a información de salud protegida activa obligaciones de notificación de filtración, incluso si el atacante no extrajo ningún dato. Si las credenciales de un empleado se usan para iniciar sesión en un sistema de información de salud y la sesión accede a PHI – incluso solo al visualizarla – eso es una filtración reportable bajo la Regla de Notificación de Filtraciones de HIPAA. La entidad cubierta debe notificar a los individuos afectados, al Departamento de Salud y Servicios Humanos y, en incidentes que involucren a 500 o más personas, a medios de comunicación destacados en los estados afectados. El costo de esa notificación e investigación posterior puede superar por mucho cualquier inversión en firewall o protección de endpoint.
Bajo los requisitos de cumplimiento de CMMC 2.0, una cuenta comprometida que accede a información no clasificada controlada (CUI) activa requisitos de reporte de incidentes bajo DFARS 252.204-7012 dentro de las 72 horas posteriores al descubrimiento. También puede activar una reevaluación del estatus de certificación CMMC de la organización. Los contratistas de defensa que sufren una filtración de CUI por compromiso de credenciales enfrentan no solo el costo de la respuesta al incidente, sino también el riesgo de perder o ver suspendida la certificación CMMC que les permite competir por contratos del DoD.
El cumplimiento FedRAMP crea obligaciones similares para proveedores de servicios en la nube y agencias federales, donde cualquier acceso no autorizado a datos federales requiere reporte inmediato del incidente a la agencia correspondiente y a CISA.
La asimetría es clara: una credencial comprometida en una empresa minorista puede resultar en responsabilidad por fraude. La misma credencial en un proveedor de salud, contratista de defensa o agencia federal activa reportes obligatorios al gobierno, posibles acciones regulatorias y consecuencias de certificación que superan con creces el costo del incidente en sí. Las organizaciones que no han mapeado explícitamente los escenarios de apropiación de cuentas basada en credenciales en sus evaluaciones de riesgos para cada marco aplicable operan con una brecha no reconocida.
El manual de credential stuffing contra plataformas de contenido
Entender cómo los atacantes usan grandes bases de datos de credenciales contra plataformas de contenido empresarial aclara por qué la arquitectura defensiva importa tanto como la capa de autenticación.
Los ataques de credential stuffing siguen una secuencia predecible. Un atacante adquiere un conjunto de credenciales – de un agregado como el documentado por Cybernews, de registros de infostealer comprados o de phishing dirigido – y comienza pruebas automatizadas contra las plataformas objetivo. Las herramientas modernas de credential stuffing pueden probar decenas de miles de pares de credenciales por minuto contra una aplicación web, rotando direcciones IP y agentes de usuario para evitar limitaciones de tasa y detección. Cuando un par tiene éxito, la herramienta registra el acceso confirmado y lo pone en cola para seguimiento manual o automatizado.
El paso de seguimiento es donde las plataformas de contenido se convierten en objetivo. Un atacante que ha confirmado acceso funcional a una cuenta empresarial no exfiltra todo de inmediato – eso activaría detección basada en volumen. Establece un patrón de acceso que imita el comportamiento normal del usuario. Puede permanecer inactivo durante días o semanas antes de buscar archivos valiosos. Puede usar el acceso para pivotar a otras cuentas accediendo a directorios internos o plataformas de comunicación donde se comparten credenciales o tokens de sesión. Cuando actúa, apunta a documentos – contratos, registros financieros, planos técnicos, historiales médicos, datos regulados – que puede monetizar directamente o usar para extorsión. Los controles de clasificación de datos que etiquetan y restringen el acceso a contenido sensible según su nivel de sensibilidad son una contramedida directa a este comportamiento de ataque.
El ataque a la cadena de suministro de Klue revelado en este mismo ciclo de noticias – en el que los atacantes usaron tokens OAuth comprometidos para acceder a entornos de Salesforce pertenecientes a LastPass, HackerOne, Huntress, Jamf, OneTrust, Recorded Future, Snyk, Tanium y otros – siguió exactamente este patrón. El mecanismo de credenciales fue diferente (tokens OAuth en vez de contraseñas), pero el objetivo era el mismo: acceso autenticado a repositorios de documentos y datos empresariales a escala. Las implicaciones para la gestión de riesgos de la cadena de suministro son significativas: el acceso de terceros a entornos empresariales crea vectores de exposición de credenciales que los programas internos de higiene no pueden cerrar por sí solos.
Para organizaciones que usan transferencia segura de archivos administrada, correo electrónico seguro, SFTP o plataformas colaborativas de contenido, la amenaza de credential stuffing es directa. Estas son precisamente las aplicaciones donde viven los datos regulados sensibles, y son exactamente las aplicaciones donde las credenciales de los empleados se almacenan en navegadores y son recolectadas por infostealers.
Por qué la capa de contraseñas ya está derrotada
El problema conceptual de tratar la autenticación basada en contraseñas como un control de seguridad es que asume que la contraseña permanece secreta. Ante la magnitud de 24 mil millones de credenciales expuestas – con un ecosistema activo de infostealers recolectando nuevas constantemente – esa suposición ya no es defendible operativamente para grandes plantillas.
Las políticas de rotación de contraseñas ayudan pero no cierran la brecha. Si las credenciales de un empleado son recolectadas por un infostealer y la organización tiene una política de rotación de 90 días, hay una ventana de 90 días en la que un atacante puede usar esas credenciales libremente. Si la rotación se aplica tras una alerta de servicios de notificación de filtraciones, suele haber un retraso de días o semanas entre el robo de credenciales y la conciencia de la organización. Los infostealers están diseñados para operar dentro de esa brecha.
La recolección de tokens de sesión agrava el problema. Los infostealers modernos no solo capturan contraseñas. Capturan cookies de sesión del navegador que permiten autenticación sin contraseña – eludiendo incluso MFA en algunas configuraciones, ya que el token de sesión se emitió tras un evento legítimo de MFA. El secuestro de sesión mediante cookies robadas es una técnica de ataque documentada que no requiere que el atacante conozca la contraseña de la víctima.
Esto significa, a nivel arquitectónico, que la defensa debe estar diseñada para funcionar incluso asumiendo el compromiso de credenciales. Esta es la lógica detrás de los principios de seguridad de confianza cero: en vez de confiar en que el usuario autenticado es quien dice ser porque presentó una credencial válida, la arquitectura aplica validación continua, análisis de comportamiento y controles de acceso basados en políticas que siguen siendo efectivos incluso cuando una credencial ha sido comprometida.
La gestión de identidades y accesos en la capa de aplicación – no solo en el perímetro de red – es lo que determina si una credencial comprometida lleva a una filtración o a un intento bloqueado y registrado. La diferencia entre una organización que detecta un ataque de credential stuffing en horas y otra que lo descubre meses después es la profundidad y consistencia de los controles de acceso y monitoreo aplicados en el plano de control para el intercambio seguro de datos. La visibilidad en tiempo real a través de un panel CISO que muestra patrones de acceso anómalos en todos los canales de contenido convierte el registro de auditoría en una capacidad operativa de detección, más allá de su función forense.
Construyendo una defensa en el plano de control
Las consecuencias regulatorias de la apropiación de cuentas basada en credenciales – especialmente en salud, defensa y servicios financieros – crean un requisito arquitectónico específico: los controles deben aplicarse en el nivel donde realmente se mueve la información sensible, no solo en el perímetro de red o en el proveedor de identidades.
Los controles perimetrales son valiosos pero insuficientes para este modelo de amenaza. Una credencial comprometida se autentica a través de los controles perimetrales por definición. El atacante presenta un token válido desde una dirección IP que puede coincidir con la ubicación del usuario, en un horario coherente con el uso normal. La detección basada en el perímetro no puede distinguir de forma fiable una sesión comprometida de una legítima sin contexto adicional.
Lo que ofrece la arquitectura de confianza cero es precisamente ese contexto adicional. Al aplicar controles de acceso basados en atributos (ABAC) a través del plano de control, la arquitectura impone políticas granulares según la sensibilidad de los datos, el rol del usuario, el estado de cumplimiento del dispositivo y el contexto de comportamiento – no solo si se presentó un token válido. Un usuario cuya credencial ha sido comprometida puede autenticarse con éxito, pero si su comportamiento posterior se desvía del patrón base o intenta acceder a datos fuera del alcance de su rol, la política ABAC bloquea el acceso y genera una alerta.
El registro de auditoría continuo es el componente probatorio que hace que esta arquitectura sea defendible ante cumplimiento. Cuando un regulador o un demandante pregunta «¿a qué accedió la cuenta comprometida y cuándo?», la respuesta debe ser un registro específico, con sello de tiempo e inmutable – no una representación general de que existían controles de acceso. Las organizaciones que no pueden presentar ese registro enfrentan el mismo problema probatorio que los reguladores han identificado cada vez más en acciones de cumplimiento – incluyendo la acción de la FTC contra Illuminate Education: la conciencia del riesgo sin controles verificables es en sí misma un fallo de cumplimiento.
La DLP dentro del plano de control proporciona una última capa de contención: políticas que inspeccionan los datos salientes en busca de tipos regulados – PHI, CUI, información personal identificable, registros financieros – y bloquean, ponen en cuarentena o alertan sobre transmisiones fuera de los canales aprobados. Incluso en un escenario donde una cuenta comprometida accede con éxito a datos sensibles, las políticas DLP pueden evitar que la exfiltración se complete. Los principios de minimización de datos aplicados en el plano de control reducen aún más el radio de impacto asegurando que las cuentas solo tengan acceso a los datos que requieren para su rol específico – no al máximo que sus permisos podrían permitir.
Kiteworks opera como el plano de control para el intercambio seguro de datos – combinando la aplicación de ABAC, cifrado de extremo a extremo, registro de auditoría inmutable y DLP en una capa de gobernanza unificada en todos los canales por los que circula información sensible: correo electrónico, uso compartido de archivos, SFTP, MFT, APIs e integraciones de IA. Esta es la arquitectura que permite a las organizaciones reguladas responder a la pregunta: «Si una credencial es comprometida y un atacante se autentica con éxito, ¿a qué puede acceder realmente, qué controles previenen la exfiltración y qué registro existe de lo sucedido?»
Qué deben hacer ahora los equipos de cumplimiento
El agregado de 24 mil millones de registros es un catalizador útil para una conversación que los equipos de cumplimiento, legales y de seguridad deberían estar teniendo independientemente de cualquier revelación puntual.
Primero, el monitoreo de exposición de credenciales debe tratarse como una función continua de evaluación de riesgos, no como una respuesta reactiva a revelaciones. Los servicios comerciales de notificación de filtraciones pueden proporcionar alertas casi en tiempo real cuando las credenciales de empleados aparecen en agregados conocidos. Esa inteligencia debe activar la rotación inmediata de contraseñas y la revisión de cuentas – no esperar al próximo ciclo programado de rotación.
Segundo, la aplicación de MFA debe verificarse en cada aplicación que accede a datos regulados, no solo en el proveedor de identidad principal. Muchas organizaciones tienen MFA fuerte en el perímetro de red pero no lo aplican de forma consistente en cada aplicación interna que usan sus empleados. Portales de transferencia de archivos, plataformas de correo electrónico y entornos de colaboración de documentos son brechas comunes.
Tercero, los programas de cumplimiento de la ley HIPAA, cumplimiento CMMC 2.0 y cumplimiento FedRAMP deben incluir cobertura explícita de la amenaza de credential stuffing en sus evaluaciones de riesgos. La pregunta estándar de evaluación de riesgos – «¿cuáles son las amenazas para nuestros datos regulados?» – debe incluir un análisis específico de qué sucede cuando se comprometen credenciales de empleados, a qué datos dan acceso esas credenciales y si los controles de acceso y el registro de auditoría existentes son suficientes para detectar y contener el incidente.
Finalmente, la infraestructura de registro y monitoreo de eventos en entornos regulados debe revisarse frente a la amenaza específica de sesiones autenticadas pero maliciosas. Esto es diferente de monitorear intentos fallidos de inicio de sesión. Requiere análisis de comportamiento de sesiones autenticadas para detectar patrones de acceso inconsistentes con la actividad normal del usuario – una capacidad que reside en el plano de control para el intercambio seguro de datos, no en el perímetro de red. Las organizaciones también deben asegurarse de que su plan de respuesta a incidentes cubra explícitamente escenarios de apropiación de cuentas basada en credenciales, con runbooks documentados para las obligaciones de reporte de cada marco regulatorio aplicable.
El agregado de 24 mil millones de registros será superado por uno mayor en cuestión de meses. El ecosistema de infostealers que aporta los registros más peligrosos a estas colecciones no se está desacelerando. La respuesta correcta no es alarmarse por una revelación puntual – es construir la arquitectura que convierte el compromiso de credenciales en un incidente contenido, no en una filtración de datos.
Para saber más sobre cómo Kiteworks minimiza el riesgo de apropiación de cuentas basada en credenciales en entornos regulados, solicita una demo personalizada hoy.
Preguntas Frecuentes
Una «colección» de credenciales es un conjunto de datos compilado de pares de nombre de usuario y contraseña agregados de múltiples filtraciones históricas – normalmente eventos ocurridos meses o años atrás. Las credenciales en una colección pueden haber sido ya rotadas o los sistemas a los que daban acceso desmantelados. Los registros de infostealer son cualitativamente distintos: son el resultado de malware ejecutándose activamente en máquinas infectadas, capturando credenciales a medida que se usan en tiempo real. Los registros de infostealer contienen credenciales recién recolectadas que probablemente sigan siendo válidas. Para los equipos de seguridad que evalúan agregados de filtraciones, la fracción de colecciones representa exposición histórica, mientras que la fracción de infostealer representa riesgo operativo activo. Los principios de seguridad de confianza cero están diseñados específicamente para entornos donde no se puede asumir la validez de las credenciales, proporcionando validación continua que no depende solo de la credencial. Las organizaciones deben incorporar escenarios específicos de infostealer en sus marcos de administración de riesgos de seguridad para asegurar que las capacidades de detección y respuesta estén calibradas a la velocidad de esta amenaza.
El credential stuffing es una técnica de ataque automatizada que prueba pares de nombre de usuario y contraseña de agregados de filtraciones contra aplicaciones web objetivo. Las herramientas modernas de credential stuffing rotan direcciones IP distribuidas y varían sus patrones de solicitud para evitar activar defensas de limitación de tasa o bloqueo de IP, haciendo que la detección basada en volumen sea poco fiable. El ataque tiene éxito cuando un par de credenciales robadas sigue siendo válido en la aplicación objetivo – normalmente porque el usuario reutiliza contraseñas en varios servicios o no ha rotado la credencial desde la filtración original. La detección requiere análisis de comportamiento de sesiones autenticadas, no solo monitoreo de intentos fallidos de inicio de sesión. Los registros de auditoría que documentan cada evento de acceso con dispositivo, ubicación y contexto de comportamiento son esenciales para identificar sesiones comprometidas a posteriori. Integrar esos registros en un SIEM con analítica de comportamiento brinda a los equipos de seguridad alertas en tiempo real para responder antes de que una sesión de credential stuffing derive en exfiltración de datos.
El MFA eleva significativamente el costo de los ataques de credential stuffing y bloquea la mayoría de los intentos que dependen de pares estáticos de nombre de usuario y contraseña. Sin embargo, el MFA no es una defensa absoluta. Los infostealers modernos capturan cookies de sesión del navegador emitidas tras un evento legítimo de MFA – permitiendo el secuestro de sesión que elude el requisito de MFA por completo. Además, algunas implementaciones de MFA pueden ser burladas mediante ataques de SIM swapping, frameworks de phishing en tiempo real o ingeniería social. La aplicación de MFA es un control esencial, pero debe tratarse como una capa dentro de una arquitectura de defensa en profundidad, no como una solución completa. Los controles ABAC a nivel de plano de control siguen siendo efectivos incluso cuando la autenticación ha sido comprometida, imponiendo restricciones basadas en políticas sobre lo que puede alcanzar una sesión comprometida. Combinar MFA con políticas de gobernanza de datos que limiten el acceso de cada rol reduce el daño que puede causar un evento de MFA burlado.
Las obligaciones dependen de a qué datos regulados accedió la cuenta comprometida. Bajo cumplimiento de la ley HIPAA, el acceso no autorizado a información de salud protegida (PHI) por una persona no autorizada se presume como filtración y requiere notificación a los individuos afectados y al Departamento de Salud y Servicios Humanos, salvo que la entidad cubierta demuestre baja probabilidad de compromiso mediante una evaluación de riesgo de cuatro factores. Bajo cumplimiento CMMC 2.0, el acceso no autorizado a CUI activa un reporte de incidente en 72 horas al DoD bajo DFARS 252.204-7012. Bajo FedRAMP, el acceso no autorizado a datos federales activa el reporte de incidente a la agencia correspondiente y a CISA. Los programas de cumplimiento de la ley HIPAA y CMMC 2.0 deben abordar explícitamente la apropiación de cuentas basada en credenciales en sus planes de respuesta a incidentes. Las organizaciones sujetas al RGPD enfrentan un requisito paralelo de notificación en 72 horas a la autoridad supervisora correspondiente cuando se involucran datos personales.
La respuesta debe priorizarse según el perfil de riesgo de las credenciales expuestas. Los empleados con acceso a datos regulados – PHI, CUI, información personal identificable, registros financieros – deben ser priorizados para rotación inmediata de credenciales y revisión de cuentas cuando los servicios de notificación de filtraciones detecten sus credenciales. La siguiente prioridad es aplicar MFA en cada aplicación que esos empleados usen para acceder a contenido regulado, no solo en el proveedor de identidad principal. La prioridad a medio plazo es verificar que los controles de acceso y monitoreo en la capa de contenido – no solo en el perímetro de red – sean suficientes para detectar y contener sesiones comprometidas antes de que resulten en exfiltración de datos. Para organizaciones sujetas a HIPAA o CMMC, esta verificación debe documentarse como parte del proceso continuo de evaluación de riesgos exigido por esos marcos. Una revisión de administración de riesgos de terceros sobre proveedores con acceso a entornos de datos regulados debe realizarse en paralelo, ya que infecciones de infostealer en endpoints de proveedores crean la misma exposición de credenciales que infecciones en endpoints internos.
Recursos adicionales
- Artículo del Blog Arquitectura Zero Trust: Nunca confíes, siempre verifica
- Video Microsoft GCC High: Desventajas que impulsan a los contratistas de defensa hacia ventajas más inteligentes
- Artículo del Blog Cómo proteger datos clasificados una vez que DSPM los identifica
- Artículo del Blog Generar confianza en la IA generativa con un enfoque Zero Trust
- Video La guía definitiva para el almacenamiento seguro de datos sensibles para líderes de TI