Critérios Comuns - Common Criteria

O Common Criteria for Information Technology Security Evaluation (referido como Common Criteria ou CC ) é um padrão internacional ( ISO / IEC 15408) para certificação de segurança de computador . Atualmente está na versão 3.1, revisão 5.

Critérios comuns é uma estrutura na qual os usuários do sistema de computador podem especificar seus requisitos funcionais e de garantia de segurança (SFRs e SARs, respectivamente) em um Alvo de segurança (ST) e podem ser obtidos de Perfis de proteção (PPs). Os fornecedores podem então implementar ou fazer reivindicações sobre os atributos de segurança de seus produtos, e os laboratórios de teste podem avaliar os produtos para determinar se eles realmente atendem às reivindicações. Em outras palavras, o Common Criteria fornece garantia de que o processo de especificação, implementação e avaliação de um produto de segurança de computador foi conduzido de maneira rigorosa, padronizada e repetível em um nível compatível com o ambiente de destino para uso. O Common Criteria mantém uma lista de produtos certificados, incluindo sistemas operacionais, sistemas de controle de acesso, bancos de dados e sistemas de gerenciamento de chaves.

Conceitos chave

As avaliações de Critérios Comuns são realizadas em produtos e sistemas de segurança de computador.

  • Alvo da avaliação (TOE)  - o produto ou sistema que está sujeito à avaliação. A avaliação serve para validar as afirmações feitas sobre o alvo. Para ter uso prático, a avaliação deve verificar os recursos de segurança do alvo. Isso é feito através do seguinte:
    • Perfil de proteção (PP)  - um documento, normalmente criado por um usuário ou comunidade de usuários, que identifica os requisitos de segurança para uma classe de dispositivos de segurança (por exemplo, cartões inteligentes usados ​​para fornecer assinaturas digitais ou firewalls de rede) relevantes para esse usuário para um propósito particular. Os fornecedores de produtos podem escolher implementar produtos que estejam em conformidade com um ou mais PPs e ter seus produtos avaliados em relação a esses PPs. Nesse caso, um PP pode servir como um modelo para o ST do produto (Alvo de segurança, conforme definido abaixo), ou os autores do ST irão, pelo menos, garantir que todos os requisitos nos PPs relevantes também apareçam no documento ST do alvo. Os clientes que procuram determinados tipos de produtos podem se concentrar nos certificados de acordo com o PP que atendem aos seus requisitos.
    • Alvo de segurança (ST)  - o documento que identifica as propriedades desegurançado alvo de avaliação. O ST pode alegar conformidade com um ou mais PPs. O TOE é avaliado em relação aos SFRs (Requisitos Funcionais de Segurança. Novamente, veja abaixo) estabelecidos em seu ST, nem mais nem menos. Isso permite que os fornecedores ajustem a avaliação para corresponder com precisão aos recursos pretendidos de seu produto. Isso significa que um firewall de rede não precisa atender aos mesmos requisitos funcionais de umsistema de gerenciamento de banco de dados e que diferentes firewalls podem, de fato, ser avaliados em relação a listas de requisitos completamente diferentes. O ST geralmente é publicado para que os clientes em potencial possam determinar os recursos de segurança específicos que foram certificados pela avaliação.
    • Requisitos funcionais de segurança (SFRs)  - especifique funções de segurança individuais que podem ser fornecidas por um produto. O Common Criteria apresenta um catálogo padrão de tais funções. Por exemplo, um SFR pode indicar como um usuário que atua em uma função específica pode ser autenticado . A lista de SFRs pode variar de uma avaliação para outra, mesmo que dois alvos sejam o mesmo tipo de produto. Embora os Critérios Comuns não prescrevam nenhum SFR a ser incluído em um ST, ele identifica dependências onde a operação correta de uma função (como a capacidade de limitar o acesso de acordo com as funções) depende de outra (como a capacidade de identificar funções individuais )

