Prevenção de Fraude Tarifária com SBC em Tempo Real: Como a Detecção Funciona na Janela de Estabelecimento de Chamada

Fraude tarifária é um problema de latência. Quanto mais tempo leva para reconhecer uma chamada fraudulenta, mais dinheiro a chamada rende ao atacante e menos pode ser recuperado. Cada minuto que uma sessão de IRSF (International Revenue Share Fraud) permanece conectada é receita chegando na conta de tarifa premium de outra pessoa. Quando a fatura da operadora chega quatro semanas depois, o dinheiro já foi embora.

“Tempo real” neste contexto não é um adjetivo de marketing. É uma posição específica em uma linha do tempo. Um Controlador de Borda de Sessão (SBC) é o único elemento de rede que fica no caminho de sinalização SIP com a autoridade e o orçamento de latência para agir dentro da janela de estabelecimento de chamada, antes que a parte chamada atenda e antes que qualquer custo de tarifação seja acumulado. Firewalls de rede operam em camadas baixas demais na pilha para ler a mensagem SIP. Sistemas de faturamento executam tarde demais no fluxo de trabalho para interromper a chamada. O SBC é o único ponto onde detecção e prevenção podem acontecer na mesma operação.

Este artigo trata da mecânica dessa operação: o que um SBC pode realmente ver durante o estabelecimento de chamada, quais tipologias de fraude deixam sinais visíveis em trânsito, como o pipeline de detecção funciona dentro de um SBC programável, e como operadores transformam essa mecânica em uma prática de detecção funcional. Para a visão geral de ameaças e a pilha de segurança em cinco camadas que o SBC fornece, consulte o guia de Segurança do SBC.

O Que “Tempo Real” Realmente Significa para Detecção de Fraude Tarifária

A maioria dos artigos sobre fraude tarifária usa “tempo real” para significar “esporádico, não realizado em lote”, porque fazer chamadas em lote é uma dica fácil de detectar enquanto chamadas esporádicas são difíceis de projetar contra. Para um SBC, detecção em tempo real opera em uma linha do tempo de três janelas, e cada janela tem um perfil de custo diferente e um conjunto diferente de sinais disponíveis.

A janela de estabelecimento de chamada vai do momento em que o SBC recebe um INVITE de entrada até o momento em que uma resposta final é enviada (200 OK para atender, ou um 4xx/5xx/6xx para rejeitar). O orçamento total de latência para qualquer decisão em trânsito está aqui, tipicamente algumas centenas de milissegundos antes que a parte originadora comece a perceber atraso no estabelecimento. Uma chamada bloqueada dentro desta janela não custa nada ao operador, porque nenhuma mídia é estabelecida e nenhuma tarifa de terminação é cobrada. Esta é a única janela onde a prevenção é genuinamente gratuita.

A janela mid-call vai do 200 OK até o BYE. A chamada está conectada, mídia está fluindo, e quaisquer minutos de terminação já estão sendo acumulados. Um SBC ainda pode encerrar a chamada no meio da sessão se um sinal downstream indicar fraude, mas cada segundo entre detecção e encerramento é tarifável. Cortes mid-call são mais úteis para fraudes de queima lenta, como uma chamada de longa duração para um destino de tarifa premium que não correspondeu a nenhum sinal pré-chamada.

A janela pós-chamada vai do BYE em diante, até o registro CDR. É aqui que a análise de padrões opera: agregados de janela móvel, correlações entre troncos, fingerprinting de atacantes. Nada disso interrompe a chamada atual, mas é o loop que melhora a detecção para a próxima. Um evento de fraude que escapa das duas primeiras janelas aparece na análise pós-chamada em minutos se o pipeline de dados estiver configurado corretamente, e a lista de bloqueio resultante retorna à janela de estabelecimento de chamada a tempo de interromper o restante da onda.

Defesa genuinamente em tempo real contra fraude tarifária usa as três janelas. Uma implantação prática de SBC executa pontuação na janela de estabelecimento de chamada para cada chamada, executa detecção de anomalias em painéis de monitoramento para a janela mid-call, e alimenta sinais pós-chamada de volta nas regras de estabelecimento de chamada. O artigo que segue foca na primeira janela, porque é aquela que importa para interromper a chamada sem custo, mas as outras duas são o que mantém a primeira afiada.

As Cinco Tipologias de Fraude Tarifária que um SBC Precisa Reconhecer

Fraude tarifária não é um ataque único. É uma família de esquemas que compartilham o objetivo de converter minutos de voz de outra pessoa em receita para o atacante. Cada tipologia tem uma assinatura distinta de padrão de chamada, que é o que torna a detecção em tempo real possível.

