Os artigos refletem a opinião pessoal do autor, e não de seus empregadores.

quinta-feira, 6 de dezembro de 2012

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.

terça-feira, 4 de dezembro de 2012

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 

quinta-feira, 1 de novembro de 2012

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.  

quinta-feira, 18 de outubro de 2012

Qual o PIN de cartão mais usado?

Um pequeno post no blog do Bruce Schneier chamou minha atenção e me levou até este interessante estudo realizado pela DataGenetics - http://www.datagenetics.com/blog/september32012. Eles analisaram 3.4 milhões de PINs em tabelas publicadas por hackers e chegaram a conclusão que '1234' é a mais utilizada, seguida de '1111'. Incrível mas real. Pior ainda: apenas 20 das dez mil combinações possíveis são responsáveis por 26% das senhas analisadas.

Esse estudo é quase uma continuidade de outro, assunto do meu post "Sua 'strong password' é realmente forte?" no mês de agosto. Minha interpretação é que uma parte importante da tarefa de revelar senhas é o estudo do comportamento dos usuários, quase um estudo antropológico a respeito dos hábitos das pessoas para a definição de seus códigos de segurança. É também interessante que esses hábitos são compartilhados por pessoas de diferentes culturas, nacionalidades e grupos sociais. Como exemplos o fato da maioria das pessoas ter em suas senhas somente uma letra maiúscula posicionada como a primeira letra da palavra. Já os números e caracteres especiais vem em sua grande maioria no final.

Esse estudo também reforça a tese de que alterar senhas fracas periodicamente não aumenta a segurança   do usuário. Na verdade piora já que a pessoa se ilude pensando que está segura. É melhor uma senha complexa apenas alterada em situações especiais do que senhas fáceis trocadas a cada 30 dias.

terça-feira, 9 de outubro de 2012

Palo Alto vs Check Point. Quem ganha essa briga?

A Palo Alto e a Check Point estão travando uma batalha através de seus sites. A empresa da California decidiu atacar a base instalada da israelense a fim de ganhar mercado, usando para isso a tática de desconstruir a superiodade tecnológica da rival. Assim não é a toa que tenha publicado uma página dedicada à rival com o título de TechBusters, http://www.paloaltonetworks.com/cam/techbusters,
claramente inspirado no programa MythBusters da Discovery Channel. O contra-ataque veio na página http://www.checkpoint.com/beyondthehype/index.html em que a Check Point chama a propaganda em torno da rival de hype, ou seja, algo propositalmente exagerado.

quarta-feira, 22 de agosto de 2012

Malware para Windows, Mac, VMWare e Windows Phone?

A evolução das técnicas de criação de malware é realmente impressionante. Se fala muito de ameaças para Windows, para Mac, para smartphones e para máquinas virtuais; mas um único malware capaz de atacar tudo isso junto é novidade. Pois de acordo com a Symantec o malware Crisis é capaz de invadir Windows, MacOS, VMs em VMWare e smartphones rodando Windows:

http://www.symantec.com/connect/blogs/crisis-windows-sneaks-virtual-machines


terça-feira, 21 de agosto de 2012

Sua "strong password" é realmente forte?

Passwords ainda são a primeira linha de proteção de qualquer serviço ou site. Com a nossa vida digital cada vez mais misturada com nossa vida real (pessoal e profissional), as passwords são tão importantes hoje como a fechadura das portas de nossas casas. A má noticia é que os hackers nunca tiveram tantos recursos para quebrar a segurança das senhas que usamos. A boa noticia? Bem, ainda estou procurando... :-)

Esse artigo, de Dan Goodin, é um dos mais completos que já vi sobre segurança de passwords e sobre os mecanismos utilizados hoje em dia pelos hackers:
http://arstechnica.com/security/2012/08/passwords-under-assault

segunda-feira, 13 de agosto de 2012

Netflow no Gerenciamento e Segurança de Rede

Nesse post reproduzo artigo de minha autoria publicado na revista RTI - edição de Julho/12. Vocês poderão ver a edição virtual da revista em http://www.arandanet.com.br/midiaonline/rti/index.html 

