Consejos realistas para la gestión de parches, Post-SolarWinds


La administración y las pruebas de parches son diferentes, exactamente iguales y completamente fuera de control. A continuación, se ofrecen consejos de los expertos sobre cómo gestionar parches en un momento de actualizaciones de program malicioso.

(imagen de Barbara Helgason, a través de Adobe Stock)

(imagen de Barbara Helgason, a través de Adobe Inventory)

«Si aún no sabía que el parche presenta riesgo, bueno … ahora lo sabe», dice Brad Causey, director ejecutivo de la firma de consultoría de seguridad y pruebas de penetración Zero Day Consulting.

Causey se refiere, por supuesto, al reciente ataque a SolarWinds que sacudió a la industria. Se utilizaron actualizaciones de application para el software package de gestión de pink Orion de SolarWinds para distribuir el troyano de puerta trasera Sunburst / Solarigate a unas 18.000 organizaciones en todo el mundo. (Nota: SolarWinds es, en sí mismo, también un proveedor de servicios de administración de parches de terceros. Sin embargo, esos servicios no parecen haberse visto afectados por los ataques recientes).

«Estamos introduciendo riesgo al tratar de reducirlo», dice Causey.

Sin embargo, esto no es algo nuevo, dice, y probar los parches antes de la implementación es una práctica recomendada estándar. Sin embargo, las pruebas de parches generalmente se realizan para evitar problemas operativos, no amenazas a la seguridad. Está destinado a detectar un cambio en la biblioteca de códigos que impide que se ejecuten otras tres aplicaciones para no detectar un troyano de puerta trasera.

Sin embargo, teniendo en cuenta los ataques Sunburst / Solarigate, ¿es hora de renovar los procedimientos de prueba de parches? ¿Cómo pueden los equipos de seguridad de la empresa abordar la gestión de parches de forma segura? Aquí hay consejos de expertos en seguridad sobre qué hacer ahora.

Ser realista.

Causey y otros dicen que un ataque a la cadena de suministro a la escala y la sofisticación de SolarWinds es desgarrador, pero eso no significa que las empresas deban reinventar por completo la gestión de parches. Más bien, los equipos de TI solo necesitan realizar algunas de las mejores prácticas que deberían haber estado haciendo todo el tiempo. Después de todo, la Institución Nacional de Estándares y Tecnología (NIST) establece directrices sobre la gestión de parches en SP 800-40.

El problema es que el SP 800-40 se actualizó por última vez hace ocho años y, según los cálculos del propio NIST, el número de vulnerabilidades por año ha triplicado desde entonces.

«Parchamos todo el tiempo. Siempre parcheamos», dice John Pironti, presidente de la consultora de ciberseguridad y riesgos IP Architects LLC.

La higiene de la seguridad, incluidos los parches, es una parte esencial de la defensa, dice Pironti. Sin embargo, dice, «Nos engañamos a nosotros mismos si pensamos que podemos defendernos contra un ataque de un estado-nación (como el incidente de SolarWinds) mientras seguimos publicando código a la velocidad que lo hacemos».

Curtis Franklin, analista senior de administración de seguridad empresarial en Omdia, dice que las empresas deben tener tecnología de administración de parches para ayudar a automatizar el proceso ahora, «porque en este momento ha ido más allá de la escala humana».

Siga confiando en los parches. Pero…

A pesar del reciente ejemplo de alto perfil de una actualización de software package malicioso, Pironti dice que las empresas no deberían rehuir la implementación de actualizaciones.

«Creo que nos estaríamos haciendo un flaco favor si empezáramos a desconfiar de los parches», dice. «Prefiero confiar en mis proveedores que cuestionarlos cuando hay un exploit en la naturaleza».

Sin embargo, dice que es justo pedir una mejor higiene de la seguridad en el ciclo de vida del desarrollo de software.

… Pídale al computer software que sea más confiable

