Como ficar à frente dos atores da ameaça

A cadeia de destruição moderna está iludindo as empresas porque elas não estão protegendo a infraestrutura dos negócios modernos: SaaS.

SaaS continua a dominar a adoção de software program, e é responsável pela maior parcela dos gastos com nuvem pública. Mas as empresas e as pequenas e médias empresas não revisaram seus programas de segurança nem adotaram ferramentas de segurança desenvolvidas para SaaS.

As equipes de segurança continuam bloqueando falhas de segurança de SaaS no native

Os controles de segurança maduros dos quais os CISOs e suas equipes dependiam na period do domínio native desapareceram. Os firewalls agora protegem um perímetro pequeno, a visibilidade é limitada e, mesmo que os fornecedores de SaaS ofereçam logs, as equipes de segurança precisam de um middleware desenvolvido internamente para digeri-los e inseri-los em seu SIEM.

Os fornecedores de SaaS têm escopos de segurança bem definidos para seus produtos, mas seus clientes devem gerenciar a conformidade e a governança de dados do SaaS, o gerenciamento de identidade e acesso (IAM) e os controles de aplicativos — as áreas onde a maioria dos incidentes ocorre. Embora esse modelo de responsabilidade compartilhada do SaaS seja common entre os aplicativos SaaS, não há dois aplicativos SaaS com configurações de segurança idênticas.

Figura 1. No contexto das preocupações de segurança de SaaS, o provedor de aplicativos é responsável por toda a infraestrutura física, bem como pela rede, sistema operacional e aplicativos. O cliente é responsável pela segurança dos dados e pelo gerenciamento de identidade. O modelo de responsabilidade compartilhada SaaS exige que os clientes SaaS assumam a propriedade dos componentes que os agentes de ameaças atacam com mais frequência. Ilustração cortesia de AppOmni.

A pesquisa da AppOmni relata que, em média, uma única instância de SaaS tem 256 conexões SaaS para SaaSmuitos dos quais não estão mais em uso, mas ainda têm permissões excessivas em aplicativos de negócios principais, como Salesforce, Okta e GitHub, entre outros.

Entre a multidão de diferentes configurações de segurança SaaS e atualizações constantes que as alteram, as equipes de segurança não conseguem monitorar essas conexões de forma eficaz. O número de pontos de entrada se multiplica exponencialmente quando os funcionários habilitam conexões SaaS-para-SaaS (também chamadas de “terceiros” ou “máquina”). As identidades de máquina podem usar chaves de API, segredos, sessões, certificados digitais, chaves de acesso à nuvem e outras credenciais para permitir que as máquinas se comuniquem entre si.

À medida que a superfície de ataque migrava para fora do perímetro da rede, o mesmo acontecia com a cadeia de eliminação — a maneira como os agentes de ameaças orquestram as várias fases de seus ataques.

A moderna kill chain do SaaS geralmente envolve:

1. Comprometer uma identidade no IdP por meio de uma campanha de phishing bem-sucedida, comprar credenciais roubadas na darkish net, cadeias de credenciais, preenchimento de credenciais, aproveitar locatários de SaaS mal configurados ou métodos semelhantes.
2. Conduzindo uma fase de reconhecimento pós-autenticação. Esta etapa lembra os invasores que invadiram as redes corporativas de outrora. Mas agora eles estão vasculhando repositórios de documentos, repositórios de código-fonte, cofres de senhas, Slack, Groups e ambientes semelhantes para encontrar pontos de entrada de escalonamento privilegiados.
3. Aproveitar suas descobertas para migrar lateralmente para outros locatários de SaaS, PaaS ou IaaS e, às vezes, para a infraestrutura corporativa – onde quer que possam encontrar os dados mais valiosos para a organização-alvo.
4. Criptografar as joias da coroa ou entregar sua nota de resgate e tentar escapar da detecção.

Figura 2. Kill chains de SaaS bem-sucedidas geralmente envolvem quatro etapas abrangentes: acesso inicial, reconhecimento, movimento lateral e persistência, e execução de ransomware e evasão de segurança. Ilustração cortesia da AppOmni.

Destrinchando uma cadeia de destruição de SaaS do mundo actual: Scattered Spider/Starfraud

O último webinar de briefing de inteligência de ameaças do líder de segurança SaaS AppOmni delineou a cadeia de destruição do ataque bem-sucedido dos grupos de atores de ameaças Scattered Spider/Starfraud (afiliados da ALPHV) a um alvo não revelado em setembro de 2023:

• Um usuário abriu um e-mail de phishing que continha hyperlinks para uma página de login de IdP falsa e, sem saber, fez login na página falsa do IdP.
• Os grupos de atores de ameaças ligaram imediatamente para esse usuário e os convenceram, por meio de engenharia social, a fornecer seu token de senha única (TOTP) baseado em tempo.
• Depois de obter as credenciais de login do usuário e o token TOTP, os invasores enganaram o protocolo MFA, fazendo-o pensar que eles eram o usuário legítimo.
• Enquanto estavam no modo de reconhecimento, os atores da ameaça tiveram acesso a um escalonamento privilegiado, permitindo-lhes obter credenciais no Amazon S3, depois no Azure AD e, finalmente, no Citrix VDI (infraestrutura de desktop digital).
• Os agentes da ameaça então implantaram seu próprio servidor malicioso no ambiente IaaS, no qual executaram um ataque de escalonamento privilegiado do Azure AD.
• Os invasores criptografaram todos os dados ao seu alcance e entregaram uma nota de resgate.

Figura 3. A cadeia de destruição usada pelos grupos de atores de ameaças Scattered Spider/Starfraud. Ilustração cortesia de AppOmni.

