Cinco lições de segurança

Cinco lições de segurança: investigação sobre alguns dos maiores roubos de dados confidenciais

por Greg Shipley, Tyler Allison e Tom Wabiszczewicz | InformationWeek EUA*

10/09/2009

Quebramos a lei do silêncio sobre brechas de dados para mostrar como agem os agressores  e como você pode impedí-los.

No mundo corporativo, quanto menos se falar em brechas de segurança, melhor. Se temos uma revelação pública sobre dados roubados, saiba que outras dezenas de brechas nunca vêm à tona. Essa lei do silêncio ajuda a evitar parceiros e consumidores raivosos e evita problemas de relações públicas, mas torna mais difícil para a indústria como um todo aprender com esses erros e melhorar a segurança da informação e as práticas de gerenciamento de risco. É por isso que esse artigo traz observações diretas do mundo real das brechas de segurança nas quais realizamos investigações forenses, para ajudar as empresas a entender como essas brechas acontecem e o que se pode fazer sobre elas.
 

A Neohapsis, empresa onde trabalhamos, investigou alguns dos maiores roubos de dados confidenciais. Após centenas de casos, podemos afirmar, sem sombra de dúvidas, que os ataques estão mais sofisticados do que nunca. Com agilidade, eles exploram controles de segurança falhos e práticas operacionais negligentes e, munidos com ferramentas comuns para gerenciamento de rede, adaptam malwares. Táticas e tecnologias de segurança da informação também progrediram, mas não no mesmo ritmo. 

A boa notícia é que existem métodos razoáveis e bem conhecidos para mitigar muitas das brechas que conhecemos; precisamos, apenas, implementar esses métodos de forma mais ampla. 

Começaremos descrevendo três brechas do mundo real:

O website de uma empresa geralmente serve como porta de entrada para os ataques. Em uma investigação que conduzimos em uma empresa de serviços financeiros, os agressores exploraram uma falha que encontraram em um aplicativo Web em um servidor Web. O servidor não continha nenhum dado crítico e, em si, não

era importante para a empresa. O ataque também não foi muito sério; os agressores encontraram uma vulnerabilidade de injeção SQL e usaram uma função  "xp_cmdshell" para ativar suas ferramentas e conseguir uma posição segura dentro do servidor. Como a empresa não considerava nem o servidor e nem o aplicativo como críticos, eles não eram monitorados como deveriam e o ataque passou despercebido. 

Os agressores usaram o servidor comprometido como base. Eles distribuíram ferramentas e scanners e passaram vários meses mapeando a rede, meticulosamente, sem serem detectados. 

Assim que encontraram o sistema que continha os dados que eles procuravam, simplesmente copiaram a informação, "ziparam" os arquivos e removeram do sistema. 

A empresa usava tecnologia padrão para antivírus e firewall, mas só soube do ataque ao usar os dados no mundo real; do contrário, talvez a empresa nunca descobrisse tal brecha. 

Em uma outra investigação que conduzimos, os agressores usaram a mesma estratégia, comprometendo um servidor e-commerce baseado em Web de uma loja virtual. No entanto, quando os agressores conseguiram chegar ao sistema de banco de dados com os registros de cartões de créditos, descobriram que o banco de dados era criptografado. Ponto para os mocinhos, certo? Infelizmente, as chaves para decodificação foram roubados do mesmo sistema e os agressores tinham em mãos, as chaves do reino, literalmente.  

Nós trabalhamos em vários casos em que os agressores ganharam acesso por meio de sistemas de ponto de venda.  

A equipe de suporte dos fornecedores de sistemas de ponto de venda usam aplicativos comuns de acesso remoto, como VNC, para ter acesso aos sistemas e resolver os problemas de suporte. Mas o fornecedor usa a mesma senha de acesso remoto com todos os clientes. Os agressores sabiam essa senha e simplesmente executaram um scan de grande volume em outros sistemas que tinham o mesmo perfil. O resto foi fácil. 

Tiramos cinco lições essenciais desses e de outros casos de intrusos do mundo real: é hora de levar a sério a segurança de aplicativos Web; adicionar camadas de controles de segurança; entender os limites da tecnologia de segurança; revisar sistemas terceirizados; e saber que uma má resposta a um incidente é pior do que nenhuma resposta. 

1 - Leve a segurança a sério

Aplicativos web geralmente são a porta preferida dos invasores. Nós ainda vemos equipes de TI que mantém sistemas remendados e firewalls distribuídos mas ignoram aplicativos falhos que podem, facilmente, ser explorados. 

A melhor defesa de uma empresa é a integração da segurança no ciclo de vida de desenvolvimento de aplicativos. A criação de códigos com poucas falhas de segurança oferece um retorno maior do que se tentar reparar aplicativos em uso. 

É essencial usar uma tecnologia de rastreamento de aplicativos Web, como o AppScanner, da IBM, ou o WebInspect, da HP, seja para garantir qualidade ou revisar processos. As empresas que compram os aplicativos Web ao invés de criá-los em casa precisam revisar esses aplicativos ou exigir que os fornecedores executem avaliação de segurança verificada por terceiros.

Firewalls para aplicativos web servem como um controle de segurança secundário. Esse produtos são desenhados para captar ataques já conhecidos e identificar comportamentos suspeitos que podem indicar tentativas de invasão. 

No entanto, eles são apenas uma ajuda, porque não indicam a origem das práticas de desenvolvimento falhas e aplicativos vulneráveis. Um firewall de aplicativo web pode te ajudar a ganhar tempo, mas as empresas são irresponsáveis por não consertarem o que causa riscos.

2 - Complemente com controles secundários

