BR112012022088B1 - meio de armazenamento não transitório legível por computador com instruções para execução em um computador hospedeiro, método para fornecer segurança em um computador hospedeiro, e aparelho de segurança de rede - Google Patents

Abstract

MEIO DE ARMAZENAMENTO LEGÍVEL POR COMPUTADOR NÃO TRANSITÓRIO COM INSTRUÇÕES PARA EXECUÇÃO EM UM COMPUTADOR HOSPEDEIRO, MÉTODO DE FORNECIMENTO DE SEGURANÇA EM UM COMPUTADOR HOSPEDEIRO, APARELHO DE SEGURANÇA DE REDE e PRODUTO DE PROGRAMA DE COMPUTADOR. Um meio de armazenamento legível por computador com instruções executáveis em um computador hospedeiro. As instruções gravam uma relação entre um site de parceiro e o computador hospedeiro, substituem uma referência ao site de parceiro com um pseudônimo de site parceiro referenciado o computador hospedeiro, entregam o pseudônimo do site parceiro a um cliente, substituem o pseudônimo do site parceiro pela referência ao site parceiro em resposta a receber o pseudônimo do site parceiro do cliente e aumentam o endereço do cliente com um pseudônimo de endereço. O pseudônimo de endereço é enviado para o site parceiro. A ação do parceiro e o pseudônimo de endereço são recebidos do site parceiro. O endereço é trocado pelo pseudônimo de endereço. A ação do parceiro é entregue ao cliente, utilizando o endereço. Estas operações são monitoradas para identificar a atividade do cliente, que constitui uma ameaça de segurança no computador hospedeiro ou no site de parceiro

Description

Referência cruzada a pedido relacionado

Este pedido reivindica prioridade ao Pedido Provisório de Patente US 61,339,248, depositado em 1 de março de 2010, cujo conteúdo é aqui incorporado por referência.

Campo da invenção

A presente invenção refere-se a sistemas de redes de computadores e métodos para detecção e defesa contra-ataques a websites, incluindo ataques através de websites de terceiros.

Fundamentos da invenção

Há muitas diferentes entidades - financeiras, de negócios, governamentais, caridade, educacionais, individuais, etc. - que podem optar por ter presenças on-line implementadas por sistemas de computador acoplado a uma rede ou código de programa de computador sendo executado em sistemas de outras entidades que estão conectadas à rede. Uma vez que estes sistemas on-line podem ser usados para prover informações, aceitar e encaminhar informações, facilitar as transações, e/ou permitir o acesso a recursos on-line, essas entidades têm interesse em garantir esses sistemas para que as atividades autorizadas sejam permitidas enquanto atividades não autorizadas são impedidas. Internet e outras utilidades online são comumente usadas para transações financeiras, comerciais, particulares e outros, de preferência mantidas em segurança.

Em um exemplo simples, um banco pode optar por oferecer a seus clientes acesso online a dados bancários e uma facilidade para iniciar transações, como transferências de fundos. É de se esperar que algumas ações ilegítimas de pessoas não autorizadas ou sistemas de computador podem querer ser executadas, como indevidamente acessar os dados bancários, iniciando transações não autorizadas, ou modificar recursos online para seus próprios objetivos, e não aqueles do operador dos recursos, como desfigurar uma presença online, roubo de dinheiro, bens ou de informação; sabotagem, ou executar outras ações ile-  gítimas. Outras ações ilegítimas podem ser inesperadas.

Como explicado aqui, uma abordagem comum para prover essa presença online é através de um "site". Enquanto os usuários podem considerar um website um "lugar", é muitas vezes um lugar lógico apenas, na medida em que é referenciado por um URI, enquanto a sua localização física real não é importante e pode de fato ser distribuída sobre vários centros de dados ou mesmo centros de dados virtuais em nuvens computacionais. Mais precisamente, um websiteé geralmente os aspectos da interface de usuário da uma presença de entidade de rede.

Por exemplo, um varejista pode configurar um servidor que tem um software nele que pode receber pedidos de uma rede e responder a esses pedidos, retornando conteúdo, aceitando entradas e/ou executando algumas ações em resposta aos pedidos. Algum desse conteúdo retornado pode ser na forma de páginas web que podem ser visualizadas por meio de dispositivos cliente em resposta a pedidos para as páginas web a partir desses dispositivos cliente. Dispositivos cliente podem incluir computadores, telefones, dispositivos portáteis inteligentes, outros dispositivos computacionais, etc. Estes dispositivos cliente podem ser usados por clientes do varejista, clientes potenciais, visitantes, fornecedores ou parceiros.

Algumas páginas web são estáticas e pré-geradas antes de uma solicitação, como uma página explicando a história de uma empresa, enquanto outras são dinâmicas e geradas em tempo real, como uma página web que mostra o conteúdo de um cartão de comprar do usuário ou uma página gerada para um produto que o usuário apenas solicitou. Assim, o servidor pode ter acesso a sistemas de dados utilizáveis para a geração de páginas web e outros conteúdos (música, vídeo, etc.). O servidor pode compreender várias máquinas em locais diferentes na rede, possivelmente servindo diferentes conjuntos de páginas ou não. Assim, o termo "site" pode se referir ao ponto de vista do lado do cliente de uma coleção de servidores, conteúdo, operações e similares, enquanto os usuários finais podem ver um website como uma coleção de páginas operadas por uma entidade com uma abordagem consistente que pode ser vista em vários aspectos. Como usado aqui, "website" pode se referir ao conteúdo, servidores, operadores dos servidores, e/ou a interação com dispositivos cliente, etc., dependendo do contexto.

Assim como os desenvolvedores do website criaram métodos defensivos para detectar e neutralizar os ataques, os invasores têm, por sua vez formas desenvolvidas em torno dessas defesas, em um ciclo de co-evolução de sofisticação crescente.

Muitos métodos têm sido desenvolvidos para roubar identidades de usuários legítimos de abusos de website. Um método comum é chamado de "phishing", em que um e-mail enviado sob o disfarce de uma entidade confiável elícita informações pessoais de destinatários incautos, normalmente, atraindo potenciais vítimas para um website fraudulento que solicita informações de identificação pessoal, tais como nomes de usuários, senhas, números de conta, PINs ATM, etc. Esta informação roubada é então usada por impostores, manualmente ou roboticamente, para efetuar login em contas das vítimas nos websites originais, a fim de roubar dinheiro, enviar e-mails falsos, ou perpetrar outras atividades ilícitas.

Para combater tais impostores, muitos operadores de websitetêm desenvolvido métodos de controle de acesso mais sofisticados que necessitam de informações de auten-ticação secundárias que os esquemas de phishing simples não podem obter facilmente. Por exemplo, quando um website suspeita que uma conta está sendo utilizada por terceiros, o website pode verificar se o usuário é realmente o proprietário da conta, exigindo credenciais de acesso adicionais escolhidas aleatoriamente, tais como local de nascimento, nome de solteira da mãe, ou a resposta a uma de um conjunto de perguntas pré-selecionadas pelo legítimo proprietário da conta.

Em resposta à implantação de técnicas de autenticação secundárias, os fraudado- res desenvolveram o que é chamado de "man-in-the-middle", no qual um phisher atrai a vítima a um website falsificado imitando a aparência e o comportamento do website destino, por um lado, interceptando a entrada da vítima e retransmitindo isto para o website real, enquanto, por outro lado interceptando a saída do website real e retransmitindo de volta para o usuário através do website falso. Assim, o man-in-the-middle permitir que fraudadores ganhem a entrada em locais privilegiados ao enganar os usuários autorizados do website para responder a todos os desafios impostos pela autorização dos locais privilegiados, assim, fugindo de todos os protocolos de autorização diretos. Apesar do nome "man-in-the-middle", todo o processo, incluindo qualquer atividade ilícita perpetrada dentro da conta assaltada,  pode ser realizado de forma totalmente automática, sem a necessidade de intervenção humana.

Para combater ataques de man-in-the-middle, muitos websites são programados para olhar para as informações de identificação estrutural, como endereços dos usuários do Protocolo Internet e localizações geográficas inferidas, "cookies" (tokens gerados do website passados para trás e para frente entre website e cliente), identificadores de agente de usuário, e marca de tempo de solicitação - informação sobre quais fraudadores normalmente não têm controle direto. Esta informação auxiliar permite que um website detecte usuários suspeitos que, apesar de cumprir todos os desafios de autorização explícita, não estão, evidentemente, usando os mesmos navegadores nos mesmos computadores nos mesmos locais como eles costumam fazer, indicando que eles podem ser vítimas de ataques de man-in- the-middle.

Agora que os websites estão examinando as informações da sessão estrutural para distinguir os impostores de usuários legítimos, os fraudadores desenvolveram um método mais sofisticado de assalto, chamado de "ataque man-in-the-browser", usando um software malicioso instalado clandestinamente em computadores das próprias potenciais vítimas. Vários mecanismos têm sido criados para tirar o malware instalado, incluindo anexos de emails de phishing, downloads de websites de phishing e de vírus de auto-propagação e worms; qualquer dos quais pode ser disfarçado dentro de cavalos de Tróia que aparentemente ou realmente desempenham funções desejáveis, ou pode ser transferido, posteriormente,através de uma porta traseira através de um mecanismo de inicialização.

Este malware, normalmente na forma de um plug-in (daí o nome), se esconde no fundo até que ele reconhece que a vítima em potencial assinou, com sucesso, em um website de destino, assim iludindo todos os protocolos de autorização diretos. Ele em seguida, usa próprio navegador da vítima no próprio computador da vítima, de acordo com a programação do próprio usuário para perpetrar fraude enquanto a vítima está também interagindo com o website, assim também iludindo todas as pistas de autenticação estruturais. Mais uma vez, apesar de algumas implementações proverem em tempo real a intervenção humana, no entanto, todo o processo, incluindo qualquer atividade ilícita perpetrada a partir da conta invadida, pode ser realizado de forma totalmente automática, apesar do nome "homem" no navegador. O malware pode iludir a detecção pelo usuário através da realização de suas transações de forma invisível, por exemplo, em uma janela fora da tela, ou, como em um ataque man-in-the-middle, interceptando as comunicações entre o usuário real e o website, e manipulando a vista apresentada ao usuário.

Uma vez que ataques man-in-the-browser, como ataques man-in-the-middle e outros ataques de phishing, causam danos substanciais para websites e para os usuários dos websites legítimos através de roubo de material e financeiro direto, bem como através de sabotagem, difamação, e outras formas de danos, é crucial para websites ter um meio eficaz para a detecção de tais ataques, a fim de tomar medidas corretivas contra eles.

No momento, no entanto, não existem métodos para websites para detectar ata-quesman-in-the-browser.

Muitos websites terceirizam alguns de seus serviços para websites de terceiros es-pecializados em tais serviços, tais como publicidade, notícias, mapas, busca, indexação, classificação, codificação, classificação, opiniões, e-mail, chat, redes sociais, fóruns, jogos sociais, edição colaborativa, questionários, enquetes, hospedagem de mídia, ofertas especiais e promoções, compras, pagamento de contas, serviços bancários, transferências bancárias, e verificação de identidade. Embora estes serviços de terceiros possam ser adaptados, personalizados e integrados de modo a parecer a ser oferecidos diretamente pelo website principal, os clientes que utilizam os serviços são desviados para os websites parceiros cor-respondentes, ignorando os servidores de web do website principal. Como resultado, o website hospedeiro perde toda a faixa de clientes enquanto eles estão lidando com os terceiros, deixando-os suscetíveis ao ataque através de um website parceiro ou uma combinação de websites parceiros e website hospedeiro. O website principal, portanto, tem que depender de websites parceiros para monitorar seus clientes em seu lugar. No entanto, a informação de monitoramento fornecida pelo de serviços de terceiros, normalmente na forma de relató-riosdiários, semanais ou mensais ou resumos, é geralmente inadequada e inoportuna. Os criminosos online têm sido rápidos para aproveitar essa fraqueza, de modo que muitos websites agora incorrem suas maiores perdas indiretamente, através de serviços de terceiros, e precisam urgentemente de um meio eficaz para usuários de rastreamento em todos os websites de terceiros, além de em seus próprios websites.

Sumário da invenção

Um meio de armazenamento legível por computador com instruções executáveis em um computador hospedeiro. As instruções gravam uma relação entre um websiteparceiro e o computador hospedeiro, substitui uma referência ao website parceiro com um pseudônimo do website parceiro referenciando o computador hospedeiro, entrega o pseudônimo do website parceiro a um cliente, substitui o pseudônimo do website parceiro para a referência ao website parceiro em resposta ao recebimento do pseudônimo do website parceiro a partir do cliente e aumenta o endereço do cliente com um pseudônimo de endereço. O pseudônimo de endereço é enviado para o website parceiro. A ação dos parceiros e o pseudônimo de endereço são recebidos do website parceiro. O endereço é trocado para o pseudônimo de endereço. A ação dos parceiros é entregue ao cliente, utilizando o endereço. Estas operações são monitoradas para identificar a atividade do cliente, que constitui uma ameaça à segurança no computador hospedeiro ou ao website parceiro.

A seguinte descrição detalhada em conjunto com os desenhos anexos, irá prover uma melhor compreensão da natureza e vantagens da presente invenção.

Breve descrição dos desenhos

A Fig. 1 é um diagrama de nível superior de informações de fluxo de um sistema de detecção de retaguarda de serviço de rede de acordo com aspectos da presente invenção. A Fig. 2 é um diagrama de nível superior de informações de fluxo de um sistema de detecção de retaguarda de serviço de rede de acordo com aspectos da presente invenção. A Fig. 3 é um diagrama de nível superior de informações de fluxo do detector de ameaças de serviço de rede na figura 1 ou Fig. 2. A Fig. 4 é um diagrama de fluxo de informações do analisador de website na fig. 3. A Fig. 5 é um diagrama de fluxo de informações do reconstrutor de sessão na fig. 3. A Fig. 6 é um diagrama de fluxo de informações do serviço e modelador de tempo-rização de servidor na figura 5. A Fig. 7 é um diagrama de fluxo de informações do comparador de dados de servi-  ço na fig. 6. A Fig. 8 é um diagrama de fluxo de informações do sincronizador do servidor na fig. 5. A Fig. 9 é um diagrama de fluxo de informações do separador de sessão na fig. 5. A Fig. 10 é um diagrama de fluxo de informação do modelador de agente na fig. 5. A Fig. 11 é um diagrama de fluxo de informação do modelador de temporização de cliente para Fig. 5. A Fig. 12 é um diagrama de fluxo de informações do comparador dados de serviço para fig. 11. A Fig. 13 é um diagrama de fluxo de informações do sincronizador de cliente na fig. 5. A Fig. 14 é um diagrama de fluxo de informações do estimador de dados de clique na fig. 13. A Fig. 15 é um diagrama de fluxo de informações do estimador de dados de carga na fig. 13. A Fig. 16 é um diagrama de fluxo de informações do analisador de sessão na fig. 3. A Fig. 17 é um diagrama de fluxo de informação de um modelador de evento para fig. 3. A Fig. 18 é um diagrama de fluxo de informação de um comparador de evento de sessão independente para fig. 3. A Fig. 19 é um diagrama de fluxo de informação do analisador de ameaça de privilégio na figura 18. A Fig. 20 é um diagrama de fluxo de informações do comparador evento na fig. 18. A Fig. 21 é um diagrama de fluxo de informações de um preditor de frequência de evento atômico para fig. 20. A Fig. 22 é um diagrama de fluxo de informações de um preditor de frequência de evento polarizado TxAB para fig. 20. A Fig. 23 é um diagrama de fluxo de informações de um preditor de frequência de evento polarizado BxTA para fig. 20. A Fig. 24 é um diagrama de fluxo de informações de um preditor de frequência de evento polarizado AxTB para fig. 20. A Fig. 25 é um diagrama de fluxo de informação de um preditor de frequência de evento combinado para Fig. 20. A Fig. 26 é um diagrama de fluxo de informações do combinador de predição na fig. 20. A Fig. 27 é um diagrama de fluxo de informação do pontuador de frequência de evento na figura 20. A Fig. 28 é um diagrama de fluxo de informação do marcador de duração de evento na figura 20. A Fig. 29 é um diagrama de blocos do processador de tráfego de servidor na fig. 2. A Fig. 30 é um diagrama de fluxo de informações do canalizador de parceiro na fig. 29.

Elementos individuais das modalidades são numerados de forma consistente em todas estas figuras.

Descrição detalhada da invenção

Esta descrição apresenta um sistema e método para a determinação de quando houver um ataque man-in-the-browser em um website entre outras coisas. Em um exemplo de modalidade da invenção, ataques man-in-the-browser em um website são detectados comparando a sessão do usuário atual, com a sessão do usuário média.

O sistema da invenção opera sobre um fluxo entrante de dados de entrada gerados por ações em um website. Exemplo de ações em um website normalmente corresponde a cliques de hiperlink pelo usuário do website. Esses cliques podem ser realizados por um ser humano ou por um programa de computador automatizado. Programas de computador automatizados podem trabalhar simulando cliques do website ou trabalhando através da interface de programação de aplicativo do website.

Exemplos de ações tomadas em um website incluem a introdução de dados em formulários no website e cliques para ir para outras páginas do website. Exemplos de introdução de dados em formulários em um website incluem a inserção de um nome de usuário e senha em um website para entrar no website, preencher um formulário de e-mail para enviar e-mail para outro usuário do website, e inserir informações pessoais para se registrar para uma conta no website.

Tal como descrito em maior detalhe abaixo, cada ação de website pode compreen-dervários parâmetros como definidos pela informação correspondente à ação no website que pode ser vista pelos processadores e computadores ligados a um servidor, um firewall, ou outro dispositivo que processa tráfego do website e informações adicionais fornecidas pelo website ou terceiros. Exemplos de parâmetros associados com as ações do website incluem endereços IP, incluindo os de proxies utilizados no processo de enviar o tráfego para o website, informações de cabeçalho de navegador, informações de sistema operacional, informações sobre outros programas instalados na máquina do usuário, informações sobre o relógio e outros ajustes na máquina do usuário, cookies, URLs referentes, nomes de usuários, os parâmetros associados com um post no website, e outras informações associadas com a ação do usuário no website.

Vários aspectos da sessão atual do usuário são comparados com a sessão média de usuário para detectar ataques man-in-the-browser usando um conjunto de dados pré- armazenados que representam os valores dos parâmetros médios de todas as sessões de usuários durante o período de coleta de dados. Isto é comparado com o tempo médio entre cliques para uma sessão média. Em seguida, a ordem em que as páginas do websitesão visualizadas na sessão atual é comparada com a ordem em que as páginas do websitesão visualizadas em uma sessão média para cada página que é acessada. Finalmente, o tempo entre cliques para cada página na sessão do usuário é comparado com o tempo médio entre os cliques para a sessão média de usuário para essa página. Testes adicionais podem ser usados em vez de, ou bem como, os acima referidos.

As comparações acima são combinadas para gerar uma pontuação que indica a probabilidade de que a sessão atual é um ataque man-in-the-browser. A pontuação é usada para determinar se ou não um alerta deve ser gerado para notificar as partes apropriadas, incluindo o administrador do website, o sistema de processamento de alerta do website, e outras partes do website associadas.

O diagrama de fluxo de informação de nível superior da Fig. 1 ilustra uma forma que a invenção aqui divulgada pode ser integrada com o centro de dados ou centros de dados 1030 empregados por um serviço de rede 1015: como um sistema de detecção de ameaça de retaguarda 1000.

Um centro de dados de serviço 1030, o sistema que opera um website ou outro serviço de rede, pode ser configurado de várias maneiras diferentes, dependendo em grande parte do tamanho do negócio: por exemplo, como um único servidor virtual compartilhado com outros serviços, um servidor físico dedicado, todo ou parte de uma fazenda de servidores, ou uma fazenda de servidores virtuais em uma nuvem de computação. Um centro de dados de serviço recebe ações do cliente 1020 a partir do cliente 1010 do serviço, que por sua vez recebe ações de serviço 1040, tal como páginas web, atualizações de páginas web, mensagens de e-mail, mensagens de texto, telefonemas, ou outras informações de volta a partir dos centros de dados de serviço. Ações de cliente típicas 1020 correspondem a cliques de hiperlink ou outras interações com um website, como a entrada de dados de formulário ou fazendo upload de imagens ou de outros recursos pelos clientes 1010 do website, que podem ser humanos ou automatizados por computador. Programas de computador automatizados podem trabalhar simulando cliques do website, usando a interface do serviço de programação de aplicativo, se houver, ou usando algum outro protocolo.

Para cada ação do cliente e ação de serviço, o centro de dados de serviço de resposta 1030 retransmite um registro de transação bruto 1050 para o detector de ameaça 1060. Um registro de transação descreve os parâmetros da transação entre o cliente e o servidor, que contém os parâmetros de ação do cliente correspondente 1020 e resposta do servidor 1040 necessários para detecção de ameaça. Em sua forma mais crua, esses registros de transações podem ser simplesmente cópias dos pacotes de baixo nível ou datagra- mas para todo o tráfego de rede entre os centros de dados expostos e clientes do website, cujo detector de ameaça de serviço de rede independentemente remonta os registros de transações completas.

O detector de ameaça de serviço de rede 1060 e outros componentes podem também estar localizados no local, fora do local, ou em um centro de computação em nuvem.

Na modalidade preferida, todo o sistema de detecção de ameaça de serviço de rede 1000 é colocado com o centro de dados de serviço 1030 para facilitar segurança e resposta em tempo real. Empresas de Internet muito grandes empregam múltiplos centros de dados geo-graficamente dispersos 1030, caso em que um único sistema de detecção de ameaça 1000 pode servir um ou vários centros de dados.

O detector de ameaças de serviço de rede 1060 analisa transações logadas 1050 para comportamento suspeito característico de ataques man-in-the-browser ("MIB") e outros tipos de ataques, e emite notificações de ameaça 1070 de acordo com processadores ameaça de serviços 1080, incluindo o administrador do serviço, o sistema de processamento de alerta de serviço, e outras partes de serviços associadas, como apropriado. Se o serviço não estiver configurado para prover todas as informações necessárias à transação pelo detector no fluxo de registros de transações brutas 1050 empurradas para o detector, então o detector pode emitir solicitações 1100 para puxar informação adicional 1120, conforme necessário a partir dos centros de dados de cliente (cliente-facing data centers) 1030 ou centros de dados de serviço interno 1110, que são instalados em alguns serviços onde eles estão protegidos da Internet por razões de segurança ou eficiência. Além disso, para os serviços que podem fazer outro uso da informação produzida pelo detector, o detector pode enviarinformações 1140 para os centros de dados de serviço 1030 ou 1110, quer não solicitado ou em resposta a solicitações 1130 do detector 1060. Detector de ameaça de serviço de rede 1060 é descrito com maior detalhe na Fig. 3.

Processadores de ameaça 1080 examinam notificações de ameaça 1070, possi-velmente em conjunto com informações adicionais fornecidas por outras ferramentas (não mostradas), e emitem ações de reparação correspondentes 1090 para os centros de dados de cliente 1030.

Ações de reparação 1090 também podem ser retornadas para o detector de ameaça 1060, permitindo que o detector responda por si próprio a posteriores ameaças de cor-respondência, sem incorrer no retardo acarretado por onerar os processadores de ameaça. Reparações de ameaça 1090 incluem imediatamente frustrar clientes sequestrados de acessar o serviço como um todo ou partes sensíveis dos mesmos, bloqueando-os, retardan- do-os, desviando-os para páginas inofensivas, ou falsificando informação sensível; alertando as vítimas que os seus sistemas foram infectados, seja através de canais independentes, como telefone ou correio comum, ou através de mudanças na informação de conta que passam despercebidas pelos sequestradores, mas obrigar as vítimas a contatar a empresa através de outros canais, como por telefone; retroceder ou bloquear as transações fraudulentas; monitorar e rastrear as contas comprometidas, e encaminhar provas incriminatórias para as autoridades competentes para posterior investigação e ação penal, ou outras ações.

Se um website incorpora serviços de websites de terceiros em seus próprios serviços, então algumas das suas ações de serviço 1040 contêm referências aos websites parceiros 1150. Quando um cliente atua em uma referência, como ao clicar em um hiperlink em um iframe proveniente de um website parceiro, então a ação do cliente 1160 é normalmente desviada (seta tracejada) diretamente para o website parceiro, e a resposta do websiteparceiro 1170 é enviada diretamente para o cliente (seta tracejada), ignorando o website principal. O website hospedeiro é, portanto, incapaz de monitorar as transações entre o cliente e os websites parceiros, e é, portanto, incapaz de detectar a fraude ou outras atividades ilícitas perpetradas através dos websites parceiros.

A invenção permite que o website principal monitore o tráfego cliente-parceiro, incluindo um novo canalizador do parceiro que intercepta o tráfego entre o website principal e seus clientes, e edita as ações de serviço de saída 1040 para incluir o tráfego cliente- parceiro através do canalizador parceiro, substituindo as referências do parceiro por pseudônimos de parceiros referindo de volta para o website hospedeiro. Quando um cliente age sobre uma referência editada, a ação do cliente correspondente 1020, em vez de ser desviada para o parceiro, volta para o website principal, onde o canalizador do parceiro a intercepta, substitui o endereço do cliente por um pseudônimo no website hospedeiro para incluir o tráfego do cliente parceiro de volta para o canalizador, substitui o pseudônimo parceiro pela referência do parceiro original, e passa a ação do cliente incluso 1180 para o website parceiro 1150. Quando o website parceiro responde à ação do cliente incluso, a ação do parceiro incluso correspondente 1190 também volta para o website principal, onde o canalizador a intercepta, substitui o pseudônimo do cliente pelo endereço do cliente original, e novamente substitui referências do parceiro pelo pseudônimo do parceiro referindo de volta ao website hospedeiro, finalmente envia a ação do parceiro incluso para o cliente, sob o pretexto de uma ação de serviço ordinária 1040.

Em uma implantação de detector de ameaça de retaguarda, o canalizador está ins-talado no centro de dados do website hospedeiro (s). Na modalidade preferida, o canalizadoré instalado no centro de dados exposto (s) 1030, onde ela pode interceptar todo o tráfego entre o hospedeiro, parceiros, e clientes, com o mínimo de perturbação da arquitetura do website existente, e sem sobrecarregar os centros de dados internos 1110 com tráfego do parceiro. O canalizador do parceiro é discutido nas fig. 29 e fig. 30.