O Scattered Spider/Starfraud provavelmente realizou essa série de eventos ao longo de vários dias. Quando o SaaS serve como ponto de entrada, um ataque sério pode incluir a rede corporativa e a infraestrutura. Essa conectividade SaaS/on-prem é comum nas superfícies de ataque corporativo de hoje.

A atividade de ataques SaaS de atores de ameaças conhecidos e desconhecidos está crescendo

A maioria das violações de SaaS não está dominando as manchetes, mas as consequências são significativas. A IBM relata que violações de dados em 2023 tiveram uma média de US$ 4,45 milhões por instância, representando um aumento de 15% em três anos.

Os agentes de ameaças dependem continuamente dos mesmos TTPs e do handbook da cadeia de eliminação do Scattered Spider/Starfraud para obter acesso não autorizado e escanear inquilinos de SaaS, incluindo Salesforce e M365, onde problemas de configuração podem ser manipulados para fornecer acesso posteriormente.

Outros invasores ganham acesso inicial com sequestro de sessão e viagens impossíveis. Depois que eles transferem a sessão sequestrada para um host diferente, seu movimento lateral geralmente envolve plataformas de comunicação como SharePoint, JIRA, DocuSign e Slack, bem como repositórios de documentos como Confluence. Se eles puderem acessar o GitHub ou outros repositórios de código-fonte, os agentes de ameaças puxarão esse código-fonte e o analisarão em busca de vulnerabilidades em um aplicativo de destino. Eles tentarão explorar essas vulnerabilidades para exfiltrar os dados do aplicativo de destino.

O briefing de inteligência de ameaças do AppOmni também relata que a exfiltração de dados por meio do compartilhamento de permissões continua sendo uma séria preocupação de segurança do SaaS. Isso ocorre, por exemplo, no Google Workspace quando o usuário não autorizado altera diretórios para um nível muito aberto de permissões. O invasor pode compartilhá-los com outra entidade externa por meio de encaminhamento de e-mail ou alteração de regras condicionais para que os invasores sejam incluídos como destinatários BCC em uma lista de distribuição.

Como você protege seus ambientes SaaS?

1. Foco na higiene dos sistemas SaaS

Estabeleça um processo de admissão e revisão de SaaS para determinar qual SaaS você permitirá em sua empresa. Este processo deve exigir respostas para perguntas de segurança como:

• Todo SaaS precisa ter certificação SOC 2 Tipo 2?
• Qual é a configuração de segurança superb para cada locatário?
• Como sua empresa evitará desvios de configuração?
• Como você determinará se as atualizações automáticas de SaaS exigirão a modificação das configurações de controle de segurança?

Certifique-se de que você pode detectar Shadow IT SaaS (ou aplicativos SaaS não autorizados) e tenha um programa de resposta para que os alertas não sejam criados em vão.

Se você não estiver monitorando seus locatários SaaS e ingerindo todos os logs deles em algum método unificado, você nunca conseguirá detectar comportamentos suspeitos e receber alertas com base neles.

2. Inventariar e monitorar continuamente contas/identidades de máquinas

Os agentes de ameaças têm como alvo identidades de máquina por seu acesso privilegiado e padrões de autenticação frouxos, muitas vezes raramente exigindo MFA.

Em 2023, os agentes de ameaças visaram e violaram com sucesso as principais ferramentas de CI/CD Travis CI, CircleCI e Heroku, roubando tokens OAuth para todos os clientes desses provedores. O raio da explosão se expande consideravelmente nessas situações.

Com a empresa média contendo 256 identidades de máquina, a higiene geralmente está faltando. Muitas delas são usadas uma ou duas vezes e então permanecem estagnadas por anos.

Faça o inventário de todas as identidades de suas máquinas e faça a triagem desses riscos críticos. Depois de mitigá-los, crie políticas que prescrevam:

• Que tipo de contas receberão identidades de máquina e os requisitos que esses fornecedores devem atender para receber acesso.
• O período de tempo durante o qual seus acessos/tokens estão ativos antes de serem revogados, atualizados ou concedidos novamente.
• Como você monitorará o uso dessas contas e garantirá que elas ainda sejam necessárias caso passem por períodos de inatividade.

3. Construa uma verdadeira arquitetura Zero Belief em seu patrimônio SaaS

A arquitetura Zero Belief baseia-se no princípio do menor privilégio (PLP) com uma abordagem “nunca confie, sempre verifique”. Embora Zero Belief tenha sido estabelecido em redes tradicionais, raramente é alcançado em ambientes SaaS.

A abordagem centrada na rede do Zero Belief Community Entry (ZTNA) não consegue detectar configurações incorretas, integrações de máquinas ou direitos de acesso de usuários indesejados dentro e para plataformas SaaS, que podem ter milhares ou até milhões de usuários externos acessando dados.

Zero Belief Posture Administration (ZTPM), uma ferramenta de segurança SaaS emergente, estende o Zero Belief para seu patrimônio SaaS. Ele preenche a lacuna de segurança SaaS que o SASE cria por:

• Evitando desvio não autorizado de ZTNA
• Permitindo decisões de acesso ajustadas
• Aplicação de suas políticas de segurança com ciclos de suggestions contínuos
• Estendendo o Zero Belief para integrações de máquinas e conexões de nuvem

Com SSPM, ZTPM e um Programa de segurança SaaS implementado, sua equipe obterá a visibilidade e a inteligência necessárias para identificar intrusos nos estágios de baixo risco de sua cadeia de destruição — e detê-los antes que uma violação se torne devastadora.