Saltar para o conteudo
Avanet

Ativar e verificar MDR Threat Feeds na Sophos Firewall

Os MDR Threat Feeds ligam o serviço Sophos MDR à Sophos Firewall. Os analistas de MDR podem enviar para a firewall, através do Sophos Fusion (anteriormente Sophos Central), endereços IPv4, domínios e URLs relacionados com um incidente ativo no ambiente do cliente. A firewall regista ou bloqueia depois o tráfego correspondente sem exigir a manutenção manual de um ficheiro de feed próprio.

Uma implementação segura requer mais do que ativar um interruptor no WebAdmin. A licença MDR, o registo no Sophos Fusion, a ação local, a visibilidade de tráfego necessária, os destinos de log e o caminho de contacto com a equipa MDR têm de estar alinhados. Um estado local Log and drop ainda não prova que um IoC específico chegou ou que o fluxo de dados afetado passa pelas verificações necessárias.

Designações na interface: Os caminhos do Sophos Fusion utilizados aqui seguem a ajuda do SFOS 22. A ajuda do SFOS 23 ainda utiliza Sophos Central para a mesma ligação à cloud. Se a sua versão apresentar essa designação, abra a página correspondente do Sophos Central; o nome, por si só, não permite concluir nada sobre o registo, o direito de utilização de MDR ou a entrega dos feeds. Send reports and logs to Sophos Central continua a ser o nome documentado da opção de registo de logs.

MDR Threat Feeds em oito passos

  1. Verificar se o Xstream Protection Bundle está ativo na firewall e se existe um direito de utilização de MDR ativo no Sophos Fusion.
  2. Em System > Sophos Fusion, confirmar que a firewall correta está registada na conta Sophos Fusion correta.
  3. Documentar no Sophos Fusion o Threat response mode pretendido e o caminho operacional de contacto MDR.
  4. Em System services > Log settings, ativar pelo menos um destino de log utilizável para Active threat response.
  5. Abrir Protect > Active threat response > MDR threat feeds e ativar a função.
  6. Escolher Log only para um piloto curto e controlado ou Log and drop para proteção em produção após uma validação bem-sucedida e clicar em Apply.
  7. Realizar as verificações positiva e negativa através do Log Viewer, do contexto do endpoint e do Sophos Fusion.
  8. Documentar o Audit ID, os responsáveis, o processo de exceções, a data de revisão e o procedimento de reversão.

Importante: Os MDR Threat Feeds são apenas uma parte da operação de MDR. Não substituem o contrato MDR, os sensores de endpoint, a comunicação de incidentes, regras de firewall restritivas ou um procedimento de recuperação testado. Uma exceção abrangente ou uma desativação não controlada pode enfraquecer uma resposta em curso da equipa MDR.

O que fazem os MDR Threat Feeds

Os analistas do Sophos MDR podem enviar informações de inteligência sobre um incidente ativo diretamente para a firewall através do Sophos Fusion. Por isso, o feed é mais específico para o cliente do que uma lista geral de reputação global. Um IoC enviado pode ser um endereço IPv4, um domínio ou um URL.

A apresentação geral da Sophos explica a interação entre o serviço MDR e a firewall. Para a configuração concreta, aplicam-se os pré-requisitos e os passos de verificação seguintes; as designações apresentadas no vídeo podem diferir das da sua versão.

A ação local da firewall determina o que acontece quando há uma correspondência:

  • Log only regista a correspondência, mas permite o tráfego.
  • Log and drop regista e descarta o tráfego correspondente.

A Sophos recomenda o bloqueio para IoCs conhecidos. Ainda assim, um piloto curto com Log only pode fazer sentido quando é necessário verificar primeiro a visibilidade, o registo de logs e os possíveis efeitos secundários num ambiente existente. Este piloto precisa de uma data de conclusão definida. Sem uma mudança planeada, a integração MDR ativa pode permanecer indefinidamente sem bloqueio local.

O Threat response mode no Sophos Fusion e a ação local do feed são dois níveis diferentes. O modo no Sophos Fusion define as autorizações de resposta da equipa MDR. Log only ou Log and drop define como a firewall trata um IoC já recebido. Antes da implementação, ambas as definições são alinhadas com o contrato MDR e com o processo interno de gestão de incidentes. A documentação atual da Sophos sobre o Threat response mode distingue Collaborate, Authorize e Notify Only.

