terça-feira, 2 de outubro de 2012

Common Criteria como Fonte de Conteúdo para Logging


O Commom Criteria (CC) ou ISO 15408 continua sendo a principal referencia para certificação de segurança de sistemas. Eu particularmente não penso que essa referência auxilie muito quando se trata de segurança de aplicações. 

Ouso dizer que o OWASP Top 10 sozinho fez e faz muito mais diferença para comunidade de desenvolvimento de software que deseja mudar a realidade de suas aplicações em termos de segurança. Se considerarmos outros ativos da OWASP como os cheat sheets, ASVS, Test Guide a disputa passa a ser covardia. Penso que o CC esteja mais alinhado com outro modelo o SSE-CMM, que se tornou um ilustre desconhecido para a comunidade de segurança em SDLC. 

Mas mesmo que no todo o CC se revele inapropriado para appsec, seus controles continuam sendo muito pertinentes e podem inspirar em muito a discussão sobre oportunidades de melhoria de segurança. Para ilustrar essa minha impressão, resolvi mapear eventos que o CC recomenda que sejam monitorados pelo serviço de logging, que compartilho a seguir:

  • Ações empreendidas pela aplicação em decorrência de violações de segurança. 
  • Ativação ou desativação de mecanismos de análise de auditoria. A aplicação pode ser instrumentalizada com mecanismo que analisem ostensivamente seu comportamento, na tentativa de reconhecer ações suspeitas. Tais mecanismos podem variar de um conjunto de regras fixas de eventos suspeitos até heurísticas avançadas que revele ações suspeitas pela correção de múltiplos eventos associados a cenários de ataque. 
  • Os eventos devem estar relacionados a identidade do usuário, para que a responsabilização pela execução do evento seja garantida.
  • Ações empreendidas pela aplicação quando ao exceder os limites relacionados ao armazenamento de registros (ex. rotação de arquivo por data, dimensão do arquivo).
  • Ações empreendidas pela aplicação em decorrência de falha do receptor dos registros de logging.
  • Requisições bem sucedidas de operação em objetos sensíveis da aplicação.
  • Todas as requisições de operação em objetos sensíveis da aplicação.
  • Os atributos de segurança usados para verificação do direito de acesso a objetos sensíveis.
  • Verificações bem sucedidas de autenticidade de informação consumida pela aplicação.
  • Todas as verificações de autenticidade de informação consumida pela aplicação.
  • Execução com sucesso de rotinas de exportação de dados da aplicação.
  • Todos os tipos de execução de rotinas de exportação de dados da aplicação.
  • Superação do limite estabelecido pelas tentativas de autenticação, a ação decorrente (ex.  bloqueio da senha), e restauração do estado normal (ex. desbloqueio da senha).
  • Rejeição de segredo fornecido a aplicação (ex. senha, frase).
  • Rejeição e aceite de segredo fornecido a aplicação (ex. senha, frase).
  • Mudança nas métricas de qualidade de segredos.
  • Uso mal sucedido de determinado mecanismo de autenticação
  • Todos os usos do mecanismo de autenticação
  • Tentativa mal sucedida de associar os atributos de segurança de determinada identidade ao respectivo sujeito (ex. criação do sujeito).
  • Tentativa mal ou bem sucedida de associar os atributos de segurança de determinada identidade ao respectivo sujeito (ex. sucesso ou falha na criação do sujeito).
  • Uso de mecanismo de anonimização de sessão.
  • Rejeição de nova sessão ou suspensão de sessão ativa em decorrência da superação do número máximo de sessões concorrentes.
  • Suspensão da sessão do usuário em decorrência de período de inatividade superior ao permitido.
  • Início de sessão do usuário.

Como pode ser observado, o CC sugere eventos muito interessantes a serem monitorados pelo serviço de logging. Considerando que uma das atividades mais complexas do projeto de logging é a definição dos eventos que ameaçam a aplicação, e por consequência serão monitorados pelo serviço, essa lista não pode ser ignorada. Ainda, a sua simples existência revela o potencial do modelo CC, como fonte de pesquisa para controles de segurança.

Um comentário:

Unknown disse...

Olá Fabrício.
Já utilize a CC em alguns projetos, principalmente no levantamento de requisitos de segurança de software. Um dos pontos mais utilizados foi justamente a parte de auditoria. Também é possível utilizá-la para definição de critérios de geração de senha bem como a política de senha, definição dos padrões de criptografia etc. Ela também consegue fornecer diretrizes para se montar um ambiente de desenvolvimento seguro. Do ponto de vista de conformidade, agrega valor a um documento de requisitos de software e pode ajudar na aprovação dos requisitos de segurança, visto que é uma norma internacional.
A CC em linhas gerais te diz o que deve ter de funcionalidade de segurança, contudo não te diz a maneira de como implementar. Talvez isso seja um dos seus grandes motivos de crítica.
Acho que é se pode utilizá-la perfeitamente junto com outras iniciativas como os documentos da OWASP e Ciclo de Desenvolvimento Seguro da Microsoft, por exemplo.