Fija un plazo de detección para cada puerta que abriste

La brecha más instructiva de las últimas semanas no entró forzando nada. Se usó indebidamente el derecho legítimo de una empresa danesa a consultar el registro nacional de población, presuntamente mediante consultas automatizadas, durante unos diez días de septiembre. Una persona empleada en el registro lo detectó el 2 de octubre. Un acceso así existe para usarse, de modo que no puedes limitarte a bloquearlo. Lo que sí puedes decidir es cuánto tiempo puede prolongarse un uso indebido antes de que alguien que lo entiende se entere.

Cada puerta por la que salen datos necesita un plazo de detección

Cada canal por el que pueden salir datos necesita una cifra: cuánto tiempo podría prolongarse un uso indebido antes de que lo supiera alguien que entiende ese canal. La mayoría de las organizaciones fija un objetivo de tiempo de recuperación para las caídas del servicio y nada para el uso indebido de los accesos que concedió a propósito. Eso incluye integraciones con socios, carpetas compartidas, portales de consulta y conectores de IA.

Las últimas semanas muestran lo que cuesta no tenerla. En Dinamarca, el ministerio responsable del registro CPR declaró el 5 de octubre de 2026 que personas no autorizadas habían accedido a nombres, direcciones y números CPR de unos 8,8 millones de personas registradas «mediante el uso indebido del acceso legítimo de una empresa danesa para consultar información en el sistema CPR» (traducción nuestra). Datatilsynet, la autoridad danesa de protección de datos, afirma que los números se obtuvieron presuntamente mediante consultas automatizadas, y Ritzau recoge la opinión del ministro de que la seguridad en torno al acceso de esa empresa no había sido suficiente. En Estados Unidos, un fallo en un sistema para compartir archivos del Defense Manpower Data Center dejó archivos accesibles durante aproximadamente nueve meses antes de que se descubriera, y un pequeño número de usuarios no autorizados accedió a ellos, según informa SecurityWeek. En Shinhan Bank, una persona ajena eludió la autenticación normal de un servicio de consulta creado para intermediarios de préstamos, y Herald Corporation informa de que los registros se extrajeron introduciendo repetidamente valores de consulta cambiantes. Ninguna solicitud aislada tenía por qué parecer inusual; el patrón estaba en la repetición.

Las tres investigaciones siguen abiertas; no se trata de señalar culpables, sino de una medida que a la mayoría de las organizaciones les falta.

Tu SIEM ve los eventos; solo el responsable puede juzgarlos

Tu SIEM es el lugar adecuado para las alertas en tiempo real, pero solo el responsable de un acceso puede juzgar si un uso de apariencia normal es legítimo. Kiteworks puede enviar su actividad al SIEM que ya utilizas mediante syslog, y ahí es donde corresponde alertar sobre lo que parece hostil.

El uso indebido de un acceso legítimo parece actividad de negocio. Que un socio extraiga grandes volúmenes al cierre del trimestre es normal; que ese mismo socio extraiga datos de forma constante durante diez días en un mes cualquiera puede no serlo. El NIST Cybersecurity Framework 2.0 pide ambas mitades: supervisar la actividad del personal (DE.CM-03) y la de los proveedores de servicios externos (DE.CM-06).

Asigna a cada identidad de gran volumen (un socio, una cuenta de servicio, un agente de IA) un responsable de negocio con nombre y apellidos que valide una vez al año su margen de normalidad: el volumen, el horario y las carpetas previstos. Haz que los umbrales del SIEM se deriven de ese margen y dirige cada salida de él al responsable, no solo a la cola del SOC.

Trabaja con tres relojes, no con uno

Un solo ritmo no sirve a la vez para máquinas y para personas, así que trabaja con tres.

