Como seu site precisa receber dados de login (sejam clientes, parceiros ou fornecedores) nas chamadas POST ou JSON com nome de usuário e senha, você poderá ter um vazamento caso o log caia em mãos de um agente malicioso que pode ser um funcionário ou externo.

Um exemplo que tive a alguns anos atras foi em um sistema de consulta de crédito integrado a parceiros de cadastro como SERASA e Associações Comerciais. O log de erros do sistema guardava em formato plain text no banco de dados os chamados com erros para que os desenvolvedores e o SAC pudessem encontrar erros no retorno de consultas.

Porém, nesse log muitas vezes o problema era erro na senha e nome de usuário enviados e com isso bastaria usar a lógica para deduzir que o usuário escreveu uma letra ou digito a mais ou diferente para conseguir saber sua senha.

E pior ainda, no log completo do serviço de autenticação era possível ver no GET os dados enviados para o cliente. Ou seja, se um parceiro consultar o meu CPF ou de alguém que me interesse, eu poderia procurar no log o retorno que foi enviado a performance nos serviços de crédito desta pessoa sem que isso fosse logado em qualquer lugar já que acessei diretamente o log.

Agora no Azure podemos deixar isso no passado, uma vez que não precisamos mais guardar logs programáticos já que ele armazena tudo no Log Analytics. Mas ainda temos um log onde qualquer operador de segurança pode usar um KQL e ver os dados, até mesmo utilizar um usuário valido para consultar dados no sistema.

Na época que notamos este problema a solução teve que ser manual, remover programaticamente nas funções a gravação de log para usuário e senha, além de mascarar CPF e CNPJ. Mas obviamente este não era uma solução definitiva, já que o log do WAF e do IIS ainda guardariam os dados brutos.

Agora no Azure WAF é possível criar regras de mascaramento para o log, ou seja, poderei identificar os dados no JSON e no POST que preciso proteger e proibir que sejam usados em consultas KQL.

Nas propriedades da política do WAF use o menu "Sensitive Data" para acessar o log scrubbing como a minha configuração abaixo:

Em meu exemplo utilizei os parâmetros e variáveis que são utilizadas pelos meus desenvolvedores para identificar usuário, senha, número de contrato e ID do cliente. Aqui poderia acrescentar CPF, CNPJ ou outros documentos que sejam argumentos recebidos e enviados.

Abaixo temos a lista de tipos de variáveis que podem ser mascaradas atualmente:

Com exceção do IP Address todos os outros tipos permitem a opção "Equal" e "Equal any" onde a primeira permite indicar uma informação nomeada e a segunda mascara qualquer que seja o conteudo no item selecionado. No caso do "Equal any" é importante lembrar que ele irá criptografar todas as variaveis daquele formato, o que pode ser ruim para debug futuro.

A Microsoft já liberou a documentação do recurso no Learn, para isso utilize o anuncio Azure WAF – Masking Sensitive Data - Microsoft Community Hub

O Virus Total tem uma modalidade de assinatura onde é gratuita e possui limites para consultas, a fim de evitar o uso por bots ou sistemas de terceiros.

Veja abaixo os detalhes e note que temos aqui nossa API Key mesmo sendo uma conta gratuita:

 

 

Já que temos a possibilidade de integrar os dados do Virus Total com os alertas e incidentes do Sentinel, a primeira ação é instalarmos a Solution:

 

 

Ao instalar a solução verá na tela de informações a esquerda que inclui 9 playbooks que irão colher os dados do incidente, alerta, domínio ou arquivo para buscar e correlacionar os dados do Sentinel com o Virus Total.

O passo seguinte é clicar em Automation --> Playbook templates e instalar os playbooks, para isso poderá filtrar pela palavra "virus total" e usar o botão Create Template para abrir a janela de instalação do playbook em seu ambiente:

 

 

Nesta tela verá que não é necessário ainda conectar seu API Key nem o Log Analytics, isso será feito após o deploy quando ele abrir a tela de design do Logic Apps:

 

 

 

Note que ao abrir as tarefas e sequencia do Logic Apps verá que a conexão do Virus Total e do LogAnalytics estarão com o simbolo de aviso e o botão salvar não irá funcionar até que arrume as conexões.

Para isso a primeira vez será necessáiro clicar em API Connections e informar os dados tanto do Virus Total quanto do Log Analaytics que será utilizado. Abaixo o exemplo de conexão com a Virus Total:

 

 

 

Nos próximos conectores você não precisará mais configurar as conexões, pois ele irá permitir utilizar a conexão já configurada nos playbooks anteriores, como a imagem abaixo:

 

 

 

Lembre-se que precisará conectar tanto a API do Virus Total quanto do Log Analytics (workspace ID e Key).

Uma vez configurado, agora você depois de abrir todas as tarefas e indicar as conexões poderá salvar o Logic Apps e verá que ele irá aparecer na tab Active playbooks:

 

 

Agora que já importamos a solução e criamos os playbooks que desejamos usar, o passo seguinte é criar a regra para executá-lo, chamada de Automation Rule.

Para isso clique no botão Create --> Automation Rule e indique o nome da regra e o disparador (trigger) que pode ser um incidente novo, alterado ou um novo alerta.

Ao escolher o tipo de disparador utilize como ação Run Playbook para escolher um dos que criamos no passo anterior:

 

 

 

 

Ao criar a regra há varias formas de filtros que você poderá utilizar, por exemplo para detectar que há um arquivo que será analisado já que um dos playbooks é especifico para hash. Tambem poderá filtrar apenas para certos tipos de incidentes ou alertas.

 

Integrar diferentes serviços para ter IoCs de diversas fontes irá ajudar muito em suas análises de incidentes.

Tambem estão sendo testados nesse momento em private preview widgets para trazer dados do Anomali, Record Future e do Virus Total quando você estiver investigando uma entidade (Entity) mas esse é outro post futuro 

 

Sabemos que o Microsoft Sentinel é uma ferramenta para capturar, analisar e gerar insights de segurança para operações e SOC.

Uma vez que temos milhares de sinais e eventos dentro do Sentinel, podemos analisar diversas situações com seu uso.

Vamos abordar aqui um Workbook que está na galeria da comunidade que tem o nome Sentinel Recon que tem como função permitir a pesquisa de forma inteligente aos dados coletados.

O primeiro passo é procurar e salvar no seu ambiente o template. Procure com o nome "Recon" em Templates como abaixo:

Uma vez aberto, use-o na aba "My workbooks". Configure a assinatura de Azure onde está o seu Log Analytics que suporta o Sentinel, e inclua o periodo de pesquisa desejado. 

Obviamente, quanto maior o periodo mais lento ele ficará para retornar os dados e dependendo do tamanho do ambiente poderá ocorrer erro de timeout.

No exemplo abaixo usei o Recon para validar os agentes que tenho instalado, tanto nativos como Arc, onde ele me dá uma visão da ingestão de dados e permitindo nas tabelas de detalhes filtrar o que desejo analisar:

Outra pesquisa que me retornou dados interessantes é utilizando os recursos "Azure Activity" e "Security Events" onde assim como exemplo anterior passo a ter uma visão do fluxo de eventos ingeridos pelo Sentinel e utilizei alguns filtros para saber a origem especifica de determinados eventos e atividades:

Use este workbook junto com o Sentinel para vasculhar e descobrir detalhes do que está sendo analisado e ingerido de forma fácil e inteligente.