Por Ilkka Turunen, director de tecnología de campo, Sonatype
Por qué la próxima gran ley cibernética de Gran Bretaña podría no entender el punto
el Reino Unido Proyecto de ley de ciberseguridad y resiliencia se está promoviendo como un paso histórico hacia la mejora de la cibernética nacional.
resiliencia. Contiene varias medidas importantes, incluida una supervisión regulatoria ampliada, una cobertura más amplia de proveedores críticos y requisitos de notificación de incidentes más rápidos. Sin embargo, gran parte de la atención se ha centrado en los plazos para la presentación de informes. Si bien la notificación temprana puede mejorar la visibilidad, la coordinación y el intercambio de inteligencia sobre amenazas, hace poco para abordar las debilidades subyacentes de la cadena de suministro de software y las prácticas de seguridad que permiten muchos incidentes cibernéticos en primer lugar.
A diferencia del régimen NIS2 de la UE, que pone un énfasis significativo en la gobernanza, la rendición de cuentas y las obligaciones de seguridad de la cadena de suministro, el debate del Reino Unido se ha centrado en gran medida en los requisitos de notificación de incidentes.
Únase al European Business Briefing
Los nuevos suscriptores de este trimestre participan en un sorteo para ganar un Rolex Submariner. Únase a más de 40.000 fundadores, inversores y ejecutivos que leen EBM todos los días.
Suscribir
Por qué la generación de informes más rápidos no genera resiliencia
Una presentación de informes más rápida puede proporcionar a los reguladores y a las autoridades cibernéticas nacionales una visibilidad más temprana de las amenazas emergentes, ayudando a mejorar la coordinación y la concienciación en todo el sector. Sin embargo, estos beneficios no deben confundirse con la resiliencia misma. Para las organizaciones que responden a un incidente activo, la capacidad de detectar, contener y recuperar sigue siendo mucho más importante que la rapidez con la que se envía una notificación.
La verdadera resiliencia se construye mucho antes de que se presente una alerta. Depende de la preparación, la coordinación ensayada, los roles claros y los procesos de respuesta ensayados. Los plazos para el trámite no reemplazan la detección, la contención, la recuperación y la capacidad de absorber un ataque sin un impacto sistémico.
Las causas fundamentales siguen sin abordarse
El impacto económico de este desequilibrio es significativo. Los incidentes provocados por la cadena de suministro provocan habitualmente tiempos de inactividad forzados, soluciones de emergencia, exposición regulatoria y pérdida de productividad en organizaciones enteras. En las grandes empresas, una única dependencia comprometida puede detener a los equipos de desarrollo, retrasar los lanzamientos y absorber semanas de esfuerzo de ingeniería. Para las empresas más pequeñas, el costo suele ser existencial. Cuando los incidentes se originan en componentes de software compartidos, las organizaciones pagan para solucionar problemas que no crearon, utilizando recursos que de otro modo podrían invertirse en crecimiento, innovación y competitividad.
Los ciberincidentes modernos casi siempre tienen raíces muy anteriores al lugar donde se informan. Comienzan en la cadena de suministro de software, no en el panel de SOC. Los componentes vulnerables de código abierto, las bibliotecas obsoletas y los frágiles canales de CI/CD se encuentran entre los mayores aceleradores del compromiso.
El ecosistema de código abierto es enorme: desarrolladores de todo el mundo componentes descargados casi 9,8 billones de veces el año pasadoexponiendo a la explotación una enorme infraestructura compartida (es decir, 1.180 descargas por cada ser humano en la Tierra). Durante el mismo período, los paquetes maliciosos de código abierto crecieron un 75 por ciento, elevando el total a más de 1,23 millones de amenazas que acechan en los gráficos de dependencia utilizados por las empresas europeas todos los días.
Si bien el proyecto de ley fortalece los requisitos de gobernanza, supervisión y presentación de informes, pone menos énfasis en las medidas prácticas que las organizaciones pueden tomar para mejorar la seguridad de la cadena de suministro de software, la gestión de vulnerabilidades y las prácticas de desarrollo seguras por diseño.
A menos que las organizaciones también aborden cómo se construye, mantiene y gobierna el software, las obligaciones de informar corren el riesgo de tratar los síntomas en lugar de las causas. El desafío es cada vez más grave a medida que las organizaciones adoptan herramientas de desarrollo asistidas por IA que aceleran la generación de código y la adopción de dependencias. Sin una gobernanza y una supervisión sólidas, estas tecnologías pueden amplificar a escala los riesgos existentes en la cadena de suministro de software.
Las cadenas de suministro, no los silos, pondrán a prueba la ley
La expansión del proyecto de ley a proveedores de servicios gestionados, proveedores críticos e infraestructura digital adicional refleja un creciente reconocimiento de que el riesgo cibernético reside cada vez más en ecosistemas interconectados en lugar de dentro de organizaciones individuales.
Uno de los impactos prácticos más importantes del proyecto de ley será la responsabilidad de la cadena de suministro. Las organizaciones serán responsables no sólo de su propia preparación para la presentación de informes, sino también de la de sus proveedores, proveedores de servicios gestionados y socios de software. La mayoría de los terceros no tienen capacidades maduras de detección y respuesta a incidentes en la actualidad. Pocos pueden demostrar honestamente que pueden detectar, evaluar y notificar incidentes en plazos ajustados. Esto obligará a realizar cambios rápidos en las normas de adquisiciones, las cláusulas contractuales y las evaluaciones de riesgos de los proveedores.
Lejos de crear resiliencia, la regulación podría exponer fragilidades sistémicas a medida que las organizaciones se esfuerzan por mapear sus dependencias y gestionar el riesgo en las cadenas de suministro de software en expansión. Las debilidades de terceros pueden convertirse en la mayor fuente de incumplimiento e interrupción operativa.
Qué deberían hacer ahora las empresas europeas
Las empresas deberían tratar esto como una prueba de estrés para las prácticas existentes, no como un manual de cumplimiento. En primer lugar, simule escenarios realistas de detección e informes para ver si sus equipos pueden cumplir con los plazos propuestos sin sacrificar la contención o recuperación de incidentes. A continuación, evalúe la preparación de los proveedores frente a estos nuevos requisitos. Si sus socios no pueden demostrar prácticas maduras de seguridad y respuesta, es probable que las obligaciones legales recaigan sobre usted.
Lo más importante es invertir en mejores prácticas de desarrollo de software, gestión continua de vulnerabilidades y supervisión de dependencias. Mejorar la higiene y la procedencia de los componentes de software reduce la frecuencia y gravedad de los incidentes de manera más efectiva que acelerar la rapidez con la que se informa un incidente después de ocurrido.
Gobernar el riesgo, no sólo informarlo
Sin abordar el software inseguro, las cadenas de suministro frágiles y los procesos de respuesta no probados, el Proyecto de Ley de Resiliencia y Seguridad Cibernética corre el riesgo de convertirse en una carga administrativa en lugar de un catalizador para una resiliencia real. La presentación de informes obligatorios tiene cabida, pero no puede sustituir a la prevención previa. La verdadera medida de la resiliencia cibernética no será la rapidez con la que las organizaciones notifiquen a los reguladores después de un ataque, sino la eficacia con la que lo previenen, contienen y se recuperan.
Contexto/antecedentes:
Conseguimos esta ubicación después de nuestra llamada informativa CSRB, después de la cual redactamos y finalizamos la siguiente sinopsis:
El proyecto de ley de ciberseguridad y resiliencia soluciona el problema equivocado
El proyecto de ley sobre resiliencia cibernética del Reino Unido da la impresión de haber avanzado, pero centrarse en los informes cada 24 y 72 horas resuelve el problema equivocado. Una divulgación más rápida ayuda a los reguladores, pero no detiene los ataques ni reduce el riesgo. Los verdaderos problemas se encuentran en el software inseguro, las vulnerabilidades no administradas, las cadenas de suministro frágiles y los procesos de incidentes que muchas organizaciones nunca han probado. A menos que se aborden estos fundamentos, el proyecto de ley corre el riesgo de convertirse en un ejercicio de presentación de informes en lugar de un paso significativo hacia la resiliencia.
Ilkka Turunen, director de tecnología de campo de Sonatype, podría explicarnos cómo:
Informar no es resiliencia: los plazos ajustados pueden dar a los reguladores una visibilidad más rápida, pero no reducirán el número de infracciones. El verdadero desafío es coordinar una respuesta rápida y eficaz, lo que se complica por la vaga definición del proyecto de ley de “incidente significativo”.
Se está pasando por alto el problema del software: la mayoría de los incidentes cibernéticos comienzan con código inseguro, componentes obsoletos o canales de desarrollo débiles. El proyecto de ley ofrece poca orientación sobre cómo mejorar la higiene del software o adoptar prácticas seguras desde el diseño.
El riesgo de la cadena de suministro será el mayor shock: las organizaciones serán responsables de si sus proveedores y MSP pueden cumplir con los requisitos de presentación de informes. Esto obligará a realizar cambios inmediatos en las adquisiciones, la contratación y la gestión general de riesgos.
Las empresas deben actuar ahora: las empresas deben comenzar a probar si realmente pueden cumplir con los plazos de presentación de informes de 24 y 72 horas, revisando la preparación de los proveedores y fortaleciendo sus prácticas de desarrollo y seguridad antes de que el proyecto de ley exponga las deficiencias actuales.