El radio de explosión extendido: Lo que sabemos sobre la vulneración Nissan-Red Hat

Los actores de amenazas modernos y los ladrones de datos ya no ven a la empresa como un monolito. En cambio, aplican una taxonomía clínica a sus objetivos, clasificando sistemáticamente los activos de una organización en cuatro dominios estratégicos iniciales de interés. Esto incluye la Confianza del Cliente (PII), la Estabilidad Interna (Datos de Empleados), el Capital Intelectual (Datos Empresariales) y, lo más crítico, la Soberanía Funcional (Control Operativo). Esto hace que sea más fácil identificar las rutas de ataque y cosechar los fragmentos de datos relevantes con más enfoque, atención y tácticas.  

En el mundo automotriz poblado por tecnología de alto riesgo, a menudo hablamos sobre la ciberseguridad dentro de los "perímetros" de nuestro negocio y los tratamos como si fueran muros sólidos. Las empresas también invierten millones en firewalls, EDR y SOC para asegurar sus puertas internas. Sin embargo, como demuestra la reciente vulneración que involucra a Nissan y Red Hat, la empresa moderna ciertamente no tiene muros. En cambio, tiene un sistema circulatorio bien conectado que llega hasta consultores externos que se supone son guardianes temporales de datos. Y cuando una arteria principal como un socio consultor global es dañada, el impacto de una fuga (por pequeña que sea) puede sentirse a miles de millas de distancia.

La línea de tiempo del ataque

En algún momento de la mañana del 26 de septiembre, que era un viernes, Red Hat detectó por primera vez el ataque en forma de acceso no autorizado. Actuando de inmediato, Red Hat bloqueó el acceso a los datos y aisló el servidor para prevenir cualquier acceso adicional al servidor incluso de fuentes validadas.

Una semana después y tras una ronda de confirmaciones internas, Red Hat transmitió la información sobre la vulneración a Nissan el 3 de octubre (el viernes siguiente) quien de inmediato reportó la vulneración a la Comisión de Protección de Información Personal. Además, según Nissan, también contactaron a los clientes que se cree fueron afectados por la vulneración directamente o cuyos datos fueron comprometidos. La empresa también emitió una disculpa en su sitio web.  

No se conocía que el servidor afectado contuviera otra información además de los datos comprometidos según Nissan.

La anatomía del ataque a Nissan y su repercusión

Visto desde un nivel estratosférico, la noticia es un título estándar de vulneración de datos: 21,000 clientes de Nissan en Japón tuvieron sus detalles personales expuestos, incluidos clientes que han (o habían) comprado vehículos y recibido servicios en la antigua Fukuoka Nissan Motor Co., Ltd. (actualmente Nissan Fukuoka Sales Co., Ltd.)

Pero la fuente de la fuga no fue un servidor de Nissan desprotegido u olvidado. El incidente involucró un ataque indirecto enrutado a Nissan que posiblemente se originó en una instancia de GitLab comprometida utilizada por Red Hat Consulting. Los niveles de protección de datos considerados para el servidor son desconocidos en este punto.

El llamado "Colectivo Carmesí" el actor de amenaza detrás de la vulneración no solo robó registros. Robaron 570GB de "Informes de Compromiso del Cliente" (CERs) numerando alrededor de 800.

Según el gigante automotriz, la estrategia de compromiso con el cliente de Nissan se centra en gran medida en la mensajería móvil personalizada, una experiencia digital-a-concesionario sin problemas, y el uso de analítica de datos para entregar contenido y servicios relevantes. La empresa apunta a construir lealtad a largo plazo y lograr altas tasas de conversión y es posible que estos datos se recolectaron y almacenaron como parte de este ejercicio y se entregaron a Red Hat como parte de un proyecto.

Los informes robados contienen detalles como:

·         Nombres completos verificados

·         Direcciones físicas

·         Números de teléfono

·         Direcciones de correo electrónico

·         Datos de clientes utilizados en operaciones relacionadas con ventas y seguros

La empresa ha afirmado que los detalles de tarjetas de crédito no formaban parte de la vulneración. Nissan también ha emitido un aviso a los clientes afectados para que tengan cuidado al responder a llamadas sospechosas sobre sus vehículos. 

Cuando se mezcla con otra información que podría obtenerse de bases de datos robadas, esto podría fácilmente llevar a los clientes un paso más cerca de una vulneración en un ataque de phishing. Estos datos también podrían utilizarse para construir un perfil de comprador del cliente y esencialmente es una pendiente resbaladiza desde aquí.  

El "Punto Ciego del Consultor"

Nissan tenía múltiples proyectos de colaboración con Red Hat.

Según la información disponible, Nissan había contratado a Red Hat con una oportunidad de consultoría para transformar al gigante automotriz en un jugador clave en el espacio de vehículos definidos por software. Esta fue una colaboración rica en datos. De hecho, Nissan había anunciado que estaría utilizando el Sistema Operativo In-Vehicle de Red Hat para impulsar su plataforma de vehículos definida por software de próxima generación.  Según Red Hat, su nuevo sistema operativo vehicular puede soportar sistemas avanzados de asistencia al conductor, cockpits digitales, telemática, infoentretenimiento y modelos de IA de vanguardia.

