Redefinindo a detecção de ameaças da IoT: o poder da análise cumulativa na estrutura de Cumad

Tabela de links

Resumo e 1. Introdução

2. Trabalho relacionado

3. Antecedentes no AutoEncoder e SPRT e 3.1. AutoEncoder

3.2. Teste de razão de probabilidade seqüencial

4. Projeto de Cumad e 4.1. Modelo de rede

4.2. Cumad: detecção cumulativa de anomalia

5. Estudos de avaliação e 5.1. Conjunto de dados, recursos e configuração do sistema Cumad

5.2. Resultados de desempenho

6. Conclusões e referências

3.2. Teste de razão de probabilidade seqüencial

O teste de razão de probabilidade seqüencial (SPRT) é uma ferramenta estatística simples, mas poderosa, que encontrou aplicações em muitos domínios diferentes, em particular, detecção de falhas ou controle de qualidade [7]. O SPRT é uma variante do teste de razão de probabilidade tradicional para testar em que distribuição (ou com quais parâmetros de distribuição), é mais provável que ele tenha a sequência observada de amostras. Diferentemente do teste de razão de probabilidade tradicional que requer um número fixo predefinido de amostras para realizar o teste, a SPRT funciona de maneira on-line; Ele atualiza a medida estatística correspondente à medida que as amostras chegam sequencialmente e podem concluir quando amostras suficientes chegaram para chegar a uma decisão. Em sua forma mais simples, a SPRT é um método estatístico para testar uma hipótese nula simples contra uma hipótese alternativa simples. A seguir, descreveremos mais formalmente a operação do SPRT.

Vamos denotar uma variável aleatória de Bernoulli com um parâmetro desconhecido θ, e deixe yi, para i = 1, 2 ,. . . denotar as correspondentes observações sucessivas de y. SPRT pode ser usado para testar uma hipótese nula simples H0 que θ = θ0 contra uma hipótese alternativa simples H1 que θ = θ1, mais especificamente,

” alt=”” aria-hidden=”true” />

Como uma ferramenta estatística simples e poderosa, a SPRT possui algumas propriedades críticas e desejadas que levam à ampla aplicação da técnica em muitos domínios diferentes. Primeiro, as taxas falsas positivas e falsas negativas do SPRT podem ser especificadas pelas taxas de erro desejadas pelo usuário, que por sua vez controlam os limiares do modelo. Segundo, foi provado que, entre todos os algoritmos de teste da razão de probabilidade seqüencial e não sequencial, a SPRT minimiza o número esperado de observações para chegar a uma decisão sem erros maiores. Em outra maneira, em média a SPRT pode chegar rapidamente a uma conclusão em comparação com outros algoritmos de teste de taxa de probabilidade.

4. Design de Cumad

Nesta seção, discutiremos primeiro o modelo de rede considerado, onde Cumad será implantado e, em seguida, apresentaremos o design da estrutura de Cumad.

4.1. Modelo de rede

A Figura 2 ilustra o modelo de rede conceitual, onde Cumad é implantado. Conforme mostrado na figura, para que a CUMAD realize sua tarefa para detectar dispositivos IoT comprometidos em uma rede, a Cumad precisa ter acesso ao tráfego de rede associado aos dispositivos IoT na rede. Dependendo dos cenários de implantação do Cumad na rede e da arquitetura de rede correspondente, pode haver algumas maneiras diferentes de Cumad obter o tráfego de rede correspondente dos dispositivos IoT. Em essência, a Cumad como uma solução baseada em rede pode ser implantada de maneira semelhante aos sistemas de detecção de intrusões baseados em rede.

No design atual do CUMAD, os recursos (estatísticos) do tráfego de rede bruta serão extraídos e alimentados a Cumad para detectar dispositivos IoT comprometidos. Cada ponto de dados de entrada alimentado ao Cumad compreende esses recursos extraídos e pode ser resumido em diferentes níveis de granularidade do tráfego de rede, como pacotes, fluxos e janelas de tempo. Esses recursos capturarão as características comportamentais da rede dos dispositivos IoT correspondentes. Na Seção 5, discutiremos os recursos de tráfego de rede contidos no conjunto de dados N-BAIOT do domínio público quando realizamos estudos de avaliação no Cumad [8].

4.2. Cumad: detecção cumulativa de anomalia

A Figura 3 ilustra a arquitetura de alto nível da estrutura de Cumad. Cumad consiste em dois componentes principais: um componente de detecção de anomalia (ADC) e um componente cumulativo de anomalia (CAC). Supondo que o modelo tenha sido treinado adequadamente (será discutido em breve), dado um ponto de dados de entrada com os recursos correspondentes, a principal responsabilidade do ADC é classificar um ponto de dados de entrada como normal ou anômalo. Após a classificação do ponto de dados de entrada, o resultado é passado para o segundo componente (CAC), que manterá uma visão cumulativa do comportamento de tráfego de rede do dispositivo IoT correspondente, mesclando sequencialmente os resultados de classificação individuais na exibição. Quando evidências suficientes em um dispositivo de IoT foram coletadas para indicar que ele foi comprometido, um alerta será gerado. A seguir, descreveremos cada componente em detalhes, tanto no treinamento quanto no modelo de treinamento e na implantação para detectar dispositivos IoT comprometidos.

