Cómo evaluar a los proveedores de DSPM: el marco de selección para compradores empresariales

La selección de una solución de gestión de la postura de seguridad de los datos es una de las decisiones de adquisición de mayor importancia que tomará un equipo de seguridad este año. Si acierta, obtendrá una visibilidad continua sobre dónde se encuentran los datos confidenciales, quién puede acceder a ellos y cuál es su nivel real de exposición. Si se equivoca, habrá adquirido un costoso panel de control que genera alertas ante las que nadie actúa. El reto radica en que todos los proveedores de este sector ofrecen demostraciones muy convincentes: motores de clasificación perfeccionados que analizan entornos de prueba cuidadosamente seleccionados, elegantes mapas de riesgo y integraciones enumeradas en una diapositiva. La brecha entre lo que se ve en la demostración de un proveedor y lo que se experimenta en producción es precisamente donde fracasan la mayoría de las adquisiciones de soluciones de gestión de la postura de seguridad de los datos (DSPM).

Esta guía ofrece un marco estructurado e independiente de los proveedores para evaluar las plataformas DSPM. Se basa en los criterios de evaluación que empresas de análisis como Forrester y Gartner utilizan en sus Magic Quadrant «Wave» y Magic Quadrant —detección, clasificación, análisis de riesgos, corrección, profundidad de integración y madurez operativa—, pero adapta dichos criterios a una metodología de puntuación práctica que su equipo puede aplicar durante la preselección y las pruebas de prueba de concepto. La guía sobre DSPM de la Cloud Security Alliance hace hincapié además en que una evaluación eficaz debe ir más allá de las listas de verificación de características para evaluar cómo se comporta una solución en su entorno de datos real, sus patrones de acceso y sus obligaciones de cumplimiento normativo.

Tanto si es usted un CISO que elabora un estudio de viabilidad, un DPO que analiza los requisitos normativos en materia de pruebas documentales, un ingeniero de seguridad en la nube que somete a pruebas de estrés la cobertura de las API, o un responsable de compras que calcula el coste total de propiedad, el marco que se presenta a continuación ofrece a cada parte interesada una línea de actuación clara dentro de un único proceso de evaluación unificado.

La puesta a prueba de la prueba de concepto

Las demostraciones de los proveedores son, por naturaleza, entornos optimizados. Los datos de prueba están limpios, las estructuras de permisos son sencillas y los modelos de clasificación se han ajustado para funcionar en los escenarios específicos que se muestran. Las evaluaciones de prueba de concepto eficaces deben incluir datos reales de producción y entornos SaaS a escala empresarial cuando sea pertinente, ya que los conjuntos de datos de prueba simplificados rara vez ponen de manifiesto los retos operativos, de visibilidad y de gobernanza que surgen en implementaciones complejas de Microsoft 365 y multicloud.

El problema del M365

He aquí un escenario que se repite en casi todas las evaluaciones de DSPM en las empresas: la demostración del proveedor analiza un sitio de SharePoint de prueba con unos cientos de documentos y permisos sencillos. La precisión de la clasificación parece excelente: más del 95 % de precisión en la detección de datos de carácter personal (PII), una puntuación de riesgo clara y un número mínimo de falsos positivos. A continuación, lo conecta a su entorno real de Microsoft 365.

Lo que el proveedor no le mostró es lo que ocurre cuando su escáner se encuentra con permisos anidados de Teams heredados a través de jerarquías de canales, sitios de SharePoint con enlaces de uso compartido complejos («cualquiera que tenga el enlace», «personas específicas», «en toda la organización»), concesiones de acceso para usuarios invitados ocultas a tres niveles de profundidad en la pertenencia a grupos, archivos de OneDrive compartidos a través del chat de Teams (lo que crea permisos de uso compartido invisibles en la administración de SharePoint) y etiquetas de confidencialidad aplicadas de forma inconsistente entre las unidades de negocio. En estas condiciones reales, la precisión de la clasificación suele disminuir significativamente, los falsos positivos se disparan porque el escáner no puede resolver las cadenas de herencia de permisos y, por defecto, marca todo como sobreexpuesto, y el panel de control de riesgos se vuelve tan confuso que su equipo de seguridad empieza a ignorarlo en cuestión de semanas.

