Introdução ao Common Criteria para apps seguros

Segurança da informação é um tema que sempre esteve em voga dentro da área da Engenharia de Software desde que os primeiros sistemas multiusuário surgiram no mercado. Com o advento da Internet e a distribuição dos softwares em larga escala, principalmente como serviço (SaaS), a preocupação com a segurança dos sistemas se tornou alarmante. E por fim, com a popularização atual dos dispositivos móveis com capacidades cada vez mais comparáveis à computadores pessoais, se conectando às redes de PCs em qualquer lugar que estejam, consumindo e gerando informações, migrando entre redes heterogêneas e etc, faz com que aspectos como autenticação, autorização, gerência de contexto, privacidade e integridade de informações se tornem assuntos de extrema importância quando o assunto é computação móvel. Mas como garantir que os sistemas e dispositivos computacionais são seguros?

O Critério Comum para Avaliação da Segurança da Tecnologia da Informação (Common Criteria for Information Technology Security Evaluation, ou simplesmente Common Criteria) é um padrão internacional para certificação de segurança computacional. O Common Criteria é um framework que provê a garantia de que o processo da especificação, implementação e avaliação da segurança de um produto computacional passou por um processo padronizado e rigoroso e lhe dá uma nota sobre esta avaliação, provendo algum tipo de garantia sobre a segurança do produto.

Este artigo está estruturado da seguinte forma: a seção 2 apresenta uma breve definição sobre o panorama atual do desenvolvimento de aplicações no que tange à segurança. A seção 3 apresenta o estudo sobre o padrão internacional Common Criteria para segurança computacional. E por fim, algumas conclusões são apresentadas sobre o trabalho e as referências bibliográficas são disponibilizadas no final deste artigo.

Desenvolvimento de Aplicações Seguras

Segundo [BEZNOZOV, 2005], a garantia de segurança provê confiança nas propriedades e funcionalidades relacionadas à segurança, bem como às operações e procedimentos de administração de uma solução desenvolvida. Em outras palavras, a garantia de segurança de um software ou dispositivo garante que os usuários sentir-se-ão confortáveis e seguros utilizando o mesmo, afinal, ninguém quer seus dados expostos ou sua segurança comprometida.

Entretanto, mesmo com o advento de metodologias de desenvolvimento de software cada vez mais rigorosas no que tange à disciplina dos desenvolvedores (mesmo nos casos dos Métodos Ágeis), parece que os requisitos de segurança são relegados à segundo plano ou mesmo são negligenciados devido à falta de expertise dos membros das equipes. É necessário um esforço global focado no aperfeiçoamento dos padrões de segurança da informação para evitar que mais fraudes, furtos de informação e invasões ocorram e até mesmo para que exista uma padronização destes processos para um efetivo controle de qualidade de software.

Entretanto, não é viável a criação de uma norma que contemple todas as faces possíveis dos problemas de segurança oriundos dos mais variados sistemas e dispositivos computacionais, principalmente pela constante evolução dos mesmos e consequente obsolescência de um padrão estático em pouquíssimo tempo. Há a necessidade de adoção de um padrão mais flexível e evolutivo, que permita que as necessidades de segurança de um sistema ou dispositivo possam ser moldadas conforme as necessidades de mercado, como o padrão Common Criteria, que é uma fusão de três outros padrões como ITSEC (padrão europeu), CTCPEC (padrão canadense) e TCSEC (padrão estadunidense), segundo [MEAD, 2008].

Common Criteria

Segundo [SALTER, 2011], o Common Criteria for Information Technology Security Evaluation é um framework para teste de produtos frente às queixas de segurança de usuários ou comunidades de usuários. Sendo mantido por um acordo internacional de mais de 20 países, chamado CCRA (Common Criteria Recognition Arrangement – Acordo de Reconhecimento de Critérios Comuns), a idéia do CCRA é que os países que aderiram ao Common Criteria devem convencer seus fornecedores a fazerem melhorias de segurança em seus produtos, embora atualmente nenhum país tenha cooperado significativamente neste sentido, tendo como tendência a adoção de padrões próprios ([SALTER, 2011]).

O Common Criteria ([CCMB, 2009]) é um padrão criado e mantido pela comunidade de usuários de TI dos países membros, que definem quais os requisitos de segurança devem possuir produtos específicos (TOEs, Targets of Evaluation) ou grupos de produtos (PPs, Protection Profiles). Com base nestas “definições”, os provedores de produtos de segurança que queiram ser certificados naqueles “critérios comuns” fazem as implementações e modificações necessárias para serem submetidos então às avaliações de documentos como Requisitos Funcionais de Segurança (Security Functional Requirements) e Alvos de Segurança (Security Targets). Tudo isso para estarem de acordo com a especificação e terem seus produtos considerados “certificados”, assim como acontece em outras áreas alheias à TI.