Controles secundários como firewall interno, criptografia ou software de monitoramento de banco de dados podem ajudar as equipes de seguranças emitindo avisos ou impedir ataques quando os agressores contornarem os controles primários. 

Infelizmente, raramente vemos implementação eficaz de controles secundários. 

Por exemplo, existem empresas que distribuem uma linha complementar de firewalls dentro da rede para isolar melhor sistemas críticos, o que é uma prática que encorajamos, no entanto, é comum encontrar firewalls internos com configurações de política falha que simplesmente permitem tráfego total, ou com regras complicadas que ninguém entende por falta de documentação. Nós tivemos alguns casos em que o firewall interno teria impedido o ataque se tivesse sido configurado corretamente. 

As empresas inteligentes irão identificar onde podem usar segmentação para isolar melhor sistemas ou dados confidencias e críticos, e criarão controles de sistemas secundário e terciário baseados na segmentação. É perguntando "O que nos prejudicaria mais caso fôssemos comprometidos?" Então, os fabricantes podem adicionar camadas de segurança ao redor de sistemas que armazenam designs de produtos e linhas de controle. Um serviço pode segmentar sistemas de controle. Um processador de pagamento ou comercial deve ser focado no sistema que processa pagamentos. 

Mas não pare após implementar os controles secundários e esqueça-os. Tome cuidado com as políticas que facilitam operações gerais mas neutralizam absolutamente os valores do controle para redução de riscos. Configure, documente e monitore esses controles. Dedique recursos para examinar os relatórios desses sistemas de controle com frequência e observe mudanças ou atividades anormais. 

Se feito certo, esses controles complementares podem te salvar; se feito errado, prejudicam o ambiente enquanto oferecem uma falsa sensação de segurança. 

3 - Conheça seus limites 

A terceira lição é entender os limites do seu sistema de segurança. Nós temos antivírus, firewalls, sistemas de detecção de intrusos em redes e hosts, autenticação, ICP, VPNs, NAC, rastreador de vulnerabilidades, ferramentas de prevenção de perda de dados, informação de segurança, plataformas de gerenciamento de eventos - e mesmo assim, as brechas ainda resistem. 

Isso porque os controles não acompanham os progressos dos agressores. Nós trabalhamos em vários casos em que sistemas com antivírus completamente atualizados falharam e não detectaram cavalos-de-tróia ativos, key loggers e sniffers (farejadores). Muitos dos ciclos de desvolvimento de assinatura de antivírus ainda funcionam com base em uma suposição antiga de que um pedaço de malware vai se espalhar e permitir que o desenvolvedor tome consciência dele e construa uma nova assinatura. Os agressores usam pacotes para esconder o malware dos antivírus. 

Rastreadores de vulnerabilidade também não estão em dia com as novas vulnerabilidades e não podem rastrear os aplicativos de forma eficaz. Detecção de intrusos e prevenção sofrem do mesmo mal que os antivírus. 

O que a equipe de TI deve fazer? Para começar, identifique o nível de segurança de uma tecnologia - e só. Não espere que seu antivírus encontre malware comum. Use rastreadores de vulnerabilidade apenas como um teste secundário para garantir que seu sistema de gerenciamento está funcionando. Acredite que seu firewall irá bloquear scans automáticos mas que um agressor habilidoso conseguirá ultrapassar a área protegida. 

Sistemas de detecção de intrusos e prevenção podem ser úteis às vezes, mas descobrimos que os dados de Netflow do roteador e os relatórios das permissões do firewall oferecem uma visão melhor do caminho percorrido pelos agressores e ajudam a medir a extensão da brecha. 

Do ponto de vista operacional, considere implementar tecnologia de gerenciamento de eventos para entender a atividade dos sistemas múltiplos ou, pelo menos, implemente gerenciador centralizado de relatórios para ajudar a pesquisar, revisar e armazenar relatórios. 

Considere também a habilidade e a motivação do seu adversário e quais controles podem ser necessários para detectar sua presença. Entender sua capacidade é extremamente importante. 

4 - Confie, mas verifique

A quarta lição é simples, mas muitas vezes esquecida: revise sistemas terceirizados. Como mostra nosso exemplo de ponto de venda, segurança que combina diligência deve ser realizada por uma equipe interna ou por uma empresa de segurança

de aplicativo terceirizada. Não se esqueça dos frutos mais baixos, mude as senhas padrão.  

5 - Previna acidentes

Por fim, geralmente lidamos com empresas em que a equipe de TI destrói evidências, seja com ou sem intenção, ao reconstruir sistemas, apagar discos, limpar seções de banco de dados ou dar acesso aos sistemas comprometidos à terceiros. Isso tudo torna mais difícil encontrar o problema e pode destruir ou comprometer evidências que poderiam ser usadas em processos criminais.

Mantenha-se nos procedimentos básicos - nem que sejam tão básicos quanto "não fazer nada antes de checar o procedimento para resposta a incidentes". Existem muitos materiais gratuítos, desde o guia NIST 800-61 até as orientações do guia "If Compromised" ("Se comprometido") do Visa. Ambos os documentos pode ser encontrados facilmente em uma busca na web. 

As brechas na segurança causam muitos problemas para as empresas e para os profissionais de TI envolvidos, mas o silêncio não é sempre a melhor opção. Remover o véu dos erros comuns ajuda as empresas a entender o que estão enfrentando. (Tradução Rheni Victório)

*Greg Shipley, Tyler Allison e Tom Wabiszczewicz trabalham no escritório de Chicado da Neohapsis

Postagem: Wydemar Fernandes

Origem: Professor Fernando.