Qué se debe probar en una demostración de viabilidad real

Estructure su prueba de concepto en torno a los escenarios que realmente ponen a prueba una plataforma DSPM. Conecte al proveedor a un entorno de producción representativo de M365, no a un inquilino de prueba. Elija un segmento de inquilinos con una complejidad real en materia de uso compartido: un departamento que colabore intensamente con socios externos, un entorno de Teams con canales privados anidados y sitios de SharePoint que hayan acumulado años de permisos de uso compartido ad hoc.

Compare la clasificación con los datos de referencia. Antes de la prueba de concepto (POC), etiquete manualmente una muestra de entre 200 y 500 documentos en distintos niveles de sensibilidad. Una vez finalizados los análisis del DSPM, compare sus clasificaciones con sus datos de referencia. Calcule la precisión (qué porcentaje de elementos marcados son realmente sensibles) y la recuperación (qué porcentaje de elementos realmente sensibles ha detectado). Los proveedores que no alcancen una precisión superior al 85 % y una recuperación superior al 80 % con sus datos reales en una prueba de concepto (POC) optimizada obtendrán peores resultados en producción.

Compruebe la profundidad de resolución de permisos. Cree escenarios de prueba con cadenas de permisos complejas y conocidas: un documento compartido a través del chat de una reunión de Teams, un archivo de SharePoint heredado a través de un grupo de seguridad anidado que incluya usuarios invitados, una carpeta de OneDrive compartida con un grupo de M365. Verifique que el DSPM pueda determinar con precisión quién tiene acceso efectivo, y no solo quién posee permisos nominales.

Evalúe el flujo de trabajo de triaje de falsos positivos. Una tasa elevada de falsos positivos es manejable si el flujo de trabajo de triaje y descarte es eficiente. Una tasa moderada de falsos positivos con una interfaz de triaje poco intuitiva es peor. Mida el tiempo que tarda un analista en revisar, validar y descartar o escalar un hallazgo. Multiplique ese tiempo por el volumen diario de alertas previsto.

Realice un ciclo completo de corrección. Seleccione cinco hallazgos reales de sobreexposición del análisis de prueba de concepto (POC). Intente corregirlos mediante el flujo de trabajo del DSPM: revocando un enlace para compartir, ajustando los permisos o aplicando una etiqueta de confidencialidad. Compruebe si la corrección surte efecto realmente en M365 y si el DSPM refleja el estado actualizado en su siguiente ciclo de análisis.

Realice la prueba a la escala real de sus datos. Si su organización cuenta con 50 TB de datos repartidos entre M365 y AWS S3, una prueba de concepto (POC) que analice 500 GB no aporta ninguna información sobre el rendimiento, la duración del análisis o la eficiencia de los análisis incrementales. Insista en que el alcance de la prueba de concepto represente, como mínimo, el 20 % del volumen de datos de producción.

Preguntas que debe plantear a los proveedores

Las listas de verificación genéricas para las solicitudes de propuestas (RFP) generan respuestas genéricas. Las preguntas que figuran a continuación están diseñadas para poner de manifiesto las carencias específicas en materia de capacidades y las realidades operativas que los materiales de marketing de los proveedores no suelen revelar.

Sobre la precisión de la clasificación: «¿Cuál es su tasa de falsos positivos medida en datos no estructurados en entornos de M365 con más de 10 000 usuarios? ¿Puede facilitarnos clientes de referencia de tamaño similar que puedan compartir sus métricas de precisión tras el ajuste?» Los proveedores que solo citan cifras de precisión procedentes de entornos controlados o que se niegan a ponerle en contacto con clientes de referencia para debatir sobre la precisión están poniendo de manifiesto una carencia.

