Mas como, se muitos profissionais da área afirmam que este é o caminho? Exatamente por isto que eu credito este problema a nós mesmos profissionais que atuamos na área.

Hoje a maioria dos clientes coloca como critério para projetos de segurança em desenvolvimento a aderência a ISO/IEC 15408 e para Penetration Test a utilização de alguma metodologia como OSSTMM. Colocam porque durante anos os profissionais pregaram e divulgaram tais informações. O pior, na grande maioria das vezes quem divulga nunca aplicou e muitas vezes se quer conhece o padrão. Muitos profissionais amparam todo o seu discurso, argumentos em chavões, mentiras ditas tantas vezes que acabam virando verdade.

Por que OSSTMM não é referência para Penetration Test?

O primeiro grande desafio é ter o documento completo, a OSSTMM está em desenvolvimento há anos e nunca se teve conhecimento de toda metodologia, abordagem proposta. Todo o desenvolvimento é baseado em puro marketing, mesmo pagando a taxa pelo suposto método completo, ele sempre está incompleto e em desenvolvimento. E vou falar, eles sofrem de um problema sério de falta de produtividade, este cenário permanece por anos.

Bom, vamos falar da parte que existe. A documentação não apresenta fases que sejam viáveis para um Penetration Test, ele apresenta um número grande de coisas que devem ser analisadas e não passa disto. Um outro ponto que é difícil de se implementar na prática é uma abordagem quantitativa chamada rav. Esta abordagem prevê que seja analisado os controles e pontuado de acordo com um critério que, após o cálculo usando a fórmula apresentada, irá determinar uma pontuação ao ambiente. De acordo com a pontuação o ambiente é considerado mais ou menos seguro.

Abordagem quantitativas são a eterna busca de gestores na área de tecnologia, busca louvável, mas em Penetration Test isto é ineficaz e inútil. Sim, o propósito de um Penetration Test é identificar fragilidades que possam levar ao comprometimento do ambiente e não ser uma análise de riscos. A análise do Penetration Test irá apresentar uma análise qualitativa e servirá como uma das n variáveis de uma análise de riscos quantitativa. Está análise irá determinar qual o controle deve ou não ser implementado de acordo com o risco associado ao ambiente e o custo envolvido na solução versus o impacto que pode causar no ambiente.

Resumindo, OSSTMM não pode servir de referência para realização de um Penetration Test. O profissional que executa estes projetos com freqüência desenvolve seu próprio método levando em consideração as características do mercado que atua e a necessidade de organizar e apresentar os resultados esperados pelo cliente. Já escrevi algumas idéias sobre metodologia em Penetration Test e também recomendo a leitura do documento SP 800-115 (Thecnical Guide to Security Testing) do NIST.

Por que a ISO/IEC 15.408 não é referência para segurança em desenvolvimento?

Existem vários motivos que levam ao entendimento claro de que a ISO/IEC 15.408 ou Commom Criteria não é para segurança em desenvolvimento, mas o Geraldo Fonseca no Twitter deu uma descrição breve e que para mim é perfeita:

"@gfonseca_  @welias  cc/15408 é framework de avaliação, não de desenvolvimento. É para avaliar o "fato consumado", e não para ajudar a criar algo seguro."

É exatamente isto, ela não propõe ou valida nenhum método para se conseguir chegar ao desenvolvimento de um código seguro. Ela apresenta apenas alguns critérios que um produto de software deve ter para que possa ser acreditado por laboratórios credenciados. Define características que um software deve ter. Mas como eu chego lá? Procuro lá na ISO/IEC 15.408 e me diz.

Bom, se você leu pode responder que ela não apresenta nada disto. Para se conseguir um software seguro é preciso ter um processo maduro e implementar práticas de segurança em código, testes e principalmente um trabalho de conscientização e treinamento dos profissionais envolvidos. 

Um post do Fernando Cima comenta sobre o relatório "State of the Art of Software Security Assurance" do Departamento de Defesa americano e o papel da ISO/IEC 15.408. Eu também escrevi um artigo para revista da ISSA.

Não que eu queira jogar uma bomba de fumaça, mas é necessário orientar as pessoas, pesquise neste cara aqui e verifique se você encontra alguma referência internacional que associe o uso da ISO/IEC 15.408 como base para desenvolvimento seguro.

Pesquisou? Pois é, não encontrou nada.

Agora procura em português. Bingo! Existem várias citações a ISO/IEC 15.408 para desenvolvimento seguro. Este "fenômeno" eu credito a este livro: SEGURANÇA NO DESENVOLVIMENTO DE SOFTWARE

Mas o propósito do livro é claro: Como desenvolver sistemas seguros e AVALIAR A SEGURANÇA DE APLICAÇÕES DESENVOLVIDAS COM BASE NA ISO 15.408

Ah! Ai é outra história! A maioria das pessoas virá especialista apenas lendo a capa de um livro, ou no melhor dos casos, fazendo como o Pateta do Walt Disney que lê o início e o fim do livro.

Como o título foi extremamente sensacionalista e na minha opinião, as declarações de Chess foram bastante parciais em favor do produto/negócio da Fortify, as interpretações não foram as melhores.

Ivan Arce CTO da Core Security escreveu um outro artigo para o mesmo portal com o título: Twelve Reasons Pen Testing Won't Die

Neste artigo Arce "contra-ataca" Chess e faz uma brincadeira criando o acrônimo, SISSP (School of Information Systems Security Prophets) e descreve de forma muito clara inúmeros motivos para se realizar testes de segurança (pen-tests).

No maior estilo Schopenhauer, Chess, escreveu outro post no blog da Fortify: Penetration Testing is Dead, Long Live Penetration Testing

A minha opinião sobre esta novela toda é: Muda-se o nome, muda-se a "roupagem" mas os testes de segurança sempre deverão ser feitos. Afinal, como será garantido que os produtos mesmo após um bom SDL (secure Development Lifecycle) são realmente seguros como deveriam ser? Como diria Michael Howard: "Ou você testa ou alguém ira testar por você".

Pergunta: que controle você testou com isso? Você apenas irá saber que precisa de uma campanha de conscientização, não terá nenhum tipo de validação dos controles de perímetro da sua rede.

Testes como esse podem ser usados para testar o nível de conscientização de seus usuários, mas nunca como ferramenta de avaliação de controles técnicos. E lamentavelmente muitos acham isso a última maravilha do mercado de segurança, pois, saibam todos que a técnica já não tinha nada complicado e agora ficou mais prático e banal com a implementação desta feature no metasploit 3.2. vejam os exemplos a seguir:

Criando um pdf com backdoor

Criando um arquivo do word com backdoor

Agora faça o seguinte, procure profissionais sérios e competentes para testar seus controles de segurança, não aceite qualquer coisa.

Além deste guide outros paper/guides podem ser acessado aqui.

Excelente material, esse guia se junta a outro material excelente sobre  IPsec.

No site da Wireshark University você pode saber mais sobre a iniciativa e comprar os DVDs que são base para a preparação.

Além deste conteúdo, é possível acessar gratuitamente uma série de paper e vídeos no próprio site.

A notícia foi dado com um certo alarde pelas comunidades de segurança. A Cisco divulgou um documento sobre como tratar esta possibilidade de infecção por um Rootkit.

O paper basicamente trata de boas práticas de hardening (Controle de Acesso, Logs, etc...) e obviamente fala da utilização de hash para validação de integridade do IOS. Vale a leitura.

Muitos profissionais citam alguns pontos negativos da utilização de uma metodologia:

• Um método previamente descrito limita as ações/técnicas do analista;
• Teste de intrusão é uma arte e não uma prática;

Eu vejo um certo desconhecimento do que é metodologia quando vejo citações como essa. Afinal, metodologia não é instrução de trabalho e sim uma descrição dos métodos para chegar aos resultados.

O que são métodos?

“A palavra método vem do grego méthodos, (caminho para chegar a um fim). O método científico é um conjunto de regras básicas para desenvolver uma experiência a fim de produzir novo conhecimento, bem como corrigir e integrar conhecimentos pré-existentes. Na maioria das disciplinas científicas consiste em juntar evidências observáveis, empíricas (ou seja, baseadas apenas na experiência) e mensuráveis e as analisar com o uso da lógica. Para muitos autores o método científico nada mais é do que a lógica aplicada à ciência (Haddad).
Metodologia literalmente refere-se ao estudo dos métodos e, especialmente, do método da ciência, que se supõe universal. Embora procedimentos variem de uma área da ciência para outra (as disciplinas científicas), diferenciadas por seus distintos objetos de estudo, consegue-se determinar certos elementos que diferenciam o método científico de outros métodos (filosófico, algoritmo – matemático, etc.).”
Fonte: Wikipedia

Para que serve a Instrução de Trabalho?

