No artigo anterior, discutimos por que um Human Risk Score construído exclusivamente com dados de treinamento, quizzes e simulações de phishing possui uma visão limitada do risco. Essas informações são importantes para entender aprendizado e determinados comportamentos, mas não conseguem responder sozinhas quem é aquela pessoa dentro da organização, quais acessos possui, a quais ameaças está exposta e qual seria o impacto de um eventual comprometimento.
Quando começamos a adicionar dados de IAM, IGA, DLP, EDR, XDR, CASB, SSE, SIEM e outras fontes, surge um novo problema técnico. Já não estamos discutindo apenas quais dados precisamos, mas como transformar informações produzidas por tecnologias completamente diferentes em uma visão coerente de risco humano.
É nesse ponto que Human Risk Observability deixa de ser apenas um conceito e começa a se tornar um problema de arquitetura.
O desafio não está em criar um grande repositório para armazenar todos os eventos relacionados aos colaboradores. Organizações já possuem SIEM, data lakes e outras tecnologias capazes de fazer isso. Uma arquitetura de Human Risk Observability precisa resolver outro problema: identificar sinais relevantes para risco humano, associá-los corretamente às identidades, adicionar contexto, compreender relações temporais e transformar essa telemetria em informação que possa orientar uma decisão.
Uma arquitetura tradicional de segurança recebe eventos de endpoints, aplicações, redes, serviços cloud e diversas outras fontes. Para Human Risk Observability, precisamos mudar um pouco o ponto de vista. O elemento central deixa de ser o dispositivo ou o evento e passa a ser a identidade.
Isso parece simples até começarmos a observar como uma mesma pessoa aparece dentro do ambiente corporativo. Em um sistema ela pode ser identificada pelo endereço de e-mail. Em outro, pelo UPN. No Active Directory, pode existir um identificador diferente. No sistema de RH, encontramos matrícula ou outro identificador interno. Essa pessoa também pode possuir uma conta administrativa separada, utilizar diferentes dispositivos e ter identidades específicas para determinadas aplicações.
Se tratarmos cada uma dessas representações como usuários independentes, teremos uma visão fragmentada. O comportamento registrado na conta administrativa pode não ser relacionado aos treinamentos realizados pela conta principal. Um alerta de DLP pode ficar separado de um evento de identidade que pertence à mesma pessoa. Antes de pensar em score, portanto, precisamos resolver o problema de identidade.
Uma arquitetura de Human Risk Observability precisa manter uma entidade central capaz de representar a pessoa e relacionar suas diferentes identidades digitais, contas, dispositivos, atributos organizacionais e sinais de segurança. Essa camada de resolução de identidade é o que permite transformar eventos dispersos em uma visão consistente.
Depois de resolver identidade, precisamos buscar sinais. É aqui que entram os conectores com o ecossistema de segurança e tecnologia da organização. Uma plataforma de awareness fornece treinamento, phishing, avaliações e reporte. IAM e IGA acrescentam autenticação, grupos, acessos e privilégios. DLP adiciona sinais relacionados à manipulação de informações. CASB e SSE trazem contexto sobre aplicações cloud, Shadow IT e Shadow AI. EDR e XDR fornecem informações relacionadas aos endpoints, enquanto o SIEM pode funcionar como uma fonte adicional de eventos já coletados ou correlacionados.
O erro seria concluir que uma plataforma com cinquenta conectores possui automaticamente melhor observabilidade do que uma plataforma com dez. O número de integrações diz pouco sobre a qualidade da informação produzida. Um conector que simplesmente importa centenas de tipos de alertas pode gerar mais ruído do que contexto.
Cada integração deveria existir porque responde a uma pergunta relevante sobre risco. Quais privilégios essa identidade possui? Ela está interagindo com informações sensíveis de forma incomum? Existem sinais relevantes associados ao seu endpoint? Está utilizando aplicações não autorizadas? Sua identidade apresentou eventos de autenticação que modificam sua exposição? Existe algum sinal externo que indique aumento na probabilidade de targeting?
Os conectores são sensores. A observabilidade começa quando conseguimos interpretar conjuntamente aquilo que esses sensores estão mostrando.
Depois da ingestão aparece outro desafio: um evento de DLP não possui a mesma estrutura de uma simulação de phishing. Um alerta de EDR é diferente de uma alteração de privilégio no IAM, que por sua vez não se parece com uma credencial identificada em uma fonte externa.
Se cada evento permanecer no formato original, teremos uma grande quantidade de telemetria, mas pouca capacidade de compará-la ou correlacioná-la. Por isso, uma arquitetura de Human Risk Observability precisa de uma camada de normalização capaz de transformar sinais heterogêneos em uma estrutura comum.
Essa estrutura pode registrar informações como identidade relacionada, categoria do sinal, origem, horário, severidade, nível de confiança, ativo envolvido e contexto. Também é importante distinguir o tipo de contribuição daquele sinal para o risco. Alguns eventos indicam comportamento, outros exposição, outros alteram impacto e existem ainda aqueles que representam mudanças de contexto.
Uma simulação de phishing pode produzir um sinal comportamental. Uma credencial encontrada em um vazamento aumenta exposição. A concessão de privilégio administrativo pode aumentar impacto. Uma mudança de função pode modificar contexto. Quando conseguimos classificar sinais dessa maneira, deixamos de tratar todos os eventos como equivalentes e começamos a construir uma representação mais coerente do risco.
Existe uma tentação natural de transformar todos os sinais imediatamente em uma única pontuação. Tecnicamente, isso facilita a construção do dashboard, mas pode esconder informações fundamentais.
Imagine uma pessoa com score de risco 85. Esse número, sozinho, não explica praticamente nada. Ela pode ter apresentado comportamentos recorrentes de risco, possuir exposição elevada ou simplesmente ocupar uma função com privilégios capazes de produzir grande impacto. Também pode existir uma combinação desses fatores.
Por isso, antes da agregação, é importante manter dimensões de risco separadas. Comportamento procura compreender aquilo que a identidade está fazendo ou como reage a determinadas situações. Exposição ajuda a representar as condições que aumentam a probabilidade de aquela identidade ser atacada ou comprometida. Contexto descreve quem aquela pessoa é dentro da organização e as condições em que opera. Impacto procura estimar as consequências potenciais caso alguma coisa aconteça.
Essa separação melhora a explicabilidade e, principalmente, o tratamento. Duas pessoas podem chegar ao mesmo score final por razões completamente diferentes e, portanto, exigir respostas diferentes. Se perdermos essas dimensões durante o cálculo, o score pode até parecer preciso, mas será pouco útil para reduzir risco.
Human Risk Observability também precisa entender tempo. Uma arquitetura que simplesmente acumula eventos históricos corre o risco de transformar qualquer erro cometido no passado em uma penalidade permanente.
Um clique em phishing ocorrido ontem provavelmente possui significado diferente de um evento semelhante ocorrido três anos atrás. Cinco ocorrências concentradas em duas semanas podem indicar um padrão que não existe quando os mesmos cinco eventos estão distribuídos ao longo de vários anos. Da mesma maneira, um comportamento que era anômalo pode deixar de ser quando a pessoa muda de função e passa a executar regularmente determinada atividade.
Isso significa que os sinais precisam carregar temporalidade e que o modelo precisa considerar recência, frequência e recorrência. Dependendo da categoria, pode existir algum mecanismo de redução de peso ao longo do tempo, desde que não ocorram novos eventos relacionados. Em outros casos, mudanças estruturais, como a concessão de um privilégio, permanecem relevantes enquanto aquela condição existir.
Essa distinção é importante. Existem sinais que representam eventos e sinais que representam estado. Um clique em phishing é um evento. Possuir privilégio administrativo é uma condição que continua existindo até que o acesso seja removido. Tratar os dois da mesma maneira produziria uma avaliação distorcida.
Outra capacidade importante é compreender o comportamento esperado para aquela identidade ou para grupos comparáveis. Nem todo evento incomum globalmente é incomum para determinada função.
Um profissional de dados pode movimentar grandes volumes de informação diariamente. Um administrador pode acessar dezenas de sistemas que seriam completamente atípicos para um usuário administrativo. Um executivo pode autenticar-se frequentemente durante viagens internacionais. Utilizar regras fixas sem considerar essas diferenças tende a gerar grande quantidade de falsos positivos.
Baselines ajudam a estabelecer esse contexto. Podemos observar o histórico da própria identidade, comparar determinados sinais com grupos semelhantes ou utilizar características da função para compreender se uma atividade representa realmente uma mudança.
Isso não significa que todo desvio de baseline represente risco. Significa apenas que mudança é uma informação importante. Quando combinada com outros sinais, pode ajudar a identificar situações que merecem atenção.
Depois que identidade, normalização, dimensões e temporalidade estão resolvidas, chegamos à parte mais importante da arquitetura: correlação.
Considere um administrador que sempre apresentou bom desempenho nas campanhas de conscientização. Isoladamente, nada chama atenção. Uma fonte externa identifica exposição recente de uma credencial associada àquela pessoa. Pouco depois, a plataforma de identidade registra autenticações anômalas e uma solução de segurança identifica atividade incomum relacionada à conta privilegiada.
Cada ferramenta conhece apenas sua parte da história. A plataforma de awareness sabe que aquela pessoa normalmente apresenta bom comportamento. A fonte externa conhece a exposição. O IAM observa autenticação. Outra tecnologia identifica atividade relacionada ao ambiente.
A observabilidade aparece quando conseguimos colocar esses sinais na mesma linha temporal e associá-los à mesma identidade. Nesse momento, o contexto muda. Um usuário com bom histórico de conscientização não deixa de apresentar risco apenas porque nunca clicou em uma simulação. A combinação de sinais provenientes de outras fontes pode alterar rapidamente sua avaliação.
O contrário também é verdadeiro. Se privilégios excessivos são removidos, uma credencial exposta é corrigida, mecanismos mais fortes de autenticação são implementados e o comportamento melhora, a arquitetura precisa conseguir representar redução de risco. Human Risk Observability não deveria funcionar apenas como um mecanismo que encontra motivos para aumentar scores.
Quando toda essa arquitetura é reduzida a um único número, existe o risco de inverter prioridades. Começamos a desenhar o sistema pensando em como produzir um score quando deveríamos primeiro pensar em como representar corretamente o risco.
O Human Risk Score deveria ser uma consequência da observabilidade. Ele pode ser extremamente útil para priorização, comparação de evolução e identificação de grupos que precisam de atenção, mas precisa preservar a possibilidade de decomposição. Uma equipe de segurança deveria conseguir sair do número agregado e compreender quais dimensões estão elevadas, quais sinais contribuíram para isso, quando aconteceram e de onde vieram.
Essa explicabilidade é importante também porque estamos trabalhando com pessoas. Um score elevado não deveria ser interpretado como uma avaliação de caráter, competência ou intenção. Um executivo pode apresentar risco elevado porque combina exposição e impacto. Um administrador pode aparecer em uma faixa superior simplesmente por possuir privilégios críticos. Outro usuário pode ter seu risco aumentado temporariamente por uma sequência de comportamentos específicos.
Sem essa decomposição, uma métrica de risco pode facilmente ser interpretada como um ranking de funcionários, algo que deveria ser evitado tanto por razões técnicas quanto de governança.
À medida que adicionamos conectores, eventos, normalização e correlação, é natural surgir a pergunta sobre a diferença entre uma plataforma de Human Risk Observability e um SIEM. A distinção está principalmente no problema que cada arquitetura procura resolver.
Um SIEM precisa receber e correlacionar eventos de segurança em grande escala para apoiar detecção, investigação e resposta. Uma plataforma de HRM não deveria tentar substituir essa função. Não existe razão para replicar toda a telemetria disponível no ambiente ou reconstruir regras de detecção que já funcionam em outras ferramentas.
O HRM deveria consumir apenas os sinais necessários para compreender mudanças relevantes no risco das identidades. Em muitos casos, inclusive, o próprio SIEM pode funcionar como fonte desses sinais. Uma correlação complexa pode acontecer na plataforma de segurança e apenas seu resultado relevante ser enviado ao HRM.
Essa separação mantém a arquitetura mais eficiente e reduz um problema importante: excesso de informação. Human Risk Observability não depende de observar todos os eventos produzidos por uma pessoa. Depende de conseguir observar os sinais que realmente modificam sua avaliação de risco.
Quanto mais fontes são conectadas, maior é a responsabilidade sobre os dados processados. Por isso, privacidade não pode ser uma camada adicionada depois que a arquitetura já está pronta.
É necessário definir quais categorias de sinais serão utilizadas, por que são necessárias, durante quanto tempo permanecerão relevantes, quem poderá acessá-las e quais decisões poderão ser tomadas a partir delas. Também precisamos separar claramente utilização para gestão de risco de outras finalidades que não faziam parte da coleta original.
Princípios como minimização de dados são especialmente relevantes. Se para determinado caso de uso basta saber que ocorreu um evento de DLP classificado em determinada categoria e severidade, talvez não exista necessidade de importar todo o conteúdo do documento relacionado ao evento. Se precisamos saber que uma identidade possui privilégio elevado, não necessariamente precisamos replicar toda a base de IAM dentro da plataforma.
Uma boa arquitetura procura ingerir contexto suficiente para compreender risco, não a maior quantidade possível de dados sobre uma pessoa.
Toda essa estrutura perde grande parte do valor se terminar apenas em um dashboard mostrando quem possui score alto ou baixo. O objetivo final de Human Risk Observability é permitir tratamentos mais precisos.
Quando a principal causa do risco está relacionada a conhecimento ou comportamento, treinamento ou comunicação direcionada podem ser adequados. Quando privilégios são o principal fator, o tratamento pode envolver IAM ou IGA. Exposição de credenciais pode exigir ações de identidade. Uso inadequado de informações pode levar a controles de DLP ou revisão de processos. Ataques direcionados podem justificar controles adicionais para determinadas pessoas ou grupos.
A própria resposta também pode produzir novos sinais. Depois que um privilégio é removido ou uma intervenção é concluída, a arquitetura deve conseguir observar se aquela ação efetivamente reduziu o risco. Isso transforma HRM em um ciclo, e não em uma fotografia.
Na prática, começamos a construir uma sequência contínua: observamos sinais, compreendemos contexto, medimos risco, priorizamos identidades ou grupos, aplicamos tratamentos e voltamos a observar os resultados.
Quando olhamos para a arquitetura completa, fica claro que Human Risk Observability não depende de substituir as tecnologias existentes. Pelo contrário, seu valor cresce justamente porque IAM, DLP, EDR, CASB, SIEM, plataformas de awareness e outras soluções já conhecem diferentes partes da realidade.
O problema é que cada uma delas observa o ambiente a partir de seu próprio ponto de vista. O IAM entende identidade. O DLP entende dados. O EDR entende endpoints. A plataforma de conscientização entende treinamento e determinadas respostas comportamentais. O SIEM conhece eventos e correlações de segurança. Nenhuma delas, isoladamente, foi criada para responder qual é o risco humano associado a uma pessoa naquele momento.
A arquitetura de Human Risk Observability cria uma camada capaz de relacionar essas perspectivas em torno da identidade. Para isso, precisa resolver identidade, selecionar sinais relevantes, normalizar informações, preservar dimensões diferentes de risco, compreender temporalidade, estabelecer baselines, correlacionar eventos e manter explicabilidade.
Somente depois disso faz sentido produzir um Human Risk Score.
Essa ordem é importante porque evita um erro que pode se tornar comum conforme HRM ganha popularidade: começar pelo score e procurar dados para justificá-lo. A arquitetura deveria fazer exatamente o contrário. Primeiro precisamos construir observabilidade suficiente para compreender o risco. O score passa a ser apenas uma forma de representar parte dessa compreensão.
Quando conseguimos fazer isso, deixamos de perguntar apenas o que uma pessoa aprendeu ou como respondeu a uma simulação. Passamos a compreender quem é aquela identidade, como seu contexto está mudando, quais sinais relevantes estão acontecendo ao seu redor e qual impacto potencial está associado a ela.
É nesse momento que Human Risk Management começa realmente a se comportar como uma disciplina de gestão de risco.