Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C9g and C9gd instances, powered by AWS Graviton5 processors, are available in the Asia Pacific (Tokyo) region. AWS Graviton5 processors are the fifth generation of custom-designed CPUs, delivering the best price performance for compute-intensive workloads running on Amazon EC2.
C9g and C9gd instances deliver up to 25% better compute performance compared to AWS Graviton4-based C8g and C8gd instances. They are up to 30% faster for databases, up to 35% faster for web applications, and up to 35% faster for machine learning. These instances are built on the sixth-generation AWS Nitro System and are the first to feature the Nitro Isolation Engine, harnessing formal verification to provide mathematical assurance that customer workloads are isolated from each other and AWS operators, pioneering a new standard for mathematically proven cloud security.
C9g instances are ideal for workloads such as high-performance computing (HPC), batch processing, gaming, video encoding, scientific modeling, distributed analytics, CPU-based machine learning (ML) inference, real time analytics, and ad serving. C9gd instances offer local NVMe-based SSD block-level storage for customers running compute-intensive workloads that also require high-speed, low-latency local storage for scratch space, temporary files, and caches.
Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C9g and C9gd instances, powered by AWS Graviton5 processors, are available in the Asia Pacific (Tokyo) region. AWS Graviton5 processors are the fifth generation of custom-designed CPUs, delivering the best price performance for compute-intensive workloads running on Amazon EC2.
C9g and C9gd instances deliver up to 25% better compute performance compared to AWS Graviton4-based C8g and C8gd instances. They are up to 30% faster for databases, up to 35% faster for web applications, and up to 35% faster for machine learning. These instances are built on the sixth-generation AWS Nitro System and are the first to feature the Nitro Isolation Engine, harnessing formal verification to provide mathematical assurance that customer workloads are isolated from each other and AWS operators, pioneering a new standard for mathematically proven cloud security.
C9g instances are ideal for workloads such as high-performance computing (HPC), batch processing, gaming, video encoding, scientific modeling, distributed analytics, CPU-based machine learning (ML) inference, real time analytics, and ad serving. C9gd instances offer local NVMe-based SSD block-level storage for customers running compute-intensive workloads that also require high-speed, low-latency local storage for scratch space, temporary files, and caches.
C9g and C9gd instances are available for purchase in Asia Pacific (Tokyo) via Savings Plans, On-Demand, Spot instances, Dedicated instances, or Dedicated hosts. Level up your compute with AWS Graviton and get started today.
AWS Transfer Family SFTP Connectors now continue running file transfers while you rotate the credentials used to authenticate with remote SFTP servers. You no longer need to update the connector to point to a new secret version each time a credential rotates, removing a manual step and helping avoid failed transfers during the rotation window.
Connectors can now retrieve credentials from an ordered list of AWS Secrets Manager version stages, such as the current and previous versions, during authentication. The connector automatically tries each version in the order you specify and proceeds with the first that succeeds, so transfers continue uninterrupted as credentials are rotated on either side. You configure this when you create or update a connector, and the connector’s credentials must be stored in AWS Secrets Manager.
Support for continuing transfers during credential rotation is available in all AWS Regions where AWS Transfer Family SFTP Connectors are supported. To learn more, visit the AWS Transfer Family User Guide. Get started with AWS Transfer Family in the AWS Transfer Family console.
AWS Transfer Family SFTP Connectors now continue running file transfers while you rotate the credentials used to authenticate with remote SFTP servers. You no longer need to update the connector to point to a new secret version each time a credential rotates, removing a manual step and helping avoid failed transfers during the rotation window.
Connectors can now retrieve credentials from an ordered list of AWS Secrets Manager version stages, such as the current and previous versions, during authentication. The connector automatically tries each version in the order you specify and proceeds with the first that succeeds, so transfers continue uninterrupted as credentials are rotated on either side. You configure this when you create or update a connector, and the connector’s credentials must be stored in AWS Secrets Manager.
Support for continuing transfers during credential rotation is available in all AWS Regions where AWS Transfer Family SFTP Connectors are supported. To learn more, visit the AWS Transfer Family User Guide. Get started with AWS Transfer Family in the AWS Transfer Family console.
Amazon Elastic Container Service (Amazon ECS) now support non-critical Managed Daemons for ECS Managed Instances. You can configure a daemon as non-critical so that your mission-critical application tasks continue running uninterrupted, even when a daemon fails, stops, or becomes unhealthy.
Amazon ECS Managed Daemons lets you centrally deploy and manage software agents independently of application deployments to ensure consistent coverage and compliance across your container infrastructure. For some mission-critical applications, uninterrupted execution of application tasks may matter more than auxiliary daemon functionality like logging or metrics collection. With this launch, you can now configure a managed daemon as non-critical so that its failure does not cause your application tasks to churn. When a non-critical daemon task fails, stops, or becomes unhealthy, the container instance remains active, your existing application tasks continue running uninterrupted, ECS continues placing new application tasks on it, and instance registration is never blocked, so your tasks launch immediately even when the daemon fails to start. Amazon ECS emits an EventBridge event when a daemon task fails to start and records service action logs for both critical and non-critical daemons, giving you full observability into daemon health.
To get started, you can use AWS Console, CLI, CloudFormation, or AWS SDKs to create a non-critical daemon by setting the critical parameter to false when creating or updating a daemon. Non-critical daemons are available in all AWS Regions where Amazon ECS Managed Daemons are supported. To learn more, refer to our documentation page.
Amazon Elastic Container Service (Amazon ECS) now support non-critical Managed Daemons for ECS Managed Instances. You can configure a daemon as non-critical so that your mission-critical application tasks continue running uninterrupted, even when a daemon fails, stops, or becomes unhealthy.
Amazon ECS Managed Daemons lets you centrally deploy and manage software agents independently of application deployments to ensure consistent coverage and compliance across your container infrastructure. For some mission-critical applications, uninterrupted execution of application tasks may matter more than auxiliary daemon functionality like logging or metrics collection. With this launch, you can now configure a managed daemon as non-critical so that its failure does not cause your application tasks to churn. When a non-critical daemon task fails, stops, or becomes unhealthy, the container instance remains active, your existing application tasks continue running uninterrupted, ECS continues placing new application tasks on it, and instance registration is never blocked, so your tasks launch immediately even when the daemon fails to start. Amazon ECS emits an EventBridge event when a daemon task fails to start and records service action logs for both critical and non-critical daemons, giving you full observability into daemon health.
To get started, you can use AWS Console, CLI, CloudFormation, or AWS SDKs to create a non-critical daemon by setting the critical parameter to false when creating or updating a daemon. Non-critical daemons are available in all AWS Regions where Amazon ECS Managed Daemons are supported. To learn more, refer to our documentation page.
Starting today, Amazon Elastic Compute Cloud (Amazon EC2) P6-B200 instances accelerated by NVIDIA Blackwell GPUs are available in the AWS Asia Pacific (Hyderabad) Region. These instances offer up to 2x performance compared to P5en instances for AI training and inference.
P6-B200 instances feature 8 Blackwell GPUs with 1440 GB of high-bandwidth GPU memory and a 60% increase in GPU memory bandwidth compared to P5en, 5th Generation Intel Xeon processors (Emerald Rapids), and up to 3.2 terabits per second of Elastic Fabric Adapter (EFAv4) networking. P6-B200 instances are powered by the AWS Nitro System, so you can reliably and securely scale AI workloads within Amazon EC2 UltraClusters to tens of thousands of GPUs.
P6-B200 instances are now available in p6-b200.48xlarge size in the following AWS Regions: US West (Oregon), US East (N. Virginia, Ohio), AWS GovCloud (US-West, US-East), and Asia Pacific (Hyderabad, Mumbai) Regions. To learn more about P6-B200 instances, visit Amazon EC2 P6 instances.
Starting today, Amazon Elastic Compute Cloud (Amazon EC2) P6-B200 instances accelerated by NVIDIA Blackwell GPUs are available in the AWS Asia Pacific (Hyderabad) Region. These instances offer up to 2x performance compared to P5en instances for AI training and inference.
P6-B200 instances feature 8 Blackwell GPUs with 1440 GB of high-bandwidth GPU memory and a 60% increase in GPU memory bandwidth compared to P5en, 5th Generation Intel Xeon processors (Emerald Rapids), and up to 3.2 terabits per second of Elastic Fabric Adapter (EFAv4) networking. P6-B200 instances are powered by the AWS Nitro System, so you can reliably and securely scale AI workloads within Amazon EC2 UltraClusters to tens of thousands of GPUs.
P6-B200 instances are now available in p6-b200.48xlarge size in the following AWS Regions: US West (Oregon), US East (N. Virginia, Ohio), AWS GovCloud (US-West, US-East), and Asia Pacific (Hyderabad, Mumbai) Regions. To learn more about P6-B200 instances, visit Amazon EC2 P6 instances.
Starting today, Amazon Elastic Cloud Compute (Amazon EC2) P6-B300 instances are available in the AWS Asia Pacific (Jakarta) Region. P6-B300 instances provide 8xNVIDIA Blackwell Ultra GPUs with 2.1 TB high bandwidth GPU memory, 6.4 Tbps EFA networking, 300 Gbps dedicated ENA throughput, and 4 TB of system memory.
P6-B300 instances deliver 2x networking bandwidth, 1.5x GPU memory size, and 1.5x GPU TFLOPS (at FP4, without sparsity) compared to P6-B200 instances, making them well suited to train and deploy large trillion-parameter foundation models (FMs) including large language models (LLMs) with sophisticated techniques. The higher networking and larger memory deliver faster training times and more token throughput for AI workloads.
P6-B300 instances are now available in p6-b300.48xlarge size in the following AWS Regions: US West (Oregon), AWS GovCloud (US-East), US East (N. Virginia), Asia Pacific (Hyderabad, Jakarta, Seoul), and South America (Sao Paulo) Regions. To learn more about P6-B300 instances, visit Amazon EC2 P6 instances.
Starting today, Amazon Elastic Cloud Compute (Amazon EC2) P6-B300 instances are available in the AWS Asia Pacific (Jakarta) Region. P6-B300 instances provide 8xNVIDIA Blackwell Ultra GPUs with 2.1 TB high bandwidth GPU memory, 6.4 Tbps EFA networking, 300 Gbps dedicated ENA throughput, and 4 TB of system memory.
P6-B300 instances deliver 2x networking bandwidth, 1.5x GPU memory size, and 1.5x GPU TFLOPS (at FP4, without sparsity) compared to P6-B200 instances, making them well suited to train and deploy large trillion-parameter foundation models (FMs) including large language models (LLMs) with sophisticated techniques. The higher networking and larger memory deliver faster training times and more token throughput for AI workloads.
P6-B300 instances are now available in p6-b300.48xlarge size in the following AWS Regions: US West (Oregon), AWS GovCloud (US-East), US East (N. Virginia), Asia Pacific (Hyderabad, Jakarta, Seoul), and South America (Sao Paulo) Regions. To learn more about P6-B300 instances, visit Amazon EC2 P6 instances.
Microsoft lleva a ANDICOM 2026 una visión de la nueva frontera de la IA: personas y agentes redefiniendo cómo se organiza el trabajo
El 63% de los usuarios de IA en Colombia afirma que hoy realiza trabajos que no habría podido hacer hace un año.
El siguiente desafío será convertir esa capacidad individual en una nueva forma de operar, combinando personas y agentes sobre datos confiables, contexto de negocio y gobierno.
Cartagena, Colombia – La inteligencia artificial (IA) está entrando en una nueva etapa. Después de incorporarse al trabajo para ayudar a crear, analizar y resumir información, comienza a asumir tareas y participar de manera más activa en procesos. Este cambio plantea un desafío para las organizaciones: pasar de utilizar IA en actividades aisladas a rediseñar cómo se distribuye el trabajo entre personas, agentes, datos y sistemas.
Esta es una de las principales ideas que Microsoft propuso en ANDICOM 2026, cuyo lema, Unleashing the Power of AI, puso el foco en cómo aprovechar y escalar el potencial de esta tecnología. Para la compañía, la próxima fase de adopción estará marcada por la capacidad de las organizaciones para transformar procesos, roles y decisiones alrededor de una inteligencia cada vez más disponible.
Las señales de este cambio ya son visibles entre los trabajadores colombianos. De acuerdo con el Microsoft Work Trend Index 2026, el 63% de los usuarios de IA en el país afirma que actualmente realiza trabajos que no habría podido hacer un año atrás. Sin embargo, esa expansión de capacidades convive con una tensión: el 70% teme quedarse atrás si no adopta la tecnología rápidamente, mientras que el 46% considera más seguro concentrarse en los objetivos actuales de su empresa que rediseñar su manera de trabajar.
“La próxima frontera de la inteligencia artificial es la colaboración entre personas y agentes. Cuando la creatividad, el juicio y la experiencia humana se combinan con agentes capaces de actuar sobre datos y procesos, se crean nuevas oportunidades para innovar, acelerar la toma de decisiones y ampliar lo que las organizaciones pueden lograr. Las empresas que liderarán esta transformación serán aquellas que conecten personas, agentes y datos de forma responsable, convirtiendo el potencial de la IA en una ventaja competitiva real”, afirmó Marc Reguera, Worldwide General Manager Customer Engagement para Microsoft Fabric.
En esta visión, la Empresa Frontera representa un modelo organizacional en el que la IA se integra de manera más profunda a la operación, con inteligencia disponible bajo demanda y equipos formados por personas y agentes. Su lógica es la de organizaciones operadas con IA y lideradas por personas, donde la tecnología amplía la capacidad de analizar y ejecutar, mientras las personas mantienen la dirección, el criterio y la responsabilidad.
Este modelo también modifica la relación cotidiana de las personas con la tecnología. Dependiendo de la tarea, un trabajador puede actuar como autor, utilizando la IA como apoyo; como editor, revisando una propuesta generada por ella; como director, definiendo un objetivo para que un agente lo ejecute; o como orquestador, coordinando un flujo en el que intervienen distintos agentes. La clave está en determinar deliberadamente qué papel debe desempeñar cada parte.
Convertir la ambición de la IA en una ventaja empresarial medible
Llevar este modelo a escala exige una base tecnológica capaz de combinar dos elementos inseparables: datos confiables y contexto de negocio. Los datos proporcionan una base segura, actualizada y gobernada sobre la cual puede operar la IA; el contexto les da significado al incorporar las métricas, relaciones, reglas y procesos propios de cada organización. Ambos son necesarios para que la IA pueda operar de manera útil y confiable a escala.
Sobre esta base, Microsoft IQ articula las distintas dimensiones del contexto que necesita la IA para comprender y actuar dentro de una organización. Work IQ aporta conocimiento sobre cómo trabajan las personas; Fabric IQ, sobre cómo opera el negocio; y Foundry IQ, sobre el conocimiento que utilizan los agentes. A esto se suma Agent 365, que incorpora capacidades de observabilidad, administración y gobierno de agentes. En conjunto, esta arquitectura reúne personas, datos y agentes bajo un contexto compartido y gobernado para integrar la IA de manera más profunda a la operación.
Esta evolución también está ampliando quién puede construir tecnología dentro de una empresa. Con agentes capaces de traducir una intención de negocio en código funcional, la frontera entre el trabajador de información y el desarrollador comienza a hacerse más flexible. Un usuario puede iniciar una aplicación y un desarrollador profesional continuar posteriormente sobre la misma base tecnológica. El resultado es una nueva distribución de capacidades.
Liberar el verdadero potencial de la IA requiere conectar personas, agentes, datos, contexto y gobierno alrededor de resultados concretos. El propósito para las organizaciones debe ser integrar la IA de manera deliberada para ampliar capacidades, enriquecer la experiencia de empleados y clientes, rediseñar procesos de negocio y acelerar la innovación. El siguiente salto de la IA no ocurrirá únicamente en las herramientas que utilizan las personas, sino en la capacidad de las organizaciones para transformar la manera en que trabajan, deciden y crean valor.
Acerca de Microsoft
Microsoft (Nasdaq «MSFT» @microsoft) crea plataformas y herramientas impulsadas por la IA para ofrecer soluciones innovadoras que satisfagan las necesidades cambiantes de nuestros clientes. La empresa de tecnología está comprometida con hacer que la IA esté ampliamente disponible, de manera responsable, con la misión de empoderar a cada persona y a cada organización en el planeta para lograr más.
The post Microsoft lleva a ANDICOM 2026 una visión de la nueva frontera de la IA: personas y agentes redefiniendo cómo se organiza el trabajo appeared first on Source LATAM.
AWS Gateway Load Balancer (GWLB) now supports sending TCP Reset (RST) packets when a target becomes unhealthy, is deregistered, or when a flow’s idle timeout expires. This feature helps reduce traffic interruptions from minutes to seconds by enabling TCP endpoints to quickly detect failed connections and establish new TCP flows through healthy targets.
Previously, when a GWLB target failed, existing TCP connections would continue to be forwarded to the unhealthy target (aka fail-open behavior). Client and server applications could experience interruptions lasting several minutes due to TCP retry and exponential back-off mechanisms built in the TCP stacks of clients or servers. When this capability is enabled, GWLB sends TCP Resets in response to the incoming traffic, indicating to the sender that a TCP connection is no longer viable. This allows TCP endpoints to recover in quickly.
TCP Reset is not enabled by default to ensure backward compatibility. You can enable it per target group using the AWS Management Console, AWS CLI, or API. Three triggers are supported independently for generating TCP Reset: target becomes unhealthy, target deregistration (after connection draining), and TCP idle timeout expiry.
This feature is available for all new and existing Gateway Load Balancers in all AWS Regions where GWLB is available. There is no additional charge for using this feature.
To learn more, visit this AWS blog,and GWLB User Guide here and here.
AWS Gateway Load Balancer (GWLB) now supports sending TCP Reset (RST) packets when a target becomes unhealthy, is deregistered, or when a flow’s idle timeout expires. This feature helps reduce traffic interruptions from minutes to seconds by enabling TCP endpoints to quickly detect failed connections and establish new TCP flows through healthy targets. Previously, when a GWLB target failed, existing TCP connections would continue to be forwarded to the unhealthy target (aka fail-open behavior). Client and server applications could experience interruptions lasting several minutes due to TCP retry and exponential back-off mechanisms built in the TCP stacks of clients or servers. When this capability is enabled, GWLB sends TCP Resets in response to the incoming traffic, indicating to the sender that a TCP connection is no longer viable. This allows TCP endpoints to recover in quickly. TCP Reset is not enabled by default to ensure backward compatibility. You can enable it per target group using the AWS Management Console, AWS CLI, or API. Three triggers are supported independently for generating TCP Reset: target becomes unhealthy, target deregistration (after connection draining), and TCP idle timeout expiry. This feature is available for all new and existing Gateway Load Balancers in all AWS Regions where GWLB is available. There is no additional charge for using this feature. To learn more, visit this AWS blog, and GWLB User Guide here and here.
Starting today, customers can subscribe and manage flat-rate pricing plans programmatically using the AWS CLI, AWS SDKs, CloudFormation, CDK, or the PricingPlanManager API.
CloudFront flat-rate plans give you one monthly price covering global content delivery, WAF, DDoS, DNS, logging, and edge compute, with no usage-based overage charges regardless of traffic spikes or attacks. Previously, customers could only subscribe to flat-rate pricing plans using the console, which required manual steps when using the API or infrastructure as code (IaC) like CloudFormation to create and manage distributions. Now, customers can programmatically subscribe, upgrade, downgrade, and cancel flat-rate pricing plans using the API or IaC tools.
Paid plans support an optional two-phase activation flow: you first create the plan, then approve it to begin billing. This prevents you from being committed to charges before you confirm, and makes the API well-suited for automated workflows and agents that provision infrastructure on your behalf. Free plans activate immediately and don’t require approval. To learn more, refer to the Getting started with the PricingPlanManager API. There are no additional fees for using the API to manage flat-rate pricing plans.
Starting today, customers can subscribe and manage flat-rate pricing plans programmatically using the AWS CLI, AWS SDKs, CloudFormation, CDK, or the PricingPlanManager API.
CloudFront flat-rate plans give you one monthly price covering global content delivery, WAF, DDoS, DNS, logging, and edge compute, with no usage-based overage charges regardless of traffic spikes or attacks. Previously, customers could only subscribe to flat-rate pricing plans using the console, which required manual steps when using the API or infrastructure as code (IaC) like CloudFormation to create and manage distributions. Now, customers can programmatically subscribe, upgrade, downgrade, and cancel flat-rate pricing plans using the API or IaC tools.
Paid plans support an optional two-phase activation flow: you first create the plan, then approve it to begin billing. This prevents you from being committed to charges before you confirm, and makes the API well-suited for automated workflows and agents that provision infrastructure on your behalf. Free plans activate immediately and don’t require approval. To learn more, refer to the Getting started with the PricingPlanManager API. There are no additional fees for using the API to manage flat-rate pricing plans.
Amazon WorkSpaces Applications now supports Graphics G7 instances, powered by NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs and Intel Xeon Scalable (6th Gen) processors. G7 instances deliver up to 2.1× better performance for graphics-intensive workloads compared to previous generation G6 instances.
With Graphics G7, customers can stream demanding professional applications such as CAD/CAM, 3D rendering, scientific visualization, video editing, and AI-assisted design workflows at higher fidelity and frame rates. G7 instances feature 32 GB of GDDR7 GPU memory per GPU and 2.67× faster memory bandwidth, enabling streaming of larger, more complex 3D scenes and models. Six instance sizes are available, with 1 to 8 GPUs, vCPUs ranging from 8 to 192, and system memory from 32 GB to 768 GB.
Graphics G7 instances are available in US East (N. Virginia), US East (Ohio), and US West (Oregon). Additional regions will be added as availability expands.
Amazon WorkSpaces Applications now supports Graphics G7 instances, powered by NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs and Intel Xeon Scalable (6th Gen) processors. G7 instances deliver up to 2.1× better performance for graphics-intensive workloads compared to previous generation G6 instances.
With Graphics G7, customers can stream demanding professional applications such as CAD/CAM, 3D rendering, scientific visualization, video editing, and AI-assisted design workflows at higher fidelity and frame rates. G7 instances feature 32 GB of GDDR7 GPU memory per GPU and 2.67× faster memory bandwidth, enabling streaming of larger, more complex 3D scenes and models. Six instance sizes are available, with 1 to 8 GPUs, vCPUs ranging from 8 to 192, and system memory from 32 GB to 768 GB.
Graphics G7 instances are available in US East (N. Virginia), US East (Ohio), and US West (Oregon). Additional regions will be added as availability expands.
To get started, select a Graphics G7 instance when launching an image builder or creating a new fleet in the Amazon WorkSpaces Applications console. For more information on available instance types, see WorkSpaces Applications Instance Families. To learn more about G7 GPU capabilities, visit the EC2 G7 Instance Types page. For pricing details, see Amazon WorkSpaces Applications Pricing.
El colapso de la ventana de parche: Por qué la seguridad necesita un nuevo plano de control
Por: Igor Sakhnov, vicepresidente corporativo y director general de Azure Networking.
Durante décadas, los defensores de la ciberseguridad se han basado en un modelo en teoría sencillo: se revela una vulnerabilidad, los equipos de seguridad evalúan la exposición, prueban las correcciones disponibles, despliegan parches en producción y, en última instancia, cierran el riesgo antes de que los atacantes puedan explotarlo a gran escala.
Ese modelo refleja cada vez más un mundo que ya no existe.
Las empresas actuales operan miles de cargas de trabajo interconectadas en entornos híbridos y multicloud. Las aplicaciones críticas para la misión impulsan servicios generadores de ingresos, experiencias para el cliente y operaciones empresariales principales que no pueden tan solo desconectarse cada vez que hay una actualización de seguridad disponible. Al mismo tiempo, las vulnerabilidades se vuelven más visibles, distribuidas de manera más amplia y armadas más rápidas que nunca.
El resultado es una brecha creciente entre la rapidez con la que las organizaciones pueden remediar vulnerabilidades de forma segura y la rapidez con la que los adversarios pueden explotarlas. Es hora de replantearse cómo la industria aborda la seguridad durante el periodo crítico entre la divulgación y la remediación.
La ventana de parche se ha colapsado
La gestión tradicional de vulnerabilidades se basaba en la suposición de que los defensores podían moverse más rápido que los atacantes. En muchos casos, podían hacerlo.
Cuando se revelaba una vulnerabilidad, las organizaciones tenían tiempo para comprender el problema, evaluar los sistemas afectados, probar parches, coordinar ventanas de cambio y desplegar correcciones antes de que se produjera una explotación generalizada.
Hoy esa línea temporal se reduce con rapidez.
Las campañas de ataques modernas operan a escala de internet. La investigación en seguridad, las divulgaciones públicas, los exploits de prueba de concepto y la inteligencia de amenazas circulan a nivel global en cuestión de horas. Una vulnerabilidad anunciada por la mañana puede convertirse en el foco de esfuerzos activos de escaneo y explotación por la tarde.
Mientras tanto, las realidades operativas de los entornos empresariales no han cambiado. Las organizaciones aún deben:
Comprender la vulnerabilidad y su impacto empresarial.
Identificar los sistemas afectados en grandes fincas.
Evaluar dependencias y preocupaciones de compatibilidad.
Validar correcciones en entornos de prueba.
Coordinar los calendarios de despliegue.
Monitorizar regresiones y riesgos operativos.
No son señales de ineficiencia. Son salvaguardas necesarias para entornos críticos para el negocio. El reto es que, mientras los procesos defensivos todavía requieren de días o semanas, los plazos ofensivos se miden cada vez más en horas.
Eso crea uno de los periodos más peligrosos en la ciberseguridad moderna: la ventana entre la concienciación y la remediación.
La IA amplía el desafío del defensor
La IA ayuda a las organizaciones a modernizar operaciones, acelerar el desarrollo y mejorar los resultados de seguridad. Pero los mismos avances tecnológicos también cambian la economía de las operaciones ofensivas.
A nivel histórico, transformar una vulnerabilidad recién revelada en un ataque efectivo solía requerir una investigación manual exhaustiva y un profundo conocimiento técnico. Tanto investigadores como atacantes de seguridad necesitaban analizar documentación, comprender las condiciones de los exploits, estudiar el software afectado y desarrollar técnicas de ataque.
Muchos de esos pasos ahora pueden acelerarse.
Los flujos de trabajo asistidos por IA pueden ayudar a analizar la divulgación de vulnerabilidades, identificar posibles rutas de ataque, evaluar dependencias técnicas y resumir información técnica compleja mucho más rápido que los procesos manuales tradicionales.
A medida que estas capacidades se vuelven más accesibles, el plazo entre la divulgación y la explotación sigue comprimiéndose. El resultado es un desequilibrio estructural.
Los defensores son todavía responsables de proteger entornos enteros que pueden incluir miles de servidores, aplicaciones, bases de datos, contenedores y activos de red. Los atacantes solo necesitan identificar una única vía viable hacia la explotación.
Esta asimetría lleva a las organizaciones a plantearse una pregunta cada vez más importante: ¿Qué ocurre antes de que se despliegue el parche?
Por qué los enfoques de seguridad existentes quedan cortos
La industria de la seguridad ha invertido mucho en mejorar la visibilidad.
Hoy en día, las organizaciones tienen acceso a más datos de vulnerabilidades, inteligencia de amenazas, análisis y capacidades de detección que nunca. Las plataformas de seguridad pueden identificar con rapidez los sistemas afectados, priorizar la remediación y alertar a los defensores ante amenazas emergentes.
Estas capacidades son esenciales. Pero la conciencia por sí sola no reduce la exposición. Muchas organizaciones se encuentran en una situación en la que saben justo qué sistemas son vulnerables pero no pueden parchearlos de inmediato.
Por ejemplo, una aplicación crítica para el negocio puede requerir una validación extensa antes de poder desplegarse actualizaciones. Un sistema de fabricación puede depender de software que no pueda desconectarse durante las horas de producción. Un entorno regulado puede requerir procesos adicionales de pruebas y aprobaciones antes de poder implementar cambios.
En estas situaciones, el reto no es identificar el riesgo. El reto es reducir el riesgo mientras la remediación sigue en curso.
La visibilidad, la detección y la priorización ayudan a las organizaciones a comprender el problema. No siempre proporcionan un mecanismo para contener ese riesgo de forma inmediata.
A medida que los plazos de ataque continúan comprimiéndose, la industria necesita un enfoque complementario centrado en la reducción de exposición en lugar de tan solo en la conciencia de exposición.
Por qué la red emerge como el plano de control más rápido
Cuando una carga de trabajo no puede defenderse de inmediato, debe ayudar a proporcionar protección adicional. Cada vez más, las organizaciones recurren a la red.
A diferencia de los controles basados en endpoints, las protecciones a nivel de red operan alrededor de las cargas de trabajo en lugar de dentro de ellas. Esta distinción se vuelve en especial importante durante periodos de alto riesgo.
La red ya comprende los patrones de comunicación, los requisitos de conectividad, las relaciones de confianza y los flujos de tráfico. Se sitúa en una posición estratégica donde las organizaciones pueden influir en cómo interactúan los sistemas entre sí sin tener que modificar por necesidad las propias aplicaciones.
Esto crea oportunidades para reducir la explotabilidad mientras se llevan a cabo los esfuerzos de remediación. Las protecciones aplicadas por la red pueden ayudar a:
Restringir el acceso a sistemas vulnerables.
Limitar la exposición a posibles trayectorias de ataque.
Reducir las oportunidades de movimiento lateral.
Segmentar activos de alto riesgo.
Contener el radio potencial de la explosión.
Ajustar los controles de manera dinámica a medida que haya nueva información disponible.
Quizá lo más importante es que los controles de red pueden implementarse mucho más rápido de lo que los parches de software empresarial pueden validarse y desplegarse.
El objetivo no es evitar el parcheo. El objetivo es crear una capa significativa de defensa durante el periodo en que el parcheo aún no se ha completado.
A medida que la IA comprime el tiempo entre la divulgación y la explotación de vulnerabilidades, las organizaciones necesitan una capa defensiva que pueda actuar de inmediato, sin esperar a que se parchee cada carga de trabajo, que se modifique cada aplicación o que cada agente de endpoint entienda una nueva amenaza.
La red está posicionada de manera especial para convertirse en ese punto de control: ya se encuentra en la ruta de la comunicación, tiene visibilidad a través de cargas de trabajo heterogéneas y puede hacer cumplir protecciones de manera consistente, en grandes entornos, en la nube sin cambiar las propias aplicaciones. Más importante aún, los controles de red pueden ir cada vez más allá del simple bloqueo basado en IP, puertos y firmas hacia una aplicación adaptativa y consciente del contexto que limita el comportamiento específico del que depende un exploit mientras preserva el tráfico legítimo.
Consideremos una vulnerabilidad de denegación de servicio en HTTP/2: la guía provisional más segura puede ser desactivar HTTP/2 por completo hasta que los sistemas estén parcheados, pero eso puede tener un impacto significativo en la aplicación y en el rendimiento. Una respuesta más precisa consciente de la red y de la carga de trabajo podría limitar el comportamiento explotable—limitar flujos concurrentes, endurecer restricciones de solicitudes o limitar la velocidad patrones de conexión abusivos—mientras se mantiene el servicio disponible. Por eso la red se ha convertido en algo más que una capa de conectividad: puede servir como un tejido de aplicación programable y ubicuo que compra a las organizaciones el bien más valioso durante un día cero: el tiempo para parchear de forma segura.
En una era en la que las vulnerabilidades pueden ser utilizadas como arma en cuestión de horas, cada día de reducción de riesgos importa.
El auge de la seguridad adaptativa
La próxima evolución de la ciberseguridad tal vez no dependerá solo de políticas estáticas o procesos de respuesta manual. Los entornos modernos son tan solo demasiado grandes, dinámicos e interconectados.
Cada vez más las organizaciones necesitan sistemas de seguridad capaces de comprender el riesgo, evaluar el contexto y adaptar las protecciones a medida que cambian las condiciones. Este cambio apunta hacia una tendencia más amplia en la industria: la seguridad adaptativa.
Los sistemas de seguridad adaptativos buscan ir más allá de las reglas predefinidas hacia mejorar de manera continua la gestión de riesgos. En lugar de tratar todas las vulnerabilidades por igual, buscan comprender las condiciones específicas que hacen explotable un defecto y determinar la forma más eficaz de reducir la exposición. A un nivel general, estos sistemas deben resolver tres desafíos críticos.
Primero, deben comprender la vulnerabilidad en sí.
Esto requiere obtener información de avisos de seguridad, divulgaciones de vulnerabilidades, inteligencia de amenazas, investigación de exploits y otras fuentes para desarrollar una comprensión significativa de cómo opera una amenaza.
Segundo, deben correlacionar esa comprensión con entornos reales.
Una vulnerabilidad solo se convierte en un riesgo material cuando existen sistemas específicos, configuraciones, caminos de conectividad y condiciones de exposición. Comprender este contexto es esencial para determinar el riesgo real.
Tercero, deben traducir la inteligencia en acción.
La visión sin aplicación aporta un valor limitado. El objetivo final es reducir la exposición mediante controles que puedan aplicarse de manera rápida, consistente y a gran escala.
Se espera que la IA desempeñe un papel significativo a lo largo de este proceso, no solo como herramienta analítica, sino como tecnología habilitadora que ayuda a los sistemas de seguridad a comprender relaciones complejas y tomar decisiones informadas más rápido de lo que sería posible de otro modo.
Mirar hacia el futuro de la ciberseguridad
La industria de la ciberseguridad ha pasado décadas en mejorar la gestión de vulnerabilidades, el despliegue de parches y las operaciones de seguridad. Esas inversiones son todavía esenciales y seguirán como elementos fundamentales de la estrategia de seguridad de toda organización. Pero el entorno que nos rodea ha comenzado a cambiar.
Los atacantes se mueven más rápido. La infraestructura se vuelve más compleja. La IA comprime los plazos en todo el panorama de amenazas. En esta nueva realidad, las organizaciones no pueden depender tan solo de los parches.
El futuro de la ciberseguridad dependerá de la capacidad de una organización para reducir riesgos durante el tiempo entre la divulgación y la remediación. El éxito vendrá de combinar prácticas sólidas de gestión de parches con controles compensatorios capaces de responder a la velocidad de la máquina.
Las organizaciones que prosperen serán aquellas que traten la seguridad como un proceso continuo y adaptativo, en lugar de una secuencia de respuestas puntuales. La cuestión fundamental ya no es si surgirán vulnerabilidades. Lo harán.
La cuestión es con cuánta eficacia pueden las organizaciones protegerse mientras trabajan para eliminarlos.
A medida que el colapso de la ventana de parches sigue, la industria necesitará nuevos enfoques que complementen las estrategias tradicionales de remediación, reduzcan con rapidez la exposición y ayuden a los defensores a recuperar el recurso que se ha vuelto cada vez más escaso en la ciberseguridad moderna: el tiempo.
Microsoft invierte en capacidades nuevas e innovadoras, capaces de proporcionar protección inmediata frente a la tormenta, para dar a las organizaciones el tiempo necesario para validar y desplegar un parche permanente de manera segura, sin exponer su entorno a riesgos innecesarios.
