Saltar para o conteudo
Avanet
Iniciar sessao

Ligar registos de fluxos cloud ao Sophos XDR e SIEM

Sophos Fusion Admin Sophos SIEM

Os registos de fluxos cloud descrevem ligações de rede, não o conteúdo integral dos pacotes. O Sophos XDR pode recebê-los de AWS VPC Flow Logs, Azure Network Watcher, Google Cloud Platform (GCP) e Oracle Cloud Infrastructure (OCI). O percurso depende da origem: S3 e Lambda em AWS, Azure Storage e uma Function em Network Watcher, Pub/Sub em GCP e Streaming em OCI.

A telemetria netflow destas integrações exige Sophos Next-Gen SIEM. GCP e OCI também fornecem outros esquemas pelas mesmas integrações; isso não torna todos os dados cloud de auditoria ou segurança dependentes de SIEM. Confirmar primeiro categorias necessárias, tenant, atualização Fusion e direitos de licença. O artigo sobre SIEM e planeamento da retenção explica o enquadramento comercial.

Estas ligações diretas distinguem-se de um collector syslog alojado na cloud. Para esse percurso aplica-se o runbook do collector XDR.

Antes da primeira alteração cloud

É necessário o mosaico do produto correto no tenant de destino em Security Operations > Integrations > Marketplace, permissões administrativas cloud aprovadas para os recursos e uma equipa responsável por custos recorrentes, chaves e qualidade dos dados. Verificar disponibilidade e campos no próprio tenant; não substituir um mosaico ausente por uma integração de nome semelhante.

Documentar por origem conta ou subscrição cloud, região, categorias pretendidas, integração de destino e início da ingestão. Limitar as permissões ao percurso previsto. Os direitos administrativos exigidos no deployment não justificam usar permanentemente uma conta pessoal de administrador como identidade da integração. Lambda, Storage e Pub/Sub podem gerar custos cloud separados.

Um estado verde confirma comunicação, não ingestão completa. A aceitação exige um evento inofensivo autorizado com prova e hora na origem, seguido do registo normalizado correspondente. O guia de integrações explica permissões, fluxo e distinção face a ações de resposta.

AWS VPC Flow Logs através de um bucket S3 próprio

AWS VPC Flow Logs é recolhido a partir de um bucket Amazon S3 próprio. A Sophos fornece um modelo CloudFormation que cria uma função Lambda de encaminhamento. Exigem-se conta AWS, bucket com flow logs e permissões para criar os recursos Lambda, CloudFormation e IAM necessários.

  1. Abrir AWS VPC Flow Logs no Marketplace Sophos. Em Configured integrations > Add new, ler as informações S3, escolher Next, atribuir um nome identificável e selecionar Done. Transferir o modelo gerado após o aprovisionamento e guardá-lo com acesso restrito.
  2. Em AWS, direcionar a exportação VPC prevista para esse bucket. O destino tem de ser Amazon S3. Usar apenas o formato predefinido AWS; um formato personalizado pode prejudicar a normalização e deteção.
  3. Na mesma região AWS do bucket de logs, abrir CloudFormation > Create stack, carregar o modelo e escolher um nome sem espaços. Definir IntegrationType como awsvpcflow. Em NotificationBucket, indicar o nome do bucket, não um URL ou URI S3. Se for usado deliberadamente SNS em vez de notificações S3, indicar o respetivo ARN em SNSNotificationarn. Rever os restantes parâmetros segundo o percurso planeado.
  4. Verificar e confirmar a criação de recursos IAM, criar a stack e aguardar CREATE_COMPLETE. Um bucket separado para o modelo não tem de ser público.
  5. Em Lambda, abrir a função criada pela stack. Em Function overview > Add Trigger, adicionar o bucket de logs como origem S3. Escolher Event Type: All Object Create Events. Prefix contém apenas o prefixo real dos logs; fica vazio se não existir prefixo. Deixar Suffix vazio. Avaliar os custos e adicionar o trigger.
  6. Gerar um fluxo de rede adequado e inofensivo no âmbito VPC selecionado. Confirmar primeiro o registo no bucket e comparar depois período e detalhes da ligação no esquema Sophos netflow.

