Neste post do blog, anunciamos nossa primeira integração de segurança e ML supervisionado, oferecendo aos usuários um pacote de solução de ML supervisionado para detectar a atividade do algoritmo de geração de domínio (DGA) nos seus dados de rede.

blog-banner-security-detection.png

blog-thumb-security-detection.png

Combining supervised and unsupervised machine learning for DGA detection

Combinação de machine learning supervisionado e não supervisionado para detecção de DGA

Para usar o machine learning no Elastic Stack, basta ter seus dados armazenados no Elasticsearch. Extraia insights valiosos dos seus dados com apenas alguns cliques e crie um pipeline de machine learning de ponta a ponta totalmente operacional.

blog-banner-ml-anomaly-laptop.png

blog-thumb-ml-anomaly-laptop.png

Train, evaluate, monitor, infer: End-to-end machine learning in Elastic

Treinar, avaliar, monitorar, inferir: machine learning de ponta a ponta na Elastic

Pessoas mal-intencionadas (e seu malware) usam algoritmos de geração de domínio (DGA) para evitar a detecção, mas com o machine learning da Elastic, você pode construir modelos facilmente para desvendar os truques. Saiba como na parte 2 desta série.

Na <a href="/pt/blog/machine-learning-in-cybersecurity-training-supervised-models-to-detect-dga-activity">Parte 1</a> desta série do blog, demos uma olhada em como poderíamos usar o <a href="/pt/what-is/elasticsearch-machine-learning">machine learning do Elastic Stack</a> para treinar um modelo de classificação supervisionado para detectar domínios maliciosos. Nesta segunda parte, veremos como podemos usar o modelo que treinamos para enriquecer os dados de rede com classificações no momento da ingestão. Isso será útil para quem quiser detectar uma possível atividade de DGA em seus dados de packetbeat.
<h2>Detecção de DGA com o Elastic Stack</h2>Um programa malicioso que infecta uma máquina geralmente precisa de uma maneira de se comunicar de volta com um servidor controlado pelo invasor — o chamado servidor de comando e controle (C&C ou C2). Para impedir as medidas defensivas que bloqueiam endereços IP ou URLs codificados, os invasores usam algoritmos de geração de domínio (DGAs). Quando o malware precisa entrar em contato com um servidor de C&C, ele usa o DGA para gerar centenas ou milhares de domínios candidatos e tenta resolver um endereço IP para cada um. O invasor então precisa registrar apenas um ou alguns dos domínios gerados pelo DGA para poder se comunicar com a máquina infectada. Os DGAs são semeados e aleatorizados de maneiras diferentes para que seja ainda mais difícil bloqueá-los e detectá-los.
Como a atividade de DGA geralmente envolve consultas de DNS, muitas vezes ela se manifestará nas solicitações de DNS feitas de uma máquina infectada. O Packetbeat pode coletar o tráfego de DNS e enviá-lo ao Elasticsearch para análise. Neste post do blog, veremos como você pode enriquecer as informações da consulta de DNS nos dados do Packetbeat com uma pontuação para indicar o quanto o domínio é malicioso.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt49f03548e4e6bc48/5f04ce44e224bf2d1883a92b/blog-dga-2-enriched-packetbeat.jpg" data-sys-asset-uid="blt49f03548e4e6bc48" alt="Dados do Packetbeat enriquecidos" style="display: block; margin: auto; width:650px;">
<figcaption>Figura 1. Exemplo de um documento do Packetbeat enriquecido</figcaption><h2>Processadores de inferência e o pipeline de ingestão</h2>Para enriquecer os dados do Packetbeat com previsões de um modelo treinado para distinguir os domínios benignos dos maliciosos, precisaremos configurar um pipeline de ingestão com processadores de inferência adequados. Os <a href="/guide/en/elasticsearch/reference/7.8/inference-processor.html">processadores de inferência</a> oferecem aos usuários uma maneira de usar um modelo treinado no Elastic Stack (ou um modelo treinado em uma de nossas bibliotecas externas compatíveis) para fazer previsões em novos documentos conforme são ingeridos no Elasticsearch. Para entender como todas essas peças móveis se encaixam e quais configurações são necessárias, vamos voltar brevemente à primeira parte deste post.
Na <a href="/pt/blog/machine-learning-in-cybersecurity-training-supervised-models-to-detect-dga-activity">Parte 1</a>, discutimos o processo de treinamento de um modelo de classificação para prever se um determinado domínio é malicioso ou não. Uma das etapas desse processo é executar a engenharia de recursos nos dados de treinamento — um conjunto de domínios maliciosos e benignos conhecidos que nosso modelo usará para aprender como atribuir pontuações a domínios novos e nunca vistos. Os domínios brutos devem ser manipulados para extrair recursos — unigramas, bigramas e trigramas — que sejam úteis para o modelo. O mesmo procedimento de engenharia de recursos também deve ser aplicado aos domínios nos nossos dados do Packetbeat cujo grau de risco queremos avaliar.
É por isso que, além de um processador de inferência, nosso pipeline de ingestão também incluirá <a href="/guide/en/elasticsearch/reference/7.8/script-processor.html">processadores de script Painless</a> para extrair unigramas, bigramas e trigramas de dados de DNS do packetbeat no momento da ingestão. Um diagrama com o pipeline completo é ilustrado na Figura 2.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt076305e0def6b448/5f04ce78e224bf2d1883a92f/blog-dga-2-painless.png" data-sys-asset-uid="blt076305e0def6b448" alt="Script Painless para enriquecimento de dados" style="display: block; margin: auto; width:650px;">
<figcaption>Figura 2. Um pipeline de ingestão com processadores de script Painless para extrair recursos de unigramas, bigramas e trigramas de um novo domínio que está entrando e um processador de inferência para prever se o domínio é malicioso ou não</figcaption>Dentro dos dados do Packetbeat, o campo no qual estamos interessados em operar é o domínio de DNS registrado. Embora existam alguns casos raros em que esse campo não conterá o domínio de interesse, ele será bom o suficiente para ilustrar o caso de uso para os fins deste post. A imagem na Figura 3 ilustra os campos de interesse em um documento de exemplo do Packetbeat.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt68491032263c0dfd/5f04cea0a6e8d0446e91d324/blog-dga-2-domain.png" data-sys-asset-uid="blt68491032263c0dfd" alt="Domínios registrados" style="display: block; margin: auto; width:550px;">
<figcaption>Figura 3. O campo de interesse do Packetbeat será <code>dns.question.registered_domain</code></figcaption>Para extrair unigramas, bigramas e trigramas de <code>dns.question.registered_domain</code>, precisaremos usar um script Painless como o da Figura 4.
<pre class="prettyprint">POST _scripts/ngram-extractor-packetbeat 
{ 
 "script": { 
 "lang": "painless", 
 "source": """ 
 String nGramAtPosition(String fulldomain, int fieldcount, int n){ 
 String domain = fulldomain.splitOnToken('.')[0]; 
 if (fieldcount+n&gt;=domain.length()){ 
 return '' 
 } 
 else 
 { 
 return domain.substring(fieldcount, fieldcount+n) 
 } 
 } 
 for (int i=0;i&lt;ctx['dns']['question']['registered_domain'].length();i++){ 
 ctx['field_'+Integer.toString(params.ngram_count)+'_gram_'+Integer.toString(i)] = nGramAtPosition(ctx['dns']['question']['registered_domain'], i, params.ngram_count) 
 }
 """ 
 } 
}
</pre><figcaption>Figura 4. Script Painless para expandir um domínio em unigramas, bigramas e trigramas</figcaption>Depois que os recursos necessários forem extraídos, o documento — ainda passando pelo pipeline de ingestão — passará pelo processador de inferência, onde o modelo de classificação que treinamos na parte anterior usará os recursos extraídos para fazer uma previsão. Finalmente, como não queremos sobrecarregar nosso índice com todos os recursos extras necessários ao modelo, adicionaremos uma série de processadores de script Painless para remover os campos que contenham os unigramas, bigramas e trigramas.
Assim, no final do pipeline de ingestão, o que ingeriremos será um documento do Packetbeat com os novos campos extras que contêm o resultado das predições de machine learning. Um exemplo de configuração de pipeline de ingestão é mostrado na Figura 5. Para obter todos os detalhes, consulte o <a href="https://github.com/elastic/examples/tree/master/Machine%20Learning/DGA%20Detection">repositório de exemplos</a>.
<pre class="prettyprint">PUT _ingest/pipeline/dga_ngram_expansion_inference
{
 "description": "Expande um domínio em unigramas, bigramas e trigramas para fazer uma previsão do grau de risco",
 "processors": [
 {
 "script": {
 "id": "ngram-extractor-packetbeat",
 "params":{
 "ngram_count":1
 }
 }
 },
 {
 "script": {
 "id": "ngram-extractor-packetbeat",
 "params":{
 "ngram_count":2
 }
 }
 },
 {
 "script": {
 "id": "ngram-extractor-packetbeat",
 "params": {
 "ngram_count":3
 }
 }
 },
 {
 "inference": {
 "model_id": "dga-ngram-job-1587729368929",
 "target_field": "predicted_label",
 "field_mappings":{},
 "inference_config": { "classification": {"num_top_classes": 2} }
 }
},
 {
 "script": {
 "id": "ngram-remover-packetbeat",
 "params":{
 "ngram_count":1
 }
 }
 },
 {
 "script": {
 "id": "ngram-remover-packetbeat",
 "params":{
 "ngram_count":2
 }
 }
 },
 {
 "script": {
 "id": "ngram-remover-packetbeat",
 "params": {
 "ngram_count":3
 }
 }
 }
 ]
}
</pre><figcaption>Figura 5. Exemplo de configuração de pipeline de ingestão</figcaption>Como nem todo documento do Packetbeat registrará uma solicitação de DNS, precisaremos fazer o pipeline de ingestão ser executado condicionalmente apenas se os campos de DNS obrigatórios estiverem presentes e não forem vazios no documento ingerido. Podemos fazer isso usando um <a href="/guide/en/elasticsearch/reference/current/conditionals-with-multiple-pipelines.html">processador de pipeline</a> (veja a configuração na Figura 6) para verificar se os campos desejados estão presentes e preenchidos e, em seguida, redirecionar o processamento do documento para o pipeline <code>dga_ngram_expansion_inference</code> que definimos na Figura 5. Embora a configuração abaixo seja adequada para um protótipo, para um caso de uso de produção, você precisará considerar a possibilidade de fazer um tratamento de erros no pipeline de ingestão. Para obter instruções e configurações completas, consulte o <a href="https://github.com/elastic/examples/tree/master/Machine%20Learning/DGA%20Detection">repositório de exemplos</a>.
<pre class="prettyprint">PUT _ingest/pipeline/dns_classification_pipeline
{
 "description": "Um pipeline de pipelines para realizar a detecção de DGA",
 "version": 1,
 "processors": [
 {
 "pipeline": {
 "if": "ctx.containsKey('dns') && ctx['dns'].containsKey('question') && ctx['dns']['question'].containsKey('registered_domain') && !ctx['dns']['question']['registered_domain'].empty",
 "name": "dga_ngram_expansion_inference"
 }
 }
 ]
}
</pre><figcaption>Figura 6. Um pipeline de pipelines condicional para realizar a detecção de DGA apenas nos documentos que registram solicitações de DNS</figcaption><h2>Uso de detecção de anomalia como analítica de segunda ordem nos resultados de inferência</h2>O modelo que treinamos na primeira parte da série teve uma taxa de falsos positivos de 2%. Embora isso pareça muito baixo, é preciso ter em mente que o tráfego de DNS geralmente tem um volume alto. Portanto, mesmo com uma taxa de falsos positivos de 2%, um grande número de consultas pode ser classificado como malicioso. Uma maneira de reduzir o número de falsos positivos seria trabalhar em outros esquemas de engenharia de recursos. Outra seria usar a detecção de anomalia nos resultados da nossa classificação. Vamos explorar como fazer essa segunda opção no Elastic Stack.
A primeira coisa a observar é que, se pegarmos os documentos do Packetbeat enriquecidos e traçarmos a contagem de documentos do Packetbeat rotulados como maliciosos em relação ao tempo, obteremos uma série temporal (Figura 7).
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt44ea9e47a1528323/5f04cf3a9ccd4234d7143ad3/blog-dga-2-time-series.jpg" data-sys-asset-uid="blt44ea9e47a1528323" alt="Atividade de DGA ao longo do tempo" style="display: block; margin: auto;">
<figcaption>Figura 7. Ao traçarmos a contagem de documentos do Packetbeat previstos como maliciosos em relação ao tempo, obtemos uma série temporal</figcaption>A segunda coisa a observar é que, muitas vezes (embora haja exceções), quando um malware de DGA está ativamente tentando se comunicar com o servidor de C&C, ele tende a gerar uma onda de solicitações de DNS de uma vez (ou seja, o malware percorre muitos dos domínios gerados pelo algoritmo, tentando resolver o endereço IP de cada um dos domínios). Na análise de série temporal dos domínios maliciosos previstos ao longo do tempo (Figura 6), podemos ver picos de atividade e pequenos ruídos entre os picos. Os picos indicam que nosso modelo classificou muitos domínios como maliciosos em um curto espaço de tempo e, portanto, provavelmente estamos lidando com um verdadeiro DGA. Em contraste, o ruído de fundo entre os picos é provavelmente o resultado de falsos positivos. É precisamente essa intuição que buscaremos codificar em um trabalho de detecção de anomalia <code>high_count</code> para essa série temporal.
Se sobrepusermos a raia de detecção de anomalia com a série temporal na Figura 7, veremos que obtemos alertas de anomalia correspondentes aos picos na série temporal (a verdadeira atividade de DGA) e nenhum alerta nos intervalos entre os picos (o ruído de fundo dos falsos positivos).
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blte3fdc5b9e672c19e/5f04cf5ae438c33db80644f6/blog-dga-2-anomalies.png" data-sys-asset-uid="blte3fdc5b9e672c19e" alt="Anomalias de DGA ao longo do tempo" style="display: block; margin: auto;">
<figcaption>Figura 8. A raia de detecção de anomalia sobreposta com a série temporal de contagem de domínios maliciosos ao longo do tempo mostra uma técnica promissora para reduzir os falsos positivos na detecção de DGA</figcaption>Embora esse seja um exemplo muito simples e, para um caso de uso de produção, provavelmente exigisse mais ajustes e configurações, ele mostra que é possível usar trabalhos de detecção de anomalia com eficácia como uma análise de segunda ordem nos resultados de inferência.
<h2>Conclusão
</h2>Neste post, usamos um modelo de classificação treinado para enriquecer os dados de rede (documentos do Packetbeat) no momento da ingestão. O processo de enriquecimento, que é facilitado pelo processador de inferência e pelos pipelines de ingestão, adiciona um rótulo previsto a cada domínio consultado durante uma solicitação de DNS. Isso mostra a probabilidade de o domínio ser malicioso. Além disso, para reduzir alertas de falsos positivos, também examinamos como usar um trabalho de detecção de anomalia nos resultados de inferência. Também estamos planejando fornecer uma seleção de configuração e modelos para detecção de DGA no <a href="/pt/siem">Elastic SIEM</a>.
Se quiser experimentar com seus próprios dados de rede, você poderá iniciar uma <a href="/pt/elasticsearch/service">avaliação gratuita do Elasticsearch Service</a> de 14 dias para começar a fazer a ingestão e a análise. Você também poderá <a href="/guide/en/machine-learning/current/ml-getting-started.html">experimentar o machine learning gratuitamente</a> por 30 dias <a href="/pt/downloads">baixando o Elastic Stack</a> localmente e iniciando uma licença de avaliação. Ou iniciar com o <a href="/pt/siem">Elastic SIEM</a> gratuito e aberto para começar a proteger seus dados hoje mesmo.

