Investigar e corrigir riscos no Sophos ITDR Dark Web Intelligence

Dark Web Intelligence mostra os registos de fugas de dados que a Sophos recolheu para os domínios configurados. O objetivo deste guia operacional não é tratar cada ocorrência como acesso atual à conta. Primeiro, verificam-se a identidade, a referência temporal, o tipo de palavra-passe e o estado da fuga de dados. Em seguida, deve responder-se apenas através de um processo aprovado para a identidade que está efetivamente associada.

Os Credential Leaks com o estado Active aumentam o Risk Score de uma identidade. No entanto, os registos históricos continuam visíveis mesmo quando estão inativos. Por conseguinte, a tabela serve tanto de vista operacional dos riscos atuais como de prova de descobertas anteriores.

Fluxo rápido

1. Abra My Products > Identity > Dark Web Intelligence e documente os filtros predefinidos.
2. Dê prioridade a um registo ativo e registe Source, identidade associada, tipo de palavra-passe e Publish Date, Leaked Date e Breach Date.
3. Verifique por que motivo o registo está Active; não considere cada linha uma conta ou palavra-passe única.
4. Para um Finding associado, compare a gravidade apresentada com a matriz, utilizando o tipo de conta, o tipo de palavra-passe e a robustez da MFA.
5. Confirme a responsabilidade e a aprovação. Só então execute a resposta apropriada, já autorizada.
6. Corrija as credenciais no Identity Provider responsável através do processo aprovado. Não utilize o Finding nem o estado da fuga de dados como substituto dessa correção.
7. Após pelo menos um ciclo de 15 minutos, volte a examinar o estado, o Finding e o Risk Score e documente as provas.

Vistas e filtros predefinidos

Entrada direta

My Products > Identity > Dark Web Intelligence

Ao abrir esta página diretamente, a tabela é filtrada pelo estado da fuga de dados Active e pelo estado da identidade Active. Antes de examinar os dados, guarde uma captura de ecrã ou anote os filtros ativos. Uma vista predefinida vazia não prova que não existem dados históricos de fugas de dados; para esta verificação, alargue deliberadamente os filtros de estado.

Acesso pelo Identity Overview

Identity Overview > Credential Leaks

Clicar numa métrica no widget Credential Leaks abre Dark Web Intelligence com uma secção correspondente à métrica:

Breached Email Accounts e Unique Passwords Breached são as métricas agregadas dos dados subjacentes. Não existe qualquer filtro adicional da tabela que reproduza por completo o respetivo método de contagem única. Por conseguinte, não é possível reconstruir exatamente a métrica a partir das linhas da tabela visíveis após o clique.

Interpretar métricas corretamente

As métricas apresentadas na parte superior de Dark Web Intelligence referem-se a fugas de dados ativas:

Estes valores utilizam unidades diferentes: fontes, registos de fugas de dados, contas e palavras-passe únicas. Não podem ser somados nem validados através da simples contagem das linhas da tabela.

Investigar um registo de fuga de dados

1. Definir o escopo

Primeiro, observe os filtros e a ordenação. Para a primeira triagem, pelo menos essas características são relevantes:

• Estado da fuga de dados Active ou Inactive
• Estado da identidade e identidade associada
• Plaintext ou Hashed
• Contexto de administrador, não administrador ou VIP, se indicado
• Source
• Publish Date, Leaked Date e Breach Date
• Finding associado, caso exista

Não dê prioridade apenas à data/hora mais recente da tabela. Um registo com uma nova Publish Date pode conter conteúdo mais antigo, especialmente no caso de listas combinadas.

2. Abrir detalhes

Clique no campo Source. O painel de detalhes mostra informações adicionais sobre a fuga de dados e, se disponível, a identidade associada. Antes de responder, a linha da tabela e o painel de detalhes devem referir-se à mesma fonte e identidade.

Se não for atribuída qualquer identidade, o registo continua a ser relevante para a investigação histórica, mas é considerado inativo. Neste caso, Actions está desativado. Não atribua uma identidade com base numa suposição nem intervenha numa conta com um nome semelhante.

3. Distinguir os campos de data

Publish Date

O momento em que a Sophos encontrou pela primeira vez o registo de fuga de dados nos dados que analisou. Não corresponde ao momento em que os dados ficaram disponíveis publicamente nem, necessariamente, ao momento do incidente.

Leaked Date

A data em que o conjunto de dados se tornou publicamente disponível. Esta data é comparada com a última alteração de palavra-passe para avaliar se o risco das credenciais é atual.

Breach Date

O momento em que a violação subjacente ocorreu. Ele fornece contexto do incidente, mas pode não estar disponível.

A ausência de Breach Date não torna Leaked Date a hora confirmada da violação. Do mesmo modo, uma nova Publish Date não prova que a palavra-passe tenha sido comprometida recentemente. Para a lógica do estado, é essencial saber se a última alteração de palavra-passe ocorreu antes ou depois da primeira fuga de dados relevante.

4. Avaliar duplicados e combolists

A mesma pessoa pode aparecer em várias linhas dentro de uma fonte. As razões comuns incluem:

• a pessoa aparece várias vezes no conjunto de dados original;
• o mesmo conteúdo foi reconhecido numa fonte genérica, como uma combolist;
• dados de fugas mais antigas voltam a ficar visíveis numa coleção encontrada posteriormente.

Por conseguinte, várias linhas não indicam automaticamente várias contas comprometidas nem vários comprometimentos atuais de palavras-passe. Compare a fonte, a data, o tipo de palavra-passe e a identidade associada em cada linha. As métricas Emails e Unique Passwords aplicam uma lógica de eliminação de duplicados; as linhas da tabela não são tratadas da mesma forma.

Quando uma fuga de dados é Active ou Inactive

Uma fuga de dados é Active se ambas as condições forem cumpridas:

1. O registo pode ser associado a uma identidade ativa num Identity Provider configurado.
2. A última alteração da palavra-passe da conta associada ocorreu antes da primeira fuga de dados.

Por conseguinte, Active indica um risco de credenciais que continua a ser relevante. O estado, por si só, não prova um início de sessão bem-sucedido por terceiros nem um ataque em curso.

Uma fuga de dados é Inactive se pelo menos um dos cenários documentados for aplicável:

• Não há identidade correspondente nos Identity Providers configurados.
• A alteração de palavra-passe mais recente ocorreu depois do momento da fuga de dados.
• A palavra-passe da conta foi alterada recentemente.
• A conta foi desativada ou eliminada.
• Um Finding relacionado recebeu o estado Resolved ou Dismissed.

Os dados históricos sobre os domínios monitorizados são recolhidos e conservados. Por conseguinte, um conjunto de dados inativo não é incorreto nem irrelevante apenas devido à sua antiguidade. Pode explicar por que motivo a mesma pessoa ou fonte aparece várias vezes.

Quando um Finding é criado

A Sophos descreve o seguinte processamento para Findings de comprometimento de conta:

1. Sophos verifica se existe uma identidade ativa nos Identity Providers configurados.
2. A Sophos determina, a partir dos dados históricos disponíveis, quando o valor em texto simples ou o hash foi exposto pela primeira vez. Isto destina-se a reconhecer conteúdo antigo em novas listas combinadas.
3. Com um valor em texto simples, a Sophos compara o valor com os requisitos globais de complexidade de palavra-passe do Microsoft Entra ID para filtrar valores inválidos.
4. A Sophos compara o momento da primeira exposição da palavra-passe com a última alteração da palavra-passe. Se a primeira exposição for posterior a essa alteração, a Sophos cria um Finding.

Os Findings são criados apenas para identidades ativas. Os dados em bruto permanecem visíveis em Dark Web Intelligence, mesmo que nenhuma identidade ativa esteja associada.

Matriz de gravidade para comprometimento de conta

Segundo a Sophos, a gravidade do Finding depende do tipo de conta, do tipo de palavra-passe e da força da MFA:

A matriz ajuda a definir prioridades, mas não substitui uma avaliação de cada caso. Sobretudo nas contas administrativas, é necessário confirmar a associação efetiva da conta antes de intervir. Um nível de gravidade inferior não significa que a correção seja desnecessária.

Gerir valores de palavras-passe

A Sophos afirma que não armazena palavras-passe em texto simples nem valores de hash e que também não pode recolher esses valores dos Identity Providers. Durante a recolha, a Sophos aplica o seu próprio hash aos valores observados e, em seguida, classifica o conjunto de dados como Plaintext ou Hashed. Segundo a Sophos, este método permite determinar valores únicos e indicadores derivados sem armazenar o valor subjacente da palavra-passe.

Em termos operacionais, isto significa:

• Plaintext descreve o tipo de conteúdo exposto observado, não uma palavra-passe disponível no Sophos Fusion (anteriormente Sophos Central).
• Não tente recuperar o valor original a partir do Sophos Fusion, de capturas de ecrã ou de exportações.
• Não copie palavras-passe suspeitas, valores de hash ou novas credenciais em tickets, notas ou mensagens de chat.
• Defina uma nova palavra-passe exclusivamente através do processo aprovado do Identity Provider e trate-a no sistema de palavras-passe pretendido.

Resposta e correção autorizadas

Decida antes de tomar qualquer ação

Antes de Actions, todos os seguintes pontos devem ser cumpridos:

• A identidade associada está claramente confirmada pelo painel de detalhes.
• O titular da conta, o tipo de conta e a função comercial são conhecidos.
• O estado atual da fuga de dados, o tipo de palavra-passe e os três campos de data foram verificados.
• Os Response Actions estão autorizados para o tenant.
• A pessoa que executa a ação está autorizada para a identidade específica e o impacto esperado.
• O gestor do serviço ou sistema responsável participa no processo relativo a contas privilegiadas ou partilhadas.

Se faltar uma destas condições, não é executada qualquer ação. O registo é encaminhado para a pessoa responsável na equipa de Identidade ou Segurança, juntamente com a data/hora, o estado do filtro e os detalhes da aprovação em falta.

Responda em Dark Web Intelligence

Se os Response Actions estiverem autorizados, estarão disponíveis para as identidades associadas na tabela ou nos detalhes da fuga de dados:

1. Abra a linha correta ou o painel de detalhes da identidade confirmada.
2. Selecione Actions.
3. Selecione apenas a Response Action já aprovada.
4. Reveja e siga todas as instruções e confirmações apresentadas no ecrã.
5. Documente a ação, o responsável, a hora, a identidade de destino e o resultado visível, mas não registe credenciais.

Utilize apenas os Response Actions disponíveis no tenant e autorizados pela organização. Se não existir uma identidade adequada, Actions permanecerá desativado; esta restrição não deve ser contornada.

Corrigir o risco das credenciais

A correção técnica é efetuada através do Identity Provider responsável pela conta e do processo de credenciais aprovado:

1. Verifique a última alteração de palavra-passe e o estado da conta da identidade confirmada em relação ao momento da fuga de dados.
2. Se não for possível excluir a possibilidade de os dados de acesso observados na fuga ainda serem válidos, inicie ou efetue uma alteração de palavra-passe autorizada especificamente para esta conta.
3. Se uma conta estiver desativada ou eliminada, confirme o estado no Identity Provider em vez de reativar a conta para a correção.
4. Se o registo não estiver associado a uma identidade, trate-o como uma fuga de dados histórica e inativa e não tente adivinhar a identidade da conta.
5. Trate um Finding associado através do processo previsto apenas depois de documentar a correção efetiva das credenciais. Utilize Dismissed apenas após uma decisão tecnicamente fundamentada e documentada, não para reduzir a fila.

Não deduza do registo de fuga de dados a necessidade de alterações adicionais na conta, na sessão, na MFA ou no diretório. Estas medidas exigem um motivo confirmado separadamente e a aprovação aplicável.

Cadência de 15 minutos e validação