O formato predefinido exigido é:

${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}

Se não chegarem dados, comparar destino de exportação, novos objetos, região e prefixo do trigger. O modelo define Reserved Concurrency como 5 por predefinição; não é uma garantia de dimensionamento. Avaliar carga e métricas CloudWatch. Rate Exceeded pode referir-se a uma quota de concorrência AWS; recriar repetidamente a integração não resolve esse limite.

Azure Network Watcher através de Storage e Azure Function

Network Watcher escreve NSG Flow Logs ou VNet Flow Logs num Azure Storage Account. Já não é possível criar novos NSG Flow Logs. Planear VNet Flow Logs para novas origens. Os NSG Flow Logs existentes podem ser ligados até à sua substituição; a Microsoft descontinua a função em 30 de setembro de 2027. Planear a sua migração para VNet Flow Logs antes dessa data. Os dois tipos exigem integrações Sophos separadas, porque usam contentores Blob ou Data Source Keys distintos.

São necessários subscrição Azure ativa, Storage Account com contentor Blob e flow logs ativos e um plano Azure Function suportado. Estão documentados Basic com B1, B2 ou B3, Dynamic com Y1 e determinados códigos Premium. Isolated não é suportado. Escolher um código Premium da lista atualmente apresentada, sem inferir suporte a partir de um nome semelhante.

  1. Em Network Watcher, enviar VNet Flow Logs de uma nova origem para o Storage Account previsto; utilizar NSG Flow Logs existentes apenas como transição até à migração. Registar nomes de conta e contentor e confirmar a chegada efetiva de novos objetos.
  2. No Marketplace Sophos, abrir Microsoft Azure Network Watcher - Azure Storage Account e criar a integração em Azure Storage Accounts > Set Up.
  3. Copiar exatamente Storage Account Name. Function App Name é um nome descritivo próprio, por exemplo NSGFlowLogsForwarder, não um valor fixo do produto. Definir Data Source Key como insights-logs-networksecuritygroupflowevent para NSG ou insights-logs-flowlogflowevent para VNet.
  4. Escolher Azure Function Service Plan Type, o Service Plan Code correspondente e Num Workers. A predefinição é um worker. Para Basic B2/B3 está documentado um máximo de três; não aplicar esse limite a todos os outros planos.
  5. Com Done, gerar e transferir AzureFunction.json. Em Azure carregá-lo através de Deploy a custom template > Build your own template in the editor. Rever Resource Group e parâmetros, depois selecionar Review + Create e Create.
  6. Storage Account e Function podem estar em Subscription IDs ou Resource Groups diferentes. Nesse caso, definir explicitamente Storage Account Subscription ID e Storage Account Resource Group da origem real.
  7. Após deployment, confirmar um fluxo esperado no contentor certo e depois em netflow na Sophos. Validar cada integração separadamente quando forem usados os dois tipos.

Se a Function estiver implementada mas faltarem dados, comparar contentor, Data Source Key, associação Subscription/Resource Group e plano. Uma segunda integração para o mesmo fluxo pode gerar duplicados; não é uma correção genérica.

GCP através de Pub/Sub

