Enviar Syslog seguro do Sophos Firewall para um SIEM

Com o Syslog, o Sophos Firewall envia eventos para um servidor de logs externo, um SIEM ou um SOC. Para que a integração seja realmente útil, quatro elementos precisam estar alinhados: transporte, seleção de logs, formato e parser. Por isso, este artigo começa diretamente pela configuração e mostra em seguida como identificar logs ausentes ou interpretados de forma incorreta.

O Log viewer local continua importante para a análise em tempo real. O Central Firewall Reporting é adequado para relatórios do Sophos Fusion (anteriormente Sophos Central); o Syslog é a escolha certa para retenção própria, correlação entre diferentes fabricantes e detecção por SIEM.

Configurar o servidor Syslog

Primeiro é preciso definir o IP de destino ou FQDN, a porta, o formato de log esperado e um parser adequado. O firewall precisa de uma rota para o Collector, e ambos os sistemas precisam de uma fonte de horário funcional. Normalmente, o SFOS usa UDP 514 para Syslog. Essa tela não oferece uma seleção de transporte separada: Secure log transmission ativa ou desativa a transmissão criptografada por TLS. No exemplo TLS oficial da Sophos para syslog-ng, é usada a porta 6514; a porta e o listener sempre precisam corresponder ao próprio Collector.

Abrir System services > Log settings.
Selecionar Add.
Atribuir um nome exclusivo, como siem-primary.
Inserir o Collector em IP address/domain.
Selecionar Port, Facility, Severity level e Format conforme o sistema de destino.
Ativar Secure log transmission se o Collector TLS estiver preparado.
Salvar.
Em Log settings, ativar os tipos de log desejados na coluna desse servidor Syslog.

O SFOS oferece suporte a até cinco servidores Syslog externos. Vários destinos fazem sentido quando cumprem funções diferentes, como um arquivo local e um Collector MDR. Enviar todos os logs indiscriminadamente para todos os destinos aumenta o volume, os custos e o risco à privacidade.

Facility, severidade e formato

Facility: As opções incluem DAEMON, KERNEL, USER e LOCAL0 a LOCAL7. Por exemplo, LOCAL1 e LOCAL2 podem diferenciar dois firewalls. Mantenha a atribuição consistente no Collector e na documentação operacional.
Severity level: A seleção representa a severidade mínima. Error também envia Critical, Alert e Emergency, mas não eventos Information ou Notice. Debug inclui todos os níveis. Uma severidade mínima alta demais pode ocultar logins e eventos operacionais comuns.
Format: Estão disponíveis Standard syslog protocol e Device standard format (legacy). O formato esperado pelo parser do SIEM é o que importa. Uma alteração posterior pode interromper pesquisas, dashboards e regras de detecção.

As Facilities identificam a origem de um log: DAEMON indica processos executados como serviços, KERNEL, processos do kernel, e USER, processos iniciados por usuários conectados. LOCAL0 a LOCAL7 permitem atribuições próprias. Na severidade, Alert é mais grave que Critical e exige ação imediata. Standard syslog protocol chamava-se antes Central Reporting Format; o Central Reporting utiliza exclusivamente esse formato. Em Device standard format (legacy), o número de campos varia conforme o módulo.

Secure log transmission

O TLS é recomendável para conexões de produção por redes inseguras ou compartilhadas, porque os logs podem conter endereços internos, nomes de usuário, URLs e eventos de segurança. No entanto, não basta ativar a opção: o Collector precisa aceitar TLS na porta escolhida, e os dois lados precisam conseguir validar os certificados.

Para a conexão Secure Syslog documentada pela Sophos, aplicam-se estas condições:

O certificado de servidor do Collector e sua cadeia de certificados precisam ser confiáveis para o firewall.
O FQDN configurado precisa corresponder ao certificado. Sem LINCE, o SFOS verifica o Common Name; com LINCE, pode corresponder o Common Name ou o Subject Alternative Name.
Em Certificates > Certificate authorities, é baixada a CA Default da Sophos. O Collector precisa confiar no arquivo Default.pem extraído dessa CA, porque a Sophos a utiliza no seu lado da conexão.
Somente depois disso, Secure log transmission é ativado com a porta TLS preparada.

