Controles preventivos de la cadena de suministro

Un caso de cadena de suministro casi nunca tiene una sola causa. En el de Cuchuco hubo una puerta de entrada (cómo llegó la versión), una de ejecución (qué pudo hacer una vez dentro) y una de detección (cuánto tardó la empresa en enterarse). Un buen plan pone al menos un control en cada capa, de forma que si uno falla el siguiente todavía corta:

• Antes de entrar: qué versiones y qué piezas pueden llegar a una compilación o a un equipo.
• Al ejecutar: qué puede hacer lo que ya entró, empezando por con quién puede hablar.
• Al detectar: cuánto tarda en verse lo que se escapó de las dos capas anteriores.

Los marcos públicos lo plantean así. El marco de desarrollo seguro de software de NIST (SSDF, SP 800-218) pide proteger el código y verificar los componentes de terceros, y la guía de NIST sobre riesgos de la cadena de suministro (SP 800-161) trata al proveedor y a la pieza de terceros como parte del riesgo propio, no como algo ajeno.

En el caso, la versión maliciosa entró y corrió. Lo que convirtió eso en una fuga fue que el servidor de herramientas podía hablar con cualquier destino de internet. Un servidor que solo necesita hablar con su almacén de hojas no tiene por qué poder hablar con nadie más.

Con las causas en una columna y los controles en otra, se busca el conjunto más barato que corta todas. A veces un control grande cubre varias causas; a veces dos pequeños lo hacen por menos. Los que no cortan ninguna causa por sí solos se dejan fuera del cálculo, aunque se puedan añadir después.

En toda lista de controles después de un incidente aparece alguno que suena a seguridad y no toca ninguna causa del caso. Señalarlo a tiempo ahorra presupuesto y evita la sensación de que el caso quedó resuelto.

La dirección pide una recomendación que pueda aprobar hoy. Tiene que cubrir las cinco causas, decir cuánto cuesta y no prometer lo que ningún control da.