ISO/IEC 15.408: Não é para desenvolvimento seguro

Uma versão em PDF deste artigo está disponível em nosso web site.

Introdução

Começar um artigo com um título negando uma afirmação amplamente divulgada é praticamente um convite a discussões intermináveis entre os que defendem uma abordagem ou outra, o que nós conhecemos como flamewar. Mas fique tranquilo, meu interesse é simplesmente esclarecer um equívoco que vem sendo repetido amplamente por anos. E quando falamos em PCI-DSS um assunto recorrente é a segurança em desenvolvimento de software, momento extremamente oportuno para esclarecer e acabar com este equívoco.

A ISO/IEC 15.408 (Commom Criteria), é um conjunto de critérios para avaliação de segurança de um software. Esta avaliação é feita através de perfis de proteção e níveis de garantia de avaliação. Com base nestes critérios, laboratórios credenciados e capacitados irão avaliar produtos e determinar  que nível de garantia de segurança o produto será acreditado.

Então como se pode afirmar que a ISO/IEC 15.408 não é para desenvolvimento seguro? Simples, ela não fornece nenhum tipo de processo,  sistema de gestão e/ou guia para implementação de qualquer controle para garantir a segurança de uma aplicação, apenas critérios para avaliar qualquer sistema, produto de segurança. 

Quem procura boas práticas para desenvolvimento seguro deve se orientar por práticas como o SDL (Security Development Lifecycle) da Microsfot ou o CLASP (Comprehensive, Lightweight Application Security Process) da OWASP (Open Web Application Security Project). Estas práticas irão lhe fornecer diversos recursos que irão possibilitar que você implemente um processo que irá aumentar a qualidade e segurança das suas aplicações.

SDL (Security Development Lifecycle)

O SDL é o grande responsável por um  aumento considerável na segurança das aplicações desenvolvidas pela Microsoft. O SDL é um conjunto de práticas que garantem que o princípio de S³+C será garantido durante o processo de desenvolvimento de software. Mas o que é o S³+C?  S³+C é (Segurança no projeto, Segurança por padrão, Segurança na Implementação + Comunicação). Veja o que a Microsoft descreve sobre esta classificação:

• Segurança no projeto: o software deve ser esboçado, projetado e implementado de modo a proteger a si mesmo e às informações que ele processa, bem como resistir a ataques.
• Segurança por padrão: no mundo real, nenhum software pode ser perfeitamente seguro, portanto os projetistas devem prever a presença de falhas na segurança. Para diminuir os danos causados quando invasores detectam essas falhas remanescentes, o estado padrão do software deve promover a segurança. Por exemplo, o software deve operar com o mínimo necessário de privilégios, e todos os serviços e recursos que não sejam amplamente necessários devem vir desativados por padrão ou ser acessíveis somente a um pequeno grupo de usuários.
• Segurança na implantação: O software deve vir acompanhado de ferramentas e guias para ajudar os usuários finais e/ou administradores a usá-lo com segurança. Além disso, as atualizações devem ser fáceis de serem implantadas.
• Comunicação: os desenvolvedores de software devem estar preparados para a descoberta de falhas na segurança do produto e devem se comunicar de forma aberta e responsável com os usuários finais e/ou administradores para ajudá-los a tomar medidas preventivas (tais como a instalação de patches ou o uso de medidas paliativas).

CLASP (Comprehensive, Lightweight Application Security Process)

O CLASP tem como propósito ser uma metodologia  leve de fácil integração com um modelo tradicional de desenvolvimento de software. Ela fornece recursos e está organizada pelos seguintes componentes:

• CLASP Views: Apresenta cinco perspectivas de alto nível que são detalhadas em atividades que podem ser aplicadas dentro do processo de desenvolvimento: Concepts View, Role-Based View, Activity-Assessment View, Activity-Implementation View e Vulnerability View.
• CLASP Best Practices: Apresenta um conjunto de sete melhores práticas para o desenvolvimento seguro, que vão das análises de segurança até a definição e administração de métricas.
• 24 Atividades CLASP que podem ser direcionadas para o modelo de segurança desejado, atendendo não só as boas práticas mas abordagens para SOX e COBIT.
• CLASP Resources (incluindo CLASP “Keywords”), que crescem a cada nova edição do projeto.
• CLASP Taxonomy, que é integrada aos demais projetos do OWASP e adotada por empresas e organizações do mercado.

A base para implementação da CLASP são suas visões, as visões se interagem e são suportadas pelos outros componentes.  Este processo atende a todas as necessidades de um processo de segurança em desenvolvimento de software e atende as diversas demandas associadas a segurança no desenvolvimento de software.

Conclusão

Com esta rápida abordagem sobre as duas principais referências em implementação de processos de segurança em desenvolvimento, podemos observar que a ISO/IEC 15.408 pode ser um objetivo a ser alcançado, critérios a serem atendidos, mas nunca irá lhe orientar, fornecer recursos que, servirão de base para a implementação do mesmo. 

A segurança adequada de uma aplicação varia de acordo com o comportamento, posicionamento e dinâmica de diversos componentes e relacionamentos que vão muito além do que está escrito em uma norma. Atingir este resultado requer uma metodologia dinâmica, alinhada ao que vem ocorrendo no mercado e que seja capaz de estabelecer melhorias na mesma velocidade que as vulnerabilidades são descobertas. Este é o papel de opções como o Microsoft SDL e o CLASP, use-as e fique seguro.

Referências

• http://www.commoncriteriaportal.org
• http://msdn.microsoft.com/en-us/library/ms995349.aspx
• http://www.owasp.org/index.php/Category:OWASP_CLASP_Project 

Sobre o Autor

Wagner Elias, CBCP, SANS GIAC GHTQ, CobiT Foundation, ITIL Foundation, atua na área de Tecnologia da Informação há mais de 10 anos, tendo acumulado larga experiência em projetos de Segurança da Informação no Brasil e exterior. É co-fundador e sócio da Conviso IT Security, onde atua como Gerente de Pesquisa e Desenvolvimento, responsável pela elaboração de metodologias, gerenciamento de pesquisas em vulnerabilidades e soluções de proteção de informações e das equipes de consultores. Foi responsável pela fundação do capítulo Brasil do OWASP e é Diretor de Eventos do capítulo São Paulo da ISSA.