No exemplo oficial do syslog-ng, Default.pem e a CA externa ficam no diretório de CAs do Collector; peer_verify(required-trusted) força a validação do certificado. Outros produtos Collector usam seus próprios Trust Stores. Um FQDN que aparece somente no SAN não funciona sem LINCE, e um endereço IP configurado não corresponde a um certificado que contém apenas um nome DNS.

Antes de ativar o LINCE para este fim, verificar o limite da certificação, os algoritmos permitidos e o reinício SSH do modo LINCE. O modo não é apenas um interruptor de syslog e não deve ser ativado sem acesso administrativo independente.

Se um SIEM na nuvem não oferecer suporte direto a esse procedimento, o firewall pode enviar os logs internamente para um Collector local, que os encaminha de forma criptografada. Um trecho sem criptografia deve ser curto, segmentado e documentado.

Preparar um Collector TLS com syslog-ng

Este exemplo exige um Collector Linux com syslog-ng, suporte TLS ativado e um certificado de servidor emitido por uma CA externa. O firewall é o cliente que envia os logs. ExternalCertificate.pem é o certificado de servidor, ExternalPrivateKey.key sua chave privada e ExternalCA.pem a CA emissora. São nomes de exemplo; adaptar caminhos e certificados ao próprio Collector. A chave privada permanece protegida no Collector; a chave privada da CA do firewall não é necessária.

Verificar a CA existente em Certificates > Certificate authorities > Default. Seu nome não pode ser alterado. Country name, State e Locality name descrevem país, região e cidade; Organization name e Organization unit name, o titular e o departamento. Common name contém um nome ou FQDN, e Email address, um contato. Private key password permite alterar uma senha de CA existente. Key type oferece RSA ou Elliptic curve: escolher Key length para RSA ou Curve name para Elliptic curve; Secure hash define o algoritmo de hash. Key length é o tamanho da chave RSA em bits; chaves maiores oferecem mais margem de segurança, mas exigem mais processamento. Os exemplos de identidade de CA são Example AG, IT Security e fw01.example.com; substituir pelo titular, departamento e convenção de nomes aprovada do próprio ambiente. Esses atributos de CA não são o certificado de servidor do Collector e não substituem seu FQDN correspondente.

Proteger a CA existente: Não alterar nem regenerar a CA Default apenas para Syslog. Planejar qualquer alteração necessária com backup, janela de manutenção e verificação dos serviços dependentes; renovar a CA Default explica as consequências. Atualizar suas configurações com Save regenera automaticamente a CA Default e altera a âncora de confiança. Salvar somente alterações aprovadas na janela de manutenção planejada. Depois, baixar o arquivo tar.gz pelo botão de download e extrair o certificado público de CA Default.pem.

No Collector, colocar Default.pem e ExternalCA.pem em /etc/syslog-ng/ca.d/, e ExternalCertificate.pem e ExternalPrivateKey.key em /etc/syslog-ng/cert.d/. Verificar antes os diretórios e arquivos existentes; não sobrescrever certificados sem planejamento. Somente o serviço responsável e os administradores autorizados devem poder ler a chave privada.

Executar estes comandos no Collector Linux, não na SFOS Device Console. O primeiro lê o certificado. O segundo cria um link simbólico no diretório de CAs e exige permissão de escrita:

cd /etc/syslog-ng/ca.d/
openssl x509 -noout -hash -in Default.pem

Usar o hash realmente retornado, não copiar 52412b66 cegamente. Para a saída de exemplo 52412b66, o comando é:

ln -s Default.pem 52412b66.0

Se já existir uma entrada .0, verificar primeiro seu destino em vez de sobrescrevê-la. Após trocar o certificado, verificar novamente o hash e a associação.

Este exemplo de syslog-ng.conf mostra um listener TLS e duas saídas locais. @version: 3.15 é a declaração de versão do exemplo documentado, não uma recomendação de instalar uma versão obsoleta. Verificar sintaxe, módulos e declaração com a versão instalada antes do uso. Integrar o exemplo à configuração existente sem substituir suas outras origens e destinos.

@version: 3.15
@include "scl.conf"
source s_src {
    network(ip(0.0.0.0) port(6514)
        transport("tls")
        tls( key-file("/etc/syslog-ng/cert.d/ExternalPrivateKey.key")
             cert-file("/etc/syslog-ng/cert.d/ExternalCertificate.pem")
             ca-dir("/etc/syslog-ng/ca.d")
             peer_verify(required-trusted))
    ); };
destination d_local {
    file("/var/log/messages");
    file("/var/log/messages-kv.log" template("$ISODATE $HOST $(format-welf --scope all-nv-pairs)\n") frac-digits(3));
};
log { source(s_src);
    destination(d_local);
};

0.0.0.0 associa todos os endereços IPv4 do Collector. Em produção, preferir o endereço de recebimento previsto e restringir TCP 6514 aos firewalls emissores pelo firewall do host. A porta 6514 deve corresponder à entrada do SFOS. key-file e cert-file indicam a identidade do servidor, e ca-dir, os dois certificados de CA; não desativar peer_verify(required-trusted) para contornar erros. Os destinos de arquivo oferecem logs brutos e uma saída adicional de chave-valor com precisão de milissegundos; adaptar caminhos, permissões, rotação e capacidade de armazenamento.

Antes de iniciar, verificar a configuração com a função de validação da versão instalada. Iniciar o serviço ou aplicar alterações de forma controlada em uma janela aprovada; em caso de problemas, retornar à configuração salva. Depois, no SFOS, definir Collector, porta 6514 e Secure log transmission em System services > Log settings > Add e clicar em Save. Selecionar os módulos necessários na coluna do servidor. O sucesso exige uma conexão TLS sem erros de confiança, um evento de firewall gerado deliberadamente nos arquivos de saída e campos corretamente interpretados no SIEM.

Definir os tipos de log e a visibilidade

O destino é ativado em duas etapas:

A regra ou função correspondente precisa gerar o evento. Nas regras de firewall, isso exige Log firewall traffic; nas regras de SSL/TLS Inspection, Log connections.
Em System services > Log settings, o tipo de log correspondente precisa ser selecionado na coluna do servidor Syslog.

Se uma das duas etapas estiver ausente, o Collector não poderá receber o evento. Para um piloto, basta começar com um conjunto pequeno e definido de forma consciente:

Firewall e Events: eventos de regras, atividades de administradores e usuários, além de eventos de autenticação, VPN, DHCP e DNS.
IPS, Content filtering, Web server protection e Zero-day protection: decisões de segurança e de políticas.
Active threat response: correspondências de MDR, NDR Essentials, Sophos X-Ops e Third-Party Threat Feeds.
System health, Wireless, Heartbeat e SD-WAN: estado operacional adicional quando esses módulos são utilizados.

Outros módulos só devem ser adicionados quando houver um objetivo de pesquisa, alarme ou auditoria. Ao analisar eventos de DoS, também é necessário verificar a configuração de Spoof Protection e DoS. Para Third-Party Threat Feeds e NDR e Active Threat Response, além do transporte de logs, são necessárias pesquisas e alarmes específicos.

Âmbito do ATR: Ativar o registo de origens remotas apenas para combinações de módulo e caminho de tráfego cujo suporte esteja estabelecido. O texto ATR da Sophos e a matriz de tráfego SVG contradizem-se quanto às direções de correspondência do X-Ops; este conflito continua por resolver. As afirmações sobre MDR, NDR ou feeds de terceiros não comprovam suporte equivalente no X-Ops. Manter controlos restritivos de firewall, DNAT/WAF e Device Access independentes do comportamento contestado do feed. Os casos contestados exigem uma verificação autorizada e controlada do módulo, da direção de correspondência, dos logs e do efeito real, além de um esclarecimento fiável; até lá, a proteção não deve depender desse comportamento. NDR e Active Threat Response explica o contexto seguro.

API XML: separar Collector, seleção de logs e supressão

Quem gerencia Syslog pela API XML precisa tratar estes três níveis separadamente. Os exemplos de adição/atualização para SFOS 22.0 e SFOS 23.0 distinguem:

Configurações do Collector: endereço de destino, porta, TLS, Facility, severidade e formato determinam o destinatário e a transmissão. Criar ou selecionar um Collector não ativa automaticamente todos os logs.
Envio por grupo e submódulo: dentro de LogSettings, SendLogs representa o nível do grupo; submódulos individuais podem sobrescrever essa seleção. O exemplo adverte explicitamente que não se deve especificar SendLogs quando todos os submódulos estiverem listados. Portanto, não tratar essas formas como uma ativação indiscriminada. Para PolicyRules, o comentário do exemplo indica Disable como padrão; isso não implica a liberação automática de todos os eventos de regras. O logging na respectiva regra continua sendo necessário adicionalmente.
Supressão: no exemplo, Log_suppress aparece separado do envio. O agrupamento de eventos repetidos não é o mesmo que a seleção de seu destinatário ou de um filtro de severidade.

