La violación de seguridad de Novo Nordisk expone los riesgos del proceso de desarrollo de software

Una reciente (y probablemente masiva) violación en Novo Nordisk, en la que los atacantes inicialmente pudieron establecerse utilizando un único token de acceso de GitHub, subraya cómo los repositorios de código y los entornos de desarrollo se han convertido en el punto de partida para los atacantes que buscan propiedad intelectual, credenciales y activos de la cadena de suministro de software.

Novo Nordisk, el gigante farmacéutico danés detrás de los exitosos medicamentos Ozempic y Wegovy, reveló la violación el 11 de junio después de descubrir acceso no autorizado a lo que dijo era «un número limitado de sus sistemas internos de TI».

¿Un incumplimiento mayor que el revelado?

Después Según la empresa, los atacantes accedieron a datos seudónimos de un número desconocido de pacientes que participaban en ensayos clínicos, incluida la identificación del paciente, el sexo, la fecha de nacimiento, los biomarcadores, los datos de salud/inmunogenicidad y los factores del estilo de vida, como el consumo de tabaco y alcohol.

La violación también afectó a los datos de Profesionales de la salud Información asociada con Novo Nordisk, incluido el nombre, número de registro, ubicación de las oficinas, correo electrónico, número de teléfono y detalles de WhatsApp. «Debido a la naturaleza de los datos expuestos, las posibles consecuencias del incidente incluyen intentos de phishing dirigidos a través de correo electrónico, teléfono y WhatsApp, o comunicaciones fraudulentas haciéndose pasar por colegas», advirtió Novo Nordisk.

Relacionado:Libérese de la deuda de seguridad abordando la exposición al riesgo

Pero los detalles proporcionados por FulcrumSec, El grupo de amenazas que se atribuye la responsabilidad del ataque cree que la violación fue mucho más amplia y potencialmente más dañina de lo que Novo Nordisk ha revelado públicamente.

Información compartida con el grupo de amenazas. Violaciones de datos.Net sugieren que los atacantes pasaron más de dos meses en la red de la compañía farmacéutica y extrajeron más de 700.000 archivos, equivalentes a aproximadamente 1,3 TB de datos, antes de exigir un rescate de 25 millones de dólares.

La información robada incluía código fuente, información patentada sobre medicamentos comercializados y no publicados, datos de investigación y ensayos clínicos, modelos internos de IA, registros relacionados con las operaciones de producción y la tecnología de producción de Novo Nordisk, registros de profesionales médicos e información sobre aproximadamente 11.500 participantes de ensayos clínicos seudónimos. Desde entonces, FulcrucmSec ha comenzado a revelar públicamente algunos de los datos que afirmó haber obtenido después de que Novo Nordisk aparentemente se negara a pagar el rescate exigido. «FulcrumSec cree que los datos extraídos y el análisis generado por IA podrían ahorrar a otros investigadores o competidores de tres a cinco años de desarrollo de programas», señaló DataBreaches.Net.

Un solo token de GitHub fue todo lo que se necesitó

FulcrumSec afirmó que obtuvo acceso inicial a Novo Nordisk en marzo a través de un «token de acceso personal de GitHub en JS del lado del cliente en un subdominio oscuro» revelado y altamente privilegiado. Luego aparentemente utilizaron el token de acceso para clonar repositorios privados y recopilar credenciales adicionales que utilizaron para penetrar más profundamente en la red y los sistemas de Novo Nordisk.

Relacionado:La prohibición británica de las redes sociales para menores preocupa a los expertos en privacidad

Novo Nordisk aún no ha confirmado públicamente el alcance de la infracción. La empresa no respondió a una solicitud de Dark Reading para comentar sobre la infracción por la que se culpó a FulcrumSec. segundo procedimiento separado de un grupo de amenazas llamado TheUSERS007. En correspondencia con DataBreaches.Net, TheUSERS007 proporcionó información que indica que el grupo irrumpió en Novo Nordisk entre el 5 y el 7 de junio y robó datos relacionados con los esfuerzos del fabricante de medicamentos relacionados con la IA.

Matt Kimpel, director de seguridad de la información (CISO) del proveedor de servicios gestionados Magna5, dice que los informes de incidentes son otro ejemplo de esto. Desarrolladores y entornos de desarrollo. se han vuelto de alta calidad Objetivos para los atacantes. «Los desarrolladores se sientan cerca de los sistemas que más importan. Tienen acceso constante al código fuente, a los procesos de construcción e implementación, a los entornos de nube y a las credenciales que estos sistemas utilizan para comunicarse entre sí», afirma.

