No tome el informe Log4j de la Junta de Revisión de Seguridad Cibernética al pie de la letra



El hallazgo más significativo en el voluminoso informe de la Junta de Revisión de Seguridad Cibernética análisis de la vulnerabilidad Log4j es lo que no observó.

La junta «no tiene conocimiento de ningún ataque significativo basado en Log4j en sistemas de infraestructura crítica». Además, «la explotación de Log4j se produjo a niveles más bajos de lo que predijeron muchos expertos, dada la gravedad de la vulnerabilidad». Eso es notable ya que Log4j es una de las vulnerabilidades más graves de la última década.

Dado el uso generalizado de la biblioteca, es difícil aceptar que una gran vulnerabilidad como esta, identificada como «endémica», no causar ningún daño real a las infraestructuras críticas. Sin embargo, el informe que dice que no hubo incidentes significativos no es motivo para bajar la guardia. De hecho, tenemos que estar más atentos que nunca.

El informe reconoce que, a diferencia de, por ejemplo, las agencias gubernamentales que revisan los desastres de transporte, «no hubo un lugar del accidente o un vehículo dañado para inspeccionar, ni pruebas de estrés para realizar en equipos defectuosos, ni diagramas de cableado para revisar». Y dado que los propietarios y operadores de infraestructura crítica aún no estaban obligados a informar las infracciones al gobierno federal, existe un punto ciego significativo. Los hallazgos del informe son solo suposiciones y las organizaciones no deben sentirse reconfortadas por ellos.

Log4j permanece profundamente integrado en los sistemas de todo el mundo: es una de las pocas piezas de software program que tienen en común aplicaciones populares como Apache Struts, ElasticSearch, Redis, Kafka y otras. También se nos dice que durante la revisión de la junta, las partes interesadas de la comunidad identificaron «nuevos compromisos, nuevos actores de amenazas y nuevos aprendizajes».

Algo de esto representa la democratización de la programación de software program. Esto es algo bueno, pero debemos ser conscientes de que mientras tengamos software package, tendremos vulnerabilidades de software package.

Conociendo cada eslabón de la cadena

La protección contra los eslabones débiles en la cadena de suministro de software package requiere un conocimiento adecuado de cada eslabón de la cadena, un objetivo difícil de alcanzar. La mayoría de las organizaciones tienen prácticas de gestión de activos terribles, y es imposible proteger las tecnologías en la infraestructura cuando nadie está seguro de cuáles son esas tecnologías, dónde se almacenan y cómo se utilizan.

Siempre surgen nuevas herramientas y capacidades, y con las aplicaciones en la nube, es aún peor. Para las aplicaciones locales en la nube, los desarrolladores normalmente no ven como su responsabilidad rastrear qué componentes de software están en la mezcla. Su atención se centra en la producción, no en el abastecimiento. Y con las aplicaciones de software package como servicio (SaaS), existe una dependencia casi overall de que el proveedor externo haga lo correcto.

Incluso sin consecuencias que podamos señalar, Log4j ofrece una prueba más de que la seguridad de la cadena de suministro de computer software está fundamentalmente rota.

Qué hacer a continuación

Entonces, ¿qué podemos hacer para solucionarlo? El informe CSRB ofrece recomendaciones ricas en anécdotas. Son bien intencionados pero demasiado opacos para que las empresas los implementen en entornos del mundo real. Por ejemplo, se nos dice que «las organizaciones deben estar preparadas para abordar las vulnerabilidades de Log4j en los próximos años». ¿Pero cómo?

Hay pasos que las organizaciones pueden tomar. Una vez más, no hay garantías: la protección infalible es imposible. Pero los peligros se pueden contener y minimizar.

Primero, las organizaciones necesitan una mayor conciencia de todas las tecnologías en uso la gestión de activos es inútil sin un inventario de activos actualizado. Esta es una prioridad constante y requiere la aceptación de los desarrolladores. Casi todas las empresas utilizan computer software de código abierto, por lo que el inventario de activos debe extenderse hasta el nivel de dependencia. Esto no es pretty, pero puede ser una de las actividades más esenciales para llevar a cabo de manera efectiva.

Los desarrolladores y su software package son una cosa, sin embargo, en todas las empresas, los usuarios comerciales ahora implementan las aplicaciones que creen que son las mejores para hacer el trabajo. Es comprensible que los empleadores estén preocupados por la seguridad y el cumplimiento, pero la aplicación de mano dura (es decir, intentar bloquear el acceso) representa una propuesta perdedora para todos. La elección de aplicaciones de los empleados y la seguridad de la empresa no se excluyen mutuamente, y con las tecnologías ahora disponibles, van de la mano.

En el pasado, llamaríamos a este uso no autorizado de aplicaciones TI en la sombra, pero ahora hay un término mejor: aplicaciones inmanejables. Son muy comunes y fáciles de detectar porque no son compatibles con los estándares de identidad y seguridad. Las aplicaciones autorizadas por TI son bastante difíciles de vigilar las aplicaciones inmanejables son un desafío aún mayor.

En segundo lugar, debemos avanzar hacia una arquitectura de confianza cero. Este concepto está generando mucho revuelo, pero existen desafíos en la implementación de confianza cero para aplicaciones inmanejables. La implementación de la confianza cero requiere varias capas de controles. Tratar de aplicar principios de confianza cero a aplicaciones inmanejables que no admiten estándares de la industria como SAML (para autenticación) y SCIM (para agregar y quitar usuarios) es extremadamente difícil. Las aplicaciones que no se pueden administrar no se pueden agregar a una superficie protegida de confianza cero, ya que no admiten estándares de identidad. Un principio basic de confianza cero define quién puede acceder a un elemento de datos, aplicaciones, activos o servicios (DAAS). Las organizaciones deben asegurarse de incluir todas las aplicaciones comerciales, incluidas las que no se pueden administrar, en su estrategia de confianza cero, no solo aquellas que admiten estándares.

No hemos esquivado una bala con Log4j, y hay más días cero en camino. El informe CSRB debería servir como una llamada de atención para que las organizaciones de todo el mundo profundicen en su cadena de suministro de software para todos aplicaciones Las cadenas de suministro físicas han tenido esta atención durante mucho tiempo el computer software merece el mismo escrutinio.



Enlace a la noticia unique