Mitigar um achado sem patch

Feche uma configuração incorreta ou contenha uma vulnerabilidade ainda sem correção alterando o próprio host, pelo WASViking Infrastructure Defense. Mitigações prontas, workarounds para vulnerabilidades conhecidas, ações antes e depois de um job de patch, scripts revisados e mudanças de software, cada uma aprovada, verificada pelo inventário seguinte, vigiada contra reversão e reversível.

Alguns achados não se fecham com uma atualização. Um controle de postura falha porque um valor de registro nunca foi definido, uma vulnerabilidade ainda não tem correção do fabricante, um serviço de banco de dados precisa parar antes da atualização e voltar a rodar depois dela. A tela Mitigation do Infrastructure Defense faz essas mudanças no host por meio do agente Sentinel Host, com a mesma disciplina que o Resolve aplica às atualizações: toda mudança é um job, uma pessoa aprova, o agente registra o que substituiu, o inventário seguinte prova que a mudança se manteve, e ela pode ser desfeita. Ao final deste guia você terá aplicado uma mitigação pronta, lido o veredito, contido uma vulnerabilidade sem correção, anexado ações a um job de patch e visto onde entram os scripts e as mudanças de software.

Antes de começar

• Infrastructure Defense habilitado, com o agente Sentinel Host reportando a partir dos hosts que você quer alterar.
• As permissões no Infrastructure Defense:
• Remediate para aplicar uma mitigação, executar um script aprovado, instalar ou remover software e desfazer uma mitigação;
• Manage e Remediate para anexar ações a um job de patch;
• Author mitigation actions para adicionar scripts à biblioteca e ligar os scripts para a organização;
• Approve para aprovar jobs e revisar scripts.

Os papéis Admin e Manager têm todas elas por padrão. - Um agente recente. Cada tipo de mudança precisa da versão que o trouxe; as telas oferecem apenas o que o agente do host executa e mostram Agent update required (atualização do agente necessária) caso contrário.

Atualize os agentes em Infrastructure Defense → Sentinel Hosts.

O que uma mitigação pode alterar

Uma mudança que precisa de reinicialização pede uma: o host reinicia uma única vez, ao final do job, quando a política do host e o aprovador permitem.

O agente verifica cada mudança antes de tocar em qualquer coisa e recusa os locais que prejudicariam o host ou o entregariam a um atacante: os repositórios de credenciais, o próprio serviço e a própria pasta, os pontos clássicos de inicialização e persistência, o acesso remoto do qual você depende, os gerenciadores de pacotes, o kernel e a cadeia de boot. Uma mudança recusada diz o porquê.

Passo 1: aplicar uma mitigação pronta

Abra Infrastructure Defense → Mitigation. Available mitigations (mitigações disponíveis) lista, para cada host, os controles de postura com falha que uma mudança curada corrige: desligar o LLMNR, ligar a proteção do LSA, exigir assinatura SMB, exigir Network Level Authentication para a Área de Trabalho Remota, bloquear sessões ociosas, restringir a enumeração anônima e outros no Windows; a randomização do espaço de endereços, o escopo do ptrace, os SYN cookies, o encaminhamento de IP e os parâmetros de rede do kernel no Linux. Cada linha diz o que a mudança faz e o Side effect (efeito colateral) a ler antes de aplicá-la.

Clique em Apply em uma linha, ou marque várias linhas (em um host ou em muitos) e clique em Apply to selected. Uma seleção cria um job por host; hosts em ambientes diferentes geram jobs separados porque cada ambiente tem a própria regra de aprovação. O motivo que você digitar vai para o registro de aprovação. A tela Configuration oferece a mesma mudança com um botão Mitigate ao lado do controle com falha.

Passo 2: aprovar e acompanhar

O job aparece no Resolve e em Recent mitigation jobs (jobs de mitigação recentes), no final da tela Mitigation. Ele segue a governança de aprovação do ambiente do host como qualquer atualização: automática, uma pessoa ou um quórum formal, dentro da janela de manutenção a menos que o aprovador o execute na hora. Um job que traz um script ou uma mudança de software nunca é aprovado automaticamente, diga a regra o que disser.