Reconhecer a tipologia importa porque a resposta é diferente em cada caso. Uma chamada IRSF deve ser bloqueada no SBC com um 603 Decline, porque o destino em si é o vetor de fraude. Uma chamada de hackeo de PBX deve ser bloqueada e o cliente deve ser alertado, porque o tronco SIP é o vetor de fraude e o cliente quase certamente não sabe disso. Uma chamada de traffic pumping deve ter a taxa limitada em vez de ser bloqueada completamente, porque a faixa de destino pode ser legítima em baixos volumes e só fraudulenta em massa.

Os Sinais de Detecção Visíveis Durante o Estabelecimento de Chamada

O SBC vê o SIP INVITE antes de qualquer decisão sobre roteamento. Tudo naquela mensagem, mais tudo que o SBC aprendeu de chamadas anteriores no mesmo tronco e de chamadas anteriores para o mesmo destino, está disponível para avaliação. Existem seis famílias de sinais que importam.

Sinais de destino são o preditor único mais forte de fraude tarifária e o mais fácil de agir sobre. O prefixo do B-number, o código de país e a classificação de zona tarifária podem ser consultados contra uma lista de bloqueio interna, uma lista de bloqueio de parceiro ou um serviço de pontuação em tempo real. O ProSBC expõe o B-number diretamente ao script de roteamento e suporta consultas paralelas a APIs externas de fraude durante o mesmo passe de estabelecimento de chamada.

Sinais de origem são a reputação do número chamador e a identidade do tronco de origem. O SBC mantém estatísticas de origem por NAP (seu termo para um peer SIP) e as expõe ao script de roteamento para uso na pontuação.

Sinais de velocidade são agregados de janela curta. Picos de CPS, saltos de chamadas simultâneas, mudanças súbitas de ACD e colapsos de ASR são todos visíveis nos contadores internos do SBC e acessíveis pela cadeia de roteamento. Esses sinais capturam eventos de fraude que não são visíveis em nenhuma chamada individual, mas se tornam óbvios em uma janela móvel de cinco minutos.

Sinais comportamentais são sinais de correspondência de padrões. Tentativas curtas repetidas para o mesmo destino a partir de A-numbers rotativos, cabeçalhos SIP idênticos em chamadas que deveriam ser únicas ou aleatórias em vez de repetidas, INVITEs que retentam em intervalo sub-segundo, padrões de registro que parecem automatizados em vez de humanos. Nenhum desses é conclusivo isoladamente; combinados, indicam de forma confiável um evento de fraude ativo.

Sinais de identidade são o resultado da verificação STIR/SHAKEN e o resultado da consulta CNAM, quando disponíveis. Uma chamada que chega com uma verificação de cabeçalho Identity falhada ou com um A-number cujo registro CNAM está ausente ou foi alterado recentemente recebe uma pontuação de fraude pior do que uma que verifica corretamente. Sinais de identidade não capturam fraude sozinhos, mas refinam todos os outros sinais, particularmente para esquemas baseados em spoofing como Wangiri. O guia de autenticação de chamadas STIR/SHAKEN cobre o fluxo de verificação em detalhes.

Sinais de contexto são a hora do dia, dia da semana e sinais de padrão de negócio contra a linha de base histórica do tronco. Um tronco de cliente que originou 50 chamadas por dia para destinos norte-americanos durante o horário comercial e subitamente origina 500 chamadas por hora para um destino caribenho às 2h da manhã está produzindo um sinal de contexto que nenhuma chamada individual revelaria.

A disciplina é usar os sinais em combinação. Um B-number em uma lista de observação sozinho pode ser um falso positivo (empresas legítimas ligam para números de tarifa premium). Um pico de CPS sozinho pode ser um falso positivo (uma campanha de marketing acabou de ser lançada). A combinação de um B-number em lista de observação mais um pico de CPS mais horário fora do comercial é confiavelmente fraude, e o script de roteamento pode calcular essa combinação na janela de estabelecimento de chamada.

Como o Pipeline de Detecção Funciona Dentro do ProSBC

O ProSBC processa cada INVITE de entrada através de uma cadeia de roteamento Ruby. A cadeia tem três estágios de filtro: before_filter (executa antes da seleção de rota), after_filter (executa após a seleção de rota mas antes do remapeamento de mensagem), e after_remap_filter (executa após a construção do INVITE de saída). A detecção de fraude tarifária em tempo real é uma operação de before_filter por design, porque o objetivo é bloquear, desviar ou limitar a chamada antes que ela avançe para uma rota de saída.