A tabela de parâmetros lista Name duas vezes e descreve a segunda linha como status de supressão; além disso, apresenta literalmente uiui como padrão. Isso não é uma base confiável para um padrão operacional nem para uma renomeação implícita do campo. Não deduzir disso um payload completo de supressão; esclarecer primeiro os campos ambíguos da API com a ajuda do build específico ou com o suporte da Sophos. Antes e depois de uma alteração aprovada, gerar os mesmos eventos representativos e comparar os logs brutos no Collector, os campos do parser no SIEM, os tipos de log esperados e log_occurrence. Uma conexão existente, por si só, não comprova a seleção correta de logs.

Falhas comuns de visibilidade

Log Suppression: O SFOS pode agrupar eventos de firewall idênticos e consecutivos. Isso afeta o Log Viewer, o Sophos Fusion e o Syslog. Portanto, o parser e a detecção também precisam considerar log_occurrence.
Active Threat Response: Remote Source Match para tráfego DNAT ou WAF de entrada não fica ativo por padrão. Sem essa seleção, as correspondências de origem relevantes ficam ausentes nos módulos e caminhos de tráfego suportados. Respeitar também o âmbito do ATR acima ao investigar tipos de correspondência ausentes; selecionar a opção não comprova suporte para as direções contestadas do X-Ops.
Wireless: Os logs de Access Points e SSIDs não estão disponíveis no Log Viewer local. Eles precisam ser enviados de forma direcionada ao Sophos Fusion ou Syslog e verificados no destino.
Content filtering e SSL/TLS: O tipo de log selecionado não substitui o logging na regra de firewall ou de Inspection correspondente.
Web Proxy: Para tráfego web nas portas 80 ou 443, o log Firewall pode mostrar Allowed enquanto o Web Filter bloqueia a mesma solicitação. Correlacione os eventos Firewall e Web Filter para determinar a decisão de política efetivamente aplicada.

Verificar o formato e o parser

Um teste do parser não deve apenas demonstrar que algum texto chegou. Os valores principais precisam ser pesquisáveis como campos separados. Este exemplo abreviado e anonimizado corresponde ao Standard syslog protocol para um evento de regra de firewall:

device_name="BRANCH-01" timestamp="2026-08-03T09:15:21+0200" device_model="XGS136" device_serial_id="C00000000000000" log_id="010101600001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" log_version=1 severity="Information" fw_rule_id="12" fw_rule_name="LAN_to_WAN_Web" nat_rule_id="4" src_ip="10.10.20.25" dst_ip="203.0.113.10" protocol="TCP" src_port=53144 dst_port=443 con_event="Stop" log_occurrence="1"

O formato legacy utiliza, entre outros, device, date, time, timezone, device_id e priority. Campos como status, user_name, nat_rule_id ou log_occurrence também dependem do tipo de log e do evento. Eles não devem ser tratados como obrigatórios para todos os eventos no formato padrão. A lista seguinte é uma lista de verificação dependente do caso de uso, não um esquema obrigatório universal. Defina os campos obrigatórios separadamente para cada tipo de log ativado, com base no esquema correspondente à versão e num evento real representativo. Os campos de regra e NAT aplicam-se apenas aos tipos de evento correspondentes confirmados; avalie os campos de ligação e utilizador e log_occurrence apenas quando forem fornecidos. A ausência de campos que não se aplicam ao tipo de evento não deve provocar o descarte de eventos válidos nem a sua classificação como falhas do parser.

Para a aceitação, dependendo do caso de uso, são especialmente importantes:

Identidade: device_name, device_model, device_serial_id
Classificação: log_id, log_type, log_component, log_subtype, severity
Política: fw_rule_id, fw_rule_name, nat_rule_id
Conexão: src_ip, dst_ip, portas, protocolo e usuário
Horário e frequência: timestamp, fuso horário e log_occurrence

