MFA sin enforcement real en cuentas privilegiadas.
Lo que vemos: el admin tiene MFA "habilitado" pero como opción, no como requisito. Si llega un atacante con la contraseña (típicamente por phishing o filtración), la sesión se inicia sin segundo factor porque la política nunca lo exige.
Por qué pasa: Microsoft activa Security Defaults en tenants nuevos, pero al primer ajuste de Conditional Access los administradores los desactivan sin sustituirlos por políticas explícitas. MFA queda "disponible" en lugar de "obligatorio".
- Entrar a
Entra ID › Protection › Conditional Access - Crear política:
Require MFA for all adminsaplicada a los roles Global Administrator, Privileged Role Administrator, Conditional Access Administrator y similares - Excluir solo una cuenta "break-glass" con contraseña larga guardada en bóveda física
- Probar con un admin secundario antes de enforced en todos
Conditional Access ausente o demasiado permisivo.
Lo que vemos: usuarios pueden iniciar sesión desde cualquier país, en cualquier dispositivo, a cualquier hora, sin reto adicional. Esto es especialmente peligroso cuando la empresa solo opera en México pero el tenant acepta logins desde Vietnam, Rusia o Nigeria a las 3 AM.
Por qué pasa: configurar Conditional Access requiere planeación. Es más fácil "dejarlo abierto" que mapear flujos legítimos. Pero unos pocos baselines cubren el 90% de los riesgos.
- Bloquear países donde no operas (named locations + block policy)
- Requerir MFA fuera de la red corporativa (trusted IPs)
- Bloquear protocolos legacy (POP, IMAP, SMTP auth — vectores comunes de credential stuffing)
- Requerir dispositivo compliant para acceso a SharePoint/OneDrive corporativo
- Sign-in risk: bloquear sign-ins de alto riesgo automáticamente (requiere Entra ID P2)
Respaldos no verificados ni probados.
Lo que vemos: "Tenemos respaldos en OneDrive" o "Microsoft respalda todo". Ambas afirmaciones son parcialmente falsas y peligrosas. Microsoft tiene retention policies por defecto cortas (30 días para Exchange, 93 días para OneDrive) y no protege contra borrado por ransomware o acción maliciosa interna.
Lo que necesitas: un sistema de backup separado del tenant, con copia immutable y restauración probada.
- Implementar solución de backup específica para M365 (Veeam Backup for Microsoft 365, Datto SaaS Protection, AvePoint)
- Cobertura mínima: Exchange Online, OneDrive, SharePoint, Teams
- Retención mínima: 1 año. Idealmente 3–7 años para sectores regulados
- Backup immutable (no se puede borrar ni durante ransomware)
- Prueba mensual de restauración — un respaldo que no se prueba no es respaldo
Roles de Global Admin sin Just-in-Time.
Lo que vemos: el equipo TI tiene 3-5 cuentas con Global Administrator activo permanentemente "porque es más cómodo". Cada una es un blanco crítico. Si una de esas cuentas se compromete, el atacante tiene el tenant completo.
El principio: nadie debería tener Global Admin permanente excepto la cuenta break-glass. Para los demás, el rol se activa por demanda con MFA + justificación.
- Activar Privileged Identity Management (PIM) en Entra ID (requiere licencia P2)
- Convertir roles permanentes en eligible (elegible) en vez de active
- Configurar activación con: MFA + justificación + ticket + duración máxima 8 h
- Para tenants sin P2: usar cuentas separadas
nombre.admin@con uso exclusivo administrativo y monitoreo de uso
Defender en modo audit, no enforced.
Lo que vemos: Microsoft Defender for Office 365 está activado pero las políticas anti-phishing, anti-malware y safe links están en modo "reportar pero no bloquear". Detecta amenazas y las registra en el reporte, pero los correos siguen llegando al buzón del usuario.
Por qué pasa: al activar Defender por primera vez, las políticas vienen en audit para evitar falsos positivos. Si nadie las endurece después, se quedan así. El equipo TI ve métricas bonitas en el reporte pero el riesgo sigue intacto.
- Aplicar preset de seguridad Standard o Strict según tu apetito de riesgo (recomendado: Standard como mínimo)
- Configurar Safe Links para reescribir URLs en correos y Office
- Activar Safe Attachments con detonation sandbox
- Configurar Anti-phishing con impersonation protection para tu dominio + dominios de proveedores clave
- Revisar el Microsoft Secure Score mensualmente — objetivo: > 70%
SharePoint con sharing público heredado.
Lo que vemos: documentos compartidos por correo con "cualquier persona con el link" hace 3 años todavía son accesibles públicamente. No se sabe quién tiene los links. No expiran. Si un ex-empleado guardó alguno, sigue funcionando.
El riesgo: exposición silenciosa de información sensible que ni el propietario del archivo recuerda haber compartido.
- Configurar nivel de sharing global a "Solo personas autenticadas" como default (SharePoint Admin Center)
- Política de expiración automática de links anonimos (30/60 días máximo)
- Generar reporte de "Anyone links" existentes y revisar uno por uno
- Para sites sensibles: deshabilitar sharing externo completamente y usar canales privados
- Activar etiquetas de sensibilidad (Sensitivity Labels) para clasificar y proteger automáticamente
Sin retención legal en buzones críticos.
Lo que vemos: cuando un empleado renuncia, su buzón se elimina junto con su cuenta. Si meses después aparece una disputa legal, revisión fiscal o investigación interna que requiere correos suyos — no hay manera de recuperarlos.
El requisito legal: en México, la Ley General de Sociedades Mercantiles y reglas del SAT requieren retención de comunicación contable y fiscal por mínimo 5 años. Para sectores regulados (financiero, salud, educación) puede llegar a 10 años.
- Activar Retention Policies en Purview con duraciones acordes a tu sector
- Para empleados que salen: convertir el buzón en Shared Mailbox (gratis, no requiere licencia) antes de eliminar la cuenta
- Activar Litigation Hold en cuentas de directivos y áreas con riesgo legal (compras, ventas, RRHH)
- Auditar trimestralmente que las políticas se están aplicando (Compliance Manager)