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

quarta-feira, 21 de dezembro de 2011

Gerenciando seus Firewalls


A primeira vista a tarefa de gerenciar uma política de firewall não deveria ser das mais complicadas. A primeira lição para quem se inicia no tema não deixa de ser inspiradora para uma vida tranquila: bloqueie tudo e libere apenas o que tem que ser liberado. E realmente a tarefa não é complicada quando a empresa tem poucos dispositivos e poucas regras para gerenciar.  Essa situação no entanto muda quando uma dessas variáveis é alterada. Uma situação típica é quando a empresa precisa aderir à alguma norma regulatória do governo ou do mercado, como o PCI-DSS da indústria de pagamentos por cartão. Basta o diretor de segurança avisar ao administrador do firewall que ele precisa adequar a política de segurança a uma determinada regra que a coisa começa a complicar.

Em geral eu recomendo que uma empresa busque um produto complementar de administração de firewall quando ao menos uma das condições abaixo existe:
  • Há muitos firewalls não isolados em funcionamento. Por não isolados quero dizer dispositivos que protegem diferentes segmentos da mesma rede, e portanto um usuário ou grupo pode ter acesso via mais do que um deles. É como se a empresa tivesse uma única e grande política distribuída entre diversos equipamentos;
  • Há firewalls de diferentes fabricantes em operação, situação comum em fusões ou aquisições (sem contar é claro empresas de datacenter e gerenciamento de segurança, para os quais tais sistemas é quase um requerimento);
  • Quando a política de segurança implementada é muito extensa e granular, fazendo com que mudanças de regras seja sempre uma tarefa complexa. Nesses ambientes encontramos facilmente regras conflitantes e muitas já inúteis, cujo único efeito prático é aumentar a carga de processamento do equipamento.
  • Existe a necessidade se aderir a normas regulatórias que implicam em adequações nas regras de acesso a sistemas ou segmentos de rede.

segunda-feira, 12 de dezembro de 2011

Dúvida existencial

Em quase vinte anos de profissão em segurança da informação não consegui ainda entender porque os orçamentos e segurança são tão pequenos. Certamente é um problema conosco, profissionais da área,  mas para mim é ainda um mistério o que deve ser feito para mudar isso. Até hoje não entendo por que a mesma empresa que responde a uma pesquisa dizendo que "segurança é prioridade" compra o firewall (ou qualquer outro sistema de segurança) mais barato enquanto faz questão de comprar os switches e roteadores que entregam tudo o que é pedido pela área de redes, sendo muitas vezes o mais caro da concorrência. 
Por que mesmo empresas de grande porte aceitam firewalls grátis de seus fornecedores de rede? Elas aceitariam um switch de backbone grátis de seu fornecedor de segurança? Certamente não. Pois é...

quinta-feira, 8 de dezembro de 2011

Centro de Defesa Cibernética

Vale registrar a estruturação no Brasil do Centro de Defesa Cibernética (CDCiber) a cargo do Exército, além da ação continua pelo Gabinete de Segurança Institucional da Presidência da República em aperfeiçoar a segurança da informação do governo em geral. Sendo a guerra cibernética mito ou não, o Brasil precisa estar preparado para lidar com uma agressão vinda de fora ou de dentro do país, sejam ações juvenis como os ataques do meio desse ano ou vindas de grupos profissionais visando a Copa do Mundo ou Olimpíadas. Ver para crer nesse caso seria uma péssima opção. 

quarta-feira, 7 de dezembro de 2011

Como sua empresa compra segurança de rede?

Olá. Fiquei um longo período sem atualizar o blog, resultado de várias viagens, correria de compromissos de trabalho, etc e tal. Mas nunca é tarde para retomar, e justamente com um tema que foi recorrente nesse ano: RFPs para compra de equipamentos de segurança de redes mal escritas. O resultado é que nesses casos ou a empresa compra errado, mais ou menos do que realmente precisa.  

O gancho é uma pesquisa divulgada pela Crossbeam Systems e disponível no site da empresa.  Bastante original, o objetivo era entender como as empresas tratam as informações de desempenho e capacidade fornecidos pelos fabricantes de sistemas de next generation firewall (firewalls que integram outras funções como prevenção de intrusos), assim como se suas aquisições foram ou não bem-sucedidas nesse quesito. O resultado não me surpreendeu: a maior parte das empresas, inclusive as grandes corporações, não sabem como interpretar os dados de desempenho informados nos datasheets e muitas vezes erram na aquisição. No outro lado, poucos fabricantes se esforçam em detalhar a capacidade de seus produtos, ou fornecem dados que permitiriam às empresas entender o que estão comprando. Mas a culpa está dividida entre ambos, vendedores e compradores. Antes vale uma olhada nos resultados da pesquisa:
  • 58% dos participantes não confiam nos dados de desempenho informados pelos fabricantes. No setor de telefonia móvel, o índice foi de 78%. No entanto, mesmo entre os que confiam nos fabricantes, 80% não acreditam nos dados publicados em datasheets.
  • 90% responderam que sempre ou algumas vezes tiveram que fazer concessões em sua segurança para não afetar o desempenho dos produtos, e incríveis 81% afirmaram que tiveram que desabilitar funcionalidades de segurança em seus dispositivos de proteção para não comprometer o desempenho da rede.
  • 63% afirmaram que foi necessário adquirir hardware adicional após a primeira aquisição porque os produtos não tiveram o desempenho esperado, tal qual informado nos datasheets.
  • 43% não realizam testes nos equipamentos em condições reais.
