quarta-feira, 26 de setembro de 2012

Desenvolvimento aberto e backdoors

O artigo abaixo foi escrito por Rodrigo Fragola no http://www.blogdofragola.blogspot.com.br/ e rendeu uma ótima discussão. Compartilho agora com vocês e retomo o debate: 
o desenvolvimento aberto oferece maior segurança? Vejam o que já rolou sobre o assunto clicando aqui.  

Recentemente, tive uma dessas discussões apaixonadas sobre desenvolvimento aberto – das quais já não costumo mais ter paciência para participar.  Aprendi com o tempo que a área de tecnologia não deve ser movida por paixões, mas por decisões práticas e objetivas, que levem em consideração o ambiente ao redor. E partindo desse princípio, pode-se dizer que a grande maioria das técnicas e tecnologias é aplicável. 



Desenvolvimento aberto (código aberto e software livre são utilizados popularmente como sinônimos, o que não exatamente apropriado) é uma forma de desenvolvimento de software, nada mais. Nem é preciso entrar nos meandros da discussão, porque ela agrega muito pouco no quesito segurança e nada, nos paradigmas fundamentais da programação. 

O desafio atual da segurança no desenvolvimento reside naquela clássica questão de se saber o que realmente um código está fazendo (por exemplo, se ele está ou não em looping), um problema sem solução. 

Hoje, temos ferramentas que “fiscalizam” as melhores práticas de programação, capazes de detectar, em tempo real, um bom nível de erros de codificação. Mas no que diz respeito ao problema apresentado, são incompletas em sua funcionalidade. No final das contas, pressupõe-se que a intervenção humana ainda é necessária. 

O principal argumento da suposta segurança dos sistemas abertos baseia-se na abertura e na visualização do código por milhões de pessoas. A alegação apresenta um componente de obviedade tentador. Afinal, algo visto e validado por milhões de pessoas deve ser mais seguro do que aquilo que ficou restrito a duas ou três. Mas a realidade é outra. 

O código aberto não é nenhuma novidade, existe há muito tempo. Um exemplo clássico foi o bug da pilha TCP/IP que atingiu 100% dos Sistemas Operacionais, há mais de 10 anos.  Ou seja, todos os fornecedores tinham o mesmo bug. Isso significa que utilizaram o mesmo código, fatalmente derivado de um BSD, que era aberto, livre para uso. 

Ainda que o código tenha sido visto por milhões de pessoas de diferentes corporações, o bug existiu por muito tempo. Então, por que, ao olharem para o código, não viram o bug?

Muitas pessoas confundem a velocidade na correção de um problema de segurança com a inexistência dele.  Um grande equívoco! Já que a agilidade em corrigi-lo está vinculada diretamente ao compromisso do fornecedor em fazê-lo, seja ele aberto ou fechado. 

Assim, conclui-se que o sistema não está livre de problemas de segurança, já que os fornecedores, abertos ou fechados, têm esses mecanismos de fornecimento.

Então, onde estão os analistas de código? Por que o código aberto não é mais seguro?

Se oferecesse maior segurança, o software livre (baseado em desenvolvimento aberto) não teria bugs. Todos podem visualizar o código, entretanto 99,9999% dos bugs são descobertos em tempo de execução na maioria dos sistemas, e não com análise de código.  

Analisar o código, aliás, é algo mais complexo do que desenvolver o próprio código. Não existe um processo de automação que diga o que um código está fazendo. Além disso, já se tem poucas pessoas desenvolvendo código em comparação às pessoas que usam os produtos e, talvez, praticamente ninguém verificando.

Podemos até fazer uma analogia com os processos de compra do Governo. Todos eles são públicos e estão disponíveis para a população verificar. Nem por isso o número de problemas apresentados na televisão em relação a esses procedimentos diminui. A população em geral que tem acesso a tais processos não tem capacidade de avaliá-los, apesar de pagar por eles e usufruir de seu resultado.

Para piorar (no que diz respeito à segurança), temos as bibliotecas de terceiros, amplamente usadas, as BIOS de computador e os sistemas de apoio embarcados para processamentos especializados (FPGA, por exemplo). Todos, livres ou não, com possibilidades de backdoors. O mercado sempre foi colaborativo, não se esqueçam desse ponto. Bibliotecas, integrações e compartilhamento de código entre sistemas sempre existiram. Todas essas camadas de apoio, que são ligadas à execução de um sistema, podem esconder brechas de segurança.

Quantas vezes você, leitor, verificou o código aberto de alguma aplicação para ver se existe algo suspeito nele? Será que este “IF” esconde um backdoor? Quantas pessoas você conhece que já fizeram isso? Eu não me lembro de nenhuma nos últimos 15 anos – pelo menos que tenha descoberto algo  relevante. Conheci muita gente que o fez para corrigir um problema ou aprender como se faz algo, mas nunca para tirar conclusões sobre aspectos de segurança ou corretude do sistema.

