Investigar o Directory e os Identity Details do Sophos ITDR

O Directory do Sophos ITDR é o inventário de trabalho para identidades, grupos, dispositivos e aplicações que o ITDR recolhe dos fornecedores de identidade ligados. Os cartões de métricas mostram o número de objetos monitorizados; um clique abre a vista correspondente. Para uma investigação, passa-se deste inventário global, através de um nome a apresentar, para os dados detalhados do objeto.

Atalho: em My Products > Identity > Directory, selecionar primeiro o separador correto, aplicar a pesquisa e os filtros e verificar a origem dos dados. Para um utilizador, abrir Display Name e, em seguida, verificar uma hipótese concreta em cada uma das áreas Summary, Activity Log, Findings, Insights, Group Membership e Dark Web Intelligence. Uma única etiqueta, um Risk Score elevado ou um início de sessão invulgar é um sinal para definição de prioridades, mas não constitui, por si só, prova de comprometimento.

Clarificar os limites do produto antes da investigação

O ITDR Directory não é o serviço de diretório do Sophos Fusion (anteriormente Sophos Central). Mostra o contexto de segurança recolhido pela integração ITDR ou pelo sensor ITDR. Em contrapartida, Global Settings > Platform > Directory service disponibiliza utilizadores e grupos para funções e produtos partilhados do Central. Daqui resultam três limites importantes:

• Uma identidade em falta no ITDR Directory não é corrigida através de uma nova sincronização do Central Directory. Primeiro, verificam-se a integração ITDR, o inventário do fornecedor e o respetivo estado de recolha.
• Um objeto no ITDR Directory não é automaticamente um utilizador gerido do Central e não implica qualquer atribuição de produto nem instalação do Endpoint.
• Os filtros, as etiquetas e a simples abertura de páginas de detalhes no ITDR não alteram objetos do Entra ID, do Active Directory, do Intune ou do diretório do Central. As correções técnicas são efetuadas no sistema de referência e depois validadas no ITDR; separadamente, poderão estar disponíveis ações de resposta expressamente autorizadas através das entradas Actions previstas para esse efeito.

O Sophos XDR também tem uma finalidade diferente. O ITDR Directory fornece contexto de inventário, postura e identidade. Em contrapartida, uma consulta XDR ou investigação XDR correlaciona telemetria e eventos de fontes de dados suportadas. Por isso, o Activity Log em Identity Details não é uma cronologia XDR completa e um finding do ITDR não é automaticamente uma detection do XDR. Para uma investigação de ameaças que abranja vários casos, os indícios confirmados do ITDR são correlacionados com os dados disponíveis do XDR, Endpoint, Entra e da rede, sem interpretar a ausência de telemetria como um resultado sem anomalias.

Interpretar corretamente o inventário do Directory

O ponto de entrada em My Products > Identity > Directory disponibiliza quatro separadores funcionalmente distintos:

Os campos de pesquisa restringem a respetiva vista por nome. A pesquisa e os filtros atuam apenas sobre os dados apresentados e recolhidos pelo ITDR. Por conseguinte, a ausência de resultados não prova nem a inexistência de um objeto no fornecedor nem a sua eliminação. Antes de uma escalada, verificam-se a grafia, o separador, os filtros ativos, o tenant do fornecedor e o momento da recolha.

Pesquisar, ordenar e filtrar identidades

Identities pode ser apresentado em vista de cartões ou de lista. Por predefinição, os utilizadores são ordenados alfabeticamente. No menu de ordenação, é possível selecionar, por exemplo, Risk Score por ordem decrescente para encontrar as identidades que devem ser investigadas primeiro. Search Identities filtra por nome.

Os filtros adequados dependem da investigação. Para uma primeira definição de prioridades, Status restringe o estado da conta comunicado pelo fornecedor de identidade e Risk Severity restringe o intervalo do Risk Score calculado. Is Admin representa o contexto de administrador definido pelo fornecedor ou com base nas funções privilegiadas detetadas, Is VIP representa a seleção para VIP Monitoring e Is Compromised representa a existência de fugas ativas de credenciais. Is Dormant encontra contas para as quais não foi registado qualquer início de sessão há mais de 90 dias.

Para enquadrar a conta, Department e Employee Type estão disponíveis como atributos organizacionais, desde que sejam fornecidos pelo fornecedor. Is Guest identifica uma conta de convidado no fornecedor de identidade; Is Cloud Only, uma conta existente apenas no fornecedor de identidade na cloud, sem identificadores locais. O contexto de MFA é fornecido por Has MFA, Has Passwordless MFA, Primary MFA Method e MFA Method. Country e Region filtram pelos atributos de localização mantidos no fornecedor.

