Prevenção de vazamento de dados e problemas de HTTPS

Question

Eu tenho visto vários conjuntos de prevenção de vazamento / perda de dados, mas, em sua documentação, não consigo encontrar como eles tratam o HTTPS.

Um dos "vetores de vazamento" é o envio de informações para webapps por meio de HTTPS. Nesse caso, a única maneira de detectar o vazamento seria descriptografá-lo.

Mas, para fazer isso, ele teria que representar o servidor remoto, usando certificados falsos, como um homem no meio do ataque. Para evitar que os usuários suspeitem ou queixem-se, acho que a coroporação precisa inserir seu certificado como uma CA válida nos navegadores dos dispositivos da empresa.

Minhas perguntas são:

• Alguém tem experiência em primeira mão sobre esse tipo de cenário? Você pode nos dizer como você implementou?
• Estou certo ou há outra maneira de gerenciar o HTTPS (por exemplo, detectar os dados em uso no nível da área de trabalho com um agente)?

Answer 1

Isso não é "como" um homem no ataque do meio, é um homem no ataque do meio.

Você o implementa usando um servidor proxy que substituirá seu próprio certificado pelo certificado remoto. No processo, o navegador emitirá erros sobre o certificado não ser válido. Esse é o ponto por trás do HTTPS e da certificação. Então, se você tiver um usuário experiente, eles saberão que você está interceptando as informações.

Você pode usar proxies que apenas registram a atividade de uma pessoa para que você possa registrar o que está acontecendo e onde ela está navegando, mas, na verdade, se você está implementando medidas draconianas para evitar a possibilidade de alguém roubar sua informação, você provavelmente está fazendo um ambiente de trabalho que promove o tipo de atitude que justifica, para o funcionário, fazer isso em primeiro lugar. E você também precisará ter políticas de disparos de RH para telefones celulares (gravação com câmeras), drives USB e talvez se certificar de que eles não memorizem as coisas também.

De qualquer forma, não há uma maneira "simples" de quebrar o monitoramento HTTPS sem que ele seja descoberto, a menos que você simplesmente bloqueie o acesso de saída a essa porta com uma regra de firewall ou um filtro de proxy. Caso contrário, o ponto inteiro do HTTPS é inútil.

    

Answer 2

But, to do that, it would have to impersonate the remote server, using fake certificates

Sim - você não só precisaria de um certificado assinado por uma autoridade aceitável para o cliente, mas também precisaria envenenar o DNS do cliente ou redirecionar o fluxo de pacotes IP.

Eu suspeito que seja tecnicamente possível implementar um proxy HTTPS que gere um certificado em tempo real assinado por uma CA local e proxy as solicitações usando isso, mas muito difícil.

Se você estiver preocupado com o vazamento de dados por HTTPS, não permita que seus usuários acessem HTTPS.

Isso não resolve o problema de eles escreverem coisas em pedaços de papel.

A única solução prática é manter uma boa trilha de auditoria - de preferência com potes de mel.

    

Answer 3

O problema de https é resolvido pelo tipo de solução MiM. Geralmente, isso significa que um proxy está capturando sessões https de saída e as atende ao usuário assinado por seu próprio certificado SSL, enquanto conduz as comunicações https para o mundo externo por conta própria.

A solução myDLP gratuita pode fazer isso usando sua própria configuração de squid, e as soluções mais complexas, como Websense e symantec, iirc fazem a mesma coisa, se um pouco mais potentes (balanceamento de carga entre proxies, gerenciamento cert fine grained etc ...)