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.

Evento SECURITY_AUDIT da ESAPI

Assim como publicado no Javadoc da ESAPI (aqui), o seu logging permite usarmos a dimensão segurança para categorizar os eventos. Estão disponíveis as seguintes categorias:

• EVENT_FAILURE – eventos não relacionados a segurança que apresentaram falhas.
• EVENT_SUCCESS – eventos bem sucedidos não relacionados a segurança.
• EVENT_UNSPECIFIED – eventos não relacionados a segurança sem determinação do seu sucesso/falha.
• SECURITY_AUDIT – eventos associados a uma trilha de auditoria, cujo resultado pode ser de sucesso ou falha ou ser irrelevante.
• SECURITY_FAILURE – eventos relacionados a segurança que apresentaram falhas.
• SECURITY_SUCCESS – eventos bem sucedidos não relacionados a segurança. 

A classificação de registros de log pela segurança repercute muito positivamente no trabalho de resposta e prevenção de incidentes. Caso essa lista não atenda as suas necessidades, ela pode ser facilmente extendida.

Eu particularmente acredito que ela seja mais do que suficiente. De fato, não faria nenhuma adição de categoria. Ao contrário, faria  apenas a subtração de SECURITY_AUDIT, pois no meu entendimento, todas as outras categorias podem, eventualmente, compor a trilha de auditoria. A reprensentação mais adequada delas, considerando esse entendimento, seria o diagrama de venn abaixo:

Logging de Aplicação

O logging é uma dimensão muito importante de uma aplicação, mas que é amplamente negligenciada durante o seu processo de design, assim como a segurança de software. Não é a toa que uma das práticas iniciais recomendadas pelo BSIMMv2 (AA1.1) dê enfoque aos mecanismos de segurança, conteúdo no qual o logging se enquadra.

Talvez seja o fato dos principais interessados: auditor, desenvolvedor e administrador do sistema, não estarem tão interessados assim, desde o princípio (abordagem build security outside in). O administrador do sistema normalmente não é estimulado a pensar nos sinais que a aplicação deva lhe fornecer para atuar diante de questões de produção. O auditor só chega em cena, depois que o circo começa a pegar fogo, ou por imposição regulatória. Já o desenvolvedor, se vale das ferramentas de debug para resolver os problemas de código, desdenhando do log.

Mas considere que você esteja numa situação privilegiada, na qual pode pensar em logging antes que necessite de fato do log. Que caminho seguir? De forma bem objetiva e resumida recomendaria as seguintes etapas para o sucesso da sua iniciativa de logging.

Reconheça a aplicabilidade do log
Para reconhecer a aplicabilidade é fundamental levantar que cenários serão tratados pela sua organização. Isso pode partir das atividades comuns dos papéis citados anteriormente. Por exemplo, o auditor precisará atuar diante de cenários que envolvam ataques, uso inadequado e falhas. Já o desenvolvedor e o administrador se interessariam mais por cenários de falhas, erros e desempenho. Inclua as seguintes questões durante a sua análise:

• A que servirá o log? Essa questão lhe ajudará a se afastar da tecnologia e perceber que o log possui um objetivo e que este deve ser o foco. Temos alguns exemplos:
• Garantir não repúdio de ações executadas por usuários autênticos.
  
• Reconhecer fluxos de execução ou entradas para a aplicação reconhecidamente suspeitas.
  
• Identificar a linha do código fonte que comprometeu a execução da aplicação.
• Mostrar a pilha de execução relacionada a determinado falha da aplicação.
• Recuperar os dados que eram processados no momento de alguma falha.
• Reconhecer quando determinados eventos são iniciados e concluídos.
• Reconhecer o tempo de processamento de determinadas ações da aplicação.
• Reconhecer o estado de recursos, como espaço disponível em disco.
• Como o log será consumido? Essa questão vai influenciar diretamente no conteúdo do log, que deverá ser elaborado para que as diferentes formas de consumo sejam possíveis.
• Manualmente com/sem apoio de ferramentas automatizadas ou automaticamente. 
• Qual a origem dos registros do log? Definição que lhe orientará quanto a dinâmica para consolidar os registros, além de dar um tratamento homogêneo independente da origem.
• Aplicação, WAF, servidor de aplicação, etc.
• Como o log será armazenado? Sua infraestrutura terá que estar preparada para receber os registros, garantir a sua segurança, oferecer acesso concorrente, etc.
• Arquivo, banco de dados e/ou console.
• Dimensão máxima da base.
• Segmentação do arquivo.

Defina o conteúdo do log
Uma vez que se tem a noção do que se espera do log e do ambiente em que ele estará inserido, chega o momento da definição do seu conteúdo. Uma abordagem bastante interessante é o reconhecimento dos eventos que devem ser encontrados no log. Como nosso interesse está muito voltado para segurança, nada mais natural que tratar de tais eventos. Anton Chuvakin e Gunnar Peterson sugerem os seguintes eventos:

• Autenticação, autorização e acesso:
• Decisões com falha ou sucesso relacionadas a autorização e autenticação.
• Acesso a sistema, a dados e componentes; e
• Acesso remoto, incluindo aqueles entre componentes de uma mesma aplicação em ambientes distribuídos.
• Mudanças:
• Mudanças em sistema ou aplicação (especialmente quando envolva alteração de privilégios).
• Mudanças de dados (incluindo a criação e destruição), e
• Instalação e mudanças em componentes e aplicações.
• Problemas de disponibilidade:
• Inicio e encerramento de sistemas, aplicações e módulos ou componentes de aplicações, e
• Sucesso e falhas de backup que afete disponibilidade.
• Problemas com recursos:
• Recursos excedendo suas capacidades.
• Problemas com conectividade.
• Limites estourados.
• Indicação de ameaças:
• Entradas inválidas ou outros abusos da aplicação.
• Outros problemas com a aplicação que comprometa a sua operação.

