jueves, 30 de abril de 2026

El paisaje del phishing en Q1 2026: AI contra AI

 Microsoft publicó su reporte de Q1 2026 sobre el threat landscape de email a finales de abril. Lo recomiendo leer entero, pero voy a contar lo que más me marcó.

Los volúmenes de phishing siguen subiendo. Eso era predecible. Lo nuevo es la calidad. Microsoft reporta crecimiento sustancial en correos generados con LLMs. La gramática perfecta, el tono profesional, la personalización por información pública del target — todo lo que antes era pista para detectar phishing, hoy es nivel base.

El problema con eso: los entrenamientos de awareness de hace tres años están obsoletos. “Busca errores ortográficos” ya no es señal. El correo phishing de hoy no tiene errores. “Busca tono extraño” ya no es señal. El correo phishing está bien escrito.

Lo que sí sigue funcionando como señal

Análisis de origen. Headers, dominios sutilmente alterados, infraestructura de envío. Defender for Office hace este trabajo bien. La pieza humana se reduce a “verifica antes de actuar en cosas inusuales”.

Análisis de contexto. ¿El CEO realmente te pide a ti, en este formato, en este momento, por este canal? Si rompe patrón, sospecha. La regla “si rompe patrón, valida por canal alterno” sigue válida.

Análisis de intent. Defender XDR ahora marca correos por intent — financial fraud attempt, credential theft, etc. La clasificación por intent es más útil que por superficie.

Lo que cambió en mi operación

Bajé las expectativas de que el usuario detecte el phishing. La línea de defensa principal ya no es “el usuario que duda”. Es la pila de detección automatizada: anti-spoofing, sandboxing, intent analysis, link rewriting con análisis dinámico. Si llega al inbox un phishing decente, asumo que un porcentaje de usuarios va a caer.

Subí la inversión en respuesta rápida post-click. Cuando un usuario hace click en un link malicioso, ¿qué pasa? La velocidad entre click y contención es lo que marca la diferencia. Defender XDR más Security Copilot reduce esto.

Capacitación distinta. Ya no enseño a “detectar phishing por errores”. Enseño a “validar por canal alterno cualquier solicitud financiera o de credenciales no esperada”. Es regla simple. La gente la sigue.

Para dónde va esto

La carrera entre phishing generado por IA y detección por IA va a definir el panorama de email security los próximos años. Es asimétrica — el atacante necesita pasar uno, el defensor necesita parar todos. Pero las herramientas defensivas están mejorando rápido también.

Mi predicción: en 2027 el email puro como vector va a perder relevancia frente a vectores multi-canal (email más SMS más voz, con IA orquestando los tres). La defensa va a tener que cubrir el customer journey completo, no solo el inbox.

martes, 28 de abril de 2026

Agent 365 ya está GA: lo que pagas con esos 15 dólares al mes

 

THEFT

El contenido generado por IA puede ser incorrecto.

 

El 1 de mayo arranca la disponibilidad general de Agent 365. Quince dólares por usuario al mes. He visto comentarios mixtos en LinkedIn — unos dicen que es un robo, otros que es regalado. Como casi siempre, depende.

Voy a tratar de ser concreto sobre qué te dan por ese precio. Lo escribo aprovechando que estuve dos semanas haciendo el piloto en uno de los tenants donde tengo manos.

Lo primero: Agent 365 no es un producto, es un control plane. Esa distinción importa. No te da más capacidad de Copilot. Te da más visibilidad y control sobre los agentes que ya existen y los que vienen. Si tu organización no tiene aún muchos agentes desplegados, el ROI es difícil de defender el primer trimestre. Si tienes Copilot Studio en uso o gente experimentando con agentes locales, la cosa cambia.

Lo que viene en la caja a mayo 2026

Runtime Protection (preview). Esto es lo que más me interesa. Monitorea al agente en tiempo de ejecución. Si el agente hace algo raro — accede a un origen no esperado, llama un API que no debería, mueve un archivo a un lugar improbable — lo flaggea. Y, si tú lo configuras así, le revoca permisos automáticamente. Es la primera vez que veo a Microsoft tratar a un agente como tratan a un endpoint con Defender. Misma filosofía: comportamiento, no firma.

Network-Layer monitoring. Extiende los controles de Entra Internet Access a los agentes. Esto significa que las conexiones del agente pasan por la misma inspección que ya tienes para los usuarios. Lo más valioso es restringir destinos web aprobados. Si tu agente solo puede hablar con APIs de tu lista, los exfil exploits a la EchoLeak pierden el destino.

