Lições aprendidas em segurança pela Microsoft

A revista MSDS Magazine de novembro 2007 traz um artigo elaborado pelo Michael Howard, onde são compartilhadas 10 lições aprendidas pela Microsoft ao longo dos cinco anos de investimento em desenvolvimento de código seguro. Vale a pena conferir!

Lessons Learned from Five Years of Building More Secure Software

Microsoft Guidance Explorer

Para os desenvolvedores .NET que não conhecem o Microsoft Guidance Explorer (versão Web) ainda, vale a pena analisá-lo. Ele aborda as recomendações de Patterns&Practices de uma perspectiva mais aplicada ainda.

Segue apenas algumas orientações de segurança tiradas dele para o desenho de software seguro, na plataforma .NET.

• Partition your web site and secure restricted pages with ssl
• Protect authentication cookies
• How to use fxcop

A versão local pode ser encontrada em Guidance Explorer.

Sugestão de Leitura "State of the Art of Software Security Assurance"

Copio o post do Cima, onde ele divulga o lançamento pelo DoD (US - Department of Defense) do relatório sobre o estado a arte em desenvolvimento de software seguro.

Segue o post - Dica: Relatório "State of the Art of Software Security Assurance".

Adicionalmente, sugiro outro relatório, este do DHS (Department of Homeland Security) produzido em agosto de 2006, mais conciso, mas tão denso quanto o do DoD, chamado Security in the Software LifeCycle.

Core Grasp for PHP

Foi lançada a ferramenta Core Grasp para PHP, cujo objetivo é detectar e bloquear a injeção de vulnerabilidades e violação de privacidade.

Quem desenvolve em PHP sabe das dificuldades de construir uma aplicação segura a partir desse framework. Vale a pena considerar....

Mais informações: CORE GRASP.

Afinal de contas, qual a melhor forma de encontrar vulnerabilidades?

Existem três abordagens básicas para descobrir vulnerabilidades: testes white box, black box e gray box. A diferença entre os três pode ser analisada pelo prisma dos recursos disponíveis para o testador. Em um extremo, temos o teste white box, cuja abordagem requer acesso completo a todos os recursos. Incluindo código fonte, desenho e até um conversa com o programador. No outro extremo encontra-se o teste black box, onde os recursos internos do sistema são indisponíveis. O teste de penetração é um exemplo dessa abordagem. Já os testes gray box não possuem uma definição bem estabelecida. Mas vamos combinar que para esse tipo, o testador tem acesso as bibliotecas compiladas e, em alguns casos, documentação básica.

Teste white box
Essa abordagem explora em profundidade o código fonte na tentativa de localizar falhas de segurança. A análise de código fonte pode ser realizada manualmente, impraticável em grande escala, e automatizada pelo uso de ferramentas de análise de código fonte.

Vantagens

• Cobertura - pelo fato do código fonte estar disponível, uma revisão de código permite sua cobertura total. Todos os fluxos de código podem ser auditados na busca de vulnerabilidades. Isto pode levar a falsos positvos, à medida que nem todos os fluxos sejam verificados.

Desvantagens

• Complexidade - a análise dos resultados gerados pelas ferramentas é de muita complexidade, pois exigem uma revisão criteriosa de cada registro para verificar se realmente corresponde a uma vulnerabilidade.
• Disponibilidade - o código fonte nem sempre é um recurso disponível.

Teste black box
Essa abordagem implica que seu conhecimento corresponde apenas aquilo que pode ser observável, assim como um usuário final. Assim como para o teste caixa branca, esta abordagem é realizada de maneira manual e automatizada, sendo esta conhecida como Fuzzing.

Vantagens

• Disponibilidade - aplicáveis sempre, inclusive nas situações onde o código fonte esteja disponível.
• Reproducibiliade - pelo fato deste teste não levar em conta pressupostos sobre o alvo, a ação pode ser reproduzida para diversos sistemas.
• Simplicidade - mesmo que abordagens que usem engenharia reversa requeiram habiliades especializadas, o teste black box em seu nível básico pode ser conduzido sem um conhecimento interno denso da aplicação.
  

