Parte 3 de 4: Protección dinámica: cuando los controles evolucionan con los riesgos
Por qué los equipos encargados de la gestión de riesgos internos y protección de datos están cada vez más conectados, y por qué tener en cuenta todo el ciclo de vida de los riesgos asociados a los usuarios cambia la forma de protegerlos.
La forma más rápida de perder la confianza en un programa de protección de datos es bloquear una actividad que la empresa necesitaba realizar. Cualquiera que haya gestionado DLP conoce la secuencia: una regla se activa ante una transferencia legítima, se crea una excepción y, tras acumular suficientes falsos positivos, las políticas acaban funcionando únicamente en modo de supervisión. Una protección que no se adapta a cada situación no protege durante mucho tiempo.
La parte 1 nos proporcionó un lenguaje común a través de la Insider Threat Matrix™. La parte 2 nos proporcionó la cadena de pruebas, en la que el análisis del sentimiento permite detectar factores de motivación antes de que se produzca ningún movimiento de datos. La parte 3 plantea la siguiente pregunta: ¿qué podemos hacer con ese contexto antes de que se produzca un incidente?
Eso es la protección dinámica. La visibilidad y los controles se adaptan al riesgo que realmente puede observarse: se aplican donde corresponde, no interfieren con los demás usuarios y vuelven automáticamente a su nivel habitual una vez que el riesgo ha desaparecido.
Las reglas estáticas tienen un problema de contexto
La DLP tradicional plantea una pregunta: ¿deben ir estos datos a ese destino? Estos controles siguen siendo esenciales: detectan las pérdidas accidentales y establecen un nivel de protección de referencia. Los riesgos internos añaden una segunda pregunta: ¿debería esta persona estar haciendo esto precisamente ahora?
Tomemos como ejemplo a un comercial que exporta 2000 registros de clientes en el marco de un cambio de territorio comercial previamente aprobado. Totalmente normal. Ahora, un segundo comercial realiza exactamente la misma exportación. Durante las últimas semanas, ha intercambiado mensajes con un competidor, ha comentado a un compañero que piensa marcharse y ha pedido a un asistente de IA que reescriba una carta de dimisión. RR. HH. no sabe nada de esto. No ha comunicado formalmente su intención de marcharse. Y entonces se exportan los registros.
El contenido no ha cambiado. El contexto sí, y lo hizo semanas antes de que existiera cualquier indicador formal de que el empleado iba a dejar la empresa. Una regla estática solo puede bloquear la actividad de ambos usuarios o permitirla en ambos casos. Ninguna de las dos opciones resulta satisfactoria.
Los equipos de riesgos internos y protección de datos convergen
¿Deberían integrarse en un único equipo las funciones de protección de datos y gestión de riesgos internos? Me preocupa menos el organigrama que conseguir que las políticas funcionen de forma coordinada, porque ambos equipos acaban analizando lo mismo: datos que se transfieren a un lugar al que no deberían ir. La DLP es la herramienta que utiliza el equipo de protección de datos para controlar ese movimiento. La gestión de riesgos internos añade el contexto de la persona, su comportamiento y el momento en que se produce.
En la práctica, ambos equipos abordan los mismos eventos de salida desde perspectivas opuestas. En el triaje de DLP, la alerta se analiza con el contexto justo para descartarla o escalarla. El equipo de riesgos internos realiza investigaciones proactivas sobre esos mismos eventos a partir de un conjunto de datos más amplio: contexto de riesgo del usuario, historial de comportamiento y señales de sentimiento. Esta perspectiva resulta especialmente importante cuando las reglas se quedan cortas y un usuario interno recurre a una táctica que los controles no habían previsto. Todo lo que corresponda claramente al ámbito de la DLP vuelve al equipo de protección de datos. Ambos equipos convergen y trabajan a partir de una única cadena de pruebas, en lugar de disponer cada uno de una visión parcial.
Esto solo funciona si ambos equipos se nutren de la misma fuente, de ahí que la base técnica sea más importante que la estructura jerárquica. Tres capacidades lo hacen posible.
- Un único agente con la flexibilidad necesaria para ambos programas. Un único agente de endpoint recopila la telemetría sobre el movimiento de archivos que el equipo de protección de datos necesita para la DLP y, cuando se activa un desencadenante, proporciona el nivel de detalle sobre el comportamiento y los datos forenses que necesita el equipo de riesgos internos. No se trata de tener dos agentes compitiendo por el mismo endpoint y generando dos versiones del mismo evento. Un único despliegue, un único flujo de datos y una única cronología.
- Acceso limitado al ámbito de cada programa y aplicado mediante políticas. Cada programa define su ámbito y las políticas de acceso basadas en roles se encargan de aplicarlo. El evento solo existe una vez, pero un analista de DLP ve aquello a lo que le autoriza el marco de su programa, mientras que un analista de riesgos internos ve lo que permite el marco de su propio programa y sus obligaciones de privacidad. El ámbito se protege mediante políticas, no mediante la confianza.
- Decisiones de protección basadas en el comportamiento. Como la política de DLP y el contexto de riesgo del usuario residen en el mismo agente, la decisión de protección puede tener en cuenta ambos factores en el momento de la acción: qué contenido es, adónde se dirige y si, en ese preciso momento, el comportamiento de esa persona justifica una advertencia, un retraso o un bloqueo.
Este enfoque funciona para los clientes porque ningún equipo tiene que renunciar a nada. Cada equipo conserva su propio flujo de trabajo y su propio ámbito, pero las pruebas no se fragmentan. Una alerta de DLP que se escala al equipo de riesgos internos llega acompañada de todo su contexto, no simplemente de un número de ticket y la esperanza de que sea suficiente. Además, la organización puede demostrar, política por política, quién vio qué y por qué.
Piense en una escalera, no en un interruptor
La protección dinámica no consiste en pasar directamente de "permitir" a "bloquear". Es una escalera que parte de un nivel de referencia.
Ese nivel de referencia es la política que se aplica a todos: una visibilidad básica del movimiento y la salida de archivos, junto con controles normativos que nunca se desactivan. De forma deliberada, no se recopila información con el máximo nivel de detalle, porque la mayoría de los usuarios no lo necesitan la mayor parte del tiempo.
El primer peldaño es la supervisión mejorada: el trabajo continúa, pero el programa presta más atención. A continuación se aplican controles flexibles: una advertencia, una solicitud de justificación, un breve retraso o una redirección a una aplicación aprobada. En el peldaño superior se encuentran los controles estrictos, reservados para situaciones en las que el nivel de confianza y el posible impacto justifican detener la acción.
Los datos también importan. Los clasificadores de IA reconocen el código fuente allí donde la correspondencia de patrones tiene dificultades. Pegar código en una herramienta de IA puede ser algo rutinario para un desarrollador, pero si coincide con un nivel elevado de riesgo del usuario o con comportamientos propios de la fase de preparación, requiere una respuesta diferente. Comprenda los datos, comprenda a la persona y aplique el nivel de fricción adecuado en cada momento.
Supervisión mejorada: más detalle cuando hace falta, no de forma permanente
La supervisión mejorada se activa en función de determinados desencadenantes, se limita a un periodo concreto y se restablece automáticamente. Un desencadenante definido en las políticas de la organización hace que una persona pase de la política de referencia sobre movimiento de archivos a un nivel de recopilación más exhaustivo durante un periodo determinado. Durante ese periodo, los eventos incorporan datos forenses detallados sobre el archivo y su trazabilidad, la actividad relacionada en los endpoints y la nube, y capturas de pantalla de los momentos relevantes. Cuando finaliza ese periodo sin que se haya producido ninguna novedad, la persona vuelve automáticamente al nivel de referencia. Nadie tiene que retirarla manualmente de una lista de vigilancia.
Los desencadenantes proceden de dos ámbitos: el riesgo y el comportamiento del usuario (un pico de descargas, una primera carga a un destino no autorizado, una advertencia ignorada o un umbral de puntuación de riesgo) y el grupo y el ciclo de vida del usuario (nuevas incorporaciones durante sus primeras semanas, empleados que van a dejar la empresa desde el preaviso hasta su salida, contratistas próximos al final de su contrato, cambios de rol o cualquier persona sujeta a un proceso de RR. HH.). Elevar el nivel de supervisión de un grupo es una decisión basada en políticas, no un juicio sobre una persona concreta.
Esto contribuye a proteger la privacidad y evita una recopilación excesiva de datos. Resulta difícil justificar ante los empleados, el comité de empresa o los organismos reguladores la captura indiscriminada de pantallas, sobre todo cuando la mayoría de esas capturas nunca llega a revisarse. Al vincular la recopilación a comportamientos definidos en las políticas, el programa puede demostrar por qué se elevó el nivel de supervisión de una persona, durante cuánto tiempo y qué información se recopiló. Las capturas de pantalla existen porque se activó un desencadenante documentado, no por la simple curiosidad de alguien.
El descenso automático de nivel evita que los usuarios permanezcan sometidos a una supervisión reforzada más tiempo del necesario.
Los mismos desencadenantes activan los controles. El mismo factor que hace que una persona pase a un nivel de supervisión superior también activa un control flexible en su siguiente movimiento de datos y, si se acumulan más pruebas, un bloqueo estricto. La supervisión y la protección se basan en una misma cadena de pruebas, por lo que siempre avanzan de forma coordinada.
Aquí es donde la parte 2 cobra todo su sentido: las señales de motivación y preparación suelen ser las que elevan a una persona a un nivel de supervisión mejorada, de modo que las pruebas se acumulan cuando todavía hay tiempo para actuar. La persona no queda marcada como una amenaza; el programa simplemente presta más atención durante un periodo y por un motivo definidos.
Una ligera fricción puede revelar lo que un bloqueo estricto no permitiría ver
Una advertencia no solo interrumpe una acción. También genera pruebas. Alguien intenta subir información sensible a un destino al que no debería enviarla el sistema le pide que justifique la acción. Puede que se dé cuenta del error y se detenga. Puede que justifique la acción y continúe mediante un flujo de trabajo aprobado. O puede que intente eludir el control. La primera acción podría haberse debido a una negligencia. Lo que ocurre después revela mucho más.
Dentro de unos umbrales definidos, y siempre que los datos y el posible impacto lo permitan, puede darse cierto margen para observar cómo evoluciona una situación: la fricción protege frente al riesgo inmediato mientras se sigue observando el comportamiento. Aplicar un bloqueo estricto ante la primera acción cuestionable puede eliminar el contexto que necesitan los investigadores. Esto no significa dejar que una actividad peligrosa siga su curso: los datos más críticos o una infracción sobre la que existe un alto grado de certeza siguen dando lugar a un bloqueo estricto inmediato, conforme a umbrales acordados con RR. HH. y el equipo jurídico. A veces, la protección adecuada es un muro; otras, un obstáculo que además permite saber hacia dónde se dirige una persona.
La evolución del riesgo paso a paso: un caso, cinco días
Jake, ingeniero de software, comunica un lunes que dejará la empresa dentro de dos semanas. El sistema de RR. HH. identifica un factor conocido asociado a los empleados que van a dejar la empresa y la plataforma eleva a Jake un peldaño, hasta el nivel de supervisión mejorada, durante su periodo de preaviso. Su acceso no cambia; simplemente, sus eventos se recopilan con mayor nivel de detalle.
El miércoles, su volumen de descargas aumenta muy por encima del nivel de referencia. Al combinarse con su próxima salida de la empresa, este hecho amplía el alcance de la supervisión: se recopila más actividad de los endpoints y la nube, incluidas capturas de pantalla relacionadas con las transferencias señaladas, para que un analista pueda ver qué se extrajo y adónde fue.
El viernes, Jake pega un fragmento de código fuente en una herramienta de IA. Normalmente sería una actividad rutinaria, pero no con su perfil de riesgo actual. Un control flexible le pide que justifique la acción por motivos de trabajo. Jake cierra la advertencia, cambia de navegador y vuelve a intentarlo.
Es este comportamiento, y no el hecho de pegar el código, lo que lo cambia todo. El intento de eludir una advertencia parece deliberado: la puntuación de riesgo aumenta, se amplía la revisión de su acceso al repositorio y se aplica un bloqueo estricto a cualquier nuevo intento de transferir código fuente al exterior. Ninguno de esos momentos por sí solo (la dimisión, el pico de descargas o el hecho de pegar código) justificaba un bloqueo estricto. En conjunto, contaban una historia diferente.
Ahora imagine la otra posibilidad. El pico del miércoles corresponde a un traspaso de tareas autorizado, el viernes transcurre sin incidentes y el riesgo no aumenta. El periodo de supervisión de Jake termina al finalizar su preaviso, la recopilación adicional se detiene y abandona la empresa en el nivel de referencia, sin necesidad de tomar ninguna decisión. Así funciona la evolución del riesgo también en sentido inverso.
El objetivo no es bloquear más. Es proteger con mayor precisión.
La "protección dinámica" puede parecer una excusa para aplicar controles cada vez más agresivos. Debería ser justo lo contrario: menos fricción para la mayoría de los usuarios y una fricción más precisa allí donde las pruebas la justifican. Un control aplicado de forma selectiva resulta mucho más fácil de asumir que otra política global que interfiera con actividades legítimas hasta que todo el mundo termine pidiendo una excepción.
Esa precisión requiere un buen gobierno, porque disponer de pruebas más completas conlleva una mayor responsabilidad. RR. HH. y el equipo jurídico deben acordar qué circunstancias elevan el nivel de riesgo, cuánto dura esa elevación, qué información se recopila en cada nivel y qué permite hacer. Los umbrales están definidos, las revisiones pueden auditarse, las capturas de pantalla permanecen ocultas hasta alcanzar el punto de escalado adecuado y el acceso se rige por las políticas que delimitan el ámbito de cada programa descritas anteriormente.
La DLP no desaparece. Obtiene el contexto del que antes carecía, de modo que los controles más estrictos solo se aplican cuando están justificados. Es un enfoque más práctico que seguir creando reglas.
A continuación: identificar los riesgos que aún desconoce
La parte 1 nos proporcionó el lenguaje común. La parte 2 nos proporcionó la cadena de pruebas, en la que el análisis del sentimiento permite detectar factores de motivación. La parte 3 ha mostrado cómo esas pruebas permiten que la protección se adapte a medida que cambia el riesgo.
Solo queda una pieza: ¿qué ocurre cuando el sistema puede empezar a detectar e investigar los riesgos y preparar el expediente de forma automática?
La parte 4 aborda el triaje y las investigaciones agénticas de principio a fin: relacionar señales a lo largo de todo el ciclo de vida para detectar riesgos internos emergentes y mostrar a los analistas dónde deben centrar su atención, en lugar de depender únicamente de una notificación que suele llegar de forma reactiva. La necesidad es sencilla: aprovechar toda esta riqueza de datos para trabajar de forma más inteligente y detectar los riesgos con mayor rapidez, porque la mayoría de los equipos no van a disponer de más personal. En el mejor de los casos, los recursos se mantienen estables y, con la adopción de la IA, a menudo incluso disminuyen.
Más información
Vea nuestro reciente webinar con los cofundadores de Insider Threat Matrix, James Weston y Joshua Beaman.