As emocionantes aventuras de um sysadmin linux na procura pelo uptime perfeito!

Desenvolvimento seguro e software livre – Dica 4: Operação Segura

Posted: janeiro 11th, 2009 | Author: coredump | Filed under: Linux e Open Source, segurança | Tags: ,

CadeadoCheque esta tag para ver os demais posts desta série.

Operação Segura

A prática final no desenvolvimento seguro é especialmente importante para projetos de Software Livre. A Operação Segura refere-se a todo o suporte que deve ser oferecido às aplicações e sistemas depois dos mesmos serem lançados e disponibilizados como uma “versão final”.

A operação segura não se refere apenas ao suporte comum dado em listas e fórums de discussão mas também ao fornecimento de canais de comunicação específicos para problemas e soluções relacionados a segurança que vão surgir de acordo com a popularização do software.

O primeiro ponto que tem de se observar nesta estrutura de suporte é o como o projeto vai lidar com falhas de segurança descobertas in the wild (ou seja, na operação normal de um software já lançado). Muitos defendem o Full Disclosure mas existem alguns projetos que lidam com as vulnerabilidades em segredo até uma correção estar disponível.

Outro ponto importante é a definição clara de como os avisos/relatórios que tratem de vulnerabilidades serão enviados e recebidos pelo projeto. É aconselhável que exista um canal rápido e conhecido (um email ou formulário de fácil acesso) pelo qual relatórios sobre novas vulnerabilidades (ou mesmo bugs relativos à segurança) possam ser enviados e tratados pela equipe responsável em tempo hábil, sem a necessidade de vigiar centenas de emails sobre suporte genéricos na lista de usuários.

Caso o projeto opte pelo Full Disclosure, os desenvolvedores tem de estar atentos à esta política e tomar as devidas precauções. Mesmo sem o Full Disclosure, os desenvolvedores tem de ter em mente que um especialista em segurança pode descobrir uma falha simplesmente analisando atualizações no repositório de controle de versões. Correções ou formas de se remediar uma falha devem ser feitas públicas e amplamente conhecidas o mais rápido possível após a descoberta/publicação de uma falha.

Internamente, as falhas de segurança encontradas após o lançamento devem realimentar o processo de análise de risco para que este possa se concentrar nas áreas próximas a onde a falha foi encontrada, no intuito de conferir a efetividade das correções e o possível aparecimento de problemas decorrentes de novo código adicionado muitas vezes as pressas.

Conclusão

Este foi o último post desta série. As cinco práticas descritas são na verdade uma simplificação de sistemas mais elaborados e menos flexíveis de desenvolvimento seguro, visando facilitar a implantação destas práticas a projetos descentralizados e muitas vezes não tão grandes assim de Software Livre. Os interessados em saber mais ou dar suas opiniões podem deixar seus comentários ou entrar em contato.

intel

1 Comment »

Desenvolvimento seguro e software livre – Dica 3: Testes de Segurança

Posted: dezembro 31st, 2008 | Author: coredump | Filed under: Linux e Open Source, segurança | Tags: ,

CadeadoCheque esta tag para ver os demais posts desta série.

Testes de Segurança

Nos processos formais de desenvolvimento a disciplina de Teste é bem definida. Existe atualmente até certificações relacionadas exclusivamente com teste de software. O teste, nos projetos de software livre, é realizado pelos próprios desenvolvedores e por usuários entusiasmados.

Esta é uma força muito importante para os projetos de software livre, e se bem utilizada e orientada pode encontrar problemas de segurança antes do lançamento de uma nova versão facilmente. Basicamente, tudo o que precisa ser feito é explicitamente orientar todos os usuários e desenvolvedores testando uma versão alfa ou beta que realizem testes específicos de segurança.

Estes testes podem ser automatizados também por ferramentas já existentes como scanners de vulnerabilidade para aplicações web, geradores de entrada aleatórias e etc… Estes testes podem ser distribuídos entre grupos de usuários interessados e o processo vai rapidamente gerar frutos.