O agente aplica as etapas em ordem e reporta cada uma com o valor ou o estado que encontrou antes e o que deixou. Uma mudança por vez roda em um host, e todas as regras de espera, reinicialização e host offline do Resolve se aplicam.

Passo 3: ler o veredito e manter a mudança vigiada

O job é concluído quando o inventário seguinte prova a mudança: Mitigation verified: 1 of 1 steps applied; 1 of 1 controls now pass. O achado de postura se fecha como sempre, passando na verificação.

Uma mitigação verificada continua vigiada. Se algo colocar a configuração antiga de volta, muitas vezes uma atualização de Group Policy ou uma execução de gerenciamento de configuração, o inventário seguinte a marca como Reverted (revertida) com o controle que falhou e quando, o achado reabre, e um alerta Mitigation Reverted vai para os seus canais. Aplique-a de novo, ou corrija o que a reverteu.

A página do ativo lista o mesmo histórico em Mitigations on this host (mitigações neste host), com um botão Undo (desfazer) por mudança.

Undo cria um job a partir do que o agente registrou antes da mudança: os valores de registro, os estados de serviço e os parâmetros do kernel anteriores, e o script de desfazer de uma etapa de script. Exige um motivo e segue a mesma aprovação da mudança que reverte.

Conter uma vulnerabilidade ainda sem correção

Para algumas vulnerabilidades o fabricante documenta um workaround: um valor de registro ou uma configuração de serviço que fecha o caminho de ataque até que a atualização possa ser instalada. O WASViking^® traz esses workarounds para vulnerabilidades conhecidas do Windows, entre elas o caminho remoto do Print Spooler (CVE-2021-34527 e CVE-2021-1675), o caminho ActiveX do MSHTML (CVE-2021-40444), a compressão do SMBv3 (CVE-2020-0796), o estouro do servidor DNS (CVE-2020-1350), a navegação entre protocolos do Office (CVE-2023-36884), o caminho de pré-autenticação da Área de Trabalho Remota (CVE-2019-0708) e o Equation Editor legado (CVE-2017-11882).

Uma vulnerabilidade com workaround mostra um chip Mitigation available (mitigação disponível) na tela Vulnerabilities, e a página dela oferece Mitigation options (opções de mitigação). A tela de opções coloca as duas respostas lado a lado: Remediation, a atualização do fabricante quando existe, e Mitigation, o workaround com o que ele altera e o efeito colateral, os hosts onde a vulnerabilidade está aberta e se cada um pode receber a mudança agora.

Marque os hosts e clique em Mitigate now. Quando o inventário seguinte prova o workaround em um host, a vulnerabilidade nesse host é marcada como Mitigated, no fix applied (mitigada, sem correção aplicada): ela sai da pontuação como um risco aceito sai, aparece separada em Mitigated, no fix applied na tela de opções, e reabre no momento em que o workaround é revertido ou desfeito. Só um workaround verificado define esse estado; ninguém pode escolhê-lo à mão como aceite de risco. O agente relê o workaround a cada inventário, e é por isso que ele exige a versão 0.1.50 ou posterior.

Um workaround fecha um caminho, a atualização fecha a vulnerabilidade. Instale a atualização pelo Resolve quando ela existir.

Executar ações antes e depois de um job de patch

Algumas atualizações precisam do host preparado: um serviço parado para que os arquivos dele possam ser substituídos, um valor definido que o instalador verifica, um serviço iniciado de novo depois. No Resolve, abra Review em uma ação recomendada e expanda Pre-actions and post-actions (pré-ações e pós-ações). Clique em Add an action, escolha quando ela roda (Before the updates, antes das atualizações, ou After the updates, depois delas), a ação e os campos dela, e marque Stop the job if this fails (parar o job se isto falhar) quando as atualizações não puderem rodar sem ela.

