Introdução
Proteger organizações contra ameaças cibernéticas utilizando apenas dados e indicadores internos é limitado e insuficiente para uma efetiva proteção aos dados, contas e identidades. Por isso, é de extrema importância a utilização de informações externas que possam aprimorar a detecção de ameaças. Atualmente muitos fabricantes possuem diversas soluções de segurança da informação robustas e com ampla base de conhecimento de indicadores de comprometimento e segurança, porém essa riqueza de informações não são devidamente compartilhadas. Por isso, informações que poderiam mitigar um ataque ou fraude podem ficar restritas ao domínio de cada fabricante de maneira fragmentada.
Diante desse cenário, surgiu o OpenID Foundation Shared Signals Framework (SSF) que visa facilitar o compartilhamento e troca de sinais de segurança entre partes confiáveis em tempo real (ou quase em tempo real). Ele desempenha um papel crucial na segurança, permitindo que organizações compartilhem eventos de segurança, como indicadores de comprometimento, de maneira eficiente e com a devida padronização para que haja o compartilhamento e interoperabilidade entre organizações e até fabricantes distintos.
O SSF se baseia em eventos Shared Signals and Events (SSE), que é composto por dois protocolos:
Continuous Access Evaluation Protocol (CAEP)
Risk Incident Sharing and Coordination (RISC) protocol.
Cada sinal do SSF é definido como um evento de segurança, que possui um identificador único. Os eventos CAEP incluem, por exemplo: revogação de sessão e alterações de claims de tokens. Já os eventos RISC, incluem, por exemplo, alteração de credencial de conta; conta removida/desativada/ativada; identificador alterado/reciclado etc. Diante das possibilidades, fica evidente que o SSF pode ser um grande auxiliador na proteção de contas, identidades e acessos.
Casos de uso de SSF
Por exemplo, uma organização (transmissor) pode emitir um evento de segurança a respeito de um usuário para outra organização (receptor) que também possui alguma conta vinculada àquele usuário. Esse evento pode ser uma notificação de algum comprometimento ou violação e a organização receptora pode imediatamente revogar o acesso no seu ambiente ou tomar outras decisões que entender apropriadas, como por exemplo: ajustar o nível de acesso do usuário, encerrar a sessão, forçar uma reautenticação, forçar a troca de senha ou MFA etc.
Utilizando a mesma ideia do exemplo anterior, podemos aplicar a um caso de uso para quando ocorrer o comprometimento de sessão de um usuário em um sistema de uma organização (transmissor), no qual pode ser enviado o sinal para outra organização (receptor) para revogar as sessões de sistemas sob seu domínio. Sendo talvez esse o caso de uso mais comum no momento.
Além da interoperabilidade entre organizações, pode-se usar o SSE para contextos internos para interoperabilidade de sistemas. Por exemplo:em um cenário em que o Identity Provider (IdP) possui uma sessão com um limite de 1h enquanto a aplicação de destino (Service Provider - SP) pode ter um sessão ilimitada. Quando o IdP identificar algum comportamento anômalo, ele pode por meio de eventos SSE, notificar o SP para encerrar a sessão.
Qual é a diferença entre os protocolos CAEP e RISC?
O protocolo CAEP lida com eventos em tempo real, e por isso pode ter um alto volume, incluindo ações relacionadas à sessão, como revogações de sessão e alterações de claims de token. Enquanto o protocolo RISC lida com eventos relacionados a conta, sendo menos frequentes e que normalmente não requer uma ação imediata, por exemplo: alterações de credenciais ou desativação de contas.
Na prática, soluções que já suportam o SSF, estão aptas a receber e enviar eventos de segurança, no qual vários serviços podem se comunicar publicando ou assinando fluxos de eventos relevantes. Por exemplo, uma solução de AM (Access Management) pode enviar um sinal de mudança de contexto de um usuário para ser usado por um SIEM iniciar uma investigação automaticamente. Outro exemplo: um aplicativo pode assinar eventos de uma solução de detecção e resposta de endpoints para receber sinais de eventos de sistemas infectados e tomar alguma ação.
Quais são os benefícios do SSF?
Dentre todos os benefícios, pode-se destacar:
Gerenciamento de Identidades e Acessos mais seguro: podemos aproveitar, por exemplo, sinais de organizações federadas ou um domínio confiável
Visibilidade mais ampla: compartilhamento de visibilidade da postura de segurança de usuários entre organizações
Avaliação contínua de riscos: possibilidade de ser implantada uma camada de segurança que cobre a sessão do usuário após a autenticação
Redução de sobrecarga operacional e proteção mais ampla: compartilhamento automático de indicadores e sinais de segurança
Conclusão
O SSF oferece uma forma segura de compartilhar informações, utilizando um formato padrão para representar eventos e um mecanismo de transporte seguro. Isso possibilita a integração fácil nas infraestruturas de segurança existentes, promovendo a colaboração entre organizações para identificar e mitigar ameaças de maneira mais rápida e eficaz.
A implementação do SSF por grandes empresas, como Apple, e o apoio de organizações como Okta, Cisco e SGNL, demonstram o reconhecimento e a maturidade crescentes do SSF como um padrão promissor na gestão de identidade e segurança. A OpenID Foundation é a entidade por trás do SSF, comprometida em criar padrões de identidade abertos, seguros e interoperáveis.
Os benefícios do SSF incluem a adesão aos princípios de confiança zero (zero trust), redução da sobrecarga operacional, maior visibilidade sobre a postura de segurança, gerenciamento contínuo de identidades federadas e avaliação contínua de riscos. O relatório da NSA e CISA reconheceu o potencial do SSF, destacando sua capacidade de revolucionar o compartilhamento de informações de segurança.
Comments