Mes de la Ciberseguridad (3/4): tu seguridad es la del más flojo de tus proveedores

Tercera entrega. Ya sabes lo que tienes y ya sabes cómo te van a engañar.

Hoy toca la parte que más incomoda, porque es la que no controlas del todo: todo lo que has instalado, contratado o enchufado a tu sistema y que mantiene otra persona.

La serie

1. El inventario
2. El factor humano
3. La cadena de suministro ← estás aquí
4. El día después

Contenedores en el puerto de Róterdam. Foto: AgainErick, CC BY-SA 4.0; imagen recortada y disponible bajo la misma licencia.

El complemento hereda los privilegios del anfitrión

Esta idea ya ha salido en este blog y la voy a seguir repitiendo, porque es la regla que explica muchísimos incidentes:

Muchas veces lo que se rompe no es el sistema. Es lo que le enchufamos al sistema.

El núcleo de WordPress también tiene fallos, pero lo habitual es que entren por el plugin de galerías que instalaste en 2021 porque hacía un carrusel bonito. Node también los tiene, pero es más fácil colar algo en el paquete de 40 líneas que instaló otro paquete que instaló tu framework. Y a una empresa grande a veces no se entra por su firewall, sino con las credenciales de su proveedor del aire acondicionado.

Ese último no es un ejemplo inventado. Así empezó el caso Target en 2013, según la investigación del Senado de Estados Unidos: con credenciales robadas a Fazio Mechanical, su proveedor de climatización, que tenía acceso a un sistema de facturación de Target. Acabó con los datos de 40 millones de tarjetas fuera.

Tres historias para entender el problema

SolarWinds, 2020. Alguien comprometió el sistema de compilación de una herramienta de monitorización de redes y metió código malicioso dentro de la actualización oficial, firmada digitalmente por el fabricante. Unas 18.000 organizaciones instalaron la puerta trasera haciendo exactamente lo correcto: mantener el software al día. La actualización, la práctica que llevamos veinte años recomendando, fue el vector.

xz-utils, 2024. Una puerta trasera en una utilidad de compresión presente en casi todas las distribuciones de Linux. Iba solo en las versiones 5.6.0 y 5.6.1, que cuando se descubrió habían llegado a algunas ramas de pruebas (Debian unstable, Fedora Rawhide) y a distribuciones de actualización continua como openSUSE Tumbleweed, pero no a las versiones estables que corren en casi todos los servidores. La colocó alguien que dedicó dos años a colaborar en el proyecto y ganarse la confianza del mantenedor, hasta conseguir permisos para publicar versiones. Se descubrió de casualidad, porque un ingeniero notó que una conexión SSH tardaba medio segundo de más.

Y el clásico de npm. Un paquete popular, con millones de descargas, que cambia de manos por una de dos vías. El mantenedor se cansa y acepta la ayuda entusiasta de un colaborador nuevo: con event-stream, en 2018, ese colaborador añadió una dependencia que robaba carteras de bitcoin. O le roban la cuenta: con ua-parser-js, en 2021, salieron tres versiones con un script de instalación que descargaba un minero y un ladrón de contraseñas. Estuvieron publicadas cuatro horas, en un paquete que se descargaba unos siete millones de veces por semana. Y no hacía falta haberlo instalado a propósito: podía llegar como dependencia de otra dependencia.

El patrón es siempre el mismo: el atacante no ataca tu puerta, ataca la puerta de quien tiene tu llave.

Por qué esto es un problema de negocio y no de informática

Porque la relación es asimétrica y casi nadie la mira así.

Cuando contratas un proveedor o instalas un plugin, estás extendiendo tu perímetro de seguridad al suyo, y lo estás haciendo sin auditarlo, sin contrato específico y sin saber ni cuántos son.

En la práctica, tu seguridad es la del más flojo de tu lista de proveedores. Cuánto daño pueda hacer el que caiga ya depende de ti: de los accesos que le diste y de lo aislado que tengas lo demás, que es justo de lo que van las medidas de más abajo. Y esa lista, en cualquier empresa mediana, tiene decenas de nombres: el CRM, la herramienta de facturación, la de nóminas, el chat de la web, el píxel de analítica, la agencia que gestiona campañas y tiene acceso a tus cuentas, la asesoría con los datos de la plantilla y el desarrollador que hizo la web en 2019 y sigue teniendo el FTP.

