Clean Pipes

*** Artigo publicado na Revista RTI - Novembro 2012 ***


Nossa área de segurança de TI é pródiga em tomar emprestado termos de outras áreas, algumas nem um pouco relacionadas à segurança. O caso mais famoso é certamente a palavra firewall, que acabou por ser mais associada à segurança de redes que ao seu uso original em construções.  Lembro isso para introduzir o assunto título do artigo esse mês: clean pipes, ou tubulações limpas em uma tradução livre.
Clean pipes em segurança de redes significa circuitos de dados livres de tráfego de ataque e do lixo eletrônico em geral. É um termo bastante genérico, não propriamente novo, existe já há alguns anos, mas que vem recentemente recebendo atenção do mercado e uma nova textura associada com outra tendência do momento, o cloud computing.  Por isso vale uma olhada mais de perto e fugir do risco de ser seduzido por termos enriquecidos pelo marketing mas com pouca eficiência prática ou relacionados a produtos e serviços maquilados com uma nova roupagem para ficarem mais atrativos.

Entender o termo não é difícil. A melhor analogia, usada por nove entre dez especialistas é a do fornecimento de água, que chega às casas livre de impurezas, não exigindo que seja filtrada pelos moradores. É claro que não se aplica muito ao Brasil, já que aqui a água chega mais ou menos pura e todos nós usamos filtros em casa. Mas de qualquer forma dá uma boa ideia do conceito principal, de ser parte do portafólio de serviços das prestadoras de telecomunicações que buscam adicionar ao serviço básico de conexão o valor agregado de filtragem das ameaças digitais antes que estas cheguem à empresa. Com o advento do cloud computing o leque abrange também os provedores desses serviços e os circuitos de dados por eles oferecidos como parte da infraestrutura de nuvem, já que é essencial que a infraestrutura esteja com o máximo de disponibilidade e livre de problemas que possam significar a interrupção dos serviços. Tal filtragem poderá então ser assimilada como custo pelos provedores e anunciada como valor agregado, ou comercializado como serviço adicional.

Esses provedores são portanto os clientes dos fabricantes e fornecedores de serviços e produtos de segurança. E aqui começa a divergência, se é que podemos chamar assim. Por ser uma prática genérica não há uma classe de produtos ou serviços específicos. O que é oferecido ajuda ou pode ser utilizado pela companhia em seu esforço de garantir circuitos seguros para seus clientes, e dessa forma o foco de produtos e serviços variam entre os fornecedores, o que implica em mais cuidado no momento da aquisição. Cabe ao provedor decidir que nível de limpeza ele quer, ou precisa, fornecer a seus clientes. Similarmente, cabe a estes questionar qual o nível de limpeza está sendo prometido, e qual o SLA que será garantido.  É um erro comprar um circuito “limpo” sem especificar o que isso significa exatamente, ou quais ataques serão bloqueados e em que extensão.

O fato é que nem todos  os ataques podem ser bloqueados pelos provedores no nível da rede, e portanto é impossível que alguma empresa garanta circuitos completamente livre de tráfego malicioso. O espectro de ameaças digitais é muito amplo e apenas parte dos ataques de rede podem ser detectados e bloqueados. Um deles são os de negação de serviço, distribuído ou não (DoS e DDoS) e há um beneficio imediato do bloqueio já pelo provedor, pois a possibilidade dos equipamentos de perímetro dos clientes, firewall inclusive, não aguentarem um ataque desses é bem alto. Já o provedor, devido a sua infraestrutura, tem mais condições de lidar com ele. Há claro modalidades diferentes de DoS, assunto para um artigo inteiro, e a empresa precisa planejar quais serão tratados. Sobretudo para provedores de infraestrutura de nuvem essa proteção é importantíssima já que o ataque pode afetar uma grande quantidade de serviços. Outro tráfego malicioso, muitas vezes relacionado com o ataque anterior, é o de botnets, as redes de comunicação dos computadores “zumbis”.  Há também todo um tráfego relacionado a ataques diversos de rede,  normalmente centrados em explorar vulnerabilidades presentes em sistemas operacionais. Existem padrões conhecidos de todos esses tipo de tráfego que o identificam com segurança, sem riscos no momento da ação.

Essa é alias uma discussão habitual entre os provedores e seus clientes, que receiam que o bloqueio possa também afetar o tráfego legítimo, e preferem assim que o circuito seja fornecido de forma bruta, sem tratamento.  Isso ocorreria devido ao falsos positivos gerados pelos produtos de detecção. Felizmente não há mais fundamento para esse temor. Um bom percentual dos ataques de rede tem probabilidade zero de falso positivo. Trata-se não somente dos dois ataques que comentei anteriormente mas de exploits conhecidos a fundo, muitos com quase uma década de existência, que detectores de intrusos identificam com 100% de certeza. Ao serem filtrados ainda no backbone do provedor, recursos de rede e segurança do cliente final são poupados para outros fins, como ataques que requerem análise de contexto antes, o que é preferível que ocorra na empresa usuária.

Esse é alias outro ponto importantíssimo. Contratar um circuito limpo não significa abrir mão da segurança de perímetro de sua rede. Por mais que hoje a noção de perímetro tenha evoluído para os pontos de contato com redes as quais a empresa não tem controle, o que inclui usuários VPN, equipamentos de mobilidade, parceiros e até serviços como correio eletrônico, entre outros; haverá sempre a conexão principal da empresa com a Internet, e que deve ser protegida.  Ter um nível superior de filtragem é uma ótimo recurso adicional, mas que deve ser tratado dessa forma, como algo a mais que não irá representar um risco se for algum dia desabilitado.  Voltando uma vez mais à nossa analogia, é como o fornecimento aqui em nosso país. A água chega limpa das principais impurezas, mas para bebê-la usamos sempre um filtro dentro de nossa casa.

Leis. Um longo caminho...

As ultimas discussões a respeito da chamada lei Carolina Dieckmann mostra como ainda é longo o caminho para as leis contra crimes digitais. Digo isso devido a uma discussão recente em sites de noticias a respeito da lei dizer que o crime ocorre "mediante violação indevida de mecanismo de segurança" e que portanto a lei vale para apenas computadores protegidos. Mas o que é um computador protegido? Todos os sistemas operacionais possuem mecanismos de segurança, algo bastante genérico por sinal. Senha vale?

Assim imagino o advogado de um suspeito de invasão dizer que seu cliente é inocente pois o computador da vítima estava desprotegido. "Não tinha senha" ele irá dizer. Espero que o juiz não tenha que contratar peritos para averiguar se o computador da vítima estava ou não protegido. Perda de tempo e dinheiro.

Mas a discussão não ocorre somente aqui. Até nos Estados Unidos, muito a frente do Brasil nesse tema de leis, há discussões e questionamento, como nesse post de Rober Graham, da Errata Security, http://erratasec.blogspot.com.br/2012/11/you-are-committing-crime-right-now.html 

Engenharia Social

** artigo publicado na Revista RTI edição de Outubro/2012 **

Um dos temas que mais chamaram a atenção no últimos meses foi o ataque sofrido pelo jornalista Matt Honan, da revista Wired. Para aqueles que não acompanharam o caso, ele teve roubadas suas credenciais de acesso ao Google, Twitter, Amazon e Apple; além de seu iPhone, iPad e Macbook completamente apagados. Como ele mesmo declarou, sua vida digital foi arruinada em menos de um dia. A história completa está contada no endereço próprio do jornalista, http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking. Lá também está a descrição de como ele conseguiu recuperar os seus dados, em http://www.wired.com/gadgetlab/2012/08/mat-honan-data-recovery.

O que mais vale nesse episódio não é o seu resultado, que será ainda contado por anos em palestras pelo mundo, mas suas entrelinhas. Todo o procedimento seguido, linha de raciocínio e vulnerabilidades exploradas estão não só descritas como detalhadas. Temos ainda a revelação de que o ataque não foi pessoal. Phobia, o invasor, disse à própria vítima que não tinha nada contra ele e que queria apenas invadir sua conta do Twitter. Algo como um exercício. É a confirmação de que ninguém pode nem deve sentir-se totalmente seguro na Internet. Há ainda o fato de que todo o processo de invasão se deu com o uso exclusivo da Engenharia Social, a técnica de ganhar acesso a um edifício ou sistema, ou de obter um resultado qualquer através da interação social, sem a quebra da segurança física ou digital do alvo. O método é normalmente associado à enganação mas na verdade é mais complexo que isso, pois requer que alguma vulnerabilidade não tecnológica seja explorada, como processos mal escritos e falhas de treinamento de pessoal.

