La Política de Actualización del Software (IV)

En la política de actualización del software se deben tener en cuenta algunos elementos importantes. En la segunda parte vimos el inventario del software de la compañía y el ciclo de vida con ejemplos en la tercera. En esta cuarta parte vamos a comprobar cómo las características del negocio pueden imponer otras condiciones a la hora de instalar actualizaciones.

Las necesidades del negocio

 

No todos los negocios tienen los mismos requisitos y necesidades con respecto a las actualizaciones del software. Vamos a ver unos ejemplos.

Las compañías de servicios de viajeros ferroviarios o aéreos tienen las fechas de vacaciones estivales o navideñas como periodos prohibidos para realizar cualquier cambio o modificación en las aplicaciones. El volumen de operaciones se incrementa considerablemente. El trabajo diario se concentra en las operaciones del servicio a los viajeros. Se evita aumentar la carga de trabajo de los operarios así como añadir otros riesgos inherentes a los nuevos productos.

Estas condiciones impiden realizar las actualizaciones periódicas siguiendo el calendario o “roadmap” de los fabricantes software, tal como vimos en la segunda parte. Cabe esperar que pasadas las fechas restrictivas, se acumulen los parches y las versiones disponibles que hayan salido durante ese periodo de tiempo. Algunos serán más necesarios e importantes que otros, habrá que decidir cuáles se instalarán, cuándo y cómo.

Otro caso. Las empresas de telecomunicaciones tamibién tienen sus limitaciones. Quisiera destacar las que dependen de los equipos electrónicos. Sirva como ejemplo un proveedor de servicios de fibra. Los nodos de la red están constituidos por el misma familia de modelos de routers. Cada router tiene redundancia basada en la doble unidad de control, manteniendo una activa y la otra en reserva. Esto permite mantener el router funcionando mientras primero se instala la nueva versión firmware en la unidad de reserva. Cuando la reserva está preparada, conmuta para ser la activa y tomar el control. La descarga del nuevo firmware ahora se realiza en la otra unidad. Finalmente, ambas unidades están actualizadas sin que haya habido cortes en el tráfico de datos de los clientes.
No obstante, a pesar de la redundancia de los equipos, la empresa debe ser muy cauta a la hora de permitir las actualizaciones del firmware. La red está formada por cientos de routers que deberían ser actualizados cada cuatro, seis o doce meses, según recomiende el fabricante. En estas condiciones hay que tener en cuenta:

• La descarga del firmware a los routers se realiza de forma remota a través de la propia red. Esto afecta al rendimiento y la capacidad de la propia red. Pudiendo alterar el tráfico de clientes
• Durante el proceso de actualización, las unidades de control dejan de ser redundantes. Los routers quedan más vulnerables a otros eventos que puedan ocurrir y afecten al rendimiento de la unidad de control activa.

Por lo tanto, se requiere un estudio más riguroso sobre cómo y cuándo actualizar el firmware de los equipos de red y las consecuencias que pueda tener este hecho en el servicio a los clientes.
La manera en que se establece un calendario, una lista de equipos o grupos de ellos para la actualización del software deberán ser las particularidades que se deben incluir en las políticas de actualización.

 

Actualizaciones de seguridad

 

Hemos visto, cómo según el tipo de negocio, las actualizaciones se pueden posponer unos meses. No obstante no se pueden evitar o retrasar aquellas versiones o parches que solucionan problemas de seguridad. Los fabricantes suelen indicar cuáles son. Es posible que haya que instalar durante las fechas vacacionales, los días de máxima carga de trabajo o en muchos equipos al mismo tiempo. Estas situaciones deben estar previstas, analizando el riesgo y la gravedad de las consecuencias dependiendo de la decisión que se tome.

 

Impacto en los servicios de TI

 

 En los ejemplos anteriores sobre los negocios hemos dado un salto cualitativo. Hemos pasado desde un ámbito más técnico hacia el impacto en el ámbito de los servicios. Será la gestión de servicios la que decida en estos casos y entramos de lleno en los proceso de gestión de cambio, tal como entiende ITIL. Pero estas cuestiones exceden las notas de este artículo.

 

Mantenimiento externalizado

 