Na modalidade preferida, o sistema de detector de ameaça de serviço de rede de retaguarda 1000 é capaz de detectar e corrigir ataques a um serviço em tempo substancialmente real.

O diagrama de fluxo de informação de nível superior da Fig. 2 ilustra uma forma al-ternativa de se integrar com um centro de dados de serviço (s): como um sistema de detecção de ameaça de serviço de rede de vanguarda 2000.

Nesta configuração, o processador de tráfego de serviço 2010 é introduzido como um proxy para interceptar ações do cliente 1020, a fim de emitir registros de transações 1050 para o detector de ameaça 1060; e interceptar ações de website normal 2030 emitidas pelos centros de dados de website 1030, a fim de substituir ações de reparação 1090 fornecidas pelo detector de ameaça 1060 ou processadores de ameaça de website 1080, conforme apropriado. Tal como acontece com os outros componentes, o processador de tráfego do website pode ser no local, fora do local, ou em um centro de computação em nuvem. Para a geração de registros de transações, processador de tráfego do website 2010 tem acesso direto a todas as informações nos cabeçalhos de solicitação de HTTP provenientes das ações do cliente 1020 e nos cabeçalhos de resposta de HTTP provenientes das ações do website 2030 ou 1090. Ele também tem acesso, por meio de seu próprio relógio, ao momento exato que as ações de clientes foram recebidas e as ações do website 1040 foram transmitidas, que se insere nos registros de transações, eliminando assim a necessidade de sincronização do servidor durante a reconstrução de sessão (ver Fig. 5) diferentes da conci- liação com as informações trocadas internamente com os centros de dados de websites 1030 e 1110 por meio de respostas de serviços 1120 para as solicitações do detector 1100 e respostas do detector 1140 para as solicitações de serviço 1130.

Na modalidade preferida do sistema de detecção de ameaça de vanguarda, para evitar geração supérflua de ações de websites normais 2030 substituídas por ações de reparação 1090, centros de dados expostos 1030 recebem as ações do cliente 1020 apenas como ações de clientes filtrados 2020 provenientes do processador de tráfego do website 2010, que quer detém ações do cliente remediada provenientes dos centros de dados do website, ou as sinaliza como remediadas antes de passá-las para os centros de dados para se registrar sem responder.

Em uma modalidade alternativa, por exemplo, se o website precisa registrar todas as ações do cliente com precisão, mas não está definido de privar-se de responder a ações do cliente remediados, as ações de cliente 1020 ou são passadas através do processador de tráfego do website 2010 não filtradas, ou copiadas diretamente (seta tracejada) para os centros de dados de website, para serem filtradas pelo processador de tráfego do website só na saída 2030.

Em outra modalidade alternativa, se for mais conveniente para determinadas ações ou outras informações serem comunicadas internamente, especialmente se o detector de ameaça de vanguarda for colocado com os centros de dados, o detector de ameaça 1060 pode solicitar 1100 informações 1120 diretamente dos centros de dados isolados 1110 ou expostos 1030, ou prover informações 1130 diretamente para os centros de dados.

Em uma implantação de vanguarda, na modalidade preferida, o canalizador do par-ceiroé incorporado no processador de tráfego de servidor 2010, onde ele pode interceptar todo o tráfego entre o hospedeiro, clientes e parceiros, sem sobrecarregar os centros de dados do hospedeiro com tráfego do parceiro.

Uma configuração de detecção de ameaça= de vanguarda 2000 é preferível para websites que não são projetados para emitir os registros de transação de parâmetros em tempo real 1050 requeridos pelo detector de ameaças, que não são projetados para implementar as ações de reparação 1090 desejadas para lidar com ameaças em real tempo, ou que preferem ter a detecção de ameaça e Reparação tratadas foram do site antes das ações do cliente ofensivas terem a chance de chegar ao website. Detecção de ameaça de vanguarda também oferece as vantagens de marcas de tempo mais precisas e mais exatas e ligações mais estreitas em estimativas de tempo de resposta do cliente, como explicado na Fig. 6.

Na modalidade preferida, o sistema de detecção de ameaça 2000 é capaz de detectar e corrigir os ataques em um website em tempo substancialmente real.

Como mostrado no diagrama de fluxo de informação de nível superior da Fig. 3, de-tector de ameaça de serviço de rede 1060 insere registros de parâmetros de transações brutos 1050 em fluxo contínuo no centro de dados do website (s), aplica uma série de etapas de processamento e emite alertas de notificação de ameaças 1070 para os processadores de ameaça do website.

Na primeira etapa de detecção, se os registros de transações inseridos 1050 não contêm todas as informações da transação necessárias pelo detector de ameaça, como é o caso dos sistemas de detecção de retaguarda 1000 (Ver a Fig. 1.), então aumentador de registro 3010 obtém o máximo de informação faltante possível 1120 por meio de consulta 1100 ao centro de dados (s), emitindo registros aumentados de transações 3020.

Em seguida, a registros de transação aumentados 3020 são analisados pelo re- construtor de sessão 3030 para separá-los em sessões individuais de clientes 3040, conforme descrito na Figura 5. O reconstrutor de sessão pode ser assistido, na sua análise através da utilização de um mapa de website 3110 gerado mantidos pelo analisador de website 3100, conforme descrito sob Fig. 4.

O analisador de sessão 3050, então analisa as sessões de cliente para características de ataques MiB ou ataques de websites semelhantes, e para cada sessão inserida pode emitir um registro de parâmetros de ameaça de sessão 3060, conforme descrito na Figura 11. O analisador de sessão pode também fazer uso de informações do mapa do website.

Em seguida, o comparador de sessão 3070 compara cada registro de parâmetros de sessão atual 3060 com um conjunto de modelos de sessão 3130 derivados do modelador de sessão 3120 provenientes do registro de parâmetros de sessão atuais de anteriores de agregado, e para cada sessão de cliente atual é emitido um registro de pontuação de ameaça 3080. O modelador de sessão pode usar o mapa do website em sua análise. O compara- dor de sessão é descrito mais adiante em ligação com a fig. 18, e o modelador de sessão em ligação com a fig. 17.

Finalmente, para cada sessão de cliente, o reparador de ameaça 3090 analisa o registro de pontuação de ameaça 3080 e, como garantia, emite notificação de ameaça 1070 para posterior análise e Reparação pelos processadores de ameaça do website 1080 (Veja fig. 1). Se direcionado a fazê-lo, o reparador de ameaça também pode emitir ações de reparação 1090 para o centro de dados do website do lado do cliente (ver Fig. 1.) ou para o processador de tráfego do website de 2010 (ver fig. 2).

Como descrito no diagrama de fluxo de informações da Fig. 4, o analisador de website 3100 para uso no detector de ameaça de serviço de rede 1060 (Ver Fig. 3) analisa a estrutura lógica do website e emite o mapa do website 3110 detalhando as ligações intrínsecas 4100 entre as páginas web, bem como o nível de acesso intrínseco 4140, nível de privilégio intrínseco 4120, e o nível de segurança intrínseco 4080 de cada região do website. A rede em teia do website 4010 monta uma lista completa de todas as páginas e outros serviços 4030 pelo website e de todos os hiperlinks internos 4040 entre as páginas e as outras mídias do website, através do exame de hiperlinks intrínsecos em várias páginas, e seguindo cada link que leva a um novo destino, construindo assim as listas de serviços e links, e assim por diante.

Semelhantes a redes em teia de website comuns da técnica anterior, rede em teia do website 4010 é lançada na raiz do website e atravessa o websiteatravés da emissão de ações do cliente 4020 - através de cliques do website simulados ou, se disponível, a interface de programação do aplicativo do website - para website do lado do cliente 1030, e analisa as respostas de ação do website 1040 para todos os links rastreáveis. No caso de o website conter regiões disjuntas ou regiões não acessíveis diretamente pelo spideringexterno, a rede em teia é também lançada em serviços não listados aparecendo nos URLs de Solicitação e URLs de Referência em sessões de cliente 3040. Além disso, links não ras- treáveis por spidering externo, tais como métodos POST CGI deliberadamente disfarçados, traços de rede em teia de website 4010 em paralelo internamente através de registros de transações 1050. Sempre que possível, a rede em teia do website 4010 também atravessa o website ao acessar os serviços e links diretamente através de consultas de banco de dados 1100 para o centro de dados do website 1110 ou 1030.

Para distinguir os localizadores de recursos uniformes (URLs) de serviços genui-namente novos provenientes de URLs apenas de sinônimo de serviços conhecidos, o resol- vedor URL (não mostrado), empregado pela rede em teia do website 4010 e detector de mudança 4050 é aumentado para resolver não apenas os URLs fornecidos e recebidos pelo spidering externo provenientes de ações do cliente 4020 e ações de website 1040, respecti-vamente, mas também os URLs e identificadores equivalentes providos pelos centros de dados de website em resposta 1120 a consultas do banco de dados 1100 e nos registros de transações 1050 nos registros de sessão de clientes 3040. Para resolver pseudônimos de URL, a rede em teia 4010 não apenas compara o conteúdo de serviços com os das redes em teia da técnica anterior, mas primeiro correlaciona URLs apresentados pela primeira vez externamente em ações do website 1040 com URIs internos dados em registros de transações 1060, sincronizando os dois, por exemplo, incluindo um número de sequência no campo User-Agent de suas solicitações.

O detector de mudança 4050 monitora as sessões de clientes 3040 para o aparecimento de novos serviços não na lista de serviços do website 4030, bem como verificando periodicamente para mudanças nos serviços já listados, e emite ordens de atualização 4060 para a rede em teia do website em conformidade.

Classificador de segurança 4070 examina cada serviço de web 4030, e emite nível de segurança 4080 classificando o serviço de acordo com se o seu conteúdo é sempre transmitido como texto simples, ou sempre transmitido de forma criptografada através de um protocolo seguro, como o TLS ou SSL, como reconhecido pelo o nome de protocolo seguro "https://" nas URLs dos serviços, em oposição a "http://", ou pelo cabeçalho de Atualização HTTP.

Mapeador de ligação 4090 elabora a lista dos serviços 4030 e links 4040 em um mapa coerente 4100 da estrutura de ligação intrínseca do website.

O classificador de privilégio 4110 examina links de website 4040 para pontos de ve-rificação que exigem senhas ou níveis mais elevados de autenticação, e usa essa informação para dividir mapa de ligação 4100 em regiões de acordo com o escalão de privilégio 4120 necessário para acessar os serviços 4030, dentro de cada região.

O classificador de acesso 4130 examina cada serviço de web e atribui a ele um nível de acesso 4140, variando de uma "parede"estática inócua não fornecendo nenhum acesso a informações pessoais ou de propriedade; através de uma "janela" insegura permitindotransações inerentemente arriscadas que um agente malicioso pode explorar para indiretamente prejudicar os interesses do cliente ou do proprietário do site, como a exibição de informações pessoais ou proprietárias e usá-lo em outro momento ou em outro lugar; para uma "porta" perigosa permitindo transações inerentemente perigosas que um agente malicioso poderia explorar para diretamente prejudicar os interesses dos cliente ou o proprietário do website, como a remoção ou transferência de bens ou dinheiro; criando, excluindo ou alterando informações como a titularidade da conta ou endereços de entrega, e, em geral, efetuando mudanças no servidor ou em outro lugar fora do navegador do cliente. Janelas geralmente são indicadas por métodos HTTP GET e HEAD, enquanto as portas são normalmente indicadas por métodos HTTP POST, PUT e DELETE.

O mapeador do website 4150 compila mapa de ligação do website 4100, os dados de nível de acesso 4140, dados de nível de privilégio 4120, e dados de nível de segurança 4080 em um único mapa gráfico direcionado ao website integrado 3110 para uso pelo re- construtor de sessão 3030 e modelador de sessão 3120 (Ver a Fig. 3) para determinar se uma transição observada coincide com um link de websiteintrínseco; pelo comparador de sessão 3070 (Fig. 3) para ponderar pontuações de ameaça de sessão de acordo com valores de ameaças intrínsecos dos serviços e transições envolvidas, e por processadores de ameaça de website 1080 e outros o websites pessoais para visualizar e explorar o terreno de ameaça de seu website, e pelos desenvolvedores de websites para melhorar a segurança intrínseca do seu website.

O mapa de website inclui um índice de serviço e um índice de link para acesso aleatório rápido pelo serviço e link.

Mapa do website 3110 também se destina a ser utilizado por outro pessoal de ope-rações, por exemplo, para determinar se todas as regiões atuais do websiteestão conectadas corretamente e se as regiões abandonadas ou experimentais são devidamente desco- nectadas, para pesquisa de desenvolvimento, por exemplo, para determinar se certos percursos comuns deve ser substituído com aquele mais eficientes, e se determinados percursos incomuns devem ser removidos, e para pesquisa de marketing, por exemplo, para explorar a forma como vários serviços podem ser acessados ou promovido.

Analisador de conflitos 4160 usa mapa do website 3110 para analisar a integridade estrutural do website, e emite avisos de conflito 4170 para todas as falhas estruturais de segurança no website, classificados por prioridade, a fim de impedir certos tipos de ameaças das quais o pessoal de segurança do websiteestão presumivelmente, ainda não consciente e que os fraudadores podem já estar a explorar. Em particular, a informação privada nunca deve ser enviada em claro, e as ações de risco nunca devem ser acessíveis a clientes sem a autorização necessária, de modo que os serviços que contêm janelas e especialmente portas devem ser especialmente privilegiados e seguro. O analisador de conflito também pode emitir avisos 4170 para links quebrados, bem como para as regiões órfãs do website, cujo status não mantido pode representar riscos de segurança.

Como descrito no diagrama de fluxo de informações da Fig. 5, o reconstrutor de sessão 3030, para uso no detector de ameaça de serviço de redes 1060 (Ver Fig. 3), compila os registros de transação aumentados 3020 a partir do centro de dados do website (s) em sessões de clientes individuais sincronizadas 3040 ao sincronizar e classificar os registros e segregando-os em sessões.

As fases de sincronização de transação, compreendendo temporização de serviço e modelagem de temporização de servidor 5010, sincronização de servidor 5040, modelagem de temporização de agente 5110, modelagem de temporização de cliente 5130, e sincronização de cliente 5150, servem para ligar de forma tão precisa quanto possível o retardo de resposta do cliente: o intervalo entre o instante em que o cliente recebeu e foi capaz de responder a ação do website 1040 (Ver Fig. 1.), até o instante em que o cliente respondeu emitindo a ação do cliente 1020. Só conhecendo o retardo de resposta de cliente preciso  podem os retardos de resposta de cliente anômalos ser detectados com precisão.

Os registros de transações normalmente proveem dois conjuntos de marcas de tempo: marcas de tempo do servidor e marcas de tempo do cliente, que para serviços HTTP são, respectivamente, fornecidos nos cabeçalhos de dados de resposta HTTP das ações do website 1040 e nos cabeçalhos de dados de Solicitação de HTTP das ações do cliente 1020. Estas marcas de tempo por si, mesmo se ambas as marcas de tempo de solicitação e as marcas de tempo de resposta foram confiavelmente presentes e precisas, são fundamentalmente inadequadas para a fixação do intervalo de resposta do cliente, porque nem a resposta nem a solicitação é instantânea em sua produção, transmissão, recepção e interpretação. Apesar de websites preocupados com a segurança poderem presumir que fornecem algum tipo de marcas de tempo de resposta, a data e hora da solicitação do cliente são apenas opcionalmente presentes. Além disso, muitos websites não corretamente sincronizam os relógios entre seus servidores, a fase da resposta marcada pela marca de tempo de resposta do servidor é indefinida, e algumas oferecem uma marca de tempo indicando quando a transação foi registrada no lugar do tempo de resposta do servidor.

Relógios de clientes são também muitas vezes imprecisos, e são, de fato intencio-nalmente desajustados pelos usuários para ajudar a disfarçar as suas localizações, incluindo por alguns usuários benignos a privacidade, e marcas de tempo de solicitação, quando presentes, podem ser deliberadamente forjados por malware MiB e outros invasores para ajudar a evitar a detecção. Assim, é útil ter uma estimativa precisa do tempo de resposta do cliente a partir da informação estatística e modelos sobre as características de temporização dos servidores, serviços, clientes e agentes.

Em uma implantação de vanguarda, o processador de tráfego de serviço 2010 (ver Fig. 2.) registra os momentos em que começa e termina retransmitindo cada solicitação de serviço a partir e cada cliente para os servidores de website e os tempos quando ele começa e termina retransmitindo retransmissão cada resposta correspondente do servidor de volta para o cliente, e pode, assim, estimar com precisão o intervalo de resposta do cliente para cada transação a partir de informações de temporização específicas de operação. Em uma implantação de retaguarda, no entanto, o reconstrutor de sessão estima o intervalo de  resposta do cliente a partir de estatísticas mais gerais.

Para operadores de websites dispostos para modificar seus websites ou têm seus websites modificados, um mecanismo de temporização do lado do cliente pode ser incorporado em serviços do website, que explicitamente medem o intervalo de tempo entre o recebimento do serviço e resposta do usuário e relata aquele intervalo de tempo de volta diretamente para o website. Para páginas HTML, por exemplo, o temporizador pode ser implementado como um objeto de Javascript Data () criado em carga e definido a data da carga, e então, quando um hiperlink na página é clicado, ou o tempo de carga ou o tempo decorrido uma vez que o carregamento é anexado ao URL de destino ou para a carga útil da solicitação HTTP.

Em uma implantação de vanguarda, com a permissão, o processador de tráfego de serviço incorpora este mecanismo nos serviços do website em tempo real. Caso contrário, tendo os desenvolvedores de websites adicionando este mecanismo em um ciclo de desenvolvimento normal pode levar muitos meses. Em qualquer caso, uma vez as informações de temporização do lado do cliente podem ser falsificadas por um invasor MiB e outros invasores, o reconstrutor de sessão ainda deve confirmá-lo com informações independentemente derivadas do lado do servidor.

Na primeira etapa de reconstrução de sessão, o sincronizador de servidor 5040 cor-rigeconfigurações do relógio discrepantes entre servidores ativos no website durante o período de coleta de dados e compensa a indeterminação da fase de serviço representada por marcas de tempo de data dos servidores gravados nos registros de transação de entrada 3020, a fim de estimar com precisão as datas de recepção do servidor, data de envio, e data de envio para cada registro de transação de entrada, aumentando o registro de transação com essas datas para emitir registro de transação de saída sincronizado de servidor correspondente 5050. O sincronizador de servidor baseia a correção de relógio do servidor e compensação de fase em modelos de temporização específicos de serviço 5020 e modelos de temporização específicos de serviços 5030 gerados e mantidos pelo modelador de temporizaçãode serviço e temporizador de servidor 5010 para cada serviço e cada servidor, respectivamente, aparecendo nos registros de transação de entrada. O modelador de servidor  é descrito em maior detalhe sob Fig. 6, e o sincronizador de servidor na figura 8.

Depois, o escolhedor de transação 5060 escolhe todos os registros de transações sincronizadas 5050 a partir do período de coleta de dados em ordem cronológica, seja por data de recebimento sincronizado, data de envio, ou data de envio, emitindo registros de transações classificadas 5070. Na modalidade preferida, os registros de transações são classificados pela data de recebimento sincronizada, que tende a ter o mínimo de variação destas três estimativas de data.

Separador de sessão 5080 inclina para fora registros de transação escolhidos 5070 para registros pertencentes a clientes individuais, com base em tais características de identificação, como o número da conta, cookie, autenticação, identificação de sessão de URL, endereço de e-mail, e endereço de IP, emitindo de cada conjunto do cliente individual de registros de transações classificadas como uma sessão de cliente individual 5100. O Separador de sessão é discutido em profundidade sob figura 9.

Finalmente, o sincronizador de cliente 5150 corrige configurações do relógio errante entre todos os clientes ativos que utilizam o website durante o período de coleta de dados, compensa a indeterminação da fase de solicitação representada por marcas de tempo dos agentes de usuário registrados nos registros de transações de entrada, ajusta o tempo de transmissão entre cada cliente e servidor em cada direção, e ajusta o tempo de carga de serviço dos agentes de usuário, a fim de estimar com precisão a data de carga do cliente e data de clique, aumentando os registros de transações em sessões de cliente 5100 com essas datas para emitir registros de transação de saída de cliente sincronizado correspondentes em sessões de cliente sincronizado 3040. O sincronizador de cliente baseia a correção de relógio de cliente, compensação de fase, retardos de transmissão, e tempo de carga sobre modelos de temporização de cliente específico de cliente 5140 gerados e mantidos pelo modelador de temporização de cliente 5130, pelos modelos de temporização de específico de agentes de agente e mantidos pelo modelador de temporização de agente 5110, bem como em modelos de servidor 5030 e modelos de serviço 5020. O modelador de agenteé descrito adicionalmente na Figura 10. O modelador de cliente está detalhado na fig. 11.

Em muitos websites, a precisão das marcas de tempo não é confiável, porque cada transação pode ser recebida e transmitida por um servidor diferente, e os servidores não podem ser devidamente sincronizados, de modo que os seus relógios e, consequentemente, suas marcas de tempo discordam significativamente e progressivamente se afastam. Este problema pode ser particularmente pronunciado quando as diferentes transações dentro da mesma sessão de cliente podem até ser servidas por centros de dados geograficamente distantes um do outro.

Um erro adicional, normalmente constante em todos os servidores específicos para um website, é devido à indeterminação da fase de servidor indicado por uma marca de tempo de servidor: muitos serviços de web têm um intervalo de tempo considerável para montar e transmitir, e a marca de tempo poderia se referir a qualquer instante durante esse intervalo. Na verdade, o significado preciso do cabeçalho Data na resposta do servidor é ainda oficialmente indefinido - embora a especificação HTTP recomenda que os dados representam o momento imediatamente antes de a entidade ser gerada, ele permite que a data seja gerada em qualquer momento durante a origem da mensagem.

Portanto, dependendo do website, a marca de tempo pode denotar quando o servidor recebeu e enfileirou a solicitação HTTP, quando desenfilerou a solicitação e começou a servir o serviço, quando terminou de servir o serviço, quando registrou a solicitação recebida ou cumprida em um banco de dados, ou qualquer um desses.

Como descrito no diagrama de fluxo de informação da Fig. 6, o modelador de tem-porizaçãode serviço e temporização de servidor 5010, para uso no reconstrutor de sessão 3030 (Ver Fig. 5), estima e monitora as características de temporização de serviço 5020 para cada serviço 6020 provido pelo website durante o período de coleta de dados, e as características de temporização de servidor 5030 para cada servidor do lado do cliente 6140 em uso no website durante o período de coleta de dados, usando o modelador de retardo de serviço e servidor 6030 para medir e modelar as estatísticas de retardo de servido do servidor 6040 e estatísticas de retardo de servidor 6050 para cada serviço prestado pelo servidor durante o período de coleta de dados, usando eco modelador 6060 para medir e modelar estática de retardo do eco servidor 6070; usando o comparador de retardo de serviço 6080 para comparar os modelos de eco retardo e retardo de serviço, e usar o comparador de re-  tardo de servidor 6090 para comparar os modelos de eco retardo e retardo de servidor.

O modelador de serviço e servidor 5010 insere registro de transações 3020 durante o período de coleta de dados e extrai o identificador do servidor 6010 para obter uma lista de todos os servidores ativos expostos durante o período de coleta de dados, que ele provê ao modelador de servidor e de serviço 6030 e eco modelador 6060, e extrai o identificador de serviço 6020 para obter uma lista de todos os serviços providos por cada servidor, durante o período de coleta de dados, que ele provê o modelador de serviço e servidor. Para os sistemas de endereçamento de Internet atuais, o identificador do servidor consiste nos endereços de IPv6 ou IPv4 do servidor e número de porta no cabeçalho por pacote TCP ou UDP, o número da porta sendo necessário para servidores de websites em uma rede privada por trás de um proxy, e o identificador de serviço consiste no URL do serviço.

Durante o período de coleta de dados, modelador de temporização de serviço e servidor 6030 usa o temporizador de serviço e do servidor 6120 para medir as características de temporização de cada servidor ativo 6140 identificadas pelo identificador de servidor 6010 para cada um dos serviços ativos daquele servidor 6020, e usa o comparador de data do serviço e servidor 6200 para modelar a distribuição estatística das características de temporização de servidor e de serviço.

Especificamente, em uma implantação de retaguarda, para cada servidor ativo e cada um dos serviços ativos do servidor, o temporizador de servidor e de serviço envia um número estatisticamente significativo de solicitações 6130 para aquele serviço para o servidor, e emite o marca de tempo de data 6160 especificada pelo servidor na resposta de serviço 6150 - cabeçalho de Data de Resposta do servidor no caso de operações de HTTP. O momento em que o temporizador de serviço envia uma solicitação de serviço, ele emite a marca de tempo enviada pela solicitação de serviço 6170, o momento em que ele começa a receber resposta do serviço correspondente 6150, ele emite marca de tempo de data recebida pela resposta de serviço 6180, e no momento em que acaba de receber a resposta de serviço, ele emite a marca de tempo de data de resposta de serviço 6190; cada uma destas vezes sendo dada pelo relógio mestre 6100 como tempo atual respectivo 6110. Em uma implantação de vanguarda, em vez de emitir um número estatisticamente significativo de instâncias de cada solicitação de serviço, o temporizador de servidor pode simplesmente passar as ações de clientes filtradas para os servidores, e receber as ações normais de serviço correspondentes 2030, provendo assim uma correção exata para cada transação de cliente real sem a necessidade de amostras adicionais.

O comparador de data de serviço e servidor 6200 modela a distribuição da diferença entre a data de recebimento de serviço 6190 e a data de envio de serviço 6170 para cada serviço 6020, emitindo os modelos como modelos de retardo de serviço 6040. O compara- dor de data de serviço também modela a distribuição da diferença entre a data de resposta nominal 6160 e cada uma da data de envio de serviço 6170, e data de recebimento de serviço 6180, e a data de recebimento de serviço 6190 para cada servidor 6010 como uma função de serviço 6020, emitindo os modelos como modelos de retardo de servidor 6050. O comparador de data de serviço é detalhado na figura 7.

