Nos artigos anteriores, nos familiarizamos um pouco com a pilha ELK e configuração do arquivo de configuração do Logstash para o analisador de logs. Neste artigo, abordaremos o que é mais importante do ponto de vista analítico, ou seja, o que você deseja ver do sistema e pelo que tudo foi criado — gráficos e tabelas combinados em painéis de controle. Hoje, iremos explorar mais detalhadamente o sistema de visualização Kibana, iremos aprender a criar gráficos, tabelas e, ao final, construiremos um painel de controle simples com base nos logs do firewall Check Point.
O primeiro passo ao trabalhar com o Kibana é a criação de um padrão de índice, que, logicamente, é uma base de índices unificados por um determinado princípio. Naturalmente, essa configuração é exclusivamente para que o Kibana busque informações de forma mais conveniente em todos os índices simultaneamente. Ela é definida pela correspondência da string, por exemplo, "checkpoint-*" e o nome do índice. Por exemplo, "checkpoint-2019.12.05" se encaixa no padrão, mas apenas "checkpoint" não se encaixa. Vale mencionar que não é possível buscar informações em diferentes padrões de índices ao mesmo tempo. Um pouco mais adiante, em artigos subsequentes, veremos que as solicitações de API são feitas pelo nome do índice ou por um padrão de linha específico; a imagem é clicável:
Após isso, verificamos no menu Descobrir que todos os logs estão sendo indexados e que o analisador está configurado corretamente. Se houver quaisquer inconsistências, como por exemplo, mudar o tipo de dados de string para inteiro, será necessário editar o arquivo de configuração do Logstash; em resultado, novos logs serão registrados corretamente. Para que os logs antigos assumam a aparência necessária após a mudança, apenas o processo de reindexação pode ajudar. Em artigos subsequentes, essa operação será abordada em mais detalhes. Vamos garantir que tudo esteja em ordem; a imagem é clicável:
Os logs estão no lugar, então podemos começar a construir os painéis de controle. Com base na análise dos painéis de controle dos produtos de segurança, é possível entender o estado da segurança da informação na organização, visualizar claramente os pontos vulneráveis na política atual e, assim, desenvolver formas de remediá-los. Vamos construir um pequeno painel, utilizando vários recursos de visualização. O painel será composto por 5 componentes:
- uma tabela para contar o número total de logs por blade
- uma tabela de assinaturas críticas do IPS
- um gráfico de pizza para eventos de Prevenção de Ameaças
- diagrama dos sites mais populares visitados
- diagrama de uso dos aplicativos mais perigosos
Para criar figuras de visualização, você precisa acessar o menu Visualizar, e escolher a figura desejada que queremos construir! Vamos por partes.
Tabela para contar o número total de logs por blades
Para isso, vamos escolher a figura Tabela de Dados, acessamos a ferramenta para criação de gráficos, à esquerda estão as configurações da figura, à direita como ela aparecerá nas configurações atuais. Primeiro, vou demonstrar como ficará a tabela pronta, depois passaremos pelas configurações, a imagem é clicável:
Configurações mais detalhadas da figura, a imagem é clicável:
Vamos analisar as configurações.
Inicialmente, configura-se métrica, este é o valor pelo qual todos os campos serão agregados. As métricas são calculadas com base nos valores extraídos de documentos de diversas maneiras. Os valores geralmente são extraídos de campos do documento, mas também podem ser gerados utilizando scripts. Neste caso, colocamos em Agregação: Contagem número total de logs).
Depois disso, dividimos a tabela em segmentos (campos) pelos quais a métrica será calculada. Essa função é executada pela configuração de Buckets, que por sua vez consiste em 2 opções de configuração:
- dividir linhas - adição de colunas e posteriormente divisão da tabela em linhas
- dividir tabela - divisão em várias tabelas por valores de um campo específico.
Em buckets podemos adicionar várias divisões para criar várias colunas ou tabelas, as limitações aqui são mais lógicas. Na agregação, você pode escolher o método de divisão em segmentos: intervalo ipv4, intervalo de datas, Termos etc. A escolha mais interessante é Termos e Termos Significativos, a divisão em segmentos é feita por valores de um campo específico do índice, a diferença entre eles está na quantidade de valores retornados e sua exibição. Como queremos dividir a tabela pelo nome dos blades, escolhemos o campo - product.keyword e definimos o tamanho em 25 valores retornados.
Em vez de linhas, o elasticsearch utiliza 2 tipos de dados — ntext e palavra-chave. Se você deseja realizar uma busca full-text, deve usar o tipo text, uma ferramenta muito útil ao desenvolver seu próprio serviço de busca, por exemplo, para encontrar menções de uma palavra em um campo específico (texto). Se você deseja apenas uma correspondência exata, deve usar o tipo keyword. O tipo de dado keyword também deve ser usado para campos que exigem classificação ou agregação, ou seja, no nosso caso.
Como resultado, o Elasticsearch conta o número de logs em um determinado período, agregando pelo valor no campo produto. No Custom Label, definimos o nome da coluna que será exibido na tabela, estabelecemos o tempo para o qual coletamos os logs, iniciamos a renderização — o Kibana envia uma solicitação ao Elasticsearch, aguarda a resposta e, em seguida, visualiza os dados recebidos. A tabela está pronta!
Gráfico de pizza por eventos de Threat Prevention
Informação de interesse é quantas reações existem, em percentagem detect e prevent a incidentes de segurança da informação na atual política de segurança. Para tal caso, um gráfico de pizza é ideal. Selecionamos em Visualize — Pie chart. Além disso, na métrica definimos a agregação pelo número de logs. Em buckets, colocamos Terms => action.
Parece que está tudo correto, mas, no resultado, os valores exibidos são para todos os blades, precisamos filtrar apenas para aqueles que operam dentro do Threat Prevention. Portanto, é imprescindível configurar filtro para que a informação seja buscada apenas nos blades responsáveis por incidentes de segurança da informação — product: ("Anti-Bot" OR "New Anti-Virus" OR "DDoS Protector" OR "SmartDefense" OR "Threat Emulation"). A imagem é clicável:
E configurações mais detalhadas, a imagem é clicável:
Tabela por eventos IPS
Além disso, uma parte muito importante do ponto de vista da segurança da informação é a visualização e verificação de eventos pelos blades IPS e Emulação de Ameaças, que não bloqueados pela política atual, para que posteriormente possamos ou mover a assinatura para prevent, ou se o tráfego for válido — não verificar a assinatura. Criamos a tabela da mesma forma que para o primeiro exemplo, mas com a diferença de que criamos várias colunas: protections.keyword, severity.keyword, product.keyword, originsicname.keyword. É imprescindível configurar o filtro para que a informação seja buscada apenas nos blades responsáveis por incidentes de segurança da informação — product: ("SmartDefense" OR "Threat Emulation"). A imagem é clicável:
Configurações mais detalhadas, a imagem é clicável:
Gráficos dos sites mais visitados
Para isso, criamos uma figura — Vertical Bar. Também utilizamos a métrica count (eixo Y), e no eixo X, como valores, usaremos o nome dos sites visitados — “appi_name”. Aqui há uma pequena dica: se iniciarmos as configurações na versão atual, todos os sites serão marcados no gráfico com uma única cor. Para torná-los multicoloridos, utilizamos uma configuração adicional — “split series”, que permite dividir a coluna já criada em vários valores, dependendo do campo selecionado, claro! Essa divisão pode ser usada como uma única coluna colorida por valores no modo empilhado ou no modo normal para criar várias colunas com base em um valor do eixo X. Neste caso, usamos o mesmo valor que no eixo X, permitindo que todas as colunas sejam multicoloridas, sendo designadas por cores na parte superior direita. No filtro, definimos — product:«URL Filtering» para ver informações apenas sobre os sites visitados; a imagem é clicável:
Configurações:
Gráfico sobre o uso dos aplicativos mais perigosos
Para isso, criamos uma figura — Vertical Bar. Também utilizamos a métrica count (eixo Y) e, no eixo X, como valores, usaremos os nomes dos aplicativos utilizados - “appi_name”. O mais importante é definir o filtro — product: «Application Control» AND app_risk: (4 OR 5 OR 3) AND action:«accept». Filtramos os logs pela blade Application control, pegando apenas os sites que são categorizados como sites de risco Crítico, Alto, Médio e apenas se o acesso a esses sites for permitido. A imagem é clicável:
Configurações, clicável:
Dashboard
A visualização e criação de dashboards está em um item de menu separado — Painel. Aqui é simples, cria-se um novo dashboard, adiciona-se a visualização, organiza-se os elementos e é isso!
Criamos um dashboard que permitirá entender a situação básica da segurança da informação na organização, claro, apenas no nível do Check Point, a imagem é clicável:
Com base nesses gráficos, podemos entender quais assinaturas críticas não estão sendo bloqueadas no firewall, para onde os usuários estão indo e quais aplicativos mais perigosos eles estão utilizando.
Conclusão
Analisamos as possibilidades de visualização básica no Kibana e criamos um painel, mas isso é apenas uma pequena parte. No decorrer do curso, iremos abordar separadamente a configuração de mapas, o trabalho com o sistema Elasticsearch, conheceremos as solicitações de API, automação e muito mais!
Então fiquem de olho nas atualizações (, , , ), .
Fonte: habr.com