Desvantagens

• Cobertura - um dos maiores desafios é saber quando parar os testes quão efetivo ele tem sido.
  
• Inteligência - o teste black box é mais indicado para cenários onde a vulnerabilidade é causada por vetor de ataque individual. Ataques complexos podem, entretanto, exigir múltiplos vetores de ataque e nesses casos é necessário um entendimento profundo da aplicação, possibilitado pelo acesos ao código fonte.
  

Teste gray box
Este teste uso como recurso determinante o acesso ao binário da aplicação, sendo sua avaliação de segurança também conhecida como auditorida de binário. Assim como para as outras abordagens, esta é realizada manualmente ou com o uso de ferramenta. Vale ressaltar que o que pode não ser automatizado é a análise e não o desassembly.

Vantagens

• Disponibilidade - com exceção de aplicações web remotas, o binário está sempre disponível.
• Cobertura - informação obtida com esta análise pode ser utilizada na melhora da técnica black box.
  

Desvantagens

• Complexidade - A engenharia reversa é uma habilidade especializada e consequentemente recursos podem não estar disponíveis para sua realização.

Infelizmente, quando se trata de segurança, não existem soluções simples isoladas, que transformem seu software em algo seguro. Isso se aplica também para a localização de vulnerabilidades. Se nem a combinação das abordagens anteriores assegura que todas as vulnerabilidades sejam encontradas, individualmente é que elas não resolvem mesmo.

The Securty Development Lifecycle book...

Para aqueles que tiverem interesse em um resumo breve do livro SDL, podem conferir a apresentação elaborada por mim durante a sua leitura.
Reforço, que vale a pena a leitura do livro, cujo conteúdo é bastante denso e sua leitura não é tão árida. O que o torna acessível a qualquer um com conhecimentos básicos da área de computação.

Ferramentas de Análise Código Fonte

A análise de código para fins de segurança é uma das alternativas bastante utilizadas pelo mercado para o desenvolvimento de software seguro. Sua difusão se deve primeiro aos resultados, em termos de localização de bugs de segurança em código e, segundo, pelaa facilidade de incorporação ao ciclo de desenvolvimento, uma vez que as principais ferramentas se integram às IDEs mais usadas hoje, como o Eclipse e o Visual Studio da Microsoft.

Todas as ferramentas comerciais existentes se fundamentam no mesmo princípio, regras e padrões de codificação suspeitos. Isso as tornam muito dependentes da ação humana. Num primeiro momento, para desenhar essas regras a partir de muita pesquisa e depois, para avaliar o resultado de uma análise de código.

As ferramentas de análise de código fundamentam a an Teorema de Rice, que coloca que qualquer questão não trivial endereçada a um programa pode ser reduzido ao Problema de Halting, isso implica que os problemas de análise de código são insolúveis no pior caso e, por consequência, que essas ferramentas são obrigadas a fazer aproximação, cujo resultado é algo não perfeito.

Os principais problemas das ferramentas de análise de código fonte para segurança estão concentradas em:

• Falso negativo - o programa contém bugs não endereçados pela ferramenta. Isso dá a falsa sensasão de que não existe bugs, que na verdade significa que a ferramenta não foi capaz de encotrar mais exemplares.
• Falso positivo - a ferramenta endereça bugs não existentes. Isso se refere a duas possibilidades: um erro propriamente dito, onde a ferramenta localizou um bug que não existe fisicamente; ou há uma classificação da ferramenta incoerente com as variáveis do ambiente. Por exemplo, a ferramenta poderia encontrar um bug de SQL Injection, que na realidade, não interessa para o software investigado pelas suas características de operação.

Vale ressaltar que as ferramentas comerciais procuram reduzir o falso positivo, assumindo o custo de deixar passar falsos negativos.