Um valor de filtro vazio não constitui um resultado negativo. Se o fornecedor não fornecer um atributo, se a licença limitar o acesso à API ou se a Microsoft ainda não tiver disponibilizado dados atualizados, o ITDR não poderá preencher o campo de forma fiável. Isto aplica-se em particular aos dados de MFA, administrador, dispositivos e atividade.

Na vista de cartões, a seta no final do cartão apresenta informações adicionais; apenas um cartão de cada vez pode estar expandido. Na vista de lista, a seta à esquerda expande uma linha. O menu de colunas permite afixar colunas, dimensioná-las automaticamente, repô-las, adicioná-las ou removê-las. Estas definições de apresentação não alteram o objeto nem a respetiva avaliação.

Se as ações de resposta tiverem sido previamente autorizadas, ficam disponíveis para um utilizador através de Actions no cartão expandido ou da coluna Actions na vista de lista. A disponibilidade de uma entrada ou ação depende do estado da identidade e da configuração; a execução também requer as permissões de operador necessárias e o processo interno de aprovação. Os filtros, as etiquetas e a abertura de detalhes continuam a ser funções distintas que não efetuam alterações. Após a execução de uma ação, verifica-se o resultado no fornecedor de referência e, em seguida, o estado atualizado no ITDR.

Utilizar ícones e etiquetas como contexto, não como veredicto

Os ícones identificam User, MFA User, Deleted User, Locked User, Admin, Guest ou Service. As etiquetas adicionais descrevem propriedades diferentes e não devem ser interpretadas como uma avaliação de risco conjunta: Admin significa que a conta foi identificada como administrador, Guest designa um convidado no tenant, Deleted User designa um utilizador eliminado no fornecedor e Locked User, uma conta desativada.

MFA User significa que a MFA está ativada, Compromised indica uma fuga ativa de credenciais e Dormant Account identifica uma identidade sem inícios de sessão registados nos últimos 90 dias. Cloud Only significa que não existem identificadores locais; com Hybrid, existem identificadores locais e estes estão sincronizados entre a cloud e o ambiente local. Human classifica a identidade como um utilizador humano, enquanto VIP identifica a configuração para VIP Monitoring.

Human e Non-Human Identity (NHI) não devem ser confundidos. Uma conta humana representa uma pessoa. As NHI incluem, em particular, Service Principals, aplicações e outras identidades de máquina. Um ícone Service fornece o contexto correspondente na vista de identidades; as Enterprise Applications locais do tenant são investigadas no separador Apps. O facto de um nome a apresentar parecer o de uma pessoa ou de um serviço não constitui uma classificação fiável.

Distinguir Application Object de Service Principal

Um Application Object do Microsoft Entra é a definição global de uma aplicação registada no respetivo tenant de origem. Descreve, entre outros elementos, a configuração de identidade da aplicação e possui uma App ID, ou Client ID. No caso de um Service Principal do tipo Application, o Service Principal é a instância local concreta dessa aplicação num determinado tenant. Este tipo referencia o Application Object e determina, no tenant em questão, o que a aplicação pode fazer, quem lhe pode aceder e a que recursos pode aceder. Esta associação não se aplica a todos os tipos de Service Principal: um Service Principal do tipo Managed identity não tem um Application Object associado; um Service Principal Legacy não tem um registo de aplicação associado.

O separador Apps mostra as Enterprise Applications obtidas pelo ITDR no tenant Entra monitorizado, ou seja, instâncias locais do tenant relacionadas com aplicações, e não simplesmente uma segunda lista de registos globais de aplicações. Daqui não se pode concluir que todos os tipos de Service Principal do Entra sejam aí apresentados, nem que todos os contextos NHI apresentados tenham um registo de aplicação. Uma aplicação multitenant pode ter um Application Object no tenant de origem, mas um Service Principal próprio do tipo Application em cada um de vários tenants consumidores. Por isso, é necessário comparar em conjunto Display Name, tenant, App/Client ID, Object ID, proprietário e permissões. Nomes iguais não significam que se trate do mesmo objeto; Service Principals locais distintos deste tipo podem referenciar a mesma aplicação global.

Através de Display Name, abre-se App Details. Aí verificam-se os metadados obtidos pelo ITDR, bem como as tabelas relativas aos proprietários da aplicação, findings associados e permissões. Uma permissão invulgar é validada no fornecedor face à finalidade empresarial prevista, ao publisher, ao consentimento e ao proprietário responsável. A apresentação no Directory não revoga qualquer consentimento nem remove qualquer permissão.

