El pasado agosto, Microsoft publicó una actualización de seguridad de sus sistemas operativos, una más, como regularmente hace.

Podía haber pasado desapercibida, como tantas, pero esta era distinta a la mayoría. Se rompía la compatibilidad con ciertos componentes del sistema operativo ampliamente utilizados. Era la materialización de un hecho anunciado, el fin de las aplicaciones desarrolladas en Visual Basic 6.0 (VB6.0)

Muchas organizaciones no se plantean una política de actualización de sus sistemas operativos, ni analizan la conveniencia o no de aplicar un nuevo parche o corrector de programas. La mayoría tiene activada la opción de actualizaciones automáticas, de forma que en algún momento las actualizaciones se descargan solas y se instalan de forma desatendida, sin prestar la debida atención a lo que realmente esta sucediendo y el impacto que estas actualizaciones pueden tener sobre la operativa y el correcto funcionamiento de nuestros sistemas.

¿Por qué Microsoft rompió esta compatibilidad? Microsoft lleva muchos años anunciando el cambio de su tecnología. De hecho, Visual Basic .NET se lanzó en 2002 como sucesor de Visual Basic 6.0. Han pasado 17 años, y tras este largo periodo de tiempo, una inmensa cantidad de bien conocidas aplicaciones empresariales siguen en el mercado sin haber realizado el imperativo cambio tecnológico. Además, debido a su facilidad de desarrollo, la mayoría de aplicaciones propias o desarrolladas a medida por una organización, siguen a día de hoy desarrolladas con la tecnología de Visual Basic 6.0.

Microsoft rompió la compatibilidad por un problema de seguridad. Constantemente se descubren vulnerabilidades en los sistemas operativos, agujeros de seguridad que pueden ser aprovechados por parte de un tercero para atacar nuestros sistemas dejándolos sin disponibilidad o comprometer la integridad del mismo, o la confidencialidad de sus datos.

La decisión fue, no la de reparar una tecnología obsoleta que seguramente hubiera supuesto igualmente un problema de compatibilidad, sino simplemente eliminar la parte que tenía el problema.

De este modo, no todas las aplicaciones desarrolladas con Visual Basic 6.0 dejaron de funcionar de golpe, pero sí que muchas quedaron afectadas y alguna determinada operativa no funcionaba. Microsoft publicó a los pocos días una nueva actualización para resolver algunos de los problemas causados, y también algunos desarrolladores buscaron alternativas para no utilizar los componentes afectados por la actualización, pero ambas son una solución temporal.

Y es una solución temporal por qué Microsoft dejará de publicar actualizaciones para Windows 2008 Server el 14 de enero de 2020. Es decir, los problemas de seguridad que se encuentren a partir de ese momento ya no serán corregidos en esta plataforma. También, y por si a alguien se le ha pasado, SQL Server 2008 ya no tiene actualmente soporte de Microsoft.

¿Alguien se ha peleado alguna vez con los objetos ActiveX en Internet Explorer? Seguro que la mayoría de nosotros, cuando intentamos cargar alguna página web, o cuando intentamos instalar un certificado digital, etc. Los objetos ActiveX forman parte de estos objetos de sistema operativo en los que constantemente se descubren agujeros de seguridad, y ante la posibilidad de una vulneración a través de Internet cuando estamos navegando “tranquilamente”, es el motivo de ir abandonando esta tecnología y sustituirla por otras que a día de hoy ofrecen unas garantías superiores. Y por ello, las aplicaciones Visual Basic 6.0 dejan de funcionar, ya que en muchas de sus operativas se basan en esta misma tecnología obsoleta por insegura.

Por cierto, que pronto dejaremos de pelearnos con los ActiveX de Internet Explorer. El fin de Internet Explorer y los componentes ActiveX es 31 de marzo de 2020.

Ante esta realidad la pregunta que debe hacerse una organización cuyos sistemas estén basados en Windows Server 2008, aplicaciones desarrolladas en Visual Basic 6.0, o Intranets que sólo funcionan con Internet Explorer, es, a partir de ahora no hacemos nada y convivimos con los riesgos de seguridad sin actualizarnos, o bien, empezamos un proyecto de modernización de nuestros sistemas.

Si optamos por la primera, debemos pedirle ya a nuestro departamento de TI o al informático que nos mantiene el sistema, que desactive las actualizaciones automáticas de nuestros equipos, decidiendo en cada caso si una actualización debe ponerse o no, y asumir que vamos a convivir con el riesgo de un potencial ataque informático, puesto que la vulnerabilidad de nuestros sistemas va a quedar más expuesta.

Algunas aplicaciones de gestión no son críticas, o no precisan de actualizaciones. Llevan años funcionando sin problemas, y si las necesidades de negocio no cambian, podemos pensar que no se requiere actualizarlas. Sin embargo, en otros casos no podemos plantearlo. Por ejemplo, un ERP o una simple aplicación de contabilidad, o una aplicación de nóminas, requieren un mantenimiento regular para adecuarse a nuevos requisitos fiscales o legales, y no actualizarlas es una opción complicada, puesto que significaría que para resolver nuevos requisitos tendríamos que optar por procesos manuales (cada vez más complicado en una administración tributaria que cada día más nos empuja a trabajar en línea con ellos) o bien subcontratar estos servicios.

Sin duda, la mejor decisión es actualizarse, y ponerse al día. Sin prisas, pero sin pausas.

Debemos evaluar nuestros proveedores de software e infraestructuras. Estar seguros de que si nuestro proveedor de ERP sigue ofreciendo una aplicación desarrollada en Visual Basic 6.0, nos a proveer una alternativa moderna en un tiempo razonable. Estar seguros que nuestro departamento de TI o nuestra informática externa, entiende y mantiene correctamente nuestros sistemas operativos, y si es precisa una actualización de nuestros servidores. Para ello, si la organización no dispone de los medios para realizar esta auditoría interna de sus aplicaciones e infraestructuras, puede contar con los profesionales externos que nos dedicamos a estas tareas de asesoramiento en TI.

En organizaciones que no hayan realizado una adecuación tecnológica en los últimos años, el cambio de tecnología puede ser un proyecto de envergadura, con un impacto considerable. No se cambia de servidores en unos días, y, sobre todo, no se cambia de ERP en unos días. Si nuestro fabricante de ERP, aplicación de nóminas, o cualquier otra aplicación empresarial no se ha puesto al día y no tenemos certeza de que vaya a hacerlo, tendremos que afrontar un proyecto que va a impactar significativamente en nuestra organización.

Una vez más, ponerse en manos de profesionales expertos va a ayudar a la organización a acometer estos cambios, de forma planificada y estableciendo una hoja de ruta de cómo conseguirlo, priorizando objetivos.

Así pues, hay que tomar una decisión. Seguridad u obsolescencia. No hacer nada no es una opción, de modo que hay que ir planteando ya cual va a ser la estrategia de nuestra organización y empezar a dar pasos para qué, de forma preventiva, nos pongamos paulatinamente al día en la tecnología que utilizamos y de la que nuestra organización cada día es más dependiente y que puede comprometer la continuidad del negocio.

F. Xavier Sala i Leseduarte, Socio Auren