La mayor parte del trabajo que mantiene la confiabilidad de un producto de seguridad es invisible. Los usuarios ven que se completó un escaneo, se bloqueó una amenaza, se aplicó una actualización durante la noche. No ven la plataforma subyacente. Los entornos de ejecución, las bibliotecas administradas, los controladores nativos y Windows Todos los requisitos deben mantenerse actualizados y funcionar conjuntamente en millones de puntos finales. Nuestra migración a .NET 10 es un ejemplo de cómo mantenemos esa plataforma en constante evolución, y es el tema central de este artículo.
Sería fácil llamar a estas actualizaciones tareas de mantenimiento y seguir adelante. Pero eso es subestimarlas. Nuestro código se ejecuta continuamente, con privilegios elevados, junto a algunas de las partes más sensibles de Windows .
Cada dependencia en nuestra pila tecnológica, desde el entorno de ejecución y las bibliotecas de terceros hasta los controladores nativos y los requisitos del sistema operativo, afecta el entorno en el que se ejecuta nuestro software. Cuando una cambia, todo lo que depende de ella también puede tener que cambiar.
El problema: las plataformas se quedan atrás al permanecer inmóviles.
En seguridad de endpoints, el terreno nunca deja de moverse. Windows La tecnología evoluciona. Las amenazas evolucionan. El hardware evoluciona, desde portátiles ARM64 hasta máquinas con mucha más memoria y almacenamiento más rápido que aquellas para las que se escribió nuestro código originalmente.
Una plataforma que se queda estancada no permanece igual. Se queda atrás. Cada vez que se omite una actualización de una dependencia o entorno de ejecución, aumenta la brecha entre el ecosistema que construimos y el que es estable hoy en día.
Un entorno de ejecución moderno, y en particular .Net 10, nos ofrece mayor seguridad, rutas de código más rápidas, menor consumo de memoria y diagnósticos más completos. Además, proporciona a nuestros ingenieros mejoras en el lenguaje y las herramientas que les permiten trabajar de forma más eficiente.
Lo que está en juego es especialmente importante para el software de seguridad:
- Una aplicación web se puede revertir con una implementación. El software ya instalado en el equipo del cliente no se puede revertir.
- Nuestro código se ejecuta con altos privilegios, junto con controladores del kernel y protecciones contra manipulaciones.
- Una regresión en tiempo de ejecución no afecta a un solo servidor. Tiene el potencial de afectar a millones de máquinas.
Por lo tanto, tratamos una actualización en tiempo de ejecución con el mismo rigor que una función de seguridad.
El desafío: todo se mueve en conjunto.
Malwarebytes para Windows no es un solo programa. Es un sistema coordinado: una interfaz de usuario, varios programas de larga duración Windows servicios, un instalador, un sistema de autoactualización, una interfaz de complementos y dependencias gestionadas por terceros.
Estos se sitúan por encima de los controladores nativos y nuestro motor de detección. La migración a .NET 10 cubrió las partes administradas de Malwarebytes mientras se deja intacto este núcleo nativo. Pero las diferentes capas aún tienen que funcionar juntas.
La migración debía cumplir varios requisitos a la vez:
- El código sensible a la seguridad debía comportarse de forma idéntica antes y después del cambio.
- Los controladores nativos y las capas de protección contra manipulaciones debían seguir funcionando correctamente con el código administrado.
- El proceso de instalación y actualización tuvo que desplegar los nuevos archivos de tiempo de ejecución y eliminar los antiguos.
- Los complementos y las dependencias de terceros debían seguir siendo compatibles.
- Existente Malwarebytes Las instalaciones debían seguir funcionando.
- Nuestro sistema de validación automatizada debía ser lo suficientemente exhaustivo como para poder confiar en el resultado sin necesidad de inspeccionar manualmente cada ruta.
El límite entre el código administrado y el código nativo merecía una atención especial. El código administrado en nuestros servicios se comunica con los componentes nativos a través de interfaces como P/Invoke y COM. Un cambio en tiempo de ejecución puede afectar sutilmente cómo estas diferentes partes de Malwarebytes Comunicarse y trabajar juntos.
Esas diferencias podrían no ser evidentes en una demostración. Quizás solo aparezcan en una máquina de cada 10 000. Lo importante es detectarlas antes que los clientes.
No todas las actualizaciones tienen el mismo aspecto.
Existen tres razones principales por las que actualizamos una dependencia: lo decidimos, la plataforma subyacente nos obliga a hacerlo o una vulnerabilidad nos lo exige. Cada caso tiene un plazo diferente.
Modernización electiva. Podemos optar por migrar a un nuevo entorno de ejecución, una nueva versión principal de una biblioteca o una nueva funcionalidad de la plataforma para aprovechar nuevas características, correcciones o mejoras de seguridad.
Cambios en la línea base. A medida que evolucionan los requisitos de la plataforma, algunas restricciones de compatibilidad antiguas pueden frenar la modernización. Por ejemplo, el cambio a .NET 10 nos permitió actualizar la línea base de la aplicación y adoptar un entorno de ejecución más nuevo y compatible. Como parte del mismo cambio, Windows Se ha dejado de dar soporte a la versión 7.
Parches obligatorios. A veces se descubre una vulnerabilidad en una biblioteca que distribuimos o en un sistema del que dependemos. El cambio ya no es opcional y el plazo no depende de nosotros. Lo que sí podemos controlar es nuestra preparación: las pruebas, el proceso de lanzamiento y la implementación gradual que nos permiten responder con rapidez sin generar nuevos problemas.
Existen diferentes motivos y diferentes plazos, pero cada caso requiere el mismo enfoque minucioso.
La migración a .NET: Por qué la hicimos
Migrar a .NET 10 ofrece Malwarebytes una base más segura, respaldada y capaz para Windows , con varios beneficios acumulativos:
Seguridad. Un entorno de ejecución moderno se beneficia del trabajo continuo de seguridad de Microsoft, que incluye configuraciones predeterminadas más seguras, criptografía más robusta y soluciones para errores de memoria e interoperabilidad. Al usar un entorno de ejecución con soporte activo de Microsoft, podemos seguir aplicando correcciones cuando se descubren vulnerabilidades.
Una base respaldada. Puede que no sea una razón glamorosa, pero .NET 10 nos mantiene en una plataforma respaldada y en desarrollo activo que está mejor alineada con las versiones más recientes de Windows Esto facilita la adopción de futuras correcciones, funciones y mejoras como trabajo rutinario en lugar de proyectos puntuales.
Diagnóstico y observabilidad. Las versiones modernas de .NET cuentan con herramientas de rastreo, métricas y diagnóstico de fallos integradas más robustas. En un producto de seguridad, es fundamental comprender el comportamiento del código en entornos reales. Un mejor diagnóstico nos ayuda a identificar y resolver problemas de fiabilidad.
Rendimiento y eficiencia de la memoria. Las versiones recientes de .NET han mejorado el compilador justo a tiempo, el recolector de basura y las bibliotecas principales. Nuestros procesos se ejecutan en segundo plano durante todo el día, por lo que su eficiencia y la gestión de la memoria son cruciales. Estas capacidades nos brindan más oportunidades para mejorar la eficiencia, aunque el impacto variará según el componente.
La migración a .NET: Cómo lo hicimos
El principio rector es simple: nunca avanzar más rápido de lo que permiten las pruebas.
Comenzamos aislando el trabajo en una rama dedicada. Reorientamos la plataforma y actualizamos todas las dependencias gestionadas para que el nuevo entorno de ejecución y el código base coincidieran en qué componentes debían incluirse.
Eso puso de manifiesto algunas de las consecuencias menos evidentes de la actualización desde el principio: bibliotecas que habían sido renombradas o integradas en el entorno de ejecución, archivos que ya no eran necesarios y otros nuevos que debían incluirse en su lugar.
La implementación es un aspecto que se suele pasar por alto y cuyos errores pueden resultar costosos. Una migración en tiempo de ejecución no se limita al código que se ejecuta, sino que también abarca lo que se almacena en el disco del cliente.
Nuestro servicio de instalación y actualización tuvo que aprender la nueva estructura de archivos del entorno de ejecución. Tuvo que eliminar las dependencias que ahora proporciona el entorno de ejecución, dejar de enviar archivos renombrados y entregar reemplazos de forma limpia tanto en instalaciones nuevas como en actualizaciones in situ.
Una correcta implementación marca la diferencia entre una actualización que los usuarios nunca notan y una que genera un problema de soporte.
Una vez que la compilación funcionó correctamente, la atención se centró en la validación.
La migración implicó:
- Pruebas automatizadas exhaustivas en todos los servicios, así como en las rutas de instalación y actualización.
- Validación de compatibilidad con configuraciones reales e instalaciones previas.
- Pruebas de rendimiento para detectar regresiones en el inicio, la memoria y el comportamiento de escaneo.
- Despliegue gradual y por fases, comenzando con poblaciones pequeñas y expandiéndose solo cuando los resultados demostraran que era seguro hacerlo.
- Monitorización continua y detección automatizada de regresiones sobre el terreno.
- Trabajo interdisciplinario en las áreas de plataforma, control de calidad, instalación y actualización, e ingeniería de lanzamiento.
“Nunca avanzamos más rápido de lo que permitían las pruebas. Cada puerta tenía que ponerse en verde por sí sola.”
La migración a .NET: Las ventajas y desventajas
Nada de esto fue gratis, y las decisiones implicaron concesiones deliberadas.
La desventaja de esta rama era la posible divergencia. Aislar la migración protegía el código base principal, pero cuanto más tiempo existiera esa rama, mayor sería el riesgo de que se desviara del desarrollo activo. Gestionamos ese riesgo mediante integraciones frecuentes, en lugar de dejar una fusión grande y arriesgada para el final.
La desventaja del despliegue fue la velocidad. El despliegue por fases también significó que los clientes recibieran la actualización más tarde que con un lanzamiento simultáneo. Aceptamos esa desventaja. La información obtenida de poblaciones más pequeñas nos permite detectar problemas antes de que la actualización llegue a un número mucho mayor de dispositivos.
La desventaja de la compilación anticipada (AOT) radicaba en la flexibilidad. Si bien la compilación anticipada puede mejorar el rendimiento al inicio, también puede limitar el comportamiento dinámico. La aplicamos de forma selectiva, componente por componente, en lugar de hacerlo de forma predeterminada en todas partes.
Qué significa la migración a .NET 10 para los clientes
El mejor resultado de las obras de infraestructura es que los clientes se beneficien de ellas sin tener que preocuparse por ello.
En .NET 10, esos beneficios para Malwarebytes Entre nuestros clientes se incluyen:
- Mayor fiabilidad en un entorno de ejecución con soporte completo y mantenimiento activo.
- Una base más segura que se beneficia de las continuas mejoras de seguridad de la plataforma.
- Acceso a nuevas funciones y correcciones de .NET.
- Mejor soporte para versiones más recientes de Windows .
- Las herramientas .NET más recientes pueden ayudarnos a desarrollar e implementar nuevas medidas de protección con mayor rapidez.
Lecciones que vale la pena recordar
Cada una de estas actualizaciones —el entorno de ejecución, las líneas base, los parches de seguridad— refuerza aún más las convicciones del equipo.
Las actualizaciones de plataforma son inversiones estratégicas en todo lo que se construye sobre ellas. La modernización también funciona mejor cuando es continua: cuanto más tiempo se queda obsoleta una plataforma, más difícil puede resultar la actualización posterior.
La automatización es especialmente importante para cambios de esta magnitud. Lo mismo ocurre con las pequeñas decisiones, a menudo poco llamativas, tomadas años antes, como mantener límites claros entre los componentes y contar con un proceso de fabricación que sepa con precisión qué se entrega.
Esos cimientos son los que hacen posibles cambios más grandes.
“La deuda técnica se acumula como la deuda financiera. La actualización más barata es la que nunca pospusiste.”
¿Qué sigue?
Ninguna actualización es una meta final. Cada una es un paso en un proceso más amplio: modernizar continuamente, de forma gradual y deliberada, para que la plataforma nunca se quede atrás. Los parámetros de referencia volverán a cambiar. Surgirán vulnerabilidades sin previo aviso. Todas estarán sujetas a la misma disciplina: las mismas pruebas, el mismo despliegue por fases y la misma evidencia antes de seguir adelante.
Esa disciplina es de lo que está hecho un producto en el que se puede confiar para que funcione todos los días, en cualquier máquina, sin pensarlo dos veces.
Malwarebytes para Windows en .NET 10 se lanzó en la versión 5.6.0. Es el último paso en un compromiso de larga data para invertir en la plataforma subyacente del producto, de modo que la protección que ofrece pueda seguir mejorando.
«Una de las mejores suites de ciberseguridad del mundo».
Según CNET.Lee su reseña →