Investigar grupos e dispositivos

Em Groups, a pesquisa pode ser restringida com quatro filtros: Deleted representa grupos eliminados no fornecedor, Mail Enabled representa grupos que podem receber e-mail e Security Enabled representa grupos que podem controlar o acesso a recursos. Assignable to Roles identifica grupos aos quais podem ser atribuídas funções.

Um clique em Group Name abre Group Details, com os metadados do grupo obtidos e tabelas dos utilizadores, grupos e aplicações associados. Numa revisão de acessos, confirmam-se no fornecedor de referência o tipo de grupo, o proprietário, as relações diretas e aninhadas, bem como a necessidade operacional. Mail Enabled nada indica sobre a utilização de um grupo para permissões; para esse efeito, Security Enabled é o atributo relevante.

Em Devices, é possível pesquisar dispositivos e filtrar por State, Ownership, Operating System, Architecture, Manufacturer, Model, Rooted, Managed e Compliant. A vista inclui dispositivos pessoais e empresariais registados no Microsoft Entra ID. Um objeto de dispositivo é uma identidade no fornecedor; Microsoft Entra registered, Microsoft Entra joined e Microsoft Entra hybrid joined são contextos distintos de registo ou associação e não significam que esteja instalado um Sophos Endpoint Agent.

Através de Display Name, abre-se Device Details. Consoante o tipo de dispositivo, a página mostra metadados obtidos, identidades associadas, findings relevantes e outras informações disponíveis. Managed, Compliant, Rooted ou Ownership são dados do fornecedor. Se estiverem em falta, o valor é documentado para a investigação como indisponível ou desconhecido. Não se pode inferir daí os estados «unmanaged», «non-compliant» ou «not rooted», nem uma propriedade pessoal ou empresarial. Além disso, um valor em falta não equivale a um valor Unknown comunicado expressamente pelo fornecedor.

Investigar sistematicamente Identity Details

Em Identities, um clique em Display Name abre a página Identity Details. Em vez de consultar todos os separadores sem uma hipótese, recomenda-se o seguinte procedimento:

1. Confirmar o objeto: comparar o nome a apresentar, estado, tipo, endereços de e-mail e contexto do fornecedor com o utilizador esperado.
2. Compreender a prioridade: verificar o Risk Score, os fatores contribuintes, findings em aberto, Compromised, Admin e o contexto de MFA e inatividade. Uma pontuação estabelece a prioridade da investigação, mas não a substitui.
3. Validar a plausibilidade do perfil e de Assets: comparar a função, o departamento, a região, a estrutura organizacional e os dispositivos Intune associados com o perfil esperado.
4. Investigar a atividade: definir o período e verificar inícios de sessão bem-sucedidos e falhados, horas, países, endereços IP e ASN quanto a desvios.
5. Abrir as evidências associadas: investigar individualmente Findings, Detections, grupos e registos da dark web, em vez de inferir a causa a partir de um resumo.
6. Validar no sistema de referência: efetuar a verificação cruzada no Entra ID, AD local, Intune e, se aplicável, na telemetria XDR. Em seguida, efetuar as alterações técnicas no respetivo sistema de referência. Se, em alternativa, estiver prevista uma resposta ITDR expressamente aprovada, utilizar para o efeito uma entrada Actions disponível.
7. Acompanhar o resultado: após a correção ou resposta, voltar a verificar o resultado no fornecedor e no ITDR e documentar que apresentação já foi atualizada e qual ainda aguarda o ciclo de recolha seguinte.

Summary

Summary combina o perfil, a prioridade e a atividade recente. Em Details, encontram-se os dados disponíveis do Entra ID, como função, departamento, estado, país e região, data e hora de criação e alteração, última alteração da palavra-passe e outros endereços de e-mail associados. Assets mostra os dispositivos Intune atribuídos ao utilizador no Entra ID. Multi-Factor Authentication indica o fornecedor de MFA, o método de MFA principal e outros tipos de MFA configurados. O contexto organizacional é fornecido por Organization, com superiores hierárquicos, subordinados diretos e estrutura organizacional; um clique numa pessoa abre-a num novo separador.

Para a avaliação de segurança, Recent Detections mostra as Open Detections dos últimos sete dias e as Closed Detections dos últimos 30 dias; View All abre Insights. Risk Score contém a pontuação atual e os principais fatores contribuintes. Top Sign-in Locations resume os locais de início de sessão mais frequentes, com atividade de IP público e privado. Quando existem dados, Commonly Used Entities agrupa as autenticações bem-sucedidas dos últimos 30 dias por IP Addresses, Browser, Asset Name e OS Version.

