ISO/IEC 15408 — Common Criteria

A ISO/IEC 15408 não avalia “um produto” de forma abstrata. O processo começa definindo o Target of Evaluation, ou TOE: a parte exata do produto ou sistema, suas fronteiras, interfaces, versão, componentes e ambiente. Um gateway de casa inteligente pode ter hardware, bootloader, firmware, módulo criptográfico, aplicativo e cloud. A avaliação pode cobrir apenas o firmware local e o secure boot, deixando aplicativo e cloud fora. O Security Target precisa declarar. O problema de segurança descreve ativos, ameaças, políticas e premissas. Uma premissa pode exigir que administradores sejam confiáveis e que a rede de gestão seja protegida. Se a implantação viola, a garantia não se transfere. O TOE possui objetivos de segurança que respondem. Requisitos funcionais e de garantia são selecionados. O escopo precisa ser verificável. Uma frase genérica como “produto seguro” não é suficiente. A força do Common Criteria está na precisão. A limitação também: quem lê apenas o nível EAL pode ignorar o que foi avaliado. Duas soluções EAL4 podem ter funções distintas. Um firewall e um smart card não são comparáveis pelo número. Em IoT, a avaliação pode focar módulo seguro, sistema operacional, gateway ou componente de rede. O consumidor precisa verificar se a função relevante — armazenamento de chaves, autenticação, atualização, isolamento — está no TOE. Recursos adicionados depois podem ficar fora. Atualizações podem passar por assurance continuity, reavaliação ou novo certificado conforme o esquema. A versão exata importa. O fabricante precisa manter configuração e evidências. O avaliador trabalha com documentação, projeto, testes e vulnerabilidades dentro do método.

A Parte 2 da edição 2022 define um catálogo de Security Functional Components. Eles cobrem áreas como auditoria, comunicação, suporte criptográfico, proteção de dados do usuário, identificação e autenticação, gestão de segurança, privacidade, proteção do TOE, utilização de recursos, acesso ao TOE e caminhos confiáveis. O autor do Security Target seleciona componentes, faz operações permitidas e constrói requisitos. O catálogo permite comparar linguagem. Não obriga todo produto a implementar tudo. Um módulo de segurança pode exigir geração e destruição de chaves, controle de acesso e self-tests. Um gateway pode exigir autenticação, logs e canais confiáveis. Requisitos precisam ser rastreados a objetivos. A implementação é testada. Algoritmos e tamanhos são definidos na especificação e em documentos de esquema, não apenas pela família. Um requisito de criptografia precisa indicar operações e chaves. A avaliação não transforma algoritmo fraco em forte. Esquemas podem exigir padrões nacionais, como FIPS, SOG-IS ou listas. A edição 2022 também trabalha com extensões quando o catálogo não cobre. Extensões precisam de estrutura e justificativa. Para casa inteligente, funções modernas como atualização segura, attestation e isolamento de containers podem ser expressas por combinações ou perfis. O Protection Profile cria conjunto reutilizável para uma categoria de produtos. Um PP para módulos criptográficos ou dispositivos de rede permite avaliações comparáveis. O comprador deve preferir produto avaliado contra PP relevante quando existe, porque o escopo funcional é mais padronizado. Um Security Target proprietário pode ser válido, mas exige leitura detalhada.

A Parte 3 define componentes de garantia. Eles tratam desenvolvimento, orientação, ciclo de vida, testes, análise de vulnerabilidades, entrega e outras evidências. A Parte 5 fornece pacotes, incluindo Evaluation Assurance Levels. EAL1 a EAL7 são níveis crescentes de profundidade e rigor em modelos tradicionais, mas um EAL maior não significa automaticamente produto mais seguro. A função avaliada e o ambiente importam. Um EAL4 aumentado com componentes específicos pode ser adequado. O fabricante entrega arquitetura, especificação funcional, design, rastreabilidade, procedimentos de configuração, testes e evidências conforme o pacote. Avaliadores independentes analisam e executam testes. Em níveis maiores, o rigor formal e a profundidade aumentam. O custo, tempo e documentação também. Produtos comerciais costumam usar níveis intermediários por custo-benefício. A avaliação procura vulnerabilidades conhecidas dentro do potencial de ataque e escopo. Não é bug bounty ilimitado. Novas vulnerabilidades podem surgir depois. O esquema de certificação define manutenção. Certificados possuem validade e status. O Common Criteria Recognition Arrangement permite reconhecimento entre membros para certos níveis e perfis, com regras atuais. O comprador precisa verificar portal oficial do esquema. Um PDF antigo em site de fabricante pode estar arquivado. O certificado deve indicar versão, PP, EAL ou pacote e relatório. A garantia é evidência de processo e análise, não ausência de falhas. Em dispositivos IoT de baixo custo, uma avaliação completa pode ser cara. Componentes certificados, como secure element, podem ser usados, mas a integração final ainda pode expor. Certificação de chip não certifica o firmware que usa a chave.

A avaliação segue metodologia definida pela ISO/IEC 18045 e, na edição 2022, a Parte 4 fornece estrutura para métodos objetivos, repetíveis e reproduzíveis. A Parte 4 de 2022 foi posteriormente retirada e a série continua evoluindo; a situação da edição deve ser conferida. Laboratórios licenciados por esquemas nacionais realizam avaliação. A autoridade certificadora revisa e emite. O processo inclui confirmar Security Target, avaliar evidências, testar e analisar vulnerabilidades. O resultado é certificado, relatório de certificação e Security Target público em muitos esquemas. O consumidor deve ler. A configuração avaliada pode exigir opções específicas: secure boot ativado, modo FIPS, algoritmos permitidos, gabinete com lacre ou funções desabilitadas. Usar fora pode invalidar. Patches precisam de gestão de continuidade. Mudança menor pode ser coberta por relatório de impacto; grande, reavaliação. O fabricante deve divulgar. Em casa inteligente, um gateway certificado pode receber atualização mensal. A política precisa equilibrar manter certificação e corrigir vulnerabilidades. Não atrasar patch crítico só para preservar selo. Esquemas possuem mecanismos. O comprador deve perguntar por suporte, fim de vida e resposta. Common Criteria não cobre operação do serviço cloud, privacidade, disponibilidade do fornecedor ou senha do usuário, salvo se no TOE e requisitos. ISO 27001 complementa governança. ETSI EN 303 645 complementa baseline IoT. IEC 62443 pode ser mais adequada a automação industrial. A seleção da norma precisa refletir o ativo e o risco.