O Blackberry e os smartphones em geral estão sendo responsáveis por malentendidos corporativos e alguns pequenos vazamentos de segurança. A grande maioria dos usuários de smartphone tem o hábito (por alguma necessidade inexplicada) de responder o mais rápido possivel qualquer mensagem, seja a hora que for. O sujeito está as 11 da noite na cama, pronto para dormir, decide dar uma última olhadilha e ...feito. Em segundos responde ou encaminha a mensagem sem ler todo o histórico (que alias é mais dificil nas telas pequenas) ou pensar com cuidado.
Tenho dois bons exemplos reais. Uma vez recebi um email que era direcionado a outro Marcelo, com informações que com certeza não deveria nunca ter recebido. Em outra ocasião enviei um email com informações de uso restrito, com o devido alerta, e a pessoa deu simplesmente um "forward" para um destinatário externo. Disse que não viu o alerta de confidencialidade. São casos que poderiam ocorrer também em um PC, mas que são potencializados pela loucura do acesso instantâneo.
PS. Escrevi esse post em meu BB (blackberry para os íntimos).
quarta-feira, 10 de março de 2010
terça-feira, 9 de março de 2010
Comparando Produtos de Segurança de Redes
Adquirir produtos de segurança de rede nem sempre é uma tarefa fácil. Há múltiplas opções, o que é ótimo para todos, e que requer que o comprador compare muito bem os produtos para adquirir aquele que melhor se adapte ao seu uso – perfil de rede, aplicações e negócio. Algumas grandes empresas possuem o privilégio de contarem com laboratórios internos de testes, ou recursos para contratar um terceiro para fazê-los de maneira personalizada. Mas a realidade da maior parte das empresas brasileiras é diferente, precisando tomar sua decisão baseados em datasheets, comparações de terceiros e referências de clientes.
Para todos a comparação de produtos de segurança envolve três partes básicas: a eficiência do mecanismo de proteção, o desempenho de rede e a usabilidade. Para aqueles que podem testar produtos internamente, os testes de eficiência devem ser realizados com ferramentas apropriadas, como o MetaExploit, um framework aberto disponível em http://www.metasploit.com/, e o BreakingPoint - http://www.breakingpointsystems.com. O principal cuidado é que o teste possa realmente medir a capacidade de proteção do produto, sobretudo para ataques mais sofisticados. Não vale executar scripts manjados ou simples demais, pois qualquer produto irá detectá-los. Uma alternativa para os testes internos, e a única para quem não pode testar, é confiar em comparativos de publicações especializadas ou órgãos independentes. Mas cuidado! É importante ler com atenção e entender como o teste foi realizado, e não ir diretamente ao famoso quadro do “Editor’s Choice”. Recomendo os testes do NSS Labs, http://www.nsslabs.com/. O NSS é sempre independente, e obtém sua receita pela venda de seus relatórios. Há, claro, outros órgãos que realizam seus testes e devem ser consultados.
O desafio é ainda maior ao comparar o desempenho de rede. Não há regras que a serem seguidas pelos fabricantes, apenas o bom senso e honestidade. A maior parte dos erros ocorrem por falha na interpretação dos datasheets de informações dos produtos. Para quem for testar em laboratório, recomendo a adoção das RFPs abaixo:
Throughput é com certeza o mais mal interpretado, e o que causa maior desapontamento. Primeiramente, devemos evitar a confusão de throughput com largura de banda, a capacidade nominal da rede. Não é dificil encontrar redes com largura de banda de 1Gbps mas com volume real muito menor, abaixo de 500 Mbps. Portanto, o thoughput requerido de um produto deve se basear no volume real existente. Outro problema é não associar o valor de throughput com o perfil da rede (protocolos e tamanho do pacote) usado para a medição. Todos os fabricantes, por motivos de marketing, publicam seus dados de performance em condições ótimas, o que significa transmissão de pacotes de 1518 bytes. Apesar de servir como comparação, esse valor não quer dizer quanto o equipamento irá render em uma situação de rede real. Algumas pessoas então pedem o throughput com pacotes de 64 bytes, o que também não quer dizer nada, já que também não representar um perfil real de rede. O meio termo, 512 bytes, tampouco representa a realidade.
Para cobrir esse lacuna a indústria adotou um padrão de fato, denominado de iMIX (Internet Mix), criado em 2001. O iMIX é a representação de um perfil de tráfego real, e é o melhor perfil a ser utilizado para comparar produtos. A grande maioria dos fabricantes publica índices de desempenho em relação ao iMIX, e muitos seguem a RFC2544 na hora de executarem seus testes. Essa padronização permite que possamos comparar “bananas com bananas”. Como exemplo, um IMIX para TCP compreende a seguinte combinação:
O terceiro elemento é a usabilidade, ou o nível exigido de conhecimento para configurar e operar o produto. Mais uma vez a melhor fonte de informação vem de análises de terceiros e referências de clientes. Esse critério tem que ser analisado com base no perfil dos operadores do produto e irá impactar os custos na parte de treinamento. Vale lembrar que não há regras, logo um fabricante pode publicar seus dados da maneira que achar melhor. O papel do comprador, portanto, será de questionar, questionar e questionar.
Para todos a comparação de produtos de segurança envolve três partes básicas: a eficiência do mecanismo de proteção, o desempenho de rede e a usabilidade. Para aqueles que podem testar produtos internamente, os testes de eficiência devem ser realizados com ferramentas apropriadas, como o MetaExploit, um framework aberto disponível em http://www.metasploit.com/, e o BreakingPoint - http://www.breakingpointsystems.com. O principal cuidado é que o teste possa realmente medir a capacidade de proteção do produto, sobretudo para ataques mais sofisticados. Não vale executar scripts manjados ou simples demais, pois qualquer produto irá detectá-los. Uma alternativa para os testes internos, e a única para quem não pode testar, é confiar em comparativos de publicações especializadas ou órgãos independentes. Mas cuidado! É importante ler com atenção e entender como o teste foi realizado, e não ir diretamente ao famoso quadro do “Editor’s Choice”. Recomendo os testes do NSS Labs, http://www.nsslabs.com/. O NSS é sempre independente, e obtém sua receita pela venda de seus relatórios. Há, claro, outros órgãos que realizam seus testes e devem ser consultados.
O desafio é ainda maior ao comparar o desempenho de rede. Não há regras que a serem seguidas pelos fabricantes, apenas o bom senso e honestidade. A maior parte dos erros ocorrem por falha na interpretação dos datasheets de informações dos produtos. Para quem for testar em laboratório, recomendo a adoção das RFPs abaixo:
- RFC 2544 Benchmarking Methodology for Network Interconnect Devices - http://www.ietf.org/rfc/rfc2544.txt -
- RFC 1242 Benchmarking Terminology for Network Interconnection Devices - http://www.ietf.org/rfc/rfc1242.txt -
- Throughput: é o mais solicitado, usado e malinterpretado. Trata-se da taxa de transmissão de pacotes da porta de entrada para a porta de saída do equipamento. Está totalmente relacionado com o tamanho dos pacotes. Deve ser considerado em todas as situações.
- Pacotes por segundo: Mede a quantidade de pacotes de 64 bytes (o menor tamanho considerado na RFC 2544) que o equipamento pode processar sem perdas. Medido em milhões, serve para demonstrar a capacidade do equipamento em sua pior situação de uso, e é um bom elemento de comparação.
- Latência: Mede o atraso sofrido pelos pacotes ao passarem pelo equipamento. Muito se fala de latência, mas na verdade poucas redes tem exigências rígidas. Não há um número mágico em latência, já que depende da rede e suas aplicações, mas valores de 100 a 150 microsegundos atendem à maior parte dos casos.
- Conexões simultâneas: Mede a quantidade de conexões abertas e simultâneas suportadas nos sistemas orientados à conexão, como os firewalls e IPS. Deve ser considerado como algo meramente informativo a não ser que seja realmente necessário, e há poucos tipos de rede, como as das operadoras de celular, que realmente exigem valores muitos altos, na base dos milhões. Uma rede de empresa tipicamente não irá passar de alguns milhares, atendido pela totalidade dos produtos hoje existentes.
- Novas conexões por segundo: Como o nome fala, trata-se da capacidade do equipamento em suportar novas conexões. É uma grande bobagem solicitar valores altos, como 50 mil, a não ser que seja realmente necessário. Em outras palavras, que aquele número de usuários ou transações irá simultaneamente conectar-se em um segundo e passar pelo equipamento. Uma alta capacidade de novas conexões por segundo ou mesmo conexões simultâneas não significa que throughput e latência sejam os melhores.
Throughput é com certeza o mais mal interpretado, e o que causa maior desapontamento. Primeiramente, devemos evitar a confusão de throughput com largura de banda, a capacidade nominal da rede. Não é dificil encontrar redes com largura de banda de 1Gbps mas com volume real muito menor, abaixo de 500 Mbps. Portanto, o thoughput requerido de um produto deve se basear no volume real existente. Outro problema é não associar o valor de throughput com o perfil da rede (protocolos e tamanho do pacote) usado para a medição. Todos os fabricantes, por motivos de marketing, publicam seus dados de performance em condições ótimas, o que significa transmissão de pacotes de 1518 bytes. Apesar de servir como comparação, esse valor não quer dizer quanto o equipamento irá render em uma situação de rede real. Algumas pessoas então pedem o throughput com pacotes de 64 bytes, o que também não quer dizer nada, já que também não representar um perfil real de rede. O meio termo, 512 bytes, tampouco representa a realidade.
Para cobrir esse lacuna a indústria adotou um padrão de fato, denominado de iMIX (Internet Mix), criado em 2001. O iMIX é a representação de um perfil de tráfego real, e é o melhor perfil a ser utilizado para comparar produtos. A grande maioria dos fabricantes publica índices de desempenho em relação ao iMIX, e muitos seguem a RFC2544 na hora de executarem seus testes. Essa padronização permite que possamos comparar “bananas com bananas”. Como exemplo, um IMIX para TCP compreende a seguinte combinação:
- 58% dos pacotes com 90 bytes
- 2% com 92 bytes
- 23% com 594 bytes
- 17% com 1518 bytes
O terceiro elemento é a usabilidade, ou o nível exigido de conhecimento para configurar e operar o produto. Mais uma vez a melhor fonte de informação vem de análises de terceiros e referências de clientes. Esse critério tem que ser analisado com base no perfil dos operadores do produto e irá impactar os custos na parte de treinamento. Vale lembrar que não há regras, logo um fabricante pode publicar seus dados da maneira que achar melhor. O papel do comprador, portanto, será de questionar, questionar e questionar.
Assinar:
Postagens (Atom)