Prevención de fraude de tarificación con SBC en tiempo real: cómo funciona la detección en la ventana de establecimiento de llamada

El fraude de tarificación es un problema de latencia. Cuanto más tiempo tarda en reconocerse una llamada fraudulenta, más dinero genera para el atacante y menos se puede recuperar mediante contracargo. Cada minuto que una sesión de IRSF (International Revenue Share Fraud) permanece conectada representa ingresos que llegan a la cuenta de tarifa premium de otra persona. Para cuando la factura del operador llega cuatro semanas después, el dinero ya no está.
“Tiempo real” en este contexto no es un adjetivo de marketing. Es una posición específica en una línea de tiempo. Un controlador de borde de sesión (SBC) es el único elemento de red que se encuentra en la ruta de señalización SIP con la autoridad y el presupuesto de latencia para actuar dentro de la ventana de establecimiento de llamada, antes de que la parte llamada conteste y antes de que se genere cualquier costo de tarificación. Los firewalls de red operan demasiado abajo en la pila de protocolos para leer el mensaje SIP. Los sistemas de facturación operan demasiado tarde en el flujo de trabajo para detener la llamada. El SBC es el único punto donde la detección y la prevención pueden ocurrir en la misma operación.
Este artículo trata sobre la mecánica de esa operación: qué puede ver realmente un SBC durante el establecimiento de llamada, qué tipologías de fraude dejan señales visibles en tránsito, cómo se ejecuta el pipeline de detección dentro de un SBC programable, y cómo los operadores convierten esa mecánica en una práctica de detección funcional. Para una visión general más amplia de las amenazas y la pila de seguridad de cinco capas que proporciona el SBC, consulte la guía de seguridad del SBC.

Qué significa realmente “tiempo real” para la detección de fraude de tarificación

La mayoría de los artículos sobre fraude de tarificación usan “tiempo real” para referirse a “esporádico, no por lotes”, porque realizar llamadas por lotes es una señal fácil de detectar, mientras que las llamadas esporádicas son difíciles de contrarrestar. Para un SBC, la detección en tiempo real opera en una línea de tiempo de tres ventanas, y cada ventana tiene un perfil de costo diferente y un conjunto diferente de señales disponibles.
La ventana de establecimiento de llamada abarca desde el momento en que el SBC recibe un INVITE entrante hasta el momento en que se envía una respuesta final (200 OK para contestar, o un 4xx/5xx/6xx para rechazar). El presupuesto total de latencia para cualquier decisión en tránsito está aquí, típicamente unos cientos de milisegundos antes de que la parte originadora comience a percibir un retraso en el establecimiento. Una llamada bloqueada dentro de esta ventana no le cuesta nada al operador, porque no se establece ningún flujo de medios y no se facturan cargos de terminación. Esta es la única ventana donde la prevención es genuinamente gratuita.
La ventana durante la llamada abarca desde el 200 OK hasta el BYE. La llamada está conectada, los medios fluyen y los minutos de terminación ya se están acumulando. Un SBC todavía puede terminar la llamada a mitad de sesión si una señal posterior indica fraude, pero cada segundo entre la detección y la terminación es facturable. Los cortes durante la llamada son más útiles para el fraude de larga duración, como una llamada prolongada a un destino de tarifa premium que no coincidió con ninguna señal previa.
La ventana posterior a la llamada abarca desde el BYE en adelante, hasta el registro CDR. Aquí es donde vive el análisis de patrones: agregados de ventana móvil, correlaciones entre troncales, identificación de atacantes. Nada de esto detiene la llamada actual, pero es el circuito que mejora la detección para la siguiente. Un evento de fraude que escapa a las dos primeras ventanas aparece en los análisis posteriores a la llamada en minutos si el pipeline de datos está configurado correctamente, y la lista de bloqueo resultante fluye de regreso a la ventana de establecimiento de llamada a tiempo para detener el resto de la oleada.
Una defensa genuina contra el fraude de tarificación en tiempo real utiliza las tres ventanas. Un despliegue práctico de SBC ejecuta la puntuación en la ventana de establecimiento de llamada para cada llamada, ejecuta la detección de anomalías en paneles de monitoreo para la ventana durante la llamada, y retroalimenta las señales posteriores a la llamada en las reglas de establecimiento. El artículo que sigue se enfoca en la primera ventana, porque es la que importa para detener la llamada sin costo, pero las otras dos son las que mantienen la primera afinada.

Las cinco tipologías de fraude de tarificación que un SBC debe reconocer

El fraude de tarificación no es un solo ataque. Es una familia de esquemas que comparten el objetivo de convertir los minutos de voz de otra persona en ingresos para el atacante. Cada tipología tiene una firma de patrón de llamadas distinta, lo cual es precisamente lo que hace posible la detección en tiempo real.