Observamos que diferentes tipos de dispositivos IoT realizam funcionalidades drasticamente diferentes e, além disso, gostaríamos de detectar qual dispositivo IoT está comprometido, precisamos desenvolver um modelo CUMAD separado para cada dispositivo de IoT e monitorar seus comportamentos de tráfego de rede separadamente usando seus modelos Cumad correspondentes. Portanto, as discussões a seguir são para um dispositivo de IoT. Observamos que, embora existam tipos muito diversos de dispositivos de IoT na Internet, o AutoEncoder é uma poderosa rede neural capaz de aprender diferentes modelos. Portanto, somos capazes de construir diversos modelos de autoencoder, um para cada dispositivo de IoT, apesar de seus comportamentos de tráfego de rede muito diferentes de

esses dispositivos IoT. Além disso, os dispositivos IoT também nos oferecem oportunidades únicas para estabelecer os modelos de comportamentos normais, em comparação com os sistemas de computador tradicionais. Em particular, cada dispositivo IoT executa apenas algumas funcionalidades simples bem definidas de maneira autônoma ou semiautônoma, com interações muito limitadas do usuário após a configuração e configuração do dispositivo inicial. Isso torna mais simples estabelecer um modelo de comportamentos normais na realização de detecção de anomalia.

4.2.1. Modelo de treinamento e configuração. Antes que o CUMAD possa ser usado para monitorar o tráfego de rede para detectar dispositivos IoT comprometidos, precisamos treinar um sistema Cumad para cada dispositivo IoT para que ele possa aprender o modelo normal do dispositivo. Durante a fase de treinamento de um sistema Cumad implantado, é fundamental que apenas aliviemos o tráfego de rede normal (benigno) do dispositivo ao sistema. Isso pode ser feito, por exemplo, quando um dispositivo IoT é implantado pela primeira vez na rede. Para minimizar os falsos positivos durante o estágio de detecção, também é importante que Cumad tenha uma visão razoavelmente completa de todo o comportamento normal do tráfego de rede do dispositivo.

Conforme discutido acima, a premissa de usar um autocoderador como mecanismo de detecção de anomalia é que, embora possa efetivamente reconstruir os pontos de dados semelhantes aos pontos de dados que ele já viu anteriormente durante o estágio de treinamento, em geral tem um desempenho ruim para reconstruir os pontos de dados que diferem substancialmente dos dados de treinamento. Isso se manifesta em grandes erros de reconstrução. Portanto, usaremos o erro de reconstrução como pontuação de anomalia e, quando a pontuação da anomalia é maior que o limite predefinido, classificamos o ponto de dados de entrada correspondente como uma amostra anômala.

Os parâmetros α e β são a taxa falsa positiva e taxa falsa negativa, desejadas pelo usuário, respectivamente. Eles normalmente têm valores pequenos para todas as aplicações práticas, por exemplo, na faixa de 0,01 a 0,05. O valor inicial de λn na Eq. (1) está definido como 0 durante o estágio de configuração do sistema. A funcionalidade do módulo de alerta é gerar alerta adequado para informar os administradores do sistema sobre a detecção de um dispositivo IoT comprometido. Outras ações também podem ser tomadas com base nas políticas de segurança locais, por exemplo, informando os agentes adequados para isolar o dispositivo IoT comprometido.

4.2.2. Detecção. Depois que o modelo foi treinado e os parâmetros necessários foram definidos para o sistema Cumad, ele pode ser usado para monitorar o tráfego de rede para detectar se o dispositivo IoT correspondente foi comprometido. A seguir, descrevemos as etapas básicas de um sistema Cumad na execução da tarefa de detecção (consulte o algoritmo 1).

gerado para indicar um ponto de dados normal. A saída do módulo detector é então passada para o módulo SPRT para determinar se evidências suficientes foram acumuladas para tomar uma decisão sobre a natureza do dispositivo IoT (comprometido ou normal; linha 10 do algoritmo). A SPRT atualiza a taxa de probabilidade meça λn de acordo com a Eq. (1), como a sequência de saída 0 (ponto de dados normal) e 1 (ponto de dados anômalos) do módulo do detector (linhas 13 a 18). Após o valor de λn ser atualizado para cada ponto de dados de entrada, o SPRT compara o valor de λn com os dois limites A e B para determinar se uma decisão pode ser tomada (linhas 20 a 29). Quando o valor de λn acertar ou cruzar o limite superior b, a SPRT concluirá que a hipótese alternativa H1 é verdadeira, ou seja, o dispositivo IoT foi comprometido. Nesse caso, a SPRT informará o módulo de alerta a detecção de um dispositivo IoT comprometido. O alerta adequado será gerado e os administradores correspondentes do sistema serão informados. Além disso, a partir deste momento, não é mais necessário que o Cumad monitore o dispositivo IoT, até que as ações adequadas sejam tomadas para limpar ou remover o dispositivo.

Quando o valor de λn é igual ou menor que o limite inferior a, a SPRT chega à conclusão de que H0 é verdadeiro, ou seja, o dispositivo IoT não está comprometido. Do ponto de vista da detecção de dispositivos IoT comprometidos, essa conclusão é menos interessante, pois não podemos encerrar o monitoramento do dispositivo como fizemos quando um dispositivo IoT comprometido é detectado. Um dispositivo IoT normal pode ficar comprometido posteriormente. Portanto, neste caso, redefiniremos o estado do SPRT para reiniciar o monitoramento do dispositivo IoT; em particular, redefiniremos o valor de λn para zero. Se uma decisão não puder ser alcançada neste momento (linha 28), o SPRT simplesmente aguardará pontos de dados de entrada adicionais e repetirão o mesmo procedimento.