Um job aceita até cinco pré-ações e cinco pós-ações. Elas rodam nesta ordem: pré-ações, as atualizações, pós-ações, e então uma reinicialização ao final quando algo a pediu e a política permite. As pós-ações rodam qualquer que seja o resultado das atualizações. Uma pré-ação que falha com Stop the job if this fails para o job antes de qualquer atualização ser instalada, e o job diz qual ação o parou.

O aprovador vê todas as ações antes de o job rodar, no Resolve, no e-mail de aprovação e na exportação dos registros de aprovação. A página do job mostra cada ação com o estado que o host reportou antes e depois dela.

Uma nova tentativa mantém as ações. Um job de rollback também as aceita.

Usar scripts da sua própria biblioteca

Quando nenhuma mudança tipada cobre o que você precisa, a Action script library (biblioteca de scripts de ação) na tela Mitigation guarda os scripts da sua organização. Os scripts ficam desligados até que alguém com Author mitigation actions ligue Allow scripts for this organization, e a confirmação diz o que isso significa: um script aprovado pode fazer tudo o que a conta de sistema pode fazer no host.

1. Add a script or a new version (adicionar um script ou uma nova versão). Dê um nome, a plataforma, o interpretador (PowerShell no Windows, sh ou bash no Linux e no macOS), o corpo (até 20 KB), os parâmetros e, opcionalmente, um script de desfazer. Salvar com um nome que já existe cria a versão seguinte; as versões nunca mudam depois de salvas.
2. Revisão. Toda versão começa In review (em revisão). Uma pessoa com Approve que não seja a autora a lê e a aprova. Equipes pequenas podem ligar Allow single-person review (permitir revisão por uma só pessoa); a mudança fica registrada na trilha de auditoria.
3. Run on a host (executar em um host), ou anexe o script como pré-ação ou pós-ação. Só versões aprovadas podem ser usadas, só em hosts da plataforma delas, e o job ainda precisa da própria aprovação. O job é assinado para aquele host: um script enviado a outro host, ou editado depois da aprovação, não roda.

Parâmetros. Declare-os como uma lista, por exemplo [{"name": "SERVICE_NAME"}, {"name": "API_TOKEN", "secret": true}]. Cada um chega ao script como a variável de ambiente WV_PARAM_ seguida do nome em maiúsculas, aqui WV_PARAM_SERVICE_NAME e WV_PARAM_API_TOKEN. Os valores comuns são digitados como linhas name=value (nome=valor) quando você executa o script. Um parâmetro secreto ganha um campo de senha: o valor é criptografado no momento em que você o envia, para aquele único host, com uma chave que só aquele host tem. O WASViking^® nunca o guarda em forma legível, o aprovador nunca o vê, e ele é mascarado na saída do script que o job guarda.

Códigos de saída. O script diz ao job como foi:

Uma etapa que roda além do que a política permite é encerrada junto com todos os processos que iniciou. O job guarda a parte final da saída, com os valores que parecem segredos mascarados.

Manter scripts fora de um host. A política do host decide se scripts aprovados podem rodar nos hosts dela. Um host sensível também pode recusar scripts, diga a nuvem o que disser: adicione allow_remote_scripts: false ao configs/config.yaml no diretório de dados do agente e reinicie o agente. A página do ativo passa a dizer que o host bloqueia scripts na configuração local, e nenhum job de script é criado para ele.

Instalar e remover software

Abra a página Installed Software (software instalado) de um host.