Uma cadeia de detecção típica executa nesta sequência. Primeiro, módulos de lista de bloqueio e lista de permissão locais (BlackWhiteListing, blacklist.csv, banco de dados de whitelist) eliminam chamadas que correspondem a regras estáticas. São verificações de latência zero. Segundo, o script de roteamento consulta um ou mais serviços externos de pontuação. TransNexus ClearIP é a integração de produção mais comum; SecureLogix e YouMail também são suportados. A consulta é feita via SIP redirect (o padrão implantado) ou HTTPS (a capacidade alternativa) e retorna um veredito contido no código de resposta SIP. Terceiro, Reason Cause Mapping converte essa resposta em uma ação de roteamento: 603 Decline interrompe a chamada, 404 avança para a próxima rota, 503 avança para a rota de failover, 302 redireciona para uma fila de análise de fraude. Quarto, verificações de velocidade e concorrência executam contra os contadores internos do ProSBC para capturar fraudes que nenhum serviço de pontuação de chamada individual pode ver.

O orçamento de latência para toda essa cadeia é de algumas centenas de milissegundos durante o estabelecimento de chamada. Consultas a serviços externos de pontuação são o contribuinte dominante, e são projetadas para caber dentro do atraso natural de retorno de toque para que a parte originadora não perceba nenhuma espera adicional. Se um serviço de pontuação não responder dentro do timeout configurado, Reason Cause Mapping trata o caminho de falha explicitamente: o script pode prosseguir para uma decisão estática (rotear, bloquear ou desviar) em vez de bloquear a chamada por acidente.

A arquitetura importa porque regras estáticas não conseguem acompanhar a fraude tarifária em escala. Atores de IRSF rotacionam faixas de destino a cada poucas horas. Ondas de Wangiri usam novos A-numbers a cada rodada. Sessões de hackeo de PBX se distribuem entre troncos de clientes para ficar abaixo dos limites por tronco. Um pipeline de detecção funcional precisa consultar inteligência ao vivo em cada chamada e compor essa inteligência com sinais locais no script de roteamento. A cadeia de filtros do ProSBC é construída exatamente para esse padrão; o guia de integração de roteamento de chamadas via REST API do SBC cobre a mecânica de integração em profundidade.

O Que Fazer Quando a Detecção é Acionada

Detectar fraude é metade do trabalho. A metade mais difícil é responder de uma forma que interrompa o atacante sem quebrar o tráfego legítimo. Existem quatro respostas práticas no SBC, e cada uma se encaixa em um nível de confiança diferente.

Bloqueio é a resposta correta quando a pontuação é inequívoca. O SBC retorna 603 Decline (ou outra causa configurada) e a chamada nunca avança. Sem mídia, sem custo de terminação, sem artefato visível ao cliente além de uma chamada falhada. Este é o padrão para IRSF de alta confiança e para qualquer chamada para uma faixa de números em lista de bloqueio definitiva.

Desvio é a resposta correta quando a pontuação é alta, mas o custo de um falso positivo também é alto. O SBC redireciona a chamada para uma fila de análise de fraude: um tronco separado, um IVR que desafia o chamador, ou um analista humano. O ProSBC suporta roteamento de redirecionamento via 302 Moved Temporarily e via avanço interno de rota. Desvio é mais útil para investigação de Wangiri de entrada e para padrões limítrofes de hackeo de PBX onde o chamador (A-number) precisa autorizar o destino antes que a chamada prossiga.

Limitação é a resposta correta quando a origem subjacente pode ser legítima, mas o volume parece abusivo. O greylisting baseado em percentual do ProSBC permite ao operador bloquear uma fração configurável das chamadas de uma origem enquanto permite que o restante passe. Um greylist de 90% efetivamente priva uma campanha de fraude de receita sem cortar a origem completamente. Esta é a resposta padrão para suspeita de arbitragem de atacado e para campanhas de traffic pumping onde a faixa de destino tem usuários legítimos.

Alerta é a resposta correta quando o SBC detectou uma anomalia, mas ainda não pode agir com confiança. A chamada prossegue, o evento é gravado no CDR com a pontuação e a regra que disparou, e um sistema downstream (painel de monitoramento, SIEM, sistema de tickets) gera um alerta revisável por humanos. Alertar sem agir é necessário para qualquer operador que mantenha uma prática de detecção de fraude; é a única forma de aprender qual é a taxa de falsos positivos de uma nova regra antes de promovê-la para bloqueio.

As quatro respostas se compõem. Uma configuração típica bloqueia a pior categoria diretamente, desvia a categoria média para uma fila, limita a categoria limítrofe e alerta sobre o ruído de fundo. A promoção entre categorias é um exercício de ajuste que acontece ao longo de semanas: uma regra que consistentemente captura fraude no nível de alerta ganha o direito de subir para limitação, depois para desvio, depois para bloqueio.

