Common Criteria
O texto abaixo apresenta um esboço prático de alto nível da metodologia Commom Criteria e foi elaborado a partir de notas de estudo.
O objetivo desse estudo foi entender o funcionamento básico dessa metodologia através da avaliação do relacionamento dos elementos princiais que a compõem.
A Common Criteria é o resultado de esforços no desenvolvimento de critérios de avaliação de segurança em TI, o que é muito útil para a comunidade internacional. Ela é um alinhamento e desenvolvimento de um número de fontes criteriosas; norte-americanos, europeus e canadense (ITSEC, TCSEC e CTCPEC respectivamente).
Acronismos
Acronismos do processo de ascepção de qualidade
Relacionamentos
Funcionamento
Um fornecedor ou um cliente emite um PP que define os SFRs e SARs. Um fornecedor desenvolve um produto/sistema (TOE) de acordo com o PP e estabelece um ST.
Um PP contém todos os SAR e SFR contra os quais o TOE será avaliado. Cada nível de EAL estabelece uma coleção de SAR e SFR que um PP deve obedecer para obter a certificação em um determinado nível.
O ST é que define como os requisitos SAR e SFR serão cumpridos. No processo de avaliação, se verifica o que foi definido pelo fabricante/fornecedor no ST e se compara com os requisitos dos SARs e SFRs.
Portal do Common Criteria e documentações:
A quantidade de categorias de PPs que existem no site do Common Criteria é pequena em face da abrangência dos mecanismos de software e hardware que são utilizados para efetuar a proteção de sistemas de informação.
Para acessar a lista com as categorias de PPs existentes basta entrar no endereço abaixo:
http://www.commoncriteriaportal.org/public/consumer/index.php?menu=6 e clicar em "collapse all categories".
Para efeitos desse estudo, foram feitas análises de alto nível em dois PPs:
PPs funcionam como RFPs de altíssima qualidade, principalmente quando são elaborados por um orgão como o Department of Defense (DoD) que precisa estabelecer critérios rígidos como é o caso da PP citada acima "Public Key Infrastructure and Key Management Infrastructure Token Protection Profile"
Quanto maior a quantidade de PPs, melhor seria para os consumidores e fornecedores pois teríamos um padrão aberto de definições de perfis de proteção para a elaboração de produtos/sistemas.
Por exemplo, um profissional que procura por um produto para identificação/autenticação de usuários, poderia fazer uma busca na categoria "ICs, Smart Cards and Smart Card related Devices and Systems" se existe algum PP relacionado a esse tipo de produto, o que adiantaria um bom tempo caso se existisse, pois em tese, no mínimo os requisitos de segurança teriam sido definidos por uma empresa, um fornecedor ou cliente em potencial. Essa é uma discussão que poderia ser aberta e envolver a comunidade de empresas e profissionais que atuam com segurança da informação.
Garantia de segurança
Uma certificação do Common Criteria não garante que o produto/sistema é seguro. Garante que ele segue os requisitos contidos em um Protection Profile (PP), que pode ter sido definido pelo próprio fabricante do produto/sistema.
Um PP define os requisitos, o cumprimento desses requisitos são definidos pelo fabricante no Security Target (ST) do produto.
No processo de certificação, um produto é chamado de Target Of Evaluation (TOE), e serão avaliados os "Security Functional Requirements" (SFRs) e Security Assurance Requirements (SAR) estabelecidos no PP, contra a implementação definida no Security Target (ST), pelo fornecedor.
Pesquisando o assunto na Internet, encontramos informações como as que estão contidas em um blog da SUN, que trata da certificação EAL 4+ para o Solaris 10.
Foram extraídos dois pontos que deixam claro essa questão controversa da garantia de segurança na certificação Common Criteria. Em um dos pontos o cara pega pesado.
If the process was not designed to actually detect software bugs or vulnerabilities in an OS, then what does it check?
This question emphasizes the current disappointment that DoD officials have with the process. They are paying extra money for evaluated products but not necessarily getting better products because of the evaluation process. The process is designed to ensure that a product behaves as documented but it is NOT a source code scrub for buffer overflows, coding errors or other issues (The fact that MS Windows products are evaluated at EAL4 should make this point painfully obvious!).
What's wrong with the current Common Criteria process?
Although the current process is somewhat better than the old NSA process, it still leaves something to be desired. I have heard it stated in public forums by DoD employees that the CC process does not meet all Government's goals. Current problems include:
Referências
http://blogs.sun.com/jimlaurent/entry/faq_what_is_a_common
http://www.commoncriteriaportal.org/public/developer/index.php?menu=2
http://www.commoncriteriaportal.org/public/files/CCPART1V3.1R1.pdf
http://www.commoncriteriaportal.org/public/files/CCPART2V3.1R2.pdf
http://www.commoncriteriaportal.org/public/files/CCPART3V3.1R2.pdf
http://en.wikipedia.org/wiki/Common_Criteria
Revisões
Publicado em 07/11/2007 17:45 em aprox. 2:00 hr
Esse texto foi escrito com base em um post enviado em 03/11/2007 para a lista de discussão cisspBR que trata sobre a certificação de segurança CISSP - Certified Information System Security Professional.
O objetivo desse estudo foi entender o funcionamento básico dessa metodologia através da avaliação do relacionamento dos elementos princiais que a compõem.
A Common Criteria é o resultado de esforços no desenvolvimento de critérios de avaliação de segurança em TI, o que é muito útil para a comunidade internacional. Ela é um alinhamento e desenvolvimento de um número de fontes criteriosas; norte-americanos, europeus e canadense (ITSEC, TCSEC e CTCPEC respectivamente).
Acronismos
- TOE - Target Of Evaluation
Produto ou sistema sujeito a avaliação - PP - Protection Profile
Classes de dispositivos seguros - ST - Security Target
Identifica as propriedades de segurança de um TOE
Acronismos do processo de ascepção de qualidade
- EAL - Evaluation Assurance Level
Níveis de 1 à 7 (EAL1 - EAL7) utilizados para certificar os produtos avaliados - SAR - Security Assurance Requirements
Verifica se as medidas de segurança são efetivas e a sua correta implementação - SFR - Security Functional Requirements
Define o comportamento desejado dos requisitos de segurança
Relacionamentos
- TOE é um produto compatível com um ou mais PPs
- SFRs e SARs fazem parte de uma lista que é efetivamente definida no escopo dos documentos do Common Criteria.
- PPs estabelecem quais SFRs e SARs são mandatórios para o TOE a ser desenvolvido e posteriormente avaliado.
- STs implementam PPs.
- A avaliação de TOEs é a checagem de STs contra PPs.
Funcionamento
Um fornecedor ou um cliente emite um PP que define os SFRs e SARs. Um fornecedor desenvolve um produto/sistema (TOE) de acordo com o PP e estabelece um ST.
Um PP contém todos os SAR e SFR contra os quais o TOE será avaliado. Cada nível de EAL estabelece uma coleção de SAR e SFR que um PP deve obedecer para obter a certificação em um determinado nível.
O ST é que define como os requisitos SAR e SFR serão cumpridos. No processo de avaliação, se verifica o que foi definido pelo fabricante/fornecedor no ST e se compara com os requisitos dos SARs e SFRs.
Portal do Common Criteria e documentações:
A quantidade de categorias de PPs que existem no site do Common Criteria é pequena em face da abrangência dos mecanismos de software e hardware que são utilizados para efetuar a proteção de sistemas de informação.
Para acessar a lista com as categorias de PPs existentes basta entrar no endereço abaixo:
http://www.commoncriteriaportal.org/public/consumer/index.php?menu=6 e clicar em "collapse all categories".
Para efeitos desse estudo, foram feitas análises de alto nível em dois PPs:
- Cryptographic Module for CSP Signing Operations — Protection Profile
da categoria "Key Management Systems"
http://www.commoncriteriaportal.org/public/files/ppfiles/PP_VID2009-PP.pdf - Department of Defense Public Key Infrastructure and Key Management Infrastructure Token Protection Profile (Medium Robustness)
da categoria "Products for Digital Signatures"
http://www.commoncriteriaportal.org/public/files/ppfiles/pp0309.pdf
Quanto maior a quantidade de PPs, melhor seria para os consumidores e fornecedores pois teríamos um padrão aberto de definições de perfis de proteção para a elaboração de produtos/sistemas.
Por exemplo, um profissional que procura por um produto para identificação/autenticação de usuários, poderia fazer uma busca na categoria "ICs, Smart Cards and Smart Card related Devices and Systems" se existe algum PP relacionado a esse tipo de produto, o que adiantaria um bom tempo caso se existisse, pois em tese, no mínimo os requisitos de segurança teriam sido definidos por uma empresa, um fornecedor ou cliente em potencial. Essa é uma discussão que poderia ser aberta e envolver a comunidade de empresas e profissionais que atuam com segurança da informação.
Garantia de segurança
Uma certificação do Common Criteria não garante que o produto/sistema é seguro. Garante que ele segue os requisitos contidos em um Protection Profile (PP), que pode ter sido definido pelo próprio fabricante do produto/sistema.
Um PP define os requisitos, o cumprimento desses requisitos são definidos pelo fabricante no Security Target (ST) do produto.
No processo de certificação, um produto é chamado de Target Of Evaluation (TOE), e serão avaliados os "Security Functional Requirements" (SFRs) e Security Assurance Requirements (SAR) estabelecidos no PP, contra a implementação definida no Security Target (ST), pelo fornecedor.
Pesquisando o assunto na Internet, encontramos informações como as que estão contidas em um blog da SUN, que trata da certificação EAL 4+ para o Solaris 10.
Foram extraídos dois pontos que deixam claro essa questão controversa da garantia de segurança na certificação Common Criteria. Em um dos pontos o cara pega pesado.
If the process was not designed to actually detect software bugs or vulnerabilities in an OS, then what does it check?
This question emphasizes the current disappointment that DoD officials have with the process. They are paying extra money for evaluated products but not necessarily getting better products because of the evaluation process. The process is designed to ensure that a product behaves as documented but it is NOT a source code scrub for buffer overflows, coding errors or other issues (The fact that MS Windows products are evaluated at EAL4 should make this point painfully obvious!).
What's wrong with the current Common Criteria process?
Although the current process is somewhat better than the old NSA process, it still leaves something to be desired. I have heard it stated in public forums by DoD employees that the CC process does not meet all Government's goals. Current problems include:
- It still take a long time (about 1 1/2 years) resulting in delays in purchasing state of the art products.
- The process is not designed to actually detect software bugs or vulnerabilities in an OS
- The rules for adoption of the OS are interpreted in a wide variety of ways across organizations.
- It is not flexible in handling OS updates and patches
Referências
http://blogs.sun.com/jimlaurent/entry/faq_what_is_a_common
http://www.commoncriteriaportal.org/public/developer/index.php?menu=2
http://www.commoncriteriaportal.org/public/files/CCPART1V3.1R1.pdf
http://www.commoncriteriaportal.org/public/files/CCPART2V3.1R2.pdf
http://www.commoncriteriaportal.org/public/files/CCPART3V3.1R2.pdf
http://en.wikipedia.org/wiki/Common_Criteria
Revisões
Publicado em 07/11/2007 17:45 em aprox. 2:00 hr
Esse texto foi escrito com base em um post enviado em 03/11/2007 para a lista de discussão cisspBR que trata sobre a certificação de segurança CISSP - Certified Information System Security Professional.
