Durante muitos anos, as plataformas de conscientização em segurança trabalharam com um conjunto relativamente bem definido de informações para medir o desempenho dos usuários. Conclusão de treinamentos, notas em avaliações, resultados de simulações de phishing, reincidência e reporte de mensagens suspeitas formaram a base dos principais indicadores utilizados para acompanhar a evolução de um programa. Com o amadurecimento do mercado, essas informações começaram a ser combinadas em scores comportamentais e, mais recentemente, muitos desses scores passaram a ser apresentados como Human Risk Scores.
Tecnicamente, existe uma diferença importante entre essas duas coisas. Um score construído exclusivamente com informações de treinamento e simulações consegue produzir uma boa visão sobre aprendizado e sobre determinados comportamentos que a plataforma foi capaz de testar. Para medir risco humano de forma mais ampla, porém, precisamos compreender uma identidade dentro do ambiente em que ela realmente trabalha. Isso exige olhar para privilégios, dados acessados, aplicações utilizadas, exposição, dispositivos, eventos de segurança e contexto organizacional. Em outras palavras, o Human Risk Score precisa ser construído não apenas com aquilo que a plataforma de awareness sabe sobre o usuário, mas também com sinais provenientes do restante do ecossistema de segurança.
Essa mudança parece simples quando colocada dessa forma, mas tem implicações importantes de arquitetura. Construir um Human Risk Score não significa apenas adicionar mais campos a um algoritmo existente. Significa criar uma camada capaz de receber sinais de fontes diferentes, associá-los corretamente às identidades, normalizá-los, adicionar contexto e transformar eventos técnicos em informações que possam ser utilizadas para avaliar risco.
Uma plataforma de conscientização possui uma vantagem importante: ela consegue gerar telemetria diretamente relacionada à interação da pessoa com segurança. Quando realizamos uma simulação de phishing, por exemplo, conseguimos observar se o usuário abriu a mensagem, clicou em um link, forneceu informações, reportou o ataque ou ignorou a tentativa. Quando aplicamos um treinamento, conseguimos acompanhar conclusão, resultado de avaliações, evolução e eventualmente dificuldades recorrentes em determinados temas.
Esses dados são extremamente valiosos porque ajudam a construir uma visão comportamental. Um usuário que reporta consistentemente mensagens suspeitas apresenta um sinal positivo. Alguém que reincide em determinados comportamentos pode exigir atenção específica. A evolução ao longo do tempo também pode indicar se determinada intervenção está funcionando. O problema técnico começa quando tentamos extrapolar essas informações para representar todo o risco daquela identidade.
A plataforma sabe que um usuário clicou em uma simulação de phishing, mas pode não saber se aquela pessoa possui privilégios administrativos. Sabe que outro colaborador obteve nota máxima no treinamento, mas talvez não saiba que sua credencial apareceu recentemente em uma fonte de exposição externa. Conhece o histórico de campanhas de um executivo, mas pode não saber que ele está recebendo um volume anormal de ataques direcionados. Sem essas informações, conseguimos medir muito bem aquilo que aconteceu dentro do programa de conscientização, mas ainda conhecemos apenas uma parte do risco.
Uma das primeiras fontes que precisam ser incorporadas a uma arquitetura de HRM é a identidade. Sistemas de IAM e IGA possuem informações que ajudam a responder perguntas que uma plataforma de awareness normalmente não consegue responder sozinha: quem é essa identidade, quais sistemas ela acessa, de quais grupos faz parte, quais privilégios possui e quais alterações recentes ocorreram em seus acessos.
Essa camada é fundamental porque o mesmo comportamento pode produzir riscos muito diferentes dependendo dos privilégios associados à identidade. Dois usuários podem clicar exatamente na mesma simulação de phishing e apresentar o mesmo histórico de treinamento. Se um deles possui poucos acessos e o outro administra serviços críticos da organização, o evento comportamental é semelhante, mas o potencial de impacto de um comprometimento não é.
O mesmo raciocínio se aplica a privilégios acumulados ao longo do tempo, contas com acessos incompatíveis com a função atual, identidades privilegiadas ou pessoas capazes de executar transações críticas. Nenhuma dessas condições significa que o usuário possui um comportamento inadequado. Elas simplesmente modificam o impacto potencial associado àquela identidade. Em um modelo de risco, essa diferença precisa aparecer.
Por isso, uma arquitetura madura não deveria perguntar apenas se a pessoa apresentou um comportamento de risco. Também deveria conseguir responder o que um atacante conseguiria fazer caso aquela identidade fosse comprometida. Essa é uma informação que awareness sozinho dificilmente conseguirá fornecer.
Outra fonte importante está nas tecnologias de Data Loss Prevention. Se identidade ajuda a compreender quem é o usuário e quais acessos possui, DLP pode adicionar contexto sobre a forma como aquela identidade interage com informações relevantes para a organização.
Uma tentativa de movimentar um documento sensível para um destino não autorizado, o compartilhamento inadequado de informações ou uma sequência recorrente de bloqueios relacionados a dados classificados podem produzir sinais úteis para um modelo de risco humano. Mais uma vez, isso não significa interpretar automaticamente cada alerta de DLP como comportamento malicioso. Existem erros, processos inadequados e situações legítimas que podem gerar eventos semelhantes.
O valor aparece quando o sinal é correlacionado com outras informações. Um evento isolado de DLP pode representar pouco. Uma sequência recorrente de eventos associada a uma identidade com acesso a informações críticas, combinada com outros comportamentos relevantes, pode alterar significativamente sua avaliação de risco.
Isso também demonstra por que um Human Risk Score não deveria funcionar simplesmente como uma soma de alertas. Se cada evento recebido de uma tecnologia externa apenas acrescentar alguns pontos ao score, estaremos substituindo um problema por outro. O desafio é compreender o significado daquele sinal dentro do contexto da identidade.
O crescimento das aplicações SaaS, do Shadow IT e, mais recentemente, do Shadow AI tornou outra camada de telemetria especialmente importante. Grande parte da atividade dos usuários acontece hoje diretamente no navegador, muitas vezes em aplicações que não são administradas ou sequer conhecidas pela organização.
Tecnologias de CASB, SSE e Secure Web Gateway conseguem produzir informações sobre aplicações utilizadas, serviços não autorizados, uploads, downloads e outras interações relevantes. Esses sinais ajudam a revelar comportamentos que dificilmente apareceriam em uma plataforma de conscientização. Um usuário pode ter excelente desempenho em todas as simulações de phishing e, ao mesmo tempo, utilizar regularmente uma aplicação de inteligência artificial não autorizada para processar documentos corporativos.
Esse exemplo é interessante porque demonstra novamente a diferença entre conhecimento e risco. A pessoa pode conhecer perfeitamente a política de segurança e ainda assim adotar determinado comportamento por conveniência, necessidade operacional ou simplesmente porque acredita que aquela utilização não representa um problema. O HRM precisa conseguir incorporar esse tipo de sinal sem depender de uma simulação específica para descobri-lo.
[](#fale-com-especialista)
Endpoints também produzem sinais relevantes. Soluções de EDR e XDR conseguem observar atividades relacionadas aos dispositivos utilizados pelas identidades, permitindo adicionar uma perspectiva que não existe dentro do ambiente de treinamento.
Dependendo da arquitetura e das políticas da organização, podem existir informações relacionadas à utilização incomum de dispositivos removíveis, execução de ferramentas não habituais, alterações relevantes de configuração, eventos de segurança ou outras atividades associadas ao endpoint. Assim como acontece com DLP, esses sinais precisam ser tratados com cuidado. Um evento técnico não deveria automaticamente ser convertido em uma conclusão sobre comportamento humano.
O ponto importante é que a identidade funciona como elemento de correlação. Um alerta de endpoint deixa de ser apenas um evento relacionado a um dispositivo quando conseguimos compreender qual identidade estava envolvida, quais privilégios ela possui, quais outros sinais foram observados e se existe alguma mudança relevante em relação ao seu padrão anterior.
É nessa correlação que começamos a sair de uma coleção de alertas para uma visão de risco.
Grande parte das organizações já concentra uma quantidade significativa de telemetria em plataformas de SIEM. Autenticações, alertas de segurança, eventos de aplicações, informações de rede e sinais provenientes de diferentes controles podem estar disponíveis nesse ambiente. Para HRM, isso representa uma oportunidade importante porque nem sempre será necessário construir integrações individuais com todas as tecnologias existentes na empresa.
Em determinados cenários, o SIEM pode funcionar como uma fonte agregadora de sinais. O HRM pode receber eventos previamente selecionados ou correlacionados e associá-los às identidades correspondentes. Em outros casos, integrações diretas com IAM, DLP, EDR ou CASB podem fornecer contexto mais rico. A arquitetura ideal provavelmente será híbrida e dependerá do ambiente de cada organização.
O mais importante é não transformar HRM em um segundo SIEM. O objetivo não deveria ser ingerir todos os eventos técnicos disponíveis nem reconstruir toda a infraestrutura de correlação já existente. A função do HRM é selecionar sinais relevantes para risco humano, associá-los às identidades e utilizá-los junto com comportamento, exposição e contexto para produzir uma visão orientada a risco.
Nem todos os sinais relevantes são produzidos dentro da empresa. Uma identidade pode estar exposta externamente de maneiras muito diferentes, e essa exposição influencia sua probabilidade de ser atacada.
Credenciais encontradas em vazamentos, informações profissionais publicamente disponíveis, presença em determinados ambientes e sinais de ataques direcionados podem contribuir para entender por que algumas identidades são mais interessantes para criminosos do que outras. Executivos, administradores, profissionais financeiros e pessoas com determinadas responsabilidades podem possuir uma exposição naturalmente maior, independentemente de seu desempenho em treinamentos.
Essa dimensão é particularmente importante porque reforça que risco elevado não significa comportamento ruim. Uma pessoa pode ser extremamente consciente, apresentar excelente desempenho em todas as avaliações e ainda assim possuir risco elevado porque sua identidade combina grande exposição com alto impacto potencial.
Um modelo que considera apenas comportamento tende a penalizar quem erra. Um modelo de risco precisa também reconhecer quem pode ser comprometido e quais seriam as consequências.
Depois que começamos a integrar diferentes fontes, surge um problema técnico que pode ser mais complexo do que criar os próprios conectores: garantir que todos aqueles eventos realmente estejam associados à mesma identidade.
Uma pessoa pode aparecer em diferentes sistemas utilizando e-mail, UPN, identificador interno, matrícula, SID, conta privilegiada ou outras formas de identificação. Pode possuir mais de uma conta, trabalhar com identidades administrativas separadas ou ter passado por alterações de nome, função e estrutura organizacional. Se esses dados não forem corretamente reconciliados, o modelo pode fragmentar sinais de uma mesma pessoa ou, pior, associar eventos de identidades diferentes.
Por isso, uma arquitetura de HRM precisa possuir uma camada consistente de resolução de identidade. O usuário não pode ser apenas um endereço de e-mail importado pela plataforma de awareness. Ele precisa funcionar como uma entidade à qual diferentes contas, atributos, acessos, dispositivos e sinais possam ser relacionados.
Essa visão também permite acompanhar mudanças ao longo do tempo. Uma pessoa pode mudar de área, receber novos privilégios ou deixar de possuir determinados acessos. O risco precisa refletir o estado atual da identidade, e não apenas uma fotografia criada no momento de sua inclusão na plataforma.
Uma plataforma pode possuir integrações com dezenas de tecnologias e ainda assim produzir um Human Risk Score pouco útil. Isso acontece porque conectar sistemas resolve apenas a primeira parte do problema. Depois da ingestão, precisamos compreender o significado de sinais que possuem estruturas, severidades e níveis de confiança completamente diferentes.
Um alerta crítico em uma ferramenta não necessariamente possui o mesmo significado de um alerta crítico em outra. Alguns eventos representam comportamentos diretamente observados, enquanto outros são inferências produzidas por modelos proprietários. Existem sinais altamente confiáveis e outros que possuem grande probabilidade de falso positivo. Também precisamos considerar frequência, recorrência, temporalidade e relação com o baseline daquela identidade.
Uma arquitetura madura precisa, portanto, criar uma camada de normalização. Em vez de simplesmente transformar cada alerta em pontos, os eventos precisam ser classificados de acordo com dimensões de risco, possuir pesos coerentes e carregar informações sobre origem, confiança, severidade e momento em que ocorreram.
A temporalidade é especialmente importante. Um evento ocorrido ontem não deveria necessariamente possuir o mesmo peso de um comportamento observado há dois anos. Da mesma forma, uma sequência de cinco eventos relacionados em poucos dias pode ser mais significativa do que os mesmos cinco eventos distribuídos ao longo de vários anos.
Esse talvez seja o ponto técnico mais importante de toda a arquitetura. Human Risk Score não deveria funcionar como um contador sofisticado de eventos.
Imagine um usuário que clicou recentemente em uma simulação de phishing. Isoladamente, temos um sinal comportamental. Agora descobrimos que essa identidade possui privilégios administrativos. Uma fonte externa indica exposição recente de credenciais e o sistema de identidade registra tentativas anormais de autenticação. O DLP também apresenta um comportamento fora do padrão relacionado àquela conta.
Nenhum desses sinais, individualmente, necessariamente demonstra um incidente ou uma condição crítica. Quando colocados na mesma linha temporal e associados à mesma identidade, entretanto, passam a contar uma história diferente.
É justamente essa capacidade de correlação que separa a simples ingestão de telemetria da análise de risco. O modelo precisa entender que determinados sinais aumentam de importância quando aparecem combinados, enquanto outros podem reduzir risco ou demonstrar evolução positiva.
O reporte consistente de ameaças, por exemplo, também é um comportamento e deveria ser considerado. Human Risk Management não pode ser construído apenas como um sistema que acumula penalidades. Comportamentos positivos, redução de exposição, remoção de privilégios e evolução após intervenções também precisam modificar a avaliação.
Quanto mais sofisticado o modelo se torna, maior é o risco de produzir uma pontuação que ninguém consegue explicar. Isso é especialmente problemático quando estamos trabalhando com informações relacionadas a pessoas.
Se um usuário recebe score 87, a equipe de segurança precisa conseguir entender por quê. Talvez parte do risco esteja relacionada a privilégios elevados, outra parte à exposição externa e outra a comportamentos recentes. Essa composição precisa ser visível. Um algoritmo que simplesmente apresenta uma nota final sem demonstrar os fatores que contribuíram para ela pode dificultar tanto a investigação quanto o tratamento.
A explicabilidade também ajuda a evitar interpretações equivocadas. Um executivo com score elevado pode não ter cometido qualquer erro. Sua classificação pode ser resultado da combinação entre exposição, função e impacto potencial. Sem essa explicação, alguém poderia interpretar a pontuação como uma avaliação negativa do comportamento daquela pessoa.
Por isso, além do valor final, um Human Risk Score deveria apresentar dimensões, sinais relevantes, evolução temporal e fatores que explicam sua composição. A pergunta não deveria ser apenas “qual é o risco?”, mas também “por que o risco está nesse nível?”.
O último componente não é exatamente uma fonte de dados, mas é fundamental para determinar se todo esse esforço de integração e correlação realmente possui valor. O Human Risk Score precisa permitir que a organização faça alguma coisa diferente a partir da informação produzida.
Se uma pessoa possui risco elevado por dificuldade recorrente em reconhecer determinados ataques, uma intervenção educacional pode ser adequada. Se o principal fator está relacionado a privilégios excessivos, o tratamento deveria envolver IAM ou IGA. Se existe exposição de credenciais, a resposta pode exigir ações de identidade. Se os sinais estão relacionados ao uso inadequado de informações, DLP e revisão de processos podem ser mais relevantes. Quando o problema está associado à exposição a ataques direcionados, talvez seja necessário combinar controles técnicos adicionais com preparação específica.
Essa capacidade de direcionar tratamentos diferentes é consequência direta da qualidade dos dados utilizados para construir o score. Quando conhecemos apenas treinamento e phishing, naturalmente nossas possibilidades de resposta ficam concentradas em treinamento e phishing. Quando compreendemos identidade, exposição, comportamento, dados, privilégios e contexto, podemos começar a tratar diferentes causas de risco de maneiras diferentes.
É nesse ponto que a arquitetura deixa de ser apenas uma evolução técnica de uma plataforma de awareness e começa a funcionar efetivamente como Human Risk Management.
A evolução de um Awareness Score para um Human Risk Score não exige abandonar nenhuma das informações que já utilizamos. Treinamentos, avaliações, simulações de phishing e reporte continuam sendo fontes fundamentais de telemetria humana. O que precisamos abandonar é a ideia de que esses dados, sozinhos, conseguem explicar todo o risco associado a uma identidade.
Uma arquitetura de HRM precisa conectar essa telemetria ao restante do ecossistema corporativo. Identidade e privilégios ajudam a compreender quem é a pessoa e o que ela pode fazer. DLP adiciona contexto sobre informações. CASB e SSE mostram parte da interação com aplicações e serviços cloud. EDR e XDR acrescentam sinais relacionados aos endpoints. SIEM pode disponibilizar eventos provenientes de diferentes controles. Fontes externas ajudam a compreender exposição. O contexto organizacional explica função e criticidade. A resolução de identidade conecta essas diferentes perspectivas, enquanto normalização, temporalidade e correlação transformam eventos em informação de risco.
A diferença fundamental está justamente aí. Um Awareness Score consegue responder muito bem como uma pessoa se saiu diante daquilo que ensinamos e testamos. Um Human Risk Score precisa responder uma pergunta tecnicamente muito mais difícil: considerando quem essa pessoa é, o que ela faz, o que pode acessar, como se comporta, a que está exposta e qual impacto poderia produzir, qual é o risco associado a essa identidade neste momento?
Responder essa pergunta exige muito mais do que um algoritmo de pontuação. Exige observabilidade sobre risco humano.