Dica: Relatório "State of the Art of Software Security Assurance"

Via blog do SDL, o Departamento de Defesa americano divulgou um excepcional documento sobre o estado atual em desenvolvimento de software seguro. O State of the Art of Software Security Assurance consolida melhor do que ninguém tudo o que existe atualmente em melhores práticas no mercado e no governo, em 400 páginas de conteúdo de alta qualidade. Mesmo que você não tenha familiaridade com o tema, ou até mesmo por isso, vale a pena ler tudo.

O relatório começa definindo bem o que é um software seguro - software que é robusto contra ataques (secure software is software that is in and of itself robust against attack) - define os problemas existentes na forma como softwares estão desenvolvidos hoje, relaciona desenvolvimento de software seguro com desenvolvimento de software (excelente texto sobre a relação com SSE-CMM), descreve os processos e métodos atuais de desenvolvimento de software e as iniciativas e padrões para avaliar a segurança de um software. Nos apêndices estão entre outros pontos considerações sobre desenvolvimento Agile, e um excelente quadro comparativo fase-a-fase entre os processos SDL da Microsoft, SSA da Oracle, CLASP, Touchpoints e TSP-Secure.

Muito destaque é dado ao processo SDL da Microsoft ao longo de todo o texto, e a Oracle também é citada em alguns pontos. O caso de nenhuma outra empresa é mencionado, e de fato o relatório é faz um diagnóstico bem cortante de onde as práticas de desenvolvimento seguro (não) estão sendo usadas no mercado:

In the vast majority of organizations, the security of the software they used was taken on faith, at least until Microsoft publicly acknowledged vulnerabilities in some of its key strategic products and very publicly undertook to modify not only its products, but the software development life cycle (SDLC) processes by which those products were built, to reduce their overall vulnerability rates.

At the same time, a growing number of other secure software process models and methodologies have been published, mainly in academia, but also in the private sector by software security luminaries John Viega and Gary McGraw. With the exception of Microsoft’s Security Development Lifecycle (SDL) and Oracle’s Software Security Assurance Process, there is no documented evidence that any of these secure software methodologies has been used in realworld software development beyond a few relatively small pilot projects (either purely academic, or under the auspices of academic–industry partnerships).

Outro ponto interessante do relatório trata da relação entre desenvolvimento de código seguro e o padrão ISO 15408 (Common Criteria ou simplesmente CC). Eu pessoalmente já vi mais de uma organização fracassar em definir um processo de desenvolvimento seguro por utilizar como modelo a ISO 15408, que na verdade não serve para isso. A ISO 15408 trata de verificar as funcionalidades de segurança implementados pelo sistema, e não da construção de um software sem vulnerabilidades.

The inadequacies of the TCSEC have been perpetuated in the CC, in that the CC does not provide a meaningful basis for documentation of assurance cases that can be used to verify security as a property of software (

vs. the correctness of the security functionality provided by system components). Also perpetuated in the CC are the inadequacies of the evaluation processes [e.g., the National Information Assurance Partnership (NIAP) CC Evaluation Program] with regard to their omission of direct vulnerability testing of the software components of systems under evaluation. Moreover, the vulnerability analyses that are done focus solely on system-level vulnerabilities in security functions of the system, rather than on the types of software vulnerabilities that may be exploited to compromise the system’s overall dependendability.

[...] Moreover, CC evaluation assurance levels (EAL) indicate only the degree of confidence that can be achieved concerning the claims the product’s vendor makes in the security target (ST) document about the conformance of the product’s (or target of evaluation’s) security-enforcing and security-relevant functionality with security policy rules defined for the TOE. STs say nothing about the robustness against attacks of, and lack of vulnerabilities in, the software that implements those security functions.

O relatório tem vários outros insights, e é leitura recomendada obrigatória para quem quer conhecer o que existe de melhor hoje em desenvolvimento seguro. Ótimo material também para quem está estudando para certificação.