log_id contém tipo de log, componente, subtipo, severidade e Message ID. Com isso, as regras de detecção ficam mais estáveis do que pesquisas de texto livre. Mesmo assim, os campos fornecidos por cada módulo precisam ser verificados com um evento real desse tipo de log.

Os doze caracteres ocupam posições fixas: os caracteres 1 e 2 formam o Log Type ID, 3 e 4 o Component ID, 5 e 6 o Subtype ID, o carácter 7 o Priority ID e os caracteres 8 a 12 o Message ID. Assim, 010101600001 é lido como 01 / 01 / 01 / 6 / 00001. O parser tem de preservar os zeros à esquerda e as larguras fixas dos campos; como verificação adicional, devem ser avaliados log_type, log_component, log_subtype e severity.

O módulo Syslog Events não é idêntico a configuration-audit.log. Os valores anteriores e posteriores só estão disponíveis para objetos-chave compatíveis, como regras de firewall, interfaces e IP hosts, e não para todas as alterações de configuração. O escopo e a análise são abordados no artigo sobre Audit Trail Logs.

No exemplo documentado 010101600001, o primeiro 01 significa Security policy, o segundo 01, Firewall rule, o terceiro 01, Allowed, 6, Information, e 00001, Firewall traffic allowed. Os IDs de posição fixa e os campos de texto emitidos têm funções diferentes; não deduzir os campos de texto de um ID numérico sem verificação. Outros Message IDs exigem um catálogo de referência Syslog adequado à versão SFOS utilizada; essa decomposição não explica todos os tipos de evento.

Vários firewalls e HA

Em um ambiente com vários appliances, cada evento precisa ser atribuído claramente ao firewall, local, cliente e cluster HA. Portanto, hostname, número de série, modelo e Facility devem estar documentados e disponíveis como filtros no SIEM. A partir do SFOS 22.0, device_name identifica o hostname do firewall que gerou o log. Após um upgrade, verifique se o parser processa esse campo em vez de continuar usando apenas device_serial_id ou o cabeçalho Syslog como chave do asset.

Depois de um failover HA, restore ou troca de hardware, é preciso verificar se os eventos continuam associados ao asset existente ou aparecem como um sistema novo ou duplicado. O mesmo se aplica depois de uma alteração no hostname ou no formato Syslog.

Testar a integração com eventos reais

Um Collector com status verde não comprova a seleção correta de logs nem o funcionamento do parser. Para a aceitação:

Documentar um firewall piloto e o estado inicial: nome do servidor, destino, porta, TLS, Facility, Severity, Format e todos os tipos de log ativados na coluna desse servidor.
Enviar inicialmente Firewall e Events para o destino.
Acionar uma regra de teste com logging e Source, Destination e Service definidos.
Verificar no SIEM o dispositivo, horário, tipo de log, ação, Rule ID, Source e Destination.
Gerar um drop definido e estabelecer e encerrar uma conexão VPN.
Testar pelo menos um evento de segurança de IPS, Content filtering ou Active threat response, se o módulo for utilizado em produção.
Depois, ativar outros tipos de log gradualmente e observar o volume e o resultado do parser.

Para testar regras, é útil consultar o guia sobre Log Viewer, Policy Test e Packet Capture. Um teste negativo também é importante: uma conexão esperada é bloqueada de forma deliberada e precisa aparecer como drop com a regra correta.

Em projetos de HA ou migração, a aceitação deve incluir um teste de failover, restore ou troca de hardware. Depois disso, o SOC ainda precisa reconhecer qual dispositivo e qual local geraram o evento.

Reverter uma alteração sem criar uma lacuna nos dados

Não altere o formato, a severidade mínima e a seleção de logs ao mesmo tempo. Se uma das cinco vagas de servidor estiver livre, adicione um segundo destino para a migração do parser ou do Collector e mantenha ambos em paralelo inicialmente. Assim, é possível comparar os dados brutos, os campos preenchidos, os timestamps e o volume sem alterar o destino que está funcionando.

Somente depois da aceitação, desative os tipos de log na coluna do destino antigo. Mantenha a entrada desse servidor durante um período de observação acordado. Se faltarem eventos, o parsing falhar ou o volume for inesperado, reative ali exatamente os tipos de log documentados anteriormente e desfaça a seleção no novo destino. Se não houver uma vaga de servidor livre, registre os valores atuais antes de cada alteração individual e restaure-os por completo em caso de falha; não exclua a entrada nem altere o parser ao mesmo tempo.