Também durante o período de coleta de dados, modelador de temporização de eco 6060 utiliza temporizador de eco 6210 para medir as características de temporização de serviço nulo de cada servidor ativo 6140, e usa comparador de data de eco 6260 para modelar a distribuição estatística das características de temporização de serviço nulo. Especificamente, temporizador de eco 6210 emite um número estatisticamente significativo de solicitações de eco 6220, também conhecidas como solicitações de ping, para cada servidor de website ativo 6140, emitindo marca de tempo de data de envio de eco 6240 no momento em que envia a solicitação de eco, e emite a marca de tempo data de recebimento de eco 6250 o momento em que recebeu a resposta de eco 6230 de volta do servidor, cada marca de tempo sendo dada pelo respectivo tempo atual 6110, conforme especificado pelo relógio mestre 6100.

Para cada eco temporizado, o comparador de data de eco 6260 calcula a diferença entre o tempo de recebimento do eco 6250 e o tempo de envio de eco correspondente 6240, e remite um modelo da distribuição do resultado como modelo de retardo de eco 6070. Na modalidade mais simples, o modelo de retardo de eco específico de servidor para cada direção compreende a metade do tempo de eco de ida e volta médio. A modalidade preferida também leva em consideração quaisquer assimetrias conhecidas da velocidade e da largura de banda na taxa de transmissão da conexão de Internet em cada extremidade, dividindo o tempo de eco de ida e volta em duas porções inversamente proporcionais à capacidade de transmissão nessa direção.

Por fim, para cada serviço ativo 6020, o comparador de retardo 6080 compara o retardo de ida e volta de serviço 6040 com o retardo de ida e volta de eco 6070, emitindo a diferença entre os modelos como a duração do serviço intrínseca no modelo de serviço 5020.

Em uma modalidade alternativa, a temporização de servidor é modelada em termos de cumprimento de serviço em bytes, em vez de em termos de duração de serviço intrínseca.

Para cada servidor de website exposto ativo 6140, o comparador de retardo de servidor 6080 também compara a distribuição do retardo de serviço de servidor 6050 com a distribuição de retardo de eco do servidor 6070, emitindo a diferença entre os modelos como modelo de temporização de servidor 5030. Na modalidade mais simples, o modelo de temporizaçãode servidor compreende três funções afins da duração de serviço intrínseca, cada uma com um parâmetro de polarização aditiva e um parâmetro de taxa multiplicativa. Especificamente, a função de recebimento do servidor, utilizada pelo sincronizador de servidor 5040 para estimar quando o servidor recebeu uma solicitação de serviço, é calculada como a diferença entre a função de retardo de solicitação de serviço e a função de retardo de solicitação de eco, a função de envio de servidor, utilizada para estimar quando o servidor iniciou enviar uma resposta, é calculada como a diferença entre a função de envio de serviço e a função de envio de eco, e a função de envio de servidor, utilizada para estimar quando o servidor terminou de enviar uma resposta, é calculada como a diferença entre a função de envio de serviço e função de envio de eco.

Em uma modalidade alternativa, em vez de criar os modelos de retardo de serviço independente de servidor 6040 separado dos modelos de retardo de servidor 6050, o com- parador de data de serviço do servidor 6200 gera um modelo de retardo de servidor para cada serviço ativo para cada servidor ativo, provendo aquele serviço. O modelo de retardo de serviço e servidor combinado mais simples então dá a solicitação de serviço, resposta de serviço, e retardos de resposta de serviço como funções constantes específicas para ambos o serviço e servidor, calculado como a média observada em cada respectiva diferença. Neste caso, o comparador de retardo de serviço 6080 e o comparador de retardo de servidor 6090 também são da mesma forma combinados em um comparador de retardo de serviço e servidor único que correspondentemente emite um modelo de temporização separado para cada serviço ativo para cada servidor ativo, provendo aquele serviço.

Se ou o temporizador de serviço 6120 ou o temporizador de eco 6210 verificar que um servidor não responde ou termina de responder a uma solicitação dentro de um período razoável de tempo, normalmente dentro de alguns segundos ou um pequeno múltiplo do tempo médio de resposta para aquele servidor ou aquela solicitação de serviço que, em seguida, ele exclui que a medição das estatísticas e emite um aviso 6310 para administradores do website que o servidor não está respondendo tão rapidamente quanto o esperado.

Modelos de temporização de serviço 5020 e modelos de temporização de servidores 5030 são atualizados pelo comparador de retardo de serviço 6080 e comparador de retardo de servidor 6090 periodicamente, com frequência suficiente para controlar o desvio entre os relógios dos servidores, bem como após a falta de energia, deslocamentos de relógio de tempo de economia de luz de, e outros eventos excepcionais que podem afetar as definições do relógio do servidor ou alterar números de porta do proxy para servidores individuais. Na modalidade preferida, o temporizador de servidor atualiza os modelos de temporizaçãode servidor com frequência suficiente para controlar com precisão o congestionamento do servidor. Em uma modalidade alternativa, os modelos de retardo de serviço 6050 e os modelos de retardo de eco 6070, e, assim, os modelos de servidor 5030, explicitamente levam congestionamento de website em consideração, como funções afins limitadas da carga do servidor.

Em uma modalidade, os modelos de serviços 5020 e modelos de servidor 5030 e os modelos de retardo de serviços subjacentes 6040, modelos de retardo de servidor 6050, e modelos de retardo de eco 6070 são computados em lotes independentes, por exemplo, para sucessivos intervalos de coleta de dados, tal como uma vez por hora pela hora anterior. Na modalidade preferida, estes modelos são continuamente atualizados com uma janela deslizante de incrementos de sobreposição mais curtos, mesmo, no limite, à medida que cada novo registro de transação é recolhido e conforme cada um dos períodos de transação antigos além da janela de tempo.

Além de seu uso para a detecção de ameaça do website, os modelos de tempori-zaçãode serviço 5020 podem ser analisados pelo analisador de serviço de 6270 e apresentados como resumos de serviço 6280 para pesquisa de operações, por exemplo, para determinar se os recursos destinados a serviços específicos ou tipos de serviços devem ser ajustados, para pesquisa de desenvolvimento, por exemplo, para determinar se certos serviços devem ser substituídos por outros mais eficientes, e para pesquisa de marketing, por exemplo, para determinar como vários serviços estão sendo usados.

Da mesma forma, em adição ao seu uso para a detecção de ameaça de website, os modelos de temporização de servidor 5030 são analisados pelo analisador de servidor 6290 e apresentados como sínteses de servidor 6300 para pesquisa de operações, por exemplo, para equilíbrio de carga, ou para determinar se certos servidores ou tipos de servidores estão realizando as expectativas.

Como descrito no diagrama de fluxo de informações da Fig. 7, o comparador de data de serviço de servidor 6200, utilizado pelo modelador de serviço e servidor 5010 (Ver Fig. 6) modela o retardo de serviço 6040 usando o modelador de retardo de serviço 7010, e modela o retardo de servidor 6050 usando o modelador de retardo de servidor 7020.

Para cada transação de serviço programado, o modelador de retardo de serviço de servidor calcula a diferença 7030 entre a Dara de recebimento do serviço 6010 e a data de envio de serviço correspondente 6170, emitindo o resultado como retardo de ida e volta de serviço 7040. O modelador de retardo ida e volta 7050 calcula um modelo de servidor independente da distribuição dessa diferença para cada serviço 6020, emitindo o resultado como modelo de retardo de serviço 6040. Na modalidade mais simples, o modelo de retardo de serviço compreende uma função constante específica de serviço, calculada como o tempo de ida e volta médio em todos os servidores ativos, que é o mínimo quadrado de melhor ajuste. Na modalidade preferida, o modelo para cada serviço tem cache em consideração pela decomposição dos dados de ida e volta para distribuições em cache contra não em cache, onde o cache é determinado solicitando o mesmo serviço do mesmo servidor, em rápida sucessão.

Da mesma forma, para cada transação de serviço temporizada, o modelador de retardo de servidor 7020 usa diferenciador 7060 para calcular o retardo de solicitação de serviço 7070 como a diferença entre a data de resposta nominal 6160 e a data de envio de solicitação de serviço correspondente 6170; usa diferenciador 7080 para calcular o retardo de resposta de serviço 7090 como a diferença entre cada data de recebimento de serviço 6190 e a data de resposta nominal correspondente, e usa o diferenciador 7100 para calcular o retardo de resposta de serviço 7110 como a diferença entre cada data de recepção de serviço 6190 e a data de resposta nominal correspondente. Buscador de modelo de serviço 7120, então, busca os parâmetros de duração de serviço 7130 para o serviço identificado por um identificador de serviço 6020 a partir de modelos de serviço 5020.

Na modalidade mais simples, os parâmetros de duração de serviço utilizados pelo modelador de retardo de servidor compreender o tempo médio do serviço. Finalmente, mo-delador de retardo de solicitação 7140 modela o retardo de solicitação para cada servidor 6010 como uma função da duração de serviço, que ele emite como o modelo e retardo de solicitação 7150; o modelador de retardo de resposta 7160 da mesma forma modela o retardo de resposta para cada servidor como uma função da duração de serviço, que ele emite como modelo de retardo de resposta 7170, e o modelador de retardo de resposta 7180 da mesma forma modela o retardo de resposta para cada servidor como uma função da duração de serviço, que ele emite como modelo de retardo de resposta 7190; estes três modelos compreendendo o modelo de retardo de servidor 6050. Na modalidade mais simples, o modelador de retardo de servidor modela a solicitação de serviço, resposta de serviço, e retar- dos de resposta de serviço como funções afins específicas de servidor da duração do serviço intrínseco, calculada pelo melhor ajuste dos mínimos quadrados, cada função especificada por um parâmetro de polarização aditivo e um parâmetro de taxa multiplicativa. Na modalidade preferida, o modelo para cada um dos três componentes de retardo de serviço também leva em consideração o cache, pela decomposição dos dados observados para cada uma das duas funções afins separadas, uma para quando o serviço está em cache, a outra  para quando não é armazenada cache.

Na modalidade preferida, o modelador de retardo de servidor e modelador de retardo de serviço considera para o efeito de criptografia - tal como TLS ou SSL - em temporização de serviço implicitamente, considerando as versões criptografadas contra criptografadas como serviços distintos, separadamente. Normalmente, isso acontece automaticamente, como resultado da convenção de dar serviços de segurança criptografados de URLs distintas, como "https: ..." versus "http: ...".

Note-se que, uma vez que a largura de banda da conexão entre o modelador de temporização de servidor e os servidores para um website é tipicamente, pelo menos, tão grande quanto a de qualquer cliente, o seu efeito sobre a duração de servir é relativamente insignificante.

Tal como ilustrado na fig. 8, o sincronizador de servidor 5040, para uso no recons- trutor de sessão 3030 (Ver Fig. 5), ajusta a marca de tempo de data de resposta 6160 em cada registro de transação de website de entrada 3020 por imprecisões nas configurações do relógio do servidor 6010 e para a indeterminação da fase de serviço, usando estimador de data de recebimento 8050, estimador de data de envio 8080, e o estimador de data de envio 8110 para estimar com precisão a data de recebimento do servidor 8060, data de envio 8090, e data de envio 8120, respectivamente, para aquela transação, e emitindo essas estimativas em registro de transação de saída sincronizado pelo servidor aumentado correspondente 5050. O sincronizador de servidor baseia esses ajustes no modelo de temporização 5020 para o modelo de temporização de servidor e serviço 5030 para o servidor.

Para detectar ataques man-in-the-browser, ataques man-in-the-middle, ataques ro- bóticos repetitivos e tipos semelhantes de ataques de website, que são caracterizados por transações anormalmente ordenadas e transações anormalmente rápidas, marcas de tempo de servidor precisas são críticas. Dando a transação o classificador 5050 (Ver Fig. 5) precisa e exata datas pelas quais ele escolhe os registros de transações, ele pode determinar se a ordem das transações em uma sessão aparece anômala. Ao dar comparador de evento 18020 (Veja fig. 18) estimativas de duração de evento exatas e precisas, pode-se determinar se um evento é anormalmente rápido.

Embora para dados de não fluxo contínuo, websites costumam se comunicar com clientes via TCP/IP, que garante a ordem do pacote, no entanto, uma sessão de tomada de TCP separada é criada para cada página, por isso, se um cliente abre uma pluralidade de páginas ao mesmo tempo, essas solicitações podem viajar ao longo das rotas diferentes e ser recebidas pelo website fora de ordem, e elas podem ser processadas por servidores de diferentes velocidades e respondidas fora de ordem, e as respostas podem igualmente viajar por percursos diferentes e alcançar o cliente fora de ordem. Note, no entanto, que dentro de uma única sequência de processamento, por exemplo, dentro de uma única janela de navegador ou guia, as ações do cliente e ações do websiteestão necessária e estritamente ordenadas, no direção de que o cliente tem para receber cada ação de website antes de ser capaz de responder, enquanto que o websitetambém tem de receber cada ação do cliente antes de ser capaz de responder.

Para cada registro de transação de entrada 3020, o modelador de serviço e servidor 5010 extrai o identificador de serviço 6020 e passa ele para o buscador de modelo de serviço 8030, extrai o identificador de servidor 6010 e passa para o buscador de modelo de servidor 8030, e extrai a marca de tempo de data de resposta de servidor 6160, que passa diretamente a cada um dos estimadores de data de servidor: estimador de data de recebimento 8050, estimador de data de envio 8080, e estimador de data de envio 8110.

O buscador de modelo de serviço 8010 usa o identificador de serviço 6020 para procurar o modelo de temporização de serviço adequado 5020, que ele emite para o esti- mador de data de recebimento 8050, estimador de data de envio 8080, e estimador de data de envio 8110. Na modalidade mais simples, mostrada aqui, o modelo de temporização de serviço compreende uma duração de serviço média 8020.

O buscador de modelo de servidor 8030 usa identificador de servidor 6010 para buscar o modelo de temporização de servidor adequado 5030, que igualmente emite para os estimadores de data do servidor. Na modalidade mais simples, mostrada aqui, para cada um dos três estimadores de data do servidor, estimador de data de recebimento 8050, esti- mador de data de envio 8080, e estimador de data de envio 8110, o modelo de temporização do servidor compreende uma função afim da duração de serviço, cada função afim sendo especificada por um parâmetro de taxa multiplicativa (taxa de recebimento 8040, taxa de envio 8070, e taxa de enviado 8100) e um parâmetro de polarização aditivo (polarização de recebimento 8160, polarização de envio 8220, e polarização de enviado 8280), respectivamente.

Estimador de data de recebimento 8050 estima o a data de recebimento do servidor 8060 - o instante em que o servidor recebeu a solicitação de serviço, ajustando a marca de tempo da data de resposta do servidor 6160 pela polarização de recebimento do servidor 8160 e o produto da taxa de recebimento do servidor 8040 e a duração do serviço 8020.

No detalhe, o multiplicador 8140 multiplica a estimativa de duração do serviço pela estimativa de taxa de recebimento de servidor, emite o resultado como estimada de duração de recebimento 8150. Adicionador 8170 então adiciona a estimativa de duração de recebimento ao receber estimativa de polarização, emitindo a soma como estimativa de retardo de recebimento total 8180. Finalmente, subtrator 8190 subtrai a estimativa de retardo de recebimento da data de resposta gravada, emitindo a diferença como estimativa de data de recebimento ajustada 8060.

Da mesma forma, o estimador de data de envio 8080 estimativas a data de envio do servidor 8090 -o instante em que o servidor começou a enviar a resposta de serviço ajustando a marca de tempo da data de resposta do servidor 6160 pela polarização de envio do servidor 8190 e o produto da taxa de envio de servidor 8070 e a duração do serviço 8020. Em detalhe, o multiplicador 8200 multiplica a estimativa de duração de serviço pela estimativa da taxa de envio do servidor, emitindo o resultado como estimada de duração de envio 8210. O adicionador 8230 em seguida, adiciona a estimativa de perda de envio para a estimativa de polarização de envio, emitindo a soma como estimativa de retardo de envio total 8240. Finalmente, subtrator 8250 subtrai a data de resposta gravada da estimativa de retardo de recebimento, emitindo a diferença como estimativa de data de envio ajustada 8090.

Do mesmo modo, estimador de data de envio 8110 estima a data de envio do servidor 8120 -o instante em que o servidor terminar de enviar a resposta de serviço - ajustando a marca de tempo da data de resposta do servidor 6160 pela polarização enviada de servidor 8280 e o produto da taxa de enviado do servidor 8100 e a duração do serviço 8020. Em detalhe, o multiplicador 8260 multiplica a estimativa de duração do serviço pela estimativa da taxa de enviado do servidor, emitindo o resultado como estimativa de duração de enviado 8270. O adicionador 8290 adiciona então a estimativa da duração enviada para à estimativa de polarização enviada, emitindo a soma como estimativa de retardo enviada total 8300. Finalmente, subtrator 8310 subtrai a data de resposta gravada da estimativa de retardo de recebimento, emitindo a diferença como estimativa de data enviada ajustada 8120.

Finalmente, editor de registro de transação 8130 aumenta o registro de transação de entrada 3020 para incluir estimativa servidor de data de recebimento de servidor 8060, estimativa de data de envio de servidor 8090, e estimativa de data enviada de servidor 8130, emitindo o registro de transação aumentada como registro de transação sincronizada 5050.

Muitas vezes, a resposta a uma solicitação de serviço é montada a partir de um número de componentes de serviço que podem diferir nas suas características de temporizaçãode serviços, desde que um número de servidores possa diferir nas suas características de temporização de servidor. Por exemplo, uma página web pode incluir texto estático, texto específico do cliente dinâmico, imagens e outros materiais, e pode até mesmo incluir outros serviços da web, por exemplo, em quadros separados de HTML. Nestes casos, na modalidade preferida, o estimador de data de recebimento 8050, estimador de data de envio 8080, e estimador de data de enviado 8110 acumulam os retardos de recebimento 8180, retardos de envio 8240, e retardo de enviado 8300, respectivamente, antes de subtrair a data de resposta, emitindo uma estimativa de data de recebimento única 8060, estimativa de data de envio única 8090, e estimativa de data de enviado única 8120, respectivamente, para toda a transação.

Deve ser notado que a temporização relativa (e, possivelmente, absoluta) de eventos pode ser feita como descrito aqui ou através de métodos convencionais, se disponível.

A Fig. 9 descreve Separador de sessão 5080, para uso em reconstrutor de sessão 3030 (Ver Fig. 5). Para agregar transações individuais em sessões de clientes individuais e segregá-las de outras sessões de clientes, o separador de sessão 5080 identifica clientes, principalmente com base em cinco tipos específicos de informações fornecidas em registros de transação classificados 5070 a partir do cabeçalho HTTP e informações de cabeçalho IP: endereços cliente e IP proxy, o ID de login de autorização; endereço de e-mail do cliente, o cookie da sessão, o ID de consulta de sessão, e as URLs atual e de referência. Infelizmente, todas essas cinco origens de informação são não confiáveis, ambíguas, degeneradas, ou não confiáveis. Na verdade, exceto para os endereços IP, que são de confiança, e os cookies, que são inequívocos em sessões legítimas, todas essas origens de informação de identificação sofrem de todas essas quatro deficiências. Em alguns websites, particularmente para implantações de retaguarda, um ID de conta interna também pode estar disponível, que, embora relacionado a esses outros tipos de informações, pode ser distinta da deles.

O endereço IP de origem e o endereço IP de destino são necessários em todas as solicitações e respostas HTTP, como parte do cabeçalho do pacote IP, fazendo com que o endereço IP, o único entre os cinco tipos específicos de informações de identificação, de forma confiável presente em todos os registros de transações. No entanto, o valor do endereço IP é um discriminante inadequado de sessões de cliente, porque no uso legítimo da relação entre endereços IP e clientes é ambígua (um-para-muitos) e degenerada (muitos- para-um). Por um lado, um único endereço IP é compartilhado por vários clientes, por exemplo, quando os clientes compartilham um roteador em uma rede de área local, ou quando compartilham um proxy ou um firewall. Embora em tais casos os clientes sejam diferenciados pelo número de porta no endereço IP estendido, o mapeamento entre o cliente e a porta é efêmero. Em tais casos, os clientes podem também ser distinguidos por HTTP transmitido para campo no cabeçalho da solicitação, mas aquele campo é opcional. Por outro lado, um único cliente pode utilizar vários endereços IP em uma única sessão, por exemplo, quando um cliente móvel é automaticamente comutado entre torres de celular durante a viagem, quando um cliente liga-se automaticamente ou intencionalmente comutado entre roteadores sem fio devido à interferência em um ambiente sem fio congestionado, ou quando se utiliza um sistema multihoming com vários endereços IP públicos. Além disso, o endereço IP e o campo Encaminhado para em um cabeçalho de solicitação de cliente não são confiáveis na medida em que podem ser falsificados por um invasor, por exemplo, a fim de camuflar os tempos de resposta do cliente e a ordem de transações.

A fim de receber as respostas do website, um invasor deve, naturalmente, ter o con- trole dos endereços IP falsos, por exemplo através da posse legítima, sequestrando o endereço IP através de malware instalado no sistema do cliente naquele endereço IP, ou roubando o endereço IP envenenando o tradutor de endereços de rede em qualquer roteador ao longo da rota para redirecionar o tráfego para o sistema do invasor, ou envenenamento os caches de resolução de endereço dentro de uma rede de área local para direcionar o tráfego para o sistema do invasor. Para certos tipos de ataques, no entanto, tais como ataques de negação de serviço em websites inundando os websites com solicitações, os ataques de negação de serviço em clientes inundando os clientes com as respostas, ou ataques difamando ou colocando os clientes em lista negra, atribuindo ou ações ofensivas ou hostis a eles, os invasores não têm necessidade de receber respostas do website. Nos ataques man-in-the-browser, o invasor compartilha automaticamente o endereço IP do cliente.

O ID de login especificado no campo de cabeçalho de solicitação de Autorização de HTTP, ao contrário do endereço IP, é não confiavelmente presente, porque muitos websites não fazem uso do mesmo, em vez de comunicar a informação de autorização no campo cookie ou em uma sequência de consulta no URL e porque a maioria dos websites permitem que os clientes visitem determinadas áreas e executem certos tipos de ações sem efetuar login. Muitos visitantes para um website que não tem uma conta no website para assinar, e aqueles clientes com contas válidas em um website, muitas vezes evitam de entrar, devido a preguiça ou preocupações de privacidade. No entanto, para websites que usam autorização HTTP para restringir o acesso a regiões privilegiadas, o ID de loginé, quando devidamente implementado pelo website, de forma confiável presente em solicitações HTTP para serviços dentro dessas regiões. Como endereços IP, IDs de loginsão legitimamente identificadores do cliente ambíguos e degenerados. Por um lado, vários clientes geralmente compartilham o mesmo ID de login, por exemplo, em situações em que um ou mais usuários estão ajudando os outros com suas contas, um ou mais usuários estão supervisionando os outros, ou quandovárias pessoas em uma empresa ou uma família usam o mesmo ID de login. Por outro lado, um único cliente pode usar IDs de loginmúltiplos, por exemplo, quando um cliente tem várias contas independentes, ou está servindo um número de clientes com contas independentes no website. IDs de logintambém são pouco confiáveis, uma vez que muitas vezes  são falsificados por invasores, por exemplo, ataques adivinhando senhas na força bruta, em ataques man-in-the-middle, e para contas roubadas. Nos ataques man-in-the-browser, o invasor compartilha automaticamente o ID de login.

O endereço de e-mail especificado no HTTP a partir do campo de cabeçalho de so-licitação é muito pouco confiável, porque, para proteger a privacidade dos usuários e para evitar spam, não é implementado pela maioria dos navegadores modernos, e geralmente é fornecido apenas por redes em teia escrupulosas e robôs. A partir do endereço de e-mail também é legitimamente ambíguo e degenerado, pois por um lado, vários usuários muitas vezes compartilham uma conta de e-mail, por exemplo, em uma família ou empresa de pequeno porte, onde uma pessoa é Internet-savvy ou imperioso, enquanto, por outro lado, um único usuário pode muitas vezes ter várias contas de correio eletrônico, por exemplo, para casa e escritório. Se o endereço de e-mail disponível, for mais ou menos como tão não confiável quanto o endereço IP, em que é facilmente falsificado, mas, a fim de receber quaisquer respostas enviadas para esse endereço de correio eletrônico, o invasor precisa ter acesso à conta de e-mail.

O cookie especificado no campo de cabeçalho de solicitação cookie HTTP está presente de forma incerta, porque os clientes podem se recusar a aceitar cookies do website e, portanto, não devolver os cookies para o website, e os navegadores modernos tornam-se mais fáceis para os usuários em recusar cookies. Por outro lado, os websites podem se recusar a atender aos usuários que recusam cookies, e muitos websites conscientes da segurança o fazem. Além disso, quando presente e devidamente implementado pelo website para incluir uma sessão exclusiva de identificação, um cookieé o identificador do cliente mais específico que o HTTP provê, porque a relação entre clientes e cookies de sessão pode ser de um para muitos, mas não legitimamente, de muitos para um: Um único cliente pode ter várias sessões de cookiessimultâneas com um website usando vários aplicativos para acessar o website, por exemplo, quando se utiliza mais de um navegador para se conectar ao website por causa de incompatibilidades website-browser, ou ao usar aplicativos de automação para desempenhar funções de rotina no website. Em contraste, um cookiesó pode ser compartilhado, se for deliberadamente roubado, por exemplo, através da cópia do cookie utilizando malware instalado no sistema do destinatário pretendido, interceptando-o através de um website falsificado, tomando o cookie com um farejador de pacote, ou encaminhando o cookie pelo script de sítio cruzado, ou se o cookieé deliberadamente plantado ou "fixo", por exemplo, obtendo o navegador da vítima para armazenar o cookie via cookie cross-site ou scripting de subdomínio cruzado.

Em alguns websites, uma sequência de consulta especificando o ID de sessão é anexada ao URL atual.