As áreas de rede e segurança trabalham como duas retas paralelas na maior parte das empresas, com interesses diferentes porém não antagônicos. Enquanto a primeira se preocupa em fazer com que os dados trafeguem o mais rápido possível até o seu destino, a outra procura garantir que cheguem com segurança.  Um observador externo diria com razão que esses objetivos são na verdade complementares, já que os dados precisam trafegar ao mesmo tempo com velocidade e segurança.  Mas é de outro ponto em comum que gostaria de comentar nesse artigo: ambos tem a mesma deficiência: falta de visibilidade da rede. Tanto os administradores de rede como de segurança gerenciam equipamentos limitados em fornecer uma visão completa sobre o tráfego que passa pela rede. Essa limitação não afeta inicialmente os objetivos de cada área, mesmo com ela é possível garantir os requerimentos de velocidade e segurança, mas visibilidade significa conhecimento. Ao se conhecer melhor e mais profundamente o tráfego aumenta-se consideravelmente a eficiência da administração.
Foi certamente levando isso em consideração que a Cisco criou em 1996 o protocolo Netflow para coleta de informações de tráfego. Em poucos anos se tornou o padrão da indústria e motivou o IETF a iniciar um grupo de trabalho para a criação de um padrão formal, IPFIX (Internet Protocol Flow Information eXport), definido em várias RFCs e presente na maior parte dos switches e roteadores de diferentes fabricantes. É interessante observar que apesar do nome criado pela IETF e por concorrentes, como JFlow pela Juniper e NetStream pela 3Com, hoje HP, o termo original continuou como o mais usado, mesmo por aqueles que não são usuários Cisco. A versão mais atual e base das RFCs é a 9 embora a mais utilizada seja a 5.
O serviço está baseado na coleta das informações básicas dos fluxos de comunicação de rede e seu envio a um analisador que irá gerar informações gerenciais como a base de referencia (baseline) do tráfego, os protocolos mais utilizados ou um mapa completo da comunicação de rede. A coleta ocorre normalmente no próprio equipamento de rede embora haja produtos especializados nessa função, chamados de coletores. O seu êxito está em responder às perguntas de “quem”, “o que”, “quando”, “onde” e “como” em relação à rede.  É importante ressaltar que ele não inclui a inspeção total dos pacotes (deep packet inspection), a única forma de dizer com precisão o que está sendo transmitido.  Mas para a administração pura de rede, que não leva em conta segurança, essa informação não é necessária e os benefícios são muitos: planejamento de capacidade, previsão de crescimento de rede, planejamento de QoS, detecção de anomalias, remanejamento de equipamentos ociosos, entre outros.  Por tudo isso sua implementação e uso é recomendado para empresas de qualquer porte e tamanho de orçamento. Há inclusive versões disponíveis de analisadores e coletores em código aberto.
Uso em Segurança
Por permitir a detecção de anomalias o protocolo passou rapidamente a ser utilizado também em segurança, já que um ataque de rede, interno ou externo, é por definição uma anomalia. Há quem inclusive defenda que essa deveria ser a forma como as empresas detectam ataques de rede, em crítica direta à segurança de perímetro representada pelos firewalls e IPS. Eu discordo e defendo o uso combinado, para não dizer integrado, dessas tecnologias. A segurança de perímetro ainda é o melhor filtro de tráfego indesejado e é ainda insubstituível. Por outro lado há carências que são supridas pela detecção de anomalias. 
A primeira delas é a segurança da rede interna, normalmente implementada com os mesmos produtos utilizados no perímetro.  É muito complexo e dispendioso analisar todo o tráfego interno com produtos instalados em determinados segmentos de rede. Complexo porque dificilmente uma rede de grande porte terá um só ponto onde se poderá instalar um único equipamento. Dispendioso porque o volume de tráfego será bem mais alto, exigindo produtos mais parrudos.  Como os dados de netflow são coletados nos equipamentos de rede já existentes, por onde passa todo o tráfego de rede, ambos temas são solucionados. A segunda carência é justamente relacionada aos ataques DoS e principalmente DDoS, áreas em que firewalls e IPS são limitados. Para isso a detecção de anomalias é bem mais eficiente. A terceira é que por mais avançado que seja, um equipamento perimetral ainda depende de assinaturas ou algoritmos para detectar um ataque. Algo completamente novo não será detectado, mas pode (repito, pode) ser detectado como anomalia.
Mais recentemente a Cisco expandiu o uso do protocolo em segurança ao criar o NSEL (NetFlow Security Event Logging), extensão do Netflow implementada em firewalls que inclui informações de como um determinado fluxo foi tratado pelo dispositivo, ou seja, se os pacotes foram ou não bloqueados. Essa informação já é exportada pelos firewalls através de eventos syslog ou outros métodos, mas de acordo com os entusiastas há vantagens em concentrar tudo em um único analisador, além é claro de melhorar os resultados gerenciais, que dirão não somente se há um flow anômalo mas também se este flow foi ou não bloqueado por um firewall. Esse é um ótimo exemplo de integração de segurança perimetral com detecção de anomalias.
Outra maneira de integrar Netflow, firewalls e IPS é via os sistemas SIEM, abordados nos últimos dois artigos aqui na RTI. Quanto mais informação é recebida pelo sistema melhor será seus alertas, relatórios e ações relativas a compliance e resposta a incidentes.  Em geral o SIEM não receberia diretamente os dados de flow mas eventos gerados pelo analisador, como um alerta de desvio de baseline, computador desconhecido comunicando-se ou outra anomalia. Nenhuma das três possibilidades de uso do Netflow em segurança são excludentes, muito pelo contrário, e dependendo da situação particilar de cada empresa há vantagens claras em utilizar todas elas.