Distinguir a telemetria da firewall da resposta dos analistas

Os dados também circulam no sentido contrário: a firewall fornece eventos de segurança para a investigação de MDR. Para isso, tem de estar registada em Sophos Central firewall management; na firewall, Sophos Central services tem de estar ativado e Send reports and logs to Sophos Central tem de estar selecionado. MDR analisa continuamente os logs de segurança de Advanced Threat Protection (ATP), Intrusion Detection and Prevention (IDP/IPS), Antivirus, Antispam, Sandstorm Sandbox, Web Protection e Application Control. Em conjunto com os dados de endpoints, servidores e outras fontes integradas, estes eventos ajudam a identificar atividade maliciosa, IoCs e tentativas de movimento lateral. No entanto, a telemetria recebida da firewall não é o feed de IoCs específico do cliente que os analistas de MDR enviam de volta para a firewall.

Num incidente crítico, a equipa MDR pode, por exemplo, terminar as sessões VPN de utilizadores comprometidos. Trata-se de uma medida de resposta a incidentes tomada pelos analistas no âmbito das autorizações concedidas, não de uma consequência automática de uma correspondência no feed nem de um procedimento local de cliques ou comandos CLI. Com Authorize, a equipa pode responder a ameaças ativas sem consultar previamente os contactos designados; com Collaborate, a resposta é coordenada com esses contactos. Isto não implica autorizações de resposta ilimitadas para todos os dispositivos ou integrações. As sessões VPN de produção não são terminadas como teste funcional.

Para intervir através de Live Response, Live Response tem de estar permitido no dispositivo em causa. Isolar Sophos Endpoint e investigar com Live Response explica os pré-requisitos e o procedimento seguro. As ações do Microsoft 365, como bloquear ou permitir inícios de sessão, revogar sessões ativas e desativar Inbox Rules, requerem que a integração de resposta esteja configurada; aplica-se o procedimento separado em Integrações MDR e XDR. O registo de logs da firewall ou a receção de um IoC de MDR não permitem automaticamente estas intervenções.

Por sua vez, os cybora.io Threat Feeds utilizados pela Avanet para a Sophos Firewall são Third-Party Threat Feeds, não Sophos MDR Threat Feeds nem feeds de MDR criados pela Avanet. A sua configuração segue o procedimento para feeds de terceiros; não concede à equipa Sophos MDR autorizações de resposta adicionais.

Compreender a ordem e o ciclo de vida

O SFOS 22 processa Active Threat Response pela ordem MDR, NDR Essentials, Sophos X-Ops e Third-Party Threat Feeds. Se um IoC corresponder em MDR com Log and drop, a firewall descarta o tráfego, regista-o em MDR e deixa de verificar os feeds seguintes. Com Log only ou Monitor, podem ser gerados eventos separados para MDR, X-Ops e Third-Party Feeds. Uma correspondência MDR com Log and drop interrompe a verificação dos feeds seguintes. Com Log only ou ações diferentes entre módulos, não se deve deduzir uma autorização geral; devem considerar-se as outras ações configuradas e verificar as evidências de tráfego e logs.

Os IoCs individuais de MDR não são criados nem editados no WebAdmin. Os analistas de MDR adicionam-nos através do Sophos Fusion e removem-nos aí. Ambas as operações são registadas com a ação e a identidade do analista como audit_ID. Estes eventos de administração devem ser procurados na vista de detalhes Admin do Log Viewer ou na Sophos Fusion Firewall Task Queue, e não confundidos com as correspondências de tráfego em Active threat response. Localmente, apenas se controla se o feed MDR está ativo e se as correspondências são registadas ou também descartadas. As Threat Exclusions, por sua vez, são globais e aplicam-se a todos os módulos de Active Threat Response.

A documentação do SFOS 22 não indica qualquer período de validade dos IoCs de MDR que possa ser configurado pelo administrador da firewall. Por isso, não se deve deduzir uma data de expiração a partir da interface local. Se uma entrada suscitar dúvidas ou puder estar desatualizada, guarde o audit_ID, o IoC e a hora e confirme o estado com a equipa MDR. Isto também é importante para a reversão: mudar de Log and drop para Log only afeta todos os IoCs de MDR atualmente recebidos; uma Threat Exclusion pode ainda enfraquecer NDR, X-Ops e Third-Party Feeds.