Ese desarrollador de 2019, por cierto, me lo encuentro a menudo, con el acceso todavía activo.

Qué hacer: seis medidas para empezar

1. La lista, otra vez

Sí, otra lista. La del primer artículo, pero de terceros: quién tiene acceso a qué, con qué nivel y desde cuándo. Incluye proveedores, exproveedores, plugins, dependencias, integraciones y esa cuenta de invitado del consultor de 2022.

Si no puedes contestar «¿quién tiene acceso a nuestros datos de clientes?» con una lista cerrada, ese es el proyecto de este trimestre.

2. Menos cosas

La medida más eficaz de toda la serie y la que menos se aplica.

Cada plugin, cada dependencia, cada integración que no instalas es una vulnerabilidad futura que no tendrás que parchear a las tres de la mañana.

Antes de instalar algo, tres preguntas: ¿cuándo se actualizó por última vez?, ¿cuánta gente lo mantiene?, ¿qué pasa si desaparece mañana? Si la última actualización es de hace tres años, lo mantiene una persona y no tienes alternativa a mano, no es gratis: es una deuda con vencimiento desconocido.

Y la pregunta definitiva: ¿podríamos hacer esto sin instalar nada? Sorprendentemente a menudo, sí.

3. Privilegio mínimo, de verdad

El proveedor de la newsletter no necesita acceso de administrador. La agencia no necesita el usuario root. El script de backup no necesita permisos de escritura sobre todo.

Y la variante que más veo: una única cuenta compartida por la que pasan cuatro empresas distintas. Cuando hay incidente, no se puede saber quién hizo qué. Cuentas nominales para las personas, siempre, aunque sea más incómodo. Y las integraciones y los procesos automáticos, cada uno con su propia cuenta de servicio, identificable y con los permisos justos.

4. Fecha de caducidad en los accesos

Los accesos deberían caducar por defecto. Un proveedor entra para un proyecto de tres meses: su acceso caduca a los tres meses, y si sigue haciendo falta, se renueva. Es un cambio de reglas por defecto que elimina, de un plumazo, la categoría entera de «cuentas de gente que ya no está».

5. Contratos que digan algo

Si un proveedor trata datos personales por ti, hay contrato de encargado de tratamiento. No es burocracia. El RGPD ya le obliga a avisarte sin dilación indebida si sufre una brecha que afecte a esos datos; el contrato es donde esa obligación deja de ser un principio y se convierte en un procedimiento: a quién se avisa, por qué canal y en qué plazo.

Y aquí la pregunta que casi nunca está en el contrato y debería ser la primera: «si tenéis una brecha, ¿en cuántas horas me lo decís?»

6. Saber qué llevas dentro

Para lo que es software, un inventario de dependencias —lo que en el sector se llama un SBOM, la lista de ingredientes del producto—. No hace falta empezar por una herramienta cara: basta con poder responder en una hora a «¿usamos la librería X?». Ese es el listón, y casi nadie lo pasa.

Lo que no se puede evitar

Una nota de honestidad para cerrar, porque me molesta la seguridad vendida como promesa.

No puedes eliminar este riesgo. Puedes reducirlo mucho, pero no a cero: usar software de terceros es la única forma sensata de construir cualquier cosa, y auditar cada línea de cada dependencia no lo hace nadie, ni las empresas grandes.

Lo que sí puedes hacer es acortar el tiempo entre que pasa algo y te enteras, y tener claro qué haces cuando pase.

Y de eso va, precisamente, el último artículo de la serie.

La semana que viene

Cierre del Mes de la Ciberseguridad con la pregunta que nadie quiere hacerse en voz alta: ¿y si ya ha pasado?

Plan de respuesta, las 72 horas para avisar a la AEPD —que empiezan a contar cuando te enteras—, la copia de seguridad que nunca has restaurado y por qué conviene tener decididos los primeros veinte minutos antes de tener que improvisarlos.

Nos vemos el 26.