Os IDs de sessão de sequência de consulta são suscetíveis a colheita em um website referido a partir da sequência de consulta de URL no campo Referidor HTTP, e para fixação de sessão enviando um e-mail a vítima um hiperlink especificando um ID de sessão em uma sequência de consulta de URL, onde O ID de sessão pode ser gerado pelo invasor ou pelo website alvo.

URLs de referência, especificadas no campo Referidor HTTP, são inconfiavelmente presentes, porque, para ajudar a proteger a privacidade dos usuários, alguns serviços, na-vegadores e extensões do navegador permitem que referências sejam desativadas.

As marcas de tempo, além de serem utilizadas para classificar as transações por ordem cronológica, são também utilizadas para ajudar a separar as sessões com base em transações de sobreposição. Note, entretanto, que um único cliente pode legitimamente ter transações de sobreposição, por exemplo, abrindo ou operando simultaneamente várias janelas do navegador abertas para o mesmo website.

Além marcas de tempo e esses cinco tipos específicos de informação, o separador de sessão também pode usar tipos genéricos de informações especificadas em cabeçalhos de Solicitação de HTTP, incluindo Accept (tipos de conteúdo aceitável), Accept-Charset (conjuntos de caracteres aceitáveis), Accept-Encoding (codificações aceitáveis), Accept- Language (linguagens aceitáveis), Accept-Ranges (faixas de tamanho aceitáveis), UserAgent (nome e detalhes de aplicação web), e Via (proxies através dos quais a solicitação foi enviada). Todos estes cabeçalhos de solicitação HTTP são opcionais e, portanto, não confiáveis. Além disso, todos eles são pouco confiáveis, sendo facilmente falsificados. Alguns navegadores e navegadores plug-in freeware ainda existem para permitir que usuários co muns convenientemente alterem alguns desses cabeçalhos durante uma sessão. No entan-to,falsificação de informações não-específicas, durante uma sessão não afeta qualquer um dos identificadores de sessão específicos. Alterações em qualquer um destes tipos de informação genéricas durante uma sessão podem ser marcadas como potencialmente indicando que a sessão foi sequestrada.

O Separador de sessão, assim, separa 9010 os registros das transações classificadas 5070 de acordo com o ID de cookie, se disponível, como chave primária, em sequências primárias 9020 e segrega 9030 as sequências primários de acordo com ID de conta, ID de login, ID de sessão de consulta, ou endereço de e-mail, como disponível, chaves como secundárias, em sequências secundárias 9040; e segrega 9050 as sequências secundárias por endereço IP como a chave terciária em sessões de cliente 5100.

Como descrito no diagrama de fluxo de informação da Fig. 10, o modelador de agente 5110, para uso no reconstrutor de sessão 3030 (Ver Fig. 5), analisa as características de temporização dos agentes individuais usando modelador de temporização de solicitação de agente 10020 e modelador de carga 10030 e emite modelos de temporização de agente 5120. Modelagem de agente é feita off-line em um ambiente de testes de laboratório, executando precisamente scripts cronometrados sobre as combinações de hardware, sistema operacional e aplicativos empregados pelos clientes para utilizar os serviços do website, como registrado, no caso de páginas web HTML, pelo campo de agente de usuário 10010 nos cabeçalhos de solicitação de HTTP dos registros de transações 3020 recebidas pelo website. Assumir a largura de banda a partir do centro de dados do website 1030 para os sistemas de teste de agente 10060 é disposto para ser pelo menos tão grande quanto a o centro de dados do website para qualquer cliente real.

O modelador de agente 5110 insere registros de transação 3020 e extrai o identificador de agente 10010 para obter uma lista de agentes de usuário utilizados para visitar o website, e extrai o identificador de serviço 6020 para obter uma lista de serviços providos pelo website, e provê tanto estes identificadores para o modelador de temporização de solicitação de agente 10020.

Para cada agente de usuário ativo disponível 10010, o modelador de agente usa modelador de temporização de solicitação de agente 10020 para modelar o retardo de solicitação do agente 10130, e usa o modelador de carga de agente 10030 para modelar o retardo de carga de agente 10190.

O modelador de temporização de solicitação 10020 usa temporizador de solicitação 10040 para medir as características de temporização de cada agente disponível 10060 iden-tificadas pelo identificador de agente 10010, para cada serviço utilizado pelo agente, identificado pelo identificador de serviço 6020, ou para um número estatisticamente significativo e a variedade de tais serviços, e usa comparador de data de solicitação de agente 10110 para modelar a distribuição estatística das características do agente de solicitação temporização.

Especificamente, para cada agente de usuário ativo disponível e cada serviço solicitado pelo agente a ser testado e com esse agente, o temporizador de solicitação de agente é executado um script 10050 em que o agente 10060 para emissão de um número estatisti-camente significativo de pedidos de 6130 para aquele serviço a partir do website 1030. O script reporta de volta ao temporizador de solicitação o tempo no instante em que um clique simulado em um hiperlink solicitando o serviço através do agente ou de outra forma natura- listicamente causado o agente a emitir uma solicitação para o serviço, que data os registros de temporizador de solicitação como data de clique 10070. O script em seguida monitora o sistema de agente e relata de volta para o temporizador de solicitação o tempo no instante em que o agente começou a transmitir a solicitação, que os registros de temporizador de solicitação como a data de envio de solicitação 10080, e o tempo no instante em que o agente terminou de transmitir a solicitação, que os registros do temporizador como a data de solicitação de enviado 10090. O temporizador de solicitação também registra o tamanho da solicitação 10120. A data de clique, data de envio de solicitação e data de solicitação de enviadosão cada uma dada pelo tempo atual 6110 de acordo com o relógio mestre 6100, para o qual todos os agentes a serem temporizados estão sincronizados. O scripttambém reporta de volta a data de solicitação nominal registrada na solicitação de serviço pelo agente - no campo Data do cabeçalho de solicitação de HTTP, no caso de páginas de HTML - que o temporizador de solicitação como a data de solicitação de serviço 10100.

A data de solicitação de serviço não está sempre disponível para solicitações de serviços, para solicitações HTTP, por exemplo, o campo Data no cabeçalho de Solicitação de HTTP é opcional, e alguns navegadores e outros aplicativos da web proveem um controle de interface de usuário para bloquear a saída da data da solicitação.

Para clientes fornecendo uma data de solicitação de serviço 10100 através de seu agente, comparador de data de solicitação de agente 10110 modela a distribuição da diferença entre a data de clique 10070 e a data de solicitação nominal, entre a data de envio de solicitação 10080 e a data de solicitação nominal, e entre a data de solicitação de enviado 10090 e a data da solicitação nominal. Para clientes que bloqueiam a data de solicitação de serviço, o comparador de data de solicitação também modela a distribuição da diferença entre a data de envio de solicitação e a data de clique, e entre a data de solicitação de enviado e a data de clique. O comparador de data de solicitação de agente modela cada um desses cinco modelos como uma função da solicitação, e emite as funções como o modelo de retardo de solicitação 10130, como parte de agente de temporização de agente 5120 para o agente identificado pelo identificador de agente 10010. Na modalidade mais simples, o comparador e data de solicitação de agente modela cada um destes retardos como uma função afim específica de agente do tamanho da solicitação 10120, calculada pelo melhor ajuste de mínimos quadrados, cada função especificada por um parâmetro de polarização aditivo e um parâmetro de taxa multiplicativa.

O modelador de temporização de solicitação de agente 0030 usa temporizador de carga de agente 10140 para medir as características de temporização de cada agente disponível 10060 identificado pelo identificador de agente 10010, para cada serviço testado pelo modelador de temporização de solicitação de agente 10020, e usa comparador de data de carga 10180 para modelar a distribuição estatística das características de temporização de carga do agente.

Especificamente, para cada solicitação de serviço emitida pelo modelador de tem-porizaçãode solicitação de agente 10020, script de temporização de agente 10050 monitora o sistema do agente e relata de volta para o temporizador de carga de agente 10140 o tempo no instante que o sistema do agente começa a receber o serviço, que o temporizador de carga registra como data de recebimento de resposta 10150, e relata de volta para o tempo- rizador de carga no instante em que o agente termina de carregar o serviço, ou, mais preci-samente, no instante que o cliente pode responder ao serviço, por exemplo, clicando em hiperlinks, no caso de uma página web HTML, que o temporizador de carga registra como data de serviço carregado 10160. O temporizador de carga também registra o tamanho do serviço 10170.

Na modalidade preferida, se uma única solicitação de serviço 6130 recebe múltiplas respostas de serviços 6150, o script de carga e temporizador de carga rastreiam cada um destes serviços separadamente para maior precisão. As datas de recebimento de resposta e as datas de serviços carregados são dadas pelos respectivos tempos atuais 6110 especificados pelo relógio mestre 6100.

O comparador de data de carga 10180 modela a distribuição da diferença entre a data de serviço carregado 10160 e a data de recebimento de resposta 10150 como uma função do serviço, e emite a função como modelo de retardo de carga 10190, como parte de modelo de agente 5120.

Na modalidade mais simples, o comparador de data de carga modela a distribuição como uma função afim específica do agente do tamanho do serviço 10170, calculada pelo melhor ajuste de mínimos quadrados, especificado por um parâmetro de polarização aditivo e um de parâmetro taxa multiplicativa. Na modalidade preferida, o modelo de recarga de carga especifica parâmetros afins separados para o texto simples contra serviços não criptografados, e para elementos de serviço de velocidades de carga divergentes, tais como HTML, imagens que utilizam formatos de compressão diferentes, e mensagens temporizadas que o cliente deve atender antes de prosseguir. Na modalidade preferida, o modelo de retardo de carga também envolve separar os modelos de retardo de carga para os serviços de cache vsnão cache.

Se o temporizador de solicitação ou temporizador de carga não receber uma resposta do script dentro de um período razoável de tempo, tipicamente alguns segundos - então, ele emite uma notificação 10220 para os administradores de teste alertando que o agente está levando mais tempo do que o esperado e especificando o agente e o serviço que provocou o problema.

Além de emitir modelos de temporização de agente 5120 para uso pelo modelador de cliente 5130 e sincronizador de cliente 5150 (Ver Fig. 5), o modelador de agente 5110 também usa analisador de agente 10200 para emitir resumo de agente 10210 resumindo os agentes 10010 utilizados para visitar a website, juntamente com a sua frequência de utilização. Para esses agentes disponíveis para o teste, o resumo de agente resume também os seus tempos de carga para diferentes tipos de serviços, enquanto aqueles disponíveis são marcados para requisição possível para testes futuros. O resumo do agente também é útil para pesquisa de desenvolvimento de website, por exemplo, para determinar quais agentes do website devem otimizar por causa de sua popularidade, ou para determinar se formas alternativas de determinados serviços devem ser fornecidas para os agentes que tomam muito tempo, e para pesquisa de marketing, por exemplo, para determinar as preferências do cliente.

Para maior eficiência, modelagem de temporização de agente pode ser integrada com os testes de controle de qualidade normais do website.

Como descrito no diagrama de fluxo de informações da Fig. 11, modelador de tem-porizaçãode cliente 5130, para uso no reconstrutor de sessão 3030 (Ver Fig. 5), estima e rastreia as características de temporização 5140 (Ver fig. 5) para cada cliente website que acessa o website durante o período de coleta de dados, utilizando modelador de retardo de serviço de cliente 11030 para medir e modelar as estatísticas de retardo de serviço de cliente 11090, usando modelador de temporização de eco 11040 para medir e modelar as estatísticas de retardo de eco de cliente 11180, ou, se o eco falhar, usar modelador de temporizaçãode traço 11050 para medir e modelar as estatísticas de retardo de traço de cliente 11260, ou, se o traço também falhar, aplicar o modelador de retardo de eco ou modelador de retardo de eco ao proxy de resposta mais próximo ao cliente localizado por Achador de proxy próximo 11020, e comparar a estimativa de retardo de serviço com o retardo de eco de serviço nulo ou retardo de traço.

Muitos provedores de serviço de Internet bloqueiam solicitações de ping e rotas para impedir a sua rede de ser mapeada por clientes maliciosos, e alguns clientes individuais também bloqueiam solicitações de ping para reduzir a visibilidade de seus sistemas e, as-  sim, reduzir o número de ataques de rede em seus sistemas.

O modelador de temporização de cliente 5130 insere registros de transações de cliente 5090 e extrai o identificador de cliente 11010 para obter uma lista de todos os clientes ativos durante o período de coleta de dados, que fornece ao modelador de temporização de serviço de cliente 11030, modelador de temporização de eco e cliente 11040, modelador de temporização de traço de cliente 11060, e achador de proxy próximo 11020. Para cada transação de cliente, o modelador temporização de cliente usa o modelador de temporização de serviço para estimar o retardo de serviço com base na data de solicitação de serviço 10100 (se disponível), o identificador de agente de usuário 10010, tamanho de solicitação 10120, e identificador de serviço 6020, que são obtidos a partir do registro de transação. O identificador de cliente consiste no endereço IPv6 ou IPv4 e número de porta no TCP ou cabeçalho de pacote UDP, o número de porta sendo necessário para os clientes em uma rede privada por trás de um roteador, firewall, proxy ou outro. No caso de páginas web HTML, a data de solicitação de serviço é originalmente proveniente do campo Data no cabeçalho da solicitação HTTP, e o agente de usuário é proveniente do campo User-Agent. O tamanho da solicitação é obtido a partir da soma dos comprimentos de cabeçalho HTTP e o valor do campo Content-Length, ou proveniente dos campos de comprimento TCP ou UDP.

Durante o período de coleta de dados, modelador de temporização de serviço de cliente 11030 usa temporizador de serviço de cliente 11060 para medir as características de temporização de cada cliente ativo identificado pelo identificador de cliente 11010, e usa comparador de data de serviço de cliente 11080 para modelar a distribuição estatística das características de retardo de serviço de cliente 11090. Especificamente, no momento em que cada ação do cliente 1020 (Ver a Fig. 1.) é recebida pelo processador de tráfego do website 2010 (ver Fig. 2.), temporizador de serviço de cliente 11060 emite marca de tempo de data de recebimento de serviço 11070 a partir do momento atual 6110 dado pelo relógio mestre 6100.

Para cada transação de serviço, o comparador de data de serviço de cliente 11080 calcula o retardo de solicitação de serviço de cliente, a partir da marca de tempo de data de solicitação de serviço 10100 (se disponível), o identificador de agente de usuário 10010, o tamanho da solicitação 10120, a marca de tempo de data de recebimento de serviço do pro-cessador de tráfego de servidor 11070, e um modelo de agente de usuário 5120 identificado pelo identificador de cliente e emite um modelo de distribuição como modelo de retardo de serviço de cliente 11090. O comparador de data de serviço de cliente é detalhado sob figura 12.

Durante o mesmo período de medição, o modelador de temporização de eco de cliente utiliza temporizador de eco 11100 para medir as características de temporização de agente nulo de cada cliente ativo 11010, e usa o comparador de data de eco 11170 para modelar a distribuição estatística das características temporização de agente nulo. Especificamente, para um cliente ativo, o temporizador de eco emite um número estatisticamente significativo de solicitações de eco 11110 de vários tamanhos para o cliente ou um substituto próximo 11120, emitindo marca de tempo de data de eco 11140 no momento em que ele envia a solicitação de eco, e emitindo marca de tempo de data de recebimento de eco 11150 no momento em que ele recebeu a resposta de eco 11130 de volta do cliente, cada marca de tempo dada pelo respectivo tempo atual 6110 dado pelo relógio mestre 6100. O temporizador de eco também registra o tamanho da solicitação de eco 11160.

Quando a resposta de eco 11130 é retardada por mais de um limite razoável - nor-malmentenão mais do que alguns segundos, dependendo da distância para o cliente e nas condições atuais de rede - então modelador de temporização de eco 11040 aborta a tentativa de ping, sob a pressuposto de que o cliente está bloqueando solicitações de ping, e o modelador de temporização de cliente 5130 tenta de temporização de traço em seu lugar.

Para cada cliente ativo, o comparador de data de eco 11170 calcula a diferença entre cada tempo de recebimento de eco 11150 e tempo de envio de eco correspondente 11140 para uma amostra estatisticamente significativa de solicitações de eco de vários tamanhos 11160, e emite um modelo da distribuição do resultado como retardo de eco 11180.

Na modalidade mais simples, o modelo de retardo de eco específico de cliente compreende a metade do tempo de eco médio para cada direção e metade da variação do tempo de eco para cada direção, cada um como uma função afim do tamanho da solicitação de eco, calculada pelo melhor ajuste dos mínimos quadrados, em que a função é especifi-  cada por um parâmetro de polarização aditivo e um parâmetro de taxa multiplicativa.

A modalidade preferida também leva em consideração as assimetrias conhecidas de velocidade e largura de banda na taxa de transmissão da conexão de Internet em cada extremidade, conforme determinado para alguns clientes do endereço IP do cliente 11010, dividindo o tempo de eco de ida e volta em duas partes inversamente proporcionais ao ren-dimento nessa direção, e também proporcionalmente dimensionem a variância para cada direção.

O modelador de temporização de traço 11050 tem temporizador de rota de traço 11190 emite solicitações de rota de traço 11200 para o mesmo cliente 11010 ou proxy perto, aumentando etapa a etapa os valores de tempo-de-vida até que o nó do destino seja alcançado ou resposta de rota de traço 11210 seja retardada por mais de um limite razoável - novamente, tipicamente não mais do que poucos segundos, dependendo da distância para o cliente e das condições da rede atual. Se a última resposta ocorre dentro de um intervalo razoável, considerando as condições de distância e de rede, em seguida, o temporizador de traço emite marca de tempo de data de envio de eco 11220 correspondente ao momento em que ele enviou a última solicitação de rota de traço bem sucedida, e emite a marca de tempo de data de recebimento de traço 11230 correspondente ao momento em que ele recebeu a última resposta de rota de traço bem sucedida de volta do cliente, cada marca de tempo sendo dada pelo respectivo tempo atual 6110 de acordo com o relógio mestre 6100. O temporizador de traço também registra o tamanho da solicitação de traço 11240.

Analogamente ao comparador de data de eco, o comparador de data de traço 11250 calcula a diferença entre cada tempo de recebimento de traço final 11230 e tempo de envio de traço correspondente 11220 para uma amostra estatisticamente significativa de solicitações de traços de vários tamanhos 11240, e emite um modelo da distribuição do resultado como retardo de traço 11260.

Na modalidade mais simples, o modelo de retardo de traço específico de cliente compreende a metade do tempo de traço médio para cada direção e a metade da variação do tempo de traço, para cada direção, cada um como uma função afim do tamanho da solicitação de traço, calculada pelo melhor ajuste dos mínimos quadrados, em que a função é especificada por um parâmetro de polarização aditivo e um parâmetro de taxa multiplicativa. Mais uma vez, a realização preferida também leva em consideração as assimetrias conhecidas de velocidade e largura de banda na taxa de transmissão da conexão de Internet em cada extremidade, conforme determinado para alguns clientes do endereço IP do cliente 11010.

Se nem o modelador de temporização de eco 11040 nem o modelador de tempori-zaçãode traço 11060 conseguem fixar o retardo de ida e volta para o cliente real 11010, então o modelador de temporização de cliente usa achador de proxy próximo 11020 para encontrar o endereço IP 11310 de um proxy de ping nas proximidades. O achador proxy próximo primeiro usa o localizador de endereço 11280 para procurar a localização do nó 11290 do cliente real a partir do endereço IP do cliente 11010. Em seguida, a achador de proxy 11300 encontra o proxy de ping mais próximo ao local do nó, emitindo seu endereço IP como endereço de destino 11310. O modelador de temporização de cliente 5130 então substitui o endereço IP do servidor proxy ping para uso pelo modelador de temporização de eco 11040 e modelador de temporização de traço 11060. No caso de o proxy de ping selecionadotambém falhar, o modelador de temporização de cliente usa o localizador de proxy próximo iterativamente para encontrar outro proxy de ping até ter sucesso.

Finalmente, para cada cliente ativo (ou pelo menos alguns clientes), o comparador de retardo de cliente 11270 compara a distribuição do retardo de solicitação de serviço de cliente 11090 com a distribuição do retardo de eco do cliente 11180 ou retardo de rota de traço 11260, emitindo um modelo da distribuição do resultado como modelo de temporização de cliente 5140. Na modalidade mais simples, o modelo de temporização de cliente compreende o retardo de solicitação de eco ou retardo de solicitação de traço, tal como um par de funções afins do tamanho de solicitação 10120, um para a direção de transmissão e um para a direção de recebimento, cada função especificando o comportamento médio com um parâmetro de polarização aditivo e um parâmetro de taxa multiplicativa, bem como a variação na direção de transmissão, e, se as datas de solicitação são fornecidas pelo cliente, a diferença entre o retardo de solicitação de serviço de cliente e o retardo de solicitação de eco ou retardo de solicitação de traço, dando ao cliente médio polarização de relógio e sua variância. Para websites com mais de um centro de dados, o temporizador de cliente gera um modelo separado para cada centro de dados geograficamente separado.

Além de emitir modelos de temporização de cliente 5140 para uso pelo sincroniza- dor de cliente 5150 (Ver Fig. 5), modelador de temporização de cliente 5130 também usa analisador de cliente 11280 para emitir resumo de cliente 11290 resumindo os clientes 11010 que visitam o website, juntamente com seus endereços IP, localização geográfica e características de temporização, inclusive se ele fornecem datas de solicitação e respondem a solicitações de ping. O resumo de cliente também é útil para pesquisa de desenvolvimento de website, por exemplo, para determinar se provê serviços mais luxuosos para clientes com larguras de banda de conexão grandes e retardos de conexão curtos, ou serviços mais escassos para clientes com larguras de banda de conexão pequenas e retardos de conexão longos; e para pesquisa de mercado, para determinar onde estão localizados os clientes e que tipo de conexões eles têm.

O diagrama de fluxo de informação da Fig.. 12 descreve o comparador de data de serviço de cliente 11080 (Ver figura 11), que usa estimador de retardo de agente 12030 para estimar o retardo de agente 12100; diferenciador 12010 para medir o retardo de serviço bruto; diferenciador 12110 para comparar estas duas estimativas, e modelador de retardo de serviço 12130 para modelar o retardo de serviço 11090.

Para cada transação de serviço, o estimador de retardo de agente 12030 usa bus- cador de modelo de agente 12040 para buscar o modelo de agente identificado pelo identificador de agente 10010 a partir dos modelos de agente 5120. Se o registro de transação não especifica o agente, o estimador de retardo de agente utiliza o modelo de agente padrão, cujos parâmetros são definidos para os valores modais dos agentes conhecidos ativos durante o período de coleta de dados.

Na modalidade mais simples, mostrada aqui, o modelo de temporização de solicitação de agente, compreende parâmetro de polarização de solicitação específico de agente 12050 e o parâmetro de taxa de solicitação específico de agente 12060. O multiplicador 12070 então multiplica a taxa de solicitação do agente pelo tamanho da solicitação 10120, emitindo do produto como intervalo de solicitação de agente 12080. O adicionador 12090 em seguida, adiciona a polarização de solicitação de agente ao intervalo da solicitação de agente, emitindo a soma como retardo de agente total 12100.

Da mesma forma, para cada transação de serviço, o diferenciador 12010 calcula a diferença entre a marca de tempo de data de recebimento de serviço 11070 marca de tempo data e serviço de solicitação de serviço 10100, emitindo a diferença como retardo de serviço bruto 12020. O diferenciador 12110 calcula então a diferença entre o retardo de serviço bruto e o retardo de agente 12100 emitido pelo estimador de retardo de agente 12030 para a mesma solicitação, emitindo a diferença como modelo de retardo de serviço 12120.

Finalmente, para cada cliente, conforme identificado pelo identificador de cliente 11010, modelador de retardo de serviço 12130 modela a distribuição do serviço, e emite um modelo da distribuição dessa diferença como modelo de retardo de serviço 11090. Na modalidade mais simples, o modelo de retardo de serviço dá o retardo de solicitação de serviço, como o retardo médio de serviço para aquele cliente, que é o modelo de melhor ajuste de mínimos quadrados.

Como descrito no diagrama de fluxo de informações da Fig. 13, o sincronizador de cliente 5090, para uso no reconstrutor de sessão 3030 (Ver Fig. 5), insere um registro de transação de cliente 5090 de cada vez, e usa o comparador de variância 13080, estimador de data de clique 13010 e estimador de data de carga 13030, e editor de registro de transações 13050 para sincronizar a transação com as estimativas de data de carga e data de clique, emitindo registro de transação de cliente sincronizado correspondente 5160.

Estimador de data de clique 13010, usando a informação do registro transação de cliente de entrada 5090, o modelo de cliente 5140 identificado pelo identificador de cliente no registro de transações de entrada, e o modelo de agente 5120 identificado pelo identificador de agente no registro de transações de entrada, emite estimativa de data de clique, precisamente estimando o instante em que o cliente solicitou o serviço de destino a partir do website, tal como clicando em um link no serviço de origem, de acordo com o relógio mestre do detector de ameaças de serviço de rede. O estimador de data de clique é detalhado sob figura 14.

Do mesmo modo, a estimador de data de carga 13030, usando a informação pro- veniente do modelo de cliente 5140, o modelo de servidor 5030, o modelo de serviço 5020, e o modelo de agente 5120, como identificado pelo identificador de cliente, o identificador de servidor, o identificador de serviço, e o identificador de agente, respectivamente, no registro de transação de entrada, em adição a data de clique 13020 emitida pelo estimador de data de clique 13010 para o mesmo registro de transação, emite a estimativa da data de carga 13040, precisamente estimar o instante em que o agente de cliente terminou o carregamento do serviço de origem para o ponto em que o cliente foi capaz de agir sobre ele, por exemplo, clicando em um hiperlink, de acordo com o relógio mestre de detector de ameaças de serviço de rede. O estimador de data de carga é detalhado na figura 15.