Muchas compañías tienen el mantenimiento externalizado con empresas que ofrecen estos servicios. En la SLA deben constar cláusulas respecto a las actualizaciones. Todo lo expuesto a través de los casos anteriores deberá tenerse en cuenta en los contratos de mantenimiento y estar descrito de forma clara en las políticas de actualización.

L. F. Real

"Supervirus" para el futuro

Repasando los informes sobre ciberseguridad del año pasado me ha llamado la atención el crecimiento y la expansión de los “supervirus”. Un rimbombante nombre que trata de sostener cierta analogía con las superbacterias que, gracias a mutaciones selectivas, consiguen ser resistentes a los antibióticos.

Estos “supersoftware” maliciosos no son nuevos. Cuando he leído más sobre ellos, he encontrado documentos escritos hace unos pocos años que los describen y analizan.

Para explicar en qué consisten vamos a partir de la siguiente pregunta.¿Cómo puedo eludir el análisis y la acción de los programas antivirus?. La respuesta se antoja inmediata. Sabiendo que los programas antivirus analizan sobre los soporte de datos como los discos duros, podría esquivar el antivirus si fuese capaz de colocar el malware en un lugar donde éste no busque ni analice. Para demostrar la certeza de tal afirmación tenemos los nuevos tipos virus informáticos capaces de hacerlo.

Fileless Malware. Este es un tipo de programa malicioso que se instala en la memoria RAM de los ordenadores. Su eliminación es sencilla, se apaga el equipo y los datos de la memoria se borran, entre ellos, este programa. El problema surge cuando los ordenadores y servidores infectados no se pueden apagar de una forma tan simple ni tampoco en cualquier momento. Esto ocurre con los centros de datos o servidores que funcionan 24x7 todos los días del año.

Apagar los sistemas requiere una preparación más allá de apretar un botón o teclear “shutdown”. El procedimiento debe ser tal que minimice el impacto en los servicios. Si queremos que éste se mantenga el proceso de apagar servidores debe contar con la presencia de otros servidores redundantes adicionales que entren en funcionamiento en lugar de los principales. Además, tiene que continuar con los procesos de arranque y restablecimiento hasta alcanzar la actividad normal.

En estas situaciones de emergencia, el foco se pone en la eliminación del malware descuidándose otras tareas y acciones importantes. Cada una tiene sus propios riesgos que hay que tener encuenta para ser gestionados adecuadamente. Si los ciberdelincuentes han sido hábiles en la creación, el malware se podrá propagar de unos servidores a otros, con lo cual el problema crece exponencialmente en complejidad

 

Bootkit. Este malware se instala entre el firmware almacenado en los circuitos integrados de arranque de los ordenadores y servidores. Los antivirus no analizan este tipo de programas. Pero la infección tampoco es sencilla. El acceso a estos circuitos y la instalación del firmware requiere ciertos conocimientos técnicos.

Es una buena herramienta para el espionaje industrial. Empresas dedicadas al mantenimiento de los sistemas microinformáticos de otras compañías pueden manipular este tipo de circuitos para obtener información relevante.

No es la primera vez que se manipula firmware de dispositivos. Sólo hay que hacer una sencilla búsqueda en internet sobre el caso de manipulación de routers Cisco por la NSA; o los productos importados de China con su carga maliciosa oculta.


Para conocer mejor estos “supervirus” dejo las siguientes referencias.




“El Fileless malware se erige como la mayor amenaza para tu ordenador en 2019” David Hernández, 9 -12-2018. Computer Hoy en Facebook

“VENI, VIDI, VICI: Malware sin fichero” Publicado el 02-02-2017, por Asier Martínez (INCIBE)

“Bootkits: Atacando el arranque” Publicado el 07-07-2015, por Antonio López (INCIBE)

“¿Rootkit o Bootkit? Aclarando la duda de forma definitiva” Ilya Lopes 19 Aug 2014, (Welivesecurity)

“LoJax: primer rootkit de UEFI en uso que se descubre, cortesía del grupo Sednit” ESET Research 27 Sep 2018

Whitepaper:
“LOJAX: First UEFI rootkit found in the wild, courtesy of the Sednit group”

L. F. Real