«Hemos sido entrenados como sociedad para aceptar códigos defectuosos», dice Pironti. Si bien las regulaciones exigen que los productos de algunas industrias cumplan con ciertos estándares de seguridad y calidad, el software program empresarial no está regulado en gran medida. Pironti cree que en algún momento esto puede cambiar. «No se puede permitir que (las empresas de program) sean los barómetros de lo que es un riesgo aceptable e inaceptable», dice.

Mientras tanto, sugiere que las empresas hagan una pregunta a los proveedores de application y servicios antes de cualquier compra: ¿Qué está haciendo para garantizar la integridad de su código de terceros?

Cree un entorno de prueba que sea Razonable Representación de la realidad.

En un mundo suitable, su entorno de prueba sería una imagen reflejada perfecta de su entorno de producción. Representaría cada dispositivo, ejecutando cada versión de cada versión del sistema operativo y cada aplicación, en cada configuración compleja que pueda estar ejecutándose en su entorno en ese momento.

«Y tendrías que invertir en todo ese equipo que nadie united states y pagarle a alguien para que lo mantenga, ¿verdad?» señala Causey.

Más realista y asequible, sin embargo, dice, es crear un entorno de prueba que represente con precisión los sistemas que son los más críticos: aquellos que son utilizados por la mayor cantidad de usuarios, o los más críticos para las operaciones diarias, o que tocan el datos más sensibles.

Franklin, de Omdia, dice que muchas empresas logran crear un entorno de prueba que representa la mayor parte de sus puntos finales. «El problema está en sus casos extremos», dice.

Esos casos extremos pueden no ser un problema. Hasta que lo sean.

Franklin presenta un ejemplo:

Podría ser el sistema que imprime los conocimientos de embarque de los camiones que salen de su planta de fabricación. Y ejecuta una impresora de matriz de puntos que ha estado funcionando desde 1997. Y Charlie, en el patio de carga, sabe cómo presionar los botones de su computadora con Windows 98 para que imprima todos estos conocimientos de embarque para que todo fluya. Y ha decidido que es simplemente imposible volver a capacitar a Charlie en el transporte. Entonces no vas a hacerlo.

Y estaba bien cuando Charlie estaba obteniendo notas escritas a mano y escribiéndolas. Pero en algún momento, hace unos años, su representante de SAP dijo «ya sabes, podemos poner un conector que vaya de SAP al escritorio de Charlie». Así que ahora el escritorio de Charlie con Home windows 98 tiene un vínculo de regreso, probablemente a través de Online, a su instancia de SAP.

Ahora, de repente, la máquina Home windows 98 de Charlie es una vulnerabilidad. … Supongo que no tiene una máquina con Windows 98 en su laboratorio (de pruebas). Entonces, incluso si (Microsoft) lanzó un parche fuera de banda para Home windows 98, no podría probarlo.

Vas a tener algunos casos así. Y se vuelven mucho más numerosos y extraños en la atención médica.

Franklin dice que la mayoría de las empresas utilizan ampliamente el sandboxing. «Pero si son honestos consigo mismos, saben que no pueden aislar todo. Si lo están haciendo bien, aunque saben qué no pueden hacer una caja de arena «.

Utilice la herramienta adecuada para el trabajo.

Identificar esos casos marginales requiere ayuda. Hay muchos tipos de tecnologías que permitirán a las empresas ubicar y organizar esos activos de TI y una amplia variedad de herramientas que ayudan a que la administración de parches sea más sencilla. Por ejemplo:

Continúa en la siguiente página

Sara Peters es editora senior de Dark Examining y anteriormente editora en jefe de Organization Efficiency. Antes de eso, fue editora senior del Pc Protection Institute, escribiendo y hablando sobre virtualización, administración de identidades, leyes de ciberseguridad y una miríada de … Ver biografía completa

Anterior

1 de 2

Próximo

Lectura recomendada:

Más información





Enlace a la noticia original