Machine learning in cybersecurity: Detecting DGA activity in network data

Machine learning na segurança cibernética: como detectar atividade de DGA em dados de rede

Pessoas mal-intencionadas (e seu malware) usam algoritmos de geração de domínio (DGA) para evitar a detecção, mas com o machine learning da Elastic, você pode construir modelos facilmente para desvendar o que está por trás dos truques.

Não é irritante receber uma ligação de telemarketing de um número de telefone aleatório? E não adianta bloqueá-lo, porque a próxima ligação será feita de um número totalmente novo. Os ciberataques empregam os mesmos truques sujos. Usando algoritmos de geração de domínio (DGA), os criadores de malware mudam a origem de sua infraestrutura de comando e controle, evitando a detecção e frustrando os analistas de segurança que tentam bloquear sua atividade.
Nesta série de duas partes, usaremos o <a href="/pt/what-is/elasticsearch-machine-learning">machine learning da Elastic</a> para construir e avaliar um modelo para detectar algoritmos de geração de domínio. Na parte 1:
<ul>
	<li>Apresentaremos o processo de extração de recursos dos domínios maliciosos e benignos brutos</li>
	<li>Explicaremos um pouco sobre o processo de encontrar recursos adequados</li>
	<li>Mostraremos como treinar e avaliar um modelo de machine learning usando o <a href="/pt/products">Elastic Stack</a></li>