As análises de código fonte podem ser divididas de acordo com as seguinteas abordagens:

• Análise estática: a análise estática pode compreender as técnicas de busca direta a partir de lista de strings (grep); a análise léxica, onde os tokens do código fonte são comparados com àqueles contidos numa biblioteca de vulnerabilidades e análise semântica, onde se prevê como o programa se comportará em tempo de execução, usando a tecnologia de compiladores (árvore sintática abstrata)
• Análise de fluxo de controle: usada para caminhar através das condições lógicas do código. O processo funciona como a seguir:
  
  1. Observe uma função e determine cada condição de desvio. Essas incluem loops, switchs, if's e blocos try/catch.
  2. Entenda as condições sobre como cada bloco será executado.
  3. Vá para a próxima função e repita.
• Análise de fluxo de dados: usada para seguir fluxos de dados dos pontos de entrada aos pontos de saída. O processo funciona como descrito a seguir:
  
  1. Para cada entrada , determine o quanto você acredita na fonte de entrada. Quando em dúvida você não deve acreditar.
  2. Siga o fluxo de dados para cada saída possível, registrando ao longo do percurso qualquer tentativa de validação de dados.
  3. Vá para a próxima entrada e continue.

A ferramenta mais eficiente é a que consegue fazer uso dessas abordagens combinadas para reduzir tanto o falso negativo, como o falso positivo. Alguns fornecedores estão na busca por ferrnamentas efetivas em temos de análise de código para segurança. Dentre eles, vale destacar:

• Coverity
• Fortify
  
• Ounce Labs
  
• Microsoft
  

Vale reforçar, que para conseguir tirar o melhor proveito das ferramentas de análise de código fonte para segurança, seu uso deve estar amparado por um ciclo de desenvolvimento seguro, como o CLASP ou SDL.

Informações adicionais :
Software Security Building Security In
Secure Programming with Static Analysis
Security Engineering Explained - Versão em português.

Software Seguro....Por onde começar?

O tema software seguro tem recebido mais atenção dia-a-dia, impulsionado pela necessidade de atacar de todas as maneiras a segurança em TI, com ações para estabelecer segurança no nível de rede, de estação e de aplicação, para inverter ou suavizar a curva de evolução de incidentes de segurança, como mostrado pelo CERT-CC.

Nosso foco será em ações, práticas, procedimentos, ferramentas, etc. que apóiem a melhoria da segurança no nível de aplicação, ou seja, para que o elo aplicação na cadeia aplicação-rede-estação seja fortalecido.

Uma coisa vale ressaltar, se alguém deseja evoluir no tema de desenvolvimento de software seguro, vai ter que arregaçar as mangas e digerir uma quantidade infinita de informações, que hoje pode ser encontradas em diversas fontes de pesquisa. Isso acontecer por duas razões principais, primeira é a dificuldade em se encontrar programas de treinamento que considerem esse tipo de assunto e segunda, pela dinamicidade associada, a cada dia surgem novas vulnerabilidades e contramedidas.

Para quem desejar se ingressar no problema de desenvolvimento de software seguro, que remete ao uso de um ciclo de desenvolvimento de software que considera segurança desde seu início, segue a relação de alguns links:

• Security Engineering Explained - relatório da Microsoft que considera preocupações elementares no desenvolvimento de software seguro (50pag.).
• Build Security In - portal desenvolvido pelo Software Engineering Institute, com orientação de Gary McGraw, patrocinado pelo Department of Homeland Security. Existem muitos artigos sobre a temática de segurança em software.
• OWASP - Open Web Application Security Project - Portal de segurança em aplicações web. Este é o projeto de segurança em desenvolvimento mais ativo hoje, com grande contribuição da comunidade. Qualquer um pode se envolver e contribuir. Pode encontrar ferramentas com WebScarab e o Processo CLASP

Abertura

Resolvi inaugurar esse canal para discutirmos vários temas relacionados ao desenvolvimento de software seguro.