Verificar cuidadosamente os pré-requisitos

Licença e Sophos Fusion

Os MDR Threat Feeds requerem o Xstream Protection Bundle na firewall. A tabela de licenças do SFOS 22 indica ainda Sophos MDR Essentials ou Sophos MDR Complete no Sophos Fusion; a documentação atual do Sophos Fusion designa as variantes do serviço como MDR e MDR Plus. Por isso, deve verificar-se o direito de utilização de MDR ativo na própria conta Sophos Fusion, em vez de o deduzir apenas de uma designação antiga do produto. O Xstream Bundle, por si só, não inclui um serviço MDR.

A firewall tem de estar registada na conta Sophos Fusion correta. Em System > Sophos Fusion, verifique o registo e o envio de relatórios e logs. O procedimento completo de ligação é explicado em Ligar a Sophos Firewall ao Sophos Fusion.

Além disso, o serviço Sophos MDR tem de estar configurado. O registo da firewall e a verificação da licença, por si só, não substituem esta configuração. Antes da ativação local, confirme com o responsável de MDR que o serviço está configurado para o cliente correto e que o Threat response mode foi escolhido de forma consciente. A Sophos exige pelo menos um contacto autorizado antes de ser possível configurar outras definições de MDR ou utilizar o serviço. Para o contexto adicional do endpoint através de Synchronized Security, a tabela de licenças do SFOS 22 indica ainda uma licença Intercept X no Sophos Fusion; este contexto não é garantido apenas pelo Xstream Bundle.

Sophos MDR: configurar contactos e Threat Response descreve o processo central completo, com funções dos contactos, alternativa de Collaborate, acesso aos dispositivos e verificação segura dos valores guardados. Não substitui a configuração local do feed que se segue.

Antes da ativação, também é necessário esclarecer as responsabilidades:

  • Quem pode alterar o Threat response mode no Sophos Fusion?
  • Quem atende uma chamada ou um pedido de esclarecimento de MDR fora do horário de expediente?
  • Quem pode aprovar uma exceção?
  • Onde são documentados o Audit ID, o Incident ID e as provas técnicas?
  • Que sistemas podem ser isolados em caso de comprometimento confirmado?

Ativar destinos de log

Em System services > Log settings, ative pelo menos um destes destinos na linha Active threat response:

  • Local reporting para o Log Viewer e relatórios locais
  • um Syslog server configurado para SIEM ou SOC
  • Central reporting para o Sophos Fusion

A coluna Central reporting só aparece quando Send reports and logs to Sophos Central está ativado na página do Sophos Fusion. Os XGS 87/87w e 107/107w não suportam relatórios locais; nestes modelos, é necessário Central Reporting ou Syslog.

Depois de selecionar os destinos de log em System services > Log settings, clique em Apply. Em seguida, volte a carregar a página e verifique se os destinos pretendidos continuam selecionados na linha Active threat response. Isto confirma a configuração guardada; o transporte efetivo dos logs e a entrega de notificações de incidentes são verificados separadamente.

Para as notificações, verifique também System services > Notification list. A ativação de um destino de log define o caminho de transporte, mas não comprova a entrega efetiva nem o tratamento correto dos alertas.

Visibilidade para IP, domínio e URL

Um IoC só atua sobre tráfego que a firewall consiga processar de forma adequada. Para tráfego encaminhado com correspondência no IP de destino, é necessária uma regra de firewall adequada. As correspondências de domínio requerem Application Classification ou uma política IPS na regra em causa. Para um caminho URL HTTPS completo, é necessário Web Proxy com desencriptação ou DPI com uma regra SSL/TLS Inspection adequada.

O tráfego dirigido ao sistema para serviços em Administration > Device access, como WebAdmin, VPN Portal e VPN, pode ser verificado com base num endereço IPv4 de origem malicioso. Para o tráfego de entrada encaminhado por DNAT ou WAF, é necessário ativar também Remote source match (inbound traffic) em System services > Log settings > Active threat response para obter a visibilidade esperada nos logs.

