AppSec: Gestão de logs e métricas para monitoramento

Fundamentos de logging para AppSec - Apresentação

Apresentando a instrutora e sua experiência

Olá! Meu nome é Giovana Cis e serei a instrutora deste curso da Alura sobre monitoramento, métricas e comunicação estratégica em APSEC.

Audiodescrição: Giovana é uma pessoa branca, de olhos castanhos, com cabelos compridos de tom loiro médio. Usa óculos arredondados e está gravando no estúdio da Alura.

Atualmente, sou gerente de APSEC e atuo nessa área há quase sete anos. Tenho uma experiência mais ampla, com nove anos dedicados à segurança e quinze anos na área de TI. Já trabalhei como pessoa desenvolvedora, com infraestrutura, redes e como DBA. Essa diversidade de experiências é valiosa na área de APSEC, pois facilita a comunicação com outras pessoas nas suas respectivas linguagens. Também sou professora de pós-graduação e instrutora da IC Council na área de APSEC.

Explorando os fundamentos de login e logs em APSEC

Na nossa primeira aula, abordaremos os fundamentos de login para a segurança de aplicações. O tema inicial é: por que o login é a base da visibilidade para a APSEC? Utilizamos logs em APSEC para entender as causas de comportamentos inesperados ou anômalos, verificar se os sistemas estão funcionando conforme o esperado, controlar ações e processos, e registrar eventos relevantes no sistema. Basicamente, os logs são usados para observabilidade, monitoramento e coleta de dados, ajudando a entender o ambiente.

O monitoramento foca em verificar se os sistemas ou aplicações estão operando dentro dos limites esperados, como CPU, memória e tempo de resposta. É uma ação reativa, identificando problemas, gerando alertas e permitindo ações corretivas. Um exemplo de logs para monitoramento é o consumo de CPU e RAM. Se atingir 100%, um alerta é enviado e a equipe responsável é acionada.

Diferenciando monitoramento e observabilidade

A observabilidade, por sua vez, busca entender o estado interno do sistema e as ações por trás dos comportamentos observados. É uma abordagem proativa, permitindo investigar a raiz dos problemas em sistemas complexos. Um exemplo é a análise de logs ou rastreamento de métricas para descobrir a causa de um alto consumo de CPU ou lentidão em sistemas distribuídos.

Os logs detalham eventos do sistema, erros e avisos, fornecendo contexto para observabilidade e monitoramento. Por exemplo, um log pode mostrar que um serviço falhou e qual foi o erro associado. Em resumo, o monitoramento é o ponto de partida, enquanto a observabilidade oferece uma abordagem mais profunda para entender e solucionar problemas em sistemas complexos. Os logs são ferramentas essenciais para isso, fornecendo os insumos necessários.

Utilizando logs para conformidade e resposta a incidentes

Em um panorama geral, o monitoramento facilita a detecção de eventos em tempo real. As métricas ajudam a entender se os indicadores estão funcionando conforme o esperado, não apenas em sistemas, mas também em processos. Os logs contribuem para investigar e responder a incidentes, além de serem usados para conformidade, fornecendo evidências para compliance, como LGPD, PCI ou outros regulatórios.

As vantagens do monitoramento de logs incluem facilitar a resposta a eventos de zero day (dia zero) ou novas ameaças, além de identificar problemas de segurança, interrupções de serviço e impactos na continuidade.

Analisando logs em casos de fraude e vulnerabilidades

Os logs são amplamente utilizados para acompanhar a correção de vulnerabilidades identificadas em nossos sistemas. Eles também são essenciais para identificar sistemas com componentes desatualizados ou que necessitam de alguma ação. No caso de incidentes, os logs são fundamentais para construir a linha do tempo de um evento ocorrido. Por exemplo, em uma fraude financeira em um sistema bancário, podemos entender onde o atacante estava, o que ele acessou e por onde veio. É possível mapear o vetor de ataque utilizado. No caso de um internet banking, podemos identificar se a fraude ocorreu no internet banking de pessoa jurídica ou física, e em qual funcionalidade específica.

Com os logs, conseguimos determinar o impacto de um incidente. Por exemplo, é diferente uma fraude financeira no site de uma pequena empresa em comparação a um grande banco. Podemos medir o impacto do ocorrido, coletar evidências para responder ou identificar o log, e aprender com o que aconteceu para evitar repetições. Isso nos fornece insumos para lições aprendidas e prevenção de erros futuros.