Sobre la resolución de permisos: «Cuando su escáner detecta un archivo de SharePoint cuyo acceso efectivo se deriva de un grupo de seguridad anidado de Azure AD que incluye usuarios invitados B2B, ¿cómo resuelve los permisos efectivos? Explíqueme paso a paso las llamadas específicas a la API y la lógica de herencia de permisos». Esto comprueba si la asignación de acceso del proveedor tiene realmente en cuenta la identidad o si se basa en datos de permisos nominales sin resolver el anidamiento de grupos.

Sobre la personalización de la clasificación: «Disponemos de tipos de datos sensibles específicos del sector que no están cubiertos por los clasificadores estándar de PII/PHI/PCI. ¿Cuál es el proceso para crear clasificadores personalizados? ¿Cuántas muestras de entrenamiento se requieren, cuál es el ciclo de ajuste habitual y qué precisión podemos esperar de los tipos personalizados en comparación con los integrados de serie?». Esto distingue a los proveedores que cuentan con motores de clasificación verdaderamente entrenables de aquellos que ofrecen reglas personalizadas basadas en expresiones regulares y que se comercializan como aprendizaje automático.

Sobre la transparencia del modelo de riesgo: «¿Cómo se calcula su puntuación de riesgo? ¿Qué variables influyen en la puntuación, cómo se ponderan y podemos ajustar las ponderaciones? Si dos archivos contienen datos personales idénticos, pero uno es accesible para 5 usuarios y el otro para 5.000, ¿cómo los diferencia su modelo de riesgo?». Una puntuación de riesgo opaca que no pueda explicarse ni ajustarse no resistirá el escrutinio de su CISO ni las preguntas de su auditor.

Sobre los mecanismos de integración: «Muéstreme la carga útil real de los eventos que su plataforma envía a un SIEM. ¿Qué campos incluye? ¿Se trata de un evento estructurado CEF/LEEF, un webhook JSON o un volcado de syslog? ¿Podemos filtrar qué eventos se reenvían?». La diferencia entre una integración con un SIEM que enriquece su SOC y otra que lo inunda de eventos inservibles radica en la estructura de la carga útil y la granularidad del filtrado.

Sobre los límites de la corrección: «¿Qué medidas correctivas puede ejecutar su plataforma de forma nativa —no solo recomendar, sino ejecutar realmente? En el caso concreto de M365, ¿puede revocar un enlace para compartir, modificar los permisos de un sitio, aplicar una etiqueta de confidencialidad y poner un archivo en cuarentena?». Muchas plataformas de DSPM presentan la corrección como una función, pero en realidad ofrecen una recomendación que un usuario debe ejecutar manualmente en una consola independiente.

En cuanto a los gastos operativos: «Tras la implementación inicial, ¿cuántas horas de personal a tiempo completo (FTE) a la semana dedica un cliente típico de nuestro tamaño al ajuste de la clasificación, la clasificación de falsos positivos, el ajuste de políticas y el mantenimiento de la integración? ¿Se incluye el soporte para el ajuste o se trata de servicios profesionales con un coste adicional?». El coste total de propiedad de un DSPM viene determinado principalmente por los costes operativos, no por las cuotas de licencia.

Armonización de los requisitos de las partes interesadas

Una evaluación del DSPM fracasa cuando se optimiza en función de las prioridades de una de las partes interesadas en detrimento de las demás. Cada miembro de su comité de evaluación aporta una perspectiva diferente, y el marco de puntuación debe tener en cuenta todas ellas.

CISO: Informes sobre riesgos y comunicación con el consejo de administración

El CISO necesita una plataforma DSPM que genere informes de riesgo dirigidos a la alta dirección —no solo conclusiones técnicas, sino datos sobre tendencias que muestren si la situación de seguridad de los datos está mejorando o empeorando con el tiempo—. Evalúe si la plataforma puede generar resúmenes listos para presentar al consejo de administración que traduzcan las métricas de exposición de datos al lenguaje del riesgo empresarial. Pregunte si la puntuación de riesgos puede segmentarse por unidad de negocio, tipo de datos o ámbito normativo, de modo que el CISO pueda informar sobre la situación según las dimensiones que le interesan al consejo de administración. Una DSPM que genere excelentes conclusiones técnicas, pero que no pueda agregarlas en narrativas estratégicas de riesgo, no satisfará las necesidades del CISO.