A análise de risco e as árvores de ataque podem ser utilizados como guias das partes que precisam ser mais testadas por segurança, e como o ciclo de desenvolvimento em software livre é contínuo o sistema deve ser realimentado com informações de vulnerabilidades encontradas e corrigidas nas versões passadas, testando novamente as correções para garantir um aproveitamento total do teste.

Este assunto nem é tão extenso. O software tem de ser testado, e tem de ser testado com foco em segurança. Simples assim.

Próximo e último assunto, Operação Segura.

intel.

No Comments »

Desenvolvimento seguro e software livre – Dica 2: Revisão de Código

Posted: dezembro 27th, 2008 | Author: coredump | Filed under: Linux e Open Source, segurança | Tags: ,

CadeadoContinuando com o assunto, estamos na metade do caminho agora. Cheque esta tag para ver os demais posts.

Revisão de Código

Depois que um projeto passa da parte de imaginar o que será feito e pensar em como fazê-lo, começa-se a parte de escrever código, propriamente dita. Se as duas outras dicas foram seguidas, o projeto já vai começar a escrever código com segurança em mente, tendo inclusive alguns documentos para nortear as escolhas (como por exemplo árvores de ataque e uma visão de risco). Caso o desenvolvimento não tenha seguido as dicas de segurança durante sua concepção, vai ser um pouco mais turbulento mas mesmo assim, funcional.

Vulnerabilidades em software podem ser decorrentes de dois problemas distintos: erros de programação e erros de desenho. Os erros de desenho podem ser evitados por uma arquitetura bem feita e uma análise de risco delineando as áreas críticas do projeto. Erros de programação são mais simples de se encontrar, mas demandam mais tempo ou pelo menos um processo formalizado de revisão de código.

Escrever código é uma arte e uma ciência. Demanda partes iguais de genialidade e uma visão lógica e mesmo de estilo. Um código feio é um código difícil de se manter, e como vou falar na última dica, a manutenção do software é de extrema importância para a segurança. Além destas considerações naturais, os membros de projetos de software livre e programadores em geral tem de começar a pensar mais em segurança. Isso envolve diversos fatores, desde conhecer bem a linguagem que se programa até conhecer as falhas da mesma, para que erros básicos possam ser evitados.

Uma das coisas que ajuda bastante na parte de escrever código é a utilização de frameworks e bibliotecas conhecidas. Por mais que seja atrativa a idéia de se codificar um novo sistema do zero isto acarreta inúmeras considerações de segurança e performance que demandam um nível elevadíssimo de trabalho. A não ser que a intenção seja realmente desenvolver um novo framework ou uma biblioteca que tenha uma aproximação diferente para o mesmo (ou um novo) problema, é mais vantajoso utilizar ferramentas que já tenham um bom tempo e uma boa base de usuários. Isto vale tanto para aplicações desktop como aplicações web. Frameworks e bibliotecas responsáveis vão normalmente fornecer aproximações mais seguras do que se ‘reinventar a roda’.

A revisão de código, em si, consiste em um passo extra para a Lei de Linus (que diz que ‘com um número suficiente de olhos, todo problema é trivial’). No ponto de vista de segurança, é mais importante que se tenha olhos treinados em identificar problemas de segurança do que um número grande de olhos. Isto porque alguns erros de segurança são difíceis de se encontrar, e algumas vezes são considerados ‘soluções normais’ pela maioria dos desenvolvedores. Por exemplo, a utilização de variáveis globais em linguagens de programação para aplicações web é uma solução que vários desenvolvedores consideraram (e alguns ainda consideraram) válida, demandou algum tempo até que olhos treinados em segurança identificassem o problema e, lentamente, isso fosse se tornando uma prática esquecida. O ponto é, problemas de segurança em código demandam olhos que estejam especificamente procurando por problemas de segurança e saibam como os encontrar.

Neste ponto, existem várias ferramentas que podem ajudar no processo de revisão. Logicamente nada é melhor que alguém ativamente analisando o código em busca de problemas, mas ferramentas podem ajudar a apontar os erros mais gritantes e facilitar o trabalho de quem está fazendo a revisão (seja uma pessoa ou um time). Frisando novamente: nada substitui olhos ativamente revisando o código escrito, ferramentas ajudam, mas nunca devem substituir o fator humano. O processo pode ser inclusive automatizado no sistema de controle de versões ou no processo de se fazer um release. Existem ferramentas que verificam o código por funções inseguras, variáveis mal utilizadas, vulnerabilidades conhecidas de linguagens e ataques comuns a aplicações web. A implantação de uma rotina de revisão de código pode ser automatizada e se realizada desde o início do projeto é um trabalho não muito pesado.

Tendo em vista que projetos de software livre costumam receber contribuições dos mais diversos tipos de desenvolvedores, é interessante que o projeto conte com um pequeno guia de segurança que descreva e indique políticas básicas como qualidade de código a ser enviada, considerações sobre utilização de frameworks e bibliotecas e mesmo uma lista de práticas que não serão aceitas.

Um exemplo deste pequeno documento seria:

Se você quer contribuir código para o projeto X, tenha em mente que:

- O projeto utiliza o framework <nome> e não aceitaremos código que não seja aderente ao mesmo
- O projeto utiliza a biblioteca <nome> para acesso a banco de dados e a biblioteca <nome> para operações de criptografia
- Não será aceito código declarando variáveis globais
- Não será aceito código usando as funções insegura(), insegura2() e insegura(3), utilize as similares seguras fornecidas pelo framework
- Estas orientações estão disponíveis no wiki/página do projeto <url>, além de outros documentos relacionados ao desenvolvimento

Isto pode ser um simples email enviado a pessoas que obtenham acesso de escrita no controle de versões do projeto ou mesmo na lista de usuários/desenvolvedores do projeto. O importante é que todos saibam que existem as recomendações e que elas devem ser seguidas.

Próximo assunto vai ser sobre Testes de Segurança.

intel

No Comments »

Desenvolvimento seguro e software livre – Dica 1: Análise de Risco

Posted: dezembro 22nd, 2008 | Author: coredump | Filed under: Linux e Open Source, segurança | Tags: ,

CadeadoMais um post nesta série, se você quer ver o assunto inteiro é só usar a tag desenvolvimento seguro.

Análise de Risco

A análise de risco é um assunto a parte na segurança da informação, e um dos mais estudados e importantes. A análise de risco, em qualquer sistema de gestão de segurança da informação, é a base para se reconhecer as fraquezas que devem ser tratadas e remediadas.

Nada diferente sobre isso quando tratamos de segurança de software/desenvolvimento seguro. Assim como na criação de uma política de segurança para redes ou empresas inteiras, a análise de risco tem de ser conduzida em várias partes do ciclo de desenvolvimento.

A análise de risco é uma prática natural. Quando se atravessa a rua, olhar para os lados e decidir se vai chegar do outro lado inteiro é uma simples análise de risco. Na minha opinião, incluir análise de risco no desenvolvimento de software, livre ou não, é de pouco impacto.

O SDL da Microsoft e o CLASP (OWASP) tratam de análise de risco na forma de Threat Modeling, ou Modelagem de Ameaças. Os Touchpoints possuem uma análise de risco formal mas que também inclui a Modelagem de Ameaças.

A análise de risco, quando relacionada a desenvolvimento seguro, se refere a identificação e medição de ameaças e impactos no software sendo desenvolvido. Se um sistema possui controle de usuários, existem sempre as ameaças de roubo de senhas, ataques de força bruta, etc… Estas ameaças devem ser então categorizadas com relação a sua severidade e probabilidade de concretização. Esta categorização vai mostrar um panorama de onde o desenvolvimento deve focar sua visão de segurança para evitar futuros problemas.

Não existe um momento ideal para se realizar uma análise de risco. Ela deve ser realizada ciclicamente desde o requisito do sistema e da criação de um novo projeto, e repetida nas diversas fases de desenvolvimento e release de novas versões. Quanto mais funcionalidade se coloca em um software, mais ameaças podem ser incluídas, e um controle do risco faz com que o desenvolvimento seguro tenha sempre um rumo para o que deve ser mais auditado e hardened.

Uma maneira comum de se analisar riscos em software é utilizando Árvores de Ataque (Attack Trees). É um assunto interessante e um dia eu escrevo sobre isso :)

Próximo assunto será revisão de código.

intel

No Comments »

Desenvolvimento seguro e software livre – Dica 0: Arquitetura e requisitos seguros.

Posted: dezembro 17th, 2008 | Author: coredump | Filed under: Linux e Open Source, segurança | Tags: ,

CadeadoComo eu disse semana passada, vou continuar sugerindo algumas dicas/melhores práticas para desenvolvimento seguro em software livre.

Arquitetura e requisitos seguros.

Tá, eu sei que falar isso parece esquisito. Quase ninguém em projetos FLOSS faz processos textbook de desenvolvimento formal, quanto mais pensar em requisitos e tal…

Mas não é bem assim. Quando eu falo de arquitetura e requisitos de segurança eu estou falando de trabalhar com a idéia de segurança desde o princípio, seja o princípio de um novo projeto ou versão ou mesmo de uma nova funcionalidade.

Quando algo novo vai ser desenhado, esta coisa tem de ser pensada levando em conta várias idéias colocadas pelos membros do projeto, mas também tem de se levar em conta a segurança final do produto. Estes são os requisitos de segurança.

Considere que o projeto é fazer uma aplicação web. Desde o início tem de se pensar em SSL para a autenticação, em como as senhas vão ser guardadas no banco de dados (criptografadas ou texto?), como vai ser feito o controle de acesso de usuários (por grupo, por usuário?), e os dados que vão ser guardados ali, são dados sensíveis que precisam de um tratamento a mais na hora de ser gravados em disco ou no banco de dados?

Ou considere que a aplicação vai ser um novo script ou um programa para se rodar em desktops/servidores. Ele vai precisar rodar como super-usuário? Se sim, ele precisa rodar SEMPRE como super-usuário ou apenas algumas partes podem ser escritas assim? O programa/script precisa usar arquivos temporários, qual a maneira mais segura de se fazer

Para os que gostam dos processos mais formais (ou trabalham com os processos em seu dia a dia), além dos casos de uso e requisitos funcionais você precisa trabalhar com os casos de abuso e requisitos de segurança. Enquanto os casos de uso mostram como os usuários vão usar os sistemas, os casos de abuso tratam de formas pelas quais atacantes poderiam explorar ou tentar explorar as falhas de segurança do sistema, sejam elas quais forem.

Isso tudo ainda está na fase de arquitetura do programa, quanto mais for pensado e pesquisado antes de se partir para a codificação, mais fácil e rápido vai ser programar seguramente. Baseado no que se pensa sobre a segurança do projeto (e, claro, nas outras necessidades como requisitos e funcionamento) pode-se tomar decisões sobre linguagens, frameworks, banco de dados e mesmo do tipo de serviço vai ser feito.

Radicalizando, pode até mesmo se chegar a conclusão de que um projeto simplesmente não tem como ser feito de forma segura. Daí é melhor manter ele na pilha de idéias até uma forma melhor aparecer :)

Tanto o SDL da Microsoft quanto os Touchpoints do McGraw tratam de Secure Design e Requirements. O OWASP CLASP trata disso na Best Practice 3: Capture security Requirements.

Depois vou escrever sobre Análise de Risco.

intel

1 Comment »