Exemplo prático de análise de fraude em um banco

Um exemplo prático envolve um incidente em um banco. Sem citar nomes, ocorreu uma fraude enquanto trabalhávamos como prestadores de serviços. Fomos acionados para ajudar a entender e interromper a fraude, que estava causando prejuízos significativos. O primeiro passo foi dialogar com o time de fraudes para identificar o canal afetado, seja internet banking de pessoa jurídica ou física. Identificamos que o ambiente afetado era o internet banking de pessoa jurídica. Revisamos os logs para entender as ações do atacante no sistema. Após analisar os logs, identificamos o vetor de ataque e a funcionalidade do sistema onde a movimentação fraudulenta ocorria.

Após essa análise, realizamos a validação da fraude, replicando o ataque em um ambiente de testes para confirmar a origem e solicitar correções ao time responsável. Os logs são parte integral desse processo de análise de fraude.

Utilizando logs para visibilidade métrica e relatórios

Em relação à visibilidade métrica, os logs são utilizados para identificar os principais problemas dentro de uma área, os principais ofensores, sejam times ou tecnologias mais vulneráveis a falhas. Utilizamos logs para monitorar e acompanhar vulnerabilidades, correções ou ações solicitadas, além de implementar controles de segurança. Os logs também são usados para criar dashboards, facilitando a visualização e resposta rápida às informações. Além disso, são utilizados para gerar alertas, notificações e até ações iniciais quando eventos ocorrem, conforme regras estabelecidas.

Os logs fornecem insumos para relatórios à alta gestão, pois precisamos de dados para reportes. Em auditoria e conformidade, o monitoramento de logs e controles bem estabelecidos são exigências regulatórias, como PCI, GDPR, LGPD e ISO 27000. Eles comprovam que os controles de segurança da empresa estão funcionando adequadamente.

Em resumo, sem logs, não temos visibilidade, e sem visibilidade, não conseguimos agir.

Fundamentos de logging para AppSec - O que colocar nos logs

Discutindo a importância dos logs para a segurança de aplicações

Discutimos anteriormente a importância dos logs para a segurança de aplicações (APSEC). Agora, vamos abordar o que devemos registrar e os eventos críticos para a segurança.

Entre os principais pontos que precisamos tratar com atenção em relação aos eventos a serem registrados estão:

1. Autenticação: Toda vez que uma pessoa usuária se autentica no sistema, devemos garantir que ela realmente tenha acesso autorizado a esse sistema. Precisamos monitorar e assegurar que esses logs e controles estejam funcionando corretamente.

2. Autorização: Quando uma pessoa usuária está autenticada no sistema, mas precisa acessar uma área diferente, uma funcionalidade em uma aplicação ou um sistema distinto, é necessário garantir que ela tenha permissão para acessar o recurso solicitado. Devemos validar isso e utilizar logs para monitorar e assegurar que tudo esteja funcionando adequadamente.

3. Transações: É importante registrar qualquer tipo de transação significativa dentro do contexto da aplicação, não apenas transações financeiras. Isso inclui ações como alterar uma senha, modificar dados do perfil ou, em um e-commerce, efetuar uma compra ou acessar o cartão cadastrado na carteira. Precisamos garantir que essas transações críticas sejam registradas para termos certeza de que ocorreram corretamente.

4. Erros: Devemos entender quando nossa aplicação ou sistema para de funcionar e o que causou isso. Precisamos de informações para compreender o que aconteceu e trabalhar na correção.

Esses são os principais eventos que devemos registrar para garantir a segurança e o bom funcionamento de nossas aplicações.

Explicando a importância dos logs de trilha de auditoria

Os logs de trilha de auditoria são fundamentais e não devem ser negligenciados. Eles focam na rastreabilidade, permitindo que possamos entender o que um usuário fez, onde e quando ele realizou essas ações dentro da aplicação. Por exemplo, no caso de uma fraude, conseguimos identificá-la e agir porque tínhamos logs de trilha de auditoria que rastreavam as ações do usuário no sistema.

Implementando logs de trilha de auditoria em Java