DPO: Pruebas de cumplimiento y preparación para la auditoría

El responsable de protección de datos necesita que el DSPM funcione como un motor de pruebas de cumplimiento. Evalúe los marcos normativos integrados para el RGPD, la CCPA, la HIPAA, la norma PCI DSS y cualquier normativa específica del sector a la que esté sujeta su organización. Compruebe si la plataforma puede generar informes listos para auditoría que relacionen los resultados de los datos con requisitos normativos específicos —no solo un panel de control de cumplimiento, sino pruebas exportables que un auditor pueda seguir desde el hallazgo hasta el control y la corrección—. El responsable de la protección de datos (DPO) también necesitará apoyo para gestionar las solicitudes de acceso de los interesados: ¿puede el DSPM localizar todas las instancias de los datos de una persona concreta en todos los repositorios analizados?

Ingeniero de seguridad en la nube: cobertura de API y automatización

El ingeniero de seguridad en la nube evalúa si el DSPM se integra en los flujos de trabajo existentes de «infraestructura como código» y de automatización de la seguridad. Necesita una cobertura completa de la API: no solo una API REST para obtener resultados, sino también la capacidad de activar análisis, actualizar políticas y ejecutar medidas correctivas mediante programación. Evalúe la compatibilidad con webhooks, la disponibilidad de proveedores como Terraform o Pulumi y la integración con los procesos de CI/CD. Al ingeniero también le preocupa el rendimiento de los análisis: ¿cuánto tiempo tarda un análisis incremental?, ¿cuál es la limitación de velocidad de la API? y ¿se escala horizontalmente la arquitectura de análisis a medida que aumentan los volúmenes de datos?

Adquisiciones: coste total de propiedad

El departamento de compras debe calcular el coste total de propiedad (TCO) más allá de la cuota de licencia. Los modelos de precios de DSPM varían considerablemente: por almacén de datos, por TB escaneado, por usuario, por resultado, cuota fija por plataforma o modelos híbridos. Solicite a los proveedores un desglose detallado de los precios según la escala prevista, incluyendo los recargos por exceso de uso, las tarifas adicionales por conectores, los servicios profesionales de implementación y ajuste, y las condiciones de aumento de precios en las renovaciones. Calcule el TCO a tres años, incluyendo los costes operativos internos (horas de ETC dedicadas a la administración, el ajuste y la clasificación). Un DSPM cuya licencia cueste un 30 % menos, pero que requiera el doble de inversión en ETC, no es la opción más económica.

Errores habituales de los compradores

Comprar basándose únicamente en el alcance de la exploración

El error de evaluación más habitual consiste en clasificar a los proveedores basándose principalmente en el número de almacenes de datos que pueden analizar. La amplitud de la detección es un requisito mínimo: casi todos los proveedores de DSPM para empresas cubren los principales proveedores de IaaS, M365, Google Workspace y las plataformas de bases de datos más habituales. Donde los proveedores se diferencian es en la profundidad de la clasificación, la contextualización del riesgo y la capacidad de corrección. Una evaluación que otorgue un peso superior al 40 % a la detección seleccionará al proveedor con la lista de conectores más extensa, lo cual no equivale al proveedor que ofrece los mejores resultados en materia de seguridad.

Omitir la prueba de concepto (POC) con datos reales

Realizar una prueba de concepto con datos sintéticos o en un entorno de prueba limpio aporta apenas más información que ver una demostración. Los datos reales presentan clasificaciones desordenadas, contenidos ambiguos que se sitúan en la frontera entre lo sensible y lo no sensible, y estructuras de permisos que han acumulado años de complejidad orgánica. Los proveedores lo saben, y por eso algunos desaconsejan conectarse a entornos de producción durante la evaluación. Insista en realizar una prueba de concepto en entorno de producción. Un proveedor que no obtenga buenos resultados con sus datos reales tampoco lo hará una vez que haya realizado la compra.

No tener en cuenta los gastos generales de explotación