“a mesma tem como função básica definir todo o funcionamento de um processo, para que os envolvidos entendam o mesmo de um forma só, considerando que todas as suas etapas são fundamentais, e quando no caso de uma auditoria o mesmo tenha os seus processos definidos e documentados e sendo o mesmo deverá realizar através de inspeção e ou auditoria interna se o mesmo processo atende o documento elaborado ou vice e versa.”
Fonte: ISO 9001

Esclarecendo este ponto, fica claro que um pen-test necessita sim de uma metodologia clara. Os seguintes pontos podem estar descritos na metodologia:

• Quais as etapas serão seguidas para atingir o resultado;
• Qual o papel de cada analista no processo;
• Como será manuseada e armazenada as informações do cliente;
• Como será divulgada informações confidenciais que forem identificadas;

Ao contrário de que alguns pregam, metodologia não é diferencial é obrigação, exija sempre que contratar um serviço de consultoria.

Não deixe de conferir mesmo que não seja usuário de Mac, pois o guide tem muitos detalhes e é bastante útil para profissionais de segurança.

Leopard Security Config

Um dos participantes dos estudos é o Andrew S. Tanembaum, aquele mesmo das discussões com Linus Torvalds e que conhece um pouco de Sistemas Operacionais.

No site é possível conhecer um pouco sobre RFID e ter acesso a informações de como escrever vírus para RFID.

[UPDATE] Meu amigo Lucas também escreveu sobre o tema, recomendo a leitura.

Uma pena que muitos C-Levels achem interessante deixar sua marca/negócio exposto desta maneira. Colocar um selo dizendo que seu site é seguro porque está sendo monitorado por um grande player é um tremendo chamariz.

Dêem uma olhada neste vídeo.

O problema é que através deste recurso pode-se roubar informações, conectar dispositivos que possam comprometer a segurança do computador, até dar boot em sistemas operacionais.

Esta breve introdução é apenas para dizer que, se já era necessário atenção quando o acesso a porta era físico, imagine se o recurso for acessado via rede?

É exatamente o que o projeto USB/IP Project se propõe a implementar.

Se os riscos já são bem divulgados nos EUA a tendência é aumentar os riscos e a exposição. Encontrei alguns projetos relacionados a SCADA bem interessante.

1 - Um cliente web para SCADA;

2 - Um Scada Open Source;

3 - Uma HoneyNet SCADA;

4 - Link Encryption para SCADA.

O SCADA trabalha usando usando o protocolo DNP3. Protocolo que pode trabalhar via TCP/IP.

A notícia boa é que o NIST publicou o Technical Guide to Security Testing. O documento está bem estruturado e utilizando todos os documentos citados como referência.

O documento trata desde, fases até ferramentas e cuidados que devem ser tomados por profissionais que desejam realizar testes de segurança em ambientes tecnológicos.

A estrutura do documento é a seguinte:

1 - Introdução

2 - Information Security Testing Overview

3 - Review Techniques

4 - Target Identification and Analysis Techniques

5 - Target Vulnerability Validation Techniques

6 - Information Security Test Planning

7 - Security Testing Execution

8 - Post-Testing Activities

O foco das discussões são os riscos que sistemas como SCADA (Supervisory Control And Data Acquisition) podem oferecer. Há algum tempo atrás eu escrevi um post sobre as características e vulnerabilidades dos sistemas SCADA. O filme Duro de Matar 4 trata a briga entre o governo americano e um hacker que é um ex-funcionário do governo que alertou sobre as falhas de segurança nos sistemas e não foi ouvido.

Se já chegou a tela dos cinemas não é de se espantar que os Estados Unidos já possuem áreas e projetos específicos para tratar e responder a incidentes desta natureza.

A CNN divulgou um vídeo de uma prova de conceito de um projeto chamado Aurora que é conduzido pelo Laboratório do Departamento de Energia de Idaho e acompanhado pelo departamento de Home Land Security dos Estados Unidos. O vídeo mostra o gerador se agitando e soltando parafusos, após isso a fumaça toma conta do ambiente. Tudo isso foi disparado através de um sistema SCADA.

A boa notícia é que o mesmo laboratório já executa estes testes há anos e o governo americano já possui um centro de segurança em SCADA no Sandia Labs.

O artigo da CNN gerou uma discussão no Slashdot que pode ser acompanhada neste link e o site tech-faq dá uma visão geral do que é o SCADA.

A primeira coisa que eu fiz foi criar um volume criptografado para armazenar as informações que eu trabalho. Criptografar os dados foi na verdade a parte mais simples, o que mais deu trabalho foi criar um método para forçar a classificação e armazenamento de forma organizada e segura.

