[GTER] LGPD

Tue Dec 22 13:53:58 -03 2020

Boa Tarde!

Usando o quepe de administrador de firewalls, e não de rede, achei a
discussão deveras interessante. Alguns pontos:

1) Dalton, Eu não tinha conhecimento de que a prática de inspeção SSL (em
que interceptamos, olhamos, e depois fechamos com outro certificado),
configura crime. Poderia, por gentileza, indicar a fonte da informação?
2) O lance de só controlar sites e acessos devidos/indevidos só baseado no
SNI conforme os colegas descreveram, infelizmente, não atende mais
(unicamente) quando pensamos em proteção. URL filtering ainda é uma das
metodologias mais usadas para bloqueios simples por categorias e/ou regex.
Para o chefe ficar feliz que o juquinha não vai mais acessar o pornhub
durante o horário de expediente, funciona, mas quando vamos mais à frente,
as coisas se complicam bastante.
Exemplo: como permitir que seu usuário não use o Gmail, mas possa usar
outra solução do Google, sendo que ambos possuem a mesma URL? Vários
produtos do Google funcionam com google.com/PRODUTO. Nem sempre só a URL é
suficiente. Hoje queremos saber aplicações.
3) Falando sobre a inspeção SSL, ela é hoje parte fundamental para
conseguirmos classificar aplicações. Sem ela não consigo classificar
produtos do Google, como no item 2, ou pegar um cara usando UltraSurf
dentro da minha rede. Nós seguimos algumas diretrizes quanto à privacidade,
como não inspecionar conteúdos de saúde e financeiros, por exemplo. Isso
sem contar a ajuda da inspeção quanto à visibilidade de vulnerabilidades
pela sua engine de IPS.
4) Douglas, pode explicar mais sobre essa sua questão a respeito da
efetividade do uso do proxy explícito? Você diz, se entendi, que a
efetividade de um proxy transparente, neste caso, é pior que um proxy
explícito? Eu questiono (o uso, pelo menos) porque, particularmente, acho o
proxy explícito pior de gerenciar, quando pensamos em configurações de
browsers, GPOs e etc.

Vou levar essa discussão internamente.

Att,

Em qui., 17 de dez. de 2020 às 19:06, Douglas Fischer <
fischerdouglas at gmail.com> escreveu:

> Ratifico sua opinião Danton!
>
> Durante um tempo fiz alguns deploys de soluções de Data Loss Prevention.
> Isso ainda no tempo que HTTPS era menos de 10% da navegação.
>
> Do ponto de vista técnico:
>  - Durante um tempo a solução dourada era a interceptação SSL.
>    Que o TLS1.3 e também o QUIC acabaram de matar nos últimos 2 anos.
>  - Depois veio a análise de DNS queries.
>    Que também está morrendo com o DoT e DoH.
>  - Agora a moda é a tal I.A. de classificação de destino.
>    Que também já está morrendo.
>
> Interessantemente, já naquele tempo(acho que uns 15 anos atrás) as
> documentações daquele vendor diziam que a única forma efetiva de assegurar
> DLP é com proxy explícito.
> Eu relutei em aceitar isso durante um tempo... E hoje já aceitei!
> De fato, do ponto de vista técnico, a única forma de uma empresa assegurar
> DLP é com proxy explícito, e bloqueio geral de todo o resto.
>
> Porém, não é só o aspecto técnico que tem que ser considerado!
> (P.S.:  Não confundir esse cenário, de relação de trabalho, com a relação
> de consumo.)
> A parte de prevenção legal é BEM IMPORTANTE E PESADA.
> Um dos custos altos do processo de implantação da solução de DLP era uma
> consultoria jurídica, mormente voltada a vertical trabalhista.
> Termos de uso dos equipamentos e rede da empresa era bem profunda.
>
>
> Naquela época eu inclusive acompanhei uma situação delicada...
> Onde em uma empresa que contratou a solução de DLP, este mecanismo
> identificou conteúdo ilegal no e-mail pessoal(webmail) de um funcionário.
> Foi um problema SÉRISSIMO!
> Pois, no entendimento da consultoria jurídica, depois de o mecanismo ter
> identificado e notificado a empresa, esta passou a ser obrigada a notificar
> as autoridades competentes, sob-pena de a falta de notificação poder ser
> encarada com cumplicidade.
>
>
>
>
>
> Em qui., 17 de dez. de 2020 às 16:04, Danton Nunes <
> danton.nunes at inexo.com.br> escreveu:
>
> > On 17/12/2020 13:11, Edvan Lima wrote:
> > > Estava lendo o artigo
> > >
> >
> https://ftp.registro.br/pub/gter/gter49/03-LGPD-IncidentesDeSeguranca.pdf
> > >
> > > Com LGPD, parei de usar proxy na rede, pelo que li,  analisar o tráfego
> > > criptografado está quebrando a privacidade dos usuários, isso pode dar
> > > problema pra gente.
> > >
> > > Porém seria uma mão de duas vias, afinal precisamos garantir  tudo que
> um
> > > usuário fizer na nossa rede, somos responsáveis e se algo acontecer,
> > temos
> > > como saber e mostrar quem foi ... não podemos por exemplo, permitir que
> > um
> > > site pornográfico seja visualizado.
> >
> > isso é política da empresa, não lei. uma política bem naïve, se me
> > permite,
> > porque o protocolo IP não tem um "porn bit" que permite de maneira
> > inequívoca
> > distinguir o que é pornografia do que não é. (se não me engano já foi
> > assunto de
> > uma das RFCs de primeiro de abril).
> >
> > se a sua filtragem se limitar às URLs e não invadir o conteúdo, tudo bem,
> > continue usando o proxy para bloquear o que der na telha dos teus chefes,
> > mas se
> > for fuçar o conteúdo de tráfego https, provavelmente estará violando não
> > só a
> > LGPD mas a lei penal, pois falsificar certificados e atuar como
> > man-in-the-middle é crime.
> >
> > hoje praticamente todo navegador envia cabeçalhos SNI (nada a ver com o
> > extinto
> > Serviço Nacional de Informações, trata-se de Server Name Indication,
> > RFC-4366)
> > que transporta pelo menos o nome do servidor remoto em texto claro. Essa
> > extensão permite criar sites virtuais em https baseados em nome e não
> > somente em
> > endereços IP, como nos velhos tempos e, obviamente, permite ao proxy
> negar
> > conexão a sites que se encontrem em uma lista negra.
> >
> > > *Se não posso usar proxy (squid) na rede, qual seria outra solução que
> > está
> > > dentro da LGPD?*
> >
> > minha opinião (de engenheiro, não de advogado): você pode usar proxies,
> > desde
> > que não falsifique certificados para analisar o conteúdo de transações
> que
> > deveriam ter criptografia fim-a-fim. como teu artefato não sabe
> distinguir
> > uma
> > página de pornografia de uma transação bancária, veja o lamaçal em que
> > você pode
> > estar se metendo cacheando os dados bancários de alguém.
> >
> > não sei que influência você tem na elaboração da política de uso da
> > empresa, mas
> > se puder, recomende não imporem regras cuja implementação possa violar a
> > lei. Se
> > a corda quebrar, adivinha para que lado quebra.
> >
> > -- Danton
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>