Shadow AI discovery. La pieza que más me sorprendió en el piloto. Defender + Intune detectan agentes locales corriendo en endpoints Windows. Empezó con OpenClaw. La hoja de ruta menciona explícitamente GitHub Copilot CLI y Claude Code. Es decir, Microsoft está poniendo en su radar a los agentes que corren fuera de su stack. Pragmático. Honesto. Necesario.

Centralización en una consola. Registro de agentes, permisos, propietarios, telemetría, alertas. Antes esto vivía repartido entre Entra, Defender, Purview y la consola de Copilot Studio. Ahora hay un sitio único. Que funciona razonablemente bien — algunos paneles aún cargan lentos, pero mejor que pelearse con cuatro pestañas.

The image shows a runtime alert with a message indicating that an AI agent, 'SalesBot-03', attempted to access an external API without authorization, and the system has subsequently revoked the permissions.

El contenido generado por IA puede ser incorrecto.

¿15 dólares por usuario al mes vale la pena?

Mi cálculo. Si tienes más de 500 usuarios con Copilot Studio activo y agentes en producción, el incidente que evitas con Runtime Protection paga el año completo. Si tienes menos de 100 y solo agentes “experimentales”, probablemente puedas esperar al refresh de cuatro o seis meses. El upside del precio es que escala sin que pagues por agente — pagas por usuario humano. Para una empresa donde un humano tendrá pronto seis o siete agentes ejecutándose en su nombre, es un modelo razonable.

Lo que me incomoda del precio: te obliga a pagar por usuarios que ni tocan agentes. No hay tier para “solo licenciar a quienes los usan activamente”. Microsoft sabe que la curva de adopción va hacia arriba, así que apuesta por cobrar todo el rebaño. Aceptable, pero opaco.

¿Qué hago si fuera tú? Lo que hice yo: piloto de 90 días con un grupo controlado, métricas claras antes de empezar (cuántos agentes registrados, cuántas anomalías detectadas, cuántos shadow agents encontrados), y decisión basada en datos. Si el shadow AI discovery te encuentra en el primer mes diez agentes que no sabías que existían, el precio se justifica solo. Si te encuentra cero, igual te dice algo importante: o estás muy maduro o no estás mirando bien.

The image depicts a digital interface showcasing the Shadow Al Discovery tool, presenting a series of results including 'E', 'AIL', 'Agent 365', 'control plane', 'GitHub', 'Claude', 'Copilot CLI', and 'Code', with a note indicating that 12 local agents were found as unmanaged.

El contenido generado por IA puede ser incorrecto.

Ya veremos cómo evoluciona. Por ahora, prefiero tenerlo activo a no tenerlo.

sábado, 25 de abril de 2026

Identity Risk Scoring en Defender XDR para identidades de agentes

 

Defender XDR estrenó en abril identity risk scoring extendido a identidades de agentes. Antes el risk scoring se aplicaba solo a humanos. Lo de los agentes era un patch. Ahora es ciudadano de primera clase del modelo.

Voy a explicar qué cambia.

El risk scoring funciona como en humanos. Defender mira señales: ubicación geográfica anormal, accesos fuera de horario, acciones desviadas del patrón histórico, conexiones a destinos sospechosos. Combina señales en un score. Te alerta cuando un agente se comporta raro.

Diferencias con humanos

Los patrones son distintos. Un humano tiene ritmos circadianos. Un agente puede estar activo 24/7. La ausencia de ritmo circadiano no es señal sospechosa para un agente. Defender lo aprende.

La velocidad es distinta. Un agente puede legítimamente hacer 1000 acciones por minuto. La señal “muchas acciones rápidas” no aplica igual. Lo que sí aplica: cambio brusco respecto a la baseline del propio agente.

El contexto es distinto. Un humano tiene “manager”, “departamento”, “rol”. Un agente tiene “sponsor”, “scope autorizado”, “tipo de tarea”. El risk scoring de Defender ahora incorpora estos atributos en su modelo.

Lo que se ve en mi tenant

Detectó tres anomalías en el primer mes. Una era benigna — un agente cambió de comportamiento porque cambió su tarea, no estaba mal. Dos eran problemáticas — un agente que empezó a tocar datos fuera de su scope (mala configuración después de un update), y otro que empezó a fallar en patrones que sugerían que su modelo subyacente había sido cambiado sin aviso.

Ese segundo caso me marcó. Era un agente custom de Copilot Studio. Alguien del equipo de IA cambió el modelo subyacente sin avisar a seguridad. Defender lo detectó por el cambio en el patrón de respuestas. Me dio visibilidad sobre algo que estaba mal gobernado. Pude presentarle al equipo de IA evidencia técnica de por qué el cambio sin aviso no es OK.

Lo que ajusté en operación