Para implementar um log de trilha de auditoria em Java, podemos utilizar o logger para criar o log, com o formato de ano, mês, dia, hora, minuto, segundo e milissegundos, para registrar os eventos. Vamos ver como isso pode ser feito com um exemplo de código.

Primeiro, precisamos importar as classes necessárias e configurar o logger e o formatter para formatar a data e hora:

import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
import java.util.logging.Level;
import java.util.logging.Logger;

public class AuditoriaLog {

    private static final Logger LOGGER =
        Logger.getLogger(AuditoriaLog.class.getName());
    private static final DateTimeFormatter formatter =
        DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSS");

Criando o método para registrar logs de auditoria

Agora, vamos criar o método registrarLog que será responsável por registrar as informações de auditoria. Este método irá receber o nome do usuário, a ação realizada e os detalhes dessa ação:

    public static void registrarLog(String usuario, String acao, String detalhes) {

        LocalDateTime agora = LocalDateTime.now();
        String timestamp = agora.format(formatter);
        String mensagem = String.format("[%s] Usuário: %s, Ação: %s, Detalhes: %s", timestamp, usuario, acao, detalhes);
        LOGGER.log(Level.INFO, mensagem);

    }

Com este método, registramos qual usuário realizou a ação, qual foi a ação e os detalhes dessa ação. Por exemplo, "o usuário realizou a autenticação na página de login". Se houver um erro, o log indicará "falha de autenticação".

Demonstrando o uso do método de registro de logs

Por fim, podemos ver um exemplo de como utilizar este método na prática:

    public static void main(String[] args) {
        // Exemplo de uso
        registrarLog("usuario123", "Login", "Login bem sucedido");
        registrarLog("usuario456", "cadastro", "Novo usuário cadastrado");
        registrarLog("usuario789", "alteracao", "Senha alterada");
    }
}

Se um log de falha de autenticação se repetir frequentemente, isso pode indicar um ataque automatizado, gerando um alerta para que a equipe possa atuar e responder ao incidente.

Exemplificando a aplicação de logs de trilha de auditoria

Em um exemplo de aplicação que implementa log de trilha de auditoria, registramos quando ocorreu (date time), como no dia 14 de setembro de 2016 às 14h21. Registramos quem fez, incluindo o nome do usuário e o e-mail, que é importante nesta aplicação. Registramos qual ação foi realizada, como criar, editar ou aprovar, e onde ocorreu, como na página de smart campaign, na parte de snippet ou de e-mail template. Com essas informações, conseguimos rastrear as ações do usuário, como o Audit Plus, dentro do sistema.

Fundamentos de logging para AppSec - Níveis e formatos de logs

Discutindo a importância dos logs em segurança da informação

Falamos anteriormente sobre a importância dos logs para a segurança da informação (PSEC) e para o monitoramento, além de discutirmos o que deve ser registrado. Agora, vamos entender como isso funciona, qual é a estrutura desses logs e que tipos de formatos esperamos, com foco em segurança.

Em segurança cibernética (CyberSEC), os níveis de log são categorias que indicam a importância e a urgência dos eventos registrados, permitindo que as pessoas responsáveis pela análise priorizem a investigação e a resposta a incidentes de segurança. Cada nível representa um tipo diferente de evento, desde informações sobre operações normais até erros críticos do sistema que requerem ação imediata.

Explorando os níveis de log e seus usos

Vamos fazer um breve resumo para entender os níveis de log e seu uso, com um exemplo em PSEC. Por exemplo, temos o nível de erro, que se refere a erros que comprometem a integridade e a confidencialidade da aplicação. Um exemplo seria uma falha ao aplicar um aplicativo de segurança, gerando uma exceção em um ponto crítico.

O nível de aviso (warn) refere-se a comportamentos anômalos ou suspeitos que precisam ser investigados para determinar se são incidentes de segurança. Por exemplo, uma pessoa tentando fazer login várias vezes em uma conta e falhando pode indicar um ataque de dicionário.

O nível informativo (info) abrange eventos normais que são valiosos para auditoria, como um login bem-sucedido ou uma alteração de senha. Esses logs são usados para enviar notificações, como e-mails informando que a senha foi alterada.

O log de nível de depuração (debug) contém informações para diagnóstico interno, ajudando a entender o funcionamento da aplicação antes de ser lançada em produção. Não devemos usar logs de depuração em produção, pois podem conter dados sensíveis. Devemos tratar erros, como um stack trace, para não expor informações ao usuário final.