Limitação por esclarecer em ATR/X-Ops: A descrição oficial e a matriz de tráfego contradizem-se quanto às correspondências de endereços de destino e de endereços de origem locais para Sophos X-Ops. Nestes casos, não está esclarecido de forma fiável se existe suporte ou exclusão; as informações sobre tráfego e módulos nos artigos ligados não constituem uma base de configuração aprovada para estes casos. Daqui não se deduz qualquer direção de tráfego de MDR, nem se pressupõe proteção para os casos de X-Ops afetados. Antes de efetuar uma alteração com base nesta informação, é necessário obter um esclarecimento vinculativo da Sophos ou realizar um teste do produto expressamente aprovado; os links seguintes não resolvem esta contradição.

A lógica geral de tráfego, módulos e inspeção é descrita em Configurar e operar Threat Feeds com segurança na Sophos Firewall. Esse artigo também explica por que razão a deteção de um domínio ou URL pode não ocorrer sem a classificação ou desencriptação adequada.

Configurar MDR Threat Feeds

  1. Iniciar sessão no WebAdmin com uma conta de administrador pessoal.
  2. Abrir Protect > Active threat response > MDR threat feeds.
  3. Ativar MDR threat feeds.
  4. Em Action, escolher Log only para um piloto com prazo definido ou Log and drop após uma validação bem-sucedida.
  5. Guardar com Apply.
  6. Voltar a carregar a página e confirmar que o estado do interruptor e a Action foram guardados.
  7. Verificar a data e hora, o administrador e a alteração no Audit Trail.
  8. No Sophos Fusion, confirmar que a firewall está online e que MDR está associado ao cliente ou tenant correto.

Não efetue alterações abrangentes ao registo de logs, à inspeção, às exceções e à Action ao mesmo tempo. Uma implementação faseada permite identificar a alteração que causou uma correspondência ou um efeito secundário.

Validar a eficácia de forma fiável

A ajuda de MDR consultada aqui não indica um indicador de teste MDR inofensivo de utilização geral. Por isso, aceder a um domínio de malware real ou a um IP malicioso conhecido não é uma forma adequada de validação. A verificação técnica é dividida em vários níveis demonstráveis. Um teste próprio de um feed de terceiros apenas comprova o caminho de tráfego e inspeção testado, não a entrega de um IoC de MDR pela equipa de analistas.

Configuração e transporte

  1. Verificar o interruptor de MDR e a Action pretendida na firewall.
  2. Confirmar o registo no Sophos Fusion e a licença MDR.
  3. Confirmar o registo de logs de Active Threat Response para o destino esperado.
  4. Verificar no Sophos Fusion se as tarefas de MDR ou da firewall foram processadas com êxito.
  5. Num incidente MDR real, confirmar com a equipa MDR o IoC esperado e o Audit ID associado.

A Sophos Fusion Firewall Task Queue apresenta as tarefas de MDR e API. Success confirma o processamento da tarefa do Sophos Fusion, mas ainda não o efeito sobre um fluxo de dados concreto. Em caso de Partial Success ou Failed, registe a firewall afetada, Entity, Action e Credential ID e compare estes dados com a configuração local.

Investigar correspondências no Log Viewer

Em Log viewer > Active threat response, guarde pelo menos as seguintes informações:

  • Data e hora, firewall e, em HA, o nó que processou o tráfego
  • Action e nome do feed
  • IP de origem e de destino, domínio ou URL
  • Portas e protocolo
  • Event ID e outros campos de detalhe
  • Para MDR, também o audit_ID associado, obtido a partir do evento de administração ou da Task Queue

A prova do tráfego e a ação do analista são evidências distintas. A ausência de um campo audit_ID na entrada de tráfego não constitui, por si só, uma falha de entrega. A associação é feita com base no IoC, na firewall e no intervalo de tempo e, em caso de dúvida, é confirmada com MDR.

Com Synchronized Security, a firewall pode apresentar também o utilizador, o host e o processo em endpoints Windows geridos. No Log Viewer, os campos relevantes são Process user e Executable, bem como host_process_user, endpoint_id e execution_path na vista de detalhes. No macOS, estes detalhes do processo não aparecem; nesse caso, o endpoint é identificado através do IP de origem e dos dados do Sophos Fusion.

Quando ocorre uma deteção, a firewall solicita estes detalhes aos endpoints geridos através do Sophos Fusion. A ajuda descreve a apresentação para Windows 7 e versões posteriores; isto não é uma recomendação de utilização do Windows 7 nem uma garantia de suporte atual de endpoint para todos os sistemas Windows mais antigos. No macOS, pode aparecer, em alternativa, uma mensagem genérica como Active threat C2/Generic-C deleted. Esta não substitui a identificação do host através do IP de origem nem a prova da ação da firewall aplicada ao tráfego.