Reconocer la tipología importa porque la respuesta es diferente en cada caso. Una llamada IRSF debe bloquearse en el SBC con un 603 Decline, porque el destino en sí es el vector de fraude. Una llamada de hackeo de PBX debe bloquearse y el cliente debe ser alertado, porque la troncal SIP es el vector de fraude y el cliente casi con certeza no lo sabe. Una llamada de inflación artificial de tráfico debe limitarse en lugar de bloquearse por completo, porque el rango de destino puede ser legítimo a volúmenes bajos y solo resulta fraudulento en masa.

Las señales de detección visibles durante el establecimiento de llamada

El SBC ve el SIP INVITE antes de que se tome cualquier decisión sobre el enrutamiento. Todo lo que contiene ese mensaje, más todo lo que el SBC ha aprendido de llamadas anteriores en la misma troncal y de llamadas anteriores al mismo destino, está disponible para evaluación. Hay seis familias de señales que importan.
Las señales de destino son el predictor individual más fuerte de fraude de tarificación y el más fácil de accionar. El prefijo del B-number, el código de país y la clasificación de zona tarifaria pueden consultarse contra una lista de bloqueo interna, una lista de bloqueo de socios o un servicio de puntuación en tiempo real. ProSBC expone el B-number directamente al script de enrutamiento y soporta consultas paralelas contra APIs externas de fraude durante el mismo paso de establecimiento de llamada.
Las señales de origen son la reputación del número de origen y la identidad de la troncal originadora. El SBC mantiene estadísticas de origen por NAP (su término para un par SIP) y las expone al script de enrutamiento para su uso en la puntuación.
Las señales de velocidad son agregados de ventana corta. Los picos de CPS, los saltos en llamadas concurrentes, los cambios repentinos de ACD y los colapsos de ASR son todos visibles en los contadores internos del SBC y accesibles desde la cadena de enrutamiento. Estas señales capturan eventos de fraude que no son visibles desde una sola llamada, pero que se vuelven obvios en una ventana móvil de cinco minutos.
Las señales de comportamiento son señales de coincidencia de patrones. Intentos cortos repetidos al mismo destino desde A-numbers rotativos, encabezados SIP idénticos en llamadas que deberían ser únicas o aleatorias en lugar de repetidas, INVITE que reintentan en intervalos de menos de un segundo, patrones de registro que parecen automatizados en lugar de humanos. Ninguna de estas es concluyente por sí sola; combinadas, indican de manera confiable un evento de fraude activo.
Las señales de identidad son el resultado de la verificación STIR/SHAKEN y el resultado de la consulta CNAM, cuando están disponibles. Una llamada que llega con una verificación fallida del encabezado Identity o con un A-number cuyo registro CNAM falta o fue cambiado recientemente recibe una puntuación de fraude peor que una que se verifica correctamente. Las señales de identidad no capturan el fraude por sí solas, pero afinan todas las demás señales, particularmente para esquemas basados en suplantación como Wangiri. La guía de autenticación de llamadas STIR/SHAKEN cubre el flujo de verificación en detalle.
Las señales de contexto son la hora del día, el día de la semana y las señales de patrón de negocio contra la línea base histórica de la troncal. Una troncal de cliente que ha originado 50 llamadas por día a destinos norteamericanos durante horario laboral y repentinamente origina 500 llamadas por hora a un destino caribeño a las 2 AM está produciendo una señal de contexto que ninguna llamada individual expondría.
La disciplina consiste en usar las señales en combinación. Un B-number en una lista de vigilancia por sí solo puede ser un falso positivo (negocios legítimos sí llaman a números de tarifa premium). Un pico de CPS por sí solo puede ser un falso positivo (una campaña de marketing acaba de lanzarse). La combinación de un B-number en lista de vigilancia más un pico de CPS más un horario fuera de oficina es fraude de manera confiable, y el script de enrutamiento puede computar esa combinación en la ventana de establecimiento de llamada.

Cómo se ejecuta el pipeline de detección dentro de ProSBC