A Sophos verifica Dark Web Intelligence a cada 15 minutos. A Sophos monitoriza e recolhe continuamente os resultados de fugas de dados; se for detetada uma fuga de dados ativa, é geralmente gerado um Finding no prazo de 15 minutos. «Geralmente» não representa um prazo máximo garantido.

Após a correção, não registe imediatamente um sucesso definitivo. Em vez disso:

1. Registe a hora de conclusão da alteração de palavra-passe ou da alteração confirmada à conta, incluindo o fuso horário.
2. Aguarde pelo menos um ciclo completo de 15 minutos. Considere que a ingestão de dados atualizados do Identity Provider pela Sophos pode exigir tempo adicional.
3. Reabra My Products > Identity > Dark Web Intelligence.
4. Procure pela mesma identidade e fonte com os mesmos filtros.
5. Verifique se a fuga de dados mudou de Active para Inactive e se o estado da identidade apresentado está correto.
6. Verifique separadamente o Finding associado. A ausência de um novo Finding não constitui prova suficiente se a fuga de dados ainda estiver Active.
7. Monitorize o Risk Score da identidade como sinal de acompanhamento. Não constitui a prova principal da alteração da palavra-passe.
8. Documente o valor inicial, a ação, a hora de conclusão, a hora de validação e o estado final.

Critérios de aceitação

O processamento só é concluído quando:

• a identidade e a fonte da fuga de dados estão claramente documentadas;
• os campos de tipo de palavra-passe e data foram avaliados;
• a correção das credenciais foi confirmada no Identity Provider responsável ou a conta está comprovadamente desativada ou eliminada;
• o registo de fuga de dados corrigido já não está Active após o processamento;
• o Finding associado foi tratado através de um processo controlado;
• nenhum valor secreto está na documentação.

Se o registo permanecer Active após vários ciclos de 15 minutos, volte primeiro a verificar a última alteração de palavra-passe, o estado da conta e a identidade associada. Se estas informações estiverem corretas e ainda não for possível explicar o estado, registe o estado do filtro, a origem, os três campos de data, a referência da identidade, a referência do Finding e a data/hora. Em seguida, encaminhe o caso para o Suporte da Sophos. Não efetue mais alterações à conta com base em suposições.

Registo de triagem

Tenant / ambiente:
Hora de validação com fuso horário:
Caminho e filtros ativos:
Source:
Identidade associada:
Estado da identidade:
Tipo de conta: Admin / Não-Admin / incerto
Monitorização VIP: sim / não / não claro
Tipo de palavra-passe: Plaintext / Hashed
Estado da fuga de dados antes da ação:
Publish Date:
Leaked Date:
Breach Date: Valor / não disponível
Contexto de várias linhas ou lista combinada:
Referência e gravidade Finding:
Última alteração de palavra-passe de acordo com Identity Provider:
Aprovação de resposta:
Ação autorizada realizada:
Hora de conclusão com fuso horário:
Validação após ciclo de 15 minutos:
Estado da fuga de dados após a medida:
Estado do Finding após a ação:
Risk Score como um sinal de acompanhamento:
Desvio / escalonamento aberto:

Evite erros comuns

• Contar cada linha da tabela como uma conta separada: Duplicatas e combolists podem criar várias linhas para a mesma pessoa.
• Publish Date lido como Breach Date: Os três campos de data descrevem eventos diferentes; Breach Date pode estar ausente.
• Interpretar Inactive como eliminado: Os dados históricos permanecem intactos e podem continuar visíveis.
• Tratar uma vista predefinida vazia como sinal verde: Por predefinição, a entrada direta mostra apenas fugas de dados ativas de identidades ativas.
• Fechar manualmente um Finding em vez de corrigir o risco: Uma alteração de estado não modifica quaisquer dados de acesso no Identity Provider.
• Forçar Actions sem uma identidade associada: Sem uma identidade correspondente, o botão está intencionalmente desativado.
• Confundir Plaintext com uma palavra-passe recuperável: A Sophos afirma que não são armazenados valores em texto simples nem valores de hash.
• Esperar uma atualização imediata: A verificação é executada num ciclo de 15 minutos; os dados de identidade de origem podem exigir tempo adicional de processamento.