top of page
Foto del escritorLeverIT

5 Razones por las que podrías estar haciendo mal el Patch Management

Para entender bien esto de los parches comencemos por analizar que son los parches, porque existen, porque son tan importantes o ¿porque a veces si y a veces no?


Bueno, lo primero que hay aceptar es que el software es hecho por humanos y errar es de humanos. Por eso el software normalmente está lleno de errores y de posibilidad de mejoras.


También es difícil proyectar que el software funcione bien en diferentes ambientes, por ejemplo, con poca memoria o corriendo al lado de otros programas que usen recursos que el programador cree va a tener siempre disponible.


Desde luego se trata de planear lo mejor y probar en la mayor cantidad de ambientes posibles, pero al distribuirlo puede estar en millones de diferentes ambientes y ahí es cuando empiezan a aparecer problemas entonces el productor de software crea un parche que puede ser una nueva .dll o .exe o archivo que hay que cambiar; solo uno quizás dentro de ese gran software y no solo hay que hacer ese programa también hay que hacer un nuevo instalador.


Finalmente, este es un nuevo software, que también pasa por pruebas y luego se distribuye.


Pero recuerden, esto igual es un software... hecho por humanos.

Este también puede traer errores o faltas de cálculo, puede que ya no tenga conflicto con algún programa, pero ahora tiene con otro. Quizás el software original funcionó perfecto en tu máquina, pero puede que el parche no.


Entonces distribuir parches es una tarea como tal que puede ser manual o automática, pero decidir si se parcha o no y que procesos llevar para garantizar que no se afecte a la empresa es otra que puede ser más complicada.


Distribuir un parche a miles de máquinas de usuarios puede ser un problema logístico, (como hacer llegar pequeños paquetes a miles de Pc’s en diferentes sitios) y que puede causar un impacto por la gran cantidad de problemas “pequeños” Pero también causar una caída a un servidor al parcharlo puede ser otro gran problema.


Entonces para estudiar este problema dividamos las maquinas en 3 grupos:


  • Máquinas de usuarios normales que tienen software de oficina muy parecido y que si se caen el impacto no es muy grande, pero de las cuales hay una gran cantidad.

  • Maquinas normales de usuarios clave para el negocio.

  • Servidores



 

Errores comunes distribuyendo Software


Razón #1: Falta de conocimiento técnico


A nivel mundial faltan personas con conocimientos de tecnología y cuando la empresa dispone de personal las dedica a otras tareas que considera más prioritarias. Diferentes herramientas pueden ayudar a automatizar parte de las tareas. Tales como herramientas de monitoreo que descubran donde faltan parches, otra que lleve flujos de procesos avisándole a las personas encargadas que les falta realizar alguna tarea y otra que envíen de manera segura y eficiente los parches.


Razón #2: No probar el parche en ambientes de prueba parecido a donde se va a instalar.

Todo parche tiene probabilidad de fallar. Es posible que nadie haya probado ese parche en las características de nuestro ambiente. Se debe tener ambientes de pruebas y una estrategia para parchar progresivamente, no todos de golpe. Si algo sale mal al comienzo poder parar ahí y no tener muchos problemas.


Razón #3: Saturar la red enviando el parche desde una pc o servidor a cada una de las otras pcs.


Se pueden usar estrategias para que el parche se envía servidores cercanos a grupos de PCs y desde ahí se instale a esas áreas. En el caso de máquinas fuera de la red, es mejor enviar estos parches desde un server en internet con esquemas de seguridad de hashing y lleva publica privada que garantizan que el parche llega sin ninguna modificación y que realmente está autorizado por la empresa.


Razón #4: Parchar servidores o computadoras criticas sin un proceso formal de cambios.


Resumiendo, un proceso formal de cambios es un proceso que lleva varios pasos. Planeación del cambio, en el que se proponen fechas en las que se alistaría el parche, cuando se probaría, como se probaría, cuando se instalaría, si algo sale mal como se puede regresar al punto antes del cambio, como se probaría que quedo bien y los riesgos involucrados. Alguien debe revisar todo, en especial los riesgos y dar un concepto. Después, dependiendo de lo critico del cambio un concejo, o persona debe autorizar ese cambio. Estos procesos garantizan que varias personas de diferentes backgrounds participan en el cambio garantizando que el riesgo baja.


Razón #5: No parchar para evitar riesgos. Déjelo asi…


Cuando un servidor es crítico y la empresa no quiere que este un solo segundo parado prefiere no parcharlo. Cosa que en ciertos casos está bien. ¿Para que arriesgarse poniendo un parche que no es necesario, pero que pasa cuando un parche está cerrando un hueco de seguridad? Si no hay un proceso de cambios bien llevado, Puede pasar y pasa mucho que la empresa prefiere dejar el equipo sin parches de seguridad. ¿Eso quién se va a dar cuenta? Bueno hay programas que están buscando al azar o en direcciones usadas por otros programas que puerto está abierto y tratan de aprovechar un hueco de seguridad en ese puerto. Si de casualidad en esa máquina no está el parche, el hacker puede entrar y tomar control o instalar un ransomware.



 

¡Si necesitas Asesoría, podemos ayudarte!


Sabemos lo complicado que es implementar un marco de Ciber Seguridad. Comienza con nosotros desde las bases identificando los activos tecnológicos con los que cuentas.





20 visualizaciones0 comentarios

Comments


bottom of page