Dentro do volume criptografado eu criei as seguintes pastas:

• Projetos
• Desenvolvimento
• Comercial
• Diversos

Na pasta projetos eu crio sempre uma pasta para cada projeto que eu estou trabalhando, da seguinte forma:

• Projetos
• - Projeto x
• - Projeto y

Na pasta desenvolvimento eu armazeno trabalhos, projetos que eu estou desenvolvendo. Nesta pasta eu também crio subpastas, da seguinte forma:

• Desenvolvimento
• - Projeto x
• - Projeto y

Na pasta comercial eu armazeno informações comerciais, de pré-venda que estou trabalhando. Está pasta eu não classifico, pois, após a execução da atividade eu apago e mantenho uma cópia no servidor de arquivos.

Na pasta diversos eu coloco tudo que eu considero informação confidencial mas, não se classifica como as pastas Projetos, Desenvolvimento e Comercial.

Eu procuro não granularizar muito as informações, sempre que eu crio sub, da sub, da sub pasta, eu acabo me enrolando e a coisa não flui. Keep It Simple Stupid!

Para criar o volume criptografado eu uso o TrueCrypt, ferramenta que eu já andei falando por aqui quando descrevi o que eu havia feito no pendrive.

A parte que mais me ajudou na verdade foi uma ferramenta que eu encontrei quando decidi que iria adotar o sistema de tags para os meus arquivos na máquina. A idéia veio porque eu me adaptei e uso muito bem os recursos de tags para o meu repositório de sites favoritos (del.icio.us).

Depois de muita pesquisa o LifeHacker acabou me dando a dica que eu precisava. A ferramenta se chama tag2find. A ferramenta possibilita que você crie etiquetas para todos os documentos que você manipular na máquina. Assim eu posso classificar todo arquivo que eu tenho como Restrito, Confidencial ou Público. A ferramenta coloca uma tag com a informação que eu desejar em cada documento, isso me possibilita que eu pesquise e encontre facilmente os documentos classificados.

Feito estes passos o processo já ficou bem mais práticos e usual, mas eu ainda tinha os inúmeros e-mails trocados diariamente e que continham informações que também podem ser críticas e merecem o mesmo tratamento dos outros arquivos.

A solução foi criar a mesma estrutura de pastas do volume criptografado no outlook. Feito isso eu tinha a organização mas os e-mails ainda estavam no meu .pst junto com todos os outros e-mails. Para resolver isso eu configurei para o outlook armazenar diariamente o conteúdo da pasta na respectiva pasta na máquina. Ou seja, todos os dias o conteúdo da pasta projeto do outlook é armazenado na pasta projeto da máquina, pasta esta que está dentro do volume criptografado.

Para fechar o processo faltava um backup, para garantir a restauração dos dados caso aconteça algum incidente. Para isso eu usei uma ferramenta simples e que foi indicado pelo meu amigo Ronaldo Monteiro, a ferramenta chama DSynchronize. Eu configurei a ferramenta para sincronizar com o servidor a cada 30 Minutos.

Bom, cada um se adapta melhor a um tipo de método, mas esse tem sido bastante prático e as minhas informações e de clientes estão bem tratadas.

A técnica de web scraping é geralmente executada utilizando linguagens de script (python, bash, perl, etc...). Utilizando expressões regulares é possível capturar dados em sites web facilmente.

Mas o que tem a ver web scraping com password cracking? Todo mundo sabe que além de uma boa ferramenta de ataque de dicionário é importantíssimo uma boa wordlist (lista de palavras). É ai que entra o web scraping, na criação desta wordlist.

Também não é novidade que geralmente os usuários comuns criam senhas associando coisas de seu cotidiano. Pensando nesta características, já pensou o estrago que podemos fazer se criarmos nossos dicionários com base nas informações que as pessoas disponibilizam em sites de redes sociais (orkut, myspace, 1grau, etc...)?

Se você reclama que as wordlists disponiveis na internet são na sua maioria em inglês e não existe wordlist em português, vou dar uma dica! A maioria esmagadora de usuários do orkut são Brasileiros.

Não conhece muitos sites de redes sociais? O wikipedia dá uma forcinha!

Quer procurar dados sobre uma pessoa especifica? A ferramenta evolution da Paterva dá uma forcinha!

Conhece o NGrep? NGrep é um sniffer que acumula a característica do Grep do Unix (utilizado para encontrar padrões de texto em fluxos de caracteres). Ele também pode ser uma mão na roda para criar sua wordlist.