quarta-feira, 27 de junho de 2012

Mercado de SIEM em 2012

Uma consequência direta do crescimento do mercado de SIEM foi o investimento de pesos-pesados na indústria de TI. A HP foi a primeira ao adquirir em 2010 a ArcSight. Em 2011 dois líderes de mercado, Q1Labs e NitroSecurity, foram comprados respectivamente por IBM e McAfee. A RSA, braço de segurança da EMC, que já tinha em seu portfolio o Envision, adquiriu também em 2011 a Netwitness. Já a NetIQ, da Attachmate, reforçou seu portfolio com a incorporação da Novell e sua solução Sentinel.  Todos esses se juntaram a um mercado onde já estavam gigantes como Symantec além de pelo menos uma dezena de empresas menores, como a AlienVault, criada sobre o sistema de código livre OSSIM, a exemplo da Sourcefire, líder do mercado de IPS e baseada no SNORT.  Para o comprador tal quantidade e diversidade de mercado é um desafio a mais. Para nós, brasileiros, o desafio é menor porque há menos empresas com presença no país, sendo o mercado por aqui mais concentrado em torno dos grandes fabricantes. O domínio desses fabricantes pode ser medido pelo último relatório Quadrante Mágico do Gartner relativo a 2011 e publicado em Maio desse ano. Como líderes o relatório lista cinco empresas, com especial destaque justamente à HP, IBM e McAfee. As outras duas são a NetIQ e a pequena LogRhythm. No quadrante challengers, bem próximo aos líderes, estão Symantec e EMC. 

terça-feira, 26 de junho de 2012

SIEM


** Esse artigo, assim como a maioria dos textos do blog, foi publicado em minha coluna mensal na revista RTI **

