Soluções de DLP (Data Loss Prevention) detectam e interrompem o vazamento de dados considerados sensíveis a um contexto (por exemplo, uma empresa). Para desenharmos o serviço e suas políticas devemos nos atentar a:

• qual o tipo de aplicação seria o vetor (por exemplo, Dropbox, MS-Teams, e-mail etc).
• qual o típico perfil para casar um modelo de dados sensíveis (por exemplo, CPF, cartão de crédito, CEP etc).
• quais os atributos de arquivo (no caso de o dado estar armazenado na forma de um arquivo, em trânsito).
• qual a origem do vazamento (dispositivo ou rede).

Neste projeto, utilizamos o recurso de DLP de uma solução SASE (Secure Access Service Edge), que monitora o tráfego de uma filial, no modo inline, conforme topologia a seguir.

Para o 1º caso, foi testado o bloqueio de uma dado de cartão de crédito no seu formato visual, ou seja, uma foto de um cartão, com os dados impressos no mesmo, seguindo o formato convencional, com código de segurança, data de expiração e sequência numérica do cartão em questão (que não tem mais utilidade à data desta publicação. Importante mencionar isso…). 

A aplicação escolhida para o teste foi o Dropbox e, devido ao formato de imagem, o arquivo teve de ser configurado como um atributo, bem como o recurso de OCR (Optical Character Recognition) para a verificação. 

Uma etapa extremamente importante ao se criar regras de DLP é a validação com dados e arquivos de testes, para evitar falsos negativos e falsos positivos.

Após essa validação, a regra configurada foi a seguinte.

 

E o arquivo utilizado foi o exibido abaixo.

 

 

 

 

 

 

 

 

 

 

 

 

Quando tentamos fazer upload via Dropbox, o bloqueio ocorre diretamente na aplicação monitorada e um evento é gerado na console.

 

 

Mas, antes disso, um evento teve foi gerado pela solução para que a solução, para que ela pudesse decriptar o tráfego e analisar seu conteúdo, através de uma regra de TLS Inspection previamente configurada. Isso ocorre porque antes de se avaliar o ato de upload de determinado dado sensível, a própria aplicação teve que ser identificada.

 

 

Para o 2º caso, foi testado o vazamento de uma lista de CPFs através de texto  enviado via Pastebin. Como a regra padrão para esse tipo de informação sensível não inclui os diversos formatos possíveis, foi necessário criar, dentro do perfil “CPF ajustado”,  uma REGEX (Regular Expression) para a correta verificação: ^\d{3}\.\d{3}\.\d{3}\-\d{2}$

 

 

Os dados foram inseridos da seguinte maneira, para fins de teste:

 

 

 

O bloqueio foi devidamente aplicado pelo DLP:

 

 

E gerou o seguinte evento na console:

 

 

---