Fallos de minimización de datos

Una empresa de logística integró la plataforma de seguimiento de un proveedor de entregas de última milla. Para habilitar las notificaciones de entrega, la integración requería el nombre del cliente y la dirección de entrega. El desarrollador que construyó la integración extrajo los datos del registro maestro de clientes, que incluía nombre, dirección, correo electrónico, número de teléfono, fecha de nacimiento, número de cuenta, historial de compras completo y tipo de método de pago. Era una sola llamada de API al maestro de clientes, y filtrar solo los campos requeridos habría exigido un esfuerzo de desarrollo adicional que no estaba en el sprint. El proveedor de entregas recibió el perfil completo del cliente. Dieciocho meses después, el proveedor de entregas sufrió una violación de seguridad. La notificación a los clientes afectados describió la exposición de nombre, dirección, correo electrónico, teléfono, fecha de nacimiento, número de cuenta e historial de compras. La investigación confirmó que la plataforma de entregas solo había usado el nombre y la dirección para algún fin. Todo lo demás se había recibido, almacenado y vulnerado sin ningún motivo operativo.

Por qué es importante

La minimización de datos es importante para TPRM por una razón que es a la vez jurídicamente significativa y prácticamente intuitiva: no se pueden vulnerar datos que no se tienen. Cada elemento de datos transferido a un proveedor más allá de lo necesario para la finalidad declarada representa una ampliación innecesaria de la superficie de exposición. Un proveedor que sufre un compromiso expone todo lo que tiene. Si tiene seis campos cuando necesitaba dos, cuatro campos se vulneran innecesariamente, lo que amplía el alcance de la notificación, la exposición regulatoria y el daño a los interesados afectados más allá de lo que requería la finalidad comercial legítima. La minimización de datos es la forma más directa y menos aprovechada de reducir el impacto de una violación de seguridad.

La dimensión regulatoria es directa. El principio de minimización de datos del GDPR impone al responsable del tratamiento, es decir, la organización cliente, la obligación de garantizar que los datos compartidos con los encargados del tratamiento se limiten a lo necesario para la finalidad del tratamiento. Una investigación regulatoria tras una violación de seguridad en un proveedor examinará no solo si el proveedor tenía una seguridad adecuada, sino también si el cliente tenía controles adecuados de minimización de datos, es decir, si los datos vulnerados realmente era necesario compartirlos en primer lugar. Una organización que compartió la fecha de nacimiento de sus clientes con un proveedor de entregas “porque estaba en la integración” verá que esa explicación es insuficiente cuando el regulador pida ver la evaluación de necesidad que justificó compartir ese dato específico con ese encargado específico para esa finalidad específica.

Desde la perspectiva de un atacante, las fallas de minimización de datos son un multiplicador de fuerza. Un atacante que vulnera a un proveedor que tiene datos minimizados obtiene un valor limitado. Un atacante que vulnera a un proveedor que tiene registros completos de clientes (perfiles completos acumulados durante años de integraciones que comparten de más) ha accedido a datos mucho más valiosos de lo que requería la función del proveedor. El esfuerzo para vulnerar al proveedor es el mismo en ambos casos. El valor de la violación lo determina lo que había en los sistemas del proveedor, que a su vez lo determina lo que el cliente decidió compartir, y esa decisión casi nunca se plantea como una decisión de seguridad.

Dónde se equivocan la mayoría de los equipos

La falla más generalizada es tratar la minimización de datos como una consideración de cumplimiento en materia de privacidad y no como una medida de reducción del riesgo de seguridad. Las revisiones de minimización de datos, cuando se realizan, suelen hacerse en el contexto de evaluaciones de impacto en la privacidad o de revisiones del delegado de protección de datos, no en el contexto de evaluaciones de seguridad de proveedores ni del desarrollo de integraciones. El equipo de seguridad, el equipo de TPRM y el equipo de desarrollo de integraciones quizá nunca tengan una conversación coordinada sobre si los datos que se comparten con un proveedor se limitan a lo necesario. El equipo de privacidad puede haber documentado una evaluación de necesidad. La integración puede compartir muchos más datos de los que contemplaba esa evaluación, porque nadie vinculó la evaluación con la implementación.