Há muito o que analisar nesses resultados, mas o fato é que há uma desconexão grave entre ambos fabricantes e usuários quando o assunto é performance. O primeiro passo para sair desse dilema é compreender que as informações publicadas em datasheets, salvo quando informado em contrário, referem-se ao máximo de desempenho na melhor situação possível. Ou seja, informam praticamente a capacidade de transmissão de dados sem processamento real de segurança. Mas é importante dizer que isso não caracteriza má fé. É um critério, o mais fácil porém não o ideal para comparação, porque na hora de ajustar-se ao ambiente real das empresas cada produto irá responder de uma maneira, e alguns chegam a redução de até 90% de performance. Por outro lado essa abordagem é respaldada quando uma empresa publica RFP pedindo apenas “x Gbps de throughput” sem especificar mais nada. Essa é a origem de todos os problemas de aquisição mal sucedida: confundir throughput com desempenho.
Infelizmente é preciso considerar também que alguns fabricantes exageram as “melhores condições” em seus números de performance. Alguns publicam seus números sem explicar que são dados atingidos com aceleração de tráfego, sem no entanto explicar como funciona, quando se aplica e, pior, que poucas vezes se aplica. Há casos também que o throughput é o somado em ambas as direções, quando um equipamento de 10 Gbps pode na verdade transmitir 5 Gbps em cada direção.  Outro caso é de fabricantes de IPS que publicam seus números com uma política de segurança frouxa, mínima, que na prática não server para proteger ninguém.
Throughput
O primeiro passo para comprar bem é entender que throughput, a capacidade de transmissão de dados de um equipamento, é relativa em dispositivos de segurança. Relativa porque um equipamento de segurança precisa processar os dados antes enviá-los, e todos, seja baseado em chips especializados ou em processadores normais, tem sua capacidade real medida em pacotes por segundos. Se esses pacotes forem maiores então o throughput é maior, se forem menores, então ele será menor. O desempenho depende também do tipo de tráfego, ou os protocolos que estão sendo transmitidos, porque alguns produtos processam um protocolo mais rapidamente que outro.
Então na hora de analisar e adquirir um produto de firewall ou intrusion prevention system, recomendo solicitar o seguinte: 

(a) Throughput de x Gbps com as seguintes condições: 
  • Tamanho médio de pacote, ou distribuição do tráfego por tamanho de pacotes
  • Distribuição do tráfego por tipo de protocolo
  • Funcionalidades que serão ativadas, como NAT, IPS e outras
  • Se o throughput é full duplex (x Gbps em ambas as direções)
  • Tamanho da política ou das regras que serão ativadas, especificando por exemplo que o produto terá todas as regras de prevenção de ataques ativadas
Switch Fabrics
Outro elemento essencial é como o equipamento será conectado à rede. Imaginem dois equipamentos de firewall com capacidade nominal de 10 Gbps e ambos com portas de 10Gbps. O primeiro permite que uma única porta de 10 Gbps seja utilizada enquanto o segundo exige que duas portas sejam usadas porque, embora a capacidade nominal das portas seja 10Gbps, o switch fabrics por trás delas somente suporta 5 Gbps para cada uma. Diferente, não? E pior, somente será detectado na hora de instalar. A segunda recomendação então é exigir: 

(b) que o throughput solicitado seja alcançado através da utilização de x portas de tal capacidade. De preferencia incluir algum diagrama deixando claro como o equipamento deverá suportar a capacidade exigida.
Sessões Simultâneas e Novas Conexões por Segundo
Mas há outros elementos além do throughput, e até mais importantes em alguns segmentos. Para provedores de serviço como sites e empresas de celulares, é mais importante definir sessões simultâneas que throughput. Um único usuário com iPhone irá consumir durante o dia até dez sessões simultâneas, e milhares de usuários consumirão dessa forma milhões de sessões, mesmo que o throughput não seja tão alto assim. Juntamente com as sessões simultâneas temos a quantidade de novas conexões que o produto irá processar por segundo. São novos usuários conectando-se ao mesmo tempo à rede da empresa. Esse elemento é também chamado em inglês de connection rate. Dessa forma recomendo exigir:
(c) X sessões simultâneas
(d) X novas conexões por segundo (cps)

Latência
Por fim temos a latência. Em geral apenas produtos ruins terão latência tão alta que prejudique a performance geral das aplicações, porém aplicações de voz ou vídeo exigem baixa latência, medida em microssegundos (μS). Para uso geral uma latência média inferior ou igual a 150 μS atenderá a maior parte das empresas. Temos assim a recomendação:
(e) Latência média igual ou inferior a 150 μS
Quanto mais próximo da realidade for cada item, melhor será a aquisição e menos dores de cabeça aparecerão na hora de usar a solução comprada. Com exceção de novas redes, todos esses dados estão disponíveis via relatórios dos equipamentos de rede e segurança já instalados. Recomendo adicionar algum espaço para crescimento e evitar exageros. Pedir demais também significa comprar errado.