O desafio da padronização de logs de segurança
Os logs de segurança são fundamentais para operações de defesa. Eles registram atividades essenciais como autenticações de usuários, acessos a arquivos, tráfego de rede e uso de aplicações. Essas informações permitem detectar e responder a incidentes de segurança.
Porém, existe um problema crítico: cada sistema gera seus logs em formatos diferentes. Firewalls, sistemas de detecção de intrusão, antivírus e outras ferramentas utilizam suas próprias estruturas de dados. Essa fragmentação dificulta a análise centralizada, compromete a detecção de ameaças e complica a conformidade com regulamentações.
O OCSF (Esquema Aberto de Cibersegurança) foi desenvolvido como resposta a este desafio. Trata-se de um framework padronizado que oferece um formato consistente para representar eventos de segurança, independentemente da origem dos dados. Sua adoção traz benefícios imediatos: melhora a interoperabilidade entre ferramentas, simplifica a análise de dados, reduz a complexidade da conformidade e diminui o risco de aprisionamento por fornecedor.
Como o Amazon Security Lake simplifica a centralização
A AWS anunciou o Amazon Security Lake, um serviço que automatiza a centralização de dados de segurança em formato OCSF. O Security Lake conecta-se nativamente com diversos serviços AWS como CloudTrail (eventos de gerenciamento e dados), Amazon EKS (logs de auditoria), Amazon Route 53 (queries de resolução), AWS Security Hub, Amazon VPC Flow Logs e AWS WAF.
O serviço também integra logs de provedores SaaS, ambientes locais e outras plataformas em nuvem, consolidando tudo em um data lake proprietário com segurança aprimorada. Todos os dados são automaticamente normalizados para o formato OCSF, garantindo consistência.
Essa centralização transforma a operação de segurança. Ao integrar com ferramentas analíticas como Amazon Athena e Amazon QuickSight, o Security Lake permite detecção de ameaças mais eficiente, monitoramento contínuo da postura de segurança e relatórios de conformidade simplificados.
O acelerador de ETL dos Serviços Profissionais da AWS
Apesar dos benefícios, clientes que desejam usar fontes customizadas de logs no Security Lake enfrentam um desafio: precisam converter seus logs proprietários para o formato OCSF manualmente.
Para resolver isso, a equipe de Serviços Profissionais (ProServe) da AWS desenvolveu um acelerador de solução ETL (Extração, Transformação e Carregamento) em código aberto. Esta ferramenta automatiza a conversão de logs de segurança customizados para o padrão OCSF 1.1, facilitando a integração com o Security Lake ou outros data lakes de segurança. A solução oferece abordagem orientada por configuração, eliminando a necessidade de modificar código para diferentes tipos de log.
Pré-requisitos e configuração inicial
Para implementar a solução, você precisará ter instalado:
A arquitetura serverless utiliza diversos serviços: Amazon S3, AWS Lambda, Amazon DynamoDB, AWS Step Functions, AWS Glue ou Amazon EMR Serverless para ETL, além de AWS Secrets Manager, Amazon RDS, Amazon CloudWatch, Amazon SNS e Amazon EventBridge.
Os custos dependem do volume de dados e frequência de processamento. As principais despesas envolvem armazenamento (S3 e DynamoDB), computação (Lambda, Glue e EMR) e orquestração. A arquitetura é otimizada para custo através de componentes serverless com pagamento conforme uso. Use o Calculador de Preços da AWS para estimar custos específicos ao seu volume de logs e necessidades de retenção.
Arquitetura e fluxo de dados
A solução funciona com dois arquivos de entrada: um arquivo de mapeamento e um arquivo de configuração. Esses arquivos guiam a transformação de logs de origem para formato OCSF em Parquet, que é então particionado por localização e conta, armazenado em uma localização S3 fornecida pelo Security Lake.
O fluxo segue estas etapas principais:
Etapa de pré-processamento
O usuário prepara dois arquivos CSV. O primeiro contém o mapeamento de campos customizados para classes OCSF. O segundo arquivo contém metadados de configuração que orientam a transformação. Quando esses arquivos são enviados para um bucket S3 de artefatos, uma notificação de evento S3 dispara uma função Lambda que armazena os metadados em tabelas DynamoDB. Funções Lambda adicionais processam os arquivos de configuração e armazenam as informações necessárias nas tabelas de mapeamento e referência.
Enriquecimento opcional
A solução pode ler dados de um banco de enriquecimento armazenado em Amazon RDS ou acessível via conexão JDBC a partir do EMR ou Glue. As credenciais são gerenciadas pelo AWS Secrets Manager.
Processamento de logs de origem
Os arquivos de log de origem são entregues a um bucket S3 por um processo externo. Uma agenda do EventBridge ou invocação manual inicia o workflow Step Functions, responsável pela conversão dos logs. O workflow Step Functions executa as tarefas de transformação, convertendo os arquivos de log para formato OCSF-Parquet usando bibliotecas Python customizadas. Os dados convertidos são armazenados em um bucket S3 de destino. Se falhas ocorrem durante o processamento, um tópico SNS notifica os usuários.
Mapeando seus logs para o formato OCSF
Antes de começar, verifique se já existem mapeamentos disponíveis no repositório GitHub de mapeamentos OCSF. Se não, você precisará criar um.
O processo envolve várias etapas: primeiro, familiarize-se com o esquema OCSF, que define a estrutura e formato para organizar dados de log em classes de evento e atributos. Cada classe de evento contém um conjunto de atributos projetados para oferecer semântica abrangente do evento.
Identifique suas fontes de log (firewalls, sistemas de detecção de intrusão, antivírus) e seus formatos nativos (CSV, JSON, etc.). Analise o conteúdo dos logs e localize as categorias e classes OCSF apropriadas. Mapeie cada campo de dados de origem para o campo correspondente no esquema OCSF. Se um campo não possui equivalente em OCSF, considere mapeá-lo para o objeto “unmapped”.
O enriquecimento de dados adiciona contexto, como padronização de timestamps, conversão de endereços IP para formato comum ou adição de dados complementares para melhor análise. Cada categoria em OCSF possui uma coluna de enriquecimento opcional que fornece mais informações. Por exemplo, a categoria de Autenticação OCSF contém uma coluna que oferece mais detalhes sobre endereços IP.
Valide os dados mapeados contra o esquema OCSF para garantir conformidade e precisão. Teste o mapeamento com amostras de dados de diferentes fontes. Use o utilitário de código aberto para validar sua saída OCSF 1.1 gerada.
Finalmente, considere contribuir seu mapeamento para a comunidade OCSF submetendo um pull request ao repositório. A AWS ProServe auxiliou muitos clientes a mapear seus logs de segurança para OCSF. Se precisar orientação para mapear e transformar seus logs, entre em contato com seu executivo de conta.
Criando e transformando arquivos de mapeamento
A solução ETL requer um arquivo CSV de mapeamento que associe atributos de log de segurança customizados aos atributos OCSF padronizados. Para instruções detalhadas sobre como gerar este arquivo, consulte o repositório de código.
Se você está seguindo um exemplo, pode habilitar o log de acesso do servidor S3 para publicar logs de origem no S3. Um exemplo de registro de log de acesso S3 seria processado pelo código Python fornecido, que normaliza os atributos e envolve cada um em aspas adequadamente.
Após preparar seu arquivo de mapeamento CSV, faça upload dele para a localização de artefatos S3 em s3://secure-datalake-artifacts-<account_number>-<aws_region>/config/mapping/. A função Lambda asl-etl-framework_update-mapping-ddb processa este arquivo e o converte para o formato DynamoDB necessário, armazenando o resultado na tabela de mapeamento de atributos OCSF.
Configurando metadados para transformação
Para criar um arquivo de metadados de configuração, prepare um arquivo CSV seguindo as orientações na documentação do repositório. Faça upload do arquivo CSV de mapeamento completo para a localização de artefatos S3 em s3://secure-datalake-artifacts-<account_number>-<aws_region>/config/metadata/.
Quando o arquivo de metadados é enviado para o S3, dispara automaticamente a função Lambda asl-etl-framework_insert_metadata_ddb, que armazena a configuração na tabela DynamoDB. A função Lambda subsequente asl-etl-framework_update-mapping-ddb lê o arquivo de mapeamento CSV e insere os mapeamentos na tabela de mapeamento de atributos OCSF correspondente.
Recursos avançados da solução
Carga histórica
A solução oferece capacidade de carga histórica que processa logs de intervalos de datas ou anos especificados baseado nas entradas do arquivo de metadados. Após conversão para formato OCSF em Parquet, esses logs podem ser integrados ao Amazon Security Lake ou usados para criar um data lake customizado.
A solução inclui funcionalidade de checkpoint para lidar com potenciais falhas durante processamento histórico de dados. Este recurso fornece resiliência ao rastrear o progresso de conversão. Se um processo falha durante processamento histórico de múltiplos anos, a solução retoma a partir do ponto de falha, preservando os dados já convertidos com sucesso.
Enriquecimento de dados
Empresas frequentemente possuem dados contextuais valiosos que podem enriquecer seus logs de segurança. Ao correlacionar dados existentes com logs de segurança e anexar informações relevantes, você cria conjuntos de dados mais abrangentes para análise avançada e insights de segurança mais profundos.
Por exemplo, se você deseja obter informações adicionais como geolocalização de cada endereço IP nos logs, pode fornecer informações do banco de dados de origem no arquivo CSV de metadados. A solução conecta ao banco de dados através de conexão JDBC, extrai as informações solicitadas e adiciona as informações extraídas como novas colunas aos logs OCSF convertidos.
Escolhendo o mecanismo de transformação
Você pode selecionar seu mecanismo de transformação preferido: AWS Glue ou Amazon EMR Serverless. Forneça o nome do mecanismo durante a implantação. Para cargas históricas grandes, recomenda-se EMR Serverless; AWS Glue é adequado para cargas históricas menores que 100 GB.
O processo segue estas etapas: o usuário insere as informações de metadados e mapeamento nos arquivos CSV respectivos e faz upload para S3. Uma função Lambda converte os arquivos para esquema DynamoDB. Uma função preprocessadora é invocada, pegando os metadados da tabela DynamoDB e gerando argumentos de entrada para o trabalho de transformação. O trabalho de transformação (Glue ou EMR, conforme sua escolha) lê as tabelas de metadados e mapeamento, convertendo os dados para formato OCSF. Os arquivos de log OCSF convertidos são armazenados em localização S3 especificada em formato Parquet, que pode ser integrada ao Security Lake.
Orquestração com Step Functions
A solução é orquestrada usando AWS Step Functions e oferece duas opções de mecanismo de execução: AWS Glue ou EMR Serverless, dependendo dos serviços permitidos em sua empresa.
Para invocar o workflow Step Functions, especifique o mecanismo de execução como emr-serverless ou glue nos parâmetros de entrada passados via EventBridge.
Os parâmetros de entrada para o workflow são:
{
"source_log_type": "s3-access-log",
"load_type": "historical",
"full_load": "false",
"ddb_lookup_table": "asl-etl-framework-ddb-table-details",
"ddb_mapping_table": "asl-etl-framework-ocsf-attribute-mapping",
"ddb_metadata_table": "asl-etl-framework-source-ocsf-metadata",
"ddb_reference_table": "asl-etl-framework-ocsf-reference",
"asl_status_table": "asl-etl-framework-run-status",
"execution_engine": "glue",
"asl_job_name": "asl-etl-framework-init-ocsf-conversion"
}
Validando os dados convertidos
Uma prática recomendada é garantir que os arquivos Parquet gerados mapeiem corretamente às definições de esquema especificadas dentro do OCSF (Esquema Aberto de Cibersegurança). Validar o mapeamento mantém a integridade de dados e permite que dados de segurança sejam efetivamente analisados por aplicações e ferramentas downstream, como o Security Lake.
Use o validador de esquema OCSF para fornecer validação complementar. Esta etapa de validação ajuda a detectar desalinhamentos de esquema ou problemas de qualidade de dados cedo no processo, levando a análise de segurança mais confiável.
Se a validação do esquema OCSF transformado falhar, primeiro valide se seus mapeamentos estão alinhados com a categoria OCSF respectiva. Ajuste seus mapeamentos, execute a solução novamente e valide os logs OCSF transformados usando o validador até obter um esquema OCSF válido.
Quando descobrir mapeamentos OCSF incorretos ou inconsistências de formato em logs convertidos, comece realizando validação minuciosa contra especificações de esquema OCSF para identificar discrepâncias específicas. Atualize os mapeamentos com mapeamentos de campo corretos, garantindo que conversões de tipo de dados e requisitos de campo obrigatório sejam atendidos. Teste essas correções usando dados de amostra para verificar conformidade OCSF antes de implementar em produção.
Próximas etapas
A solução está disponível como um projeto de código aberto, porém envolver a AWS ProServe oferece vantagens significativas, incluindo experiência comprovada de implementação, orientação de melhores práticas e cronogramas de implantação acelerados. A equipe ProServe traz experiência extensiva em padronização de logs de segurança e pode ajudar a customizar a solução para seus requisitos específicos, garantindo integração ideal com o Security Lake.
Para começar sua jornada rumo a análise de segurança padronizada usando OCSF, entre em contato com sua equipe de conta AWS para discutir como a AWS ProServe pode ajudar a implementar esta solução em seu ambiente.
Fonte
Transform security logs into OCSF format using a configuration-driven ETL solution (https://aws.amazon.com/blogs/security/transform-security-logs-into-ocsf-format-using-a-configuration-driven-etl-solution/)
