Assim como publicado no Javadoc da ESAPI (aqui), o seu logging permite usarmos a dimensao seguranca para categorizar os eventos. Estao disponiveis as seguintes categorias:EVENT_FAILURE eventos nao relacionados a seguranca que apresentaram falhas.EVENT_SUCCESS eventos bem sucedidos nao relacionados a seguranca.EVENT_UNSPECIFIED eventos nao relacionados a seguranca sem determinacao 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 seguranca que apresentaram falhas.SECURITY_SUCCESS eventos bem sucedidos nao relacionados a seguranca. A classificacao de registros de log pela seguranca repercute muito positivamente no trabalho de resposta e prevencao de incidentes. Caso essa lista nao atenda as suas necessidades, ela pode ser facilmente extendida. Eu particularmente acredito que ela seja mais do que suficiente. De fato, nao faria nenhuma adicao de categoria. Ao contrario, faria apenas a subtracao de SECURITY_AUDIT, pois no meu entendimento, todas as outras categorias podem, eventualmente, compor a trilha de auditoria. A reprensentacao mais adequada delas, considerando esse entendimento, seria o diagrama de venn abaixo: O OWASP lancou uma serie de desafios chamado OWASP Hackademic Challenges Project , um projeto de codigo-livre, cujo objetivo e ajudar o testador a ganhar conhecimento em testes de seguranca em aplicacoes web.A Sr. Nimbus atraves desse post disponibiliza a solucao dos 8 primeiros desafios:Solucao do Desafio 1:Solucao do Desafio 2:Solucao do Desafio 3:Solucao do Desafio 4:Solucao do Desafio 5:Solucao do Desafio 6:Solucao do Desafio 7:Solucao do Desafio 8: O Commom Criteria (CC) ou ISO 15408 continua sendo a principal referencia para certificacao de seguranca de sistemas. Eu particularmente nao penso que essa referencia auxilie muito quando se trata de seguranca de aplicacoes. Ouso dizer que o OWASP Top 10 sozinho fez e faz muito mais diferenca para comunidade de desenvolvimento de software que deseja mudar a realidade de suas aplicacoes em termos de seguranca. 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 seguranca 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 discussao sobre oportunidades de melhoria de seguranca. Para ilustrar essa minha impressao, resolvi mapear eventos que o CC recomenda que sejam monitorados pelo servico de logging, que compartilho a seguir:Acoes empreendidas pela aplicacao em decorrencia de violacoes de seguranca. Ativacao ou desativacao de mecanismos de analise de auditoria. A aplicacao pode ser instrumentalizada com mecanismo que analisem ostensivamente seu comportamento, na tentativa de reconhecer acoes suspeitas. Tais mecanismos podem variar de um conjunto de regras fixas de eventos suspeitos ate heuristicas avancadas que revele acoes suspeitas pela correcao de multiplos eventos associados a cenarios de ataque. Os eventos devem estar relacionados a identidade do usuario, para que a responsabilizacao pela execucao do evento seja garantida.Acoes empreendidas pela aplicacao quando ao exceder os limites relacionados ao armazenamento de registros (ex. rotacao de arquivo por data, dimensao do arquivo).Acoes empreendidas pela