Solução de problemas de DLP

Este playbook descreve as etapas para resolver problemas quando a Prevenção de Perda de Dados (DLP) não funciona como esperado na sua Conta.

Visão geral

Complicações com políticas de Prevenção de Perda de Dados (DLP) podem causar resultados inesperados, levando a riscos de segurança potenciais. Isso pode ser devido a uma configuração que não está alinhada com os requisitos, ou tipo de dados personalizado ou perfil definido de forma incorreta.dd

Avaliação Inicial Usando Eventos

Filtragem para eventos de Prevenção de Perda de Dados (DLP) usando Eventos pode ser alcançada definindo o predefinido "Segurança de Aplicativos":

Eventos associados a regras de controle de dados incluirão campos reveladores, como os Perfis de DLP que foram acionados, Tipos de Dados correspondentes, atributos de arquivos e mais.

Isso permitirá que você entenda o que está sendo atualmente acionado e pergunte a si mesmo 'Os resultados estão de acordo com o que eu esperava de acordo com minha configuração?'

Solução de Problemas da Questão

O processo de solução de problemas é projetado para ser sequencial, com cada etapa construída a partir da última. Se um requisito anterior não for atendido, as etapas subsequentes não serão acionadas.

Nota:

Nota: É um requisito para todas as etapas abaixo garantir que você tenha uma regra de FW (mesmo que temporariamente criada para fins de solução de problemas) com rastreamento de eventos ativado  que corresponderá ao tráfego esperado para ser inspecionado pelo DLP.

Outra configuração orientada para solução de problemas será uma regra de DLP de fallback capturando tanto upload/download para fins de monitoramento sem correspondência de conteúdo ou especificação de tipo de arquivo.

É também recomendado testar usando um arquivo não textual, como .docx ou .pdf, para garantir que problemas de detecção de tipo de arquivo relacionados a arquivos textuais sejam evitados (mais detalhes abaixo).

(1) Inspeção TLS Habilitada (para tráfego sobre TLS)

• Verificar no Evento do Firewall: Verifique o campo booleano Inspeção TLS no evento FW gerado e certifique-se de que está definido como 1. Se o valor estiver definido para 0, siga as diretrizes nos seguintes artigos para configurar e testar a inspeção TLS na sua conta:
  - Configurar Política de Inspeção TLS para a Conta
  - Testar Inspeção TLS na Cato Cloud 

• Os tipos de SO específicos (Android, Linux, SO desconhecido) não são inspecionados por TLS.

• Algumas aplicações nativas do cliente não são inspecionadas por TLS (devido a preocupações com fixação de certificados). Regras de bypass padrão de TLS podem ser identificadas no CMA.

• Certifique-se de que a política de firewall da Internet contém duas regras com alta prioridade (próximo ao topo da base de regras) para bloquear QUIC e GQUIC, pois a inspeção TLS não pode funcionar neste tipo de tráfego:
  

  Para verificar se uma determinada solicitação usa ou não o protocolo QUIC, gere um arquivo HAR e inspecione a coluna "Protocolo" na solicitação POST/GET relevante. Se uma solicitação estiver usando QUIC, ela será listada como "h3", "http/2+quic/46" ou similar:
  

(2) Verifique a aplicação de destino identificada por Cato

• Verifique no Evento de Firewall: Veja o campo de evento "Aplicação" e busque pelo aplicativo identificado.

• Caso sua aplicação não seja identificada corretamente, certifique-se de que o seguinte seja verdadeiro:

  • Você está acessando o destino da aplicação usando seu nome de host em vez de usar diretamente o endereço IP.

    • Este passo garante que CATO veja a consulta DNS associada, permitindo-nos derivar o nome do host do destino, o que é crucial para a detecção de Aplicativos.

  • Certifique-se de que o tráfego destinado ao servidor DNS que você está usando para resolver o Nome/s do Host da aplicação de destino seja visível para o CATO (por exemplo, alcançou a interface LAN do Socket)

• Você pode definir uma aplicação específica para políticas CASB/DLP ou selecionar "Qualquer Aplicação" (todo o tráfego de aplicação HTTP/S).

  • A lista completa do que CATO define como "Aplicações em Nuvem" e "Aplicações" pode ser encontrada em "Recursos -> Catálogo de Aplicativos" filtrados pelo tipo.
    

  • Você pode abrir um ticket RFE (Solicitação de Aprimoramento) com o Suporte do CATO caso tenha uma aplicação específica que gostaria de ter adicionada como Aplicação em Nuvem.

(3) Verificação do Requisito de Tamanho de Arquivo

• Verifique no Evento DLP (subtipo "Segurança de Aplicativos"): Procure o campo de evento Veredito de Ameaça e verifique se o valor está definido como Ignorar Por Tamanho - ver este valor indicará que o conteúdo não foi escaneado devido ao tamanho do arquivo não estar dentro do intervalo mínimo/máximo exigido.

