Monday, September 28, 2009

Escopo de uma Análise de Vulnerabilidades: O que incluir?

Antes de mais nada, uma distinção rápida: Análise de Vulnerabilidades é realizada na própria rede da empresa, onde é feita uma varredura à procura de vulnerabilidades no ambiente, sem a interferência de firewalls ou roteadores com ACL's (Access Lists). Muitas vezes também são realizados testes locais no equipamento e algum tipo de ferramenta faz o levantamento da configuração do referido sistema. Isto é diferente de um Teste de Invasão, que normalmente é realizado a partir da Internet (embora em alguns casos seja feito a partir de um determinado segmento de rede interno), e tem por principal característica a realização de testes SEM o conhecimento prévio do ambiente e com o maior número possível de dispositivos de segurança ativos (até para poder testar sua eficácia).

Projetos de análise de vulnerabilidades baseados tanto em ferramentas automatizadas (Internet Scanner, Nessus, etc) quanto em verificações manuais (permissões, configurações em geral, etc) devem abranger a maior quantidade possível de dispositivos, sistemas operacionais, bancos de dados, etc.

Mas afinal de contas o que deve estar incluído no escopo? Muitas vezes a companhia não tem recursos suficientes para executar esta tarefa em casa e acaba optando pela contratação de uma consultoria especializada. E normalmente, estas consultorias cobram de acordo com a quantidade de dispositivos a serem testados. Por este motivo, surge sempre a dúvida em relação ao que incluir nestes testes.

Além dos servidores críticos (sim, acredite, uns são mais críticos que outros) e dos bancos de dados, segue uma breve lista com alguns "targets" interessantes e que normalmente são deixados de fora em um trabalho desta natureza (obviamente a lista não esgota todas as possibilidades, mas já é uma bom começo):
  • Desktops. De que adianta proteger os servidores se as máquinas dos usuários, que muitas vezes realizam atividades administrativas na rede estão desprotegidos? Inclua máquinas que representem um padrão específico de configuração (exemplo: caso haja configuração idêntica para todas as máquinas de RH, não é necessário testar todas. O mesmo vale para desktops/laptops de TI, Produção, Vendas, etc).
  • Impressoras. É isso mesmo. Não se esqueça que existe um sistema operacional na impressora, muitas vezes com um webserver para configuração do equipamento, além de ter um filesystem que poderia, por exemplo, ser usado para armazenar imagens pornográficas, músicas ou programas piratas, etc.
  • Access Points. É impressionante a quantidade de equipamentos DLINK, TPLINK, etc, com configuração "default", com usuário "admin", senha "admin". Configuração aberta ou utilizando o protocolo WEP? My goodness...
  • Servidores de FAX. Dá pra pensar inclusive em testes de wardialing. O que tem de servidor HP-UX e outros tipos de Unix com placas de modem ativas... Mas o que um servidor de FAX pode ter de tão arriscado? Não sei, eu é que pergunto. Que tipo de informação trafega por este tipo de equipamento?
  • Centrais Telefônicas. Pois é. Há alguns anos atrás (não tantos assim), me deparei com uma central telefônica da Nortel (especificamente uma Alcatel 4400), cujo sistema operacional era um tal de Chorus/Mix, que nada mais era do que uma versão modificada de Unix System V, inclusive com as mesmas falhas de segurança das versões antigas de Unix. Um verdadeiro queijo suiço e em uma central telefônica. A coisa era tão grave que dava para usar o famoso comando: # rm -rf / (não tente isso em casa...).
  • Mainframe. Telnet? FTP? Pois é, colocaram IP no mainframe...
A pergunta é: Tem IP? Se tem, são grandes as chances de eventuais explorações de vulnerabilidades. Aliás, imagine quando as cafeteiras estiverem conectadas à internet (com IP), rodando algum tipo de Windows Coffee Mobile e podendo ser configuradas remotamente? E torradeiras? E os carros com seus sistemas operacionais FiatOS, GeneralM_OS, FordOS, Hyundai Operating System? Ou pior, se estiverem rodando algum tipo de Linux ou WCMS - Windows Car Mobile System (se usarem, quero royalties)?