El coste de la licencia es la cifra más visible en la adquisición de una plataforma DSPM, pero el coste operativo —las horas de personal a tiempo completo dedicadas al ajuste, la clasificación prioritaria, la gestión de políticas y el mantenimiento de la integración— suele ser entre dos y tres veces superior al coste de la licencia a lo largo de un periodo de tres años. Evalúe de forma explícita la carga operativa: cuánto ajuste se requiere para alcanzar una precisión de clasificación aceptable, cuántos falsos positivos procesará su equipo a diario y qué nivel de experiencia se necesita para gestionar la plataforma.

Tratamiento del DSPM como enfermedad independiente

El DSPM no funciona de forma aislada. Su valor se ve amplificado o reducido en función de lo bien que se integre con su arquitectura de seguridad global. La Cloud Security Alliance destaca que una implementación eficaz del DSPM se beneficia de una plataforma SSE que ofrezca capacidades de apoyo como CSPM, SSPM, UEBA y supervisión de la actividad en tiempo real. Evalúe a cada proveedor de DSPM en el contexto de su infraestructura actual: ¿complementa o duplica su solución DLP? ¿Puede enviar los resultados a su CASB para su aplicación? ¿Enriquece su SIEM con datos contextuales o simplemente aumenta el volumen de alertas?

Subestimación de la gobernanza de los datos de IA

A medida que las organizaciones implementan herramientas de IA generativa, copilotos y flujos de trabajo RAG, los requisitos de gobernanza de datos se están ampliando más allá de las categorías tradicionales de cumplimiento normativo. Un DSPM que se limite a clasificar los datos según las taxonomías de PII/PHI/PCI podría pasar por alto el nuevo requisito de identificar y gobernar los datos que fluyen hacia los conjuntos de entrenamiento de IA, los flujos de trabajo de ajuste fino y los almacenes de generación aumentada por recuperación. Evalúe si el DSPM es capaz de detectar la exposición de datos sensibles a los servicios de IA y si su taxonomía de clasificación es lo suficientemente ampliable como para abarcar los requisitos de gobernanza específicos de la IA.

Estructuración del proceso de evaluación

Un proceso de evaluación riguroso evita que el alcance del proyecto se amplíe sin control y que los proveedores lo desvíen de su objetivo.

Semanas 1-2: Definición de requisitos. Reúna a su comité de evaluación (CISO o su representante, DPO, ingeniero de seguridad en la nube y responsable de compras). Defina las capacidades imprescindibles frente a las que serían deseables. Adapte la tabla de puntuación ponderada a las prioridades de su organización. Establezca el entorno de prueba de concepto (POC) y el conjunto de datos de referencia.

Semanas 3-4: Solicitud de propuestas (RFP) y selección inicial. Envíe solicitudes de propuestas específicas utilizando las preguntas para proveedores que figuran en esta guía. Califique las respuestas escritas según sus criterios ponderados. Reduzca la lista a entre tres y cuatro proveedores para las demostraciones.

Semanas 5-6: Demostraciones estructuradas. Realice las demostraciones siguiendo una lista de escenarios estandarizada, y no el guion de demostración preferido por el proveedor. Exija a todos los proveedores que realicen demostraciones de los mismos casos de uso: resolución de permisos de M365, creación de clasificadores personalizados, ejecución de medidas correctivas e integración con SIEM.

Semanas 7 a 10: Prueba de concepto. Someta simultáneamente a los dos proveedores finalistas a una prueba de concepto en entorno de producción. Evalúe el rendimiento de la prueba de concepto según los criterios ponderados, utilizando los datos medidos: precisión de clasificación, tasa de falsos positivos, rendimiento del análisis y tiempo de ida y vuelta de la corrección.

Semanas 11-12: Puntuación final, negociación y decisión. Sumar las puntuaciones de todos los evaluadores. Presentar la matriz de puntuación a los responsables ejecutivos con una recomendación clara. Negociar las condiciones del contrato con el proveedor seleccionado, utilizando los datos de rendimiento de la prueba de concepto (POC) como argumento para negociar los acuerdos de nivel de servicio (SLA).