A sociedade hoje passa por um momento de inflexão, com transformações inevitáveis, sobretudo nas empresas. Estas mudanças são marcadas por dois fatores: a conscientização ambiental e a crise dos mercados financeiros. Em relação à primeira, é fundamental que a sociedade tenha uma mudança de postura, pois os recursos naturais do planeta estão sendo mal utilizados. O último estudo da organização WWF mostra que estamos utilizando mais do que o planeta pode fornecer, mais precisamente 1,3 planetas Terra. Na linha de frente estão os governos e as empresas.
Já a crise financeira global, de tamanho e longevidade ainda indefinidos - pelo menos no momento em que escrevo este artigo -, começa a afetar a economia real, o crédito e os investimentos. O fato concreto é que muitas empresas já adotam medidas conservadoras como controle de gastos e reavaliação de investimentos. Neste cenário, duas palavras ganharam maior importância: eficiência e redução. Eficiência operacional e na utilização de recursos. Redução de custos, consumo, emissões e complexidade.
É claro que todas as mudanças que afetam as empresas possuem forte impacto na área de TI, com reflexos também na área de segurança em geral, e em segurança de redes em particular. Como normalmente ocorre, a indústria de tecnologia não está à margem e muitas já detectaram a necessidade de uma TI menor, porém mais eficiente e, preferencialmente, mais segura.
A necessidade de maior segurança e conformidade com regulações nas operações de negócio, aliada ao desenvolvimento de técnicas mais avançadas de invasão, causaram a proliferação de dispositivos de segurança instalados na rede. Há poucos anos, as redes basicamente possuíam apenas um firewall instalado. Hoje é normal encontrar em redes de médio e grande porte os sistemas IPS de prevenção de intrusos e de detecção de anomalias e controle de tráfego; filtros anti-spam, de conteúdo e anti-vírus; e agora os novos dispositivos de DLP para prevenção de perda de dados.
Realmente são muitos equipamentos. Por outro lado, a TI Verde está causando um movimento oposto, com a consolidação de servidores e serviços e a diminuição dos CPDs. Na indústria de tecnologia de segurança também há movimentos como este, com o objetivo de obter maior eficiência, menos complexidade e menor custo. Um deles é o da virtualização da segurança, diferente da proteção dos ambientes virtualizados, embora ambos possuam alguma interposição.
A virtualização da segurança é a transformação dos tradicionais dispositivos de segurança de rede – appliances – em dispositivos virtuais, baseados nas mesmas tecnologias usadas para virtualizar servidores de aplicações. O benefício é a utilização de um único equipamento – no caso um servidor munido de suporte à virtualização – para hospedar diferentes dispositivos virtuais de proteção, sejam firewalls, sistemas IPS ou filtros diversos. Note que é bem diferente do antigo modelo de software de segurança, que exigia um servidor para cada instância de software. Aqui estamos falando de um servidor executando várias instâncias, não do software de segurança em si, mas de um dispositivo virtual completo, que não exige instalação do componente de segurança, já que este já está instalado na máquina virtual. A vantagem é fácil de perceber: o espaço que antes era ocupado por vários equipamentos, consumindo energia e emitindo calor, agora pode ser substituído por apenas um equipamento.
No entanto, as limitações deste modelo nos levam a outra tendência: da consolidação de dispositivos físicos em um hardware especialmente projetado. A limitação dos appliances virtuais é o desempenho. Afinal de contas estamos falando de um único servidor, com placas de redes tradicionais e sem customização para o tratamento de pacotes de rede, necessário para a proteção de redes de alta capacidade.
Este novo hardware segue o modelo dos já consagrados switches de chassi, que consolidam centenas de portas de acesso e evitam que as empresas tenham que comprar múltiplos switches de configuração fixa de portas. No caso da segurança de redes, estamos falando de um chassi de uso específico, no qual as placas podem ser selecionadas entre módulos de rede gigabit ou decagiga, e módulos de aplicação contendo diferentes sistemas e necessidades, do firewall aos filtros de rede. Para atender aos requerimentos, os chassis de segurança, chamados também de switches de segurança, precisam ter algumas funcionalidades e características básicas.
A primeira e principal característica é a diversidade de tecnologias que podem ser implementadas nos módulos de aplicação do hardware. Quanto mais opções, mais se poderá consolidar e simplificar a rede. Aqui já temos uma primeira diferenciação: os fabricantes que optaram por plataformas abertas e aqueles que decidiram criar plataformas para consolidar suas próprias tecnologias. Independente da escolha deve-se avaliar o conjunto da solução, bem como cada aplicação de segurança individualmente, além do plano de expansão da plataforma.
Entre as funcionalidades, destaco duas. A primeira é a capacidade de rotear o tráfego interno para que o administrador possa escolher como os pacotes de rede serão analisados pelos diferentes módulos de segurança. Há fabricantes que permitem que determinado tráfego passe apenas por um módulo – digamos o firewall – enquanto outro tráfego passe pelo firewall, IPS e filtro web. Pode-se também escolher a ordem pela qual cada porção do tráfego é analisada. A segunda funcionalidade é do balanceamento de tráfego. Imagine que em determinado momento ou época do ano é necessária uma capacidade de análise de firewall maior, o que em um ambiente normal exigiria um hardware maior e mais investimento. Em uma plataforma consolidada, isto pode ser resolvido com a utilização temporária de uma placa adicional de aplicação, com o tráfego balanceado entre as duas.
Ambos os modelos são incrivelmente vantajosos em comparação com o que temos hoje. Com eles a mudança de arquitetura de segurança torna-se apenas uma questão de reconfigurar o sistema centralizado, seja o servidor de virtualização ou o chassi de segurança. Reduzir ou aumentar capacidades torna-se uma tarefa muito mais simples, acompanhando mudanças no negócio, e a manutenção de investimentos algo muito mais palpável. A complexidade da administração e manutenção também diminui consideravelmente, afinal estamos falando de um único equipamento no lugar de vários. Ativar, substituir ou desativar instâncias de proteção, reaproveitando os recursos para outras aplicações, também se torna mais simples.
No entanto, o melhor ainda está por vir. A tendência para o futuro, não muito distante, é o surgimento de plataformas de hardware combinando ambos modelos, e isso sim significará um enorme avanço. Fisicamente haverá a mesma plataforma de chassis existente hoje, porém as aplicações executadas em seus módulos serão virtualizadas. Ainda mais flexibilidade para um mundo em que a segurança de redes será, pelo menos em parte, mais eficiente e mais simples.
quarta-feira, 3 de dezembro de 2008
terça-feira, 4 de novembro de 2008
Produtos para Data Loss Prevention (DLP)
A chegada do tema da prevenção da perda ou vazamento de dados – data loss prevention, DLP –trouxe consigo a inevitável discussão sobre produtos e tecnologias. Como já comentado em outros artigos, o principal fundamento do DLP é que o dado necessita ser protegido ao longo do seu ciclo de vida, o que exige medidas de proteção enquanto o dado está armazenado, em uso, em transmissão, arquivado ou no processo de descarte.
É um fato que a implementação eficiente do DLP não pode ser baseada unicamente em produtos, porém dificilmente se chegará a resultados eficientes sem eles. Dessa forma, considero importante comentar sobre como o mercado e fornecedores estão se organizando em torno do tema. Infelizmente, como sempre há gente tentando se aproveitar, uma quantidade enorme de produtos começou a ser classificada como “produtos para DLP”, além do produto mágico que “resolve todos os problemas”, mesmo que a empresa não faça nada mais além do que comprar e instalar tal produto.
Um principio que não deve ser quebrado é que o projeto da empresa não pode, em hipótese alguma, começar com a aquisição de produtos. A primeira etapa é identificar quais são os tipos de dados considerados críticos e mapeá-los, e só depois selecionar produtos de acordo com a necessidade de proteção em cada fase do ciclo de vida. Os principais produtos serão os de detecção e/ou prevenção de mal uso, havendo também uma divisão entre as ferramentas para rede (network DLP) e para estações (endpoint DLP).
Os primeiros são baseados na captura e análise de tráfego para detectar a transmissão de dados importantes, não muito diferente dos sistemas de detecção de intrusos (IDS). Alguns possuem a capacidade de bloquear o tráfego, o que exige sua instalação em linha e traz vantagens, porém adiciona à rede mais um ponto de falha, exigindo medidas de alta disponibilidade. A empresa deverá averiguar quais são os protocolos suportados, já que normalmente os dados podem ser enviados por meios distintos como correio eletrônico, webmail, instant messenger e FTP. Outro elemento de diferenciação é a capacidade de resistir a evasão, já que pessoas capacitadas tentarão enganar os sistemas IDS/IPS, utilizando-se de técnicas já bem difundidas de fragmentação, mascaramento de tráfego e outros. A semelhança com esses sistemas é tão grande que alguns deles estão incorporando funcionalidades DLP. O mesmo está acontecendo com produtos anti-spam, também começando a checar a transmissão de dados. Aqui também temos vantagens e desvantagens. A vantagem principal é a simplificação e a redução de custos, e a desvantagem é o peso das novas funcionalidades no seu desempenho, além do fato de que talvez a cobertura não seja tão ampla quanto o de um produto especializado.
Já o endpoint DLP se concentra em monitorar o uso dos dados nas estações de trabalho. Esse cuidado se justifica. É nos computadores pessoais que ocorrem muitas das violações e vazamentos, além de ser onde documentos confidenciais são criados e alterados. O cuidado se intensifica quando se leva em consideração a capacidade crescente de armazenamento de dispositivos USB e bluetooth, incluindo tocadores de música e smartphones. As funcionalidades podem variar, mas em geral o software deve ser leve para não carregar ainda mais o já sobrecarregado computador, deve suportar diferentes formatos de arquivos de dados, possuir algum tratamento para bloquear arquivos criptografados e ser capaz de analisar clientes de correio eletrônico e webmail.
Os principais produtos trazem integrados a funcionalidade de varredura, a fim de identificar dados críticos armazenados em bancos de dados e servdores de arquivos. O suporte a múltiplos formatos de arquivos é mais uma vez requerido, além do suporte a diferentes sistemas de bancos de dados. As varreduras ajudam a equacionar uma das maiores dores de cabeça que é a falta de controle sobre o armazenamento de dados nas empresas, sobretudo os não estruturados.
As duas funcionalidades podem ser encontradas em produtos separados ou em suítes. Estas trazem a vantagem da integração e da console unificada, mas é necessário prestar atenção nas funcionalidades disponíveis antes de se deixar levar pelo apelo natural desses produtos. Uma característica que não deve deixar de ser levada em conta na hora da seleção é a capacidade e facilidade de customização para o Brasil, afinal ninguém aqui precisa de detecção de números da seguridade social americana, identificação que corresponde ao CPF brasileiro. Outro recurso interessante e desejável é a integração com sistemas de diretório, como o Active Directory, permitindo que rapidamente o autor de uma violação seja identificado, e o perfil de violações de pessoas e departamentos possa ser mapeado.
Apesar desses produtos constituirem a espinha dorsal do DLP, ele não se restringe a eles. Uma estratégia bem desenhada não pode prescindir do gerenciamento de identidade e do controle de acesso, essenciais para garantir a confidencialidade e integridade dos dados. A esses sistemas se juntam as ferramentas de auditoria de acesso, sempre englobando tanto os dados estruturados como os não estruturados. Outra tecnologia que também deve estar sempre presente é a criptografia. Criptografar significa esconder os dados de olhos indesejados, e deve ser considerada principalmente na transmissão de dados via Internet ou outras redes compartilhadas. Para laptops deveria ser uma exigência em todas as empresas, visto a quantidade de computadores portáteis roubados ou furtados.Por fim, não custa repetir que antes de adquirir um produto é preciso saber exatamente do que se precisa e analisar bem as opções. A aquisição deve vir acompanhada de um bom projeto de implementação e administração, que aliás deve ser continua, com equipe permanente, treinada e dedicada à função.
É um fato que a implementação eficiente do DLP não pode ser baseada unicamente em produtos, porém dificilmente se chegará a resultados eficientes sem eles. Dessa forma, considero importante comentar sobre como o mercado e fornecedores estão se organizando em torno do tema. Infelizmente, como sempre há gente tentando se aproveitar, uma quantidade enorme de produtos começou a ser classificada como “produtos para DLP”, além do produto mágico que “resolve todos os problemas”, mesmo que a empresa não faça nada mais além do que comprar e instalar tal produto.
Um principio que não deve ser quebrado é que o projeto da empresa não pode, em hipótese alguma, começar com a aquisição de produtos. A primeira etapa é identificar quais são os tipos de dados considerados críticos e mapeá-los, e só depois selecionar produtos de acordo com a necessidade de proteção em cada fase do ciclo de vida. Os principais produtos serão os de detecção e/ou prevenção de mal uso, havendo também uma divisão entre as ferramentas para rede (network DLP) e para estações (endpoint DLP).
Os primeiros são baseados na captura e análise de tráfego para detectar a transmissão de dados importantes, não muito diferente dos sistemas de detecção de intrusos (IDS). Alguns possuem a capacidade de bloquear o tráfego, o que exige sua instalação em linha e traz vantagens, porém adiciona à rede mais um ponto de falha, exigindo medidas de alta disponibilidade. A empresa deverá averiguar quais são os protocolos suportados, já que normalmente os dados podem ser enviados por meios distintos como correio eletrônico, webmail, instant messenger e FTP. Outro elemento de diferenciação é a capacidade de resistir a evasão, já que pessoas capacitadas tentarão enganar os sistemas IDS/IPS, utilizando-se de técnicas já bem difundidas de fragmentação, mascaramento de tráfego e outros. A semelhança com esses sistemas é tão grande que alguns deles estão incorporando funcionalidades DLP. O mesmo está acontecendo com produtos anti-spam, também começando a checar a transmissão de dados. Aqui também temos vantagens e desvantagens. A vantagem principal é a simplificação e a redução de custos, e a desvantagem é o peso das novas funcionalidades no seu desempenho, além do fato de que talvez a cobertura não seja tão ampla quanto o de um produto especializado.
Já o endpoint DLP se concentra em monitorar o uso dos dados nas estações de trabalho. Esse cuidado se justifica. É nos computadores pessoais que ocorrem muitas das violações e vazamentos, além de ser onde documentos confidenciais são criados e alterados. O cuidado se intensifica quando se leva em consideração a capacidade crescente de armazenamento de dispositivos USB e bluetooth, incluindo tocadores de música e smartphones. As funcionalidades podem variar, mas em geral o software deve ser leve para não carregar ainda mais o já sobrecarregado computador, deve suportar diferentes formatos de arquivos de dados, possuir algum tratamento para bloquear arquivos criptografados e ser capaz de analisar clientes de correio eletrônico e webmail.
Os principais produtos trazem integrados a funcionalidade de varredura, a fim de identificar dados críticos armazenados em bancos de dados e servdores de arquivos. O suporte a múltiplos formatos de arquivos é mais uma vez requerido, além do suporte a diferentes sistemas de bancos de dados. As varreduras ajudam a equacionar uma das maiores dores de cabeça que é a falta de controle sobre o armazenamento de dados nas empresas, sobretudo os não estruturados.
As duas funcionalidades podem ser encontradas em produtos separados ou em suítes. Estas trazem a vantagem da integração e da console unificada, mas é necessário prestar atenção nas funcionalidades disponíveis antes de se deixar levar pelo apelo natural desses produtos. Uma característica que não deve deixar de ser levada em conta na hora da seleção é a capacidade e facilidade de customização para o Brasil, afinal ninguém aqui precisa de detecção de números da seguridade social americana, identificação que corresponde ao CPF brasileiro. Outro recurso interessante e desejável é a integração com sistemas de diretório, como o Active Directory, permitindo que rapidamente o autor de uma violação seja identificado, e o perfil de violações de pessoas e departamentos possa ser mapeado.
Apesar desses produtos constituirem a espinha dorsal do DLP, ele não se restringe a eles. Uma estratégia bem desenhada não pode prescindir do gerenciamento de identidade e do controle de acesso, essenciais para garantir a confidencialidade e integridade dos dados. A esses sistemas se juntam as ferramentas de auditoria de acesso, sempre englobando tanto os dados estruturados como os não estruturados. Outra tecnologia que também deve estar sempre presente é a criptografia. Criptografar significa esconder os dados de olhos indesejados, e deve ser considerada principalmente na transmissão de dados via Internet ou outras redes compartilhadas. Para laptops deveria ser uma exigência em todas as empresas, visto a quantidade de computadores portáteis roubados ou furtados.Por fim, não custa repetir que antes de adquirir um produto é preciso saber exatamente do que se precisa e analisar bem as opções. A aquisição deve vir acompanhada de um bom projeto de implementação e administração, que aliás deve ser continua, com equipe permanente, treinada e dedicada à função.
sexta-feira, 8 de agosto de 2008
Vulnerabilidades e Ameças para Web e Phishing
O IBM X-Force, a equipe de pesquisa e inteligência em segurança da IBM Internet Security Systems, publicou neste mês o seu relatório de meio de ano, analisando as ameaças e vulnerabilidades do ano, além das tendências para o segundo semestre de 2008. Essa análise no meio do ano é uma ótima oportunidade para analisarmos a situação geral da segurança digital, comparar com a estratégia e ações adotadas e realizar desde já ajustes de rota. O relatório está disponível no endereço http://www-935.ibm.com/services/us/iss/xforce/midyearreport e vale a pena ser lido.
Boa parte do relatório está focado na análise de vulnerabilidades e ameaças para aplicações web. O primeiro dado importante é que ele confirma as tendências anunciadas no ano passado que indicavam o ambiente web – browser, plugins, aplicações – como o novo foco e alvo principal do crime digital, evidenciando que as empresas precisam acompanhar e ajustar o foco de sua estratégia, destinando recursos para a proteção de aplicações web. É fato que a maior parte das empresas ainda é lenta em acompanhar movimentações do crime digital, o que nesse tema se traduz em ainda privilegiar e direcionar a maior parte dos recursos de segurança para a proteção do sistema operacional.
Alguns dados no relatório chamam bastante atenção. Aplicações relacionadas a web respondem por 51% de todas as vulnerabilidades mapeadas desde 2006, e 54% das que foram reportadas este ano. Esse dado dá a dimensão do problema, porém outro é ainda mais preocupante: 94% dos exploits (os programas de ataque) foram lançados no mesmo dia da publicação da vulnerabilidade, o que significa pouquissimo tempo de reação para empresas que ainda adotam essa postura em sua estratégia de segurança.
O relatório também aborda spams e phishing, com uma visão atualizada, e mostra como funciona a dinâmica no mundo do crime digital. Nos últimos anos os fabricantes de sistemas anti-spam investiram para sofisticar as tecnologias de detecção, passando a detectar spam em mensagens contendo apenas imagens, textos complexos ou estruturas de HTML complexas. Esse investimento surtiu efeito e a eficácia das mensagens spam em passar pelos sistemas de detecção reduziu bastante. E o que o X-Force observou? A substituição dessas técnicas pela de mensagens URL inseridas em textos pequenos, e o uso de URLs com pequena duração, o que dificulta a detecção.
Uma mensagem phising que está obtendo bastante sucesso aqui no Brasil falsifica uma mensagem do UOL charges, simulando que a vítima está recebendo uma charge enviada por um amigo ou parente. Ao infectar o computador, o programa envia novas mensagens para toda a lista de contatos da vítima. A mensagem é bem escrita e parece ser real. Apenas uma análise atenta da URL contida na mensagem levanta suspeitas, porém um usuário sem conhecimentos de informática dificilmente irá perceber a fraude. Adicionalmente, poucos antivirus detectam o programa com sucesso, o que se é de esperar já que muitos grupos estão utilizando técnicas de mutação de código para enganá-los. Por outro lado, o vírus é facilmente eliminado do computador e não utiliza técnicas rootkit, que tornam o vírus invisível até mesmo de programas avançados de detecção. Os rootkits mais avançados chegam a exigir uma completa reinstalação do sistema operacional.
A mensagem para gerentes de segurança é: fique sempre alerta e não descanse sobre uma ameaça aparentemente vencida. Para isto, três atividades são essenciais: informação, monitoração e análise. Informação para acompanhar o que está ocorrendo no mundo e não ser pego de surpresa. Para isto as empresas contam com serviços gratuitos e pagos disponíveis para todos os orçamentos e perfis. No site da IBM é possível obter gratuitamente informações sobre o nível de risco atual, vulnerabilidades e ameaças. Pela monitoração a empresa pode detectar rapidamente uma tentativa ou inicio de invasão, e medir a eficiência de seus dispositivos de proteção. Porém, mas do que acompanhar eventos, pela monitoração se pode identificar tendências, o que serve para a análise dessas tendências de ataque a empresa em relação às tendências mundiais, e a definição de ações imediatas e médio prazo, além de prover insumos para o planejamento de longo prazo em segurança.
Boa parte do relatório está focado na análise de vulnerabilidades e ameaças para aplicações web. O primeiro dado importante é que ele confirma as tendências anunciadas no ano passado que indicavam o ambiente web – browser, plugins, aplicações – como o novo foco e alvo principal do crime digital, evidenciando que as empresas precisam acompanhar e ajustar o foco de sua estratégia, destinando recursos para a proteção de aplicações web. É fato que a maior parte das empresas ainda é lenta em acompanhar movimentações do crime digital, o que nesse tema se traduz em ainda privilegiar e direcionar a maior parte dos recursos de segurança para a proteção do sistema operacional.
Alguns dados no relatório chamam bastante atenção. Aplicações relacionadas a web respondem por 51% de todas as vulnerabilidades mapeadas desde 2006, e 54% das que foram reportadas este ano. Esse dado dá a dimensão do problema, porém outro é ainda mais preocupante: 94% dos exploits (os programas de ataque) foram lançados no mesmo dia da publicação da vulnerabilidade, o que significa pouquissimo tempo de reação para empresas que ainda adotam essa postura em sua estratégia de segurança.
O relatório também aborda spams e phishing, com uma visão atualizada, e mostra como funciona a dinâmica no mundo do crime digital. Nos últimos anos os fabricantes de sistemas anti-spam investiram para sofisticar as tecnologias de detecção, passando a detectar spam em mensagens contendo apenas imagens, textos complexos ou estruturas de HTML complexas. Esse investimento surtiu efeito e a eficácia das mensagens spam em passar pelos sistemas de detecção reduziu bastante. E o que o X-Force observou? A substituição dessas técnicas pela de mensagens URL inseridas em textos pequenos, e o uso de URLs com pequena duração, o que dificulta a detecção.
Uma mensagem phising que está obtendo bastante sucesso aqui no Brasil falsifica uma mensagem do UOL charges, simulando que a vítima está recebendo uma charge enviada por um amigo ou parente. Ao infectar o computador, o programa envia novas mensagens para toda a lista de contatos da vítima. A mensagem é bem escrita e parece ser real. Apenas uma análise atenta da URL contida na mensagem levanta suspeitas, porém um usuário sem conhecimentos de informática dificilmente irá perceber a fraude. Adicionalmente, poucos antivirus detectam o programa com sucesso, o que se é de esperar já que muitos grupos estão utilizando técnicas de mutação de código para enganá-los. Por outro lado, o vírus é facilmente eliminado do computador e não utiliza técnicas rootkit, que tornam o vírus invisível até mesmo de programas avançados de detecção. Os rootkits mais avançados chegam a exigir uma completa reinstalação do sistema operacional.
A mensagem para gerentes de segurança é: fique sempre alerta e não descanse sobre uma ameaça aparentemente vencida. Para isto, três atividades são essenciais: informação, monitoração e análise. Informação para acompanhar o que está ocorrendo no mundo e não ser pego de surpresa. Para isto as empresas contam com serviços gratuitos e pagos disponíveis para todos os orçamentos e perfis. No site da IBM é possível obter gratuitamente informações sobre o nível de risco atual, vulnerabilidades e ameaças. Pela monitoração a empresa pode detectar rapidamente uma tentativa ou inicio de invasão, e medir a eficiência de seus dispositivos de proteção. Porém, mas do que acompanhar eventos, pela monitoração se pode identificar tendências, o que serve para a análise dessas tendências de ataque a empresa em relação às tendências mundiais, e a definição de ações imediatas e médio prazo, além de prover insumos para o planejamento de longo prazo em segurança.
terça-feira, 5 de agosto de 2008
DNS Cache Poisoning
Reproduzo neste post artigo de Nelson Brito (nbrito@sekure.org), colega de trabalho e grande especialista e pesquisador em segurança, sobre a vulnerabilidade do DNS Poisoning. O Nelson não apenas descreve com perfeição a vulnerabilidade como aborda pontos curiosos.
Há uma nova vulnerabilidade que permitem aos hackers manipularem as entradas de DNS através de DNS Cache Poisoning, possibilitando a *manipulação de tradução de nome para endereço IP. A muito tempo não há uma vulnerabilidade multi-plataforma como esta que cause tanta comoção no cenário de segurança, pois esta vulnerabilidade afeta todas as implementações de DNS. Tanta comoção se explica, também, por um segundo fator. O pesquisador que descobriu a vulnerabilidade, Dan Kaminsky (http://www.doxpara.com/?p=1162), *trabalhou em segredo com vários fabricantes - entre eles Microsoft, Cisco, ISC, etc - para a correção. Só em 7 de Julho de 2008 a informação de uma vulnerabilidade de DNS Cache Poisoning veio a público.
Devido a gravidade da descoberta, ele solicitou que a comunidade de segurança não fizesse nenhuma especulação em público, para dar tempo às empresas e órgãos (todos que forem afetados) de aplicarem a correção. Esta solicitação foi interpretada como um desafio por outro pesquisadores. A princípio, Dan liberaria detalhes somente na Blackhat de Agosto próximo, (http://www.blackhat.com/html/bh-usa-08/bh-usa-08-speakers.html#Kaminsky), porém um hacker alemão, chamado Halvar Flake, liberou algumas "especulações corretas" sobre o funcionamento e detalhamento da vulnerabilidade em um BLOG. Estas informações ficaram poucos minutos disponíveis na Internet, pois o POST foi retirado do BLOG. Porém estes poucos minutos foram o suficiente para que a informação se propagasse pela Internet.
Ao final do dia 23 de Julho, o pesquisador HD Moore (autor do Metasploit Framework) e o hacker Druid, lançaram um exploit funcional para este vulnerabilidade (http://www.caughq.org/exploits/CAU-EX-2008-0002.txt). Uma curiosidade é que um dos desenvolvedores do exploit (HD Moore) foi vítima de sua própria criação, pois na manhã do dia 29 de Julho a empresa BreakingPoint, onde HD Moore trabalha, teve seu tráfego redirecionado para uma página falsa do Google (http://www.networkworld.com/news/2008/073008-dns-attack-writer-a-victim.html).
Apesar da preocupação inicial gerada pelo alto índice de automação do ataque, uma análise superficial pode sugerir alguma dificuldade na exploração de servidores DNSs bem configurados, aqueles onde usuários externos não tenham capacidade de iniciar consultas DNS. Ocorre que tal análise é falha pois todos os serviços dependem, em maior ou menor grau, do serviço DNS. Qualquer serviço, portanto, pode se tornar "side channel" para o ataque em questão. Cito, em particular, o serviço de e-mail. Neste caso o atacante pode gerar as consultas DNSs necessárias à exploração da vulnerabilidade através do envio de mensagens a contas inexistentes no domínio alvo. Ao receber estas mensagens o servidor de e-mail verificará a inexistência da conta de destino e realizará consultas DNS pelo MX do domínio do atacante de forma a devolver as mensagens ao remetente e gerando, assim, os pacotes necessários ao ataque. As configurações de Firewalls e NATs devem ser verificadas de forma a preservarem o caráter randômico da porta de origem.
Fontes da Web com mais informações
X-Force Database & MSS GTOC AlertCom
http://www.iss.net/threats/298.html
https://webapp.iss.net/gtoc/index.html
http://blogs.iss.net/archive/dnsnat.html
Original Release
http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
Milw0rm Release
http://milw0rm.com/exploits/6122
Metasploit Framework email list archive
http://spool.metasploit.com/pipermail/framework/2008-July/date.html#3528
*List of vulnerable ISPs (older)
http://www.hackerfactor.com/blog/index.php?/archives/204-Poor-DNS.html
NANOG email list archive
The postings on the subject to this list are well worth reading.
http://www.merit.edu/mail.archives/nanog/index.html#09778
Media / Blogs
http://blogs.zdnet.com/security/?p=1545
http://blog.wired.com/27bstroke6/2008/07/dns-exploit-in.html
http://www.circleid.com/posts/87233_dns_attack_code_published/
http://it.slashdot.org/it/08/07/23/231254.shtml
http://www.informationweek.com/blog/main/archives/2008/07/dns_poisoning_v.html
Online DNS testers for testing if one's dns is vulnerable to exploitation
https://www.dns-oarc.net
http://www.doxpara.com
Há uma nova vulnerabilidade que permitem aos hackers manipularem as entradas de DNS através de DNS Cache Poisoning, possibilitando a *manipulação de tradução de nome para endereço IP. A muito tempo não há uma vulnerabilidade multi-plataforma como esta que cause tanta comoção no cenário de segurança, pois esta vulnerabilidade afeta todas as implementações de DNS. Tanta comoção se explica, também, por um segundo fator. O pesquisador que descobriu a vulnerabilidade, Dan Kaminsky (http://www.doxpara.com/?p=1162), *trabalhou em segredo com vários fabricantes - entre eles Microsoft, Cisco, ISC, etc - para a correção. Só em 7 de Julho de 2008 a informação de uma vulnerabilidade de DNS Cache Poisoning veio a público.
Devido a gravidade da descoberta, ele solicitou que a comunidade de segurança não fizesse nenhuma especulação em público, para dar tempo às empresas e órgãos (todos que forem afetados) de aplicarem a correção. Esta solicitação foi interpretada como um desafio por outro pesquisadores. A princípio, Dan liberaria detalhes somente na Blackhat de Agosto próximo, (http://www.blackhat.com/html/bh-usa-08/bh-usa-08-speakers.html#Kaminsky), porém um hacker alemão, chamado Halvar Flake, liberou algumas "especulações corretas" sobre o funcionamento e detalhamento da vulnerabilidade em um BLOG. Estas informações ficaram poucos minutos disponíveis na Internet, pois o POST foi retirado do BLOG. Porém estes poucos minutos foram o suficiente para que a informação se propagasse pela Internet.
Ao final do dia 23 de Julho, o pesquisador HD Moore (autor do Metasploit Framework) e o hacker Druid, lançaram um exploit funcional para este vulnerabilidade (http://www.caughq.org/exploits/CAU-EX-2008-0002.txt). Uma curiosidade é que um dos desenvolvedores do exploit (HD Moore) foi vítima de sua própria criação, pois na manhã do dia 29 de Julho a empresa BreakingPoint, onde HD Moore trabalha, teve seu tráfego redirecionado para uma página falsa do Google (http://www.networkworld.com/news/2008/073008-dns-attack-writer-a-victim.html).
Apesar da preocupação inicial gerada pelo alto índice de automação do ataque, uma análise superficial pode sugerir alguma dificuldade na exploração de servidores DNSs bem configurados, aqueles onde usuários externos não tenham capacidade de iniciar consultas DNS. Ocorre que tal análise é falha pois todos os serviços dependem, em maior ou menor grau, do serviço DNS. Qualquer serviço, portanto, pode se tornar "side channel" para o ataque em questão. Cito, em particular, o serviço de e-mail. Neste caso o atacante pode gerar as consultas DNSs necessárias à exploração da vulnerabilidade através do envio de mensagens a contas inexistentes no domínio alvo. Ao receber estas mensagens o servidor de e-mail verificará a inexistência da conta de destino e realizará consultas DNS pelo MX do domínio do atacante de forma a devolver as mensagens ao remetente e gerando, assim, os pacotes necessários ao ataque. As configurações de Firewalls e NATs devem ser verificadas de forma a preservarem o caráter randômico da porta de origem.
Fontes da Web com mais informações
X-Force Database & MSS GTOC AlertCom
http://www.iss.net/threats/298.html
https://webapp.iss.net/gtoc/index.html
http://blogs.iss.net/archive/dnsnat.html
Original Release
http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
Milw0rm Release
http://milw0rm.com/exploits/6122
Metasploit Framework email list archive
http://spool.metasploit.com/pipermail/framework/2008-July/date.html#3528
*List of vulnerable ISPs (older)
http://www.hackerfactor.com/blog/index.php?/archives/204-Poor-DNS.html
NANOG email list archive
The postings on the subject to this list are well worth reading.
http://www.merit.edu/mail.archives/nanog/index.html#09778
Media / Blogs
http://blogs.zdnet.com/security/?p=1545
http://blog.wired.com/27bstroke6/2008/07/dns-exploit-in.html
http://www.circleid.com/posts/87233_dns_attack_code_published/
http://it.slashdot.org/it/08/07/23/231254.shtml
http://www.informationweek.com/blog/main/archives/2008/07/dns_poisoning_v.html
Online DNS testers for testing if one's dns is vulnerable to exploitation
https://www.dns-oarc.net
http://www.doxpara.com
domingo, 3 de agosto de 2008
Uma nova fronteira para a segurança ?
Computadores cada vez mais potentes, links para Internet cada vez mais rápidos, redes wireless cada vez mais disponíveis e ... usuários cada vez mais vulneráveis. Deixando um pouco de lado o mundo da TI e segurança corporativa, creio que vale a pena refletir sobre o que está acontecendo em nossas casas, e principalmente no que ainda está por vir. Enquanto configurava meu novo playstation 3 para conexão wi-fi à minha rede doméstica e a partir dela a Internet, comecei a me questionar sobre a segurança daquele poderoso computador preto com gabinete futurista à minha frente (sim, o ps3 não é uma simples console de jogos mas um computador poderosíssimo). Os computadores que minha familia usa em casa estão bem protegidos por um personal firewall/IPS em estado paranóico e um Windows travado. Mas, e o ps3, quem o protege? Você pode estar pensando agora “mas quem iria invadir uma console de jogos eletrônicos? Para quê?”. Minha resposta é “por que não?”
Antes de prosseguir é bom lembrar que até o momento o ps3 se mostrou inviolável. Nenhum tentativa bem sucedida foi registrada até o momento, e a verdade é que o seu processador Cell Broadband Engine incorpora funcionalidades de segurança contra ataques que em outros hardware necessitam ser implementados por software. Para quem se interessar segue link de um artigo sobre o tema: http://www-128.ibm.com/developerworks/power/library/pa-cellsecurity.
Voltando à pergunta, por que alguém iria invadir uma console de games? A primeira possibilidade é a utilização do poder de processamento da console para uso em uma eventual rede bot. A segunda seria a busca por informações pessoais, como fotos nele armazenadas e dados pessoais para acesso ou compras via web. Uma rede de bots baseadas em consoles de jogos de última geração seria mais poderosa que uma rede similar baseada em computadores pessoais, e mais difícil de ser percebida. Mas nosso tema central não é a segurança do playstation 3 ou do Xbox 360, e sim a segurança das redes domésticas cada vez mais sofisticadas.
Atualmente a quase todalidade das residências de classe média no Brasil já possuem um computador, que como sabemos baixam de preço na mesmo proporção que ganham poder de processamento. Atualmente muitas famílias possuem mais que um computador, já que muitos pais trabalham com laptops e naturalmente o utilizam em casa, e filhos adolescentes estão ganhando seus próprios computadores para se relacionar, divertir e estudar. A quase totalidade dos lares de classe média acabam também possuindo um link de acesso rápido (e cada vez mais rápido) com a Internet. A equação N computadores para 1 link se resolve com uma rede, e a rede mais fácil hoje em dia para se instalar é uma rede wi-fi, não por coincidência também a cada ano mais potente e rápida.
Outros dispositivos estão rapidamente se conectando a essas redes, ainda não no Brasil, é verdade, mas por pura questão de tempo. Um tipo de equipamento com tudo para se tornar muito popular é set-top box conectado à Internet para download de filmes, como o Apple TV. Algumas pessoas estão também conectando sua TV a computadores pessoais, e estes, claro, conectados à rede sem-fio. Dispositivos de música como o novo modelo de Ipod também se conectam por wifi e assim vamos até chegar aos eletrodomésticos com acesso a Internet, como as geladeiras e micro-ondas, ainda caros e privilégio para poucos, mas como as TVs de LCD há alguns (poucos) anos atrás, hoje acessíveis para muitos. Em comum todos esses equipamentos eletrônicos e eletrodomésticos possuem computadores neles embutidos embutidos, com seus respectivos sistemas operacionais, os embedded operating systems.
Sistemas computacionais embutidos não são nenhuma novidade. Existem em nossos carros, em máquinas de café, em elevadores e por toda a parte. Agora, esses equipamentos em nossa casa conectados o tempo todo na Internet é outra estória. Essas redes residenciais são hoje, e continuarão a ser no futuro, geridas por pessoas sem a menor idéia de como protegê-las, até porque nem todo mundo é ou será especialista em informática. Imaginem uma dona de casa dizendo à vizinha que antes de sair precisa iniciar o download da última versão de sua geladeira! Parece piada, mas imaginem em um futuro próximo uma botnet baseada em milhões de geladeiras, realizando processamento para quebra de senhas ou ataques denial of service contra algum alvo. Pode ser futurista, mas não é nenhuma piada. Sistemas operacionais embutidos conectados à rede já são um problema de segurança em muitas empresas, principalmente porque não estão sujeitos aos mesmos controles que os computadores normais, embora possuam os mesmos tipos de acesso e as mesmas vulnerabilidades. Um problema real é o de um ataque denial of service que pode prejudicar ou retirar de funcionamento sistemas de elevadores, de telefonia ou, pior, equipamentos hospitalares. Além de não estarem sujeitos ao mesmos controles, muitos equipamentos nunca são atualizados, seja por falha de seus fabricantes ou de seus usuários. E muitos desses sistemas operacionais estão baseados em versões de sistemas operacionais comuns como o Linux, conhecidos e vulneráveis quando desatualizados.
Os usuários domésticos em muito breve estarão sujeitos aos mesmos desafios, porém com menos conhecimento e recursos que empresas. Será que daqui há cinco ou dez anos as pessoas estarão mais cientes dos riscos e saberão como se proteger? Eu aposto que não, porque nos últimos cinco anos a situação evoluiu muito pouco, enquanto a tecnologia e a conectividade a cada ano evoluem mais. Quando penso nisso me lembro de meu vizinho, que não conheço, com sua rede wi-fi de nome “default” e sempre disponível sem configuração nenhuma de segurança, aberta a todos, para deleite de alguns “espertos” que podem acessar a Internet sem pagar nada.
Antes de prosseguir é bom lembrar que até o momento o ps3 se mostrou inviolável. Nenhum tentativa bem sucedida foi registrada até o momento, e a verdade é que o seu processador Cell Broadband Engine incorpora funcionalidades de segurança contra ataques que em outros hardware necessitam ser implementados por software. Para quem se interessar segue link de um artigo sobre o tema: http://www-128.ibm.com/developerworks/power/library/pa-cellsecurity.
Voltando à pergunta, por que alguém iria invadir uma console de games? A primeira possibilidade é a utilização do poder de processamento da console para uso em uma eventual rede bot. A segunda seria a busca por informações pessoais, como fotos nele armazenadas e dados pessoais para acesso ou compras via web. Uma rede de bots baseadas em consoles de jogos de última geração seria mais poderosa que uma rede similar baseada em computadores pessoais, e mais difícil de ser percebida. Mas nosso tema central não é a segurança do playstation 3 ou do Xbox 360, e sim a segurança das redes domésticas cada vez mais sofisticadas.
Atualmente a quase todalidade das residências de classe média no Brasil já possuem um computador, que como sabemos baixam de preço na mesmo proporção que ganham poder de processamento. Atualmente muitas famílias possuem mais que um computador, já que muitos pais trabalham com laptops e naturalmente o utilizam em casa, e filhos adolescentes estão ganhando seus próprios computadores para se relacionar, divertir e estudar. A quase totalidade dos lares de classe média acabam também possuindo um link de acesso rápido (e cada vez mais rápido) com a Internet. A equação N computadores para 1 link se resolve com uma rede, e a rede mais fácil hoje em dia para se instalar é uma rede wi-fi, não por coincidência também a cada ano mais potente e rápida.
Outros dispositivos estão rapidamente se conectando a essas redes, ainda não no Brasil, é verdade, mas por pura questão de tempo. Um tipo de equipamento com tudo para se tornar muito popular é set-top box conectado à Internet para download de filmes, como o Apple TV. Algumas pessoas estão também conectando sua TV a computadores pessoais, e estes, claro, conectados à rede sem-fio. Dispositivos de música como o novo modelo de Ipod também se conectam por wifi e assim vamos até chegar aos eletrodomésticos com acesso a Internet, como as geladeiras e micro-ondas, ainda caros e privilégio para poucos, mas como as TVs de LCD há alguns (poucos) anos atrás, hoje acessíveis para muitos. Em comum todos esses equipamentos eletrônicos e eletrodomésticos possuem computadores neles embutidos embutidos, com seus respectivos sistemas operacionais, os embedded operating systems.
Sistemas computacionais embutidos não são nenhuma novidade. Existem em nossos carros, em máquinas de café, em elevadores e por toda a parte. Agora, esses equipamentos em nossa casa conectados o tempo todo na Internet é outra estória. Essas redes residenciais são hoje, e continuarão a ser no futuro, geridas por pessoas sem a menor idéia de como protegê-las, até porque nem todo mundo é ou será especialista em informática. Imaginem uma dona de casa dizendo à vizinha que antes de sair precisa iniciar o download da última versão de sua geladeira! Parece piada, mas imaginem em um futuro próximo uma botnet baseada em milhões de geladeiras, realizando processamento para quebra de senhas ou ataques denial of service contra algum alvo. Pode ser futurista, mas não é nenhuma piada. Sistemas operacionais embutidos conectados à rede já são um problema de segurança em muitas empresas, principalmente porque não estão sujeitos aos mesmos controles que os computadores normais, embora possuam os mesmos tipos de acesso e as mesmas vulnerabilidades. Um problema real é o de um ataque denial of service que pode prejudicar ou retirar de funcionamento sistemas de elevadores, de telefonia ou, pior, equipamentos hospitalares. Além de não estarem sujeitos ao mesmos controles, muitos equipamentos nunca são atualizados, seja por falha de seus fabricantes ou de seus usuários. E muitos desses sistemas operacionais estão baseados em versões de sistemas operacionais comuns como o Linux, conhecidos e vulneráveis quando desatualizados.
Os usuários domésticos em muito breve estarão sujeitos aos mesmos desafios, porém com menos conhecimento e recursos que empresas. Será que daqui há cinco ou dez anos as pessoas estarão mais cientes dos riscos e saberão como se proteger? Eu aposto que não, porque nos últimos cinco anos a situação evoluiu muito pouco, enquanto a tecnologia e a conectividade a cada ano evoluem mais. Quando penso nisso me lembro de meu vizinho, que não conheço, com sua rede wi-fi de nome “default” e sempre disponível sem configuração nenhuma de segurança, aberta a todos, para deleite de alguns “espertos” que podem acessar a Internet sem pagar nada.
quinta-feira, 5 de junho de 2008
Invasão de Rede. Preparando-se para o pior.
Todos nós sabemos que nenhuma rede é inexpugnável, mesmo quando todas as boas práticas são seguidas e os dispositivos de segurança necessários estão instalados. Seja por alguma técnica ou método novo de ataque, ou por autoria ou conivência de pessoa interna, sempre existe a possibilidade de uma tentativa de invasão ser bem sucedida. Nesses casos, o que fazer?
Bem, antes de falar sobre o que fazer em uma situação de invasão é necessário pensar sobre o que deve ser feito antes. Sim, as atividades de resposta a emergências começam bem antes da invasão, e não tem a ver com as medidas aplicadas para preveni-la. Além de proteger sua rede, a empresa precisa também criar um plano e preparar-se para agir em caso de invasão. Se tudo der certo esse plano nunca sairá do papel, no entanto, se algo der errado a empresa irá se arrepender de não tê-lo feito. Abaixo estão listadas quatro medidas que julgo essenciais em qualquer plano, e que irão ajudar muito a controlar e reduzir os efeitos de uma invasão.
O ponto de partida é o estabelecimento de um time, idealmente composto de representantes das áreas de rede, servidores, sistemas aplicativos, negócios e segurança. Muitas vezes essas pessoas já são conhecidos por todos na empresa e possuem até uma relação pessoal, reduzindo a necessidade de formalização. Mas em empresas maiores é necessário formalizar um time, mantendo um pequeno cadastro com o nome e informações de contato. Já vi empresas perderem muito tempo apenas na tarefa de encontrar as pessoas chave que devem ser envolvidas. Uma empresa mais organizada teria também alguns procedimentos estabelecidos e o time treinado nesses procedimentos, além do time técnico com conhecimento mínimo de resposta a emergências, mesmo quando há contrato com um provedor externo, a fim de realizar as primeiras ações de reação ao ataque. É algo similar a uma brigada interna de incêndio, responsável pelo combate inicial ao fogo até a chegada dos bombeiros.
Em uma situação de emergência, uma das primeiras coisas que um especialista solicita é o mapa da rede, contendo não só diagramas atualizados de conexão física e lógica como serviços, protocolos e portas utilizadas, de preferência por servidor; além de regras de acesso configuradas em roteadores, firewalls, IPS e quaisquer outros dispositivos que permitam a definição de acesso. Sem esse mapa é quase impossível identificar o método usado em uma invasão e estabelecer medidas para conter ou rastrear o invasor. Manter este mapa atualizado é uma questão de prioridade e disciplina, porém é muito dificil depois de uma invasão correr atrás do prejuizo e tentar documentar a rede. O mapa também deverá ter a informação do nível de criticidade para o negócio da empresa de cada servidor ou grupo de servidores, além de outros dispositivos críticos de negócio.
Em relação aos serviços habilitados em um servidor, é essencial saber quais estavam habilitados antes da invasão. Não há muita valia listar os serviços disponiveis depois do servidor ter sido comprometido. Imaginem a situação de um servidor que possui apenas o serviço HTTP habilitado, e que ao ser invadido via porta 80 tem o serviço SSH habilitado pelo invasor para que este possa então controlá-lo remotamente. Uma avaliação do servidor após o ataque irá identificar o SSH como o serviço utilizado para a invasão, e assim este será desativado dando a falsa sensação de se ter bloqueado o acesso do hacker. No entanto, como a invasão ocorreu originalmente via HTTP, o invasor poderá novamente invadir via HTTP e reativar o SSH. Saber que antes da invasão só havia a porta HTTP ativada significa identificar corretamente como a invasão ocorreu e reagir eficientemente.
As ações em uma situação de ataque em andamento são distintas das ações de um ataque já realizado, porém em ambas fará uma grande diferença a existência de logs de aplicação, servidores e rede. E organizar um sistema de logs é também uma atividade prévia. Há dois elementos principais quando falamos de logs: sincronização de horários e centralização. A rastreabilidade de um ataque dependerá em muito da existência de logs em sistemas diferentes que possam ser correlacionados. Traços do ataque podem estar registrados nos logs de rede, dispositivos de segurança e nos servidores, e para correlacionar esses logs é indispensável que todos estejam compartilhando o mesmo horário. É uma tarefa hoje simples porém deixado de lado em muitas empresas. Centralizar logs é mais complexo, mas nem por isso deve ser negligenciado. A centralização evita que um invasor manipule, corrompa ou apague os logs; além de facilitar o trabalho de análise em uma eventual investigação. Hoje em dia há soluções de centralização que se encaixam bem em orçamentos de todos os tamanhos.
A quarta e última recomendação diz respeito a padronização. Padronização é bom em qualquer situação, já que reduz custos e complexidade, mas é muito importante na resposta a emergências. Um ambiente sem padronização significa um ambiente no qual a seleção e configuração de sistemas está descentralizada e até nas mãos dos usuários finais, e provavelmente não documentada, o que facilita em muito a ação de um hacker. Também ações de remediação são mais fáceis quando atingem todos os sistemas, e não apenas um ou outro. Imaginem uma empresa na qual os usuários e analistas tem liberdade para escolher o sistema operacional de suas máquinas, e na qual um hacker se estabeleceu dominando várias dessas máquinas. Mesmo o uso de Linux deve ser padronizado em distribuição e versão.
Para empresas que estão mais avançadas em sua preparação, eu também recomendo duas ações adicionais. A primeira é utilizar regularmente ferramentas de identificação de vulnerabilidades. Além de ser uma boa ação preventiva, saber quais são as vulnerabilidades de um sistema agiliza muito a identificação do método de ataque. Outra sugestão é o uso regular de ferramentas de análise de rede, como os analisadores de protocolo e detectores de anomalia. Essas ferramentas são de grande valia na hora de rastrear um invasor ou identificar a extensão de um ataque. Como exemplo, o detector de anomalias terá o mapa de todas as sessões de rede estabelecidas por um servidor, além de protocolos e portas usadas. Uma simples consulta às informações do detector de anomalias e à documentação da rede pode ser a diferença entre ter ou não a segurança da rede, sistemas e dados reabilitada.
Bem, antes de falar sobre o que fazer em uma situação de invasão é necessário pensar sobre o que deve ser feito antes. Sim, as atividades de resposta a emergências começam bem antes da invasão, e não tem a ver com as medidas aplicadas para preveni-la. Além de proteger sua rede, a empresa precisa também criar um plano e preparar-se para agir em caso de invasão. Se tudo der certo esse plano nunca sairá do papel, no entanto, se algo der errado a empresa irá se arrepender de não tê-lo feito. Abaixo estão listadas quatro medidas que julgo essenciais em qualquer plano, e que irão ajudar muito a controlar e reduzir os efeitos de uma invasão.
O ponto de partida é o estabelecimento de um time, idealmente composto de representantes das áreas de rede, servidores, sistemas aplicativos, negócios e segurança. Muitas vezes essas pessoas já são conhecidos por todos na empresa e possuem até uma relação pessoal, reduzindo a necessidade de formalização. Mas em empresas maiores é necessário formalizar um time, mantendo um pequeno cadastro com o nome e informações de contato. Já vi empresas perderem muito tempo apenas na tarefa de encontrar as pessoas chave que devem ser envolvidas. Uma empresa mais organizada teria também alguns procedimentos estabelecidos e o time treinado nesses procedimentos, além do time técnico com conhecimento mínimo de resposta a emergências, mesmo quando há contrato com um provedor externo, a fim de realizar as primeiras ações de reação ao ataque. É algo similar a uma brigada interna de incêndio, responsável pelo combate inicial ao fogo até a chegada dos bombeiros.
Em uma situação de emergência, uma das primeiras coisas que um especialista solicita é o mapa da rede, contendo não só diagramas atualizados de conexão física e lógica como serviços, protocolos e portas utilizadas, de preferência por servidor; além de regras de acesso configuradas em roteadores, firewalls, IPS e quaisquer outros dispositivos que permitam a definição de acesso. Sem esse mapa é quase impossível identificar o método usado em uma invasão e estabelecer medidas para conter ou rastrear o invasor. Manter este mapa atualizado é uma questão de prioridade e disciplina, porém é muito dificil depois de uma invasão correr atrás do prejuizo e tentar documentar a rede. O mapa também deverá ter a informação do nível de criticidade para o negócio da empresa de cada servidor ou grupo de servidores, além de outros dispositivos críticos de negócio.
Em relação aos serviços habilitados em um servidor, é essencial saber quais estavam habilitados antes da invasão. Não há muita valia listar os serviços disponiveis depois do servidor ter sido comprometido. Imaginem a situação de um servidor que possui apenas o serviço HTTP habilitado, e que ao ser invadido via porta 80 tem o serviço SSH habilitado pelo invasor para que este possa então controlá-lo remotamente. Uma avaliação do servidor após o ataque irá identificar o SSH como o serviço utilizado para a invasão, e assim este será desativado dando a falsa sensação de se ter bloqueado o acesso do hacker. No entanto, como a invasão ocorreu originalmente via HTTP, o invasor poderá novamente invadir via HTTP e reativar o SSH. Saber que antes da invasão só havia a porta HTTP ativada significa identificar corretamente como a invasão ocorreu e reagir eficientemente.
As ações em uma situação de ataque em andamento são distintas das ações de um ataque já realizado, porém em ambas fará uma grande diferença a existência de logs de aplicação, servidores e rede. E organizar um sistema de logs é também uma atividade prévia. Há dois elementos principais quando falamos de logs: sincronização de horários e centralização. A rastreabilidade de um ataque dependerá em muito da existência de logs em sistemas diferentes que possam ser correlacionados. Traços do ataque podem estar registrados nos logs de rede, dispositivos de segurança e nos servidores, e para correlacionar esses logs é indispensável que todos estejam compartilhando o mesmo horário. É uma tarefa hoje simples porém deixado de lado em muitas empresas. Centralizar logs é mais complexo, mas nem por isso deve ser negligenciado. A centralização evita que um invasor manipule, corrompa ou apague os logs; além de facilitar o trabalho de análise em uma eventual investigação. Hoje em dia há soluções de centralização que se encaixam bem em orçamentos de todos os tamanhos.
A quarta e última recomendação diz respeito a padronização. Padronização é bom em qualquer situação, já que reduz custos e complexidade, mas é muito importante na resposta a emergências. Um ambiente sem padronização significa um ambiente no qual a seleção e configuração de sistemas está descentralizada e até nas mãos dos usuários finais, e provavelmente não documentada, o que facilita em muito a ação de um hacker. Também ações de remediação são mais fáceis quando atingem todos os sistemas, e não apenas um ou outro. Imaginem uma empresa na qual os usuários e analistas tem liberdade para escolher o sistema operacional de suas máquinas, e na qual um hacker se estabeleceu dominando várias dessas máquinas. Mesmo o uso de Linux deve ser padronizado em distribuição e versão.
Para empresas que estão mais avançadas em sua preparação, eu também recomendo duas ações adicionais. A primeira é utilizar regularmente ferramentas de identificação de vulnerabilidades. Além de ser uma boa ação preventiva, saber quais são as vulnerabilidades de um sistema agiliza muito a identificação do método de ataque. Outra sugestão é o uso regular de ferramentas de análise de rede, como os analisadores de protocolo e detectores de anomalia. Essas ferramentas são de grande valia na hora de rastrear um invasor ou identificar a extensão de um ataque. Como exemplo, o detector de anomalias terá o mapa de todas as sessões de rede estabelecidas por um servidor, além de protocolos e portas usadas. Uma simples consulta às informações do detector de anomalias e à documentação da rede pode ser a diferença entre ter ou não a segurança da rede, sistemas e dados reabilitada.
quinta-feira, 15 de maio de 2008
PCI-DSS e os Requerimentos para Segurança de Rede
Um tema que vem sendo cada vez mais discutido é o do padrão de segurança para empresas de cartão de crédito, o PCI-DSS, ou Payment Card Industry Data Security Standards. O PCI-DSS foi criado pelas cinco maiores bandeiras de cartões de pagamento do mundo: Visa, American Express, MasterCard, Discover e JCB International, visando o aperfeiçoamento das condições de segurança dos dados de cartão de crédito. O padrão é mantido pelo PCI Security Standards Council (https://www.pcisecuritystandards.org/), entidade criada pelas cinco empresas citadas acima justamente para esse fim.
O objetivo das cinco bandeiras de cartão é fazer com que todas as empresas que armazenam, usam, transmitam ou processam dados de cartão de crédito implementem o padrão de segurança. Esperam dessa forma acabar com casos como o da TJX, holding das lojas TJMAX e Marshalls, bastante populares nos Estados Unidos. Pois a TJX anunciou em janeiro de 2007 que mais de 45 milhões de dados de cartões de crédito foram roubados de seus sistemas, gerando enormes prejuizos. A não adoção do padrão pode levar a penalidades contratuais.
Para garantir a adoção, o PCI Council criou uma programa certificação anual, que inclui processos de auditoria, auto-avaliação e testes remotos, dependendo do volume de transações e papel da empresa no sistema de pagamentos por cartões. Estão obrigados a certificar-se os chamados acquirers banks (que administram o relacionamento com os estabelecimentos comerciais), bancos emissores, processadoras, provedores de serviço e o comércio em geral. O prazo para certificação no Brasil expira em 2009 e atinge as bandeiras Visa, Mastercard e American Express, já que a Discover e JCB não estão presentes no país.
O padrão de segurança, portanto, chegará cedo ou tarde às áreas de TI das empresas afetadas. O PCI-DSS é composto de doze requerimentos globais, que listam boas práticas para a transmissão, processamento e armezenamento dos dados de cartões de pagamento. Uma leitura atenta revela que todos os requerimentos são práticas que deveriam ser adotadas por todos, independente de obrigação, o que infelizmente não acontece, permitindo casos como o da TJX.
E quão dificil é tornar uma rede aderente ao PCI-DSS ? O que precisa ser mudado? Encontramos a maior parte das exigências para redes nos requerimentos de número 1 e 2, embora outros também as contenham.
O requerimento 1 – “Instalar e manter uma configuração de firewall para proteger dados dos usuários de cartão” – exige a instalação de sistemas de firewall cujas configurações sejam periodicamente testadas e restrinjam o acesso de redes e hosts não confiáveis, exceto os protocolos necessários para a operação da empresa, além de restringir por meios de DMZ as conexões entre servidores acessíveis publicamente e os servidores que armazenam dados de usuários de cartão, não permitir acesso direto entre redes externas e dispositivos que armazenam dados de cartão e a utilização de mascaramento de IPs e portas (NAT e PAT). O requerimento solicita ainda o uso de firewalls entre redes cabeadas e redes wireless e uso de personal firewalls em qualquer computador móvel ou de propriedade de funcionários que tenha acesso direto à Internet.
Na parte de administração estão exigências de documentação de rede, incluindo redes wireless, documentação das funções e responsabilidades da administração de rede, segregação de funções, documentação dos protocolos, serviços e portas necessários habilitados, e justificativa dos serviços autorizados além de HTTP, SSL, SSH e VPN e a revisão trimestral das configurações de routers e firewalls.
O requerimento 2 – “Não usar defaults para senhas de sistemas e outros parâmetros de segurança” – parece ser auto-explicativo. Em especial eles reforçam a configuração de redes wireless sem os defaults que muitos ainda teimam em deixar, a implementação de uma função primária por servidor e uso de criptografia para todo o acesso administrativo remoto, usando SSH por exemplo, além de outras boas práticas relacionadas a configuração de dispositivos. Podemos resumir estem requerimento como “troquem tudo que vem pré-definido pelo fabricante”. Há no item uma observação para as empresas que utilizam empresas de hosting para armazenar seus serviços.
As próximas exigências que se aplicam a redes estão no requerimento 4 – “Criptografar a transmissão de dados de usuários de cartão através de redes públicas e abertas”. Assim temos as exigências de uso de protocolos como SSL, TLS e IPSEC além de cuidados com a configuração de redes wireless, para as quais é recomendado o uso do WPA ou WPA2. O WEP é permitido, porém com uma série de recomendações. O requerimento 4 ainda traz alertas sobre o uso de correio eletrônico para envio de dados sem criptografia. Parece bobagem mas há ainda empresas que fazem tudo certo porém no final transmitem dados confidenciais via FTP ou correio eletrônico, em arquivos abertos de texto ou planilha.
Depois temos o requerimento 6 – “Desenvolver e manter sistemas e aplicações seguros”. Embora aqui o foco não seja dispositivos de redes, há instruções para processos de identificar e corrigir vulnerabilidades, além de processos de controle de mudanças que se aplicam a sistemas de redes. No requerimento 10 – “Rastrear e monitorar todo o acesso a recursos de rede e dados de usuários de cartão”, temos as exigências para coleta e manutenção do logs, além das medidas para proteger os próprios logs. Como exemplo das instruções está a da sincronização de relógios e horários.
Por fim, em se tratando de requerimentos para redes, temos o requerimento 11 – “Regularmente testar processos e sistemas de segurança”. Os principais ponto deste requerimento são as exigência de testes trimestrais internos e externos de vulnerabilidade testes periódicos de redes wireless contra dispositivos desconhecidos conectados, testes anuais de invasão e testes também anuais que possam aferir a capacidade de identificar e parar ataques. O requerimento deixa claro que esses testes também devem ser realizados após qualquer mudança significativa na rede. O requerimento ainda descreve a necessidade de se utilizar sistemas de detecção e prevenção de intrusos (IDS / IPS) em redes e também em servidores e computadores críticos (host-based IDS).
Por mais que os requerimentos acima pareçam óbvios, e talvez o sejam, os recorrentes vazamentos de dados de cartão de crédito mostram que as empresas ainda pecam em um ou outro item. Meu palpite é que os vazamentos ocorrem nos detalhes, como uma planilha aberta sendo enviada por email, um CD sem criptografia extraviado, um firewall não revisado com o passar do tempo, uma rede wireless instalada por um funcionário sem conhecimento da área de TI. Um detalhe pode passar desapercebido pelos administradores de rede e sistemas, mas com certeza não o será pelos criminosos de plantão.
O objetivo das cinco bandeiras de cartão é fazer com que todas as empresas que armazenam, usam, transmitam ou processam dados de cartão de crédito implementem o padrão de segurança. Esperam dessa forma acabar com casos como o da TJX, holding das lojas TJMAX e Marshalls, bastante populares nos Estados Unidos. Pois a TJX anunciou em janeiro de 2007 que mais de 45 milhões de dados de cartões de crédito foram roubados de seus sistemas, gerando enormes prejuizos. A não adoção do padrão pode levar a penalidades contratuais.
Para garantir a adoção, o PCI Council criou uma programa certificação anual, que inclui processos de auditoria, auto-avaliação e testes remotos, dependendo do volume de transações e papel da empresa no sistema de pagamentos por cartões. Estão obrigados a certificar-se os chamados acquirers banks (que administram o relacionamento com os estabelecimentos comerciais), bancos emissores, processadoras, provedores de serviço e o comércio em geral. O prazo para certificação no Brasil expira em 2009 e atinge as bandeiras Visa, Mastercard e American Express, já que a Discover e JCB não estão presentes no país.
O padrão de segurança, portanto, chegará cedo ou tarde às áreas de TI das empresas afetadas. O PCI-DSS é composto de doze requerimentos globais, que listam boas práticas para a transmissão, processamento e armezenamento dos dados de cartões de pagamento. Uma leitura atenta revela que todos os requerimentos são práticas que deveriam ser adotadas por todos, independente de obrigação, o que infelizmente não acontece, permitindo casos como o da TJX.
E quão dificil é tornar uma rede aderente ao PCI-DSS ? O que precisa ser mudado? Encontramos a maior parte das exigências para redes nos requerimentos de número 1 e 2, embora outros também as contenham.
O requerimento 1 – “Instalar e manter uma configuração de firewall para proteger dados dos usuários de cartão” – exige a instalação de sistemas de firewall cujas configurações sejam periodicamente testadas e restrinjam o acesso de redes e hosts não confiáveis, exceto os protocolos necessários para a operação da empresa, além de restringir por meios de DMZ as conexões entre servidores acessíveis publicamente e os servidores que armazenam dados de usuários de cartão, não permitir acesso direto entre redes externas e dispositivos que armazenam dados de cartão e a utilização de mascaramento de IPs e portas (NAT e PAT). O requerimento solicita ainda o uso de firewalls entre redes cabeadas e redes wireless e uso de personal firewalls em qualquer computador móvel ou de propriedade de funcionários que tenha acesso direto à Internet.
Na parte de administração estão exigências de documentação de rede, incluindo redes wireless, documentação das funções e responsabilidades da administração de rede, segregação de funções, documentação dos protocolos, serviços e portas necessários habilitados, e justificativa dos serviços autorizados além de HTTP, SSL, SSH e VPN e a revisão trimestral das configurações de routers e firewalls.
O requerimento 2 – “Não usar defaults para senhas de sistemas e outros parâmetros de segurança” – parece ser auto-explicativo. Em especial eles reforçam a configuração de redes wireless sem os defaults que muitos ainda teimam em deixar, a implementação de uma função primária por servidor e uso de criptografia para todo o acesso administrativo remoto, usando SSH por exemplo, além de outras boas práticas relacionadas a configuração de dispositivos. Podemos resumir estem requerimento como “troquem tudo que vem pré-definido pelo fabricante”. Há no item uma observação para as empresas que utilizam empresas de hosting para armazenar seus serviços.
As próximas exigências que se aplicam a redes estão no requerimento 4 – “Criptografar a transmissão de dados de usuários de cartão através de redes públicas e abertas”. Assim temos as exigências de uso de protocolos como SSL, TLS e IPSEC além de cuidados com a configuração de redes wireless, para as quais é recomendado o uso do WPA ou WPA2. O WEP é permitido, porém com uma série de recomendações. O requerimento 4 ainda traz alertas sobre o uso de correio eletrônico para envio de dados sem criptografia. Parece bobagem mas há ainda empresas que fazem tudo certo porém no final transmitem dados confidenciais via FTP ou correio eletrônico, em arquivos abertos de texto ou planilha.
Depois temos o requerimento 6 – “Desenvolver e manter sistemas e aplicações seguros”. Embora aqui o foco não seja dispositivos de redes, há instruções para processos de identificar e corrigir vulnerabilidades, além de processos de controle de mudanças que se aplicam a sistemas de redes. No requerimento 10 – “Rastrear e monitorar todo o acesso a recursos de rede e dados de usuários de cartão”, temos as exigências para coleta e manutenção do logs, além das medidas para proteger os próprios logs. Como exemplo das instruções está a da sincronização de relógios e horários.
Por fim, em se tratando de requerimentos para redes, temos o requerimento 11 – “Regularmente testar processos e sistemas de segurança”. Os principais ponto deste requerimento são as exigência de testes trimestrais internos e externos de vulnerabilidade testes periódicos de redes wireless contra dispositivos desconhecidos conectados, testes anuais de invasão e testes também anuais que possam aferir a capacidade de identificar e parar ataques. O requerimento deixa claro que esses testes também devem ser realizados após qualquer mudança significativa na rede. O requerimento ainda descreve a necessidade de se utilizar sistemas de detecção e prevenção de intrusos (IDS / IPS) em redes e também em servidores e computadores críticos (host-based IDS).
Por mais que os requerimentos acima pareçam óbvios, e talvez o sejam, os recorrentes vazamentos de dados de cartão de crédito mostram que as empresas ainda pecam em um ou outro item. Meu palpite é que os vazamentos ocorrem nos detalhes, como uma planilha aberta sendo enviada por email, um CD sem criptografia extraviado, um firewall não revisado com o passar do tempo, uma rede wireless instalada por um funcionário sem conhecimento da área de TI. Um detalhe pode passar desapercebido pelos administradores de rede e sistemas, mas com certeza não o será pelos criminosos de plantão.
segunda-feira, 24 de março de 2008
O longo caminho para o PCI
Os dois próximos anos serão os anos da implementação da certificação PCI-DSS no Brasil, destinada a aperfeiçoar a segurança das compras via cartões de pagamento e reduzir as perdas por fraude. Mas o caminho será longo. Um bom exemplo é o procedimento de compra dos passaportes de acesso a um parque de diversões em São Paulo. O processo realizado via Internet é fácil, tranquilo e seguro; e os dados não são coletados ou armazenados em nenhum momento pelo Parque. Mas o problema começa após a compra!
Para entrar no parque os clientes que fizeram a compra via Internet são obrigados a preencher e assinar um formulário com nome, documento de identidade, número do cartão de crédito, bandeira e data de validade. Esse formulário, completamente inútil já que a cobrança é automática no ato da transação via Internet, é então empilhado no guichê de entrada do parque, e depois recolhido, manuseado e visto por deus sabe lá quem.
E assim temos o absurdo da situação. O parque de diversões não armazena os dados de cartão de crédito em seus servidores, mas o faz em papel, da maneira mais vulnerável possível e ainda assinados, facilitando, em muito, o trabalho dos fraudadores!
Para entrar no parque os clientes que fizeram a compra via Internet são obrigados a preencher e assinar um formulário com nome, documento de identidade, número do cartão de crédito, bandeira e data de validade. Esse formulário, completamente inútil já que a cobrança é automática no ato da transação via Internet, é então empilhado no guichê de entrada do parque, e depois recolhido, manuseado e visto por deus sabe lá quem.
E assim temos o absurdo da situação. O parque de diversões não armazena os dados de cartão de crédito em seus servidores, mas o faz em papel, da maneira mais vulnerável possível e ainda assinados, facilitando, em muito, o trabalho dos fraudadores!
terça-feira, 18 de março de 2008
Data Loss Prevention
O modelo de proteção digital adotado pela indústria é hoje fortemente baseado no conceito de defesa em profundidade, no qual tecnologias são distribuidas ao longo da rede, servidores e estações a fim de impedir que pessoas não autorizadas tenham acesso à rede, servidores, aplicações e dados; e que aquelas autorizadas tenham acesso somente ao que deveriam acessar. É o que os americanos chamam de “bad guy out, good guy in”. No centro e no final de tudo está, ou deveria estar, o dado, a informação, aquela cuja confidencialidade, integridade e disponibilidade devem ser garantidas.
Não há nada de errado no modelo acima, salvo que no fundo ninguém tem certeza se o dado, a informação, a proteger está realmente protegido pelo arsenal de tecnologias e produtos instalados. Não que as tecnologias sejam incapazes de proteger o dado de novas técnicas e métodos de ataque. Elas são, mas a questão é outra. Quem disse que o dado a proteger está realmente intocado no disco rígido de um servidor e que não irá vazar via o correio eletrônico ou um dispositivo USB qualquer?
O problema é que a vida real é complicada. E cada vez se complica mais. Os novos ambientes de negócio estão exigindo teias de compartilhamento cada vez mais complexas. A fronteira entre o usuário externo e interno está cada vez mais cinzenta com as tecnologias de acesso remoto e o crescimento e facilitação do trabalho a partir de casa ou em viagem. O trabalho remoto exige que o funcionário, mesmo quilômetros e quilômetros de distância, trabalhe como se estivesse sentado em sua mesa de trabalho, caso ainda tenha uma em sua empresa. Podemos ainda incluir a integração cada vez mais necessária e real entre empresas clientes, fornecedoras e parceiras, aliado às novas tecnologias móveis, aos novos recursos de negócios na Internet, às novas possibilidades de interação com clientes e empregados, às soluções inovadoras como VoIP e virtualização (para citar apenas duas).
Tudo isso trouxe para a mesa de discussão uma nova abordagem para a segurança de dados, focada justamente no dado ou na informação. Como tudo novo, ainda há muitos nomes. Alguns chamam de data loss prevention (prevenção de perda de dados) ou DLP, já que gostamos muito de siglas. Outros usam a sigla DLP, mas com uma pequena diferença: Data Leakage Prevention (prevenção de vazamento de dados). Há ainda uma corrente chamando isso de data-centric security (segurança centrada em dados). Em todos eles a discussão é a mesma: como proteger os dados de problemas vindos de dentro ou de fora, armazenados ou “em viagem”, em servidores centrais ou em computadores pessoais.
O grande desafio é que o DLP usa mas não se resume a tecnologias. É um processo. O início está em responder e entender quais são realmente os dados a proteger. Quais dados, caso percam sua confidencialidade, integridade ou disponibilidade irão me trazer prejuizos ou irão quebrar algum contrato ou regulamento de negócios? Onde estão esses dados? Estão armazenados em servidores ou em estações? Estão sendo transmitidos por onde? Estão viajando em notebooks? Como classificar e manter a classificação dos dados? Como compartilhar a informação com segurança? Como eliminar os dados quando não mais precisar deles?
Alguém que conheça as normas de segurança perguntaria “qual a novidade nisso?”. Realmente as perguntas acima estão mesmo na primeira versão da norma britânica BS7799 ainda na década de 80, que deu origem a ISO/IEC 17799 e a versão atual na ISO 27000. Muitas empresas se preocupam há anos com esse tema e possuem políticas de segurança da informação que tratam a questão da segurança do dado ou da informação. Qual a diferença? Não seria isto algo requentado, e pior, vendido como se fosse algo novo? Ou será que as pessoas (leia-se empresas) que não fizeram o que que deveriam ter feito estão agora se mexendo?
Para as questões acima eu coloco duas questões chaves que trouxeram o DLP para o centro da discussão:
(1) Como eu já comentei, o aumento da complexidade no uso e compartilhamento da informação. Está muito complicado controlar o acesso à informação ao mesmo tempo que as regulações – sejam governamentais ou de mercado (como o PCI-DSS para o mercado de cartões de crédito) – aumentam as exigências para que tal controle seja eficiente e demonstrável. Esse aumento da complexidade aumentou a demanda por tecnologias.
(2) O amadurecimento, aperfeiçoamento ou mesmo surgimento de tecnologias e produtos para auxiliar o controle e proteção dos dados. Exemplos dessas tecnologias estão em produtos para controle do uso de portas USB, controle de acesso a redes sem-fio, análise de conteúdo em emails e tráfego de rede a procura de dados confidenciais, entre muitos outros exemplos.
Um outro desafio é a nossa capacidade (de quem vende e de quem compra soluções) em reduzir tudo a tecnologias ou produtos. É o típico caso de uma empresa que compra um determinado produto classificado como DLP e acha que resolveu o problema (estejam certo que muitos e muitos produtos virão agora com a tarja “DLP”). Data Loss Prevention não é, e nunca será, um projeto de instalação de software. É um processo constante de conhecer, classificar, proteger e monitorar os dados, estejam eles onde estiverem. Indo mais além, é necessário um alto nível de customização para cada empresa, já que os dados tem a ver com o negócio de cada empresa. Muda a empresa, muda como os dados nela serão tratados.
Então como começar? O primeiro passo é abrir aquele velho livrinho empoeirado com o título “Política de Segurança da Informação”. Se este não existir ou estiver muito velho e desatualizado, seria o caso de abrir outro livro: a ISO/IEC 17799-1 ou ISO/IEC 27002. As normas podem ser adquiridas em português na ABNT (www.abnt.org.br). Mas não se pode cair na armadilha, comum no passado, de tentar criar uma política de segurança “completa”. Tem que ser algo simples, que todo mundo entenda. As normas darão as informações necessárias e servirão como guia para alcançar os objetivos.
Se a empresa possui e usa sua política de segurança, então estamos no segundo passo, que é a implementação de soluções, caso sejam necessárias. Quanto mais a empresa estiver avançada em termos de conscientização e aplicação da política, mais fácil será essa fase. Mesmo assim não podemos esquecer que o DLP não protege a infraestrutura. Indo mais além, ele não está preocupado com a infraestrutura, embora esta ainda necessite ser protegida. A preocupação está no dado que viaje e descansa dentro da infraestrutura, e durante o seu ciclo de vida.
A maior vantagem do DLP é a aproximação das equipes de proteção com as áreas de negócio. Executivos de negócio não conhecem, ou pelo menos não precisam conhecer, redes e TI. Eles não estão interessados se a rede está protegida ou não, e sim seu o seu negócio, se o seu dado – seja ele qual for – está protegido ou não.
quinta-feira, 21 de fevereiro de 2008
Phishing
A “Executivos Financeiros” publicou em 15/2 o resultado de uma pesquisa da F-Secure que indica o Brasil é o maior alvo de cavalos-de-tróia em sites bancários do mundo. De acordo com a pesquisa, 30,7% dos bancos com clientes infectados por trojans em todo o mundo são brasileiros, seguido pelos Estados Unidos, com 16,9% e pelo Reino Unido, com 13,8%. Além disso, os cavalos-de-tróia brasileiros seriam personalizados para alguns bancos, enquanto que em outros países esses seriam genéricos.
Os ataques ocorrem através do phishing, a técnica de enviar emails fraudulentos com cavalos-de-tróia anexados ou para fazer com que a pessoa acesse um site fraudulento de seu banco. O phishing é realmente o maior problema para os bancos atualmente por atingir o elo mais fraco da segurança bancária: o cliente. No Brasil o phishing é um problema antigo, tanto que evoluiu para os programas personalizados que a pesquisa se refere. Os tipos antigos – genéricos - simplesmente não tem mais eficiência contra os bancos brasileiros.
A análise do histórico de phishing no Brasil serve com um bom parâmetro para a evolução das ameaças na Internet e das tecnologias de proteção. Hoje, contra os tipos de ameaças que os bancos no Brasil estão sujeitos, soluções genéricas e pontuais também não funcionam. O mercado de segurança está hoje em um momento de transição, do modelo baseado em soluções pontuais e genéricas para o modelo baseado em uma visão mais ampla, mais integrado e mais personalizado, ou seja, com uma camada cada vez maior de serviços.
Os ataques ocorrem através do phishing, a técnica de enviar emails fraudulentos com cavalos-de-tróia anexados ou para fazer com que a pessoa acesse um site fraudulento de seu banco. O phishing é realmente o maior problema para os bancos atualmente por atingir o elo mais fraco da segurança bancária: o cliente. No Brasil o phishing é um problema antigo, tanto que evoluiu para os programas personalizados que a pesquisa se refere. Os tipos antigos – genéricos - simplesmente não tem mais eficiência contra os bancos brasileiros.
A análise do histórico de phishing no Brasil serve com um bom parâmetro para a evolução das ameaças na Internet e das tecnologias de proteção. Hoje, contra os tipos de ameaças que os bancos no Brasil estão sujeitos, soluções genéricas e pontuais também não funcionam. O mercado de segurança está hoje em um momento de transição, do modelo baseado em soluções pontuais e genéricas para o modelo baseado em uma visão mais ampla, mais integrado e mais personalizado, ou seja, com uma camada cada vez maior de serviços.
terça-feira, 12 de fevereiro de 2008
Green Security
Dentre as muitas tendências da Tecnologia da Informação, GreenIT, ou TI Verde, aparece como uma das mais promissoras a ocupar a agenda dos CIOs. GreenIT é sinônimo de redução do consumo de energia pela infraestrutura de TI, principalmente datacenters, e a discussão vem ganhando corpo. Ao se olhar alguns dados pesquisados é fácil ver onde está a justificativa: de acordo com cientistas do Lawrence Berkeley National Laboratory, um CPD típico de 3 mil metros quadrados consome mais eletricidade que 8.000 lâmpadas de 60 watt, o que representa de 6 a 10 vezes a energia necessária para um edifício de escritórios típico em seu horário de pico. Essa incrível demanda de energia cresce não só pelo consumo de energia dos servidores mas também porque os novos servidores, cada vez mais adensados, liberam mais calor, exigindo também mais capacidade de refrigeração. Hoje a energia consumida pelos componentes de refrigeração responde de 60 a 70% da energia total consumida em um CPD.
Uma leitura atenta do parágrafo anterior revela o que será na verdade o grande motivador para que empresas de todos os setores e tamanhos, conscientes ou não da questão ambiental, coloquem o tema em sua lista de prioridades: custos. A cada ano o modelo atual de centro de processamento de dados torna-se mais caro; basicamente por dois motivos relacionados entre si: o aumento do consumo de energia e o aumento do custo dessa energia. O aumento do consumo de energia se dá pelo aumento do poder de processamento, de novas aplicações adicionadas aos CPDs (VoIP e streaming de vídeo são bons exemplos), adensamento das CPUs que assim produzem mais calor e o aumento dos requerimentos de refrigeração.
A indústria de TI como um todo está se mexendo para dar a seus clientes uma solução compatível com as exigências de desempenho, custos e eficiência que as empresas modernas requerem de seus fornecedores. E assim chegamos a uma das soluções que mais vem sendo adotada: virtualização. Virtualização significa fazer mais com menos. Mais aplicações, mais processamento, e menos hardware. Menos hardware também significa menos custos de manutenção e gerenciamento de servidores. Como vantagem para a virtualização pesa o fato que é uma tecnologia antiga e madura, com diversas soluções para diferentes ambientes e necessidades, e com fornecedores bem estabelecidos e conhecidos. Não é portanto uma aventura tecnológica, tanto que o IDC estima gastos de 15 bilhões em 2009 com virtualização.
Mas como fica a segurança em um ambiente virtualizado? É a mesma coisa que para um ambiente tradicional? A resposta é sim, todos as ameaças a um ambiente físico também estão presentes no ambiente virtualizado. Virtualização reduz a necessidade de servidores mas não a exposição à ameaças. Além disso, ela introduz novas camadas de software que trazem novas janelas de oportunidades a invasores. O diagrama abaixo mostra as camadas típicas de um sistema virtualizado:
O uso dos componentes de sistemas de virtualização como vetor de ataque foi comprovado por dois trabalhos de pesquisa de 2006 que merecem ser consultados para quem quer se aprofundar no assunto. O primeiro deles, “Introducing Blue Pill”, de Joanna Rutkowska, foi apresentado em Julho de 2006 no SysScan Conference em Singapura. Um resumo foi publicado em 26 de Junho de 2006, no blog da autora: http://theinvisiblethings.blogspot.com/2006/06/introducing-blue-pill.html. O BluePill se trata de um rootkit que usa virtualização para se comunicar com o hardware sem ser detectado. O outro trabalho também se relaciona com um rootkit, chamado de SubVirt, e é anterior ao BluePill. O SubVirt se baseia em tecnologias comerciais de virtualização como o VMWare e o VirtualPC. O artigo da pesquisa - SubVirt: Implementing malware with virtual machines – pode ser consultado em http://www.eecs.umich.edu/virtual/papers/king06.pdf é de autoria da Universidade de Michigan e da Microsoft Research.
Uma apresentação que causou bastante barulho, também em 2006, foi a do rootkit Vitriol no Microsoft BlueHat summit. O rootkit foi criado para enganar a tecnologia de proteção PatchGuard da Microsoft. O rootkit utiliza funções avançadas de suporte a virtualização presentes nos novos chips Intel e AMD, e “pode migrar on the fly um sistema operacional em execução para uma máquina virtual e instalar-se como um hypervisor rootkit (ou seja oculto). O código malicioso assim torna-se inacessível para o sistema operacional, mantendo-se oculto e controlando o acesso ao malware”. Eu diria que dessa forma o malware passa a controlar efetivamente o computador com pouquissimas chances de ser detectado e removido. Para quem se interessar, mais informações estão na Insecure.org: http://seclists.org/isn/2006/Oct/0079.html. Vale a penas também olhar a apresentação do criador do Vitriol que está disponível em http://www.theta44.org/software/HVM_Rootkits_ddz_bh-usa-06.pdf (há um link para esta apresentação no final do artigo da Insecure.org).
Os exemplos anteriores mostram o uso dos componentes de virtualização como vetores de ataques, porém a camada de gerenciamento pode também ser vulnerável, como demonstra vulnerabilidades descobertas que afetam sistemas de gerenciamento de fornecedores do mercado. Essas vulnerabilidades podem ser consultadas no site do X-Force (http://xforce.iss.net/) ou sites similares, e mostram a seriedade com que o tema deve ser tratado. Um ambiente virtual pode ser muito mais complexo do que um ambiente físico, e exige muito mais atenção do que um ambiente físico ao ser planejado e instalado. A solução passa pela utilização de sistemas de proteção de servidor compatíveis com virtualização, o tratamento de servidores virtuais com o mesmo cuidado dos servidores físicos (não só o sistema operacional hospedeiro deve ser protegido), o cuidado no desenho da “rede virtual” e em políticas e processos de controle mais rígidos.
Uma leitura atenta do parágrafo anterior revela o que será na verdade o grande motivador para que empresas de todos os setores e tamanhos, conscientes ou não da questão ambiental, coloquem o tema em sua lista de prioridades: custos. A cada ano o modelo atual de centro de processamento de dados torna-se mais caro; basicamente por dois motivos relacionados entre si: o aumento do consumo de energia e o aumento do custo dessa energia. O aumento do consumo de energia se dá pelo aumento do poder de processamento, de novas aplicações adicionadas aos CPDs (VoIP e streaming de vídeo são bons exemplos), adensamento das CPUs que assim produzem mais calor e o aumento dos requerimentos de refrigeração.
A indústria de TI como um todo está se mexendo para dar a seus clientes uma solução compatível com as exigências de desempenho, custos e eficiência que as empresas modernas requerem de seus fornecedores. E assim chegamos a uma das soluções que mais vem sendo adotada: virtualização. Virtualização significa fazer mais com menos. Mais aplicações, mais processamento, e menos hardware. Menos hardware também significa menos custos de manutenção e gerenciamento de servidores. Como vantagem para a virtualização pesa o fato que é uma tecnologia antiga e madura, com diversas soluções para diferentes ambientes e necessidades, e com fornecedores bem estabelecidos e conhecidos. Não é portanto uma aventura tecnológica, tanto que o IDC estima gastos de 15 bilhões em 2009 com virtualização.
Mas como fica a segurança em um ambiente virtualizado? É a mesma coisa que para um ambiente tradicional? A resposta é sim, todos as ameaças a um ambiente físico também estão presentes no ambiente virtualizado. Virtualização reduz a necessidade de servidores mas não a exposição à ameaças. Além disso, ela introduz novas camadas de software que trazem novas janelas de oportunidades a invasores. O diagrama abaixo mostra as camadas típicas de um sistema virtualizado:
Os sistemas de virtualização em geral introduzem três novos componentes de software. O Hypervisor ou VMM (virtual machine monitor) é o componente quer permite a execução e coordena as múltiplas instâncias de sistemas operacionais ou serviços que são executados no sistema hospedeiro. Esses sistemas ou serviços virtuais necessitam compartilhar os mesmos componentes de hardware, e a multiplexação ou interface desses diversos sistemas em execução com o hardware físico cabe ao componente de virtualização de hardware. Por fim há o componente de gerenciamento. Todos sabemos que novos componentes significam novas vulnerabilidades, e dessa forma novas ameaças em potencial. Além das novas vulnerabilidades trazidas com os novos componentes, há as vulnerabilidades herdadas dos sistemas operacionais executados. O Windows e Linux terão as mesmas vulnerabilidades, sendo executados em um servidor físico ou em um virtual.
O uso dos componentes de sistemas de virtualização como vetor de ataque foi comprovado por dois trabalhos de pesquisa de 2006 que merecem ser consultados para quem quer se aprofundar no assunto. O primeiro deles, “Introducing Blue Pill”, de Joanna Rutkowska, foi apresentado em Julho de 2006 no SysScan Conference em Singapura. Um resumo foi publicado em 26 de Junho de 2006, no blog da autora: http://theinvisiblethings.blogspot.com/2006/06/introducing-blue-pill.html. O BluePill se trata de um rootkit que usa virtualização para se comunicar com o hardware sem ser detectado. O outro trabalho também se relaciona com um rootkit, chamado de SubVirt, e é anterior ao BluePill. O SubVirt se baseia em tecnologias comerciais de virtualização como o VMWare e o VirtualPC. O artigo da pesquisa - SubVirt: Implementing malware with virtual machines – pode ser consultado em http://www.eecs.umich.edu/virtual/papers/king06.pdf é de autoria da Universidade de Michigan e da Microsoft Research.
Uma apresentação que causou bastante barulho, também em 2006, foi a do rootkit Vitriol no Microsoft BlueHat summit. O rootkit foi criado para enganar a tecnologia de proteção PatchGuard da Microsoft. O rootkit utiliza funções avançadas de suporte a virtualização presentes nos novos chips Intel e AMD, e “pode migrar on the fly um sistema operacional em execução para uma máquina virtual e instalar-se como um hypervisor rootkit (ou seja oculto). O código malicioso assim torna-se inacessível para o sistema operacional, mantendo-se oculto e controlando o acesso ao malware”. Eu diria que dessa forma o malware passa a controlar efetivamente o computador com pouquissimas chances de ser detectado e removido. Para quem se interessar, mais informações estão na Insecure.org: http://seclists.org/isn/2006/Oct/0079.html. Vale a penas também olhar a apresentação do criador do Vitriol que está disponível em http://www.theta44.org/software/HVM_Rootkits_ddz_bh-usa-06.pdf (há um link para esta apresentação no final do artigo da Insecure.org).
Os exemplos anteriores mostram o uso dos componentes de virtualização como vetores de ataques, porém a camada de gerenciamento pode também ser vulnerável, como demonstra vulnerabilidades descobertas que afetam sistemas de gerenciamento de fornecedores do mercado. Essas vulnerabilidades podem ser consultadas no site do X-Force (http://xforce.iss.net/) ou sites similares, e mostram a seriedade com que o tema deve ser tratado. Um ambiente virtual pode ser muito mais complexo do que um ambiente físico, e exige muito mais atenção do que um ambiente físico ao ser planejado e instalado. A solução passa pela utilização de sistemas de proteção de servidor compatíveis com virtualização, o tratamento de servidores virtuais com o mesmo cuidado dos servidores físicos (não só o sistema operacional hospedeiro deve ser protegido), o cuidado no desenho da “rede virtual” e em políticas e processos de controle mais rígidos.
O título do artigo – Green Security – foi claro um trocadilho com GreenIT, mas pode ser interpretado como o desafio de implementar um ambiente de virtualização com segurança, e impedir que as perdas com a falta de segurança sejam maiores que os ganhos obtidos com a virtualização.
quinta-feira, 10 de janeiro de 2008
Será que a lei pega?
No dia 8 de janeiro o IDG Now publicou noticia sobre projeto de lei 1227/07 do deputado Eduardo Gomes (PSDB-TO) punindo a prática do SPAM. Em uma visão rápida parece um bom projeto. Define como SPAM qualquer mensagem enviada sem autorização prévia ou para uma pessoa/empresa que não tenha relação comercial prévia com o remetente. Nesse caso a mensagem deveria conter as já tradicionais instruções de remoção. A multa seria de R$ 200 por mensagem. Como muitas vezes essas instruções são apenas para dar um ar de seriedade a uma mensagem SPAM, o projeto de lei também prevê multa para esses casos.
É claro que a lei não irá eliminar mensagens fraudulentas, mas é um bom começo para eliminar as mensagens indesejadas que lotam caixas postais e gastam nosso tempo; e também não irá afetar mensagens vindas do exterior. Mas qualquer lei que regule e reduza o marketing por e-mail é bem-vinda. O link do IDG é http://idgnow.uol.com.br/seguranca/2008/01/08/idgnoticia.2008-01-08.5497773866
É claro que a lei não irá eliminar mensagens fraudulentas, mas é um bom começo para eliminar as mensagens indesejadas que lotam caixas postais e gastam nosso tempo; e também não irá afetar mensagens vindas do exterior. Mas qualquer lei que regule e reduza o marketing por e-mail é bem-vinda. O link do IDG é http://idgnow.uol.com.br/seguranca/2008/01/08/idgnoticia.2008-01-08.5497773866
Assinar:
Postagens (Atom)