¿Actualizar o no actualizar?

Desde que comencé a trabajar donde estoy trabajando ahora, he estado en una lucha interminable con mi jefe y compañeros de trabajo con respecto a la actualización de los sistemas.

Por supuesto, estoy totalmente de acuerdo en que cualquier actualización (ya sea firmware, sistema operativo o aplicación) no se debe aplicar descuidadamente tan pronto como salga, pero también creo firmemente que debería haber al menos alguna razón si el proveedor la lanzó; y la razón más común generalmente es la reparación de algún error ... que tal vez no experimente ahora, pero podría experimentar pronto si no sigue el ritmo.

Esto es especialmente cierto para las correcciones de seguridad; Como ejemplo, si alguien simplemente hubiera aplicado un parche que ya había estado disponible durante meses , el infame SQL Slammergusano habría sido inofensivo.

Estoy dispuesto a probar y evaluar las actualizaciones antes de implementarlas; pero estoy totalmente en desacuerdo con el enfoque "si no está roto, entonces no lo toque" para la administración de sistemas, y realmente me duele cuando encuentro sistemas de producción Windows 2003 SP1 o ESX 3.5 Update 2, y la única respuesta que puedo obtener es "Está funcionando, no queremos romperlo".

¿Qué piensas sobre esto?
¿Cuál es tu política?
¿Y cuál es la política de su empresa , si no coincide con la suya?

¿Qué pasa con las actualizaciones de firmware (BIOS, almacenamiento, etc.)?
¿Qué pasa con las principales actualizaciones del sistema operativo (service packs)?
¿Qué pasa con las actualizaciones menores del sistema operativo?
¿Qué pasa con las actualizaciones de la aplicación?

Por supuesto, mi principal interés es actualizar los servidores, ya que la administración de parches de clientes suele ser más sencilla y existen herramientas y prácticas recomendadas para manejarlo.

La seguridad y la agilidad deben equilibrarse con la estabilidad y el tiempo de actividad al determinar su estrategia de parcheo. Su enfoque de retroceso para esto debería estar en la línea de 'Está bien, pero debe saber que ahora estamos en riesgo de que estos servidores se vean comprometidos y se roben nuestros datos, o que los servidores se vuelvan no funcionales' y 'Está bien, pero debe saber que esto afecta el soporte de nuestro proveedor para este sistema y la capacidad futura de que este sistema interactúe con nuevos sistemas'.

Contra la mentalidad a largo plazo de 'no está roto, no actualices', debes dejar en claro que:

• La migración de un sistema heredado sin parches que se ha retrasado a un sistema moderno es un proceso mucho más costoso y doloroso que la actualización gradual de ese sistema con el tiempo.
• El personal de TI experimentado y calificado busca activamente nuevas tecnologías y compañías que constantemente estén desarrollando sus sistemas de TI. Hay un costo en dólares muy real en el volumen de negocios, la pérdida de oportunidades y la pérdida de conocimiento cuando una empresa pierde su personal de TI altamente comprometido y creativo debido a que sus sistemas se estancan y se vuelven poco atractivos para trabajar. Entonces todo lo que te queda son los 'salvavidas'.

Espero que esto te brinde algo de influencia y la mejor de las suertes para convencer a los anteriores de que se tomen las cosas en serio. Como siempre, establezca un rastro en papel que demuestre que ha informado a la administración de los riesgos que están tomando.

Este es un debate interminable y las personas razonables no estarán de acuerdo. Si habla de PC de usuario, estoy de acuerdo en que deben actualizarse. Si habla de servidores, considere una política separada para los servidores que se enfrentan a Internet y los que no. No sé acerca de sus servidores, pero en mi entorno, tal vez el 10% de nuestros servidores tienen puertos abiertos a Internet. Estos servidores orientados a Internet tienen la máxima prioridad cuando se trata de parches de seguridad. Los servidores que no se enfrentan a Internet tienen menor prioridad.

Los gurús de la seguridad argumentarán que este enfoque es problemático porque si un hacker alguna vez ingresa a su red, los servidores sin parches permitirán que los exploits se desperdicien a través de la red como un incendio forestal y ese es un argumento razonable. Aún así, si mantiene esos servidores con conexión a Internet cerrados y configura correctamente su firewall para abrir solo los puertos que son absolutamente necesarios, creo que este enfoque funciona y a menudo se puede usar para apaciguar a los administradores que tienen miedo de los parches.