Segurança de TI é como uma torre de babel. Ao longo dos anos as empresas vão acumulando produtos e tecnologias diversas para cada tipo de ameaça ou função de segurança. Uma empresa de grande porte terá pelo menos dez tecnologias implementadas, não só em dispositivos diferentes como de fabricantes distintos. Para piorar é normal que produtos diferentes sejam usados para atender a mesma necessidade, como firewalls de vários fabricantes.  Por sua vez cada fabricante consolida os eventos de seus produtos em consoles próprias, com óbvias limitações para importação de dados de outros, quando essa possibilidade existe.  Além disso há dados relevantes nos logs de servidores que necessitam ser consolidados e processadas. O resultado são dados dispersos em diferentes sistemas e uma imensa dificuldade para gerar informação.
A integração de eventos e dados de segurança não é nenhuma panaceia, porém é necessária para algumas funções como compliance, investigação de incidentes e gerenciamento de ameaças.  Em empresas com quantidade menor de eventos de segurança essa tarefa pode ser realizada manualmente, mas quando há milhares ou milhões de eventos isso se torna impossível.  Assim o processo natural é o de adquirir um sistema SIEM (security information and event management), de gerenciamento de eventos e informações de segurança, na esperança de por ordem na bagunça.  Infelizmente a implementação falha ou fica aquém das expectativas em muitas empresas. É importante entender os motivos ou ao menos discutir algumas possibilidades.
Um sistema SIEM é por principio complexo, concebido para importar dados das fontes mais variadas possíveis, consolidar, processar, correlacionar, comparar e por fim gerar alguma informação relevante para o seu usuário. É também por principio um sistema de várias faces, ou possibilidades de uso.  Parte desse último aspecto vem do fato que os sistemas atuais evoluíram de dois outros tipos de aplicação: os chamados SIM (security information management) e SEM (security event management), parecidos no nome mas diferentes na função. O primeiro foi uma evolução do sistemas de gerenciamento de logs especializado em segurança. Suas fontes principais são dispositivos diversos de rede, servidores e aplicações. Já o SIEM foi criado para consolidar e correlacionar eventos gerados por produtos de segurança.  Como ambas funções são próximas nada mais natural que houvesse uma convergência.
Mas as possibilidades são muitas, indo além da pura consolidação de logs e eventos. O sistema pode ajudar na administração de compliance - a adequação da empresa às normas regulatórias, gerenciamento e investigação de incidentes,  gerenciamento de ameaças em tempo real e gerenciamento de riscos em geral. Aqui vemos o primeiro problema, a aquisição e instalação de um SIEM sem embasamento de um projeto. Em outras palavras, o software precisa ser a ferramenta de um projeto, e não o projeto em si.  Adquirir um sistema como ponto de partida é o primeiro equivoco e um atalho para problemas.  A empresa portanto necessita de um projeto claro e de metas, até porque elas irão ajudar a definir qual é o melhor produto, o que não é tarefa fácil pois há no mercado mais de 50 produtos classificados como SIEM. O Gartner Group em seu famoso Quadrante Mágico pontua 24 produtos diferentes no relatório de 2011, sete deles no quadrante de líderes. O relatório inclui também uma solução baseada em código aberto. É natural portanto que existam produtos melhores em uma determinada função que outros.
Há outros dois pontos cruciais em qualquer projeto. O primeiro deles é levar em conta as fontes de dados as quais se deseja consolidar e a maneira como isso ocorrerá.  Plataformas conhecidas irão contar com agentes nativos, outras irão exigir algum desenvolvimento ou configuração por syslog ou outros.  O cliente deverá levar isso em conta antes e não depois da aquisição. A quantidade de fontes de dados influi também na capacidade de armazenamento, que deverá ser parte do projeto. O objetivo do projeto também influi nesse quesito. Se a empresa tem investigação de incidentes passados como meta, ela deverá definir o período de guarda dos dados e incluir na estimativa de capacidade. Se a meta é estar em conformidade com normas ou leis, o prazo pode alcançar a anos, com muitos terabytes de dados. Mas não é só capacidade. O desempenho da arquitetura de armazenagem pode influir muito no tempo de resposta da solução, sobretudo se utilizada para o gerenciamento e correlação de eventos em tempo real.
O segundo ponto é a equipe que irá operar o sistema. Funções tão variadas exigem perfis profissionais também variados.  Como será a manutenção do sistema? Não digo do software mas das regras nele configuradas. A correlação de eventos, por exemplo,  baseia-se em regras. Boa parte já vem inclusa no pacote inicial mas muitas outras deverão ser criadas para o que o sistema adapte-se à empresa e possa fornecer a informação que se espera dele.  Já compliance e investigação exigem outros perfis de regras e análise.  Uma implementação mal planejada irá inundar a equipe com eventos que para eles não farão sentido, e que portanto serão ignorados. Os usuários irão também variar de acordo com a função, pois os administradores de compliance, risco e segurança de rede são normalmente pessoas diferentes.
A conclusão vale para qualquer produto mas é mais importante para sistemas caros e complexos. Primeiro o cliente precisa comprar bem, o que significa saber o que quer a curto, médio e longo prazos, sem menosprezar o tempo e recursos necessários para a implementação, nunca esquecendo-se que não há software que faça milagres. 