La segunda falla es no revisar las integraciones existentes en cuanto al cumplimiento de la minimización. La mayor parte de la gobernanza de la minimización de datos se centra en las nuevas integraciones, en las que la incorporación inicial activa una revisión de privacidad. Las integraciones que se construyeron antes de que se formalizaran los requisitos de minimización, o que nunca se sometieron a una revisión de minimización, siguen compartiendo lo que resultaba conveniente al momento de su creación. Una relación con un proveedor que comenzó hace cinco años puede tener una integración que comparte elementos de datos que eran relevantes para un caso de uso que desde entonces cambió, campos que se agregaron “para uso futuro” y nunca se usaron, o categorías de datos que el proveedor ya no trata en absoluto. Esas integraciones acumulan fallas de minimización en silencio hasta que una violación de seguridad revela lo que había en los sistemas del proveedor.

• Tratar la minimización de datos como un ejercicio de cumplimiento en materia de privacidad y no como una medida de reducción del riesgo de seguridad integrada en la gestión del riesgo de proveedores
• Sin revisión de minimización para las integraciones existentes: solo las nuevas relaciones con proveedores se someten a evaluación de minimización de datos, mientras que las integraciones heredadas siguen compartiendo datos en exceso
• La comodidad del desarrollador define el alcance de los datos: integraciones construidas para transmitir registros completos porque filtrar requiere más esfuerzo, sin que los requisitos de protección de datos guíen la implementación
• Sin especificación contractual del alcance de los datos: DPA que autorizan el tratamiento sin especificar los campos de datos que el tratamiento requiere ni prohibir la recepción de campos adicionales
• Alcance de la violación calculado a posteriori: organizaciones que descubren qué datos tenía un proveedor solo después de una violación de seguridad, en lugar de gobernar de antemano qué datos reciben los proveedores

Cómo se ve una buena práctica

Los programas maduros de minimización de datos tratan cada decisión de compartir datos con un proveedor como una evaluación de necesidad: definen los datos mínimos requeridos para la finalidad declarada antes de construir la integración, no después. Esa evaluación da forma a la especificación de la integración, se documenta en el acuerdo de tratamiento de datos y se revisa periódicamente para confirmar que los datos compartidos siguen correspondiendo a la finalidad actual del tratamiento. El resultado son relaciones con proveedores en las que lo que recibe el proveedor es proporcional a lo que necesita, lo que reduce la exposición ante violaciones de seguridad, simplifica el alcance de las notificaciones y crea un registro regulatorio defendible.

• Especificación de campos basada en la finalidad antes de construir la integración: los campos de datos requeridos para la finalidad del proveedor se definen antes de que comience el desarrollo, y la integración se diseña para transmitir solo esos campos
• Especificación del alcance de los datos en los DPA: los elementos de datos específicos que el proveedor está autorizado a recibir se documentan en el contrato, y la recepción de campos adicionales se trata como tratamiento no autorizado
• Revisión periódica de minimización de las integraciones existentes: revisión anual o activada por eventos de lo que recibe cada proveedor frente a lo que requiere su función actual, con eliminación de los campos excedentes
• Anonimización y seudonimización cuando la finalidad lo permita: reemplazo de los datos identificables por equivalentes anonimizados o seudonimizados cuando la función del proveedor no requiere identificar a las personas
• Delimitación de datos históricos: intercambio de datos acotado en el tiempo que limita a los proveedores a datos actuales o recientes cuando los datos históricos no son necesarios para la finalidad declarada
• La minimización como métrica de seguridad: el cumplimiento de la minimización de datos se sigue como métrica de riesgo de proveedores junto con los controles de seguridad, y el intercambio excesivo de datos se trata como un hallazgo de riesgo

Herramientas

La gobernanza de la minimización de datos requiere herramientas que den visibilidad sobre qué datos se comparten con los proveedores y mecanismos para hacer cumplir el alcance de los datos a nivel de campo en las integraciones.

Descubrimiento e inventario de datos: Microsoft Purview, BigID, Varonis

Las plataformas de descubrimiento de datos identifican qué datos personales existen en los sistemas que sirven de fuente para las integraciones con proveedores, lo que proporciona el inventario que permite basar las evaluaciones de minimización en datos reales y no en suposiciones sobre qué campos existen. Para los profesionales de TPRM, preguntar si un proveedor puede confirmar los campos específicos que recibe del cliente, y compararlo con lo que requiere su función, ofrece una evaluación directa de la minimización que las herramientas de descubrimiento de datos respaldan.

Pasarela de API y enmascaramiento de datos: Apigee, AWS API Gateway, Informatica