O estimador de data de clique 13010 pode estimar a data de clique com base quer na marca de tempo de data de solicitação gravada pelo cliente, quando disponível, ou na data de recebimento Ed solicitação do servidor registrado pelo sincronizador de servidor. A estimativa de tempo de clique baseada em cliente é normalmente mais preciso porque ele depende apenas da polarização de relógio de cliente normalmente constante e breve retardo de clique de agente, enquanto que a estimativa baseada em servidor depende do tempo de transmissão altamente variável a partir do cliente e do servidor, o qual não pode ser estimado como preciso. Da mesma forma, o estimador de data de carga 13030 pode estimar a data de carga com base tanto na marca de tempo de data de carga gravada pelo cliente utilizando um temporizador de carga incorporado, quando disponível, ou na marca de tempo de data de envio de serviço do servidor gravada pelo sincronizador de servidor. Novamente, a estimativa de tempo de carga baseada em cliente é normalmente muito mais precisa porque depende apenas do relógio de cliente normalmente constante e breve retardo de clique de agente, enquanto que a estimativa baseada em servidor depende do tempo de transmissão altamente variável a partir do servidor para o cliente, e no tempo de carga altamente variável pelo cliente, nenhum dos quais pode ser calculada com a maior precisão. Por outro lado, as marcas de tempo de data emitidas pelo cliente são ambas inconfialvelmente presentes, sendo opcionais, por exemplo, na especificação do cabeçalho de Solicitação HTTP, e indignas de confiança, em que os fraudadores podem mexer com elas diretamente.

O comparador de variância 13080 primeiro verifica se a data de solicitação do clien- te 10100 e a data de carga do cliente estão disponíveis no registro de transações do cliente de entrada 5090. Caso um dos dois esteja disponível, o comparador de variância compara a variância na polarização de transmissão do cliente 13090 com a variância na polarização de relógio de cliente 13100, tal como determinado pelo modelo de cliente 5140 identificado pelo identificador de cliente no registro de transação de entrada. Se a diferença entre a variância de polarização de relógio e a variância de transmissão de polarização for maior que o limite de variância 13110, então, o relógio do cliente é considerado pouco fiável, caso contrário, é considerado digno de confiança, em que o limite de variância é tipicamente ajustado para um valor entre zero e um poucos centisegundos.

Se a data de solicitação do cliente está disponível e relógio do cliente é considerado confiável, então o comparador de variância define o comutador de estimador de dados de clique 13060 para usar o estimador de data de clique baseado em solicitação; senão ele define como usar o estimador de data de clique baseado em recebimento. Da mesma forma, se a data de carga do cliente e a data de solicitação do cliente estão disponíveis e o relógio do cliente é considerado confiável, então o estimador de variância define a comutação de estimador de data de carga 13070 para usar o estimador de data de carga baseado em solicitação; senão ele define como usar o estimador de data de carga.

Como descrito no diagrama de fluxo de informações da Fig. 14, para cada registro de transação de cliente de entrada, o estimador de data de clique 13010, para uso no sin- cronizador de cliente 5090 (Ver a Fig. 13.), ou usa estimador de data de clique baseado em recebimento 14010 para emitir estimativa de data de clique baseada em recebimento 14020, ou usa estimador de data de clique baseado em solicitação 14030 para emitir a estimativa de data de clique baseada em solicitação 14040, dependendo do valor da comutação de estimador de data de clique 13060.

Para estimador de data de clique baseado em recebimento 14010, buscador de modelo de agente 12040 procura o modelo de agente 5110 identificado pelo identificador de agente 10010 no registro de transação 5090, emitindo a taxa de solicitação de agente 12060 e polarização de solicitação de agente 12050, modelando o retardo entre a instante que o cliente solicita um serviço, por exemplo, clicando em um hiperlink no serviço de origem, e o instante em que o cliente começa a transmitir a solicitação. Da mesma forma, buscador de modelo de cliente 14070 procura o modelo de cliente 5130 identificado pelo identificador de cliente 11010 no registro de transação, emitindo a taxa de transmissão de cliente 14080 e polarização de transmissão de cliente 14090, modelando o retardo entre o instante em que o cliente começa a transmitir uma solicitação e o instante que o servidor recebe.

O multiplicador 14050 multiplica a taxa de solicitação de agente 12060 pelo tamanho da solicitação 10120, obtido a partir do registro de transação 5090, emitindo o produto como estimativa de duração de solicitação 14060. O multiplicador 14100 multiplica a taxa de transmissão de cliente pelo tamanho da solicitação 10120, emitindo o produto como estimativa de duração de transmissão 14110. Operador máximo 14120, então calcula o máximo desses dois valores, emitindo o resultado como estimativa de duração de solicitação total 14130. O adicionador 14140 então adiciona polarização de solicitação de agente 12050 e polarização de transmissão de cliente 14090, emitindo a soma como estimativa de polarização de solicitação total 14150. O adicionador 14160 em seguida, adiciona a duração de solicitação à polarização de solicitação, emitindo a soma como a estimativa de retardo de solicitação 14170. Finalmente, subtrator 14180 subtrai o retardo de solicitação da data de recebimento de solicitação do servidor 8060 obtida a partir do registro de transação do cliente, emitindo a diferença como estimativa de data de clique baseada em recebimento 14020.

Para o estimador de data de clique baseado em solicitação 14030, o buscador de modelo de agente 12040 procura o modelo de agente 5110 identificado pelo identificador de agente 10010 no registro de transação 5090, emitindo a taxa de clique de agente 14190 e polarização de clique de agente 14200, modelando o retardo entre o instante que o cliente solicita um serviço, por exemplo, clicando em um hiperlink no serviço de origem, e na data da solicitação 10100 registrada pelo agente no registro de transação de cliente com um relógio sincronizado. O buscador de modelo de cliente 14070 procura o modelo de cliente 5130 identificado pelo identificador de cliente 11010 no registro de transação, emitindo a polarização de relógio de cliente 14250, modelando a diferença entre a configuração do relógio de cliente e o relógio mestre do detector de ameaça de serviço de rede.

O multiplicador 14210 multiplica a taxa de clique de agente 14190 pelo tamanho da solicitação 10120, emitindo o produto como estimativa de duração de clique de agente 14220. O adicionador 14230 em seguida, adiciona a duração de clique à polarização de clique de agente 14200, emitindo a soma como estimativa de retardo de clique de agente 14240. O adicionador 12460 em seguida, adiciona o retardo de clique de agente a polarização de relógio de cliente 14250, emitindo a soma como estimativa retardo de clique total 14270. Finalmente, o somador 14280 acrescenta o retardo de clique a data de solicitação 10100, emitindo o resultado como a estimativa de data de clique baseada em solicitação 14040.

Como descrito no diagrama de fluxo de informações da Fig. 15, para cada registro de transação de entrada de cliente, estimador de data de carga 13030, para uso no sincro- nizador de cliente 5090 (Ver a Fig. 13.), ou usa no estimador de data de carga 15010 e esti- mador de polarização de carga 15020 para emitir estimativa de data de carga baseada em envio 15030, ou emite estimativa de data de carga baseada em solicitação 15040, dependendo do valor de comutação de estimação de data de carga 13070.

O buscador de modelo de serviço 7020 olha para o modelo de serviço 5030 identificado pelo identificador de serviço 6020 no registro de transação de cliente 5090, emitindo a duração de serviço 7030 para o estimador de duração de enviado do servidor, o multiplicador 15090 e emitindo o tamanho de serviço 10170 para o estimador de duração de recebimento de cliente, o multiplicador 15100 e estimador de duração de carga de agente, o multiplicador 15120.

O buscador de modelo de servidor 7040 busca o modelo de servidor 5020 identificado pelo identificador de servidor 6010 no registro transação de 5090 de cliente, emitindo a taxa de enviado de serviço do servidor 7110e polarização de serviço enviado do servidor 7290, modelando o retardo entre o instante em que o servidor começa a enviar um serviço para o instante em que termina de enviá-lo. Da mesma forma, o buscador de modelo de cliente 14070 procura o modelo de cliente 5130 identificado pelo identificador do cliente 11010 no registro de transação, emitindo a taxa de recebimento de serviço de cliente 15050 e polarização de recebimento de serviço de cliente 15060, modelando o retardo de transmissão entre o servidor no instante em que começa a enviar um serviço e o instante que o cliente termina de receber. Da mesma forma, o buscador de modelo de agente 12040 procura o modelo de agente 5110 identificado pelo identificador de agente 10010 no registro de transação, emitindo a taxa de carga de serviço de agente 15070 e polarização de carga de serviço de agente 15080, modelando o retardo entre o instante em que o agente começa a receber o serviço e o instante em que o agente termina de carregar o serviço, na medida em que o cliente pode atuar sobre ele.

O estimador de duração de carga 15010 usa o multiplicador 15090 para multiplicar a taxa de enviado do servidor 7110 pela duração de serviço 7030, emitindo o produto como estimativa de duração de enviado 7280; usa o multiplicador 15100 para multiplicar taxa de recebimento de cliente 15050 pelo tamanho de serviço 10170, emitindo o produto como es-timativa de duração de recebimento 15110 e usa o multiplicador 15120 para multiplicar a taxa de carga 15070 pelo tamanho de serviço 10170, emitindo o produto como duração de carga 15130. O estimador de duração de carga em seguida, utiliza operador máximo 15140 para calcular o valor máximo entre a duração de enviado, duração de recebimento e duração de carga, emitindo o máximo como estimativa de duração de carga 15150.

O estimador de polarização de carga 15020 usa o adicionador 15160 para adicionar polarização de enviado de servidor 7290, polarização de recebimento de cliente 15060, e polarização de carga de agente 15080, emitindo o resultado como polarização de carga total 15170.

O estimador de data de carga 13030 em seguida, adiciona duração de carga 15150 à polarização de carga 15170, emitindo a soma como estimativa de retardo de carga total 15190. Finalmente, somador 15200 adiciona o retardo de carga à data de envio de servidor 7100 no registro de transação de cliente 5090, emitindo o resultado como estimativa de data de carga baseada em envio 15030.

O diferenciador 15210 subtrai a data de solicitação 10100 especificada no registro de transação de cliente 5090 da data de clique 13020 emitida pelo estimador de data de clique baseado em solicitação 14030 (Veja fig. 14), emitindo a diferença como retardo de clique 14270. Como alternativa, o estimador de data de clique poderia passar o retardo de clique diretamente para o estimador de data de carga. O adicionador 15230 em seguida, adiciona o retardo de clique à data de carga 15220 obtida a partir do registro de transação de cliente, emitindo a soma como a estimativa de data de carga baseada em solicitação 15040.

O diagrama de fluxo de informação da Fig. 16 descreve analisador de evento de transição temporizado 16000, um tipo exemplar particularmente simples de analisador de sessão 3050 para uso em detector de ameaça serviço de rede 1060 (Ver Fig. 3) que analisa sessões de transação de clientes 3040 em eventos de sessão atômicas ou eventos de sessão elementares, compreendendo transições temporizadas, e reempacota-os como sessões de evento de cliente 16240 para um processamento eficiente por modelador de sessão 3120 e comparador de sessão 3070 da figura 3. Em uma modalidade mais complexa, o analisador de sessão analisa as sessões de cliente em trigramas de sobreposição ou pedaços maiores quando existem estatísticas suficientes, e inclui outra informação de cliente distinta.

Os nomes de origens 16080 e nomes de destino 16030 podem ser tanto URLs a partir de registros de transações de HTTP, ou nomes de serviços internos providos pelo website de uma implantação de retaguarda. Na modalidade mostrada, os nomes de serviço são tokenizados para a eficiência no analisador de sessão 16000. Em uma modalidade alternativa, eles são tokenizados antes, no reconstrutor de sessão 3030 ou mesmo em ambos o analisador de website 3100 e aumentador de registro 3010 (ver Fig. 3).

O codificador de origem 16010 tokeniza nome de origem 16080 para emitir identificador de origem 16020, onde o nome de origem é o nome do serviço 6020 acumulado 16070 do registro de transação de sessão anterior. Da mesma forma, o codificador destino 16030 tokeniza o nome de destino 6020 para emitir o identificador destino de destino 16040. O codificador de origem e o codificador de destino codificam um nome de serviço, buscando o nome em um dicionário e retornando o token correspondente, normalmente um hash do nome, inserindo o nome no dicionário e, assim, gerando um token para ele se o nome de serviço ainda não entrou no dicionário. O token tem a precisão de uma palavra binária padrão nas máquinas que incorporam o detector de ameaça, para busca eficiente, comparação e outras manipulações.

O codificador de duração 16050 codifica a duração da transição 16120 para emitir o identificador de intervalo de tempo de transição 16060, em que a duração da transição é calculada como a diferença 16110 entre a data de clique 13020 (o instante estimado quando o cliente solicitou o serviço de destino) e a data de carga de origem 16100, a data de carga 12020 acumulada 16090 do registro transação de sessão anterior (o instante estimado quando o cliente foi primeiro capaz de solicitar o serviço). Em uma modalidade, o codificador de duração simplesmente emite o tempo de transição quantitativo para a precisão de uma palavra binária padrão. Em uma modalidade alternativa, o codificador de duração grosseiramente quantifica o tempo de transição em escala exponencial, e tokeniza intervalos quan- tizados para o acesso eficaz em uma matriz esparsa. Uma escala de amostra exponencial é [0..1/16), [1/16..1/8), [1/8..1/4), [1/4..1/2), [1/2..1), [1..2), [2..4), [4..8), [8..~) segundos. Uma representação quantitativa é preferível para análise de sessão atômica, onde cada evento individual em cada sessão é considerado separadamente para a exatidão. Uma representação tokenizada é preferível para análise de sessão elementar, em que todos os eventos de um tipo dentro de uma sessão são agrupados e tratados como um grupo.

O codificador de transição 16150 codifica o par ordenado compreendendo o identi-ficador de origem 16020 e o identificador de destino 16040 (como mostrado), ou, de forma equivalente, compreendendo nome de origem 11040 e nome de destino 11060, para emitir um identificador de transição único 16160 que identifica a transição da origem de o destino.

Codificador de origem temporizado 16170 codifica a combinação do identificador de origem 16020 e identificador de intervalo de tempo 16060 (como mostrado), ou, de modo equivalente, a combinação do nome de origem 16080 e tempo de transição 16020, para emitir identificador de origem temporizado 16180. Da mesma forma, codificador de destino temporizado 16130 codifica a combinação do identificador de destino 16040 e identificador de intervalo de tempo 16060 (como mostrado), ou, de modo equivalente, a combinação do nome de destino 6020 e o tempo de transição 16020, para emitir identificador de destino temporizado 16180.

O codificador de ligação opcional 16190 busca identificador de origem 16020 e o identificador de destino 16040 (como mostrado), ou, de forma equivalente nome de origem, 16080 e nome de destino 6020, no mapa do website 3110 para determinar o tipo de ligação,  e codifica para o tipo de ligação como identificador de ligação 16200.

Transições extrínsecas dentro de uma sessão podem indicar um ataque de sequestro. No entanto, certas ligações extrínsecas são fornecidas por navegadores de web e aplicativos similares, normalmente acessados por botões ou itens de menu na interface do usuário do aplicativo, incluindo um recurso de "voltar" para voltar ao serviço anterior na sessão, uma função de histórico para retornar ao outro serviços visitados recentemente pelo cliente, e uma função de marcação para retornar aos serviços previamente marcados pelo cliente. Na modalidade mais simples, o codificador de ligação classifica links em uma das três categorias:intrínseca, etapa de volta, e extrínseca. Em uma modalidade mais complexa, o codificador de ligação também reconhece pular de volta para serviços anteriores dentro da sessão atual como uma quarta categoria. Ligações extrínsecas também podem ser fornecidas por fontes externas, como websites e e-mails, e o codificador de ligação reconhece tais ligações de entrada pelo referenciador 16250, quando presente no registro de ação de cliente, e classifica como um outro tipo de ligação.

Para a análise de sessão elementar, o analisador de sessão 16000 usa contador de tipo de evento 16210 para primeiro verificar se um evento de sessão existente 16240 tem identificadores de correspondência - neste caso identificador de origem de correspondência 16020, identificador de destino de correspondência 16040, identificador de duração 16060 e, se estiver disponível, identificador de ligação de correspondência 16200 - e, se assim for, apenas aumenta o contador de tipo de evento 16220 para esse tipo de evento, em vez de codificar os identificadores derivados e empacotar um evento de sessão separado.

O empacotador de registro de evento de sessão 16230 monta o identificador de origem 16020, identificador de destino 16040, identificador de duração de transição 16060, identificador de origem temporizado 16180, identificador de transição 16160, e identificador de destino temporizado 16140, no registro de evento de sessão 16240. Se disponível, o em- pacotador de evento de sessão também registra identificador de tipo de ligação 16200 no registro de evento de sessão. Para eventos de sessão elementar, o empacotador de evento de sessão, também armazena a contagem de casos do tipo de evento 16220 no registro de evento de sessão.

Emitir evento de sessão de cliente 16240 pode ser ou um evento de sessão atômica, listando cada evento individual como um registro separado, ou uma síntese de evento de sessão elementar, agrupando eventos equivalentes em um único registro. Para análise de sessão atômica, o empacotador de evento de sessão 16230 simplesmente anexa cada registro de evento de sessão 16240 para o evento de sessão atômica atual de cliente em tempo real. Para a análise de sessão elementar, o contador de tipo de eventos funde 16210 registros de eventos equivalentes dentro de uma sessão, mantendo uma contagem exemplar, no registro de evento para cada tipo de evento.

Na modalidade exemplar mostrada, o composto atribui transição de serviço 16160, origem temporizada 16180, e destino temporizado 16140 são codificados no analisador de sessão 16000, poupando tempo posterior no modelador de sessão 3120 e comparador de sessão 3070, mas à custa do espaço requerido para armazenar os identificadores adicionais nos registros de eventos de sessão. Em uma modalidade alternativa, os atributos compostos são codificados no fly, sempre que necessário, economizando espaço, à custa de tempo.

O diagrama de fluxo de informação da Fig. 17 descreve modelador de evento de transição temporizado 17000, um tipo particularmente simples de modelador de sessão 3120 para uso em detector de ameaça de serviço de rede 1060 (Ver Fig. 3) cujos modelos de sessão 3130 incluem modelos de eventos 17010 modelagem não sessões inteiras, mas apenas os eventos de transição atômicos ou elementares dos quais as sessões são compostas, e modelando apenas as estatísticas globais das características mais rudimentares daqueles eventos: as identidades dos serviços constituintes de uma transição e a duração da transição - juntamente com combinações comuns dessas características.

Em particular, o modelador de evento 17000 modela as estatísticas globais durante o período de coleta de dados de uma origem de transição, duração de transição, e destino, bem como de pares de origem e de destinos juntos, pares de destino e duração de transição juntos, e pares de duração de transição e origem juntos. Quando as informações de ligação a partir de um mapa de websiteestão disponíveis, o modelador de evento também modela as estatísticas globais de tipos de ligação durante o período de coleta de dados. Em detalhe, para cada registro de evento de sessão de sessão ou registro de tipo de sessão 16240, atu- alizador de modelo de origem 17020 atualiza a frequência de origem 17030 correspondente ao identificador de origem 16020, o atualizador de modelo de duração de transição 17040 atualiza a frequência de duração de transição 17050 correspondente ao identificador de duração de transição 16060, o atualizador de modelo de destino 17060 atualiza a frequência de destino 17070 correspondente ao identificador de destino 16040, atualizador de modelo de destino temporizado 17080 atualiza a frequência de destino temporizada correspondente ao identificador de destino temporizado 16140, o atualizador de modelo de transição 17100 atualiza a frequência de transição 17110 correspondente ao identificador de transição de serviço 16160, o atualizador de modelo de origem temporizado 17120 atualiza a frequência de origem temporizada 17130, e atualizador de modelo de ligação 17140 opcionalmente atualiza a frequência de tipo de ligação 17150 correspondente ao identificador de tipo de ligação 16200, onde o identificador de origem, identificador de duração, identificador de destino, identificador de destino temporizado, identificador de transição, identificador de origem temporizado e identificador de tipo de ligação são obtidos a partir do registro de evento de sessão 16240, e os modelos correspondentes são atualizados no banco de dados de modelos de eventos 17010. Além disso, o atualizador de frequência de evento 17160 atualiza a frequência de evento 17170 no banco de dados de modelos de evento.

Frequências de origem 17030 são modeladas separadamente a partir de frequências de destino 17070 porque a distribuição de frequências de origem não é idêntica em geralà distribuição de probabilidades de destino, uma vez que, por exemplo, uma página de entrada é relativamente pouco provável que seja um destino, e uma página de logout é improvável que seja uma origem, uma vez que as sessões de cliente muitas vezes começam com uma página de login e terminam com uma página de logout.

O modelador de evento 17000 foi projetado para operar ou em registros de tipo de evento de sessão, ou em registros de tipo de evento de sessão elementar, onde cada registro de tipo de evento contém uma contagem de caso 16220, além dos identificadores. Quando operando em registros de evento de sessão atômica , o modelador de evento atualiza a frequência de origem 17030, frequência de duração 17050, frequência de destino 17070, frequência de destino temporizada 17090, frequência de transição 17110, frequência de origem temporizada 17130, frequência de ligação 17150, e frequência de evento 17170 simplesmente incrementando cada frequência por um, o valor padrão de incremento 17200. Quando operando em registros de evento de sessão elementar, o modelador de evento atualiza estas frequências aumentado cada um pela contagem de sessão 16220, inseridas como incremento 17.200.

Além disso, o modelador de evento é projetado para operar tanto no modo de lote, por exemplo, para o processamento do trabalhando todo o conjunto de transações do website durante um período de coleta de dados, como uma hora, ou em modo contínuo, de forma incremental para atualizar os modelos em tempo real com uma janela deslizante, por exemplo, adicionando cada transação ou o valor de cada minuto de transações tal como ocorre, e a remoção de cada transação ou incremento de transações com a época além do período de recolha de dados de, por exemplo, uma hora. Ao operar em modo contínuo, comutador 17190 altera o incremento de uma negativa para remover um registro de evento atômico, e muda o incremento para o negativo da contagem de caso 16220 para remover um registro de evento do tipo a partir das frequências de execução, conforme especificado removendo a sinalização 17180.

Em uma modalidade alternativa, as chaves juntas - identificador de transição 16160, identificador de origem temporizado 16180, e identificador de destino temporizado 16140 - não são diretamente armazenados no evento de sessão 16240, mas são construídos a partir do identificador de chaves elementares - identificador de origem 16020, duração 16060, e identificador de destino 16040, conforme o caso, no fly pelo buscador de modelo de transição 22010, buscador de modelo de origem temporizado 23010, e buscador de modelo de destino temporizado 24010, respectivamente. Esta alternativa é preferível quando o espaço disponível para armazenar chaves nos registros de eventos de sessão é mais crítico do que o tempo necessário para gerar as chaves comuns.

O diagrama de fluxo de informação da Fig. 18 representa um comparador de sessão independente de evento 18000, um tipo particularmente simples de comparador de sessão 3070 para utilização no detector de ameaça de serviço de rede 1060 (Ver Fig. 3), que pontua cada evento em um evento de sessão do cliente 16240 independentemente, utilizan- do no processador de evento de sessão 18010 e comparador de evento 18020, e usa pon- tuador de sessão 18030 para combinar as pontuações de eventos na contagem de ameaça de sessão 3080. O comparador de sessão também utiliza opcionalmente analisador de ameaça de privilégio 18040 para ponderar cada pontuação de evento de acordo com o nível de privilégio do cliente para o evento, e também utiliza opcionalmente analisador de ameaça intrínseca 18050 para ponderar cada pontuação de evento de acordo com o nível de ameaça intrínseca do evento.

O processador de evento de sessão 18010 atua por meio dos registros de tipo de evento elementares ou registros de eventos atômicos ordenados cronologicamente escolhidos na sessão de cliente 16240, emitindo-os um de cada vez, como eventos de sessão 16240 para o comparador de evento 18020.

Comparador de evento 18020 compara cada tipo de evento ou evento com o modelo 17010 para esse tipo de evento, emitindo pontuação de evento anomalia 18060 para esse evento. Para eventos elementares, o comparador de evento também emite o número de instâncias 16220 desse tipo de evento a partir do registro de tipo de eventos. O comparador de evento é discutido mais adiante na Fig. 20.

Para eventos atômicos, pontuação de sessão 18030 usa acumulador de pontuação 18070 para acumular as pontuações de eventos de anomalia individuais 18060, emitindo pontuação de ameaça 3080 para a sessão como um todo. Na modalidade preferida, as pon-tuações de anomalia de eventos são aditivas, em vez de multiplicativas (Ver Fig. 27.), para facilitar o acúmulo das pontuações para os muitos eventos em uma sessão longa sem transbordar. Na modalidade mais simples, a pontuação de sessão simplesmente adiciona todas as pontuações do evento de anomalia para emitir a pontuação de ameaça de sessão. Para eventos elementares, o pontuador de sessão utiliza multiplicador 18080 para multiplicar a pontuação de anomalia para cada tipo de evento pelo número de casos 16220 desse tipo de evento, emitindo o resultado como pontuação de evento 18090, neste caso o acumulador de pontuação 18070 soma os eventos em vez das pontuações de anomalia de evento para calcular a pontuação de ameaça de sessão.

Na modalidade preferida, para avaliar ameaças de sequestro de sessão tais como ameaças man-in-the-browser e ameaças man-in-the-middle, onde, para evitar a detecção, para completar suas transações fraudulentas privilegiadas antes de o cliente fechar a sessão, e para maximizar o número de sessões sequestradas sob supervisão humana - invasoresestão motivados a sequestrar uma sessão tão rapidamente e logo que possível após o cliente ter obtido acesso privilegiado bem sucedido a um website, o comparador de sessão 18000 usa analisador de ameaça de privilégio 18040 para calcular uma ponderação de tempo amortecido 18100 de acordo com como logo após efetuar login o evento correspondente anômalo ocorreu, com base nos registros de evento de sessão 16240, e, em algumas modalidades, o índice de evento 18110 emite pelo processador de evento de sessão 18010, e, para os eventos elementares, a contagem de evento de instância 16220. Para websites que oferecem vários escalões de privilégio, o analisador de ameaça de privilégio também pondera a pontuação de evento de acordo com o nível de privilégio. Analisador de ameaça de privilégio 18040 é discutido na figura 19.