GCP fornece cloudaudit, thirdpartyalert e, com SIEM, netflow. As origens suportadas incluem Cloud Audit Logs, Security Command Center Findings, VPC Flow Logs e GKE Dataplane V2. Incluir apenas categorias escolhidas deliberadamente.

  1. No projeto GCP certo, criar um topic em Pub/Sub > Topics e uma subscrição em Subscriptions. Definir Acknowledgement deadline como 300 segundos.
  2. Em Logging > Log router > Create Sink, criar um sink para esse Cloud Pub/Sub topic. Limitar filtros às origens necessárias. Logs de organização e pasta exigem um sink agregado adequado; um sink de projeto não os abrange automaticamente.
  3. Criar uma conta de serviço dedicada. Em Add Principal na subscrição Pub/Sub, atribuir ao seu ID a função Pub/Sub Subscriber.
  4. Criar também uma função personalizada com monitoring.timeSeries.list e atribuí-la à conta. Uma conta já usada por Sophos XDR pode ser reutilizada se esta permissão adicional obrigatória também estiver aprovada.
  5. Gerar uma chave JSON e guardá-la em segurança. No Marketplace Sophos, abrir GCP > Configured integrations > Add new, introduzir nome, Project ID e Subscription ID Pub/Sub e carregar o JSON correto em Upload Key File.
  6. Ativar realmente as origens escolhidas: os logs Data Access exigem selecionar explicitamente os serviços em IAM & Admin > Audit Logs. Os findings SCC usam a exportação Pub/Sub correspondente. Ativar VPC Flow Logs ao nível da sub-rede; a amostragem limita o alcance face a uma captura integral dos pacotes.
  7. GKE Dataplane V2 tem de ser selecionado ao criar o cluster. Verificar depois Network Policy Logging e filtro do sink. Não substituir sem planeamento um cluster existente apenas para um piloto de logging.
  8. Gerar um evento adequado por categoria e verificar separadamente prova na origem, percurso Pub/Sub e esquema normalizado.

Na rotação de chaves, criar primeiro a nova chave JSON e atualizar a integração Sophos existente. Em API Query Log, secrets cache invalidated. Integration was updated. Restarting. indica a atualização. Só eliminar a chave GCP antiga após nova confirmação da ingestão. O carregamento do ficheiro, por si só, não basta.

OCI através de Streaming

OCI fornece cloudaudit, http, nids e, com SIEM, netflow. São necessários um stream OCI, os logs pretendidos e um service connector. A identidade de integração precisa de stream-pull para leitura; não exige direitos administrativos gerais para a recolha contínua.

  1. Preparar um utilizador dedicado e a estrutura aprovada de grupos/compartments. Dar apenas acesso de leitura necessário ao stream previsto.
  2. Em OCI Streams > Create Stream, escolher o Stream Pool adequado. Registar Stream Pool OCID, que não é intercambiável com um ID qualquer de stream ou compartment.
  3. Através de Connector Hub, encaminhar para o stream os logs aprovados de auditoria, flow, load balancer, WAF ou firewall. Antes da Sophos, verificar a entrega no destino Streaming correto. Outro destino do connector não alimenta automaticamente este stream.
  4. No Marketplace Sophos, abrir OCI > Configured integrations > Add new. Introduzir Name, Username dedicado, respetivo Auth token, Stream Pool ID, Tenant Name, Topic Name do stream e Region.
  5. Com compartments aninhados, Tenant Name é o nome da tenancy sem a cadeia de compartments. Para utilizadores federados no caso documentado OracleIdentityCloudService, usar por exemplo acme/OracleIdentityCloudService; acme representa a própria tenancy. Não misturar os casos.
  6. Selecionar Done e confirmar um evento adequado em OCI, no percurso Streaming e no esquema Sophos esperado. Um evento cloud audit não testa o fluxo netflow adicional.

Se a ingestão falhar, verificar primeiro Stream Pool, nome do stream, região, token e stream-pull. Se faltar apenas uma categoria, rever seleção de origens e routing do connector antes de recriar toda a integração.

Qualidade dos dados e remoção controlada

Documentar por categoria origem, início de ingestão, período, esquema e exemplo reproduzível. Comparar hora e fuso com a prova de origem. Um fluxo comum ou registo de auditoria não tem de gerar detection ou case MDR. Uma ligação verde ou um registo encontrado também não prova anos de retenção.

Antes da remoção, identificar percurso e recursos partilhados. Parar apenas exportação, sink, trigger ou connector aprovado; não eliminar indiscriminadamente bucket, topic, Storage Account ou stream partilhados. Após confirmar que não chegam novos registos, remover configuração Sophos e chaves ou recursos exclusivamente dedicados segundo as decisões de alteração e retenção. Eliminar uma ligação não prova que a telemetria histórica foi apagada.

Num piloto falhado, manter disponíveis os percursos anteriores necessários. O rollback reverte a alteração documentada de routing ou exportação e verifica o resultado. Não desfaz automaticamente dados enviados, custos cloud nem eventos perdidos.