</ul>Na parte 2, discutiremos como implantar o modelo treinado em um pipeline de ingestão para enriquecer os dados do <a href="/pt/beats/packetbeat">Packetbeat</a> no momento da ingestão. Arquivos de configuração e materiais de apoio estarão disponíveis no <a href="https://github.com/elastic/examples/tree/master/Machine%20Learning/DGA%20Detection">repositório de exemplos</a>.&nbsp;
Se quiser experimentar em casa, recomendo iniciar uma <a href="/pt/elasticsearch/service">avaliação gratuita do nosso Elasticsearch Service</a>, na qual você terá acesso completo a todos os nossos recursos de machine learning. OK, vamos lá.
<h2>DGA: o que acontece na prática</h2>Depois de infectarem uma máquina-alvo, muitos programas maliciosos tentam contatar um servidor remoto — o chamado servidor de comando e controle (C&C ou C2) — para extrair dados e receber instruções ou atualizações. Isso significa que o binário malicioso precisa saber o endereço IP do servidor de C&C ou o domínio. Se esse endereço IP ou domínio está codificado no binário, as medidas defensivas podem impedir essa comunicação com relativa facilidade adicionando o domínio a uma lista de bloqueio.&nbsp;
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt79b409f8d7fe0f42/5eeab3f76b547b2c37e3a7ee/blog-dga-1-malware.png" data-sys-asset-uid="blt79b409f8d7fe0f42" alt="" style="display: block; margin: auto;">
<figcaption>Figura 1. Um binário de malware percorre os domínios gerados pelo DGA para encontrar aquele registrado como o servidor de C&C.&nbsp;
</figcaption>Para subverter essa medida defensiva, os autores do malware podem adicionar um DGA a ele. Os DGAs geram centenas ou milhares de domínios de aparência aleatória. Então, o binário do malware na máquina infectada passa por cada um dos domínios gerados, tentando resolver os nomes de domínio para ver qual dos domínios foi registrado como o servidor de C&C. É difícil para uma abordagem defensiva baseada em regras impedir esse canal de comunicação devido ao grande volume e à aleatoriedade dos domínios. Também é difícil para um analista humano encontrá-lo, já que o tráfego de DNS geralmente tem um volume muito alto. Ambos os fatores fazem com que essa seja uma aplicação ideal para o machine learning.&nbsp;
<h2>Treinamento de um modelo de machine learning para classificar domínios</h2>No machine learning supervisionado, fornecemos um conjunto rotulado de dados de treinamento de domínios maliciosos e benignos, permitindo que um modelo aprenda com esse conjunto de dados para que possa então ser usado para classificar domínios anteriormente não vistos como maliciosos ou benignos.&nbsp;
Existem vários tipos diferentes de DGAs, e nem todos têm a mesma aparência. Alguns DGAs produzem domínios de aparência aleatória, outros usam listas de palavras. Para modelos em produção, diferentes recursos e modelos podem ser usados para capturar as características dos diferentes algoritmos. Neste exemplo, treinaremos um único modelo com base nas características encontradas nos algoritmos mais comuns.
Aqui, vamos usar um conjunto de dados composto por domínios de várias famílias de malware e domínios benignos para treinar nosso modelo.&nbsp;
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blta81a7ecea3bfbb26/5eeab4068d39260a3ded679b/blog-dga-1-datasets.png" data-sys-asset-uid="blta81a7ecea3bfbb26" alt="" style="display: block; margin: auto; width:650px;">
<figcaption>Figura 2. Domínios de exemplo gerados pelas famílias de malware <code>cryptolocker</code>, <code>banjori</code> e <code>suppobox</code>
</figcaption><h3>Engenharia de recursos</h3>A entrada necessária para criar um modelo de machine learning eficaz consiste nos recursos que podem capturar as características dos domínios gerados pelos DGAs. Portanto, temos de dizer ao modelo quais aspectos da string são importantes para distinguir entre domínios maliciosos e benignos. Isso é conhecido como engenharia de recursos no mundo do machine learning.
Compreender os recursos que melhor distinguem os domínios benignos dos maliciosos é um processo iterativo. Por exemplo, começamos com alguns recursos simples, como comprimento de nome de domínio e entropia de nome de domínio, mas os modelos resultantes não eram particularmente precisos em comparação com outros métodos, como o LSTM. Esses modelos tiram proveito das características sequenciais das strings, portanto, examinamos outros recursos que codificariam as sequências de maneira mais eficaz.
Depois de iterar por meio de várias abordagens de engenharia de recursos, concluímos que usar a presença de substrings de vários comprimentos capturaria melhor a diferença entre domínios maliciosos e benignos no modelo.&nbsp;
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltdeba08fd148fe3a6/5eeab41a7253820a4364d9eb/blog-dga-1-n-grams.png" data-sys-asset-uid="bltdeba08fd148fe3a6" alt="" style="display: block; margin: auto; width:650px;">
<figcaption>Figura 3. Divisão de um domínio de entrada iglxbvkw em unigramas, bigramas e trigramas&nbsp;
</figcaption>Essas substrings são comumente conhecidas como n-gramas. Ao desenvolver recursos, é importante equilibrar o número de recursos (a dimensionalidade do conjunto de dados de treinamento) e a complexidade de calcular os recursos com seu benefício para o modelo. Após iterar e testar n-gramas de vários comprimentos, concluímos que n-gramas com comprimento 4 ou mais não adicionavam informações preditivas significativas ao modelo, razão pela qual nosso conjunto de recursos é restrito a unigramas, bigramas e trigramas. O diagrama na Figura 3 ilustra como esses recursos são gerados a partir de um domínio de exemplo.
Para gerar um índice do Elasticsearch que tenha cada domínio de DGA dividido em unigramas, bigramas e trigramas, você pode reindexar o índice de origem por meio de um pipeline de ingestão com um processador de script Painless. Um exemplo é mostrado na Figura 4 abaixo.&nbsp; Para obter configurações completas, instruções e várias opções de customização, consulte o <a href="https://github.com/elastic/examples/tree/master/Machine%20Learning/DGA%20Detection">repositório de exemplos</a>.&nbsp;
<pre class="prettyprint">POST _scripts/ngram-extractor-reindex 
{ 
 "script": { 
 "lang": "painless", 
 "source": """ 
 String nGramAtPosition(String fulldomain, int fieldcount , int n){ 
 String domain = fulldomain.splitOnToken('.')[0]; 
 if (fieldcount+n&gt;=domain.length()){ 
 return '' 
 } 
 else 
 { 
 return domain.substring(fieldcount, fieldcount+n) 
 } 
 } 
 for (int i=0;i&lt;ctx['domain'].length();i++){ 
 ctx[Integer.toString(params.ngram_count)+'-gram_field'+Integer.toString(i)] = nGramAtPosition(ctx['domain'], i, params.ngram_count) 
 } 
 """ 
 } 
}
</pre><figcaption>Figura 4.&nbsp;Exemplo de script Painless para extrair n-gramas de domínios em dados de entrada
</figcaption>Normalmente, seria necessário fazer mais pré-processamento para converter as substrings de comprimentos 1, 2 e 3 em vetores numéricos para o algoritmo de machine learning. No nosso caso, o machine learning da Elastic cuidará dessa conversão em valores numéricos, também conhecida como codificação. O machine learning da Elastic também examinará os recursos e selecionará automaticamente aqueles que contiverem mais informações.
<h2>Criação de um trabalho de analítica de estruturas de dados</h2>A próxima etapa é usar a UI Data Frame Analytics (Analítica de estruturas de dados) para criar um trabalho de classificação. Eu destaquei alguns aspectos importantes desse processo nas capturas de tela abaixo.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt41bc9b5e914391bd/5eeab4326b547b2c37e3a7f2/blog-dga-1-create-job.jpg" data-sys-asset-uid="blt41bc9b5e914391bd" alt="" style="display: block; margin: auto; width:350px;">
<figcaption>Figura 5. O assistente de analítica de estruturas de dados orienta você na criação de um trabalho de classificação
</figcaption>Uma coisa importante a notar é que podemos especificar uma divisão de treinamento/teste usando o controle deslizante. Na captura de tela da Figura 5, a divisão de treinamento/teste é definida como 80%, o que significa que 80% dos documentos no índice de origem serão usados para treinar o modelo, e os 20% restantes serão usados para testar o modelo.
Assim que o processo de treinamento for concluído, poderemos navegar até a UI Data Frame Analytics Results (Resultados da analítica de estruturas de dados) para avaliar o desempenho do modelo. Como dividimos nosso índice de origem em um conjunto de treinamento e um conjunto de teste, poderemos ver o desempenho do modelo em cada um. Embora o desempenho do treinamento e o desempenho do teste forneçam informações valiosas, neste caso, estaremos mais interessados no desempenho do modelo no conjunto de dados de teste, pois isso nos dará uma ideia do erro de generalização em um modelo. Esse erro indica como será o desempenho do modelo em pontos de dados que não encontrou antes.&nbsp;
<h2>Avaliação de um modelo de machine learning</h2>Assim que o processo de treinamento for concluído, poderemos clicar em “View” para visualizar os resultados da página de gerenciamento de trabalhos da UI de machine learning da Elastic.&nbsp;
A página de resultados (veja a Figura 6) nos dá duas informações importantes: uma confusion matrix que resume o desempenho do nosso modelo e uma tabela de resultados onde podemos fazer uma busca detalhada para ver como os pontos de dados individuais foram classificados pelo modelo. Podemos alternar entre a confusion matrix e a tabela de resumo para os conjuntos de dados de teste e treinamento usando os filtros Testing (Teste) e Training (Treinamento) no canto superior direito da tabela.&nbsp;
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt2835b4e08a0b8637/5eeab44b688c1c62a49ae2f2/blog-dga-1-data-frame.jpg" data-sys-asset-uid="blt2835b4e08a0b8637" alt="" style="display: block; margin: auto;">
<figcaption>Figura 6. A página de resultados da analítica de estruturas de dados exibe uma confusion matrix e uma tabela com dados de amostra
</figcaption>Uma maneira comum de exibir o desempenho de um modelo é com uma visualização conhecida como confusion matrix. A confusion matrix exibe a porcentagem de pontos de dados que foram classificados como true positives (positivos verdadeiros, os domínios maliciosos que o modelo identificou como maliciosos e que realmente eram) e true negatives (negativos verdadeiros, os domínios benignos que o modelo identificou como benignos), bem como a porcentagem de documentos em que o modelo confundiu domínios benignos com maliciosos (false positives ou falsos positivos) ou vice-versa (false negatives ou falsos negativos).&nbsp;
Fiel ao seu nome, a confusion matrix nos mostrará rapidamente se um modelo está confundindo frequentemente instâncias de uma classe com outra.&nbsp;
Na Figura 6, vemos que nosso modelo tem uma taxa de 98% de positivos verdadeiros nos dados de teste. Isso significa que, se implantássemos esse modelo em produção para classificar os dados de DNS recebidos, esperaríamos ver aproximadamente uma taxa de 2% de falsos positivos. Embora pareça ser um número bastante baixo, o alto volume de tráfego de DNS significa que ele ainda levaria a uma taxa de alerta bastante alta. Na parte 2, daremos uma olhada em como a detecção de anomalia pode ser usada para reduzir o número de alertas de falsos positivos.&nbsp;
<h2>Conclusão</h2>Neste post do blog, apresentamos uma breve visão geral do uso do <a href="/pt/what-is/elasticsearch-machine-learning">machine learning da Elastic</a> para criar e avaliar um modelo de machine learning para detecção de DGA. Examinamos o processo de extração de recursos dos domínios maliciosos e benignos brutos e explicamos um pouco sobre o processo para encontrar recursos adequados. Por fim, vimos como treinar e avaliar um modelo de machine learning usando o Elastic Stack.
Na próxima parte da série, veremos como usar <a href="/guide/en/elasticsearch/reference/7.8/inference-processor.html">processadores de inferência</a> em pipelines de ingestão para implantar esse modelo a fim de enriquecer os dados de entrada do Packetbeat com previsões de grau de risco do domínio e como usar trabalhos de detecção de anomalia para reduzir o número de alertas de falsos positivos. Enquanto isso, <a href="/pt/elasticsearch/service">experimente nossos recursos de machine learning gratuitamente</a> para ver que tipo de insights você poderá revelar quando enxergar através do ruído em seus dados.

Articles by Camilla Montonen

Combinação de machine learning supervisionado e não supervisionado para detecção de DGA

Treinar, avaliar, monitorar, inferir: machine learning de ponta a ponta na Elastic

Machine learning na segurança cibernética: como detectar atividade de DGA em dados de rede

Machine learning na segurança cibernética: modelos supervisionados de treinamento para detectar atividade de DGA

Produtos

Empresa

Recursos

Soluções

Elastic (ELK) Stack

NOVO

Articles by Camilla Montonen

Combinação de machine learning supervisionado e não supervisionado para detecção de DGA

Treinar, avaliar, monitorar, inferir: machine learning de ponta a ponta na Elastic

Machine learning na segurança cibernética: como detectar atividade de DGA em dados de rede

Machine learning na segurança cibernética: modelos supervisionados de treinamento para detectar atividade de DGA