Las pasarelas de API y las plataformas de enmascaramiento de datos proporcionan el mecanismo técnico para hacer cumplir el alcance de los datos a nivel de campo en la capa de integración, ya que permiten definir políticas que eliminan o enmascaran elementos de datos específicos antes de que se envíen a los puntos de conexión de los proveedores. Esto transforma la minimización de un requisito de desarrollo (cada integración debe construirse para filtrar correctamente) en un mecanismo de aplicación en la infraestructura que funciona sin importar cómo se haya construido la integración. Para los profesionales de TPRM, preguntar si la ingesta de datos de clientes del proveedor usa una pasarela de API con aplicación de políticas a nivel de campo revela un control técnico de minimización que va más allá de las buenas prácticas de los desarrolladores.

Herramientas de ingeniería de privacidad: Privitar, Anonos, Immuta

Las plataformas de ingeniería de privacidad ofrecen capacidades de anonimización, seudonimización y enmascaramiento dinámico de datos que pueden transformar los datos antes de compartirlos con los proveedores, reemplazando los campos identificables por equivalentes que preservan la privacidad cuando la función del proveedor no requiere identificación. En el caso específico de los proveedores de analítica y reportes, estas herramientas permiten compartir datos con utilidad estadística y eliminar el riesgo de identificación que conllevan los registros completos. Para los profesionales de TPRM, preguntar si el caso de uso analítico de un proveedor puede atenderse con datos anonimizados o seudonimizados revela si compartir registros completos es realmente necesario o simplemente conveniente.

Gestión de contratos de datos: Monte Carlo, Great Expectations, dbt

Las plataformas de contratos de datos formalizan las expectativas de esquema y contenido de los flujos de datos entre sistemas: definen qué campos se esperan, qué valores son válidos y qué transformaciones se aplican. En el contexto de la minimización de datos, los contratos de datos pueden codificar el alcance a nivel de campo del intercambio de datos con proveedores como una especificación formal que se valida durante la ejecución de la integración, en lugar de suponerse a partir de la documentación. Una infracción del contrato de datos, es decir, un campo inesperado que aparece en un flujo de datos hacia un proveedor, activa una alerta en lugar de ampliar silenciosamente lo que recibe el proveedor.

Desafíos de gobernanza

El desafío de gobernanza de la minimización de datos es la intersección entre privacidad, seguridad e ingeniería, que vuelve ambigua la titularidad de la tarea. Los equipos de privacidad son dueños del principio de minimización, pero a menudo carecen de visibilidad sobre la implementación técnica de los flujos de datos. Los equipos de ingeniería construyen las integraciones, pero puede que no tengan requisitos de privacidad en sus especificaciones de desarrollo. Los equipos de seguridad evalúan el riesgo de los proveedores, pero puede que no revisen el alcance de los datos como parte de su evaluación. Los equipos de TPRM evalúan a los proveedores, pero normalmente no auditan qué datos recibe realmente el proveedor. En la mayoría de las organizaciones, ningún equipo es dueño de la pregunta integral de si lo que recibe el proveedor coincide con lo que el proveedor necesita.

Cerrar esa brecha requiere convertir el alcance de los datos en un elemento de primer nivel de la incorporación y evaluación de proveedores, tan explícito como los controles de acceso y los requisitos de cifrado. Un acuerdo de tratamiento de datos que especifica los campos exactos que el proveedor está autorizado a recibir, combinado con una verificación periódica de que el flujo de datos real coincide con la especificación, crea el ciclo de gobernanza que transforma la minimización de datos de un principio en un control aplicado.

• Defina el alcance de los datos en los DPA a nivel de campo: los elementos de datos específicos autorizados para el proveedor, no solo una descripción general de la categoría de datos
• Convierta la minimización en un requisito de desarrollo: los requisitos de privacidad y seguridad sobre el alcance de los datos se incluyen en las especificaciones de integración, no se agregan a posteriori
• Audite anualmente las integraciones existentes: revise lo que cada proveedor significativo recibe realmente frente a lo que autoriza su DPA y requiere su función
• Incluya el alcance de los datos en las evaluaciones de proveedores: pida a los proveedores que confirmen los elementos de datos que reciben y compárelos con lo que requiere su servicio
• Trate el intercambio excesivo de datos como un hallazgo de riesgo: las auditorías de integración que identifican proveedores que reciben más datos de los que requiere su función se tratan como hallazgos de seguridad que requieren remediación

Si usted forma parte de un equipo pequeño

Comience con una auditoría del alcance de los datos de sus cinco integraciones con proveedores de mayor riesgo. Para cada una, haga dos preguntas: ¿qué campos de datos recibe realmente este proveedor de nosotros y qué campos de datos requiere su función? La diferencia entre esas dos respuestas es su exposición por falta de minimización. Para la mayoría de las organizaciones, esa auditoría revelará al menos una integración en la que un proveedor recibe muchos más datos de los que requiere su función, y esa es una oportunidad de remediación inmediata y concreta que solo requiere un cambio en la integración, no un nuevo programa de seguridad. Los datos que se eliminan del flujo son datos que no pueden ser vulnerados.