Os logs do tipo trace fornecem detalhes minuciosos sobre o funcionamento da aplicação e sua integração com outros sistemas. Eles são úteis em ambientes de teste, mas não devem ser habilitados em produção, pois podem ser explorados por atacantes.

Considerando os riscos e a importância dos formatos estruturados

Os riscos associados a essas categorias de log incluem o vazamento de dados sensíveis e pessoais, especialmente no nível de depuração. Devemos estar atentos à Lei Geral de Proteção de Dados (LGPD) e ao Regulamento Geral sobre a Proteção de Dados (GDPR) ao usar logs em ambientes que não sejam de teste.

Se tivermos muitos logs sem um filtro adequado, isso pode dificultar bastante a análise. Ter muita informação sem uma inteligência por trás não ajuda quando precisamos investigar o que está acontecendo. Discutimos um pouco sobre formatos estruturados para logs. Por que os utilizamos? Para facilitar a correlação desses logs. Suponhamos que temos logs de uma aplicação, do servidor e de um sistema diferente, e acabamos juntando todos em um único lugar. Para correlacionar esses dados e entender o que está acontecendo, como, por exemplo, um erro na aplicação que ocorreu devido a um erro de CPU na máquina que hospeda essa aplicação, precisamos fazer essa correlação. Para facilitar essa correlação, é necessário que os dados recebidos, os logs, estejam em um formato estruturado. Assim, ferramentas específicas, como um SIEM, que discutiremos mais adiante, conseguem trabalhar esses dados de maneira mais eficiente.

Analisando formatos de log: JSON e CEF

Com formatos estruturados, também conseguimos realizar análises em tempo real e baseadas em padrões de comportamento ou ações que desejamos investigar. A ideia do SIEM com esses dados estruturados é permitir consultas semelhantes a um SQL em um banco de dados, facilitando a busca por informações. Usar formatos estruturados também melhora a padronização dos logs, evitando ambiguidades ao trabalharmos com eles.

Existem dois principais formatos que discutiremos aqui. O primeiro é o JSON, amplamente utilizado por pessoas desenvolvedoras em todo lugar e considerado o modo mais comum no mercado atualmente. Ele é simples, leve e legível tanto para máquinas quanto para nós, humanos. Se precisarmos analisar, conseguimos entender que a timestamp indica quando um evento ocorreu, qual o nível de log (por exemplo, warning), o tipo de evento (como uma tentativa de acesso não autorizada), onde ocorreu e todas as informações detalhadas. Nós, como humanos, conseguimos ler isso da mesma forma que uma máquina pode interpretar. O JSON é ideal para aplicações baseadas em microserviços, APIs ou containers, pois é fácil de ler, não é custoso e é fácil de trabalhar. Ele se integra facilmente com ferramentas de log utilizadas atualmente, como Kibana.

O segundo formato é o CEF (Common Event Format), amplamente utilizado em ferramentas de segurança. Enquanto o JSON é usado para aplicações em geral, o CEF é mais voltado para ferramentas de segurança, como ArcSight ou QRadar. Ele é mais robusto para logs de segurança em larga escala. A vantagem é que ele já vem no padrão que as ferramentas de segurança corporativas, como o SIEM, mais utilizam, facilitando a integração. Não que o JSON seja ruim, mas como o CEF é o formato padrão das ferramentas de segurança, é mais fácil para elas entenderem e trabalharem com ele. No CEF, podemos ver que as informações são as mesmas, mas a estrutura dos dados é diferente. Por exemplo, temos o nome do aplicativo, o meio de produção, o ID da sessão, tudo detalhado. Como se trata de uma ferramenta de segurança, já temos a análise de score de ameaça, a regra que foi acionada (como a JSQL Injection) e mais informações relevantes.

Sobre o curso AppSec: Gestão de logs e métricas para monitoramento

O curso AppSec: Gestão de logs e métricas para monitoramento possui 204 minutos de vídeos, em um total de 62 atividades. Gostou? Conheça nossos outros cursos de Segurança em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Fundamentos de logging para AppSec
• Monitoramento de segurança de aplicações
• Métricas e KPIs em AppSec
• Dashboards e relatórios de AppSec
• Comunicação estratégica em AppSec
• Playbooks de respostas a incidentes em AppSec