E foram essas as vulnerabilidades exploradas pelo hacker Phobia para atingir seu objetivo. Ele não precisou quebrar a segurança de nenhum sistema dos provedores, tampouco precisou decodificar senhas ou invadir os equipamentos da vítima para apagar os dados.  Ele apenas se aproveitou de procedimentos mal definidos ao se fazer passar pelo jornalista ao telefone e obter o acesso aos serviços. O principal erro das empresas foi o de solicitar dados de identificação pessoal que podem ser facilmente obtidos na Internet.

A primeira vista esses erros podem parecer grosseiros, mas não encaro assim. Vejamos o caso da Amazon. Ela permitiu sem muita dificuldade que o impostor adicionasse um novo cartão de crédito à conta de Honan. Para isso eles pediram nome, email e endereço; todas informações fáceis de se obter. Mas o autor desse procedimento iria com certeza perguntar: mas para que alguém iria incluir um cartão de crédito na conta de outra pessoa? Não deixa de fazer sentido. Se o cliente quer incluir um cartão para que criar dificuldades? A resposta não está nesse procedimento mas em outro, para recuperar a senha. Para isso eles pediam nome, endereço e o número do cartão de crédito registrado, algo certamente difícil de se obter a não ser que, sim, o próprio invasor o tenha incluído na conta. A única maneira de se evitar uma situação assim é pensar como o hacker, algo que muitas empresas não estão preparadas para fazer.

Há ainda outra entrelinha. Senhas são a nossa primeira linha de defesa, para muitos serviços online a única. Quanto maiores e mais variadas, mais “fortes”, seguras, elas são. Esta certamente não era uma preocupação para o jornalista, já que ele contou utilizar uma ferramenta de administração de senhas, que gera códigos com mais de dez dígitos e grande variação de caracteres. Ele se julgava seguro dessa forma, e ninguém pode dizer que estava enganado. Por muito menos  a maior parte dos usuários se sente seguro apenas porque troca suas senhas a cada 90 dias. Eu sou um crítico dessa “boa prática”. Não discordo dela mas sim da maneira como é implementada. Em muitos sites essa é a única medida de segurança para seus usuários, que continuam a usar senhas compostas de números ou combinações simples, apesar de trocá-las periodicamente. O pior risco é a falsa sensação de segurança.

Qual então a solução? Para os usuários infelizmente não há nada o que fazer quando seus provedores não fornecem recursos melhores. Mas eles existem em alguns casos, e devemos aprender a utilizá-los. Um bom exemplo é o Google e o Facebook, que possuem como opção a autenticação em duas fases quando o acesso é feito de um computador nunca antes usado pelo usuário.  No caso deles o telefone se torna o segundo fator de autenticação, seja ao receber um SMS com uma segunda senha, ou via aplicativo nele instalado. É o mesmo método usado por muitos bancos no Brasil para avisar de uma operação de débito ou crédito. Já o UOL envia mensagem de SMS quando a senha é alterada, medida também implementada por alguns bancos brasileiros para avisar seus clientes de operações diversas. Mas para isso é necessário que o telefone celular esteja cadastrado, o que muita gente não faz.

Para as empresas é necessário repensar. Por que não implementar um segundo fator de autenticação para algumas tarefas, como por exemplo, a troca da senha? Não menos importante são as perguntas de identificação positiva no atendimento telefônico. Dados tidos como confidenciais, como CPF ou identidade, podem ser comprados facilmente, ou obtidos no lixo residencial ou empresarial. Um bom exemplo de identificação positiva, pouco usada e muito mais eficiente, é permitir que o próprio cliente cadastre suas perguntas e respostas, geralmente de cunho pessoal e que um impostor dificilmente irá obter. É possível também fazer um trabalho melhor com as senhas. O primeiro passo é permitir letras maiúsculas e minúsculas, além de caracteres especiais.  Só números e letras minúsculas é muito pouco. Segundo, não limitar o tamanho da senha em apenas oito caracteres. Este deve ser o mínimo mas certamente não o máximo. É necessário que as empresas deixem de seguir somente o que aparenta ser a boa prática e pesquisem casos e exemplos diferentes em seu e em outros mercados.