ProSBC procesa cada INVITE entrante a través de una cadena de enrutamiento Ruby. La cadena tiene tres etapas de filtro: before_filter (se ejecuta antes de la selección de ruta), after_filter (se ejecuta después de la selección de ruta pero antes del remapeo del mensaje), y after_remap_filter (se ejecuta después de que el INVITE de salida ha sido construido). La detección de fraude de tarificación en tiempo real es una operación de before_filter por diseño, porque el objetivo es bloquear, desviar o limitar la llamada antes de que avance a una ruta de salida.
Una cadena de detección típica se ejecuta en esta secuencia. Primero, los módulos de lista de bloqueo y lista de permitidos locales (BlackWhiteListing, blacklist.csv, base de datos de lista de permitidos) eliminan las llamadas que coinciden con reglas estáticas. Estas son verificaciones de latencia cero. Segundo, el script de enrutamiento consulta uno o más servicios de puntuación externos. TransNexus ClearIP es la integración de producción más común; SecureLogix y YouMail también están soportados. La consulta se ejecuta sobre redirección SIP (el patrón desplegado) o HTTPS (la capacidad alternativa) y devuelve un veredicto transportado en el código de respuesta SIP. Tercero, Reason Cause Mapping convierte esa respuesta en una acción de enrutamiento: 603 Decline detiene la llamada, 404 avanza a la siguiente ruta, 503 avanza a la ruta de conmutación por error, 302 redirige a una cola de análisis de fraude. Cuarto, las verificaciones de velocidad y concurrencia se ejecutan contra los contadores internos de ProSBC para capturar fraude que ningún servicio de puntuación de llamada individual puede detectar.
El presupuesto de latencia para toda esta cadena es de unos cientos de milisegundos durante el establecimiento de llamada. Las consultas de puntuación externas son el contribuyente dominante, y están diseñadas para caber dentro del retardo natural de tono de retorno para que la parte originadora no perciba espera adicional. Si un servicio de puntuación no responde dentro del tiempo de espera configurado, Reason Cause Mapping maneja la ruta de falla de manera explícita: el script puede pasar a una decisión estática (enrutar, bloquear o desviar) en lugar de bloquear la llamada por accidente.
La arquitectura importa porque las reglas estáticas no pueden seguir el ritmo del fraude de tarificación a escala. Los actores de IRSF rotan rangos de destino cada pocas horas. Las oleadas de Wangiri usan nuevos A-numbers en cada ronda. Las sesiones de hackeo de PBX se distribuyen entre troncales de clientes para mantenerse por debajo de los umbrales por troncal. Un pipeline de detección funcional debe consultar inteligencia en vivo en cada llamada y componer esa inteligencia con señales locales en el script de enrutamiento. La cadena de filtros de ProSBC está construida exactamente para ese patrón; la guía de integración de enrutamiento de llamadas con API REST del SBC cubre la mecánica de integración en profundidad.

Qué hacer cuando la detección se activa

Detectar el fraude es la mitad del trabajo. La mitad más difícil es responder de una manera que detenga al atacante sin interrumpir el tráfico legítimo. Hay cuatro respuestas prácticas en el SBC, y cada una se ajusta a un nivel de confianza diferente.
Bloquear es la respuesta correcta cuando la puntuación es inequívoca. El SBC devuelve 603 Decline (u otra causa configurada) y la llamada nunca avanza. Sin medios, sin costo de terminación, sin artefacto visible para el cliente más allá de una llamada fallida. Esta es la respuesta predeterminada para IRSF de alta confianza y para cualquier llamada a un rango numérico en una lista de bloqueo estricta.
Desviar es la respuesta correcta cuando la puntuación es alta pero el costo de un falso positivo también lo es. El SBC redirige la llamada a una cola de análisis de fraude: una troncal separada, un IVR que desafía al llamante o un analista humano. ProSBC soporta enrutamiento por redirección mediante 302 Moved Temporarily y mediante avance de ruta interno. El desvío es más útil para la investigación de Wangiri entrante y para patrones limítrofes de hackeo de PBX donde el llamante (A-number) necesita autorizar el destino antes de que la llamada proceda.
Limitar es la respuesta correcta cuando la fuente subyacente podría ser legítima pero el volumen parece abusivo. La lista gris basada en porcentaje de ProSBC permite al operador bloquear una fracción configurable de llamadas desde una fuente mientras deja pasar el resto. Una lista gris del 90% efectivamente priva a una campaña de fraude de ingresos sin cortar la fuente por completo. Esta es la respuesta estándar ante arbitraje mayorista sospechado y campañas de inflación artificial de tráfico donde el rango de destino tiene usuarios legítimos.
Alertar es la respuesta correcta cuando el SBC ha detectado una anomalía pero aún no puede actuar con confianza. La llamada procede, el evento se escribe en el CDR con la puntuación y la regla que se activó, y un sistema posterior (panel de monitoreo, SIEM, sistema de tickets) genera una alerta revisable por un humano. Alertar sin actuar es necesario para cualquier operador que ejecute una práctica de detección de fraude; es la única forma de conocer la tasa real de falsos positivos de una nueva regla antes de promoverla a bloqueo.
Las cuatro respuestas se componen entre sí. Una configuración típica bloquea la peor categoría directamente, desvía la categoría media a una cola, limita la categoría limítrofe y alerta sobre el ruido de fondo. La promoción entre categorías es un ejercicio de ajuste que se ejecuta a lo largo de semanas: una regla que captura fraude de manera consistente en el nivel de alerta se gana el derecho de pasar a limitar, luego a desviar, luego a bloquear.

