Agora, a criptografia é um cavalo de Tróia: Ignore-a e corra os riscos

Resumo executivo

O jogo de superação entre os hackers e profissionais de segurança de dados continua. Assim que as organizações começam a achar que estão seguras com os mais recentes padrões de criptografia, os cibercriminosos encontram maneiras de violar essa segurança. Os black hats estão se infiltrando nas redes das empresas, obrigando a criptografia a proteger o malware e ransomware de suas aplicações, para que não sejam detectados. Não é de se admirar que 87% dos diretores de informações achem que a criptografia Secure Sockets Layer (SSL) traz maior risco para as suas organizações do que as ameaças cibernéticas.¹

A solução de tolerância zero para esses cavalos de Tróia é usar a inspeção de SSL para desmascarar os códigos maliciosos. No entanto, a maioria das tecnologias de inspeção disponíveis hoje em dia coloca uma carga insustentável no desempenho da rede. Os profissionais de segurança precisam de uma forma menos comprometedora para resolver a relação entre a segurança dos dados e o desempenho das aplicações, para poder permitir a transformação digital em toda a empresa.

 

A criptografia está em toda parte, para o bem e para o mal

Com base em algumas estimativas, até 65% do tráfego de dados no mundo atualmente está criptografado.² E embora muitos ainda empreguem os termos criptografia e SSL de forma sinônima, o protocolo subsequente do SSL, o Transport Layer Security (TLS), Até 2030, organizações no mundo todo terão implementado 125 bilhões de dispositivos de IoT. Esta maior exposição cria mais riscos de segurança. está gradualmente ganhando força; a Internet Engineering Task Force (IETF) aprovou recentemente a versão 1.3 do TLS. Em seus últimos relatórios de transparência, a Google refere-se apenas ao TLS quando discute a criptografia em trânsito.³

É fácil identificar a marca da transformação digital no uso crescente da criptografia. Por ser um componente importante da segurança de dados, a criptografia incentivou as organizações a mudarem radicalmente a forma como trabalham, vendem, comunicam e regulam suas atividades.

Como tratar a mobilidade e as vulnerabilidades da IOT

Nos últimos anos, os desenvolvedores de sites usavam o Hypertext Transfer Protocol (HTTP) na maioria das páginas da web, reservando o Hypertext Transfer Protocol Secure (HTTPS) criptografado para páginas que recebiam ou apresentavam dados confidenciais, tais como números de cartão de crédito, nomes de usuários, senhas e outras informações privadas. Atualmente, o HTTPS é regra para todas as páginas da maioria dos sites.4 Além disso, de acordo com o NSS Labs, 75% de todo o tráfego da web será criptografado até 2019.5 Um dos principais fatores de estímulo da proliferação da criptografia é a mobilidade dos usuários da web. Com a maioria dos usuários acessando a Internet por dispositivos móveis, qualquer conteúdo da web não criptografado fica exposto em redes públicas. Além de revelar informações pessoais confidenciais, essas páginas não criptografadas expõem também todo o conteúdo do URL e da página, incluindo todas as páginas que o usuário visitou no site, todos os termos de pesquisa e todos os conteúdos exibidos.

Outra fonte de vulnerabilidade fora das dependências da empresa é a rede de dispositivos conectados conhecida como Internet das Coisas (IoT). O IHS prevê que, no mundo todo, a quantidade de dispositivos de IoT saltará 12% em média por ano, passando de quase 27 bilhões em 2017 para 125 bilhões em 2030.6 A adoção da criptografia foi mais lenta para esses dispositivos. Como eles são limitados no que diz respeito à largura de banda, memória e fontes de energia, é mais difícil implantar o pacote completo de ferramentas de criptografia nos próprios dispositivos. No entanto, a vulnerabilidade dos dispositivos de IoT (eles são normalmente implantados externamente ou em edifícios sem segurança), e seu papel cada vez mais central na infraestrutura essencial, destacam a necessidade de trazer soluções mais robustas para essa categoria.

Os assinantes e prestadores de serviços de SaaS não têm alternativa

O mercado global da nuvem está crescendo a uma taxa anual de 22% e espera-se que represente mais de 50% de todos os orçamentos de TI até 2019. Parte desse investimento provavelmente será empregado na atualização da segurança dos dados em trânsito entre as redes internas e os provedores de nuvem. E isso não é apenas um fardo para as empresas. Os provedores de software como serviço (SaaS) também têm interesse na criptografia, pois seus modelos de responsabilidade compartilhada exigem proteção para os dados que suas plataformas transmitem aos assinantes, bem como para os dados armazenados nas nuvens.