Como se já não bastasse a dificuldade técnica na avaliação de um código feito por outra pessoa (em ambientes de desenvolvimento essa é uma reclamação constante de novos programadores que entram na equipe), ainda existe a possibilidade de estarem escondidas entre os códigos, ações não tão óbvias. 

Lembro de um campeonato que existia na época de faculdade, cujo objetivo era desenvolver um programa em C que parecia fazer algo específico, mas, na verdade, escondia outras operações. Havia também uma competição que premiava o programa em C mais “confuso”, de modo que, ao ser lido, o leitor não pudesse saber o que ele fazia. Um dos requisitos desses campeonatos era que o programa fosse pequeno, capaz de ser analisado por uma pessoa. 

Se é possível esconder códigos em programas pequenos, pense agora no volume de códigos existentes atualmente! 

Um backdoor pode ser apenas uma atribuição errônea de uma variável ou um conjunto de 03 linhas de código, bem diferente de milhares de linhas de código, como ocorreu no FLAME. 

Resiliência: Os backdoors vieram para ficar, sejam por erros de programação ou inserção proposital.



A qualidade de software como base competitiva



Nos dias atuais, com um mercado altamente competitivo, que reúne vários fabricantes e fornecedores de diversos tipos de produtos e serviços, a qualidade deixa de ser um diferencial competitivo e passa a ser um item básico de sobrevivência das organizações, uma necessidade permanente. Desta forma, uma empresa que forneça bens e/ou serviços com baixa qualidade corre um sério risco de ser descartada pelo mercado consumidor.

Devido a esse mercado altamente competitivo, as empresas passaram a se preocupar em adotar as técnicas mais modernas de qualidade e produtividade para combinar os recursos disponíveis de maneira a aumentar o seu volume de negócios, garantindo a satisfação dos seus clientes e suas margens de lucro.

Em contrapartida, se as empresas não entregam novos produtos ou funcionalidades aos clientes, rapidamente se tornam obsoletas. Assim, o grande desafio é equilibrar as ações para entregar constantemente novos produtos com qualidade e custos adequados. 

Esta teoria é facilmente compreendida através da triângulo da qualidade (TRIPLE CONSTRAINT). Uma estrutura para a avaliação de demandas conflitantes, um triângulo em que um dos lados ou um dos cantos representa um dos parâmetros que está sendo gerenciado pela equipe do projeto. (PMI, 2004:375) 


O triângulo trata do gerenciamento de necessidades conflitantes do projeto, como o escopo, o tempo e o custo. No que tange a qualidade do projeto é necessário encontrar o balanceamento desses três fatores.

Para encontrar esse equilíbrio existem diversas ferramentas como, por exemplo, o PDCA (Plan, Do, Check, Action), o KAMBAN e o 05 Porquês, que têm a função de ajudar as empresas a atingir a excelência nos seus projetos, melhorando continuamente e aplicando valor ao seu produto.

Existem inúmeras vantagens para se efetuar testes de qualidade nos softwares desenvolvidos. A principal delas é a satisfação dos clientes, pois reduzindo o número de reclamações deles, o produto passa a ser indicado e a imagem da empresa melhora a cada dia. Com isso, surge a fidelização em relação aos produtos, a maturidade e estabilidade dos softwares passam a ser atingidas rapidamente e os custos com desenvolvimento e manutenção são reduzidos, gerando maior receita à empresa.

Com base na pesquisa e na observação das empresas estudadas, seguem as recomendações sobre a estrutura organizacional que melhor se adéquam ao departamento de testes de software:

- Não é recomendado que o Departamento de Qualidade e Testes de Software seja coordenado pela mesma gerência da Equipe de Desenvolvimento, pois pode haver conflitos de interesse;

- O departamento de Testes de Software deve estar preferencialmente abaixo de uma diretoria específica de qualidade da empresa;

- A estrutura interna do Departamento de Teste de Software deve seguir os padrões de certificações existentes, citadas anteriormente, que são:

Líder do Projeto de Testes: responsável pela liderança de um projeto de teste específico, normalmente relacionado a um sistema de desenvolvimento, seja um projeto novo ou em manutenção (RIOS e MOREIRA, 2006);

Engenheiro/Arquiteto de Teste: responsável pela montagem da infraestrutura de teste, montando o ambiente de teste, escolhendo as ferramentas de teste e preparando a equipe para executar o seu trabalho neste ambiente de teste;

Analista de Teste: responsável por modelar, especificar e documentar os casos de testes que devem ser realizados, em resumo esta função cria os Planos de Testes que o testador irá executar;

Testador: responsável por executar os testes e analisar os resultados obtidos, seguindo parâmetros previamente definidos no Plano de Testes.

Para o profissional, temos algumas certificações no mercado. São elas:



Para as empresas desenvolvedoras temos: