MDR com resposta ativa: o que precisa estar definido antes do primeiro incidente
Contratar um serviço de MDR não significa entregar ao fornecedor autorização irrestrita para modificar o ambiente sempre que identificar uma ameaça.
Também não deveria significar que cada ação relevante precise ser negociada do zero durante um incidente.
Entre esses dois extremos existe uma questão central para a operação: definir antecipadamente como a resposta vai funcionar.
Comece pelo escopo
MDR combina tecnologia e especialistas para monitorar, investigar e responder a ameaças continuamente. Dependendo do serviço, isso pode incluir hunting proativo, contenção, remediação e análise de causa raiz.
Na prática, porém, cada ambiente possui tecnologias, riscos e restrições diferentes.
Por isso, a primeira definição é simples: o que está efetivamente coberto?
Endpoints? Identidades? Cloud? E-mail? SaaS? Servidores? Rede?
Uma operação não consegue investigar adequadamente aquilo que não consegue observar.
Defina quais ações podem ser executadas
Depois vem a resposta.
Se uma estação apresentar sinais claros de comprometimento, o fornecedor pode isolá-la?
Se uma identidade privilegiada estiver sendo abusada, existe procedimento para bloquear ou revogar o acesso?
Se um indicador malicioso aparecer em outros ativos, quais ações podem ser executadas sem nova autorização?
A resposta não será igual para todas as empresas.
Uma máquina de escritório e um servidor associado a uma operação crítica podem exigir níveis diferentes de autonomia.
O importante é que essa diferença seja conhecida antes do incidente.
Crie uma matriz de autorização
Uma abordagem prática é dividir as ações em categorias.
Algumas podem estar previamente autorizadas em determinadas condições. Outras podem exigir confirmação de um responsável da empresa. Ações com potencial de impacto elevado no negócio podem depender de uma decisão executiva ou operacional.
Também é necessário definir substitutos.
Se o responsável principal não atender durante a madrugada, quem assume?
Não é incomum que especialistas de MDR possam executar determinadas ações de remediação previamente acordadas com o SOC do cliente.
A tecnologia é apenas uma parte dessa equação. A outra é governança.
Não confunda primeiro atendimento com resposta concluída
Outro ponto importante está nas métricas.
Saber quanto tempo o fornecedor leva para reconhecer um alerta é útil. Mas vale acompanhar também quanto tempo é necessário para investigar o evento, determinar seu alcance e iniciar uma ação de contenção quando ela for necessária.
Esses tempos mostram lugares diferentes do processo.
Um SLA de atendimento pode estar sendo cumprido enquanto uma investigação permanece aberta aguardando informação, permissão ou outra equipe.
É justamente nesses intervalos que aparecem gargalos.
Determine onde termina a responsabilidade do fornecedor
Mesmo um MDR com ampla capacidade operacional não elimina a responsabilidade da organização sobre seu próprio risco.
Recuperação de sistemas, priorização do negócio, comunicação externa, questões legais e aceitação de determinados impactos continuarão exigindo participação interna.
Por isso, um bom modelo não tenta apagar a fronteira entre cliente e parceiro.
Ele torna essa fronteira clara.
Quando um incidente começa, todos deveriam saber quem monitora, quem investiga, quem contém, quem aprova exceções, quem recupera e quem leva a situação para as demais áreas da organização.
Essa clareza reduz handoffs desnecessários e permite que a capacidade técnica realmente se transforme em capacidade de resposta.
A Setrix apoia organizações na estruturação de operações de detecção e resposta conectadas às características do ambiente e aos riscos do negócio.
Fontes
Microsoft Security — What Is MDR? Managed Detection and Response
Microsoft Security — Microsoft Defender Experts MDR
NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile
Microsoft Security — What is SOCaaS? SOC as a Service




Comentários