Excluir pela API não é desativar a coluna de logs: as tabelas de exclusão para SFOS 22.0 e SFOS 23.0 indicam apenas Name como não obrigatório, mas o descrevem como status de supressão e não mostram um seletor de destino. Essa tabela contraditória não comprova nem uma seleção segura do destino quando o nome é omitido, nem a equivalência entre excluir um Collector e desativar seus tipos de log. Manter o Collector que está funcionando durante a migração. Antes de uma exclusão pela API, a identidade inequívoca e aprovada da entrada a ser removida e a sintaxe de exclusão precisam estar esclarecidas com base na ajuda da API do build específico ou com o suporte da Sophos; não adivinhar um seletor.

Operação, retenção e falhas

Uma integração Syslog precisa de um Owner, uma retenção definida e uma resposta aos alarmes. Também deve estar claro quem avalia falsos positivos e ajusta as regras de detecção. Os logs de firewall podem conter dados pessoais, endereços internos, nomes de usuário, URLs e atividade de VPN. Portanto, os direitos de acesso, os prazos de exclusão, a separação de tenants e os custos do SIEM devem ser esclarecidos antes de um rollout amplo.

A operação precisa detectar não apenas ataques, mas também a ausência de dados:

monitorar uma atividade mínima esperada por firewall;
verificar separadamente se tipos de log importantes, como Firewall, Events, IPS ou Active threat response, estão atualizados;
monitorar campos centrais do parser para identificar valores vazios ou renomeados de forma inesperada;
gerar alertas sobre a expiração de certificados e o estado do Collector;
voltar a gerar eventos de teste depois de atualizações de firmware, parser ou certificados.

O próprio monitoramento também precisa ser testado: se um tipo de log esperado ou um firewall parar deliberadamente de enviar dados, o alarme de ausência definido deve ser acionado.

Dados brutos sem campos interpretados também representam uma falha. Uma atualização do parser pode manter o transporte intacto enquanto dashboards e regras de detecção deixam de gerar correspondências.

O Syslog não substitui os Service Logs locais nem um arquivo de troubleshooting para o suporte. Para registros NetFlow v5 de regras de firewall com logging direcionado, usa-se NetFlow; para amostras de interface e padrões de tráfego, sFlow. O estado do hardware e das interfaces também pode ser monitorado por SNMP.

Isolar os erros de forma direcionada

Nenhum log chega: Verificar o destino, a porta, o transporte, o roteamento e o firewall do lado oposto. Depois, confirmar se o tipo de log desejado está ativo na coluna Syslog. Se o Collector estiver atrás de uma VPN ou rede de gerenciamento, considerar também a rota, a SD-WAN Policy e o Source NAT.

Somente determinados eventos estão ausentes: Primeiro, verificar o logging na regra de firewall ou de Inspection afetada e, em seguida, o tipo de log em Log settings. Para ATR, verificar também o Match Type necessário.

Primeiro, confirmar se o módulo e o caminho de tráfego são suportados. Respeitar o âmbito do ATR acima: a ausência de logs não resolve o conflito do X-Ops, e as direções contestadas não justificam simplesmente ativar outros tipos de correspondência.

Logs brutos chegam, mas faltam campos: Comparar o formato configurado, a versão do parser e a versão do firmware. Campos padrão e legacy não devem ser esperados no mesmo perfil de parser.

TLS não conecta: Verificar a porta TLS e o serviço do servidor e, depois, a cadeia de certificados, o FQDN, Common Name, SAN e o modo LINCE. Além disso, o Collector precisa confiar na CA da Sophos Default.pem. Ao trocar certificados, verificar os dois Trust Stores e o processo de renovação.

Os timestamps não correspondem: Verificar o NTP no firewall e no Collector, o fuso horário do SIEM e a normalização do parser. Horários incorretos impedem uma correlação confiável com logs de Endpoint, servidor e identidade.

Muitos logs ou muito ruído: Não desativar tudo indiscriminadamente. Primeiro, avaliar os tipos de log não utilizados, as regras desnecessariamente ruidosas, os casos de uso do SIEM e log_occurrence; depois, reduzir a seleção de forma direcionada.