Portátil infetado na VPN: conter a sessão, não a rota

Os relatórios de abuso de endpoint chegam normalmente com um atalho proposto: pôr o portátil em túnel dividido para que mude o endereço visto no destino. Isso muda uma observação, não uma infeção. O dispositivo mantém todo o acesso interno que a sessão já detém, e o malware continua a correr em hardware que ninguém examinou. Três condições devem definir a ordem do trabalho: o que as credenciais do dispositivo ainda alcançam, se esse acesso está a ser usado neste momento, e que prova uma limpeza rápida destruiria.

Primeira condição: o que as credenciais ainda alcançam

Uma conta revogada ou desativada é apenas metade da resposta, porque um cliente pode guardar um certificado, um token em cache, uma chave pré-partilhada guardada ou uma credencial de máquina que sobrevive à mudança de palavra-passe. Mapeie todos os autenticadores que o perfil usa antes de escolher uma ação. Depois verifique se o produto termina sessões na revogação ou apenas recusa as novas.

Onde o gateway o suporta, termine a sessão de forma explícita e confirme pela tabela de contabilidade ou de sessões que desapareceu. Uma alteração que só afeta o próximo início de sessão deixa o fluxo atual a correr.

Segunda condição: o acesso está a ser usado agora

Correlacione a janela de alerta com a sessão real, o endereço de túnel atribuído e a identidade do dispositivo. Uma saída corporativa partilhada representa todos os que estão por trás dela, pelo que um endereço público observado não consegue identificar qual endpoint produziu um fluxo. Essa correlação é o passo que as pessoas saltam quando o alerta parece óbvio.

Use os registos que o serviço implementado realmente recolhe, como eventos de início e paragem de contabilidade que ligam uma sessão a uma identidade e a um endereço. Se esses registos estiverem incompletos, diga-o no relatório em vez de preencher a lacuna com a visão da firewall. Um relatório que separa prova de inferência resiste melhor à revisão do que um que não o faz.

Terceira condição: o que tem de sobreviver à resposta

Uma contenção que destrói a única cópia da prova é um segundo incidente. Preserve os registos relevantes, os registos de sessão e os artefactos do endpoint através do processo que detém a retenção e o acesso. Não cole uma exportação num ticket que toda a equipa de suporte pode ler.

Depois decida com o responsável do incidente quanto do endpoint reconstruir. A quarentena limita os danos enquanto o âmbito é estabelecido, e também limita o que os respondentes ainda podem observar, pelo que estes dois objetivos têm de ser trocados deliberadamente.

Como a contenção se parece na realidade

A contenção eficaz é em camadas: quarentena de rede na camada de acesso, revogação de todos os autenticadores que o perfil usa, terminação explícita da sessão e restrição das permissões internas que a conta detinha. Qualquer uma delas isolada deixa um caminho aberto.

Na primeira hora, a ordem importa mais do que a completude. A revogação antes de uma limpeza dá a oportunidade de observar a reação do cliente, e a terminação da sessão antes da revogação mostra se o gateway a respeita de todo. Registe qual controlo produziu qual efeito.

O encaminhamento é uma decisão de serviço, não uma ferramenta de contenção

O túnel dividido reduz o que a saída do escritório transporta, e o túnel completo coloca mais tráfego por um caminho de inspeção escolhido. Nenhum dos modos certifica o endpoint, e nenhum revoga uma credencial.

Um desenho de túnel completo vale a pena quando o caminho de inspeção está equipado para detetar e agir, o que é um projeto diferente do incidente à sua frente. Mudar de modo a meio do incidente produz sobretudo confusão sobre que registos pertencem a que comportamento. Decida o modo depois, com o dono do serviço e a equipa de monitorização presentes.

Condições para a readmissão

Escreva as condições de readmissão antes de o dispositivo voltar: o estado de remediação que tem de ser verificado, o estado de cada credencial exposta, os controlos do endpoint que têm de reportar, e as permissões mínimas de que a conta precisa em vez das que por acaso tinha. Classifique-as em obrigatórias e desejáveis. O conjunto original de permissões não é um requisito.

Uma análise limpa é apenas um dado de entrada, e um início de sessão bem-sucedido prova apenas que o fluxo de autenticação correu. Restaure o acesso por fases, vigiando a sessão e o uso de recursos ao abrigo do plano aprovado. Nomeie o responsável por qualquer restrição que permaneça. Se o abuso chegou a um parceiro através da saída do escritório, avise esse parceiro pelo canal que o contrato exige em vez de esperar que ele repare.