O processo de avaliação também tenta estabelecer o nível de confiança que pode ser colocado nos recursos de segurança do produto por meio de processos de garantia de qualidade :

  • Requisitos de garantia de segurança (SARs)  - descrições das medidas tomadas durante o desenvolvimento e avaliação do produto para garantir a conformidade com a funcionalidade de segurança reivindicada. Por exemplo, uma avaliação pode exigir que todo o código-fonte seja mantido em um sistema de gerenciamento de mudanças ou que um teste funcional completo seja executado. O Common Criteria fornece um catálogo desses, e os requisitos podem variar de uma avaliação para outra. Os requisitos para alvos específicos ou tipos de produtos são documentados no ST e PP, respectivamente.
  • Nível de garantia de avaliação (EAL)  - a classificação numérica que descreve a profundidade e o rigor de uma avaliação. Cada EAL corresponde a um pacote de requisitos de garantia de segurança (SARs, veja acima) que cobre o desenvolvimento completo de um produto, com um determinado nível de rigor. Os Critérios Comuns listam sete níveis, com EAL 1 sendo o mais básico (e, portanto, mais barato para implementar e avaliar) e EAL 7 sendo o mais rigoroso (e mais caro). Normalmente, um autor de ST ou PP não selecionará os requisitos de garantia individualmente, mas escolherá um desses pacotes, possivelmente 'aumentando' os requisitos em algumas áreas com requisitos de um nível superior. EALs mais altos não significam necessariamente "melhor segurança", eles apenas significam que a garantia de segurança reivindicada do TOE foi verificada de forma mais ampla.

Até agora, a maioria dos PPs e STs avaliados / produtos certificados foram para componentes de TI (por exemplo, firewalls, sistemas operacionais , cartões inteligentes). A certificação Common Criteria às vezes é especificada para aquisições de TI. Outros padrões contendo, por exemplo, interoperação, gerenciamento de sistema, treinamento de usuário, suplemento CC e outros padrões de produto. Os exemplos incluem a ISO / IEC 27002 ) e a proteção de linha de base de TI alemã .

Os detalhes da implementação criptográfica dentro do TOE estão fora do escopo do CC. Em vez disso, os padrões nacionais, como FIPS 140-2 , fornecem as especificações para os módulos criptográficos, e vários padrões especificam os algoritmos criptográficos em uso.

Mais recentemente, os autores do PP estão incluindo requisitos criptográficos para avaliações de CC que normalmente seriam cobertos por avaliações FIPS 140-2, ampliando os limites do CC por meio de interpretações específicas do esquema.

Alguns esquemas de avaliação nacionais estão eliminando progressivamente as avaliações baseadas em EAL e só aceitam produtos para avaliação que alegam conformidade estrita com um PP aprovado. Atualmente, os Estados Unidos permitem apenas avaliações baseadas em PP. O Canadá está em processo de eliminação das avaliações baseadas em EAL.

História

CC originou-se de três padrões:

  • ITSEC  - O padrão europeu, desenvolvido no início dos anos 1990 pela França, Alemanha, Holanda e Reino Unido. Também foi uma unificação de trabalhos anteriores, como as duas abordagens do Reino Unido (o Esquema de Avaliação CESG UK voltado para o mercado de defesa / inteligência e o Livro Verde do DTI voltado para uso comercial), e foi adotado por alguns outros países, por exemplo, Austrália.
  • CTCPEC  - O padrão canadense seguiu o padrão do DoD dos EUA, mas evitou vários problemas e foi usado em conjunto por avaliadores dos EUA e Canadá. O padrão CTCPEC foi publicado pela primeira vez em maio de 1993.
  • TCSEC  - Departamento de Defesa dos Estados Unidos, DoD 5200.28 Std, denominado Livro Laranja e partes da Série Arco - íris . O Orange Book se originou do trabalho de segurança do computador, incluindo o Relatório Anderson, feito pela National Security Agency e pelo National Bureau of Standards (o NBS acabou se tornando NIST ) no final dos anos 1970 e início dos anos 1980. A tese central do Orange Book decorre do trabalho de Dave Bell e Len LaPadula para um conjunto de mecanismos de proteção.

O CC foi produzido pela unificação desses padrões pré-existentes, predominantemente para que as empresas que vendem produtos de informática para o mercado governamental (principalmente para uso de Defesa ou Inteligência) precisassem apenas avaliá-los em relação a um conjunto de padrões. O CC foi desenvolvido pelos governos do Canadá, França, Alemanha, Holanda, Reino Unido e Estados Unidos

Organizações de teste

Todos os laboratórios de teste devem estar em conformidade com a ISO / IEC 17025 , e os organismos de certificação normalmente serão aprovados de acordo com a ISO / IEC 17065.