terça-feira, 15 de maio de 2012

Next Generation IPS - Parte II


Em meu primeiro texto sobre IPS abordei o conceito de next-generation IPS na visão do Gartner Group.  É sempre importante olhar o que o instituto está dizendo pois possui um enorme poder de influência sobre o mercado, e mesmo quando erra em suas conclusões e previsões seus analistas acabam por induzir fabricantes, integradores e clientes em suas decisões por um longo período.  De acordo com o último estudo sobre prevenção de intrusos, os equipamentos de próxima geração deveriam possuir as seguintes características além da já tradicional capacidade de identificar ataques de rede: conhecimento das aplicações e visibilidade de toda a pilha de protocolos, reconhecimento de contexto, reconhecimento de conteúdo e motor expansível. No mesmo artigo eu concluí que tal produto ainda não existe, apesar de dez em dez fabricantes anunciarem que atendem aos requisitos do Gartner.

Após encerrar o artigo fiquei pensando sobre os administradores de prevenção de intrusos: estariam eles preparados? As empresas precisarão também de “administradores e operadores de próxima geração”? Ainda não completei meu estudo mas gostaria de compartilhar alguns pensamentos e conclusões, mesmo que provisórias. Muitas delas valem também para o next-generation firewall, outro conceito criado pelo Gartner.

Nos anos iniciais da tecnologia o administrador/operador de IDS (detecção de intrusos) foi educado em meio ao caos de muitos milhares de alertas para analisar e deles extrair o que poderia ser um ataque real. Tiveram que se acostumar com termos estranhos como “falso positivo” e “falso negativo” e com a dura realidade de no final apenas analisar o passado. A geração seguinte da tecnologia permitiu que os sensores saíssem da posição passiva para ficar no meio da rede, ativos e capazes de bloquear os ataques.  Os falso positivos assim tomaram outra dimensão: o produto seria capaz de equivocadamente bloquear tráfego legítimo afetando os negócios da empresa. Assim o ajuste fino – tuning – tornou-se algo essencial em todo e qualquer projeto. No entanto o ajuste fino em um política de IPS é algo muitíssimo mais complexo que o ajuste de configurações de desempenho, por exemplo. O advento do IPS dessa forma dificultou ainda mais a administração, pois os milhares de eventos continuavam e era necessário um trabalho extenso e complicadíssimo de ajuste finos das políticas de detecção.

A situação fez com que os principais fabricantes investissem milhões de dólares no aperfeiçoamento da detecção, surgindo assim as assinaturas baseadas em protocolos e vulnerabilidades, e na redução dos falso positivos onde o produto seria capaz de sozinho separar o joio do trigo e apenas alarmar eventos reais de invasão.  De tão importante essas funcionalidades tomaram a frente do discurso de marketing.  Vejo esse período como a terceira fase da tecnologia: a busca de um produto mais eficiente e mais fácil de administrar. A questão tecnológica de um produto mais eficiente já se completou mas a administrativa ainda não. As ferramentas existem mas os usuários ainda não as usam amplamente ou com proficiência. Dispositivos de IPS ainda são produtos difíceis de administrar, tanto que esse continua a ser um dos argumentos dos provedores de serviços de gerenciamento de segurança (MSS).

Minha primeira conclusão é que os administradores ainda não estão prontos para passar para uma nova fase dos produtos que gerenciam, já que ainda nem complementaram a fase atual. É verdade que umas das funcionalidades solicitadas pelo Gartner, reconhecimento de contexto, reduziria ainda mais a quantidade de eventos relevantes; porém as outras podem aumentar a complexidade da administração ao gerar mais eventos e requerer outros tipos de ajuste fino.  Também não vejo os provedores de MSS anunciando o gerenciamento desses novos IPS, mesmo estes sendo largamente anunciados por fabricantes.  Eu gosto muito mais do conceito de “threat landscape”, ou a proteção contra o amplo cenário de ameaças existente, usando para isso quantas camadas de tecnologia forem necessárias em quantos produtos forem precisos, do que a ideia de que uma tecnologia irá evoluir para abarcar todas as camadas necessárias para a segurança de rede.  Mais do que enveredar por novas funcionalidades de um produto considero mais importante que os administradores de IPS migrem para sua própria próxima fase: a de administradores de ameaças.