Ao usar o analisador de ameaça de privilégio 18040, pontuação de sessão 18030 usa multiplicador 18170 para multiplicar a pontuação 18090 para cada tipo de evento ou evento pela ponderação de privilégio correspondente 18100, emitindo o resultado como pontuação de evento ponderada 18180, em tal caso o pontuador de sessão soma as pontuações de evento ponderadas, ao invés de pontuações de eventos não ponderados 18090, para emitir a pontuação de ameaça de sessão 3080.

Se o mapa de website 3.110 contendo informações sobre níveis de ameaça intrín-secaestá disponível (ver fig. 4), então, o comparador de sessão também considera níveis de ameaça intrínseca, utilizando analisador de ameaça intrínseca 18050 para determinar a ponderação de ameaça intrínseca 18120 para cada evento ou tipo de evento, a fim de ponderar diferentes níveis de ameaça intrínseca de acordo com as preferências dos agentes de segurança do website.

Em detalhe, o analisador de ameaça intrínseca 18050 usa buscador de ameaça in-trínseca 18130 para buscar o nível de ameaça intrínseca associado com o evento de sessão 16240 no mapa de website 3110, emitindo o resultado como nível de ameaça intrínseca 18140. O pontuador de ameaça intrínseca 18150 depois buscar a pontuação de ameaça intrínseca correspondente ao nível de ameaça intrínseca na tabela de pontuações de ameaça intrínseca 18160, emitindo o resultado como ponderação intrínseca 18120.

Ao usar o analisador de ameaça intrínseca 18050, o pontuador de sessão 18030 usa o multiplicador 18170 para multiplicar a pontuação 18090 para cada tipo de evento ou evento pela ponderação de ameaça intrínseca correspondente 18100, emitindo o resultado como pontuação de evento ponderada 18180. Ao utilizar ambos o analisador de ameaça intrínseca e o analisador de ameaça de privilégio 18040, o pontuador de sessão primeiro usa o multiplicador 18190 para multiplicar a ponderação de ameaça intrínseca pela ponderação de privilégio 18100, emitindo o resultado como ponderação de evento 18200. Em seguida, ele multiplica a ponderação de evento pela pontuação de evento para emitir a pontuação de evento ponderada. Em ambos os casos, o apontador de sessão seguida, resume as pontuações de eventos ponderadas, em vez de as pontuações de eventos não ponderadas, para emitir a pontuação de ameaça de sessão 3080.

Como descrito no diagrama de fluxo de informações da Fig. 19, o analisador de ameaça de privilégio 18040 analisa a ameaça relacionada com o privilégio de cada evento de sessão de entrada ou tipo de evento de sessão 16240, utilizando analisador de privilégio 19010, agente de privilégio 19020, redimensionador de privilégio de tempo 19030, e pontua- dor de privilégio 19040, e ponderação de privilégio de emissão 18100.

Especificamente, para os eventos da sessão atômica 16240, analisador de ameaça de privilégio usa analisador de privilégio 19010 para monitorar os eventos de entrada crono-logicamente escolhidos para eventos de alteração de privilégio como eventos de login e logout, eventos de autenticação secundária, e eventos de atualização de HTTP, emitindo o nível atual de privilégio 19050, no tempo de cada evento e a duração de privilégio 19060 - a duração desde que o último cliente adquiriu aquele nível de privilégio dentro da sessão.

Na modalidade preferida, a duração de privilégio para um nível de privilégio especial é o retardo de resposta do cliente total, calculado através da soma das durações de transição 16060, em cada caso de sessão desde a aquisição daquele nível de privilégio, assim descontando as fases quando o cliente normalmente esperaria, em vez de agir, incluindo o tempo de transmissão, o tempo de serviço, e o tempo de carga. Em uma modalidade alter- nativa, a duração de privilégio é o tempo decorrido desde o instante de aquisição daquele nível de privilégio, calculado como a diferença entre o tempo e o evento corrente e o tempo do evento de aquisição de privilégio. Em outra modalidade alternativa, a duração de privilégioé o número de transações de clientes uma vez adquirido aquele nível de privilégio, calculado como a diferença no índice de evento 18110 emitido pelo processador de evento de sessão 18010 (Veja fig. 18) uma vez que o privilégio foi adquirido.

O agente de privilégio 19020 converte a duração de privilégio 19060 para uma pon-deração de tempo amortecido, emitindo-o como privilégio envelhecido 19070, em que o amortecimento é regido pelo declínio de ponderação 19080. Especificamente, quando a duração de privilégio é medida como o tempo decorrido, o agente de privilégio utiliza o multiplicador 19090 para multiplicar a duração de privilégio pelo declínio de ponderação, emitindo o produto como agente ponderado 19100, e, em seguida, usa o exponenciador 19110 para tirar o valor exponencial do agente ponderado, emitindo o resultado como privilégio envelhecido 19070, onde durante o tempo medido em segundos, o declínio de ponderação é tipicamente em torno do logaritmo natural de dois, de modo que a ponderação cai a partir de 1 no momento da aquisição de privilégio para 1/2 de um segundo mais tarde, para 1/4 no final de 2 segundos. Quando a duração de privilégio é medida em termos de número de eventos de transição, o agente de privilégio pode, alternativamente, ser calculado de forma recursiva, inicializando-o em 1, no caso de evento de aquisição de privilégio, e multiplicando o resultado pelo declínio da ponderação em cada evento subsequente.

Para eventos de sessão elementares, embora nem a data nem o índice de evento cronológico é conhecido por eventos individuais, no entanto, se analisador de sessão 16000 (Ver Fig. 16) inclui o nível de privilégio em sua classificação de eventos, então, tipos de eventos repetidos dentro de uma sessão podem ser efetivamente envelhecidos pela duração mínima implícita no número de instâncias 16220 daquele tipo de evento na sessão. Assim, para os eventos de sessão elementar, o pseudo-agente de privilégio 19025 efetivamente envelhece cada tipo de evento repetido pelo número de casos que devem ter precedido, na modalidade mais simples, multiplicando o declínio de ponderação 19080 por si só tão frequentemente quanto a contagem de instância de evento, e somando os produtos parciais, emitindo a soma como pseudo-agente de privilégio 19070. A modalidade preferida aplica a fórmula de forma fechada para a série geométrica, (dn +1-d)/(d-1), usando o incrementador 19120 para adicionar 1 à contagem de instância de evento n 16220 13220, emitindo o resultado como expoente p=n+1 19130; usando o operador de potência 19140 para aumentar a declínio de ponderação 19080 para aquele expoente, emitindo o resultado como potência 19150; usando subtrator 19160 para subtrair o declínio de ponderação da potência, emitindo o resultado como numerador 19170; e usando um Separador 19200 para dividir o numerador pelo Separador 19190, onde o Separador é calculado usando decrementador 19180 para subtrair um de declínio de ponderação, o resultado final sendo emitido como pseudo- agente de privilégio 19070.

Redimensionador 19030 redimensiona a série amortecida de ponderações de privilégio envelhecido para um mínimo especificado pelo mínimo ponderador 19210, usando complementadores 19220 para subtrair o mínimo ponderador, emitindo a diferença como complemento mínimo 19230, usando multiplicador 19240 para multiplicar o complemento mínimo pelo agente de privilégio 19070, emitindo o resultado como privilégio dimensionado 19250 e utilizando adicionador 19260 para adicionar o privilégio dimensionado para o mínimo ponderador, emitindo o resultado como ponderação declinada 19270. Um mínimo ponderador positivo garante que sequestradores irão continuar a ser detectados mesmo que eles mudem seu comportamento para adiar suas transações fraudulentas mais tarde em uma sessão.

O pontuador de privilégio 19040 busca pontuação de privilégio 19280 correspondente ao nível de privilégio 19050 na tabela de pontuações de privilégio 19290 para ponderarníveis diferentes de privilégio de acordo com as preferências dos agentes de segurança do website. Valores de pontuação de privilégio típicos para um website usando logins ambas a senha e a autorização secundária são 0,1 para não entrada não logada, 0,9 para entrada logada com uma senha, e 1,0 para secundariamente autorizada, mas outros valores de pontuação podem ser utilizados.

Finalmente, o multiplicador 19300 multiplica a pontuação de privilégio 19280 pela ponderação declinada 19270, emitindo o resultado como ponderação de privilégio 18100.

Em uma modalidade alternativa, o nível de privilégio 19050 é determinado de antemão pelo analisador de sessão 16000 e armazenado em registros de evento de sessão 16240 (Ver Fig. 16.).

Como descrito no diagrama de fluxo de informações da Fig. 20, o comparador de evento 18020 compara um evento de sessão 16240, que é ou um evento de sessão atômica ou um tipo de evento de sessão elementar, com os modelos de eventos 17010 para esse tipo de evento, e emite pontuação de anomalia de evento correspondente 18060. Em MiB, MiM, e tipos semelhantes de ataques de sequestro, um fraudador usa uma conta de website simultaneamente com um cliente legítimo da conta. As ações do sequestrador do website são assim, intercaladas com ações do cliente legítimo.

A fim de maximizar a chance de concluir as transações fraudulentas e minimizar a chance de serem descobertas, as ações do fraudador precisam ser executadas de forma rápida e no início da sessão de login. Portanto, o sequestrador não tem tempo disponível para inserir ações em momentos apropriados no fluxo do cliente legítimo. Como resultado, o fluxo combinado de ações do cliente e do fraudador logo após o loginé provável que apre-sentemtransições que são anômalas, muitas vezes não sendo intrínsecas ao website, e anormalmente rápidas para as sessões normais, em geral, e especialmente para as sessões normais da vítima. Além disso, o fluxo das ações do fraudador sozinho é provável que apre-sentetransições que são anomalias, não intrínsecas, e anormalmente rápidas para sessões normais, em geral, e, especialmente, para as sessões normais da vítima, porque o sequestradoré provável de usar um fluxo aerodinâmico saltando etapas intermediárias normais, mas estritamente desnecessárias, e é provável automatizar aquele fluxo.

Assim, o comparador de evento 18020 examina ambas a frequência relativa e a du-ração relativa do evento, comparando a frequência observada 20020 do tipo de evento, com a frequência prevista 20130 do tipo de evento, bem como a comparação entre a duração observada 20040 do evento ou tipo de evento com a duração prevista 20140 do tipo de evento.

Em detalhe, estimador de a frequência de evento 20010 estima a frequência relativa do tipo de evento de sessão 16240 a partir de modelos de eventos 17010, emitindo a  frequência de evento observada 20020.

O estimador de duração de evento 20030 estima a duração de evento, emitindo a duração de evento observada 20040. Quando o evento de sessão 16240 é provido pelo pro-cessador de sessão atômica 8200 (Ver Fig. 18), o estimador de duração 20030 apenas extrai a duração de evento, como ajustado pelo sincronizador de transação 5140 (Ver Fig. 6), a partir do registro do evento de sessão. Quando, por outro lado, o fato de a sessão ser fornecida pelo processador de tipo de evento de sessão 24010 (Ver Fig. 16.) e a duração dos eventos individuais na sessão não é conhecida, mas o tipo de evento 24010 é específico para um intervalo de tempo grosseiramente quantificado, então o estimador de duração de evento estima a duração de evento, como a duração média do tipo de evento, ou, se essa informação não estiver disponível, a duração de evento é estimada como a duração média do intervalo de tempo quantizado, tanto do que é recuperado a partir de modelos de eventos 17010.

O comparador de evento utiliza um ou mais preditores de frequência de eventos 20050 para prever a frequência de evento a partir das frequências de eventos marginais recuperadas de modelos de eventos 17010, cada preditor de frequência de evento emitindo uma predição de frequência de evento correspondente 20060. Preditores de frequência de evento individuais exemplares são descritos nas Fig. 21 a Fig. 24, e um preditor de frequência de evento combinada fatorando as operações comuns entre estes quatro preditores individuais exemplares é descrito na fig. 25.

Correspondendo a cada preditor de frequência de evento 20050 é um preditor de duração de evento 20070 no qual se prevê a duração do evento ou tipo de evento 16240 a partir de modelos de evento 17010 correspondentes aos utilizados nos preditores de frequência de evento, cada preditor de duração de evento emitindo uma predição de duração de evento correspondente 20080.

O detector de duração de evento anômalo opcional 20090 compara cada predição de duração de evento individual 20080 com a duração de evento observada 20040, emitindo sinal de comutação de preditor 20100 para desligar preditores de frequências de eventos individuais 20050 para eficiência computacional quando a duração de evento observada é determinada para não ser anormalmente breve por uma predição de duração de evento par-ticular.

O detector de duração de evento anômalo determina um evento para ser anormal-menterápido, se a duração observada for menor que a duração prevista menos um limite de duração 20110 ou por um outro teste. Na modalidade preferida, o limite de duração é zero, a fim de adiar decisões de ameaça até que a anomalia da sessão inteira possa ser comparada com a anomalia de todas as outras sessões. Em alternativa, se o número de ataques detectadosé esperado como sendo substancialmente maior do que a ameaça, os processadores 1080 (Ver Fig. 1) podem lidar, em seguida, o limite de duração pode ser ajustado para cima para acelerar os acontecimentos menos ameaçadores. O detector de duração de evento anômalo é usado como uma otimização da eficiência em modalidades em que ele reduz o tempo de computação ou outras demandas de recursos.

O combinador de predição 20120 combina as predições de frequência de eventos individuais 20060 e predições de duração de evento correspondentes 20080 em uma única frequência de evento prevista 20130 e uma única duração de evento prevista correspondente 20140. O combinador de predição é detalhado na Fig. 26.

O pontuador de frequência de evento 20150 compara frequência de evento prevista 20130 com frequência de evento observada 20020, considerando o limite de frequência 20170, e emite pontuação de frequência anômala 20160. Em uma modalidade, o pontuador de frequência de evento é desligado se a pontuação de duração anômala 20190 estiver abaixo do limite de duração 20110, para a eficiência computacional. O pontuador de frequência de evento é discutido em maiores detalhes na Fig. 27.

O pontuador duração de evento 20180 compara duração de evento prevista 20140 com duração de evento observada 20040, considerando o limite de duração 20110, e emite pontuação de duração anômala 20190. Em uma modalidade, o pontuador de duração de evento está desligado se a pontuação de frequência anômala estiver abaixo do limite de frequência 20170, para a eficiência computacional. O pontuador de duração de evento é discutido em maiores detalhes na Fig. 28.

Pontuador de evento anômalo 20200 insere pontuação de frequência anômala  20160 e pontuação de duração anômala 20190, e emite pontuação de evento anômalo 18060. Se qualquer pontuação de frequência anômala ou pontuação de duração anômala for não positiva, o pontuador de evento anômalo emite uma pontuação de evento anômalo de zero. Na modalidade preferida, o pontuador de anomalia de evento combina a pontuação de anomalia de frequência e duração de pontuação de anomalia multiplicando-os juntos, em que o produto resultante pode ser interpretado como a informação mútua ponto a ponto entre os termos do evento, ponderado pela brevidade anômala do evento.

A Fig. 21 até Fig. 25 representam preditores de frequência exemplares de eventos para um simples evento de transição temporizado, ou seja, um evento composto por três variáveis: um primeiro serviço de web de origem visto por um cliente, um segundo destino próximo visto pelo cliente, e o tempo de transição entre os serviços, em que o tempo de transição está idealmente medido como o intervalo entre a recepção do cliente da origem e a solicitação do cliente do destino. A frequência e a duração de uma transição temporizada podem ser previstas a partir das frequências marginais independentes da origem, o tempo de transição, e destino, tal como no preditor atômico 21000 na fig. 21, ou a partir de um indicador parcial em que qualquer dependência entre duas das três variáveis é considerada: a partir da frequência junta submarginal da transição origem destino e a frequência marginal da transição, tal como no preditor de frequência polarizada TxAB 22000 na fig. 22, a partir da frequência junta submarginal da origem temporizada e a frequência marginal do destino, tal como no preditor de origem temporizada 23000 na fig. 23, ou a partir da frequência marginal da origem e da frequência submarginal junta do destino temporizado, como preditor de destino temporizado 24000 na fig. 24. Para aqueles preditores que não se referem à frequência da transição específica os preditores AxTxB, BxTA, e AxTB podem, opcionalmente, ser refinados pela frequência do tipo de ligação, se essa informação está disponível. A Fig. 25 combina todos esses quatro preditores para eficiência computacional quando todos os quatro indicadores são executados pelo mesmo processador. Deve notar-se que algumas modalidades incluem menos do que todos os quatro indicadores.

Tal como ilustrado na fig. 21, o preditor de transição temporizado atômico 21000 usa buscador de modelo de origem 21010 para procurar frequência de origem 17030 cor- respondente ao identificador de origem 16020, processador de modelo de duração de transição 21020 para procurar frequência de duração de transição 17050 correspondente ao identificador de duração de transição 16060, buscador de modelo de destino 21030 para procurar frequência de destino 17070 correspondente ao identificador de destino 16040, buscador de modelo de ligação opcional 21040 para procurar frequência de tipo de ligação 17150 correspondente ao identificador de ligação 16200, buscador de frequência de norma 21070 para procurar norma de frequência de evento 17170, em que o identificador de origem, identificador de duração, identificador de destino, e identificador tipo ligação são introduzidos a partir do evento de sessão 16240, e os modelos correspondentes e a norma de frequência são recuperados dos modelos de evento 17010. O multiplicador 21050 multiplica juntos a frequência de origem, a frequência de duração, a frequência de destino, e, opcionalmente, a frequência de ligação 17150, emitindo o produto como frequência absoluta Ax- TxB 21060. O operador de potência 21080 multiplica a norma de frequência à quarta potência, emitindo o resultado como norma quadruplicada 21090. Finalmente, o normalizador 21100 divide a frequência AxTxB absoluta pela norma quadruplicada, emitindo a frequência relativa como a predição de frequência independente AxTxB 21110. Se a frequência de ligação não está incluída no cálculo de frequência combinada, em seguida, o operador de potência só levanta a aumenta para a terceira potência.

Em preditor de transição temporizada atômico 21000, processador de modelo de duração 21020 também busca duração 21120 correspondente ao identificador de duração 16060 no registro de evento de sessão 16240, que ele emite como duração 21120. O multiplicador 21130 multiplica a duração pela frequência de duração 17050, emitindo o produto como duração total 21140. O Separador 21150 divide a duração total pela frequência atômica absoluta 21060, emitindo o quociente como predição e duração independente 21160.

Tal como ilustrado na Fig. 22, preditor de frequência polarizada TxAB 22000 usa processador de modelo de duração de transição 21020 para procurar a frequência de duração de transição 17050 correspondente ao identificador de duração de transição 16060, o processador de modelo de transição 22010 para procurar a frequência de transição 17110 correspondente ao identificador de transição 16160, e buscador de norma de frequência 21070 para procurar a norma de frequência de evento 17170, onde o identificador de duração e o identificador de transição são a entrada do evento de sessão 16240, e os modelos correspondentes e a norma de frequência são recuperados dos modelos de evento 17010. O multiplicador 22020 então multiplica juntos a frequência de duração e a frequência de transição, emitindo o produto como frequência TxAB absoluta 22030. O operador de energia 22040 esquadria a norma de frequência, emitindo o resultado como norma dupla 22050. Finalmente, o normalizador 22060 divide a frequência TxAB absoluta pela norma dupla, emitindo a frequência relativa como a predição de frequência polarizada TxAB 22070.

Em preditor polarizado TxAB 22000, processador de modelo de duração 21020 também procura a duração 21120 correspondente a ao identificador de duração 16060 no registro de evento de sessão 16240, que ele emite como duração 21120. O multiplicador 21130 multiplica a duração pela frequência de duração 17050, emitindo o produto como duração total 21140. O Separador 21150 divide a duração total pela frequência absoluta TxAB 22030, emitindo o quociente como predição de duração polarizada TxAB 22080.

Tal como ilustrado na fig. 23, preditor de frequência polarizada BxTA 23000 usa buscador de modelo de destino 21030 para procurar frequência de destino 17070 correspondente ao identificador de destino 16040, buscador de modelo de origem temporizada 23010 para procurar frequência de origem temporizada 17130 correspondente a identificador de origem temporizada 16180, buscador de modelo de ligação opcional 21040 para procurarfrequência de tipo de ligação 17150 correspondente ao identificador de ligação 16200, e buscador de norma de frequência 21070 para procurar a norma de frequência de evento 17170, onde o identificador de destino, identificador de origem temporizada e identificador de tipo de ligação são inseridas a partir do evento de sessão 16240, e os modelos correspondentes e a norma de frequência são recuperados dos modelos de eventos 17010. O multiplicador 23020 então multiplica juntas a frequência de destino, a frequência de origem temporizada, e, opcionalmente, a frequência de ligação 17150, emite o produto como frequência BxTA absoluta 23030. O operador de potência 23040 multiplica a norma de frequência para a terceira potência, emitindo o resultado como norma tripla 23050. Finalmente, o normalizador 23060 divide a frequência BxTA absoluta pela norma tripla, emitindo a fre- quência relativa como a predição de frequência polarizada BxTA 23070. Se a frequência de ligação não está incluída no cálculo de frequência combinada, então, o operador de potência só aumenta a norma para a segunda potência.

No preditor polarizado BxTA 23000, buscador de modelo de origem temporizada 23010 também procura duração 21120 correspondente ao identificador de origem temporizada 16180 no registro de evento de sessão 16240, que ele emtie como duração 21120. O multiplicador 21130 multiplica a duração pela frequência de origem temporizada 17130, emitindo o produto como duração total 21140. O Separador 21150 divide a duração total pela frequência absoluta BxTA 23030, emitindo o quociente como predição de duração polarizada BxTA 23080.

Da mesma forma, como representado na fig. 24, preditor de frequência polarizada AxTB 24000 usa buscador de modelo de origem 21010 para procurar frequência de origem 17030 correspondente ao identificador de origem 16020, buscador de modelo de destino temporizado 24010 para procurar frequência de destino temporizado 17090 correspondente ao identificador de destino temporizado 16140, o buscador de modelo de ligação opcional 21040 para procurar a frequência de tipo de ligação 17150 correspondente ao identificador de ligação 16200, buscador de norma de frequência 21070 para procurar norma de frequência de evento 17170, onde o identificador de origem, identificador de destino temporizado e identificador de tipo de ligação são inseridos a partir do evento de sessão 16240, e os modelos correspondentes e a norma de frequência são recuperados dos modelos de eventos 17010. O multiplicador 23020 multiplica juntas a frequência de origem, a frequência de destino temporizado e, opcionalmente, a frequência de ligação 17150, emitindo o produto como frequência absoluta AxTB 24020. Como no preditor de frequência AxTB 23000 (Ver Fig. 23), o operador de potência 23040 multiplica a norma de frequência para a terceira potência, emitindo o resultado como norma tripla 23040. Finalmente, o normalizador 23060 divide a frequência AxTB absoluta pela norma tripla, emitindo a frequência relativa como a predição de frequência polarizada AxTB 24030. Se a frequência de ligação não está incluída no cálculo de frequência combinada, então, o operador de potência só aumenta a norma para a segunda potência.

No preditor polarizado AxTB 24000, o buscador de modelo de destino temporizado 24010 também procura duração 21120 correspondente ao identificador de destino temporizado 16140 no registro de evento de sessão 16240, que ele emite como duração 21120. O multiplicador 21130 multiplica a duração pela frequência de destino temporizado 17090, emitindo o produto como duração total 21140. O Separador 21150 divide a duração total pela frequência AxTB absoluta 24020, emitindo o quociente como predição de duração polarizada AxTB 24040.

Tal como ilustrado na fig. 25, preditor de transição temporizada combinado 25000 usa o buscador de modelo de origem 21010 para procurar a frequência de origem 17030 correspondente ao identificador de origem 16020, processador de modelo de duração de transição 21020 para procurar frequência de duração de transição 17050 correspondente ao identificador de duração de transição 16060, buscador de modelo de destino 21030 para procurar a frequência de destino 17070 correspondente ao identificador de destino 16040, o buscador de modelo de destino temporizado 24010 para procurar a frequência de destino temporizado correspondente ao identificador de destino temporizado 16140, o processador de modelo de transição 22010 para procurar a frequência de transição 17110 correspondente ao identificador de transição 16160, o buscador de modelo de origem temporizada 23010 para procurar a frequência de origem temporizada 17130 correspondente ao identificador de origem temporizada 16180, o buscador de modelo de ligação opcional 21040 para procurar a frequência de tipo de ligação 17150 correspondente ao identificador de ligação 16200, e o buscador de norma de frequência 21070 para procurar a norma de frequência de evento 17170, onde o identificador de origem, o identificador de transição de duração, o identificador de destino, o identificador de destino temporizado, o identificador de transição, temporizada, o identificador de origem e o identificador de tipo de ligação são inseridos a partir do evento de sessão 16240 e os modelos correspondentes e a norma de frequência são recuperados dos modelos de eventos 17010.

O multiplicador 25050 esquadrinha a norma de frequência 17170, emitindo o resultado como norma dupla 20050; o multiplicador 25060 multiplica a norma dupla novamente pela norma, emitindo o resultado como norma tripla 23050 e o multiplicador 25070 multiplica  a norma tripla novamente pela norma, emitindo o resultado como norma quádrupla 21090.

Como no preditor de frequência AxTxB independente 21000, o preditor de frequên-ciaatômica AxTxB 25010 multiplica juntas a frequência de origem 17030, a frequência de duração 17050, a frequência de destino 17070, e, opcionalmente, a frequência de ligação 17150, dividindo a frequência AxTxB absoluta resultante 21060 pela norma quádrupla 21090 e emitindo a frequência relativa resultante como a predição de frequência independente Ax- TxB 21110. Como no preditor de frequência polarizada AxTB 24000, preditor de frequência polarizada AxTB 25020 multiplica juntas a frequência de origem, a frequência de destino temporizado e, opcionalmente, a frequência de ligação, dividindo a frequência AxTB absoluta resultante pela norma tripla 23050, e emitindo a frequência relativa resultante como prediçãode frequência polarizada AxTB 24030. Como no preditor de frequência polarizada TxAB 22000, o preditor de frequência polarizada TxAB 25030 multiplica juntas a frequência de duração e a frequência de transição, dividindo a frequência TxAB absoluta resultante pela norma dupla 20050, e emitindo a frequência resultante relativa como predição de frequência polarizada TxAB 22070. E, como no preditor de frequência polarizada BxTA 23000, o predi- tor de frequência polarizada BxTA 25040 multiplica juntas a frequência de destino, a frequência de origem temporizada, e, opcionalmente, a frequência de ligação, dividindo a frequência BxTA absoluta resultante pela norma tripla 23050, e emitindo a frequência relativa como predição de frequência polarizada resultante BxTA 23070. Se a frequência de ligação não está incluída nos cálculos de frequência combinada, então, o preditor AxTxB 25010 utiliza a norma tripla em vez da norma quádrupla, e o preditor AxTB 25020 e preditor BxTA 25040 usam a norma dupla em vez da norma tripla.