É praticamente impossível levantar todos os eventos de uma aplicação, mas quanto mais ampla for a lista, mais condições se tem de conduzir a forma de elaboração do registro. Definidos os eventos, você pode estabelecer uma convenção de dados do registro relacionado a cada evento. Essa é uma forma de reduzir o poder discricionário do desenvolvedor em definir o conteúdo do log, fonte patente de problemas.

Definidos os eventos, é recomendável usar uma forma de categorização dos registros do log. Tal categorização lhe permite priorizar sua atenção diante dos eventos produzidos pela aplicação. A maneira amplamente difundida é pela sua prioridade ou criticidade, que na maioria dos casos varia de trace, nível menos crítico, até fatal, nível mais crítico. A justificativa para cada categoria segue abaixo:

• FATAL – apropriado para eventos que indiquem uma falha crítica de serviço. Se um serviço emitir um erro FATAL, ele está completamente incapaz de responder. Ex. Indisponibilidade total de um dos componentes-chave da aplicação.
• ERRO – apropriado para eventos que indiquem uma descontinuidade em uma requisição ou habilidade do serviço em responder. Um serviço deve ter alguma capacidade de continuar a responder a requisições mesmo na presença de ERROs. Os ERROs não podem ser tolerados pela aplicação e devem ser investigados imediatamente.
• AVISO – apropriado para eventos que indiquem um erro não crítico em determinado serviço. Erros resumidos ou brechas menores em requisições recaem sobre essa categoria. A distinção entre AVISO e ERRO é muito tênue. Um critério simples é se a falha resulta em chamada de suporte pelo usuário. Caso a resposta seja positiva, escolha ERRO, caso contrário use AVISO. Os AVISOs podem ser tolerados pela aplicação, mas devem sempre ser justificados e examinados. Ex. Aplicação operando em modo debug. O console da aplicação não impõe controle de acesso.
• INFO – apropriado para eventos do ciclo de vida de serviços e outras informações cruciais relacionadas. Mensagens INFO para uma determinada categoria de serviço devem revelar qual o estado corrente do serviço. Outra definição de mensagens INFO, registram ações que alteram significativamente o estado da aplicação. Ex. Atualização do banco de dados, requisição.
• DEBUG – apropriado para mensagens que incorporam informações extras aos eventos de ciclo de vida. Informação de desenvolvimento ou mais aprofundada necessária para o suporte é a base para esta prioridade. Pode-se considerar a pilha de execução e mensagens trocadas com sistemas externos a aplicação.
• TRACE – informação muito detalhada de interesse de desenvolvedores. Tais mensagens são mantidas por um período de tempo muito pequeno quando a aplicação entra em produção e devem ser consideradas temporárias. A dificuldade em se distinguir mensagens DEBUG e TRACE é a mais elevada. Uma vez que se considere um bloco de instruções de logging  desprezível após o desenvolvimento e teste da aplicação, provavelmente ele deve ser classificado como TRACE. Estas mensagens podem conter, por exemplo, além dos métodos de classes no fluxo de execução, os argumentos que cada método recebe e devolve.

As categorias citadas anteriormente servem apenas como um exemplo a ser considerado para definir as categorias que fizerem sentido para os objetivos do logging .

Outra dimensão recomendada para categorizar os registros é a segurança. Todos os eventos considerados por Anton Chuvakin e Gunnar Peterson recaem sobre essa categoria.

Disponibilize o mecanismo de logging
A maneira mais recomendada para conceber um mecanismo de logging é adaptar uma das diversas bibliotecas disponíveis de acordo com suas necessidades.
Dentre as funcionalidades oferecidas por uma biblioteca de logging, as seguintes se destacam:

• Administração da saída (dimensão, backup, divisão, gravação, etc.)
• Classificação dos registros (criticidade/prioridade/segurança).
• Gerenciamento de concorrência.

Tais funcionalidades estão presentes em várias bibliotecas como, por exemplo: Enterprise Library, SLF4J e ESAPI. A ESAPI merece um destaque especial por este post, pois foi concebida com pretensões muito ousadas no que se refere a segurança. Decorre daí a possibilidade de instrumentar de forma bastante simples a aplicação, para que ela se adapte automaticamente diante de cenários de ataque, a partir do uso do AppSensor.

Instrua os desenvolvedores
Uma vez que se defina o que e como logar, para que se obtenha sucesso nessa iniciativa, o desenvolvedor deve ser “bombardeado” de treinamento, orientação e acompanhamento para garantir o uso adequado do mecanismo e, principalmente, que o conteúdo dos registros seja completo e compreensível para o fim a que ele se destina.

Considerações Finais
Apresentamos algumas etapas fundamentais no processo de estruturação do logging de aplicações. Cada fase mereceria diversos posts para contemplar assuntos tão extensos, mas por limitações de tempo tivemos que nos limitar a elas.

São ainda questões interessantes a serem discutidas:

• Como ajustar o logging de uma aplicação que usa um WAF?
• Como garantir que o conteúdo do log não seja subvertido pelo desenvolvedor?
• Como orquestrar o mecanismo de validação de entrada e saída e o mecanismo de logging para que a aplicação trabalhe segundo uma abordagem de segurança positiva?

Links Relacionados
http://tinyurl.com/3hv6mgv