Outra conclusão é que talvez toda essa discussão esteja com o foco errado. Afinal são os produtos que devem ditar as rotinas de administração, ou são as rotinas de administração que devem ditar as funcionalidades dos produtos? Em outras palavras, as empresas devem adquirir IPS de próxima geração e então sua equipe técnica deve aprender a como usar as funcionalidades na sua rotina diária, ou são as equipes técnicas que devem buscar essas funções, seja no mesmo produto ou não, para atender às necessidades de seus processos? É interessante observar que é dessa forma que os estudos começam, perguntando aos clientes o que eles gostariam de ter nos produtos que utilizam. Porém uma vez publicado, o foco parece inverter-se, como se daquele momento em diante os produtos ditassem o que é necessário para as empresas.

Mas quais seriam as características dos administradores de ameaças em uma empresa? Inicialmente uma equipe especializada nas ameaças as quais a empresa em que trabalha está sujeita. Significa conhecer profundamente os ativos críticos para os negócios e como eles poderiam ser afetados. Em seguida estudar o que novos serviços, negócios ou equipamentos podem trazer de riscos ou de aumento na janela de oportunidade para os invasores.  Uma ferramenta essencial para essa equipe é a inteligência em segurança, provida por serviços pagos e gratuitos na Internet. Quais as novas ameaças que estão surgindo, quais novas vulnerabilidades foram descobertas, as ondas de ataques que estão ocorrendo na Rede podem chegar à minha empresa e afetar os negócios? Essas e outras perguntas são respondidas através dessas informações a que gosto de chamar de inteligência em segurança.

Ao implementar funcionalidades disponíveis em produtos apenas porque elas estão lá corremos o risco de apenas agregar coisas para as quais não sabemos muito como utilizar.  Me lembro de um cliente antigo que após testar uma nova funcionalidade do produto que minha empresa vendia me disse: “gostei muito, é uma função muito interessante, mas para que serve?”. Naquele momento percebi que para ele não servia para nada.

segunda-feira, 23 de abril de 2012

Next Generation IPS - parte I