Subí los thresholds para alertas críticas. Por defecto, Defender es ruidoso para agentes nuevos hasta que aprende la baseline. Las primeras dos semanas tuve más alertas que las que mi equipo podía triagear. Microsoft documenta esto, hay que esperar.

Conecté las alertas con tickets automáticos al sponsor del agente. Si un agente de María entra en risk alto, María recibe ticket. La accountability es del sponsor.

Empecé a usar el risk score en políticas de Conditional Access. “Si un agente está en risk alto, requiere re-autenticación de su sponsor humano antes de continuar acciones críticas”. Esto añade fricción a un agente comprometido, sin parar a los buenos.

Lo que me gustaría que mejoraran

Más explicabilidad en las alertas. A veces Defender dice “risk alto” sin explicar qué señales pesaron. Para investigación, necesito saber el por qué.

Integración con Entra Agent ID más profunda. Hoy hay puente, pero algunos atributos del agente no se reflejan en el modelo de risk. Espero que cierren ese gap.

Mi conclusión: risk scoring para identidades de agentes era el control que faltaba. Lo tienes activo, vas mucho más tranquilo. Si tienes agentes en producción y no estás monitoreando con risk scoring, es la pieza que más rápido te baja el riesgo de identidad de agente.

jueves, 16 de abril de 2026

La ventana de chat de Security Copilot dentro de Defender XDR

 

En el update de abril, Microsoft metió una ventana de chat de Security Copilot dentro de Defender XDR. Suena a feature pequeña. No lo es.

Antes, cuando un analista del SOC tenía un incidente abierto, vivía con dos pestañas: la del incidente y la de Security Copilot. Copiaba contexto entre ambas. Pegaba IDs, hashes, IPs, nombres de host. La fricción era constante. Yo medí un día cuántos clicks gastaba un analista L2 en una hora de triage cruzando Defender con Copilot. 437 clicks. Cuatrocientos treinta y siete.

Ahora el chat vive dentro del incidente. Le preguntas al modelo sobre el incidente abierto, sin copiar nada. El contexto ya está cargado.

Las preguntas que más se hacen mis analistas

“Qué dispositivos están afectados”. Te lo da con confidencias por dispositivo.

“Cuáles son las identidades comprometidas”. Lista, con riesgo asignado.

“Compárame este incidente con los tres últimos parecidos”. Aquí brilla. Antes esto era un script de búsqueda ad-hoc en KQL. Ahora una pregunta.

“Qué acciones recomendarías en orden”. Te las prioriza con justificación. No siempre acierta. Pero la lista te ahorra el primer borrador.

Lo que está mejor de lo que esperaba

La calidad de las respuestas con contextos largos. Defender tiene incidentes con cientos de eventos. La ventana de chat los resume bien. No vi alucinaciones graves en mis tres semanas. Vi imprecisiones — un par de veces dijo “endpoint X” cuando era “endpoint Y” — pero detecto bien con un segundo de revisión.

Lo que está peor de lo que esperaba

La latencia. Para incidentes grandes, la primera respuesta tarda 8 a 12 segundos. Después es más rápido. Los analistas se quejan del primer paso. Microsoft sabe, está prometido bajar.

Lo que cambió en mi operación

Bajé el tier 1 a la mitad. No despedí a nadie — los moví a tier 2. El modelo hace el triage inicial de muchos incidentes. Los analistas humanos validan y deciden las acciones complejas. Mi MTTD bajó algo. Mi MTTR bajó más.

Subí los criterios de las cosas que Security Copilot puede ejecutar autónomamente. Antes era todo “sugerir, humano ejecuta”. Ahora hay un puñado de acciones (aislar dispositivo confirmado, bloquear IP en blocklist conocida, deshabilitar cuenta en lista de acciones aprobadas) que el modelo ejecuta solo, con notificación. La auditoría duerme tranquila porque cada acción tiene log y razón.

Subió mi consumo de SCUs. Esto es importante. La ventana de chat es seductora. Los analistas la usan más. Y cada query gasta. Si no metes cost caps por usuario, el final del mes te va a sorprender. Yo los puse en la segunda semana después de que un analista corrió 600 queries en un turno. Útil. Caro.

¿Lo recomendaría? Sí. Es de las cosas que justifican Security Copilot por sí solas, si tu SOC tiene volumen. Si tu SOC trabaja 5 incidents por día, no se nota. Si trabaja 50, cambia tu vida.

Una cosa que pediría a Microsoft: poner el chat también en Sentinel con el mismo nivel de integración. Hoy la experiencia entre ambos es desigual. Mismo motor, distinta integración. Espero que en próximos updates lo cierren.

Al final, esto es lo que compras con Security Copilot incluido en E5: que esté ahí donde el analista ya está mirando. La integración es la mitad del valor del modelo.