Relacionado:La mayoría de los CISO reportan presión para ocultar malas noticias de seguridad

Objetivos blandos y de alta calidad

Kimpel enfatiza que las plataformas de desarrollo se han convertido silenciosamente en los sistemas más valiosos de la empresa y la mayoría de los programas de seguridad no se han puesto al día. Por ejemplo, un repositorio de código fuente ya no es sólo el lugar donde se almacena el código fuente. También incluye definiciones de infraestructura, procesos de implementación, integraciones con sistemas posteriores y documentación que explica cómo está conectado el entorno. «Para un atacante, acceder al repositorio de códigos es más como abrir los planos que abrir un archivador», señala Kimpel.

El desarrollo asistido por IA acelera el riesgo al aumentar el volumen y la velocidad de creación de código, al tiempo que abre nuevas oportunidades para que se filtren datos confidenciales y secretos a través de herramientas y flujos de trabajo no autorizados, afirma Kimpel. Los tokens API, las cuentas de servicio y otras credenciales de máquinas se han convertido en objetivos particularmente valiosos porque son abundantes, tienen muchos privilegios, son difíciles de inventariar y monitorear para las organizaciones y, a menudo, persisten durante largos períodos de tiempo sin rotación.

“Estas plataformas merecen ser tratadas como sistemas de producción y no como herramientas de desarrollo”, argumenta. «La mayoría de las veces se sientan». La protección predeterminada, las aprobaciones de sucursales, la revisión de código y la activación de canalizaciones suponen que la identidad correcta está haciendo el trabajo, lo que significa que una vez que un atacante actúa como un desarrollador confiable, los mismos controles funcionan para él, señala. «Lo que la mayoría de las empresas hacen mal es ver la gestión de secretos como un problema de herramientas en lugar de un problema de identidad».

Los repositorios de códigos se han convertido en uno de los puntos ciegos más importantes en la seguridad empresarial, coincide Shane Barney, CISO de Keeper Security. No es raro que credenciales codificadas, tokens comprometidos y claves de acceso caducadas incorrectamente se acumulen silenciosamente en repositorios, canales de CI/CD y archivos de configuración. A diferencia de las cuentas humanas, estas credenciales de máquina rara vez tienen propietarios únicos, horarios de rotación consistentes o un monitoreo significativo. Una vez que se les atiende, en gran medida quedan olvidados, afirma. «Esta invisibilidad es lo que convierte un único token expuesto en una caída que dura meses», señala Barney. «Si una credencial de máquina contiene amplios privilegios y nadie la está vigilando, un atacante que la encuentre no necesita aumentar sus privilegios ni actuar con cuidado. El acceso ya está ahí. El radio de explosión de esa credencial es la vulnerabilidad».

El enfoque correcto para mitigar este riesgo es centralizar la gestión de secretos, hacer cumplir el principio de privilegio mínimo de manera consistente en todas las identidades del entorno y permitir la rotación automática para que las credenciales no pierdan silenciosamente su propósito. «Esta disciplina no elimina el riesgo, pero cierra la brecha entre lo que encuentran los atacantes y lo que realmente pueden hacer con ello».

Reducir el riesgo

El incidente es otro recordatorio de que los entornos de desarrollo, incluidos los puntos finales de desarrollador e IDE, repositorios y canales de CI/CD, a menudo están configurados con acceso de producción, dice Ed Luz, director de investigación de Oasis Security Identity. El uso y el acceso a estos dispositivos deben mapearse y monitorearse, y las claves confidenciales deben guardarse en ubicaciones designadas y administradas y cambiarse periódicamente. “Aquí hay dos detalles más importantes”, dice Luz, refiriéndose a la violación de Novo Nordisk. «Primero, el punto de entrada: un único token de acceso a GitHub. Segundo, el movimiento lateral: credenciales adicionales encontradas dentro de los propios repositorios. Los atacantes no traspasaron el perímetro, fueron autenticados».

Kimpel recomienda que las organizaciones mejor comiencen por hacer un inventario de sus identidades no humanas y obtener una visión clara de lo que está presente en el entorno. “A partir de ahí, las prioridades son claras: eliminar secretos de larga duración allí donde la carga de trabajo lo permita, planificar agresivamente, rotar con una verdadera cadencia y según una señal en lugar de un calendario”, afirma. «Monitoree las identidades de las máquinas de la misma manera que monitorea las identidades humanas, detecte el comportamiento normal y alerte sobre anomalías».