Las vulnerabilidades del ‘software’ suponen un riesgo para la infraestructura de la red

Como la crisis de Log4J puso de manifiesto, entender lo que hay en el software que desencadena sus aplicaciones es crucial para comprender su postura de seguridad. Algo que ocurre de igual manera en lo que respecta a sus servicios de red. La infraestructura de red de la empresa sigue teniendo mucho que ver con el hardware en el centro de datos, con la LAN y WAN, pero ahora está transicionando cada vez más hacia el software.

En esta era de las redes definidas por software, un número cada vez mayor de dispositivos de red no son más que software propietario que se ejecuta en un hardware de conmutación genérico o incluso en un simple servidor x86 con tarjetas de red adicionales. Este cambio de énfasis de lo duro a lo blando ha hecho que las pilas de software que ejecutan la red sean una nueva fuente de riesgo y preocupación para la ciberseguridad. La capacidad de las TI para ofrecer acceso a los servicios y, por extensión, la integridad de los datos de la empresa, se construye sobre una base de software de red y de gestión de red. Pero, ¿en qué se basan esos cimientos? Es probable que ni siquiera el equipo de redes lo sepa.

Veamos tres tipos diferentes de software de red que se encuentran en la empresa: de código abierto, propietario con código abierto integrado y totalmente propietario.

Código abierto que se conoce

Los componentes de red de software de código abierto (OSS) abundan -ClearOS, Open vSwitch, ONOS, DeNT, pfSense, SoNIC, Stratum, Untangle, por nombrar algunos- y las ofertas comerciales los envuelven. El número de opciones para la conmutación, el enrutamiento y la seguridad está creciendo, y los paquetes individuales están madurando. Añada además el conjunto mucho más amplio de herramientas disponibles para la supervisión y gestión de la red -Cacti, Checkmk, Nagios, Pandora, Prometheus, Zabbix- y el número de posibilidades aumenta drásticamente.

La cuestión es que las empresas, en su mayoría, no saben qué hay realmente detrás de todas estas herramientas. E incluso si alguna herramienta no cuenta con vulnerabilidad conocida, como log4j, ciertamente podría ser vulnerable al próximo compromiso que aparezca. Y podría haber un intervalo incómodamente largo entre el momento en que se encuentra un exploit de esa vulnerabilidad en la naturaleza y el momento en que la información llega a TI.

No todo el mundo va a auditar todo su código para averiguar si contiene componentes vulnerables, pero todo el mundo debería prepararse para hacer o consumir análisis de códigos automatizados en este tipo de sistemas. Gracias a un impulso del Gobierno federal estadounidense, pronto habrá una forma de descubrir qué código se utiliza: las listas de materiales de software (SBOM), que son listados detallados de todos los componentes que entran en un paquete de software, incluidos los componentes de terceros.

Código abierto que quizá no conozca

Considere que el OSS está probablemente escondido bajo las cubiertas de algún software propietario en su red. Esta fue una pieza importante en la trama de log4j: el OSS se ha utilizado en todo tipo de aplicaciones internas y comerciales. Los desarrolladores pueden saberlo, pero la gente del equipo de red probablemente no.

Lo mismo podría estar ocurriendo con todo tipo de herramientas y plataformas de red propietarias, con cualquiera de las decenas de otros proyectos de OSS de uso común: bibliotecas matemáticas, bibliotecas gráficas, bases de datos, etc. En nombre de la velocidad y la innovación, los desarrolladores de software ya no trabajan completamente desde cero; y es que un gran paquete de software puede apoyarse en decenas de otros.

Pilas de propiedad ocultas

A veces la dependencia oculta está en otro software propietario, no en un paquete de OSS. Consideremos las numerosas vulnerabilidades reveladas en la última década que afectan a las pilas comerciales TCP/IP: Ripple20, un conjunto de vulnerabilidades que afectan a la pila TCP/IP de Treck; Name:Wreck, un conjunto de vulnerabilidades que afectan, entre otras pilas, a Express Logic (ahora Microsoft) NetX y Siemens Nucleus Net time; y las pilas TCP/IP utilizadas en dispositivos IOT ampliamente desplegados. Este tipo de vulnerabilidad también puede afectar a la seguridad de la infraestructura de red.

Nadie está sugiriendo en este momento que cada departamento de TI pueda revisar cada línea de código en cada aplicación para detectar problemas de seguridad. Sin embargo, el Gobierno federal está tomando la delantera en algunos aspectos de este problema al exigir a los proveedores que atestigüen que siguen prácticas de desarrollo seguras o que muestren dónde no lo hacen, cómo mitigan los riesgos y cuándo lo harán. Y deben, cuando se les solicite, presentar un SBOM completo, algo que deberían pedir a gritos las compañías, sobre todo de aquellos programas sobre los que construyen su infraestructura de red.