sexta-feira, 18 de abril de 2014

Por que as bases de dados exigem proteção específica?

Por Josh Shaul, Diretor de Produtos Gerenciados da Trustwave
 
As recentes notícias acerca da violação de dados da rede militar dos EUA, na qual hackers tiveram acesso a informações localizadas em bancos de dados do Departamento da Marinha, destacaram falhas de segurança em sistemas de terceiros (e não da própria Marinha) que levaram os atacantes ao seu destino final.

E essa história não é única. Várias violações recentes parecem ter se originado no sistema de fornecedores ou parceiros. Mas talvez seja um sinal de que estamos começando a ver a foto em tamanho maior - aquela em que os limites da nossa rede segura e controlada se tornam totalmente transparentes na medida em que nos conectamos com o mundo para acelerar o ritmo dos negócios.

Por muitos anos, eu tenho pregado o evangelho da segurança dos dados. Em grande parte do tempo, a resposta que eu recebo, quando pergunto a um CSO sobre a estratégia de segurança do banco de dados de sua empresa, é nada mais que uma descrição das proteções em torno do perímetro da rede.

Firewalls, prevenção de intrusão, anti-malware - tudo o que as empresa vem implantando são apenas as tecnologias que podem ser compradas para proteger as suas redes. O que muitas não percebem é que, embora a proteção do perímetro seja um componente vital do plano de segurança, esta, por si só, não é suficiente.

Como a maioria dos profissionais "internos" de TI já sabe, proteger as fronteiras é difícil, especialmente em um ambiente onde aplicações web, em nuvem e as móveis são cada vez mais utilizadas para fins corporativos.

De acordo com o Relatório de Pressões de Segurança da Trustwave, editado em 2014, e que detalha os resultados de uma pesquisa envolvendo mais de 800 profissionais de TI em todo o mundo; há uma forte pressão sobre os profissionais de segurança para que eles liberem, de forma rápida, a implementação de um número cada vez maior de aplicativos móveis e serviços em nuvem na estrutura da empresa. Mas estes são, segundo a pesquisa, os pontos de maior risco de vulnerabilidade apontados pela segurança de TI.

Mesmo entendendo-se que a proteção das fronteiras seja essencial e, em muitos casos, impeça violações de dados potencialmente destrutivas, vamos imaginar que um criminoso consiga encontrar outra maneira - que não pelas bordas - de penetrar na rede.

Sabemos, por exemplo, que muitas empresas têm colaboradores que carregam laptos, tablets e outros aparelhos móveis dentro de suas dependências, muitas expondo esses dispositivos a redes desprotegidas. De imediato, isso já cria oportunidade para os atacantes plantarem um malware nesses dispositivos que, em algum momento, acabarão por se conectar à rede corporativa, dando aos bandidos uma janela aberta para o banco de dados. Os malwares direcionados são outra ameaça muito real - que  ignoram totalmente as mais tradicionais defesas da rede, bem como a barreira dos antivírus. Outra revelação da pesquisa da Trustwave, é que os malwares direcionados estiveram no topo da lista de ameaças de segurança que causaram mais preocupação para as organizações durante o ano de 2013, seguidos pela violação de dados e pelos ataques via engenharia social.

Se há algo de que os criminosos estão atrás, sem dúvida, são exatamente os dados sensíveis, valiosos e vendáveis. A equipe da Trustwave tem realizado milhares de testes de penetração e investigações forenses durante os últimos anos. Com isso, temos visto, em primeira mão, quais métodos os cibercriminosos utilizam para comprometer sistemas e roubar dados. E é nas bases de dados que estão algumas das maiores deficiências de segurança das empresas.

Como sabemos, todos os bancos de dados têm um sistema de autenticação para controlar os logins de acesso. Existem várias formas de autenticação, mas, em geral, os sistemas são configurados para permitir a autenticação de usuário/senha (a opção menos robusta). Apenas bata na porta, diga o nome e a senha corretos, e você já está dentro, bastante simples. E pode se tornar ainda mais simples. As bases de dados, muitas vezes, vêm com usuários nativos (built-in), que dispõem de senha provisória (default). Há inúmeras listas desses modelos de usuário built-in/senha default disponíveis na Internet. Assim quando você instala um aplicativo, pode estar instalando também essas manjadas senhas default de suas contas built-in.