A criptografia é obrigatória para a conformidade

As organizações de vários segmentos do setor são obrigadas a usar criptografia em determinados tipos de dados confidenciais que estão em trânsito, a para manter a conformidade com regulamentos como o PCI DSS (Padrão de segurança de dados da indústria de cartões de pagamento) e a HIPAA (Lei de Responsabilidade e Portabilidade de Seguro de Saúde). Independentemente do método de comunicação (e-mail, sites, aplicações de SaaS, etc.), a criptografia constitui uma exigência quando os dados que são transmitidos se enquadram no âmbito destas regulamentações.

Os usuários de e-mail unem-se para a criptografia

Há alguns anos, a Google começou a marcar os e-mails não criptografados enviados para os usuários do Gmail. Como consequência, a quantidade de e-mails recebidos usando a criptografia SSL aumentou em 25%. O resultado foi que 89% dos e-mails de entrada e 90% dos e-mails de saída são criptografados na rede do Gmail. No entanto, o fenômeno da criptografia estende-se para além do Gmail. Na Europa, por exemplo, os provedores de e-mail com criptografia de ponta a ponta, Tutanota e ProtonMail, têm testemunhado um forte aumento nas taxas de adoção.10

O júri está de acordo. A criptografia é a nova regra. Tão generalizadamente normal que a complacência pode ser a próxima grande ameaça à segurança de TI. À medida que os profissionais de segurança ficam mais à vontade com as ofertas de proteção com a criptografia, há o risco real de não perceberem como essa proteção está sendo subvertida silenciosamente. A prova está nas profundezas dos pacotes, mas nem todos estão preparados para procurar.

 

Os perigos de evitar a inspeção dos pacotes

A verdade inevitável e desconfortável é que o que é bom para os protetores da segurança é bom também para os criminosos. Um relatório de um fornecedor de entrega de aplicações revelou que em agosto de 2016, aproximadamente 41% dos ataques cibernéticos usaram criptografia para não serem detectados. No início de 2017, esse número havia aumentado para mais de 50%. Outra empresa que lida com segurança em nuvem contou 600.000 de atividades maliciosas diárias usando SSL.

As soluções de segurança cibernética tradicionais, tais como os sistemas de detecção de intrusão (IDS) e os sistemas de prevenção de intrusão (IPS), são treinadas para confiar no tráfego criptografado. Como o tráfego criptografado fica “em último na fila” no que diz respeito à prioridade de inspeção, os criminosos começaram a usá-lo como cavalo de Tróia, uma entrada desprotegida, para entrar pela porta da frente da rede da empresa.

Os cibercriminosos encontraram várias maneiras de explorar as defesas da criptografia:

  •  Ocultação da infecção inicial. Os cibercriminosos criptografam o malware e o enviam por uma porta aprovada; os usuários clicam em links incorporados que os levam para sites que contêm a carga ou como arquivos anexados. Os hackers têm conseguido esconder o botnet Zeus, por exemplo, em sessões de SSL.
  •  Ocultação do comando e controle. Determinadas famílias de malware empregam a criptografia para ocultar comunicações de comando e controle. Um exemplo disso é o explorador Heartbleed, que aproveita as fraquezas do SSL para extrair informações dos servidores de hospedagem, incluindo chaves de criptografia privadas, que eles usam para acessar as comunicações criptografadas.
  • Ocultação da exfiltração de dados. Muitas famílias de malware também empregam a criptografia para ocultar informações da rede, tais como senhas e informações roubadas (por exemplo, contas bancárias e senhas).

Por causa das recompensas para os criminosos, os ataques via canais criptografados estão atingindo proporções epidêmicas. 90% dos diretores de informações indicam que sofreram um ataque à rede usando a criptografia SSL. Pode parecer questão de lógica confiar em certificados digitais de fornecedores de confiança como um meio de impedir a exploração da criptografia. No entanto, é fácil e barato obter certificados legítimos, e isso se aplica aos bons e aos maus agentes. Os certificados são agrupados com muitos navegadores da web e o custo de usá-los em um site varia entre de graça a algumas centenas de dólares por ano. Além disso, os cibercriminosos estão se tornando cada vez mais adeptos ao roubo de chaves de certificados que lhes permitem criptografar e-mails, sites e aplicações maliciosos, normalmente marcados para inclusão na lista de permissões. Em ambos os casos, IDS e IPS podem identificá-los como válidos, devido à identidade do certificado.

 

Por que os profissionais de segurança adiam as inspeções

