Las políticas de ciberseguridad sólidas siempre han sido importantes. Con el estado interconectado de las empresas modernas —incluidas las universidades—, los líderes de TIC están más preocupados que nunca. Esta marea creciente también ha provocado un pánico equivocado y una apuesta condenada por cubrir todas las bases con algunos subproductos desafortunados.
Muchos piensan que no hay alternativas al carrusel de pagar el “impuesto” anual de mantenimiento y aplicar parches de seguridad disruptivos continuos. Esto ignora la naturaleza del panorama moderno de amenazas a la ciberseguridad. Se debe comenzar por comprender que la mayoría de las firmas de software empresarial no son empresas de seguridad y probablemente nunca lo serán. Los parches de seguridad proporcionados por el proveedor de ERP generalmente son simples correcciones de errores. Casi siempre son una forma glorificada (y lucrativa) de código incorrecto.
Por lo general, los proveedores de software revisan los errores para determinar la validez y la importancia. Puede ser un proceso arduo y largo. Los proveedores deben identificar todas las áreas posibles donde se utilizó la biblioteca o base de código afectados, qué plataformas se ven afectadas y su historial. Entonces los proveedores pueden darse cuenta de que un error ha existido durante bastante tiempo, a menudo hasta 20 o incluso 30 años. De hecho, muchas veces el mismo problema se repara nuevamente años después, ya que es muy común “pasar por alto un detalle”.
Eventualmente se lanza un parche y aquí es donde comienza el verdadero dolor para las organizaciones. La aplicación de parches de seguridad suele ser un proceso largo y complicado, especialmente para las grandes plataformas. En ellas es probable que se rompan las personalizaciones hechas a causa de algunos de los subproductos inesperados del comportamiento de ese parche.
Puntos débiles en los parches de seguridad
Incluso si una empresa tiene una política de parchado inmediato (algo muy poco común; probablemente es anual o, en el mejor de los casos, mensual), puede pasar fácilmente un año antes de que el parche se descargue, instale, pruebe a través del entorno y finalmente se ponga en producción. Los clientes deben esperar a que se publiquen los parches, realizar pruebas de regresión rigurosas, ejecutar control de calidad, realizar pruebas de usuario final y reparar las cosas que los parches de seguridad rompen, multiplicadas por cada instancia de aplicación o base de datos. Todo esto consume mucho tiempo, es arriesgado, perturbador y costoso.
Y luego, cuando vuelve a aparecer algo muy similar, es hora de revivir toda la rueda de hámster. Los proveedores de software generalmente sólo restringen ciertos comandos. Éstos con frecuencia son reemplazados por el siguiente comando en la lista, y los clientes se ven obligados a repetir este ciclo cientos de veces.
Más allá de las cosas que se han parchado, piensa en los grandes casos de seguridad en los medios a lo largo de los años. Ninguno se resolvió con un parche de proveedor. Es más probable que las empresas afectadas hayan sufrido por la falta de atención a configuraciones débiles, amenazas internas, acciones administrativas laxas, políticas no aplicadas y similares. Estos modernos escenarios de amenazas están haciendo que los clientes de ERP se pregunten si están realmente seguros confiando en los parches de los proveedores para sus políticas de seguridad.
La realidad es que los parches de seguridad de los proveedores son complejos. Incluso cuando se aplican, tienden a tener un alcance limitado porque sólo abordan el problema que se descubrió y no abordan la debilidad en su conjunto.
Debe haber (y hay) una mejor manera.
El panorama de seguridad más amplio
Las soluciones de seguridad modernas abordan casi todas las enumeraciones de debilidades comunes aplicables, y no sólo los puntos de exposición individuales. Por ejemplo, en lugar de desmantelar un solo problema de inyección de SQL e introducir vulnerabilidades de sintaxis individuales (estrategia de parche del proveedor), las soluciones modernas mitigan las debilidades de inyección de SQL en su conjunto.
Hoy en día, los CISO requieren estrategias de seguridad modernas y más rentables, como protecciones de bases de datos en memoria o autoprotección en tiempo real para middleware y aplicaciones. Esas y otras técnicas modernas ofrecen formas mucho más efectivas y proactivas de abordar la higiene de la seguridad de pilas de software empresarial. Además, facilitan reducciones masivas en el tiempo de inactividad y la interrupción del negocio. Los CISO más inteligentes aprovechan el uso de estas tecnologías como un control común o control de compensación, según corresponda. Lo hacen para cumplir o superar las expectativas de los auditores de seguridad cuando la aplicación de parches de seguridad es demasiado impráctica o incluso imposible para la empresa.