O preditor combinado 25000 também emite as respectivas predições de duração como na Fig. 21 a Fig. 24.

Em uma modalidade alternativa, as chaves juntas - identificador de transição 16160, identificador de origem temporizado 16180, e identificador de destino temporizado 16140 - não são diretamente armazenadas no evento de sessão 16240, mas são construídas a partir das chaves elementares - identificador de origem 16020, duração da transição 16060, e identificador de destino 16040, conforme o caso, no fly pelo processador de mode- lo de transição 22010, buscador de modelo de origem temporizada 23010, e buscador de modelo de destino temporizado 24010, respectivamente. Esta alternativa é preferível quando o espaço disponível para armazenar as chaves nos registros de eventos de sessão é mais crítico do que o tempo requerido para regenerar as chaves juntas.

Em uma modalidade alternativa, norma dupla de frequência 20050, norma tripla de frequência 23050, norma quádrupla de frequência 21090 são pré-computadas e armazenadas em modelos de evento 17010, em vez de serem computadas no preditor de evento. Esta alternativa é preferível quando o acesso à memória é mais rápido do que a multiplicação.

Em uma modalidade alternativa, as frequências marginais (frequência de origem 17030, frequência de duração 17050, e frequência de destino 17070) e frequências submar- ginais (frequência de transição 17110, frequência de origem temporizada 17130, e frequência de destino temporizado 17090) não são pré-computadas e armazenadas no banco de dados de modelos de eventos 17010, mas em vez disso são calculadas no fly a partir de eventos atômicos ou de frequências elementares pelos processadores de frequência marginal (processador de frequência de origem 21010, processador de frequência de duração 21020, e processador de frequência de destino 21030) e processadores de frequência intermediária (processador de frequência de transição 22010, processador de frequência de origem temporizada 23010, e processador de frequência de destino temporizado 24010), respectivamente. Esta modalidade alternativa é preferível quando o espaço de armazenamentodisponível para os modelos de eventos é mais crítico do que o tempo disponível para calcular as frequências marginais e submarginais no fly.

As frequências marginais (frequência de origem 17030, frequência de duração 17050, e frequência de destino 17070) e frequências submarginais (frequência de transição 17110, frequência de origem temporizada 17130, e frequência de destino temporizado 17090) como armazenadas no banco de dados de modelos de evento 17010 e emitidas pelos respectivos processadores de frequências podem ser tanto absolutas, caso em que elas podem ser representadas exatamente como números inteiros, ou relativas, caso em que devem ser representadas como frações aproximadas ou como números racionais de espaço ineficiente.

No entanto, enquanto a predição atômica 21110 é um produto de três frequências marginais, as predições submarginais (predição de transição 22070, predição de origem temporizada 23070, e predição de destino temporizado 24030), são produtos de apenas duas frequências, de modo que esses produtos são calculados a partir de frequências absolutas,então para tornar a frequência atômica compatível com as frequências submarginais, ou as frequências submarginais devem ser multiplicadas pela norma, permitindo que os produtos continuem a ser representados exatamente como inteiros, ou a predição atômica deve ser dividida pela norma, caso em que o produto deve ser aproximado como uma fração ou mantido como um número racional. Esta proporção pode ser implementada em qualquer fase entre o fim de preditores de eventos de frequências 20050 e o início de combinador de predição 20120. Note-se que, pelo menos, para a estimação de frequências simples relativa, todas as frequências atômicas, marginais e submarginais têm a mesma norma, que é a frequência de transição temporizada total, obtida a partir do banco de dados de modelos de evento.

Em algumas modalidades, os modelos de evento 17010 são armazenados em uma matriz esparsa tal como uma heap, em vez de como uma matriz completa ou árvore completa, a fim de economizar memória. Para um website grande, o número de tipos de transições observadas iria de outro modo exigir uma matriz completa impraticavelmente grande.

Como descrito no diagrama de fluxo de informações da Fig. 26, o combinador de predição 15130 insere as predições de frequência de eventos individuais 20060 e as prediçõesde duração de eventos individuais 20080, combinando-as para emitir a frequência de evento prevista 20130 e duração de evento prevista 20140, respectivamente.

Em uma modalidade preferida, o combinador de predição utiliza seletor máximo 26010 para selecionar a predição de frequência de eventos máxima para emitir como a frequência de evento prevista, e, via comutador de predição 26020, utiliza o seletor 26030 para selecionar a predição de duração de evento correspondente para emitir como a duração de evento prevista. A utilização do máximo aqui implica que um evento não deve ser considerado incomum se qualquer um de um conjunto de preditores credíveis mostrar que ele não é incomum. Em uma modalidade alternativa (não mostrada), um combinador de predição cal- cula a média Bayesiana das predições de frequência de entrada e predições de duração, e emite as médias como a frequência de evento prevista e duração de evento prevista, respectivamente.

Tal como ilustrado na fig. 27, o pontuador de frequência de evento 20150 insere a frequência de evento observada 20020 e a frequência de evento prevista 20130, as compara usando o comparador frequência de evento 27010, normaliza o resultado, e emite a pontuação de frequência de anomalia 20160.

O comparador de frequência de evento 27010 usa o diferenciador 27020 para com-pararfrequência de evento observada 20020 a frequência de evento prevista 20130, emitindo a diferença como excesso de frequência 27030. Em seguida, o somador 27040 adiciona limite de frequência 20170 ao excesso de frequência, emitindo o excesso de frequência ajustada 27050. Trilhador de frequência 27060 então testa se o excesso de frequência ajustadaé maior do que zero, indicando que o evento não é anômalo, caso em que ela emite um zero 27070 como a pontuação de frequência anômala 20160. Para a eficiência computacional, o trilhador também pode opcionalmente inserir pontuação de duração anômala 20190. Se a pontuação de duração anômala é inferior ao limite de duração 20110, então, o evento é igualmente determinado como não sendo anormal, e do mesmo modo o trilhador emite uma pontuação de anomalia de frequência de zero.

Em uma modalidade preferida, o limite de frequência é omitido ou configurado para zero, a fim de adiar as decisões de ameaça até que a anomalia da sessão inteira possa ser comparada com a anomalia de todas as sessões. Em alternativa, se o número de ataques detectados for esperado de ser substancialmente maior do que os processadores de ameaças 1080 (Ver Fig. 1) podem lidar, então, o limite de frequência pode ser ajustado para cima para acelerar os eventos menos ameaçadores.

Se, por outro lado, o trilhador de frequência 27060 determinar o evento como sendo anormal, então este passa a frequência de evento observada 20020 através de da frequência de evento trilhada 27080.

O normalizador frequência de evento, então, divide 27090 a frequência de evento trilhada pela frequência de evento prevista 20130, emitindo o resultado como razão de fre- quência 27100. Emitir a razão de frequência, em vez da frequência absoluta observada garante que a frequência observada de cada evento seja avaliada somente com relação à frequência prevista daquele evento, e independentemente das frequências absolutas de eventosnão relacionados.

Uma vez que a frequência de evento observada 20020 é uma frequência simples, ao passo que a frequência de evento prevista 20130 é um produto de frequência, se as frequências são representadas como frequências absolutas, então, a fim de tornar a frequência de evento observada proporcional à frequência prevista, ou a frequência de evento observadaé multiplicada pela norma, ou a frequência de evento prevista é dividida pela norma. Esta proporção pode ser implementada em qualquer fase entre o fim do estimador de frequência de evento 20010 ou preditor de frequência de evento 20050 e antes da comparação no comparador de frequência de evento ou normalização no normalizador de frequência de evento 27090. Adiar esta proporção até ao fim do combinador de predição 20120 pode reduzir a quantidade de computação.

Finalmente, log 27110 calcula o logaritmo da razão de frequência 27100, emitindo o resultado como pontuação de frequência anômala 20160. Usando o logaritmo em vez da razão em si conforme a pontuação de evento permite que o comparador de sessão 3070 (Ver Fig. 3.) some as anomalias de eventos, em vez de multiplicá-las, evitando assim trans- bordamento.

Tal como logaritmos da razão da frequência junta relativa com o produto das fre-quências marginais relativas, a pontuação de anomalia de frequência 20160 pode ser inter-pretado como a medição da informação mútua ponto a ponto entre as dimensões marginais. Na modalidade preferida, 27110 calcula o logaritmo de base 2, de modo que a pontuação é medida em bits. Em particular, no caso de transições temporizadas, preditor de frequência independente AxTxB 21000 mede a informação mútua ponto a ponto entre a origem, o tempo de transição, e destino; preditor de frequência polarizada TxAB 21050 mede a informação mútua ponto a ponto entre o tempo de transição e a transição de serviço; o preditor de frequência polarizada BxTA 23000 mede a informação mútua ponto a ponto entre o destino e a origem temporizada; e o preditor de frequência polarizada 24000 mede a informação mútua ponto a ponto entre a origem e o destino temporizado. Embora a informação mútua ponto a ponto possa ser não positivo, o pontuador de evento anômalo 20200 assegura que apenas pontuações positivas são emitidas; ou seja, a anomalia de sessão é determinada apenas por eventos anômalos, de modo que nenhum número de eventos normais pode compensar os anômalos. Isto está de acordo com o fato de que os ataques man-in-the-browser, man-in- the-middle, e ataques semelhantes caracteristicamente incluem alguns eventos breves, geralmente perto do início de uma sessão, independentemente de quanto tempo que dura a sessão.

Tal como ilustrado na Fig. 28, o pontuador de duração de evento 20180 insere duração de evento previsto 20140 e duração de evento observado 20040, compara-os usando o comparador de duração de evento 28010, normaliza o resultado, e emite pontuação de anomalia de duração 20190.

Comparador de duração de evento 28010 usa o diferenciador 28020 para comparar duração de evento observado 20040 para duração de evento previsto 20140, emitindo a diferença como déficit de duração 28030. Em seguida, somador 28040 adiciona limite de duração 20110 ao déficit de duração, emitindo déficit de duração ajustada 28050. O trilhador de duração 28060 então, testa se o déficit de duração ajustada é maior do que zero, indicando que o evento não é anômalo, caso em que ele emite um zero 28070 como a pontuação de duração anômala 20190. Para a eficiência computacional, o trilhador também pode opcionalmente inserir pontuação de frequência anômala 20160, se a pontuação de frequênciaanômala é menor que o limite de frequência 20170, o evento é igualmente determinado a não ser anômalo, e o trilhador da mesma forma emite uma pontuação de duração anômala de zero. Na modalidade preferida, o limite de duração é omitido ou configurado para zero, a fim de adiar as decisões de ameaça até que a anomalia da sessão inteira possa ser comparada com a anomalia de todas as sessões. Em alternativa, se o número de ataques detectadosé esperado de ser substancialmente maior do que os processadores de ameaças 1080 (Ver Fig. 1.) podem lidar, então, o limite de duração pode ser ajustado para cima para acelerar os eventos menos ameaçadores. Se, por outro lado, o comparador de duração de evento determinar que o evento é normal, então ele passa o déficit de duração ajustada como défi-  cit de duração trilhada 28080.

O normalizador de duração de evento 28090, então, divide o déficit de duração trilhada 28080 pela duração de evento prevista 20140 para fornecer pontuação de duração anômala 20190, variando de zero, se a duração de evento não é anômala no todo, a um, se a duração de evento é tão anormalmente breve quanto possível.

Como já foi explicado, um sistema de segurança de rede pode incluir a detecção de ataques man-in-the-browser e outros ataques, usando uma variedade de ferramentas e abordagens. Outras modalidades podem ser imaginadas por um versado comum na técnica após leitura desta descrição. Em outras modalidades, as combinações e subcombinações da invenção acima descrita podem ser vantajosamente feitas. As disposições exemplares de componentes são apresentadas para fins de ilustração e deve ser entendido que as combi-nações, adições, redisposições, e semelhantes são contempladas em modalidades alternativas da presente invenção. Assim, embora a invenção tenha sido descrita em relação a modalidades exemplificativas, os versados na técnica reconhecerão que numerosas modificações são possíveis.

Por exemplo, os processos aqui descritos podem ser implementados utilizando componentes de hardware, componentes de software, e/ou qualquer combinação dos mesmos. A especificação e os desenhos devem, por conseguinte, ser considerados em um sentido ilustrativo e não restritivo. Será, no entanto, evidente que várias modificações e alterações podem ser feitas a isso, sem se afastar do espírito e do escopo mais amplo da invenção, conforme definido nas reivindicações, e que a invenção destina-se a cobrir todas as modificações e equivalentes dentro do escopo das seguintes reivindicações.

Como representado no diagrama de blocos da Fig. 29, processador de tráfego de servidor exemplar 2010 (ver Fig. 2.) usa canalizador 29050 para incluir tráfego instigado por hospedeiro entre clientes 1010 e serviços de parceiros terceiros 1150, de modo que possa ser logado, junto com o tráfego entre os clientes e o serviço de rede primária 1015, pelo lo- gador 29150 para análise pelo detector de ameaça 1060, revisado pelos processadores de ameaça 1080, e, quando necessário, remediado pelo reparador 29160. A figura apresenta um exemplo de uma maneira em que o canalizador pode ser integrado com outros proces- sos normalmente encontrados em um processador de tráfego no serviço de rede, tais como firewalls 29010 e 29090, autenticadores 29020, e criptografadores 29120 decriptografadores 29030, compressores 29110 e descompactadores 29040, tradutores de link 29080, reforma- tadores 29100, e equilibradores de carga 29105.

O tráfego proveniente de clientes 1010 e destinados ao hospedeiro 1015, incluem o tráfego dos clientes e destinam aos parceiros 1150, e incluem o tráfego dos parceiros destinados para todos os clientes entra no processador tráfego de serviço 2010 através de um firewall frontal 29010, que protege o local de hospedeiro da rede externa usando recursos de segurança de baixo nível, tal como o IP + bloqueio de portas e filtragem de pacotes de texto simples. O tráfego do hospedeiro destinado para clientes, tráfego incluso de clientes destinados a parceiro, e tráfego incluso de parceiro destinado a clientes da mesma forma todos saem do processador de tráfego do serviço através do firewall frontal.

Autenticador 29020 é responsável pela negociação de protocolos de criptografia tal como o SSL e TSL com clientes 1010 e parceiros 1150, e para verificação de baixo nível da identidade dos clientes e parceiros e confirmação da identidade do hospedeiro, como seu proxy, por exemplo através de certificados SSL.

O decriptografador 29030 converte de forma segura ações de entrada criptografadas provenientes de clientes 1010 e parceiros 1150 contendo informações pessoais ou proprietárias em texto simples para que elas possam ser examinadas pelo canalizador 29050 e firewall traseiro 29090, e postas em prática pelo hospedeiro 1015. O criptografador 29120 criptografa ações de saída de texto simples provenientes do hospedeiro e recriptografa as ações de saída retransmitidas entre clientes e parceiros para proteger informações sensíveis em rota através da rede para os clientes e parceiros.

Da mesma forma, o descompressor 29040 descomprime ações de entrada proveni-entes de clientes 1010 e parceiros 1150 em texto simples de modo que elas possam ser examinadas pelo canalizador 29050 e firewall traseiro 29090, e postas em prática pelo hospedeiro 1015. O compressor 29110 comprime ações de saída, tais como conteúdo HTML provenientes do hospedeiro e recomprime ações retransmitidas entre clientes e parceiros para uma transmissão mais rápida através da rede.

O canalizador 29050 usa roteador de canalizador 29060 para separar o tráfego de entrada provenientes de clientes 1010 destinado ao hospedeiro 1015, que ele roteia através do canalizador do hospedeiro 29070, a partir do tráfego incluso bidirecional entre clientes e parceiros 1150, que ele roteia através de canalizadores do parceiro 29140, causando um curto circuito do hospedeiro. O canalizador de hospedeiro 29070 edita tráfego hospedeiro de saída para incluir respostas do cliente de volta através dos canalizadores do parceiro. Da mesma forma, canalizadores do parceiro 29140 editam tráfego do cliente parceiro de saída para incluir as respostas do cliente de volta através dos canalizadores do parceiro. O canalizadoré discutido em maior detalhe na fig. 30.

O tradutor de ligação 29080 remapeia pseudônimos de URL externamente visíveis em solicitações de clientes de volta para os URLs internos reais correspondentes, permitindo que a estrutura pública do local de hospedeiro pareça simples, constante, e amigável ao usuário, enquanto protege a estrutura do website real de malfeitores potenciais.

O firewall traseiro 29090 remedia ameaças em ações de entrada de cliente des-comprimidas descriptografadas, usado recursos de alto nível como aplicação- detecção de ataque e detecção de malware. O firewall traseiro também remedia ameaças em ações de hospedeiro de saída, como a divulgação de informações sensíveis e violações de políticas.

O equilibrador de carga 29100 distribui ações de cliente entre os servidores de websites hospedeiro ou centros de dados no serviço de rede 1015, e roteia de volta as ações de hospedeiro correspondentes. Uma maior instalação terá frequentemente equilibra- dores de carga em momentos diversos no processador de tráfego de serviço, cada um alimentandomúltiplas instâncias dos seus componentes a jusante, a fim de tratar eficazmente o tráfego de rede superior. Por exemplo, a autenticação 29020, descriptografia 29030, criptografia 29120, descompressão 29040, compressão 29110, canalização 29050, e reformata- ção 29105 são todos os processos intensivos de computação, para um local movimentado pode ter um ou mais equilibradores de carga entre o firewall frontal e múltiplos autenticado- res e decriptografadores, um equilibrador de carga entre o firewall traseiro e múltiplos refor- matadores, e assim por diante.

O reformatador 29105 reformata as ações de hospedeiro de saída para dispositivos específicos do cliente, tais como telefones celulares, que têm diferentes restrições, como a largura de banda, capacidade de processamento, resolução de tela espacial e temporal, e interatividade.

Throttler 29130 armazena em buffer ações de hospedeiras e ações de parceiro de saída, conforme necessário e alimenta-as para fora, a uma taxa controlada, para combinar com a largura de banda de transmissão para o cliente e outros constrangimentos de taxa.

Logger 29150 registra cada transação, possivelmente a partir de cada processador de tráfego de serviço 2010, incluindo não apenas todas as ações de cliente-hospedeiro e hospedeiro-cliente como em um website comum, mas também todas as transações relacio-nadas ao hospedeiro cliente-parceiro-cliente, para análise pelo detector de ameaça de serviço de rede 1060, usando um relógio mestre único para a temporização precisa. Na modalidade preferida, os tempos de transação são registrados o mais próximo do cliente quanto possível - de preferência no firewall frontal na configuração mostrada - a fim de limitar retardo de ação dos clientes tão firmemente quanto possível, para a análise precisa de ameaças. O logger também pode obter informações de transação adicional do local de hospedeiro 1015, conforme disponíveis e úteis. Por outro lado, o serviço de rede também pode aumentar seus próprios registros com informações do logger 29150, ou pode até mesmo suplantar seus próprios registros com os de logger do processador de tráfego de serviço.

Como explicado na maior parte desta divulgação, o detector de ameaça 1060 analisa os registros de transação emitidos pelo logger 29150 e serviço de rede 1015 para diferentes tipos de ameaças de serviços de rede, a emitindo alertas e relatórios para processadores de ameaça 1080.

Processadores de ameaça 1080, por sua vez, emitem regras de medidas corretivas para o reparador 29160, que implementa as ações de reparação através dos componentes adequados no processador de tráfego de serviço 2010, via o forçador 29170.

Na modalidade preferida, cada fase de processador tráfego de serviços 2010 re-querendopotência de processamento significativa, incluindo reformatadores 29105, tradutores de link 29080, canalizadores de hospedeiros 29070, canalizadores de parceiros 29140, descompressores 291110 e compressores 29040 e decriptografadores 29030, criptografado- res 29120, utiliza um cache para um serviço eficiente, emitindo uma cópia em cache de um recurso processado se os recursos não processados combinarem.

A implantação de canalizador 29050 para processador de tráfego de serviço 2010 pode apresentar novos bugs de software e incompatibilidades, novos riscos de mapeamento de link incorreto, novas tensões de recursos e novas oportunidades para o ataque. Assim, a modalidade preferida também inclui monitores 29190, mostrando em tempo real, informações de diagnóstico, tais como taxas atuais e comparativas de tráfego de canalizador de hospedeiro e tráfego de canalizador de parceiro para cada parceiro, bem como os erros relacionados e ações de Reparação, para monitoramento por processadores de ameaça 1080 - ou os mesmos processadores de ameaça que para o detector de ameaça 1060 ou processadores de ameaça independentes.

A adição de tráfego cliente-servidor e servidor-cliente pode aumentar substancialmente a carga em um processador de tráfego de serviço estabelecido. Em tais casos, na modalidade preferida, roteador 29060 está situado em frente ao canalizador do parceiro offload 29140 em um processador de tráfego de serviço separado do canalizador de hospedeiro 29070, com seus próprios componentes front-end, tais como firewall frontal 29010, autenticador 29020, decriptografador 29030 e criptografador 29120, e descompressor 29040, compressor 29110, throttler 29110, e cache 29180. Em uma modalidade alternativa, o processador de tráfego de serviço separado está localizado em outro ponto da rede externa , talvez juntamente com detector de ameaça 1060, processadores de ameaças 1080, e reparador 29160, com logs de canalizador de hospedeiro retransmitidos para o local do canalizador parceiro através de uma linha dedicada ou tráfego de rede criptografada, e o logger do canalizador de hospedeiro sincronizado ao logger do canalizador do parceiro para precisão.

Dependendo das características de tráfego de serviço de rede, custos, infraestrutu- ra existente, disponibilidade, experiência e outras considerações, os vários componentes do processador de tráfego de serviço 2010 podem ser incorporados como módulos de software em um ou mais servidores físicos ou virtuais, componentes de hardware, uma rede de servidores, um centro de computação em nuvem, ou qualquer combinação destas e de outras  possibilidades.

Os versados na técnica irão reconhecer que estes e outros componentes front-end poderiam ser empregados em muitas configurações alternativas, incluindo empregar várias instâncias de vários componentes, empregando-os em uma ordem diferente, ou omitindo alguns dos componentes ou adicionando outros.

Como descrito no diagrama de fluxo de informações da Fig. 30, o canalizador 29050 (Ver fig. 29) inclui o tráfego de hospedeiro relacionado entre clientes 1010 e serviços de parceiro terceiros 1150 através de canalizadores de parceiro 29140, onde o tráfego - que, de outra forma passa invisível e inacessivelmente entre os serviços de clientes e parceiros - é logado pelo logger 29150 a ser monitorado pelos monitores 29190 (Ver Fig. 29), analisados pelo detector de ameaça 1060, corrigidos pelo reparador 29160 e, opcionalmente, acessados pelo website do hospedeiro 1015. O canalizador inclui tráfego de cliente-hospedeiro apresentado a hospedeiro interpondo o canalizador de hospedeiro 29070 como proxy de hospedeiro reverso* 30010 para os clientes e como direto para proxy de cliente* 30030 para os servidores de hospedeiro, onde paraproxy de parceiro 30020 processa o conteúdo de ações hospedeiro-cliente 1040, encontra todas as referências a serviços de parceiro destinados, e os substitui por pseudônimos reversivelmente mapeados referentes ao canalizador do parceiro.

Da mesma forma, um canalizador de parceiro 29140, que atua como mediador cli- ente*proxy 30040 para os clientes, inclui o tráfego do cliente-parceiro responsivo, agindo como cliente*proxy mediato 30060 para parceiros 1150, e inclui o tráfego cliente-parceiro conduzido pelo parceiro subsequente usando paraproxy de parceiro 30050 para encontrar todas as referências de parceiro alvo no conteúdo das ações de parceiro-cliente 1190 e re- versivelmente apelida-os para o canalizador de parceiro.

No detalhe, a rede está configurada de modo que as solicitações de cliente 1020 destinadas para o serviço de rede primária 1015 são interceptadas pelo hospedeiro*proxy reverso 30010 no canalizador de hospedeiro 29070. O hospedeiro*proxy usa mapeador de cliente 30070 para reversivelmente substituir os endereços de retorno do cliente nas ações de cliente-hospedeiro*proxy com cliente*pseudônimo local para o canalizador de hospedei- ro, emitindo as solicitações modificadas como ações cliente*proxy - hospedeiro*proxy 30080 de modo que as respostas de hospedeiro 30110 serão encaminhadas de volta para o canalizador de hospedeiro em vez de ir diretamente para o cliente. O mapeador de cliente pode opcionalmente também anexar endereço público do cliente 11010 à ação editada, caso seja requerido pelo paraproxy de parceiro 30020 ou pelo serviço de rede primária.

Encaminhar cliente*proxy 30030 no canalizador de hospedeiro 29070 usa hospedeiro * remapeador 30090 para substituir pseudônimos * hospedeiro nas ações cliente*proxy - hospedeiro*proxy 30080 com os endereços de hospedeiros reais, emitindo as solicitações modificadas como ações cliente*proxy - hospedeiro 30100. Observe que a tradução de cliente para as transações de hospedeiro não pode ser necessária se o canalizador de hospedeiro se comunica com um hospedeiro e único servidor através de uma conexão dedicada ou como um módulo co-residente e não através de uma rede.

Ao interceptar respostas hospedeiro - cliente*proxy 30110, cliente * proxy direto 30030 no canalizador de hospedeiro 29070 usa mapeador de hospedeiro 30120 para rever- sivelmente substituir os endereços de retorno de hospedeiro nas ações de hospedeiro com seus pseudônimos de canalizador de hospedeiro, emitindo as respostas modificadas como ações hospedeiro * proxy - cliente * proxy 30130.