Em Top Sign-in Locations > View Details, são apresentados, para os últimos 30 dias, sobretudo a localização geográfica, o ASN e a frequência dos principais endereços IP. IP type e Login outcome servem de filtros; não se pressupõe que sejam obrigatoriamente apresentados como colunas de resultados. Os endereços IP privados não devem ser interpretados geograficamente como os endereços públicos. Uma cidade frequente pode resultar de uma VPN ou de um ponto de saída da cloud; um país desconhecido pode justificar uma verificação, mas, sem contexto de hora, dispositivo e fornecedor, ainda não constitui um incidente.

Activity Log

Activity Log mostra a atividade de autenticação durante o período selecionado no canto superior direito. Total Activities, Successful Logins e Failed Logins fornecem primeiro o volume. Para o enquadramento geográfico, Top sign-in locations mostra países, endereços IP, quantidade e distribuição por IP público ou privado. Authentication locations acrescenta as autenticações mais frequentes dos últimos 30 dias por endereço IP e ASN, bem como uma pesquisa por localização, IP ou ASN. A evolução temporal é apresentada por Logins per day, com separação entre inícios de sessão bem-sucedidos e falhados, e por Activity map, como mapa térmico por dia da semana e hora do dia.

Esta vista do ITDR resume agregados e padrões. Não mostra uma tabela de eventos na qual todos estes dados estejam lado a lado para cada início de sessão. Em vez disso, Browser, Asset Name e OS Version devem ser avaliados como agregados de perfil de 30 dias relativos a autenticações bem-sucedidas em Summary > Commonly Used Entities e não podem ser atribuídos a uma entrada individual no Activity Log. Para correlacionar eventos com hora e fuso horário exatos, resultado, IP de origem, ASN, país, dispositivo, browser, sistema operativo ou detections adjacentes, consultam-se os registos de eventos disponíveis no Entra ou no XDR. Tentativas falhadas frequentes nos agregados do ITDR podem representar erros do utilizador, credenciais desatualizadas ou um ataque; só a correlação com evidências de eventos permite determinar a causa.

Findings, Insights, Group Membership e Dark Web Intelligence

Findings apresenta os findings desta identidade por risco. O texto completo em Recommendation aparece ao passar o cursor por cima; um clique no nome do finding abre os detalhes. Verificam-se então o estado, o risco, a categoria, as evidências afetadas e a correção recomendada. Alterar manualmente um estado não é o mesmo que efetuar a correção técnica no fornecedor.

Insights mostra, por predefinição, as Open Detections dos últimos sete dias; o período pode ser alterado através do Date Picker. Closed Detections abrange os últimos 30 dias. Por conseguinte, um período predefinido vazio não exclui atividade anterior.

Group Membership apresenta os grupos do utilizador. O campo de pesquisa restringe a lista; um clique em Group Name abre o grupo e os respetivos membros adicionais. São particularmente relevantes associações inesperadas que sejam privilegiadas, atribuíveis a funções, aninhadas ou que já não sejam necessárias para a atividade. As alterações são efetuadas no fornecedor de referência.

Dark Web Intelligence mostra registos de fugas associados à identidade. Através de Breach Source, abre-se o respetivo registo. Um registo documenta a exposição de credenciais. Para o enquadramento, é necessário verificar em conjunto o momento da fuga, o contexto da publicação ou violação, o estado da conta e a última alteração da palavra-passe. O registo não prova automaticamente que as credenciais atualmente utilizadas sejam válidas nem que tenha ocorrido um início de sessão.

Considerar os limites dos fornecedores e os tempos de atualização

O Sophos ITDR suporta Microsoft Entra ID e Active Directory local, mas nem todos os fornecedores disponibilizam os mesmos objetos e campos. Dados específicos da cloud, como ativos do Intune, Service Principals do Entra, métodos de MFA ou atividade de início de sessão no Entra, podem estar ausentes numa integração exclusivamente com o AD local. Por outro lado, o sensor ITDR local recolhe tipos de objetos AD adicionais para verificações de postura; isto não torna automaticamente completos os separadores da cloud.

Após a recolha inicial completa do Entra, o ITDR verifica atualizações em intervalos diferentes consoante o tipo de dados: detalhes de utilizadores, Service Principals, aplicações, grupos e dispositivos aproximadamente a cada dez minutos, configuração de MFA aproximadamente a cada 15 minutos, último início de sessão do utilizador aproximadamente a cada seis horas e dados do domínio aproximadamente a cada 24 horas. Estes são intervalos de recolha e não garantem que a Microsoft já disponibilize através da API uma informação de origem alterada.