O padrão Common Criteria lida com diferentes alvos de avaliação, ou TOEs (Targets of Evaluation) como são chamados no padrão, não estando restrito ao campo de atuação de software. Dentre os quase 2000 produtos certificados ([CCRA, 2012]) temos software de proteção de dados, sistemas biométricos, sistemas operacionais, entre outros, desenvolvidos por grandes empresas como McAfee, Symantec, RSA Security, Apple, entre outras. Para fazer as avaliações de produtos tão variados, são feitas combinações de requisitos funcionais de segurança em grupos, chamados pacotes, sendo que a garantia de segurança do sistema ou dispositivo se dará somente com a análise do referido pacote como um todo.

Segundo [MEAD, 2008], o sucesso no uso do Common Criteria depende da habilidade em definir os requisitos de segurança necessários a cada produto. Isto deve ser feito de uma maneira que leve em consideração o objetivo, as características que necessitam de proteção e o propósito do sistema sob avaliação (o TOE). Ainda segundo [MEAD, 2008], as bases do Common Criteria são os requisitos de garantia de segurança e os requisitos funcionais de segurança. Existem sete níveis de garantia de avaliação (EAL, Evaluation Asurance Level), quanto maior o nível, maior a confiança que pode-se ter sobre os requisitos de segurança terem sido atingidos para aquele produto. Uma curiosidade citada por [MEAD, 2008], à época do artigo, é que a maioria dos produtos encontrava-se entre os níveis 1 e 3 de maturação da avaliação.

Sendo um framework, Common Criteria não define como serão feitos os processos de avaliação ou mesmo quais são os requisitos dos produtos a serem analisados, cabendo à comunidade decidir isso. Isso garante que os critérios de avaliação sejam adequados à cada tipo de produto ou funcionalidade especifica (podem ser criados critérios de avaliação para funcionalidades de produtos computacionais ao invés de ser avaliado o produto inteiro), bem como permite que os modelos de segurança evoluam com o passar do tempo. Esse modelo de framework também permite a utilização de Perfis de Proteção (Protection Profiles) como modelos para avaliações posteriores, reduzindo redundância e criando toda uma padronização em volta de tais produtos, de maneira orgânica e adequada às reais necessidades do mercado.

Conclusões

Muito se evoluiu no desenvolvimento de sistemas e dispositivos computacionais nas últimas décadas. A necessidade de aumento de produtividade e qualidade aliado à redução dos custos devido à satisfação dos clientes com o produto entregue foi o que norteou a criação de processos de software cada vez mais precisos e controladores, que apesar disso não evitaram que muitas brechas de segurança fossem expostas e bilhões de dólares fossem perdidos por tais falhas. Esse consenso de que os sistemas e dispositivos desenvolvidos jamais estão seguros fez com que nações unissem esforços em prol de um padrão internacional para assegurar segurança e qualidade aos seus softwares.

O Common Criteria, hoje, está longe de ser um padrão mundialmente aceito e nem mesmo está plenamente adequado aos muitos desafios de segurança que dispomos. Entretanto, ele é um primeiro passo rumo a algo muito maior e deve ser tratado com a seriedade que merece, devido ao seu potencial de se tornar uma ferramenta colaborativa sólida e escalável para o aumento da qualidade e segurança dos produtos computacionais desenvolvidos. Os clientes preocupados com segurança, como o governo federal dos EUA, estão exigindo a certificação Common Criteria como fator determinante nas decisões de compra ([APPLE, 2012]), isso deve servir de impulso para que as demais nações também o aceitem nos próximos anos.

Referências

BEZNOZOV, K. e KRUCHTEN, P.; Towards Agile Security Assurance, 2005. Disponível em: < http://lersse-dl.ece.ubc.ca/record/87/files/87.pdf >. Acesso em: 14 maio 2012

MEAD, N.; The Common Criteria, 2008. Disponível em: < https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/requirements/239-BSI.html>. Acesso em: 14 maio 2012

SALTER, C.; Common Criteria Reforms, 2011. Disponível em: < http://www.niap-ccevs.org/cc_docs/CC_Community_Paper_10_Jan_2011.pdf>. Acesso em: 14 maio 2012

CCMB; Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and General Model, 2009. Disponível em: < http://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R3.pdf>. Acesso em: 14 maio 2012

CCRA; Certified Products, 2012. Disponível em: < http://www.commoncriteriaportal.org/products/ >. Acesso em: 14 maio 2012

APPLE; Introdução ao Common Criteria, 2012. Disponível em: < http://www.apple.com/br/support/security/commoncriteria/>. Acesso em: 14 maio 2012

Autor

Artigo escrito por Luiz Fernando Duarte Junior, graduado em Ciência da Computação (Ulbra, 2010) e pós-graduado em computação mobile (Unisinos, 2013), professor na Faculdade de Tecnologia de Porto Alegre (FAQI), tradutor do livro Criando aplicações móveis com Corona e autor do livro Criando apps para empresas com Android.

Publicado por

Luiz Duarte

Pós-graduado em computação, professor, empreendedor, autor, Agile Coach e programador nas horas vagas.