Aprendizajes de Log4j: No se apresure a remediar
La mayoría de nosotros, compartiendo el rasgo de ser seres humanos, hemos experimentado lo que comúnmente se conoce como “ lucha o huida ”, una reacción física autónoma a menudo intensa que se manifiesta con un corazón acelerado, músculos tensos y palmas sudorosas. La reacción puede ir acompañada de una sensación de pánico, así como de una parálisis de decisión que hace que nuestra capacidad de pensar lógicamente sea prácticamente inexistente.
Las empresas tienen su propia versión de esta respuesta, desarrollada y perfeccionada a lo largo de años de responder a situaciones digitales amenazantes.
El riesgo para las empresas es similar al riesgo para los seres humanos. En los seres humanos, la activación excesivamente frecuente, intensa o inapropiada de la respuesta de lucha o huida está implicada en una variedad de condiciones clínicas. Es una forma abreviada de decir que pueden causar daños físicos reales. Desde el punto de vista empresarial, la invocación de una activación frecuente, intensa o potencialmente inapropiada de una respuesta de lucha o huida digital puede ser perjudicial para la salud del negocio, en particular en el ámbito de la seguridad.
Al igual que las conocidas “etapas del duelo”, hemos observado el surgimiento de “etapas de reacciones de seguridad” a lo largo de décadas de trabajo para mitigar las amenazas relacionadas con las aplicação y la infraestructura.
La importancia de elegir la respuesta correcta
Apresurarse a buscar una solución puede ser una de esas reacciones que, a largo plazo, no resulta la mejor respuesta. Tenga en cuenta que el primer parche lanzado para Log4j de Apache también era vulnerable , por lo que las organizaciones que se apresuraron a solucionarlo básicamente tuvieron que empezar de nuevo y volver a aplicar parches a todos sus sistemas.
Es en este punto donde me detengo y afirmo firmemente que no apresurarse a tomar medidas remediales no significa ignorar el riesgo o pecar de inactivo.
Es especialmente importante recordar esto porque no gestionar de forma responsable los datos que impulsan un negocio digital tiene consecuencias en el mundo real. A raíz de Log4j, la Comisión Federal de Comercio de Estados Unidos (FTC) advirtió que tomaría medidas contra las empresas del sector privado que no protegieron los datos de los consumidores expuestos como resultado de Log4j. ( ZDNet )
Por qué la mitigación es lo primero
La mitigación precede a la remediación por una razón, y una de las más importantes es abordar el instinto humano de “hacer algo” y apresurarse a realizar la remediación. La mitigación rápida también aborda la necesidad de ser administradores responsables de los datos de los clientes protegiéndolos de la exfiltración mientras se formula el plan de acción de remediación adecuado .
La mitigación debe ser la primera acción a tomar, especialmente cuando se trata de una vulnerabilidad tan generalizada que requerirá una exploración profunda de la cadena de suministro de software. La ubicuidad y la dificultad de descubrir dónde pueden estar escondidos los paquetes y componentes vulnerables probablemente estén detrás del hallazgo de que “las descargas vulnerables de #log4shell todavía alcanzaban el 46 % en general” el 4 de enero. ( Sonatipo )
La realidad de un mundo digital por defecto es que nuevas y traumáticas vulnerabilidades de seguridad seguirán perturbando el negocio y poniendo a prueba recursos que ya están sobrecargados. Debido a la naturaleza robusta de una cartera de aplicação empresariales (que a menudo abarca cinco generaciones de arquitecturas de aplicação distribuidas en el núcleo, la nube y el borde), debemos asumir que la remediación consumirá la mayor parte del tiempo y la energía. Por eso es tan importante una mitigación rápida. Alivia la presión y permite un enfoque más deliberado e integral para la remediación, un enfoque que incluye verificar que los parches publicados sean seguros y permitir que los desarrolladores actualicen, apliquen parches y prueben de acuerdo con los ciclos de lanzamiento existentes.
Las organizaciones deben asegurarse de tener puntos de control en todos los entornos que respalden la mitigación. La protección web y de API, la inspección de contenido y las capacidades de bloqueo en puntos estratégicos de control brindan una especie de “plataforma” para la mitigación frente a este tipo de vulnerabilidades generalizadas. Estos mismos puntos de control también pueden proporcionar información valiosa en forma de exposición de intentos de explotar dichas vulnerabilidades.
CONCLUSIÓN
La mayoría de nosotros recordaremos los simulacros de incendio de nuestra infancia, donde practicábamos cómo salir de la escuela de forma segura en caso de incendio. También practiqué simulacros de tornado y supongo que es probable que haya niños en todo el mundo que hayan practicado la preparación para terremotos o tsunamis. Tener un plan y saber cómo ejecutarlo puede ser fundamental para reducir el tiempo que se pasa en pánico cuando llega la noticia de una vulnerabilidad importante.
Así que no os asustéis. Utilice puntos de control estratégicos y concéntrese en la mitigación rápida para poder ejecutar una remediación específica .
Y recuerda, la práctica reduce el pánico . Planificar y ejecutar su propio “simulacro de incendio de seguridad” no es en absoluto una mala idea.