É necessário o Entra ID P1 ou P2 para o âmbito de dados previsto do ITDR. Com o Entra ID Free, as API e as verificações de postura são limitadas; por conseguinte, uma integração pode apresentar Provisioning Failed. Após uma atualização de licença, os dados de administrador ou MFA na Microsoft podem permanecer desatualizados durante até uma semana. Neste caso, verifica-se primeiro o relatório de atividade correspondente do Microsoft Entra. Se a própria apresentação do fornecedor ainda não estiver atualizada, o ITDR não poderá mostrar um estado mais recente.

A MFA de terceiros numa configuração antiga do Okta ou Duo também pode aparecer como não protegida, porque o Entra não guarda a informação de MFA ao nível do utilizador. Nesse caso, uma indicação Has MFA = false não pode ser tratada isoladamente como prova de ausência de controlo MFA. A configuração do fornecedor, o Conditional Access, os External Authentication Methods atuais e um teste de início de sessão controlado têm de ser coerentes entre si.

Validação e resolução de problemas

O objeto está em falta ou aparece no separador errado

1. Repor a pesquisa e os filtros ativos e verificar a grafia, bem como nomes a apresentar alternativos.
2. Verificar se Identities, Groups, Devices ou Apps corresponde ao tipo de objeto correto.
3. Confirmar o tenant e o fornecedor de identidade de referência; no caso de aplicações, distinguir Application Object, Service Principal, App/Client ID e Object ID.
4. Pesquisar o objeto diretamente no fornecedor e verificar o estado, eliminação e contexto de convidado, cloud, híbrido ou serviço.
5. Nas definições da integração ITDR, verificar o estado e a última recolha bem-sucedida. Não reiniciar o Central Directory Sync como substituição.
6. Voltar a verificar apenas depois do intervalo de recolha específico do tipo de dados e documentar os momentos relevantes.

O filtro ou o campo de MFA, administrador ou dispositivo está vazio ou é inesperado

• Remover os filtros e verificar o atributo em bruto no fornecedor.
• Verificar a licença Entra, a disponibilidade da API e o estado da integração.
• Para MFA, verificar também o fornecedor, o método principal e os restantes métodos, bem como a configuração de terceiros.
• Para dispositivos, distinguir entre registo ou associação, gestão pelo Intune, conformidade e proteção do Sophos Endpoint.
• Após alterações de licença ou atributos, validar primeiro a apresentação atualizada do fornecedor, e não apenas o ITDR.
• Documentar «vazio», No data ou uma etiqueta em falta como desconhecido, e não como «não».

O local de início de sessão ou o padrão de atividade parece suspeito

No Activity Log, comparar primeiro o período, bem como o volume de inícios de sessão, os agregados de êxitos e falhas, os países, os endereços IP, o ASN e os padrões de dia/hora. Em Top Sign-in Locations, é possível utilizar IP type e Login outcome como filtros.

Enquadrar separadamente Browser, Asset Name e OS Version em Commonly Used Entities como agregados de 30 dias. Em seguida, correlacionar a hora e o fuso horário exatos do evento, bem como o resultado, dispositivo, browser e sistema operativo de um início de sessão individual, nos registos de eventos disponíveis no Entra ou no XDR. Verificar também os Findings e Insights associados.

NAT, VPN, redes móveis, pontos de saída da cloud e viagens podem alterar a localização apresentada. Quando o risco for confirmado, executar passos de resposta apenas de acordo com o processo interno de incidentes e com as permissões necessárias.

Verificar a apresentação após uma correção

Confirmar primeiro a alteração técnica no sistema de referência. Depois, aguardar o momento de recolha esperado do ITDR, repor os filtros e voltar a abrir a mesma identidade ou o mesmo objeto. Verificam-se o campo corrigido, as etiquetas dependentes, os findings associados e o período de investigação relevante. O Risk Score, os findings e os atributos do fornecedor podem ter ciclos de atualização diferentes; uma pontuação que ainda não tenha mudado não invalida uma alteração bem-sucedida na origem. Se a apresentação continuar incorreta para além do intervalo esperado, guardam-se a evidência do fornecedor, o tenant, o ID do objeto, o momento da alteração, o estado da integração e capturas de ecrã para a escalada.

Concluir a investigação de forma rastreável

No final, documentar o objeto, o tenant, o fornecedor e o tipo de identidade. Registar também a pesquisa e os filtros utilizados, o período da investigação, as áreas de detalhe verificadas, os dados do fornecedor em falta e os resultados da validação no sistema de referência e no ITDR. O contexto Human e NHI, bem como Application Object e Service Principal, permanecem separados.