O uso do termo “next-generation” (próxima geração) em segurança de TI  é uma constante há vários anos. Em especial o Gartner Group o adora, já que volta e meia publica alguma análise sobre alguma nova geração de um produto. Pois em outubro de 2011 o instituto de pesquisa publicou estudo de seis páginas com o título “Defining Next-Generation Network Intrusion Prevention”,  descrevendo as funcionalidades que devem compor os dispositivos de prevenção de intrusos que as empresas precisariam no futuro próximo.
Eu pessoalmente não gosto desse termo. Primeiro porque não diz muita coisa. Os fabricantes estão sempre trabalhando em inovações para seus produtos que serão a sua próxima geração. Um bom exemplo é o firewall. Há quase dez anos atrás o Gartner publicou um estudo para o “next-generation firewall”, que naquela época era um firewall que incluía detecção de intrusos, ou deep packet inspection na terminologia da época. Hoje para o Gartner o next-generation firewall deve incluir várias outras funcionalidades e certamente daqui a cinco anos haverá outra geração de firewall e IPS, com as funcionalidades necessárias ao ambiente naquela época.
O segundo motivo é que causa confusão. Os relatórios do Gartner são pagos. Esse sobre IPS, especificamente, custa 95 dólares americanos, e muita gente decide não comprá-lo. Mas mesmo quem não tem acesso total ao relatório quer comprar seu IPS de próxima geração e exige isso de seus provedores.  Já os fabricantes, que precisam responder aos seus clientes e prospectos, passam a chamar seu produto de next generation IPS e a  realçar as funcionalidades de “próxima geração” presentes em seu produto. Porém mesmo para estes a aderência ao critério difere, pois o Gartner não especifica funcionalidades de produtos. Não é de se estranhar portanto que o next-generation IPS do fabricante A seja bem diferente do next-generation IPS do fabricante B.  
A única solução a meu ver é o usuário conhecer o que está sendo proposto pelo Gartner , analisar se faz sentido para sua empresa e especificar as funções ao invés de apenas pedir genericamente um “IPS de próxima geração”. Mas importante ainda é entender qual o problema e contexto da proposição de um novo tipo de IPS.  O motivador do estudo é a percepção pelo Gartner que os sistemas atuais de prevenção de intrusos, de “primeira geração”, não estão sendo capazes de deter os novos tipos de ataques, mais sofisticados e direcionados, e portanto é necessário que a tecnologia embarcada nos produtos evolua.  Mas como os analistas do Gartner chegaram a essa conclusão? Esse e os demais estudos são análises de mercado. Como exposto no documento as fontes foram os clientes do Gartner afetados por tais ataques – grandes empresas normalmente - e os fabricantes listados nos relatórios “Magic Quadrant” do próprio instituto. O resultado final é a opinião dos analistas do que precisa ser mudado para fazer frente ao problema.
De acordo com eles a tecnologia atualmente adotada é a da detecção e bloqueio de tentativas de explorar vulnerabilidades não corrigidas em servidores ou  erros de configuração.  Ataques mais sofisticados com malware especialmente desenvolvido para um alvo, malware instalado involuntariamente e botnets fogem da definição inicial da tecnologia de IPS e não são eficientemente detectados ou bloqueados. Dessa forma os produtos deveriam incorporar outras funcionalidades, sem deixar de lado as originais, obviamente. São elas:
Conhecimento das aplicações e visibilidade de toda a pilha de protocolos – capacidade de identificar aplicações e detectar ataques no seu contexto, independente da porta e protocolos de transporte utilizados.  Em comparação, a tecnologia mais elementar de IPS está baseada em portas, protocolos e serviços elementares de rede.
Considero essa capacidade extremamente importante, tanto para o firewall como para o IPS, já que a Internet se move cada vez mais para cima, ou seja, para aplicações baseadas em navegadores e nos novos recursos disponíveis para colaboração  e interconexão de sistemas.  O estudo fala também em detectar aplicações hostis. O que é necessário então verificar com seus fornecedores? Primeiro, quantas aplicações são hoje reconhecidas e o roadmap para essa parte. Depois, Como a área de pesquisa está estruturada para adicionar novas aplicações, já que todas foram estruturadas para pesquisar ameaças e vulnerabilidades. Verificar qual a penalização em desempenho quando a funcionalidade está em uso é também essencial. Se o seu fornecedor disser que não há, é importante perguntar como.
Reconhecimento de contexto – capacidade do produto agir em função do contexto do evento detectado, a partir de bases de informação externas. O ponto principal é que essa funcionalidade é genérica e envolve na verdade diferentes funções. Uma delas é o uso de listas de reputação de endereço. Outras são a identificação dos usuários, posição geográfica da origem do tráfego, correlação com o estado de vulnerabilidade e aplicação de correções nos destinos do tráfego suspeito. Dessa forma se o seu fornecedor disser que seu produto reconhece contexto é importante perguntar quais as fontes usadas e qual o tipo de ação que o produto toma a partir delas.  Nunca peça simplesmente em uma RFP que o produto “reconheça contexto” porque você irá receber coisas diferentes de cada fabricante. Um bom exercício é consultar diferentes fabricantes e ver como eles o estão implementando. 
Reconhecimento de conteúdo – inspecionar e classificar de executáveis e outros arquivos como PDF e Word.  A minha impressão é que nesse ponto o Gartner não quer dizer que um IPS faço o papel de antivírus, mas que deve identificar o envio de arquivos de tipos específicos e utilizar isso como mais um elemento na decisão de liberar ou bloquear o tráfego associado.  
Motor expansível – é a minha tradução livre para “agile engine”, ou a capacidade do motor do sistema de receber facilmente expansões para detectar novas modalidades de ataque ou conectar-se a novas fontes de apoio a decisão.  Trata-se de um requerimento louvável mas bem genérico e difícil de ser verificado na vida real.
 No final precisamos entender que o produto descrito pelo Gartner não existe, e tampouco esse deve o objetivo deles.  Trata-se mais de uma lista de recomendações de funcionalidades que deveriam ser adotadas em complemento à tradicional detecção baseada em vulnerabilidades e ameaças. Talvez elas nem façam sentido em muitas das empresas de hoje, para as quais um firewall e IPS básicos já dão conta do recado.  

domingo, 5 de fevereiro de 2012