• Tiempo real, para las máquinas. El SIEM alerta de lo que parece hostil en todo lo que registras.
• Diario o semanal, para una sola pregunta. Un administrador de Kiteworks hace a Activity Explorer la misma pregunta agregada cada vez: ¿qué ha cambiado respecto al periodo anterior y qué indicadores se han activado? Los indicadores son reglas sencillas, no puntuaciones: un volumen diario de una categoría superior al triple de su mediana del periodo, diez o más fallos de una misma cuenta en una hora, más de 100 descargas de una misma cuenta en un día (ajustable) y actividad fuera del horario laboral que definas. Como esa pregunta no nombra a nadie, es la que puedes programar con una periodicidad fija, por ejemplo con las tareas programadas de Claude. Decide antes tres cosas: de quién es la cuenta de administrador de Kiteworks que usa la ejecución y quién aprobó ese acceso permanente, dónde llega la respuesta y quién la lee, y si tu conector de Kiteworks es accesible desde una ejecución programada en tu configuración. Compruébalo antes de confiar en ello.
• Mensual o trimestral, para los responsables. El responsable lee un informe guardado que cubre cualquier periodo de hasta 12 meses, leído en ventanas de 30 días y comparado con el periodo anterior. El informe indica hasta dónde se remontaba realmente el log. User Account Reviewer añade las cuentas inactivas, bloqueadas y externas, y Sharing Auditor muestra dónde el uso compartido a nivel de carpeta abre el acceso de entrada.

A los umbrales diarios se les escapa, por diseño, el uso lento y constante (low-and-slow): un socio que se mantiene por debajo de 100 descargas al día durante un mes no activa ninguna regla diaria. Comparar periodos acota dónde mirar, porque Activity Explorer muestra el cambio por aplicación, por categoría de actividad y en el porcentaje de usuarios externos. Seguir la tendencia de una sola cuenta es una pregunta sobre una persona, y corresponde a un caso o a tu SIEM, no al informe rutinario.

Trata a los agentes de IA como una población aparte

Un agente de IA con un conector actúa con los permisos de una persona a velocidad de máquina, así que su actividad merece su propia línea base. Kiteworks afirma que toda operación iniciada por IA a través de Kiteworks MCP queda anotada en su registro de auditoría, y Activity Explorer dedica a la actividad del cliente Kiteworks MCP una sección propia en cada informe guardado, incluso cuando es cero, con sus fallos. Solo cuenta ese cliente: una automatización que llama a Kiteworks a través de otra aplicación aparece bajo esa aplicación, así que ten claro cuál de tus integraciones es cuál. Un aumento de las acciones fallidas de agentes merece una pregunta a quien aprobó el conector.

El registro de revisión es tu prueba

Los logs prueban que los eventos ocurrieron; solo un registro de revisión prueba que alguien miró y decidió. En cada ciclo, conserva la fecha, quién revisó, el periodo, hasta dónde se remontaba el log y los indicadores. Anota una decisión por indicador: esperado, ajustar la regla del SIEM, restringir el acceso o abrir un caso.

Fíjate primero en los patrones y después en las personas. Activity Explorer parte de agregados, nunca muestra direcciones IP ni ubicaciones, solo abre una vista por persona con una referencia de caso y pide aprobación antes de que un informe guardado nombre a alguien. Eso cubre una herramienta, no tu programa: la misma actividad en tu SIEM incluye nombres de cuenta y direcciones IP. Antes de la primera ejecución, acuerda con tu delegado de protección de datos y, si la tienes, con la representación de los trabajadores: la base jurídica y una evaluación de impacto (DPIA) para toda la revisión, incluido el envío de datos al SIEM; que los datos de la revisión se usen para la seguridad y nunca para evaluar el desempeño; cómo se informa a la plantilla; y durante cuánto tiempo se conservan los registros que nombran a alguien.

Cinco preguntas para fijar tu propio plazo de detección:

1. ¿Qué canales pueden sacar datos sensibles y quién es el responsable de cada uno?
2. En cada canal, ¿cuánto tiempo podría prolongarse un uso indebido antes de que su responsable lo supiera, y es aceptable?
3. ¿Qué canales alimentan tu SIEM y cuáles no lee nadie?
4. ¿Qué pregunta quiere ver respondida cada responsable cada semana, y está programada?
5. ¿Quién validó la última revisión, en qué fecha y qué decidió?

La primera cifra que fijes será errónea. No tener ninguna es peor. Si quieres calcular con nosotros el plazo de detección de tus canales de Kiteworks, escribe a sales@kiteworks.com o inicia una conversación. No necesitas configurar Claude ni MCP para preguntar. Para la parte de la pregunta que tiene que ver con los permisos, consulta Revisa a qué pueden acceder todavía tus proveedores.