O resumo local encontra-se em Reports > Network & threats > Active threat response, na lista Synchronized IoC. A Visão geral dos serviços e ficheiros de log da Sophos Firewall contextualiza também atr.log. Uma entrada de log nunca é avaliada isoladamente: os eventos da firewall, de DNS, Web, IPS, endpoint e Sophos Fusion do mesmo intervalo de tempo devem ser analisados em conjunto.

Verificações positiva e negativa

Um piloto em produção deve incluir pelo menos estes dois casos:

  1. Positivo: Num IoC ou incidente real confirmado pela equipa MDR, guarde separadamente uma entrada de tráfego rastreável com a Action correta e a ação do analista associada com Audit ID, e cruze ambas. Para isso, não se gera tráfego adicional para infraestruturas maliciosas.
  2. Negativo: Um processo de negócio legítimo comparável continua acessível e não provoca um bloqueio MDR não intencional.

Sem um incidente real, não se cria artificialmente um IoC de MDR. Em vez disso, verificam-se a configuração, o processamento das tarefas, o transporte dos logs e o caminho de comunicação. Para um teste de tráfego totalmente controlável, um feed piloto de terceiros próprio é mais adequado do que um destino malicioso externo.

Tratar uma correspondência MDR como um incidente

Uma correspondência MDR é um sinal forte, mas a entrada de log, por si só, ainda não explica o percurso completo do ataque. Um procedimento ponderado é o seguinte:

  1. Guardar a hora, Action, IoC, nome do feed, Event ID e audit_ID.
  2. Identificar o host e o utilizador afetados através do IP de origem, DHCP, Synchronized Security e dados do endpoint.
  3. Abrir no Sophos Fusion o caso MDR associado, a Detection e os restantes eventos dos dispositivos.
  4. Correlacionar os logs da firewall, de DNS, Web, IPS e endpoint no mesmo intervalo de tempo.
  5. Esclarecer com a equipa MDR por que razão o IoC foi adicionado e qual a resposta prevista.
  6. Em caso de comprometimento confirmado, acionar o procedimento interno de resposta a incidentes.
  7. Só depois decidir sobre a limpeza, regras adicionais ou uma exceção restrita.

O Audit ID identifica a ação do analista de MDR. No Log Viewer, clique primeiro no botão da vista de detalhes e selecione depois Admin no menu pendente. Aí, guarde a ação e o audit_ID da adição ou remoção. Em alternativa, a ação do analista encontra-se em My Products > Firewall management > Tasks Queue no Sophos Fusion. Num pedido de esclarecimento a MDR, inclua no caso o Audit ID juntamente com o número de série da firewall, a hora, o IoC, o Event ID e o Incident ID. Uma remoção registada comprova uma ação de administração, não a limpeza do endpoint afetado.

Gerir exceções de forma controlada

Em Protect > Active threat response > Add threat exclusions, é possível criar exceções de host/rede e de ameaças. Estas exceções aplicam-se a vários módulos. Assim, uma exceção para uma correspondência MDR também pode enfraquecer X-Ops, NDR ou Third-Party Threat Feeds.

Antes de criar uma exceção, documente o IoC, o processo de negócio afetado, o caso MDR e a confirmação do falso positivo. A exceção deve ser tão restrita quanto possível e incluir o motivo, o responsável, o ticket e a data de revisão ou expiração. Redes inteiras de clientes ou conjuntos abrangentes de domínios não são uma solução rápida adequada.

As configurações de Threat Feeds não podem ser importadas ou exportadas separadamente; as Threat Exclusions, porém, podem. As definições do feed MDR também não podem ser transferidas através de Import existing configuration para a configuração inicial de um novo grupo de firewalls no Sophos Fusion. Por isso, após uma migração, restauro ou substituição, é necessário voltar a verificar explicitamente a função, a Action, o registo de logs e a associação ao Sophos Fusion.

Quando não aparece nenhuma correspondência MDR