• Audite el alcance de los datos en sus integraciones con proveedores de mayor riesgo: lo que se recibe frente a lo que se requiere
• Para cualquier proveedor que reciba categorías de datos sensibles (de salud, financieros, identificadores gubernamentales), confirme que esas categorías son realmente necesarias para la función del proveedor
• Agregue especificaciones del alcance de los datos a nivel de campo en su próxima renovación de DPA: qué campos está autorizado a recibir el proveedor, no solo qué categoría de datos
• Incluya el cumplimiento de la minimización de datos como pregunta en las evaluaciones de proveedores: pida a los proveedores que confirmen los datos específicos que reciben y para qué usan cada elemento

Qué exigir

Pregunte directamente:

“¿Puede confirmar los campos de datos específicos que recibe actualmente de nosotros como parte de esta integración y, para cada campo, qué función específica cumple en su plataforma?”

“Si alguno de los campos de datos que recibe de nosotros no se usa activamente en su plataforma para la finalidad contratada, ¿cuál es su proceso para identificar y eliminar esos campos de su ingesta de datos?”

“¿Hay alguna categoría de datos que reciba de nosotros, como la fecha de nacimiento, la información financiera o los datos relacionados con la salud, sin la cual podría atender nuestro caso de uso mediante anonimización, seudonimización o exclusión del flujo de datos?”

Evidencia que debe esperar

• Inventario específico de campos de datos con la justificación de la finalidad de cada campo recibido
• Confirmación de que no se recibe ningún campo sin una finalidad operativa activa
• Evaluación de la capacidad de anonimización o seudonimización para los campos en los que la identificación no es necesaria desde el punto de vista operativo
• Proceso para eliminar campos de la ingesta de datos cuando ya no son necesarios para la finalidad contratada

Un proveedor que no puede describir qué hace con cada campo de datos que recibe ha confirmado que no ha examinado si todos los datos recibidos son necesarios. La pregunta de la minimización de datos no se refiere solo a lo que el proveedor necesita: se refiere a si el proveedor sabe qué tiene y por qué lo tiene. Si no lo sabe, tampoco lo sabe su programa de gobernanza de datos.

Cómo demostrarlo

El principio de minimización de datos del artículo 5(1)(c) del GDPR, la regla del mínimo necesario de la HIPAA y el estándar de necesidad razonable de la CCPA crean obligaciones de garantizar que el intercambio de datos con proveedores se limite a lo necesario para la finalidad declarada. Las investigaciones regulatorias posteriores a violaciones de seguridad en proveedores examinan cada vez más si los datos vulnerados realmente era necesario compartirlos en primer lugar. Demostrar la debida diligencia requiere evidencia de una gobernanza activa de la minimización, no solo una política de privacidad que mencione el principio.

• Registros de auditoría del alcance de los datos que muestran que los flujos de datos hacia los proveedores se revisaron frente a la necesidad operativa
• Especificaciones de campos de datos en el DPA para las relaciones con proveedores de mayor riesgo
• Registros de cambios en las integraciones que muestran la eliminación de los campos de datos excedentes identificados en las revisiones de minimización
• Documentación de la evaluación de necesidad para las categorías de datos sensibles compartidas con proveedores
• Registros de la revisión anual de minimización para las relaciones significativas de intercambio de datos con proveedores

Conclusión clave

Los datos que usted no comparte con un proveedor no pueden ser vulnerados a través de ese proveedor. La minimización de datos es a la vez la medida de reducción de riesgos más sencilla disponible y la que con más frecuencia se sacrifica por comodidad de ingeniería. Cada campo adicional en un flujo de datos hacia un proveedor es un campo adicional en cada notificación de violación de seguridad, una exposición regulatoria adicional y un daño adicional a cada interesado cuya información se conservó sin ninguna finalidad. La pregunta de necesidad (¿este proveedor realmente necesita estos datos específicos para cumplir esta función específica?) es una pregunta que la mayoría de las organizaciones responde una sola vez, de manera informal, al construir la integración, y luego nunca vuelve a plantear. Formularla de forma sistemática, documentar la respuesta en el contrato y auditar si la respuesta coincide con la realidad es lo mínimo necesario para que la minimización de datos sea un control y no un principio.