Si solo confía en Windows Update para los parches (no mencionó qué sistema operativo está ejecutando, pero soy principalmente un tipo de Windows, así que esta es mi referencia), eche un vistazo a las revisiones reales que se lanzan cada mes . Tengo algunos servidores que si ejecuto Windows Update en ellos me dirán que necesito más de 50 parches, pero si me desplazo por esos parches e investigo cada uno de ellos, veré que el 90% de los elementos que son parches no son de seguridad relacionados, pero corrigen errores que afectan los servicios que no ejecuto en ese cuadro. En entornos más grandes donde usa un sistema de administración de parches, es común revisar todo lo que se publica y solo molesta con lo que es absolutamente necesario y que generalmente representa aproximadamente el 10% de lo que Microsoft lanza.

Mi argumento es que este debate sobre "parchear o no parchear" sugiere que uno debe ser uno u otro lado cuando, realmente, esta es una gran área gris.

Solo puedo hablar de servidores, pero tenemos un régimen de 'Actualización trimestral', en cuatro fechas predeterminadas y anunciadas por año, agrupamos las solicitudes de actualización, las aplicamos a nuestro entorno de referencia, las ejecutamos durante un mes para probar la estabilidad y, si es bueno, implementar durante los siguientes n días / semanas. Además de esto, aplicamos una política de actualización de emergencia donde tenemos la capacidad de implementar en referencia, probar y lanzar actualizaciones urgentes dentro de un día o dos si la gravedad es tal, aunque esto solo se ha usado 2/3 veces en los últimos 4 años más o menos.

Este enfoque doble garantiza que nuestros servidores estén razonablemente actualizados, pero no estúpidamente, que las actualizaciones sean impulsadas por expertos en la materia (es decir, firmware, controladores, sistema operativo, personal de la aplicación) y no vendedores, pero también permite soluciones rápidas si necesario. Por supuesto, tenemos la suerte de tener muy pocos modelos de hardware diferentes en toda la empresa (<10 variantes de servidor) y plataformas de referencia considerables y actualizadas para probar.

He trabajado en diferentes empresas que tenían políticas en todo el proceso continuo de "aplicar parches lo antes posible, no nos importa si rompen algo que tenemos en funcionamiento; luego los retiraremos" a "nada se aplica sin dos semanas de prueba ". Ambos extremos (y puntos intermedios) están bien siempre que la Compañía comprenda las compensaciones .

Ese es el punto importante: no hay una respuesta particular correcta o incorrecta a esta pregunta; Se trata de equilibrar la estabilidad frente a la seguridad o las características de su entorno particular . Si su cadena de administración comprende que retrasar los parches para las pruebas puede hacerlos más vulnerables al malware, está bien. Del mismo modo, si entienden que aplicar parches tan pronto como estén disponibles puede no funcionar o incluso romper la configuración particular de su sistema, también está bien. Existen problemas cuando estas compensaciones no se entienden.

Mi punto de vista es que el mejor curso está prácticamente en el medio de tus dos extremos. Por ejemplo, ¿por qué desea desesperadamente actualizar ESX si no hay una razón demostrable para hacerlo, posiblemente rompiendo los sistemas de trabajo en el proceso? Claro que podría ser vulnerable si fuera público, pero no debería haber forma de que se pueda acceder directamente desde fuera de su red, entonces, ¿dónde está el riesgo? ¿Hay algún error o falta de características que realmente te presenten una razón para actualizar?

Actualizar por el bien, que es realmente lo que estás proponiendo ("pero podrías estar experimentando pronto"), incluso mientras afirmas que no, es un camino absurdo y peligroso para viajar. A menos que pueda presentar una razón real , a diferencia de alguna razón teóricamente posible, nunca convencerá a otros si se oponen a la actualización.

Si cree que hay una razón real para realizar una actualización, debe documentar los pros y los contras, y siempre hay contras, y presentarlos a los que están más arriba en el árbol. Bien documentado, debe haber poca resistencia. Si no puede proporcionar un argumento convincente, siéntese y piense seriamente en ese hecho.

Editar

Pensé que debería dejar en claro que veo una gran diferencia entre la aplicación de parches de seguridad y estabilidad requeridos en comparación con la realización de actualizaciones de software o sistema operativo. Lo primero que implemento después de las pruebas adecuadas. Lo último lo hago solo si hay un beneficio real.

Las actualizaciones de seguridad se envían a un servidor provisional, luego a la producción después de que han demostrado que no explotan las cosas. A menos que haya una verdadera emergencia de sueño (que he golpeado varias veces :(), en cuyo caso PRODUCCIÓN AHORA. Otras actualizaciones solo según sea necesario, después de pasar tiempo en la puesta en escena.

Creo que lo primero que debe hacer es "clasificar" las actualizaciones por gravedad y tener un cronograma de parches basado en la clasificación. No hay duda de que las correcciones de seguridad de día cero deben aplicarse de inmediato; mientras que Service Pack puede esperar después de evaluaciones cuidadosas.