Usar FUD como justificativa para implementar segurança é pura incompetência e imaturidade do nosso segmento. Usar argumentos como: "Se você não implementar X, vai parar Y" só mostra nossa incapacidade de gerar valor ao negócio e mostrar métricas tangíveis.

Já que o mercado mostra uma dita WEB 2.0 como uma nova visão da antiga internet, porque nós não podemos criar o FUD 2.0 para nosso segmento.

O FUD 2.0 seria uma visão totalmente nova para conseguir o comprometimento do negócio com nossos objetivos e soluções. O acrônimo FUD (Fear, uncertainty and doubt - Medo, Incerteza, Dúvida) seria substiuído por: FUD (Feasibility, Usability, Dashboard - Praticabilidade, Usabilidade, Dashboard).

Qualquer iniciativa de segurança deve no mínimo ter o FUD 2.0, que seria as seguintes características:

Praticabilidade: conceitualmente o melhor dos mundos é uma gestão de alto nível com uma visão estratégica, tática e operacional, mas, antes de qualquer coisa, uma implementação deve ser prática e viável para a organização. Muitas vezes precisamos abrir mão do certo pelo justo. Isto é gestão de riscos. Quando colocamos todos os pontos necessários como mandatório estamos fazendo Compliance e não gestão de riscos.

Usabilidade: de nada adianta implementar vários controles se a organização não se adaptar e não se tornar parte da cultura da organização.

Dashboard: sim, segurança também deve mostrar seus indicadores, métricas comprovando a eficácia dos controles implementados. É necessário mostrar o valor que se criou ao negócio após a implementação de segurança.

Alguém deve estar se perguntando, qual é a grande novidade do FUD 2.0? Nenhuma! Existe alguma novidade na Web 2.0? Também não. Assim como a web 2.0 o FUD 2.0 é apenas uma visão mais adequada e buscando resultados melhores.

A ferramenta chamada Wikipedia Scanner ficou muito comentada após a divulgação de que, foi encontrado alterações questionáveis por empresas como Wal-Mart, CIA e Diebold.

Para pesquisar as alterações você pode informar o nome e localização da organização ou escolher entre as opções já cadastradas no site.

As alterações são atribuídas por IP da organização, ou seja, se um funcionário de uma organização escrever qualquer bobagem o IP da organização é que vai estar na alteração. Além das reclamações sobre a qualidade/veracidade das informações incluídas na wikipedia, agora você corre o risco de ter o nome da sua empresa associado a informações de caráter duvidoso.

O que tem a ver segurança com entrevistas? Bom, não só na minha atuação como consultor de segurança com foco em BCP (Business Continuity Plan), mas em qualquer outra atuação em segurança, as entrevistas com usuários, gestores, desenvolvedores é atividade frequente. Portanto, recomendo a leitura.

Seguindo os tópicos citados no post dele, vou comentar alguns pontos que são interessantes em um entrevista voltada para análise de segurança:

Sempre que possível, prepare suas perguntas antecipadamente.

Isso é fundamental, qualquer boa metodologia/padrão deve possuir formulários de entrevistas que sejam claros e preparados antecipadamente.

Pergunte questões abertas, especialmente as que começam com “como”, “por que” ou “o que”, e encoraje o entrevistado a descrever, explicar ou exemplificar algo.

Muitas vezes o entrevistador leva o entrevistado a responder o que ele quer e perde a oportunidade de conhecer detalhes que só o entrevistado que conhece pode informar.

Faça uma pergunta por vez, e não tente misturar mais de um tema na mesma pergunta.

Objetividade e clareza são fatores chaves para qualquer entrevista.

Entrevistador não faz discurso e nem inclui o editorial nas suas perguntas.

Cada pergunta deve ser claramente explicada e se possível com exemplos práticos. Lembre-se o formulário é apoio e não um checklist.

A estrela de uma entrevista bem-sucedida nunca pode ser o entrevistador.

Como diria os manos...Sem palavras...

Deixe as perguntas fazerem o seu trabalho.

Se as perguntas forem claras o trabalho será muito mais eficaz.

Resista ao impulso de incluir opinião ou tentar antecipar na pergunta uma possível resposta do seu entrevistado.

Não leve o entrevistado a falar o que você quer, ele deve responder com as informações que ele possui.

Grave e transcreva suas entrevistas, compare-as com as técnicas que você conhece, e tente melhorá-las.

Estude entrevistas publicadas na imprensa - as boas e as ruins.

Esses dois tópicos podem ser usados para aprendizagem e crescimento.