Bienvenido a la serie de OmniTrust sobre lecciones aprendidas de la CRA.<\/p>\n
Cuando se present\u00f3 por primera vez la Ley de Ciberresiliencia (CRA) de la Uni\u00f3n Europea, la mayor\u00eda de las organizaciones la abord\u00f3 como cualquier otra regulaci\u00f3n nueva. Las preguntas iniciales eran previsibles: \u00bfNos aplica? \u00bfQu\u00e9 productos est\u00e1n dentro del alcance? \u00bfQu\u00e9 documentaci\u00f3n ser\u00e1 necesaria? \u00bfCu\u00e1nto trabajo requerir\u00e1 el cumplimiento?<\/p>\n
A medida que las empresas han pasado de la planificaci\u00f3n a la implementaci\u00f3n, ha surgido una realidad diferente.<\/p>\n
Las organizaciones que m\u00e1s avanzan ya no se centran en comprender la propia regulaci\u00f3n. Se centran en comprender c\u00f3mo operacionalizarla en carteras completas de productos, organizaciones de ingenier\u00eda, cadenas de suministro y ciclos de soporte.<\/p>\n
Ah\u00ed es donde la situaci\u00f3n se vuelve interesante.<\/p>\n
Durante el \u00faltimo a\u00f1o, OmniTrust ha tenido la oportunidad de trabajar con fabricantes, proveedores de software, empresas industriales, compa\u00f1\u00edas de dispositivos m\u00e9dicos y proveedores de productos conectados que se est\u00e1n preparando activamente para el cumplimiento de la CRA. Tambi\u00e9n hemos pasado incontables horas hablando con expertos del sector, l\u00edderes de seguridad de productos, profesionales de cumplimiento, equipos de ingenier\u00eda y ejecutivos que intentan responder a la misma pregunta fundamental:<\/p>\n
Lo que hemos descubierto es que los mayores desaf\u00edos rara vez son los que las empresas esperaban.<\/p>\n
Las organizaciones suelen empezar centr\u00e1ndose en controles de ciberseguridad, pr\u00e1cticas de desarrollo seguro o documentaci\u00f3n t\u00e9cnica. Todo eso es importante. Pero muchos equipos descubren r\u00e1pidamente que los desaf\u00edos m\u00e1s dif\u00edciles tienen que ver con gobernanza, responsabilidad, gesti\u00f3n de evidencias, visibilidad de la cadena de suministro de software, procesos de respuesta a vulnerabilidades, compromisos de soporte y coordinaci\u00f3n interfuncional.<\/p>\n
En otras palabras, crear un producto seguro es importante, pero no es suficiente.<\/p>\n
La CRA est\u00e1 demostrando ser tanto un desaf\u00edo operativo como un desaf\u00edo de ciberseguridad.<\/p>\n
Por qu\u00e9 creamos esta serie<\/strong><\/p>\n Este blog marca el comienzo de nuestra serie de lecciones aprendidas sobre la CRA. El objetivo es sencillo: compartir observaciones pr\u00e1cticas, lecciones de implementaci\u00f3n y mejores pr\u00e1cticas emergentes de organizaciones que trabajan activamente en su preparaci\u00f3n para la CRA.<\/p>\n En lugar de repetir el lenguaje regulatorio o resumir la legislaci\u00f3n, queremos centrarnos en lo que las empresas est\u00e1n experimentando realmente al pasar de la teor\u00eda a la ejecuci\u00f3n.<\/p>\n En distintos sectores estamos viendo surgir muchos de los mismos patrones.<\/p>\n Los inventarios de productos suelen estar incompletos. Las dependencias de software no siempre se comprenden bien. La documentaci\u00f3n suele estar dispersa entre m\u00faltiples sistemas. La responsabilidad de las actividades de cumplimiento puede no estar clara. La recopilaci\u00f3n de evidencias se vuelve dif\u00edcil de mantener durante ciclos de vida largos. Los equipos descubren que los programas de seguridad existentes, aunque valiosos, no satisfacen autom\u00e1ticamente las expectativas regulatorias.<\/p>\n No son situaciones poco habituales. De hecho, se est\u00e1n volviendo notablemente comunes.<\/p>\n La buena noticia es que las organizaciones tambi\u00e9n est\u00e1n descubriendo formas pr\u00e1cticas de abordarlas.<\/p>\n Una de las lecciones m\u00e1s importantes que surgen de los primeros esfuerzos de implementaci\u00f3n es que el cumplimiento de la CRA no puede delegarse en un solo departamento.<\/p>\n Los equipos de seguridad no pueden resolverlo solos.<\/p>\n Los equipos de ingenier\u00eda no pueden resolverlo solos.<\/p>\n Los equipos legales no pueden resolverlo solos.<\/p>\n Las organizaciones que avanzan m\u00e1s r\u00e1pido est\u00e1n tratando la CRA como una iniciativa de transformaci\u00f3n empresarial en lugar de como un proyecto independiente de cumplimiento.<\/p>\n Eso significa que el patrocinio ejecutivo, la gobernanza interfuncional, las responsabilidades claramente definidas y los procesos repetibles se vuelven tan importantes como los controles t\u00e9cnicos.<\/p>\n La conversaci\u00f3n se ampl\u00eda r\u00e1pidamente m\u00e1s all\u00e1 de la ciberseguridad hacia gesti\u00f3n de producto, calidad, operaciones, soporte al cliente, compras y gesti\u00f3n de proveedores.<\/p>\n El resultado es un cambio en la forma de pensar de la organizaci\u00f3n. Las empresas exitosas dejan de preguntar \u00ab\u00bfC\u00f3mo completamos una evaluaci\u00f3n de la CRA?\u00bb y empiezan a preguntar \u00ab\u00bfC\u00f3mo demostramos continuamente el cumplimiento durante todo el ciclo de vida del producto?\u00bb<\/p>\n Aunque el recorrido de cada organizaci\u00f3n es diferente, varios temas recurrentes aparecen una y otra vez.<\/p>\n Algunas empresas tratan la CRA como un ejercicio legal y esperan orientaci\u00f3n adicional antes de actuar. Otras suponen que las certificaciones existentes o los programas de seguridad maduros satisfar\u00e1n autom\u00e1ticamente los requisitos de la CRA. Muchas organizaciones dependen en gran medida de hojas de c\u00e1lculo y repositorios de documentaci\u00f3n desconectados para gestionar evidencias, solo para descubrir que mantener el cumplimiento con el tiempo se vuelve cada vez m\u00e1s dif\u00edcil.<\/p>\n Quiz\u00e1 el error m\u00e1s com\u00fan sea considerar el cumplimiento de la CRA como un proyecto puntual.<\/p>\n La realidad es que muchas de las obligaciones m\u00e1s importantes de la regulaci\u00f3n comienzan despu\u00e9s de que un producto llega al mercado. La gesti\u00f3n de vulnerabilidades, las actualizaciones de seguridad, la notificaci\u00f3n de incidentes, la gobernanza de componentes de software, los compromisos de soporte y el mantenimiento de documentaci\u00f3n contin\u00faan durante todo el ciclo de vida del producto.<\/p>\n El cumplimiento no es una meta. Se convierte en una disciplina continua.<\/p>\n Para las organizaciones que acaban de iniciar su recorrido con la CRA, los primeros pasos suelen ser menos complicados de lo que parecen.<\/p>\n Empiece por comprender su cartera de productos. Establezca responsabilidades claras. Clasifique adecuadamente los productos. Inventar\u00ede componentes y dependencias de software. Defina procedimientos de respuesta a vulnerabilidades. Identifique d\u00f3nde se crea la evidencia y d\u00f3nde se almacena.<\/p>\n Y, sobre todo, empiece a pensar en c\u00f3mo se mantendr\u00e1n estas actividades con el tiempo.<\/p>\n Las empresas m\u00e1s avanzadas no son necesariamente las que tienen los mayores presupuestos de seguridad. A menudo son las que han establecido procesos de gobernanza repetibles y creado un sistema de registro fiable para gestionar informaci\u00f3n de ciberseguridad de productos durante todo el ciclo de vida.<\/p>\n En futuros art\u00edculos analizaremos algunas de las lecciones m\u00e1s importantes que est\u00e1n surgiendo de los primeros esfuerzos de implementaci\u00f3n.<\/p>\n Examinaremos por qu\u00e9 la clasificaci\u00f3n de productos se est\u00e1 convirtiendo en uno de los primeros grandes obst\u00e1culos que encuentran las organizaciones. Analizaremos la creciente importancia de la gobernanza de la cadena de suministro de software y la visibilidad del software de c\u00f3digo abierto. Hablaremos de c\u00f3mo la CRA est\u00e1 transformando las relaciones con proveedores, por qu\u00e9 las obligaciones posteriores al lanzamiento est\u00e1n resultando m\u00e1s exigentes de lo que muchos esperaban y por qu\u00e9 los programas de seguridad maduros no se traducen autom\u00e1ticamente en preparaci\u00f3n regulatoria.<\/p>\n Y, sobre todo, nos centraremos en lecciones pr\u00e1cticas que responsables de producto, l\u00edderes de ingenier\u00eda, CISO, profesionales de cumplimiento y equipos ejecutivos puedan aplicar de inmediato.<\/p>\n La CRA sigue evolucionando, pero una cosa ya est\u00e1 clara: las organizaciones que empiecen hoy a desarrollar capacidades operativas estar\u00e1n en una posici\u00f3n mucho m\u00e1s fuerte que aquellas que esperen una claridad perfecta ma\u00f1ana.<\/p>\n Una ayuda durante el camino<\/strong><\/p>\n Un tema sigue apareciendo en casi todas las conversaciones sobre la CRA que mantenemos con clientes: la mayor\u00eda de los equipos puede crear una evaluaci\u00f3n inicial de seguridad. La parte dif\u00edcil es mantenerla actualizada.<\/p>\n Los productos evolucionan, el software cambia, aparecen vulnerabilidades, cambian los proveedores y las regulaciones maduran. Las organizaciones necesitan una forma de mantener un registro vivo del riesgo cibern\u00e9tico de los productos en lugar de depender de documentos est\u00e1ticos y hojas de c\u00e1lculo desconectadas.<\/p>\nLo que est\u00e1n aprendiendo los altos directivos<\/h2>\n
Errores comunes que seguimos viendo<\/h2>\n
Por d\u00f3nde deber\u00edan empezar las empresas<\/h2>\n
Qu\u00e9 cubriremos a continuaci\u00f3n<\/h2>\n