El CIS Benchmark de Microsoft 365 explicado — Level 1, Level 2 y qué exige realmente
El CIS Microsoft 365 Foundations Benchmark v3.0 es el estándar de configuración mínima defensible publicado por el Center for Internet Security. No es una recomendación marketing — son controles específicos con dos niveles (L1 práctico, L2 robusto), agrupados en siete secciones. Qué incluye cada nivel, dónde difiere de SCuBA y de Secure Score, y por qué muchos PDFs de "auditoría M365" lo citan mal.
Qué es el CIS Benchmark
El Center for Internet Security es un non-profit fundado en 2000 cuya función es publicar configuraciones de referencia para sistemas — Windows, Linux, Kubernetes, AWS, Azure, Microsoft 365. La línea base para Microsoft 365 se llama CIS Microsoft 365 Foundations Benchmark; la versión actual es v3.0 (publicada 2024). Es gratis en PDF para uso interno y consultivo, con descarga desde [cisecurity.org/benchmark/microsoft_365](https://www.cisecurity.org/benchmark/microsoft_365).
A diferencia de SCuBA (emisor federal, ScubaGear como herramienta de evaluación incluida), CIS publica el documento — la implementación queda al consumidor. Empresas como Tenable, Rapid7 o el propio Microsoft Compliance Manager incluyen evaluadores que mapean contra CIS, pero no son del CIS directamente.
Los dos niveles
El benchmark divide cada control en dos niveles:
- Level 1 (L1) — controles considerados baseline operacional. Reducen riesgo material sin impactar significativamente la utilidad del producto para el usuario final. Diseñados para que cualquier tenant pueda aplicarlos sin un proceso de cambio extenso.
- Level 2 (L2) — controles de seguridad robusta para entornos sensibles. Pueden requerir trade-offs (productividad, costo, complejidad operativa) y se aplican selectivamente.
Un tenant que cumple L1 al 100% no es "completamente seguro" — es un tenant que pasó el piso. L2 es el techo defendible. Cualquier organización mid-market con datos regulados (financiero, salud, gobierno) debería apuntar a L2 en las secciones que aplican.
Las siete secciones
El v3.0 organiza ~140 controles en siete secciones principales:
1. Account / Authentication — políticas de password, MFA, conditional access, federation. Es la sección más densa.
2. Application Permissions — consents OAuth, registro de aplicaciones, permisos de service principals.
3. Data Management — DLP, sensitivity labels, retention policies, BYOD restrictions.
4. Email Security / Exchange Online — SPF, DKIM, DMARC, anti-phish, auto-forwarding, mailbox auditing.
5. Auditing — Unified Audit Log, retención, alertas.
6. Storage — SharePoint / OneDrive sharing, external access, version history.
7. Mobile Device Management — Intune, compliance policies, app protection.
Cada control tiene un número estable (e.g. `1.1.1` para "Ensure Security Defaults is disabled on Azure Active Directory" — donde "disabled" tiene sentido si tienes Conditional Access más granular configurado).
Cómo difiere de SCuBA y Secure Score
| | CIS M365 v3.0 | CISA SCuBA | Microsoft Secure Score |
|---|---|---|---|
| Emisor | CIS (industria) | CISA (US federal) | Microsoft |
| Scope | M365 + recomendaciones operativas | M365 estricto técnico | M365 + Defender + Azure AD |
| Forma del output | PDF con controles + niveles | Política con ID estable | Score relativo 0–100% |
| Mecanismo de evaluación | Manual o vía evaluador de terceros | ScubaGear (incluido) | Portal nativo |
| Granularidad | L1 / L2 | Una sola línea base | Por feature individual |
CIS es más amplio que SCuBA pero menos auditable (no hay ID estable como `MS.AAD.3.1v1` — los controles tienen números pero la versión evoluciona). Secure Score es más visible pero menos defensible ante un auditor — sube y baja con el catálogo de features de Microsoft.
Cómo simiriki lo trata
simiriki cita CIS M365 v3.0 explícitamente en la Posture Brief Page 3 como uno de los marcos de referencia primarios. Las 197 reglas en `packages/scan-core/src/registry.ts` mapean a controles CIS en los comentarios JSDoc, con el número de control del documento v3.0. La cobertura: L1 al 95%+, L2 al ~70% (algunos L2 — política de password complejas custom, registros de aplicaciones en Microsoft AppSource — no se evalúan vía Graph API y requieren validación manual).
El gap honesto que vale señalar: CIS L2 incluye controles operativos (training de usuarios, revisión documental trimestral) que ninguna herramienta puede evaluar automáticamente. Cualquier "auditoría CIS L2" que prometa cobertura 100% automatizada está mintiendo sobre el scope del framework.
Por qué muchos PDFs lo citan mal
Los errores comunes en PDFs de "auditoría M365" cuando referencian CIS:
1. Confundir L1 y L2. Reportar "tenant 92% en cumplimiento CIS" sin especificar el nivel — porque L1 y L2 son universos distintos de controles.
2. Citar v2.0 cuando v3.0 está activa. v3.0 cambió varios controles, eliminó algunos obsoletos, y añadió controles para Teams + Power Platform. v2.x ya no está actualizado.
3. Mezclar CIS con Secure Score. "Tu Secure Score subió, eso significa que tu cumplimiento CIS también" — falso. Son métricas distintas. Microsoft puede subir tu Secure Score por habilitar una feature que CIS no considera baseline.
Conclusión
CIS Microsoft 365 Foundations Benchmark v3.0 es el estándar más citado y, bien usado, el más útil para auditoría técnica de M365 en entornos regulados. La pregunta correcta a hacerle a tu MSP es: "¿qué versión del benchmark, qué nivel evaluaron, y dónde están las brechas L2 documentadas?". Si la respuesta es "92% de cumplimiento CIS" sin esa especificidad, no te están entregando una auditoría — te están entregando una métrica.
Lecturas relacionadas:
- [ScubaGear: la herramienta con la que CISA audita Microsoft 365](/blog/scubagear-cisa-auditoria-microsoft-365)
- [Microsoft Secure Score vs CISA CPG: qué mide cada uno](/blog/secure-score-vs-cisa-cpg)
- [Auditoría de Microsoft 365 para PyMEs mexicanas: la guía completa](/blog/auditoria-microsoft-365-pyme-mexico)
¿Tu empresa está protegida?
Diagnóstico gratuito de madurez digital en 5 minutos. Identifica riesgos antes de que se conviertan en incidentes.