Sobre comentários

Pessoal, algumas vezes recebo comentários defendendo, ou com alguma propaganda, de um ou outro produto de mercado. Quando iniciei o blog decidi que seu foco seria temas relacionados à segurança em geral ou tecnologias, mas nunca a defesa ou crítica de produtos em específico. Quando cito fabricantes procuro fazer dentro desses contextos. Com esse principio em mente eu não aprovo comentários que façam apologia a algum produto. Espero que compreendam.


sexta-feira, 3 de fevereiro de 2012

Espionagem


A espionagem deve existir desde que o mundo é mundo e as tribos antigas começaram a brigar entre si, e, claro, não poderia deixar de usar novos meios para chegar aos seus objetivos. Um exemplo é um caso ocorrido em 2008 com os quadros digitais da marca Insignia, fabricados sob encomenda e vendidos nos Estados Unidos pela Best Buy, velha conhecida dos turistas brasileiros. Naquele ano um lote de quadros foi infectado durante o processo de fabricação, com o malware sendo implantado nos chips do aparelho e mirando senhas de jogos em computadores Windows. Pode não ser um caso isolado, tanto que o site Rationally Paranoid possui uma lista de produtos comerciais infectados em sua página ( http://rationallyparanoid.com/articles/malware-in-commercial-products-list.html ). Não verifiquei toda a lista mas alguns casos são reais e reconhecidos pelos fabricantes. 
Pois nações como o Estados Unidos estão com receio de que malwares voltados à espionagem sejam implantados também nos equipamentos de telecomunicações usados pelas empresas privadas do país. Um programa de controle bastante estrito já existe para os chips usados pelos sistemas militares que controlam as armas, e agora as autoridades parecem estar preocupadas com possíveis ações nas redes comerciais. Esse foi o teor de uma pesquisa que o Departamento de Comércio está realizando entre as empresas de telecomunicações americanas, para levantamento de hardware e software fabricado no exterior e em uso nas redes dessas empresas.  A principal inquietação parece ser a China mas inclui também funcionários de indústrias eletrônicas.   A China por eventuais ações patrocinadas pelo governo do país para interceptar dados confidenciais e os funcionários por ações individuais para infiltrar malware para ataques de negação de serviço ou roubo de dados, como aliás já foi feito, por má-fé ou acidente, nos casos relatados acima. De acordo com os sites de notícias há uma baita polêmica ao redor dessa ação, mas a preocupação é séria o suficiente para o governo americano ameaçar as empresas que não colaborarem com uma lei da época da guerra fria, da década de 50, que trataria a recusa em responder ao questionário como crime.
A infecção de componentes de hardware por malware não é algo novo, e há programas e métodos já conhecidos para implantar código malicioso diretamente na BIOS além do caso da vulnerabilidade no chip que controla a bateria dos MacBooks da Apple. A HP também divulgou recentemente uma vulnerabilidade, até onde sei não explorada, em sua impressora HP Laserjet. Mas a possibilidade da instalação de malware diretamente na fábrica é algo diferente e bem mais ameaçador.  O principal problema é a falta de controle dos clientes finais sobre o hardware que estão adquirindo. Computadores e dispositivos diversos de informática são hoje fabricados literalmente ao redor do mundo, com componentes vindo dos lugares mais diversos, independente da marca ser de uma companhia americana, europeia ou chinesa. Assim, ao adquirir um equipamento, seja um roteador de rede ou servidor, a empresa estará adquirindo um conjunto desconhecido de componentes, de origem também desconhecida. Os analistas de segurança dessa empresa irão pesquisar sobre vulnerabilidades no Windows da Microsoft ou no IOS da Cisco, mas nunca no flash disco que acompanha o equipamento. Aliás um controle de tal magnitude seria algo impensável e impossível. É do fabricante do equipamento acabado a responsabilidade dos componentes integrados, mas é justamente nesse quesito que reside as dúvidas dos americanos. E se o fabricante não tiver tal controle? E se o próprio fabricante estiver sendo usado pelo governo de seu país para espionar? No final uma eventual ação mal intencionada seria somente detectada durante ou após a execução de alguma função não esperada ou suspeita. Em se tratando de segredos comerciais ou nacionais, tarde demais.