Outro problema sério está nas pessoas. Muitas empresas dão aos colaboradores contas em bancos de dados e esperam que eles usem senhas fortes. Na Trustwave, temos frequentemente em nossas mãos verdadeiros espólios de cibercriminosos - enormes depósitos de senhas roubadas. Nossa avaliação  dessas senhas não é nada encorajadora. Os dados mostram como a nossa sociedade se tornou ótima em escolher senhas realmente ruins, mesmo que ainda atendam aos requisitos mínimos de complexidade. De acordo com o 2013 Trustwave Global Security Report, as expressões Welcome1, Store123 e Password1 foram as três principais senhas usadas no ano passado.

Corrigir um banco de dados falho também pode ser um desafio, especialmente considerando o processo de planejamento, coordenação e testes, que deve acontecer antes do aplicativo de produção ser alterado. Considere alguns desses problemas: Fornecedores de bancos-de-dados não pré-divulgam as correções para o fornecedor da aplicação. Todo mundo pega a correção ao mesmo tempo. Na maioria dos departamentos de TI, não há discussão sobre correção dos bancos de dados, até que a equipe de aplicação, ou o fornecedor, anuncie uma compatibilidade com a nova patch que foi lançada.

Este é o ponto onde a janela da exposição começa a se abrir. Uma vez que a patch é testada pelo fornecedor do aplicativo, ela normalmente deve ser instalada e testada exaustivamente em um setor de não-produção. Só então o down time da aplicação está corretamente agendado e a nova patch pode, finalmente, ser aplicada na produção.
 
Com base em nossa experiência, esse processo de correção leva cerca de nove meses.

Mas para um atacante, encontrar um meio de explorar um banco de dados, cujas correções foram realizadas em nove longos meses, bastam apenas algumas habilidades básicas de pesquisa e simples ações "recorte e cole". Além disso, no momento em que um fornecedor de banco de dados corrige uma vulnerabilidade, o surgimento de códigos de livre exploração torna-se quase inevitável. Os atacantes sabem disso e estão sempre tirando proveito da situação.

Mais um ponto fraco que vemos nos bancos de dados refere-se à forma como eles são configurados. Os bancos de dados modernos têm um conjunto formidável de recursos de segurança e controles de acesso. Quando implantados corretamente, os controles ajudam a prevenir ataques, abuso e uso indevido. No entanto, muitas vezes, descobrimos que eles estão configurados incorretamente, com recursos de segurança desativados e controles de acesso fora de atividade.

Parte do problema decorre da batalha entre a facilidade de uso e a maior segurança. Quanto mais os fornecedores realizam ajustes 'fora da caixinha' em relação à segurança dos seus bancos de dados, mais difícil se torna seu uso. Com os controles de acesso ocorre a mesma coisa. É muito mais fácil configurar e usar um sistema com controles de acesso abertos do que definir claramente os papeis e privilégios de cada um, e então dar entrada e manter essas regras para cada banco de dados em particular.

Os bancos de dados também contêm "opções" de segurança que simplesmente não deveriam ser opcionais. Recursos como a desativação de autenticação, permitindo ilimitadas tentativas fracassadas de login, ou permitindo senhas em branco em contas de administrador, não deveriam ter lugar nos sistemas que armazenam os nossos dados mais preciosos. E essas são opções reais para diversos  produtos de bancos de dados do mercado.

É tempo de as empresas fazerem da segurança de seu banco de dados uma prioridade, além de assegurar os perímetros. Os bancos de dados são, atualmente, o elo mais fraco de muitas empresas. Tomar medidas para protegê-los nos locais em que estão instalados, pode ser a barreira que faltava para a boa política de segurança. 
 

Nenhum comentário:

Postar um comentário