A conformidade com a ISO / IEC 17025 é normalmente demonstrada a uma autoridade de aprovação nacional:

As características dessas organizações foram examinadas e apresentadas na ICCC 10.

Acordo de reconhecimento mútuo

Assim como o padrão dos Critérios Comuns, há também um nível de subtratado Common Criteria MRA (Acordo de Reconhecimento Mútuo), pelo qual cada parte reconhece as avaliações em relação ao padrão dos Critérios Comuns feitas por outras partes. Originalmente assinado em 1998 pelo Canadá, França, Alemanha, Reino Unido e Estados Unidos, Austrália e Nova Zelândia aderiram a 1999, seguidos pela Finlândia, Grécia, Israel, Itália, Holanda, Noruega e Espanha em 2000. O Acordo foi desde então renomeado Acordo de Reconhecimento de Critérios Comuns ( CCRA ) e o número de membros continua a se expandir . Dentro do CCRA, apenas avaliações até EAL 2 são mutuamente reconhecidas (incluindo aumento com correção de falha). Os países europeus dentro do antigo acordo ITSEC normalmente reconhecem EALs mais altos também. As avaliações no EAL5 e acima tendem a envolver os requisitos de segurança do governo do país anfitrião.

Em setembro de 2012, a maioria dos membros do CCRA produziu uma declaração de visão em que o reconhecimento mútuo dos produtos avaliados pelo CC será reduzido para EAL 2 (incluindo aumento com correção de falha). Além disso, esta visão indica um afastamento total dos níveis de garantia e as avaliações serão confinadas à conformidade com Perfis de Proteção que não têm nível de garantia declarado. Isso será alcançado por meio de grupos de trabalho técnicos desenvolvendo PPs em todo o mundo, e ainda não foi totalmente determinado um período de transição.

Em 2 de julho de 2014, um novo CCRA foi ratificado de acordo com as metas delineadas na declaração de visão de 2012 . As principais alterações ao Acordo incluem:

  • Reconhecimento de avaliações contra apenas um Perfil de Proteção Colaborativo (cPP) ou Níveis de Garantia de Avaliação 1 a 2 e ALC_FLR.
  • O surgimento de Comunidades Técnicas internacionais (iTC), grupos de especialistas técnicos encarregados da criação de cPPs.
  • Um plano de transição do CCRA anterior, incluindo o reconhecimento de certificados emitidos ao abrigo da versão anterior do Convénio.

Problemas

Requisitos

Critérios comuns são muito genéricos; não fornece diretamente uma lista de requisitos de segurança do produto ou recursos para (classes de) produtos específicos: isso segue a abordagem adotada pelo ITSEC , mas tem sido uma fonte de debate para aqueles acostumados com a abordagem mais prescritiva de outros padrões anteriores, como TCSEC e FIPS 140 -2.

Valor da certificação

A certificação Common Criteria não pode garantir a segurança, mas pode garantir que as declarações sobre os atributos de segurança do produto avaliado foram verificadas de forma independente. Em outras palavras, os produtos avaliados em relação a um padrão de Critérios Comuns exibem uma cadeia clara de evidências de que o processo de especificação, implementação e avaliação foi conduzido de maneira rigorosa e padronizada.

Várias versões do Microsoft Windows, incluindo Windows Server 2003 e Windows XP , foram certificadas , mas os patches de segurança para lidar com vulnerabilidades de segurança ainda estão sendo publicados pela Microsoft para esses sistemas Windows. Isso é possível porque o processo de obtenção de uma certificação de Critérios Comuns permite que um fornecedor restrinja a análise a determinados recursos de segurança e faça certas suposições sobre o ambiente operacional e a força das ameaças enfrentadas pelo produto nesse ambiente. Além disso, o CC reconhece a necessidade de limitar o escopo da avaliação a fim de fornecer certificações de segurança úteis e com boa relação custo-benefício, de modo que os produtos avaliados sejam examinados em um nível de detalhe especificado pelo nível de garantia ou PP. Portanto, as atividades de avaliação são realizadas apenas até uma determinada profundidade, uso de tempo e recursos e oferecem garantia razoável para o ambiente pretendido.

No caso da Microsoft, as premissas incluem A.PEER:

"Quaisquer outros sistemas com os quais o TOE se comunica são considerados sob o mesmo controle de gerenciamento e operam sob as mesmas restrições de política de segurança. O TOE é aplicável a ambientes em rede ou distribuídos apenas se toda a rede operar sob as mesmas restrições e residir em um domínio de gerenciamento único. Não há requisitos de segurança que atendam à necessidade de confiar em sistemas externos ou nos links de comunicação para esses sistemas. "

Essa suposição está contida no Perfil de Proteção de Acesso Controlado (CAPP) ao qual seus produtos aderem. Com base nesta e em outras suposições, que podem não ser realistas para o uso comum de sistemas operacionais de uso geral, as funções de segurança reivindicadas dos produtos Windows são avaliadas. Portanto, eles só devem ser considerados seguros nas circunstâncias especificadas e assumidas, também conhecidas como configuração avaliada .

Quer você execute o Microsoft Windows na configuração avaliada precisa ou não, deve aplicar os patches de segurança da Microsoft para as vulnerabilidades do Windows à medida que elas continuam aparecendo. Se alguma dessas vulnerabilidades de segurança puder ser explorada na configuração avaliada do produto, a certificação Common Criteria do produto deve ser retirada voluntariamente pelo fornecedor. Como alternativa, o fornecedor deve reavaliar o produto para incluir a aplicação de patches para corrigir as vulnerabilidades de segurança na configuração avaliada. A falha do fornecedor em seguir qualquer uma dessas etapas resultaria na retirada involuntária da certificação do produto pelo organismo de certificação do país no qual o produto foi avaliado.

As versões certificadas do Microsoft Windows permanecem em EAL4 + sem incluir a aplicação de quaisquer patches de vulnerabilidade de segurança da Microsoft em sua configuração avaliada. Isso mostra a limitação e a força de uma configuração avaliada.

Críticas

Em agosto de 2007, o colunista do Government Computing News (GCN) William Jackson examinou criticamente a metodologia Common Criteria e sua implementação nos EUA pelo Common Criteria Evaluation and Validation Scheme (CCEVS). Na coluna, foram entrevistados executivos da indústria de segurança, pesquisadores e representantes da National Information Assurance Partnership (NIAP). As objeções descritas no artigo incluem:

  • A avaliação é um processo caro (geralmente medido em centenas de milhares de dólares americanos) - e o retorno do fornecedor sobre esse investimento não é necessariamente um produto mais seguro.
  • A avaliação se concentra principalmente em avaliar a documentação de avaliação, não na segurança real, exatidão técnica ou méritos do produto em si. Para as avaliações dos EUA, apenas no EAL5 e superior os especialistas da Agência de Segurança Nacional participam da análise; e apenas no EAL7 é necessária a análise completa do código-fonte.
  • O esforço e o tempo necessários para preparar as evidências da avaliação e outras documentações relacionadas à avaliação são tão complicados que, quando o trabalho é concluído, o produto em avaliação geralmente está obsoleto.
  • As informações da indústria, incluindo as de organizações como o Fórum do Fornecedor de Critérios Comuns , geralmente têm pouco impacto no processo como um todo.

Em um artigo de pesquisa de 2006, o especialista em computação David A. Wheeler sugeriu que o processo Common Criteria discrimina organizações centradas em software livre e de código aberto (FOSS) e modelos de desenvolvimento. Os requisitos de garantia de Critérios Comuns tendem a ser inspirados na metodologia tradicional de desenvolvimento de software em cascata . Em contraste, muitos softwares FOSS são produzidos usando paradigmas ágeis modernos . Embora alguns tenham argumentado que ambos os paradigmas não se alinham bem, outros tentaram reconciliar os dois paradigmas. O cientista político Jan Kallberg levantou preocupações sobre a falta de controle sobre a produção real dos produtos, uma vez que eles são certificados, a ausência de um corpo organizacional permanente que monitore a conformidade e a ideia de que a confiança nas certificações de segurança de TI de Critérios Comuns ser mantida além das fronteiras geopolíticas.