Además de esto, Nissan también había contratado a Red Hat para construir un sistema de gestión de clientes. Los detalles de este proyecto no están muy claros. De la información disponible a nosotros y analizada por nuestro equipo de investigación, parece que fue este proyecto el que se vio impactado por la vulneración.

La información filtrada fue brindada a los consultores de Red Hat por Nissan con el propósito de trabajar en el proyecto del sistema de gestión de clientes. La división de consultoría de Red Hat había almacenado la información en su propia instancia interna de GitLab junto con otros artefactos del proyecto. Desafortunadamente, este fue el servidor que fue vulnerado. Técnicamente, esto no es una vulneración en Nissan.

Durante años, he argumentado que las firmas consultoras están convirtiéndose en puntos de agregación máxima de credenciales. Contratamos expertos para ayudarnos a escalar, pero al hacerlo, a menudo les otorgamos un nivel de confianza que pasa por alto nuestros protocolos estándar de Confianza Cero. Tal dicotomía en los controles de seguridad podría ser fácilmente mal utilizada por un actor de amenaza. De hecho, los actores de amenaza vigilan a los consultores que manejan estos datos. Esto no es para culpar a nadie aquí de ninguna manera. Pero esta es una práctica estándar en industrias que opera en base al nivel de confianza que existe entre el cliente y el consultor (en algunos casos el consultor podría incluso ser un individuo). 

Cuando un consultor crea un "repositorio en la sombra" o un entorno de prueba para construir su próximo sistema de gestión de compromiso con el cliente, ese entorno podría estar fuera de la supervisión rigurosa de su CISO interno o del equipo de seguridad correspondiente. En algunos casos, puede que ni siquiera esté sujeto a las mismas auditorías de evaluación de riesgos a las que están sujetos otros aspectos de su infraestructura. Ha habido casos en el pasado cuando una colaboración termina pero el consultor retiene los datos del cliente por un tiempo. A veces, los datos incluso se olvidan en el proceso. 

Una capa adicional de seguridad para dichos datos y colaboración podría ayudar bastante a prevenir tales incidentes. 

Tres lecciones para el líder estratégico de ciberseguridad

Si estás sentado en una sala de juntas hoy, el evento Nissan-Red Hat debería desencadenar tres cambios inmediatos en tu pensamiento:

• Comienza a auditar compromisos: Pasamos meses evaluando el producto de un proveedor de software pero solo unos minutos firmando un SOW para sus consultores. Debemos tratar a los equipos de consultoría como usuarios privilegiados con acceso "permanente-temporal" que requiere monitoreo continuo y automatizado. El consultor debe entregar informes de cumplimiento de manera continua para satisfacer las necesidades de exposición al riesgo del cliente.

• La muerte de los secretos estáticos: Los secretos codificados en los Informes de Compromiso con el Cliente (CERs) fueron el principal combustible para esta vulneración. En una era de caza de amenazas impulsada por IA, los tokens estáticos son una responsabilidad. Si un secreto puede ser escrito, puede ser robado.

• Reconozca el "Radio de Explosión" extendido: Esta vulneración afectó a Nissan, pero los datos robados incluían informes de más de 800 organizaciones, incluyendo agencias gubernamentales y gigantes financieros. Debemos mapear nuestro "radio de explosión" y saber la respuesta a la pregunta "si nuestro consultor principal es vulnerado esta noche, ¿qué llaves específicas de nuestro reino tienen actualmente?"

La gran imagen. Mirando más allá del firewall

En Shieldworkz, a menudo discutimos la convergencia de lo digital y lo físico. En el sector automotriz, esto no se trata solo de "nombres de clientes". En cambio, se trata de los datos personales del cliente y la infraestructura que gestiona el ciclo de vida del vehículo. A medida que avanzamos hacia ciudades más inteligentes y conectadas, una vulneración de un "sistema de gestión de clientes" incluso a nivel de proyecto piloto puede ser el primer paso hacia una intrusión mucho más peligrosa en la capa de OT (Tecnología Operativa) de nuestras vidas.

La seguridad ya no es un problema técnico; es esencialmente un desafío continuo de concienciación intelectual. Requiere la imaginación de ver las conexiones que hemos construido y el coraje para asegurarlas incluso cuando están fuera de nuestra vista directa.

¿Es la capa de consultoría de su organización un puente bien supervisado o una vulneración esperando ocurrir?

Y finalmente, nueva regla (en la voz de Bill Maher): Trate a sus consultores externos no como "invitados de confianza", sino como una extensión crítica de su superficie de ataque que requiere el mismo rigor de Confianza Cero que sus equipos internos.

Una nota sobre la vulneración publicada por Nissan más temprano hoy