Proveedores críticos, la vulnerabilidad que no es tuya pero sí tu riesgo

Cuando un proveedor entrega firmware, software o un servicio, parte de la superficie de ataque del banco la decide otra empresa. El banco puede delegar la operación, pero no la responsabilidad: si un fallo del proveedor afecta a los clientes, es el banco quien responde. Por eso en banca se mantiene un registro de proveedores críticos y se exige a cada uno plazos de respuesta y evidencia periódica de su seguridad.

En la Unión Europea, DORA incluye reglas específicas para el riesgo de terceros que prestan servicios de tecnología a entidades financieras, entre ellas el mantenimiento de un registro de acuerdos con esos terceros. En los ejercicios de esta sala el registro es ficticio.

Abre leeme.txt y proveedores.csv. Un proveedor crítico con acceso remoto a la red del banco es el caso que más preocupa, porque su propio compromiso podría convertirse en acceso al banco. Cuenta los proveedores que son críticos y además tienen acceso remoto.

La columna ultima_evidencia marca la fecha del último informe de seguridad que entregó cada proveedor. Entre los críticos, quien lleva más tiempo sin entregar evidencia es el primero al que se le pide una actualización. No se mira a los no críticos: una evidencia vieja allí es un asunto de otro nivel.

avisos-a-proveedores.csv registra los avisos que el banco envió a cada proveedor y las horas que llevan sin respuesta. Cada proveedor tiene en proveedores.csv su plazo contractual de respuesta. Un aviso incumple si las horas sin respuesta superan ese plazo.

Cuenta los avisos que incumplen, pero solo de proveedores críticos. Un aviso fuera de plazo de un proveedor no crítico tiene otro tratamiento.

Cuando un aviso de un proveedor crítico no se contesta a tiempo, el banco no puede parchear, pero sí puede exigir. Lo útil es una petición concreta, con fecha y con el impacto descrito, y con copia al responsable del contrato, no un recordatorio genérico.