Atualmente, os arquitetos de segurança enfrentam um dilema na tentativa de resolver o crescente problema da criptografia. Em teoria, as empresas podem implementar a inspeção de SSL nos pontos de entrada da rede. No entanto, muitas organizações titubeiam para dar esse passo. As razões variam, mas podem ser divididas, de maneira ampla, em dois casos: falta de ferramentas de inspeção e relutância em empregá-las, principalmente por preocupações relacionadas ao desempenho.

Quando a inspeção perde terreno para outras prioridades de TI

Conforme observado acima, os profissionais de segurança às vezes confiam na criptografia a ponto de minimizar as suas vulnerabilidades. Mesmo quando estão cientes do perigo, no entanto, outras necessidades têm precedência sobre o investimento em recursos de inspeção de SSL. A equipe de segurança já está sobrecarregada tentando acompanhar a evolução dos padrões de criptografia e gerenciando certificados digitais. Assim, a inspeção pode parecer uma tarefa excessiva.

Além disso, a transformação digital e a crescente pressão para reduzir os custos operacionais estão levando os líderes de TI a reduzir a presença de seus data centers. Consequentemente, eles estão examinando todos os novos investimentos em hardware de forma mais aprofundada. Novos hardware, que adquiridos como capacidade de inspeção de SSL, muitas vezes não são aprovados.

Quando a inspeção é desativada

Entre as empresas com recursos de inspeção, muitas optaram por não habilitá-los ou desativaram-nos após um período de uso. Então, o que as impede? Um dos principais fatores é o impacto no desempenho de suas redes. Estudos mostram que quando a inspeção de tráfego de SSL/TLS é ativada, o desempenho pode ser afetado em quase 75%. Em conjunto com o crescente investimento empresarial em Ethernet de alta velocidade e o aumento da demanda por largura de banda de WAN, faz muito sentido que muitos líderes de segurança de TI venham relutando em ativar a inspeção de pacotes. A inspeção teria um impacto prejudicial não somente na taxa de transferência do tráfego e no desempenho da inspeção, mas também na produtividade do usuário.

A descodificação e a inspeção podem aumentar também a complexidade da gestão da segurança de rede, acrescentando mais hardware e software para gerenciamento, além de novas políticas e fluxos de trabalho de segurança. As organizações precisam desenvolver e administrar as listas de autorização, criar e gerenciar regras e resolver falsos positivos. Mas isso é um problema, pois muitas soluções de segurança não gerenciam as listas de autorização de forma ativa e a gestão delas torna-se uma enorme sobrecarga.

Alguns sites permitem a Fixação de Chave Pública de HTTP para impedir os ataques “man-in-the-middle”. No entanto, há muito o que dar errado. As autoridades de certificação podem alterar suas práticas de emissão sem aviso prévio, e novos certificados podem não fazer uso do mesmo sequenciamento seguro que os antigos. Se o novo sequenciamento dos certificados não incluir mais as chaves fixadas, o site não ficará acessível até que a política de Fixação de Chave Pública de HTTP expire. Erros ou negligências podem fazer com que a empresa fique sem site  durante semanas ou meses. Com mais de 75% das empresas gerenciando de 10 a 19 chaves de certificados de SSL, esta é uma preocupação generalizada.

 

Qualidade da inspeção: uma preocupação urgente

Com o custo médio das invasões da segurança cibernética na casa dos 7,35 milhões de dólares, as empresas precisam estar atentas. A criptografia está em uma encruzilhada crítica para a proteção e as invasões. As organizações que não contam com uma estratégia de criptografia correm um risco muito maior de sofrerem com as ameaças cibernéticas. E não basta simplesmente criptografar e-mails, sites e aplicações. Como os agentes ruins estão explorando a criptografia para executar mais da metade dos seus ataques, número que continuará aumentando,21 as empresas devem ter estratégias de descriptografia e inspeção simultâneas.

O equilíbrio entre a inspeção de SSL e o desempenho das aplicações não precisa obrigatório. Para solucionar este problema, é necessário dedicar recursos tecnológicos e de desenvolvimento ao mecanismo que conduz a inspeção. Alguns fornecedores oferecem soluções de pontos que dependem de componentes prontos para uso. O preço inicial atrativo oculta o custo de ter esses dispositivos quando se analisa as demandas do mundo real para expansão do volume de tráfego, requisitos de advanced threat protection e restrições relacionadas à equipe segurança. As organizações que precisam disponibilizar dados seguros no ritmo dos negócios digitais devem dar prioridade mais alta à qualidade da inspeção de SSL.

Deixe um comentário

Your email address will not be published.

You may use these <abbr title="HyperText Markup Language">HTML</abbr> tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

Precisa de Ajuda?