Eu costumava brincar em treinamentos com a seguinte teoria: Tem IP? E pior, está roteando na rede corporativa? Entonces...

Saturday, September 12, 2009

Neurônios Filosóficos - Parte 4: Redes Sociais e meus dados pessoais...

Difícil essa vida 2.0, não é mesmo? Afinal de contas temos que manter tantos perfis diferentes em diversos sites de relacionamento! Linkedin, Orkut, Facebook, Naymz, Myspace, entre tantos outros.

O que realmente impressiona é a facilidade com que as pessoas divulgam dados pessoais como números de celular, telefone residencial, quantidade de parentes (sim, pelas fotos e legendas, ficamos sabendo quem é pai, mãe, filho, sobrinha, filho, etc).

Depois não entendemos de onde os caras do mal, confortavelmente instalados nas luxuosas instalações dos presídios brasileiros, conseguem nossos dados! Puxa, se ele falou que minha filha se chama Adriana, tem um carro modelo Palio cor preta, e que ainda por cima ela é loira de olhos azuis, ele só pode estar falando a verdade!

Há pessoas, principalmente os mais idosos, que já tiveram até enfartos, sem contar os que caíram em golpes e transferiram dinheiro ou compraram créditos de celulares pré-pagos.

Ok, então isso quer dizer que não podemos participar de redes sociais? Obviamente não, mas o mínimo de cuidado com as informações que divulgamos é altamente recomendável, para não dizer que é prudente...

Saturday, September 5, 2009

Métricas - Parte 1: Um aspecto importante em Segurança da Informação

Olá, depois de uma semana muito corrida, finalmente arrangei um tempinho para atualizar o blog. A partir de hoje publicarei uma série de posts referentes a um assunto de suma importância para aqueles que trabalham na área e precisam muitas vezes justificar os caros investimentos em equipamentos, software, treinamentos, etc. Aliás, não só justificar investimentos, mas saber o que está acontecendo. Trata-se das Métricas de Segurança.

Um bom Sistema de Gestão de Segurança da Informação (SGSI) deve contemplar um monitoramento constante, tanto de sua efetividade, quanto dos controles implementados (Anexo A da ISO 27001 ou a própria ISO 27002).

Antes de entrar no mérito de alguns indicadores importantes, o que acontecerá em posts futuros, segue uma lista interessante de materiais de referência sobre o assunto:

NIST - Recommended Security Controls for Federal Information Systems
NIST - Performance Measurement Guide for Information Security
NIST - Guide for Assessing the Security Controls in Federal Information Systems
NIST - Directions in Security Metrics Research

Todas as referências acima são excelentes fontes de informação que permitem iniciar um processo formal de desenho, implantação, monitoração e aperfeiçoamento de indicadores de segurança da informação.

O mais importante é que cada indicador seja baseado em um conceito amplamente conhecido, que é o SMART:
  • S (Specific) - A métrica deve ser específica e diretamente relacionada ao que se quer monitorar;
  • M (Measurable) - A informação deve ser acurada e completa. Os indicadores devem ter valores numéricos (numerais, percentuais) e não subjetivos;
  • A (Actionable) - A informação deve ser clara e permitir a fácil identificação de que o indicador sinaliza algo "bom" ou "ruim";
  • R (Relevant) - Bem óbvio, afinal de contas não devemos perder tempo medindo algo que não sirva para nada;
  • T (Timely) - Sempre que precisarmos, a informação deve estar disponível.  Imagine o chefe pedindo dados que precisam de 3 horas para preparação!
Para finalizar este post, é importante ter em mente que um indicador deve ser sempre fácil de gerar, deve ser o mais automatizado possível (imagine ter que contratar alguém só pra gerar planilhas e depois copiar e colar informações), e principalmente fácil de entender (principalmente através de gráficos que permitam o acompanhamento ao longo do tempo).

Uma sugestão de especificação simplificada de um indicador pode ser observado na tabela abaixo (para maiores detalhes de como criar um indicador, vide os links apresentados acima):


 A ideia é sugerir indicadores de acordo com as necessidades de controles da ISO 27002, em futuros posts. Até lá!