• O tamanho máximo de arquivo para DLP inline é de 50MB (500MB para API de Proteção de Dados).

  • Geralmente, você pode identificar o comportamento do gzip nos bastidores seguindo os passos abaixo:

    • Abrir as ferramentas de desenvolvedor do navegador, aba "rede"

    • Enquanto baixa um arquivo, identifique a solicitação que representa o download (no Google suite, é mais provável que seja identificável ao filtrar o domínio:*.googleusercontent.com, quadro azul na imagem abaixo).

    • Procure pelo cabeçalho Content-Encoding na resposta (moldura vermelha na imagem abaixo). Se for gzip, você pode perceber que há compressão nos bastidores.
      

• Para Perfis de Prevenção contra Perda de Dados (DLP) OCR o Tamanho do Arquivo Suportado é entre 10KB e 50 MB.

4 Tipo de Arquivo Está Identificado + Suportado Para Prevenção de Perda de Dados (DLP)

• Verifique no Evento de Prevenção de Perda de Dados (DLP) (subtipo "Segurança de Aplicativos"): Procure o campo Tipo de Arquivo indicando qual tipo de arquivo foi detectado por CATO.

• Se o valor for Tipos de Arquivo Desconhecidos, isso significa que o CATO falhou ao identificar o arquivo + ele está sendo isento da verificação de conteúdo.

• Verifique se o tipo de arquivo é suportado para Prevenção de Perda de Dados (DLP): arquivos de áudio, vídeo e binários não são suportados.

• Precaução extra precisa ser tomada ao corresponder o arquivo JAR usando o tipo de conteúdo, porque um arquivo .JAR pode ser um arquivo Zip ou um arquivo de arquivo Java (JAR). Consulte A Regra de Controle de Dados Não Funciona no Arquivo JAR ao Corresponder por Código Fonte para mais detalhes.

• Para Perfis de Prevenção contra Perda de Dados (DLP) OCR os tipos de arquivo suportados incluem: PNG, JPEG, TIFF, BMP, PNM, WEBP, JPEG.

Limitações para Detecção de Arquivos Textuais

A detecção de arquivos textuais, como CSV & TXT, enfrenta desafios devido à ausência de indicadores específicos. Nossa detecção depende de três entradas principais:

• Magiclib: Um cabeçalho de arquivo único para seu tipo. Por exemplo, arquivos PDF começam com um cabeçalho distinto (%PDF-1.5, %µµµµ, etc.), servindo como um forte indicador de tipo de arquivo.

• Cabeçalhos HTTP: O cabeçalho "Content-Type" em uploads de arquivo pode indicar o tipo de arquivo, como application/vnd.ms-excel para arquivos Excel durante um upload.

• Extensão do Nome do Arquivo: Usado quando outros indicadores estão ausentes ou inconclusivos, assumindo que o nome do arquivo é extraído corretamente.

As limitações surgem com arquivos textuais porque:

• Eles carecem de um cabeçalho mágico único para distinguir tipos (CSV, TXT, script Python).

• Requisições HTTP para uploads (por exemplo, via curl) podem não ter metadados suficientes sobre o tipo do arquivo (por exemplo, cabeçalho "Content-Type").

• O nome do arquivo pode não estar presente na requisição HTTP.

  • Caso o nome do arquivo esteja ausente dos eventos, por favor Contatar Suporte

Esses fatores podem tornar desafiador diferenciar entre um corpo de texto simples em uma solicitação POST/PUT e um envio real de Arquivo textual, potencialmente causando com que a Prevenção de Perda de Dados (DLP) não detecte esses arquivos.

Para outras limitações conhecidas da Prevenção de Perda de Dados (DLP), consulte Criando a Política de Controle de Dados. 

5 Perfil de Prevenção de Perda de Dados (DLP) Corresponde ao Conteúdo Escaneado

• Esta etapa ajuda a determinar se o problema decorre do alinhamento do tipo de dado com o conteúdo do arquivo

•  Ferramenta Validadora de Prevenção de Perda de Dados (DLP): Validar os Tipos de Dados com um Arquivo de Teste é uma etapa essencial e útil no Processo de resolução de problemas. Ela fornece uma maneira prática de validar as Regras da Prevenção de Perda de Dados (DLP) contra Dados do mundo real, servindo como um método eficaz para identificar e corrigir problemas.

  • Um exemplo de validação bem-sucedida de um Tipo de Dado de palavra-chave em um arquivo .csv:
    

  • Validação de Expressões Regulares: Quando usa um Tipo de Dado personalizado com regex, a caixa de teste regex torna-se um recurso inestimável. Ela permite testar seus padrões regex e validar sua precisão. É sempre recomendável testar seus padrões aqui primeiro para evitar resultados indesejados no Sistema de Prevenção de Perda de Dados (DLP).
    

  • A opção "Exportar Texto Extraído" pode ser útil para examinar os dados textuais analisados do Arquivo conforme foi escaneado pelo motor de Prevenção de Perda de Dados (DLP):
    

  • Por exemplo, verificar se os IDs de etiquetas de sensibilidade anexados a um documento são detectados pode ser feito revisando o arquivo .txt gerado pela opção "Exportar Texto Extraído". Abaixo está o resultado textual da análise de um .docx contendo uma etiqueta MIP: mip-example.png