Administración de parches para evitar problemas como EternalBlue [cerrado]

Al igual que con los parches para las vulnerabilidades utilizadas por el ransomware, no hubo un impacto negativo descrito por Microsoft.

En una utopía, los administradores de sistemas estarían aplicando parches a los sistemas casi a diario. Sin embargo, en el mundo real, es todo lo contrario.

Es posible que algunas actualizaciones deban revisarse, de modo que no afecten negativamente la productividad de una empresa. Aunque es raro, algunas instituciones consideran que el tiempo de inactividad y la posible pérdida de trabajo son muy importantes.

Es posible que los sistemas no estén conectados a la red o que no estén conectados a un servidor corporativo que indique cómo implementar ciertas actualizaciones. Las computadoras portátiles son conocidas por estar atrasadas en los parches debido a su naturaleza portátil y no conectada.

Además, algunas instituciones pueden tener ciclos de parches, de modo que un parche puede ser público, pero no implementado durante un mes o más.

No hubo una excusa válida para el impacto del ransomware, ya que el parche y el aviso fueron públicos 17 de marzo, pero las vulnerabilidades se aprovecharon casi 2 meses después (12 de mayo) .

Puede leer el boletín de seguridad de Microsoft aquí: enlace

La respuesta es fácil, aplique los parches (de seguridad y críticos de calidad) tan pronto como estén disponibles en el proveedor, lo que implica que solo use plataformas compatibles con el proveedor (esto no siempre es fácil de verificar, por ejemplo, Ubuntu LTS proporciona parches de seguridad solo para un subconjunto de paquetes muy limitado.

Para las actualizaciones no críticas, depende de si desea continuar o planea rehacer los sistemas cada 3 años de todos modos.

Sasser ha sido el estándar de oro para las historias de precaución sobre parches. Se cree que se diseñó a la inversa a partir del parche mensual de abril y se lanzó dentro de una semana.

Eso sería abril de 2004. El concepto de generación automatizada de parches de parches ( enlace ) es lo peor. Escenario de un caso para una hazaña armada liberada. Las vulnerabilidades de Wormable en los servicios habilitados por defecto tienen una larga historia en Windows, y las organizaciones han tenido 13 años para organizar sus acciones en términos de parches oportunos.

El tiempo que llevó empacar un exploit ya armado es bastante largo. (aproximadamente 2 meses) Aún así, no hay excusa en muchos casos.

Microsoft también prueba sus parches todos juntos (es decir, sin excepciones a los parches no opcionales) las organizaciones usan filtros WSUS (normalmente) para restringir los parches a los parches críticos / de seguridad solamente. Esta es otra práctica que desaconsejaría en gran medida, esto significa que está ejecutando un conjunto de parches que hacen que sus sistemas sean especialmente vulnerables a la explotación del encadenamiento ( enlace ) además de disminuir la dificultad que tiene un atacante para elevar los privilegios después de que inevitablemente se incorporen a un sistema.

Si estuviera diseñando una política de parches, se aplicaría en todos los puntos finales dentro de las 72 horas posteriores a la publicación (inicie sesión en los dispositivos de punto final de usuario hasta que haya parcheado con un script de inicio de sesión / inicio). Además, sería una La estrategia de parches "todos" coincide con los procesos de control de calidad propios de Microsoft, por lo que no estoy sujeto a problemas por parches incompletos.

No está directamente relacionado, pero aquí hay una historia que podría explicar qué parches deben revisarse antes de aplicarse en entornos de producción. Había estado trabajando en una organización de tamaño mediano a grande que utilizaba tareas de producción automatizadas basadas en Microsoft Excel, y una gran cantidad de máquinas estaban involucradas en ese sistema de producción. Nada mal hasta allí. Como teníamos administradores conscientes de la seguridad, todas las máquinas ejecutaban un antivirus y las firmas de los antivirus se actualizaban todos los días, durante la noche.

Una noche, el archivo de firmas del antivirus contenía una detección falsa que puso en cuarentena una DLL requerida por Microsoft Office ... No se pudo producir nada durante toda la mañana, y la producción solo se reinició por la tarde porque tomó menos de media hora diagnosticar el problema, pero la mitad del día para que el equipo de soporte restaure la DLL en todas las máquinas. Puede que no parezca muy importante, pero como los productos contenían pronósticos del tiempo, los clientes no estaban especialmente contentos de no encontrarlos al comienzo del día laboral ...

Pero esa no es una razón para no aplicar un parche de seguridad al menos un mes después de que se haya hecho público.