El software rara vez es una propuesta \u00fanica.<\/p>\n
De hecho, es probable que cualquier aplicaci\u00f3n disponible en la actualidad deba actualizarse (o parchearse) para corregir errores, abordar las vulnerabilidades<\/a>y actualizar funciones clave en varios puntos en el futuro.<\/p>\n Dado que la empresa t\u00edpica depende de una multitud de aplicaciones, servidores y dispositivos de punto final en sus operaciones diarias, la adquisici\u00f3n de un s\u00f3lido plataforma de gesti\u00f3n de parches<\/a> identificar, probar, implementar, instalar y documentar todos los parches apropiados son fundamentales para garantizar que los sistemas permanezcan estables y seguros. <\/p>\n Al igual que con la mayor\u00eda de las herramientas tecnol\u00f3gicas, no todas las soluciones de administraci\u00f3n de parches se crean de la misma manera, y lo que una organizaci\u00f3n considera s\u00f3lido puede resultar inadecuado para otra. Sin embargo, una evaluaci\u00f3n que comienza con un enfoque en criterios clave espec\u00edficos (atributos y funcionalidades esenciales que probablemente ofrecer\u00e1n muchos proveedores, pero no todos) permitir\u00e1 a los equipos de TI reducir sus opciones mientras trabajan para identificar la mejor soluci\u00f3n para el parche de su organizaci\u00f3n. necesidades de gesti\u00f3n.<\/p>\n La capacidad de una herramienta de administraci\u00f3n de parches para mantener un inventario de todos los sistemas parcheables es esencial para administrar los parches en todos los niveles. La informaci\u00f3n vital para rastrear incluye:<\/p>\n El lugar donde reside el inventario (\u00bfes parte del sistema de parches o puede residir en un sistema de configuraci\u00f3n existente?) tambi\u00e9n es una consideraci\u00f3n importante. <\/p>\n Cuando se combina con procesos de integraci\u00f3n continua\/entrega continua (CI\/CD) en DevOps, el ciclo de vida del parche se convierte en parte del desarrollo de software para aplicaciones internas. Sin embargo, tenga en cuenta que los ciclos de vida de los parches pueden presentar dependencias complejas. Por ejemplo, en los sistemas operativos Linux, la plataforma debe determinar si se puede aplicar un parche o si se debe eliminar un parche existente antes de aplicar el parche nuevo, momento en el cual se puede reinstalar el parche original.<\/p>\n Para determinar el impacto de un parche en los sistemas existentes, una herramienta de administraci\u00f3n de parches debe ser capaz de implementar un parche para probarlo en un entorno cerrado. Esto deber\u00eda incluir la capacidad de habilitar el inicio de sesi\u00f3n a nivel de depuraci\u00f3n en las instalaciones de parches para garantizar que no se eliminen errores o determinar qu\u00e9 provoc\u00f3 una falla en caso de que lo fueran. Los encargados de la toma de decisiones tambi\u00e9n deben determinar si existe soporte para realizar pruebas en sistemas aislados, en un grupo piloto o, idealmente, en un entorno aislado para validar los parches.<\/p>\n Una soluci\u00f3n debe poder implementar parches en todos los sistemas previstos, lo que incluye determinar las pol\u00edticas de implementaci\u00f3n, los grupos y los m\u00e9todos apropiados para el elemento que se parchear\u00e1. Idealmente, una implementaci\u00f3n podr\u00e1 llamar a los scripts previos y posteriores durante la implementaci\u00f3n para abordar los servicios, el cierre de la aplicaci\u00f3n, los procesos de copia de seguridad o los puntos de control, las pruebas y el reinicio. Tambi\u00e9n debe haber un proceso de prueba completado antes de que el nodo se vuelva a agregar a la rotaci\u00f3n en el balanceador de carga.<\/p>\n Una herramienta de administraci\u00f3n de parches debe saber qui\u00e9nes son los cargadores y editores de confianza, ser capaz de validar el parche y admitir un dep\u00f3sito en el sitio de parches validados y confiables. Si bien el uso de repositorios distribuidos en el sitio es \u00f3ptimo tanto para el rendimiento como para la seguridad, el uso de repositorios del proveedor y en el sitio es la condici\u00f3n esperada. Cualquier herramienta que dependa \u00fanicamente del repositorio de un proveedor ofrece la situaci\u00f3n de almacenamiento menos deseable.<\/p>\n Una soluci\u00f3n de administraci\u00f3n de parches debe ser capaz de priorizar autom\u00e1ticamente o manualmente los parches para su implementaci\u00f3n. Si establecer la prioridad de los parches implica un proceso manual, es fundamental conocer la fuente de datos utilizada. Si el proveedor proporciona la prioridad, es esencial comprender c\u00f3mo el sistema de parches consume esta informaci\u00f3n. El uso de prioridad de proveedor, CVE y respuesta de emergencia cuando sea necesario (parches de d\u00eda cero) proporcionar\u00e1 a la empresa la soluci\u00f3n de administraci\u00f3n de parches m\u00e1s completa.<\/p>\n La aplicaci\u00f3n de parches puede utilizar un m\u00e9todo de escaneo con agente o sin agente. Los sistemas con solo m\u00e9todos sin agente tienen un impacto negativo en el rendimiento de la red y la CPU y, por lo tanto, son los menos deseables. Sin embargo, si bien se espera el uso de un agente, las soluciones que utilizan un enfoque con agente y sin agente brindan la mayor flexibilidad.<\/p>\n Una soluci\u00f3n de parcheo empresarial debe poder parchear aplicaciones de terceros, especialmente en computadoras de escritorio y port\u00e1tiles, ya que pueden ser un vector de virus, malware o ransomware. Obviamente, la capacidad de admitir todas las aplicaciones comunes de los principales jugadores (Adobe, Microsoft, etc.) no es negociable. Pero idealmente, el soporte de terceros ser\u00eda extenso e incluir\u00eda la capacidad de admitir la aplicaci\u00f3n de parches en las aplicaciones internas. <\/p>\n Dado que las empresas y organizaciones se ven obligadas a navegar por un panorama cada vez m\u00e1s traicionero de ransomware y otras amenazas cibern\u00e9ticas, identificar una soluci\u00f3n de administraci\u00f3n de parches efectiva es absolutamente fundamental para garantizar operaciones seguras y eficientes. Sin embargo, a medida que el espacio se ha llenado de proveedores, determinar qu\u00e9 soluci\u00f3n satisfar\u00e1 mejor las necesidades de una empresa espec\u00edfica solo se ha vuelto m\u00e1s complicado.<\/p>\n Es posible que no haya una \u00fanica soluci\u00f3n de administraci\u00f3n de parches para cada empresa, lo que hace que la selecci\u00f3n sea m\u00e1s un proceso que una simple elecci\u00f3n de proveedor. Sin embargo, cuando la b\u00fasqueda de una soluci\u00f3n de gesti\u00f3n de parches comienza con un \u00e9nfasis en los criterios clave que se consideran no negociables, los responsables de la toma de decisiones estar\u00e1n en una mejor posici\u00f3n para formular una lista corta de proveedores y soluciones con mayor probabilidad de satisfacer las necesidades de su organizaci\u00f3n. <\/p>\n \u00bfBusca m\u00e1s orientaci\u00f3n? Aseg\u00farese de descargar el informe m\u00e1s reciente de Syxsense y Gigaom: Criterios clave para evaluar la gesti\u00f3n de parches<\/a>.<\/p>\n <\/p>\nInventario<\/h2>\n
\n
Gesti\u00f3n del ciclo de vida<\/h2>\n
Prueba de parche<\/h2>\n
Implementaci\u00f3n de parches<\/h2>\n
Fuentes confiables<\/h2>\n
Priorizaci\u00f3n de parches<\/h2>\n
Arquitectura de parches<\/h2>\n
Soporte de terceros<\/h2>\n
Llevar<\/h2>\n