• Uninstall (desinstalar) aparece em um programa que o agente consegue remover sem interação: no Windows, um produto do Windows Installer ou um programa que registrou um comando de desinstalação silenciosa; no Linux, um pacote que o gerenciador de pacotes consegue remover sem levar nenhum outro pacote junto. Software protegido (o kernel, a cadeia de boot e de login, os gerenciadores de pacotes, o acesso remoto, o próprio agente) nunca é oferecido. Os demais mostram Not removable here (não removível aqui) com o motivo.
• Install software on this host (instalar software neste host) aceita um id de pacote do winget no Windows ou um pacote dos repositórios configurados do host no Linux, com uma versão opcional.
• Install from an installer file (instalar a partir de um arquivo instalador, no Windows) aceita um instalador que você enviou em Sentinel Gateways → Installer uploads, ou um link https com o SHA-256 do arquivo, o tipo (MSI ou EXE), os parâmetros silenciosos e o assinante esperado. O host baixa o arquivo diretamente por HTTPS (pelo proxy do sistema, quando houver um), confere o SHA-256 fixado e a assinatura Authenticode, e o assinante esperado quando você o informou, e então o executa em modo silencioso. Nada roda se qualquer verificação falhar.

Uma mudança de software é assinada para o host e nunca é aprovada automaticamente. O inventário seguinte a prova: o programa some depois de uma desinstalação e aparece depois de uma instalação. Não há desfazer automático para software.

Definir os limites na política do host

Em Infrastructure Defense → Policies, o bloco Mitigation actions (ações de mitigação) de cada política decide:

• se approved library scripts may run on these hosts (scripts aprovados da biblioteca podem rodar nestes hosts, quando os scripts estão ligados para a organização);
• o longest action step (etapa de ação mais longa), de 1 a 180 minutos, para as etapas de mitigação e para as ações dos jobs de patch.

Mudanças de registro e de serviço nunca são bloqueadas pela chave de scripts. Uma etapa que pede reinicialização segue as configurações de reinicialização da política e a escolha do aprovador, como uma atualização.

Depois do primeiro dia

• Alertas. Mitigation Verified, Mitigation Failed e Mitigation Reverted chegam aos seus canais de Slack, Teams, e-mail ou webhook com o host e a mudança.
• Evidências. Export CSV em Recent mitigation jobs lista cada mitigação com o estado e a nota. Export approval records na tela do Resolve traz as ações de cada job na coluna host_changes, com cada decisão de aprovação.
• Trilha de auditoria. Ligar ou desligar os scripts, salvar, aprovar e aposentar uma versão de script, criar, aprovar e desfazer uma mitigação são entradas de auditoria como qualquer outra ação do Resolve. Valores secretos nunca aparecem nelas.

Solução de problemas

Uma mitigação mostra Agent update required. O agente do host ainda não executa esse tipo de mudança. Atualize-o em Sentinel Hosts; a tabela em "Antes de começar" lista a versão que cada mudança exige.

Um workaround mostra Not available on this host. O host não é um host Windows que recebe jobs, ou o agente dele é anterior à 0.1.50.

A mitigação aparece como Reverted no dia seguinte. Algo no host definiu o valor antigo de novo. Em um host Windows ingressado em domínio, normalmente é um objeto de Group Policy que gerencia a mesma configuração: altere-o lá, ou a mitigação continuará sendo desfeita a cada atualização da política.

Um job aparece como Partial. Algumas etapas tiveram sucesso e outras falharam, ou um controle ainda falha; a página do job lista cada etapa com o resultado e o motivo.

Um script não aparece em Run on a host. Ele ainda não foi aprovado, os scripts estão desligados para a organização, a política do host não os permite, o host os bloqueia localmente, ou nenhum host da plataforma do script tem um agente recente o bastante.

Um parâmetro secreto é recusado. O agente do host é anterior à 0.1.50 e não consegue abrir valores selados. Atualize-o antes de executar o script com um segredo.

Um job de instalador falhou com uma mensagem de hash ou de assinatura. O arquivo que o host baixou não é o que você fixou, ou não é assinado pelo fabricante esperado. Confira o SHA-256 e o assinante, e se o link entrega sempre o mesmo arquivo.

Próximos passos

• Reverter uma mudança que deu problema desfaz um job de atualização de segurança do mesmo jeito que o Undo reverte uma mitigação.
• Sentinel Gateways explica os envios de instaladores que uma instalação de software pode usar.
• Infrastructure Defense, em Capacidades, explica o Resolve, a governança de aprovação e como o Viking Exposure Score é medido antes e depois de cada mudança.