5 li��es de seguran�a

5 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 destroi 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

in http://www.itweb.com.br/noticias/index.asp?cod=60785