Em 2017, a vulnerabilidade ROCA foi encontrada em uma lista de produtos de cartão inteligente certificados pelo Common Criteria. A vulnerabilidade destacou várias deficiências do esquema de certificação Common Criteria:

  • A vulnerabilidade residia em um algoritmo de geração de chave RSA desenvolvido internamente que não foi publicado e analisado pela comunidade de criptoanálise. No entanto, o laboratório de testes TÜV Informationstechnik GmbH (TÜViT) na Alemanha aprovou seu uso e o organismo de certificação BSI na Alemanha emitiu certificados de critérios comuns para os produtos vulneráveis. O Alvo de segurança do produto avaliado afirmou que as chaves RSA são geradas de acordo com o algoritmo padrão. Em resposta a essa vulnerabilidade, o BSI agora planeja melhorar a transparência exigindo que o relatório de certificação pelo menos especifique se a criptografia proprietária implementada não está exatamente em conformidade com um padrão recomendado. A BSI não planeja exigir que o algoritmo proprietário seja publicado de forma alguma.
  • Embora os organismos de certificação agora estejam cientes de que as declarações de segurança especificadas nos certificados dos Critérios Comuns não são mais válidas , nem o ANSSI nem o BSI revogaram os certificados correspondentes. De acordo com o BSI , um certificado só pode ser retirado quando foi emitido sob concepção errônea, por exemplo, quando se descobre que foram apresentadas provas erradas. Depois que um certificado é emitido, deve-se presumir que a validade do certificado diminui com o tempo por melhorias e novos ataques sendo descobertos. Os organismos de certificação podem emitir relatórios de manutenção e até realizar uma recertificação do produto. Essas atividades, no entanto, devem ser iniciadas e patrocinadas pelo fornecedor.
  • Embora vários produtos certificados pelo Common Criteria tenham sido afetados pela falha do ROCA, as respostas dos fornecedores no contexto da certificação foram diferentes. Para alguns produtos foi emitido um relatório de manutenção, que afirma que apenas as chaves RSA com um comprimento de 3072 e 3584 bits têm um nível de segurança de pelo menos 100 bits, enquanto para alguns produtos o relatório de manutenção não menciona que a mudança no TOE afeta funcionalidade de segurança criptográfica certificada, mas conclui que a alteração está no nível da documentação de orientação e não tem efeito na garantia.
  • De acordo com a BSI , os usuários dos produtos finais certificados deveriam ter sido informados da vulnerabilidade ROCA pelos fornecedores. Esta informação, no entanto, não chegou em tempo hábil às autoridades da Estônia, que implantaram o produto vulnerável em mais de 750.000 carteiras de identidade da Estônia .

Abordagens alternativas

Ao longo da vida útil do CC, ele não foi universalmente adotado nem mesmo pelas nações criadoras, em particular, as aprovações criptográficas sendo tratadas separadamente, como pela implementação canadense / norte-americana de FIPS-140 e o CESG Assisted Products Scheme (CAPS ) no Reino Unido.

O Reino Unido também produziu uma série de esquemas alternativos quando se constatou que os prazos, custos e despesas gerais de reconhecimento mútuo estão impedindo o funcionamento do mercado:

  • Os esquemas CESG System Evaluation (SYSn) e Fast Track Approach (FTA) para garantia de sistemas governamentais em vez de produtos e serviços genéricos, que agora foram incorporados ao CESG Tailored Assurance Service (CTAS)
  • O CESG afirma marca testada ( marca CCT), que visa lidar com requisitos de garantia menos exaustivos para produtos e serviços de uma maneira eficiente em termos de custo e tempo

No início de 2011, a NSA / CSS publicou um artigo de Chris Salter, que propôs uma abordagem orientada ao Perfil de Proteção para avaliação. Nessa abordagem, comunidades de interesse se formam em torno de tipos de tecnologia que, por sua vez, desenvolvem perfis de proteção que definem a metodologia de avaliação para o tipo de tecnologia. O objetivo é uma avaliação mais robusta. Existe alguma preocupação de que isso possa ter um impacto negativo no reconhecimento mútuo .

Em setembro de 2012, o Common Criteria publicou uma Declaração de Visão implementando em grande parte as idéias de Chris Salter do ano anterior. Os principais elementos da Visão incluem:

  • Comunidades Técnicas se concentrarão na criação de Perfis de Proteção (PP) que apóiem ​​sua meta de resultados de avaliação razoáveis, comparáveis, reproduzíveis e com boa relação custo-benefício
  • As avaliações devem ser feitas em relação a esses PPs, se possível; se não, o reconhecimento mútuo das avaliações do Alvo de segurança seria limitado a EAL2

Veja também

Referências

links externos