Construir una práctica de detección en tiempo real (guía para operadores)

La mecánica anterior solo importa si el operador tiene una práctica que la utilice. Cuatro KPIs marcan la diferencia entre un pipeline de detección funcional y uno configurado pero ignorado.
El primero es la tasa de bloqueo, la fracción de llamadas entrantes que el SBC rechaza por sospecha de fraude. La mayoría de los operadores se estabilizan en un porcentaje de un solo dígito en troncales empresariales y una tasa más alta en troncales mayoristas. Una tasa de bloqueo que tiende hacia cero generalmente significa que las reglas han dejado de activarse porque los atacantes las han superado por rotación; una tasa de bloqueo que sube repentinamente significa que una oleada real de fraude está llegando y las reglas están funcionando. Ambas direcciones ameritan alertas.
El segundo es la tasa de falsos positivos, la fracción de llamadas bloqueadas que resultaron ser legítimas. Los falsos positivos se miden por quejas, por tasas de éxito en reintentos después de un bloqueo y por revisión manual de una cohorte muestreada. Una práctica de detección funcional mantiene la tasa de falsos positivos por debajo del 1%; una postura más estricta (cercana al 0.1%) es normal en troncales mayoristas donde el tráfico legítimo bloqueado es contractualmente costoso.
El tercero es la latencia de detección, el tiempo entre el inicio de un evento de fraude y la primera acción del SBC contra él. Para eventos capturados por un servicio de puntuación en tiempo real en la ventana de establecimiento de llamada, son los pocos cientos de milisegundos de latencia de la consulta. Para eventos capturados por análisis de ventana móvil, es lo que el pipeline posterior a la llamada tarda en producir una nueva regla de bloqueo. El número que vale la pena rastrear es la mediana de latencia entre eventos, porque los eventos de cola que tardaron una hora en detectarse sesgan la media y enmascaran una mediana funcional.
El cuarto es la pérdida por fraude por millón de minutos, el daño financiero residual que escapó a los tres primeros KPIs. Este es el único número que traduce la práctica de detección en términos de negocio. Una práctica de detección que reduce la pérdida por fraude de $50 por millón de minutos a $5 por millón de minutos está cumpliendo su función, independientemente de cómo se vea la tasa de bloqueo.
La práctica en sí es un ciclo semanal. Revisar los registros CDR de la semana pasada para llamadas bloqueadas, desviadas y alertadas. Muestrear las alertas y confirmar si fueron fraude o ruido. Promover las reglas que se ganaron su promoción, retirar las reglas que ya no se activan y actualizar las listas de bloqueo de socios. El SBC es el sustrato; la práctica es el trabajo que hace útil al sustrato.

Cuando el tiempo real no es suficiente

Algunos fraudes son invisibles durante la ventana de establecimiento de llamada. Un actor IRSF sofisticado usa rangos numéricos nuevos que ninguna lista de bloqueo ha visto todavía. Una campaña paciente de hackeo de PBX se mantiene por diseño por debajo de cada umbral estático. Un operador de arbitraje mayorista distribuye el tráfico entre múltiples troncales para evadir los límites de velocidad por troncal. En estos casos, la ventana de establecimiento de llamada dejará pasar el fraude; la detección tiene que moverse a las otras dos ventanas.
La ventana durante la llamada captura fraude que se vuelve visible después de que la llamada se conecta. La señal clásica es la duración: un actor IRSF quiere que la llamada permanezca activa el mayor tiempo posible para maximizar la participación en ingresos, por lo que una llamada saliente a un destino limítrofe que cruza un umbral de duración amerita un corte durante la llamada. El SBC puede enviar un BYE por iniciativa propia cuando un monitor impulsado por el script de enrutamiento se activa, y el flujo CDR de ProSBC y el registro de mensajes SIP exponen suficiente señal para que esto se configure en producción.
La ventana posterior a la llamada captura todo lo demás. La agregación de ventana móvil a través de CDRs revela patrones que ninguna llamada individual puede mostrar: A-numbers rotativos, concentración de destinos, anomalías de ACD, deriva en la reputación de origen. La señal luego se retroalimenta al pipeline de establecimiento de llamada como nuevas entradas en la lista de bloqueo y nuevos umbrales de reglas. Una práctica de detección de fraude bien construida cierra este circuito en minutos para patrones de alta confianza y en un día para todo lo demás.
Nada de esto reemplaza la detección en el establecimiento de llamada. La complementa. La ventana de establecimiento de llamada captura el fraude que es reconocible a partir de la información de una sola llamada. Las otras dos ventanas capturan el fraude que requiere agregación entre llamadas. Un SBC que se encuentra en la ruta de señalización es el único elemento de red que tiene visibilidad en las tres.

Preguntas frecuentes