Construindo uma Prática de Detecção em Tempo Real (Playbook do Operador)

A mecânica acima só importa se o operador tem uma prática que a utilize. Quatro KPIs fazem a diferença entre um pipeline de detecção funcional e um configurado-mas-ignorado.

O primeiro é taxa de bloqueio, a fração de chamadas de entrada que o SBC recusa por suspeita de fraude. A maioria das operadoras se estabiliza em um percentual de dígito único em troncos corporativos e uma taxa mais alta em troncos de atacado. Uma taxa de bloqueio que tende a zero geralmente significa que as regras pararam de disparar porque os atacantes rotacionaram além delas; uma taxa de bloqueio que sobe repentinamente significa que uma onda real de fraude está atingindo e as regras estão funcionando. Ambas as direções merecem alerta.

O segundo é taxa de falsos positivos, a fração de chamadas bloqueadas que se revelaram legítimas. Falsos positivos são medidos por reclamações, por taxas de sucesso de retentativa após um bloqueio e por revisão manual de uma amostra. Uma prática de detecção funcional mantém a taxa de falsos positivos abaixo de 1%; uma postura mais rigorosa (próxima de 0,1%) é normal em troncos de atacado onde tráfego legítimo bloqueado é contratualmente penoso.

O terceiro é latência de detecção, o tempo entre o início de um evento de fraude e a primeira ação do SBC contra ele. Para eventos capturados por um serviço de pontuação em tempo real na janela de estabelecimento de chamada, são as poucas centenas de milissegundos da latência da consulta. Para eventos capturados por análises de janela móvel, é o tempo que o pipeline pós-chamada leva para produzir uma nova regra de bloqueio. O número que vale rastrear é a latência mediana entre eventos, porque eventos de cauda que levaram uma hora para detectar distorcem a média e mascaram uma mediana funcional.

O quarto é perda por fraude por milhão de minutos, o dano financeiro residual que escapou dos três primeiros KPIs. Este é o único número que traduz a prática de detecção em termos de negócio. Uma prática de detecção que reduz a perda por fraude de $50 por milhão de minutos para $5 por milhão de minutos está fazendo seu trabalho, independentemente de como a taxa de bloqueio esteja.

A prática em si é um loop semanal. Revise os registros CDR da semana passada para chamadas bloqueadas, desviadas e alertadas. Faça amostragem dos alertas e confirme se foram fraude ou ruído. Promova regras que mereceram promoção, aposente regras que não disparam mais e atualize listas de bloqueio de parceiros. O SBC é o substrato; a prática é o trabalho que torna o substrato útil.

Quando o Tempo Real Não É Suficiente

Algumas fraudes são invisíveis durante a janela de estabelecimento de chamada. Um ator IRSF sofisticado usa faixas de números novas que nenhuma lista de bloqueio viu ainda. Uma campanha paciente de hackeo de PBX fica abaixo de cada limite estático por design. Um operador de arbitragem de atacado distribui tráfego por múltiplos troncos para escapar dos limites de velocidade por tronco. Nesses casos, a janela de estabelecimento de chamada deixará a fraude passar; a detecção precisa migrar para as outras duas janelas.

A janela mid-call captura fraudes que se tornam visíveis após a chamada conectar. O sinal clássico é duração: um ator IRSF quer que a chamada fique conectada o máximo possível para maximizar a participação na receita, então uma chamada de saída para um destino limítrofe que ultrapassa um limite de duração justifica um corte mid-call. O SBC pode enviar um BYE por iniciativa própria quando um monitor acionado pelo script de roteamento dispara, e o fluxo de CDR e o log de mensagens SIP do ProSBC expõem sinal suficiente para que isso seja implementado em produção.

A janela pós-chamada captura tudo o mais. A agregação de janela móvel entre CDRs revela padrões que nenhuma chamada individual pode mostrar: A-numbers rotativos, concentração de destinos, anomalias de ACD, deriva de reputação de origem. O sinal é então alimentado de volta ao pipeline de estabelecimento de chamada como novas entradas de lista de bloqueio e novos limites de regras. Uma prática de detecção de fraude bem construída fecha esse loop em minutos para padrões de alta confiança e em até um dia para todo o restante.

Nada disso substitui a detecção na janela de estabelecimento de chamada. Complementa. A janela de estabelecimento de chamada captura a fraude que é reconhecível a partir da informação de uma única chamada. As outras duas janelas capturam a fraude que requer agregação entre chamadas. Um SBC que fica no caminho de sinalização é o único elemento de rede com visibilidade nas três janelas.

Perguntas Frequentes