Ações de serviço de hospedeiro 30110 muitas vezes contêm referências a outros serviços disponíveis no website principal, e também podem conter referências a serviços de terceiros 1150 em websites de parceiro. Paraproxy de parceiro 30020 no canalizador de hospedeiro 29070 usa inclusor de parceiro 30140 para encontrar referências do parceiro nas ações de serviços de hospedeiro de saída que correspondem aos alvos na regra básica de tradução de referência de parceiro 30150, e as substituí por pseudônimos locais para o ca-nalizador de parceiro especificado 29140, emitindo os resultados inclusos como hospedeiro * proxy - cliente * proxy ação * proxies 30160, a fim de que todas as ações do cliente sobre essas referências sejam roteadas através do canalizador do parceiro especificado em vez de irem diretamente para os websites do parceiro 1150.

Em uma página web HTML, e hospedeiro e parceiro são especificados como hiper- links de URI incorporados na descrição da página de HTML, correspondentes a controles clicáveis por usuários na representação gráfica da página de web. Na modalidade mais simples, inclusor de parceiro 30140 usa um substituidor de sequência de caracteres de finalidade geral para substituir todas as ocorrências de padrões de URI alvo de acordo com a regra básica de tradução de parceiro 30150. Em uma modalidade mais sofisticada, o inclusor de parceiro analisa a descrição de HTML, determina a codificação de caracteres apropriada, e busca pelas sequências de destino apropriadas, por exemplo, apenas nos campos 'href' de tags âncora ('a'). Mais geralmente, o tradutor de endereço de parceiro não é aplicado apenas aos serviços de HTML, mas, usando técnicas análogas óbvias para os versados na técnica, para serviços de outros tipos de MIME listados nas regras básicas de tradução de parceiro.

Um URI pode ser especificado em muitas maneiras diferentes. Por exemplo, os se-guintessão todos equivalentes: http://www.***.com/ http://***.com/ (omitindo o subdomínio "www" opcional) http://www.***.com (omitindo o indicador de diretório "/" opcional) http://www.***.com// (adicionando um indicador de diretório "/"supérfluo) http://www.***.com/# (adicionando um indicador de âncora "#" vazio) http://www.***.com/? (adicionando um indicador de consulta "?" vazio) http://www.***.com/.. (adicionando um indicador de diretório pai ".." vazio) http://www.***.com/index.html (adicionando o nome de página padrão "in- dex.html" opcional) http://www.***.com:80/ (adicionando a porta World Wide Web HTTP " 80"opcional) HTTP://wWw.Google.cOm/(opcionalmente capitalizando letras) http://w%77w.67oogle.c.%6fm/ (opcionalmente caracteres de codificação de por-centagem) http://garbage@www.***.com/ (adicionando um código de autorização ignorado) http://74.125.19.106/ (usando o endereço IP decimal 4-octeto) http://1249710954/ (utilizando o endereço IP decimal) http://0112.0175.0023.0152/ (usando o endereço IP octal 4-octeto) http://0112.0175.0023.0000152/ (adicionado zeros líder supérfluos) http://0x4a.0x7d.0x13.0x6a/ (usando o endereço IP 4-octeto hexadecimal)

Além das variantes aqui exemplificadas, um URI pode ser especificado em relação aquele da página ou iframe no qual ele ocorre, ou pode ser um URN (nome de recurso uniforme), um PURL (localizador de recurso uniforme persistente), ou mesmo algum outro tipo de variante ainda definido. Na modalidade preferida, para facilitar a detecção de fraudes através da utilização de URIs fora do padrão, para reduzir o tamanho das regras básicas, e para facilitar o cache de ações de hospedeiro, regra básica de paraproxy de parceiro 30150 inclui regras para primeiro resolver cada um URI para forma canônica, utilizando algoritmos bem conhecidos e serviços, antes de comparar o URI canônico com os alvos na tabela de conversão de parceiro.

Alguns websites têm convenções sinonímias adicionais, tais como, opcionalmente, nomear um serviço através de uma sequência de consulta em vez de um percurso de diretório; dispor subdiretórios em uma matriz, em vez de em uma árvore; aceitar abreviações opcionais ou erros ortográficos de nomes de domínio, nomes de diretórios ou nomes de serviço, ou atribuir números de série sinônimos aos serviços. Na modalidade preferida, mais uma vez para facilitar a detecção de fraudes que usam URIs fora do padrão, para simplificar a base de regras, e para facilitar o armazenamento em cache, base de regra de tradução de parceiro 30150 é aumentada com algoritmos personalizados e regras para a redução de tais sinônimos específicos de site para a forma canônica, antes de comparar o URI canônico com os alvos na tabela de conversão de parceiro.

Em muitos casos, todos os URIs dentro do domínio do parceiro, um subdomínio do mesmo, ou um percurso respectivo, devem ser inclusos. Na modalidade preferida, inclusor de parceiro 30140 permite que URIs alvos e seus pseudônimos sejam especificados com padrões genéricos na base de regra 30150, por exemplo, usando a sintaxe de expressão regular padrão para correspondência de padrão de sequência e substituição, ou usando nomes de variáveis para os diferentes componentes de um URI.

Por URIs padrão, os parceiros * pseudônimos de inclusão podem assumir diferen-  tes formas. Por exemplo, o URL do parceiro https://www.partner.com/percurso/página.html#âncora?consultapode ser mapeado diretamente para um parâmetro de consulta, uma porta atribuída dinamicamente, um diretório, um subdomínio local para o hospedeiro ou um domínio diferente: https://www.hospedeiro.com/?service=parceiro%2fpercurso%2fpage.html%23âncora%3fconsulta Https://www.hospedeiro.com:12345/percurso/página.html#âncora?consulta https://www.hospedeiro.com/parceiro/percurso/página.html#âncora?consulta https://parceiro.hospedeiro.com/percurso/página.html#âncora?consulta https://www.hospedeiroparceiro.com/percurso/página.html#âncora?consulta

Na modalidade preferida, o inclusor de parceiro 30140 suporta todos estes métodos em base de regra 30150, permitindo que o website do hospedeiro escolha o mais adequado. Na modalidade preferida, os URLs são mapeados através de algoritmos, como nos exemplos, de modo que nenhuma tabela de tradução de endereço detalhada é necessária. Na modalidade preferida, os URLs são mapeados diretamente para preservar a sua legibilidade humana, como nos exemplos, em vez de, por exemplo, serem substituídos pelos números de série ou desordenados.

Hospedeiro * proxy reverso 30010 no canalizador de hospedeiro 29070 usa rema- peador * cliente 30170 para substituir os pseudônimos * cliente no hospedeiro * proxy - cliente * proxy ação * proxy de inclusão 30160 com os endereços de clientes reais, emitindo as respostas modificadas como hospedeiro * proxy - cliente ação * proxies 1040, e encaminha- os em direção aos respectivos clientes 1010.

Quando um cliente 1010 atua sobre um parceiro * pseudônimo em um hospedeiro * proxy - cliente ação * proxy de inclusão 1040 (ou em um parceiro * proxy - cliente ação * proxy de inclusão 30280), em vez de serem desviados diretamente para o website parceiro, a referida ação cliente-parceiro * proxy ação 30180 é canalizada através de um canalizador do parceiro 29140, que pode ser localizado no website principal 1015, um website de registro, um website de monitoramento, um website de detecção de ameaça, em uma nuvem de computação, ou em outro lugar. Analogamente ao mapeador de cliente 30070 no hospedeiro * proxy reverso 30010, proxy * parceiro mediato 30040 usa o mapeador de cliente 30190 para reversivelmente substituir os endereços de retorno de cliente nas ações cliente - parceiro * proxy entrantes com cliente * pseudônimo local para o canalizador de parceiro, emitindo as solicitações modificadas como ações cliente * proxy - parceiro * proxy 30200, de modo que as respostas de parceiro 1190 serão roteadas de volta para o canalizador de parceiro, em vez de irem diretamente para o cliente. O mapeador de cliente pode opcionalmente também anexar endereço público do cliente 11010 à ação editada, caso seja requerido pelo paraproxy de parceiro 30050 ou o serviço de parceiro 1150.

O canalizador do parceiro usa então parceiro * remapeador 30210 em cliente * proxy mediado 30,060 para remapear os pseudônimos de parceiro locais para os endereços reais do serviço de parceiro, e envia as ações cliente * proxy - parceiro 1180 em direção aos websites de parceiro especificados 1150.

Quando um serviço de parceiro 1150 responde a uma ação do cliente referido incluso 1180, sua resposta arrastada 1190, em vez de ir diretamente de volta para o cliente, é canalizada de volta através do canalizador de parceiro 29140. Lá, cliente * proxy mediado 30060 usa mapeador de parceiro 30220 para reversivelmente substituir os endereços de retorno parceiro nas ações de parceria com os seus pseudônimos parceiro- canalizador, emitindo as respostas modificadas como ações parceiro * proxy - cliente * proxy 30230. Note-se que a tradução de endereços de clientes pode ser desnecessária para transações de parceiro referido, se o canalizador do parceiro tem uma conexão dedicada para os websites d eparceiro em questão.

Analogamente ao paraproxy de parceiro 30020 no canalizador de hospedeiro 29070, paraproxy de parceiro 30050 no canalizador do parceiro 29140 usa inclusor de parceiro 30240 para encontrar referências do parceiro nas ações de parceiro de serviços de saída correspondentes aos alvos na base de regra de tradução de referência de parceiro 30250, e substituí-los com pseudônimo local para o canalizador do parceiro especificado, emitindo os resultados de inclusão como parceiro * proxy - cliente * proxy ação * proxy 30260, a fim de que todas as ações do cliente sobre essas referências sejam roteadas através do canalizador do parceiro desejado em vez de irem diretamente para o respectivo web-  site parceiro 1150.

Finalmente, parceiro * proxy mediado 30040 no canalizador de hospedeiro 29140 então usa remapeador * cliente 30270 para substituir os cliente * pseudônimos no parceiro * proxy - cliente * proxy ação * proxies de inclusão 30260 com os endereços de clientes reais, emitindo as respostas modificadas como parceiro * proxy - cliente ação * proxies 30280, e as encaminha em direção aos respectivos clientes 1010.

Na modalidade preferida, o paraproxies de parceiro 30020 e 30050 são acelerados com caches 30310 e 30320, respectivamente. Para recursos estáticos contendo referências de parceiro que exigem mapeamento, os caches armazenam uma cópia do recurso com as referências já mapeadas, junto com informações para determinar se a origem mudou, tal como uma data e soma de verificação do recurso não mapeado. Para recursos estáticos que não requerem remapeamento, os caches armazenam apenas a mudança determinante, a ausência de conteúdo que indica que a origem pode ser passada como inalterada. Cada cache, ou itens relevantes nela incluídos, também é apagado quando respectivas bases de regra de tradução de parceiro 30150 ou 30250 muda.

Base de regras de tradução de endereço de parceiro 30150 e 30250 são mantidas por reparador 29160 (Veja fig. 29) por meio de ações de reparação 1090. Em princípio, as duas bases de regras podem diferir: O serviço de hospedeiro 1015 e serviços de parceiro 1150 emitem diferentes conjuntos de respostas 30110 e 1190 com diferentes conteúdos, geralmente contendo diferentes conjuntos de referências a websites de parceiro, que podem ser úteis para rotear o tráfego de forma diferente, mesmo para as referências de parceiro, no caso de um ataque ser direcionado diretamente para um site parceiro do que para o sítio de hospedeiro. No entanto, se as bases de regras diferem, ou se o canalizador de hospedeiro 29070 e o canalizador do parceiro 29140 não são co-residentes, é importante manter a base de regra sincronizada, tanto para evitar colisões acidentais onde diferentes serviços de parceirosão indesejavelmente mapeados para o mesmo endereço, e evitar referir uma ação a um canalizador despreparado para remapear seu destino.

Na modalidade preferida, as substituições nas bases de regra de tradução de endereço 30150 e 30250 podem ser condicionadas pelo cliente, de modo que os clientes suspei- tos de abuso através de serviços de parceiro 1150 podem ser impedidos de visitar os parceiro ou desviarem para outros serviços nesses sites, no site de hospedeiro, no site de detecção de ameaça, ou em outro lugar para monitoramento ou outra Reparação, ou alterando os endereços de serviço de parceiro nas ações parceiro * proxy - cliente * proxy 30230 depois de visitar um site parceiro, mudar o endereços de parceiro nas ações cliente * proxy - parceiro * proxy 30200 antes de visitar um site parceiro, ou mudando os endereços de parceiro nas ações hospedeiro * proxy - cliente * proxy 30130 antes do cliente poder mesmo tentar visitar um website parceiro. Tradução de parceiro cliente condicional também é útil para testar a inclusão de um serviço de parceiro ou uma reparação, limitando uma substituição para os endereços IP de pessoal de teste, e para a eliminação, limitando-o a um grupo experimental de clientes.

Ao substituições de endereço de hospedeiro, opcionalmente específicas de cliente, para as bases de regras 30150 e 30250, o tradutor de parceiro também pode ser usado para mudar os endereços de serviço de hospedeiro em ações de clientes entrantes ou ser incorporado em ações de serviço de saída, a fim de corrigir abuso envolvendo uma combinação de serviços de parceiro e hospedeiro, ou serviços de hospedeiro sozinho, seja em geral ou por clientes específicos.

Mais geralmente, uma vez que qualquer serviço de parceiro pode-se referir a serviços de parceiro não referidos pelo hospedeiro ou um parceiro anterior, a base de regra 30250 no canalizador de parceiro 29140 pode direcionar serviços adicionais não direcionados na base de regras 30150 no canalizador de hospedeiro 29070. Assim, o canalizador pode ser usado para incluir comunicação não apenas com os parceiros fixos, mas com parceiro de parceiros, e além.

O canalizador de hospedeiro 29070 e o canalizador do parceiro 29140 emitem registros de suas ações para logger 29150 (Ver Fig. 29) como registro de canalizador de hospedeiro 30290 e registro de canalizador de parceiro 30300, respectivamente, usando o tempo atual 6110 dado pelo relógio mestre 6100 (ver fig. 6), para permitir que o detector de ameaça 1060 detecte ameaças que envolvem websites de parceiro, e para que o pessoal de segurança possa monitorar diretamente a operação de canalizador 29050 para eventos sus- peitos e tendências utilizando monitor 2900v0 (Ver fig. 29). Logs de canalizador do parceiro também ajudam o detector de ameaça a melhorar as estatísticas de tempo para as transações cliente hospedeiro, considerando excursões para websites de parceiro.

Uma modalidade da presente invenção refere-se a um produto de armazenamento em computador com um meio de armazenamento legível por computador tendo nele um código de computador para a execução de várias operações implementadas em computador. Os meios de comunicação e código de computador podem ser os especialmente concebidos e construídos para as finalidades da presente invenção, ou eles podem ser do tipo bem conhecido e disponível para aqueles que possuem habilidade nas áreas de software de computador. Exemplos de meios legíveis por computador incluem, mas não estão limitados a: a mídia magnética, tais como discos rígidos, disquetes e fitas magnéticas; mídias ópticas tais como DVDs, CD-ROMs e dispositivos holográficos; mídia magneto-óptica, e dispositivos de hardware que são especialmente configurados para armazenar e executar um código de programa, tais como circuitos integrados de aplicação específica ("ASIC"), dispositivos lógicosprogramáveis ("PLD") e dispositivos ROM e RAM. Exemplos de código de computador incluem o código de máquina, tal como o produzido por um compilador, e arquivos contendo elevado nível de código que são executados por um computador através de um intérprete. Por exemplo, uma modalidade da presente invenção pode ser implementada usando Java ®, C++, ou outra linguagem de programação orientada a objetos e ferramentas de desenvolvimento. Outra modalidade da invenção pode ser implementada em conjunto de circuitos cabeados no lugar de, ou em combinação com, instruções de software executáveis por máquina.

A descrição anterior, para fins de explicação, usou nomenclatura específica para prover uma compreensão profunda da invenção. No entanto, será evidente para os versados na técnica os detalhes específicos que não são necessários para a prática da invenção. Deste modo, as descrições anteriores de modalidades específicas da invenção são apresentadas para fins de ilustração e descrição. Elas não se destinam a ser exaustivas ou a limitar a invenção às formas precisas divulgadas, obviamente, muitas modificações e variações são possíveis à luz dos ensinamentos anteriores. As modalidades foram escolhidas e descritas de modo a explicar melhor os princípios da invenção e as suas aplicações práticas, elas, assim, permitem a outros versados na técnica a melhor forma de utilizar a invenção e várias modalidades com várias modificações conforme são apropriadas para o uso particular con-templado. Pretende-se que as seguintes reivindicações e seus equivalentes definam o âmbi- to da invenção.

Claims (9)

1. Meio de armazenamento não transitório legível por computador com instruções para executar em um computador hospedeiro, CARACTERIZADO por compreender instruções para: (i) gravar uma relação entre um site parceiro e o computador hospedeiro; (ii) substituir uma referência ao site parceiro com um pseudônimo do site parceiro referenciando o computador hospedeiro; (iii) entregar o pseudônimo do site parceiro para um cliente; (iv) substituir o pseudônimo do site parceiro para a referência ao site parceiro em resposta ao recebimento do pseudônimo do site parceiro a partir do cliente; (v) aumentar um endereço do cliente com um pseudônimo de endereço; (vi) enviar o pseudônimo de endereço para o site parceiro; (vii) receber a partir do site parceiro uma ação do parceiro e o pseudônimo de endereço; (viii) trocar o endereço pelo pseudônimo de endereço; (ix) entregar a ação do parceiro para o cliente utilizando o endereço; (x) monitorar de (ii) a (ix) para identificar atividade de cliente que constitui uma ameaça à segurança no computador hospedeiro ou no site parceiro; e (xi) implementar uma ação corretiva em resposta à ameaça à segurança, em que a ação corretiva é selecionada dentre bloquear o cliente, atrasar o cliente, desviar o cliente para uma página web inofensiva e fornecer ao cliente informação falsa.

2. Meio de armazenamento legível por computador, de acordo com a reivindicação 3, CARACTERIZADO por compreender adicionalmente instruções executáveis para: analisar uma estrutura lógica do site parceiro; preparar um mapa de site parceiro detalhando ligações intrínsecas entre páginas web, níveis de acesso intrínsecos, níveis de privilégio intrínsecos e níveis de segurança intrínsecos; avaliar falhas de segurança na estrutura lógica do site parceiro; determinar se uma transição observada é consistente com a estrutura lógica do site parceiro; produzir uma pontuação de ameaça de sessão com base no monitoramento e na estrutura lógica do site parceiro; emitir um aviso para o site parceiro em resposta a uma identificação de uma falha de segurança estrutural na estrutura lógica do site parceiro; detectar aparecimento de um novo serviço que é inconsistente com uma lista pré- existente de serviços de site parceiro; reconstruir uma pluralidade de sessões de site parceiro para identificar a ameaça de segurança; criptografar comunicações entre o computador hospedeiro e um dentre o site parceiro e o cliente; acessar informações de segurança dos centros de dados voltados para cliente ou dos centros de dados de serviço interno.

3. Meio de armazenamento legível por computador, de acordo com a reivindicação 4, CARACTERIZADO por compreender adicionalmente instruções executáveis para analisar comunicações interceptadas entre o cliente e o site parceiro para avaliar a estrutura lógica do site parceiro.

4. Meio de armazenamento legível por computador, de acordo com a reivindicação 1, CARACTERIZADO por o computador hospedeiro ser configurado como um servidor físico dedicado, um servidor virtual compartilhado com outros serviços, uma parte de uma fazenda de servidores ou uma fazenda de servidores virtuais em uma nuvem de computação.

5. Meio de armazenamento legível por computador, de acordo com a reivindicação 1, CARACTERIZADO por compreender adicionalmente instruções executáveis para alertar uma vítima da ameaça de segurança utilizando um canal de comunicação independente.

6. Meio de armazenamento legível por computador, de acordo com a reivindicação 1, CARACTERIZADO por o computador hospedeiro ser controlado por uma primeira entidade; e em que as instruções para substituir a referência ao site parceiro com o pseudônimo do site parceiro inclui instruções para: receber, a partir de terceiros controlando o site parceiro, conteúdo web incluindo (i) material de terceiros para apresentação a um usuário do cliente e (ii) um hi- perlink de terceiros que identifica o site parceiro, os terceiros sendo diferentes da primeira entidade controlando o computador hospedeiro; gerar, pelo computador hospedeiro, uma página web tendo conteúdo web modificado, o conteúdo web modificado incluindo (i) o material de terceiros para apresentação ao usuário do cliente e (ii) um hiperlink de computador hospedeiro no lugar do hiperlink de terceiros, o hiperlink de computador hospedeiro identificando o computador hospedeiro; fornecer a página web tendo o conteúdo web modificado para o cliente; e executar tradução de endereço de rede para permitir que o cliente e o site parceiro troquem informações através de diferentes redes.

7. Meio de armazenamento legível por computador, de acordo com a reivindicação 6, CARACTERIZADO por cada um dentre o cliente, o computador hospedeiro e o site parceiro residir em uma rede pública; e em que as instruções para fornecer a página web tendo o conteúdo web modificado para o cliente incluem instruções para enviar, a partir do computador hospedeiro, uma página web que inclui o hiperlink de computador hospedeiro identificando o computador hospedeiro, um endereço IP de computador hospedeiro para identificar uma fonte de rede da página web, e um endereço IP de cliente para identificar um destino de rede da página web.

8. Método para fornecer segurança em um computador hospedeiro controlado por uma primeira entidade, CARACTERIZADO por compreender: receber, a partir de terceiros controlando um site parceiro, conteúdo web incluindo (i) material de terceiros para apresentação para um usuário de um dispositivo cliente e (ii) um hiperlink de terceiros que identifica o site parceiro, os terceiros sendo diferente da primeira entidade controlando o computador hospedeiro; gerar, pelo computador hospedeiro, uma página web tendo conteúdo web modificado, o conteúdo web modificado incluindo (i) o material de terceiros para apresentação ao usuário do dispositivo cliente e (ii) um hiperlink de computador hospedeiro no lugar do hiper- link de terceiros, o hiperlink de computador hospedeiro identificando o computador hospedeiro; fornecer a página web tendo o conteúdo web modificado para o dispositivo cliente; receber uma mensagem do cliente do dispositivo cliente, a mensagem do cliente in-cluindo (i) um pedido para acessar um recurso do site parceiro e (ii) um endereço de cliente identificando o dispositivo cliente; gerar uma mensagem de proxy com base na mensagem do cliente, a mensagem de proxy incluindo (i) o pedido para acessar um recurso do site parceiro e (ii) um endereço proxy identificando o computador hospedeiro; fornecer a mensagem de proxy ao site parceiro; receber uma mensagem de ação de parceiro a partir do site parceiro em resposta à mensagem de proxy, a mensagem de ação de parceiro incluindo (i) uma resposta de ação de parceiro e (ii) um endereço de site parceiro identificando o site parceiro; gerar uma mensagem de ação de proxy com base na mensagem de ação de parceiro, a mensagem de ação de proxy, a mensagem de ação de parceiro incluindo (i) uma resposta de ação de parceiro e (ii) um endereço de proxy identificando o computador hospedeiro; fornecer a mensagem de ação de proxy ao dispositivo cliente; monitorar comunicações entre o dispositivo cliente e o site parceiro através do computador hospedeiro para identificar ameaças à segurança resultantes das comunicações; e implementar uma ação corretiva em resposta a uma ameaça à segurança identifi-cada, a ação corretiva sendo selecionada dentre bloquear o dispositivo cliente, atrasar o dispositivo cliente, desviar o dispositivo cliente para uma página web inofensiva e fornecer ao dispositivo cliente informação falsa.

9. Aparelho de segurança de rede, CARACTERIZADO por compreender: uma interface de comunicação; memória; e circuitos de processamento acoplados à interface de comunicação e à memória, a memória armazenando instruções que, quando executadas pelos circuitos de processamento, fazem os circuitos de processamento: receber, a partir de terceiros controlando um site parceiro, conteúdo web incluindo (i) material de terceiros para apresentação para um usuário de um dispositivo cliente e (ii) um hiperlink de terceiros que identifica o site parceiro, os terceiros sendo diferente da primeira entidade controlando o computador hospedeiro, gerar, pelo computador hospedeiro, uma página web tendo conteúdo web modificado, o conteúdo web modificado incluindo (i) o material de terceiros para apresentação ao usuário do dispositivo cliente e (ii) um hiperlink de computador hospedeiro no lugar do hiperlink de terceiros, o hiperlink de computador hospedeiro identificando o computador hospedeiro; fornecer a página web tendo o conteúdo web modificado para o dispositivo cliente, receber uma mensagem de cliente a partir do dispositivo cliente, a mensagem do cliente incluindo (i) um pedido para acessar um recurso do site parceiro e (ii) um endereço de cliente identificando o dispositivo cliente, gerar uma mensagem de proxy com base na mensagem de cliente, a mensagem de proxy incluindo (i) o pedido para acessar um recurso do site parceiro e (ii) um endereço proxy identificando o computador hospedeiro, fornecer a mensagem de proxy ao site parceiro, receber uma mensagem de ação de parceiro a partir do site parceiro em resposta à mensagem de proxy, a mensagem de ação de parceiro incluindo (i) uma resposta de ação de parceiro e (ii) um endereço de site parceiro identificando o site parceiro, gerar uma mensagem de ação de proxy com base na mensagem de ação de parceiro, a mensagem de ação de proxy, a mensagem de ação de parceiro incluindo (i) a resposta de ação de parceiro e (ii) um endereço de proxy identificando o computador hospedeiro, fornecer a mensagem de ação de proxy ao dispositivo cliente, monitorar comunicações entre o dispositivo cliente e o site parceiro através do compu-tador hospedeiro para identificar ameaças à segurança resultantes das comunicações, e implementar uma ação corretiva em resposta a uma ameaça à segurança identificada, a ação corretiva sendo selecionada dentre bloquear o dispositivo cliente, atrasar o dispositi- vo cliente, desviar o dispositivo cliente para uma página web inofensiva e fornecer ao dispo-sitivo cliente informação falsa.

Images