A verificação não começa pelo reinício de um serviço. Primeiro, separe as camadas:

  1. A licença MDR, a conta Sophos Fusion, o registo da firewall e o Threat response mode estão corretos?
  2. Os MDR Threat Feeds estão ativos localmente e a Action foi guardada?
  3. O IoC em causa foi efetivamente enviado pela equipa MDR para este ambiente?
  4. A Sophos Fusion Firewall Task Queue apresenta Success, Partial Success, Failed ou ainda Pending?
  5. Os logs de Active Threat Response estão ativados localmente, para Syslog ou no Sophos Fusion?
  6. O tráfego passa pela firewall, regra e inspeção esperadas?
  7. O IoC está incluído nas exceções de Active Threat Response, Web ou SSL/TLS?
  8. O intervalo de tempo e, em HA, o nó analisado estão corretos?

Para verificar o estado do motor e dos feeds, é possível correlacionar temporalmente atr.log com o Log Viewer e a Sophos Fusion Firewall Task Queue. Os logs são apenas consultados; alterações não documentadas a dados de feeds, bases de dados ou serviços não fazem parte do procedimento normal. Se a causa continuar por esclarecer, guarde o CTR, os logs relevantes, o Task ID, o Audit ID, a versão e a hora para o Sophos MDR ou o Sophos Support.

Reversão e controlo de alterações

Antes da ativação, documente o estado anterior do interruptor, a Action, os destinos de log e as exceções existentes. Em caso de impacto inesperado na atividade da empresa, não crie imediatamente uma exceção abrangente.

  1. Registar a correspondência afetada e o impacto na atividade.
  2. Informar a equipa MDR com o Audit ID e o incidente.
  3. Se houver aprovação dos responsáveis, repor temporariamente a Action local de Log and drop para Log only.
  4. Apenas se isso também não for suficiente e MDR concordar, repor o feed de forma controlada no estado anterior documentado.
  5. Após cada alteração, voltar a verificar o mesmo processo de negócio e o efeito nos logs.
  6. Resolver a causa e restabelecer a proteção em produção com uma nova data de revisão.

Em ambientes HA, a configuração e o estado são verificados no Primary atual. Os logs encontram-se no nó que processou o tráfego. Após um failover controlado, volte a validar a ligação ao Sophos Fusion, o estado dos feeds, as novas entradas de log e o tráfego real; não se pressupõe continuidade ininterrupta de MDR ou dos logs.

Lista de verificação

  • Xstream Protection Bundle ativo
  • Direito de utilização de MDR ativo no Sophos Fusion
  • Firewall registada na conta Sophos Fusion correta
  • Threat response mode e caminho de contacto MDR documentados
  • Destino de log de Active Threat Response ativado
  • MDR Threat Feeds ativados
  • Action escolhida de forma consciente e piloto com prazo definido
  • Visibilidade de tráfego para IPv4, domínio e URL verificada
  • Remote source match ativado para DNAT/WAF, se necessário
  • Task Queue e estado local comparados
  • Audit ID e processo de gestão de incidentes conhecidos
  • Contexto do endpoint e limitações das plataformas verificados
  • Exceções com responsável e data de revisão
  • Reversão e verificação de HA documentadas

Perguntas frequentes

Os MDR Threat Feeds estão incluídos no Xstream Bundle?

A função da firewall requer o Xstream Protection Bundle e, adicionalmente, um direito de utilização de MDR ativo no Sophos Fusion. A tabela de licenças do SFOS 22 indica MDR Essentials ou MDR Complete; o Sophos Fusion utiliza atualmente MDR e MDR Plus. O Xstream, por si só, não é um contrato MDR.

Qual é a diferença entre Threat response mode e Log and drop?

O Threat response mode no Sophos Fusion define as autorizações de resposta da equipa MDR. Log and drop é a ação local da firewall para um IoC já recebido. Ambos os níveis têm de estar alinhados com o contrato e com o processo interno de gestão de incidentes.

Como identifica MDR uma entrada específica do feed?

A vista de detalhes Admin do Log Viewer e a Sophos Fusion Firewall Task Queue apresentam o audit_ID da ação do analista. Este ID é enviado à equipa MDR juntamente com a hora, o IoC, o Event ID e o Incident ID.

É possível testar os MDR Threat Feeds com um domínio de malware?

Não, gerar tráfego intencional para uma infraestrutura maliciosa real não é um teste funcional seguro. Sem um incidente MDR real, verificam-se a configuração, o processamento das tarefas, o registo de logs e o caminho de contacto. Para um teste de tráfego controlado, é adequado utilizar um feed piloto de terceiros próprio.