Share via

Common Criteria e Softwares Seguros

  • Article

Em um post bem antigo, mas curiosamente ainda muitíssimo acessado, eu descrevi como a equipe em que eu trabalho (que tem o imodesto nome de Security Center of Excellence) faz entrevistas de candidatos para posições na área de segurança da Microsoft. O nosso ponto principal é que perguntas técnicas supostamente básicas, como por exemplo "descreva como uma conexão TCP é estabelecida", tem uma incrível capacidade de identificar os bons candidatos. Bons profissionais conhecem bem os fundamentos da área em que trabalham, maus profissionais decoram os buzzwords.

O Common Criteria (CC) é o pretexto para uma outra pergunta favorita de entrevista. O CC é um padrão para certificar a segurança de produtos, adotado por mais de 20 países (daí o "common") e padronizado como o padrão ISO 15408. É também um tema recorrente nos exames de CISSP, que gosta de incluir perguntas sobre aspectos técnicos como TOE, PP e EAL. 

Nas nossas entrevistas no entanto as pergunta seriam outras. "A certificação Common Criteria indica se um software é seguro?" "Você basearia o seu processo de desenvolvimento seguro na Common Criteria?" Independente da opinião ser ou não igual a minha, o que eu esperaria é que o candidato soubesse o que é um software seguro (em resumo, aquele que resiste a ataques), e argumentasse com coerência se a CC atinge esse objetivo ou não.

No blog do SDL, Eric Birdstrup escreve um excelente post falando sobre a relação a certificação Common Criteria e a segurança de um software. Ou, na opinião dele, a falta de relação.  Eric defende que a CC faz um bom trabalho em identificar vulnerabilidades no desenho da solução, mas ignora completamente vulnerabilidades na implementação e na instalação do software. E é portanto insuficiente para afirmar qualquer coisa sobre a segurança de uma produto.

Eric está certo no seu diagnóstico. A CC simplesmente atesta que o produto implementa um determinado conjunto de funcionalidades de segurança. No entanto ele nada fala sobre "funcionalidades extras" (como um SQL injection) eventualmente incluídas no produto por uma implementação incorreta. Nenhuma prática de codificação segura é avaliada pela CC, nem tampouco testes para avaliar a segurança da implementação (como testes de fuzzing) são usados durante o processo de certificação.

Para piorar, a CC avalia somente uma forma específica de instalação do produto. Se você utilizar um parâmetro de instalação diferente, por mínimo que seja, a sua instalação não está mais certificada. A CC não diz nada por exemplo sobre como fazer o "hardening" para outros cenários de uso do produto.

Não é só a Microsoft que acha que a CC é deficiente. Um relatório do próprio Departamento de Defesa americano vai direto na veia:

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.  

Emr resumo, a CC ainda embute o pensamento da época em que se pensava que fazer um software seguro era acrescentar funcionalidades de segurança, e se ouvia que "o meu software é seguro porque usa certificação digital", ou "o meu software é seguro porque implementa controle de acesso mandatório". Hoje sabemos que nada disso importa se o seu software por exemplo está repleto de estouros de buffer.

No seu post Eric defende que a Common Criteria deve ser revista e incluir os aspectos de implementação e instalação. Mas como fazer isso? Você pode colaborar participando do comitê que avalia a ISO 15408 na ABNT e dando a sua opinião.

Comments