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

Compartilhe:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Slashdot
  • StumbleUpon
  • Technorati
  • TwitThis
  • Identi.ca
  • Twitter

Posts relacionados:

  1. Desenvolvimento seguro e software livre – Dica 3: Testes de Segurança Cheque esta tag para ver os demais posts desta série....
  2. Desenvolvimento seguro e software livre – Dica 2: Revisão de Código Continuando com o assunto, estamos na metade do caminho agora....
  3. Desenvolvimento seguro e software livre – Dica 1: Análise de Risco Mais um post nesta série, se você quer ver o...
  4. Desenvolvimento seguro e software livre – Dica 0: Arquitetura e requisitos seguros. Como eu disse semana passada, vou continuar sugerindo algumas dicas/melhores...
  5. Desenvolvimento seguro e software livre Acabei a poucos dias atrás de escrever o trabalho final...

1 Comment »

One Comment on “Desenvolvimento seguro e software livre – Dica 4: Operação Segura”

  1. 1 Marcelly said at 17:43 on janeiro 12th, 2011:

    Excelente série. Muito obrigada!


Leave a Reply