Os bancos bloqueiam agentes de IA nas contas, um SBOM que não conseguiu delimitar um incidente Shai-Hulud, passkeys que não fecham a identidade, quanto tempo guardar logs, e uma falha de 2.7 que os desligou.
Nesta edição
- 01Os bancos estão a bloquear agentes de IA nas contas dos clientes.
- 02O SBOM não indicou o que tinha realmente sido executado.
- 03As passkeys fecham o problema das palavras-passe. Não fecham a identidade.
- 04O seu SOC quer todos os logs para sempre. O seu DPO quer seis meses.
- 05Uma falha com pontuação de 2.7 desligou os logs, e ninguém a teria corrigido.
Receba o próximo GRC Brief na sua caixa de entrada.
Subscrever The GRC BriefOs bancos estão a bloquear agentes de IA nas contas dos clientes.
O Axios noticiou a 22 de outubro que os principais bancos norte-americanos estão a detetar agentes de IA de terceiros a operar dentro de contas de clientes, geralmente porque o cliente cedeu o seu nome de utilizador e palavra-passe. O presidente executivo do JPMorgan afirmou que permitir a entrada de agentes externos arbitrários seria demasiado arriscado para os clientes e para o banco. O Bank of America lembrou aos clientes que, se partilharem as suas credenciais, são responsáveis por tudo o que daí resulte. Muitos bancos estão a avançar para o acesso apenas de leitura. Uma posição contrária, da Bianco Research, é que a banca de retalho beneficia da inércia dos clientes, e um agente que transfira saldos inativos para um fundo do mercado monetário representa um custo para o banco.
Fonte: Axios · 22 Oct 2026
A minha análise
Ambas as explicações podem ser verdadeiras em simultâneo, e o que está por baixo delas é mais interessante do que qualquer uma delas. Um cliente de retalho não tem forma de conceder a um agente uma autoridade limitada, pelo que entrega a credencial completa. É o problema de identidade de máquina sobre o qual escrevi em setembro: uma identidade por agente, com credenciais com âmbito definido para uma tarefa, exceto que o titular da conta não dispõe de nenhuma dessas ferramentas e o banco não consegue distinguir o seu agente de um intruso. O acesso apenas de leitura resolve metade do problema. Um agente que pode ler os seus extratos ainda os pode divulgar se for comprometido ou manipulado, e bloquear uma transferência e proteger a confidencialidade são duas funções distintas.
O SBOM não indicou o que tinha realmente sido executado.
No ISC2 Security Congress, Deepam Kanjani, gestor de segurança de produto da Atlassian, analisou uma resposta real a um incidente Shai-Hulud. O pacote malicioso estava três níveis de dependência abaixo, invisível para a análise de nível superior. Quando o incidente começou, o SBOM da equipa já estava desatualizado e não existia telemetria em tempo de execução, pelo que não foi possível determinar o que tinha sido executado em mais de 400 serviços. A sua recomendação é específica: manter os SBOMs em produção com menos de 72 horas em mais de 98 por cento dos serviços de produção, e detetar carregamentos de módulos desconhecidos em tempo de execução.
Fonte: Dark Reading · J. Vijayan, 27 Oct 2026
A minha análise
Já disse duas vezes este ano que o SBOM deve ser tratado como um inventário vivo e não como um artefacto de auditoria. Aqui está o número que não tinha. Setenta e duas horas. Se o seu for gerado no momento da compilação e o último lançamento foi em setembro, descreve um sistema que já não está em execução. E repare qual das metades está a faltar em quase todo o lado. A lista de materiais regista o que foi entregue. Ninguém está a monitorizar o que foi carregado. Durante um incidente, as únicas duas perguntas relevantes são o que foi executado e onde chegou, e uma lista de dependências não responde a nenhuma delas.
As passkeys fecham o problema das palavras-passe. Não fecham a identidade.
Uma ressalva primeiro: este ponto é uma coluna de opinião de um especialista do lado do fornecedor, não uma notícia. O argumento é válido na mesma. As passkeys eliminam o segredo reutilizável e resistem ao phishing, o que fecha a maior parte da superfície de ataque às credenciais. O que não tocam é tudo o que rodeia o autenticador: se a conta foi legitimamente criada em primeiro lugar, o que acontece quando um dispositivo muda, o que o caminho de recuperação aceita como prova, e se uma sessão pode ser sequestrada após um início de sessão completamente limpo. À medida que as organizações eliminam palavras-passe, os atacantes movem-se para essas margens.
Fonte: SecurityWeek · T. George, expert column, 30 Oct 2026
A minha análise
Já viu a versão concreta disto duas vezes. Em agosto, um kit de phishing que inscreveu a sua própria passkey na conta da vítima e sobreviveu ao reposicionamento da palavra-passe. No mês passado, um fornecedor externo de MFA desonesto que satisfez a verificação enquanto o segundo fator nunca aconteceu de facto. Nenhum deles atacou a criptografia. Ambos foram diretamente para a inscrição e recuperação. Por isso, implemente passkeys; continuam a ser a decisão certa. Depois responda às duas perguntas que decidem se resistem: quem tem permissão para inscrever uma passkey numa conta, e o que é que o seu service desk aceita como prova quando alguém liga a dizer que perdeu o dispositivo.
O seu SOC quer todos os logs para sempre. O seu DPO quer seis meses.
Escrevi sobre isto esta semana. Quando o PHP2Shell se tornou público a 21 de outubro, a equipa de inteligência de ameaças da Amazon disse aos responsáveis pela resposta para investigar a partir de pelo menos 17 de outubro, quatro dias antes. Se os logs do seu servidor web rodarem semanalmente, nunca saberá se foi afetado antes de qualquer anúncio público. Pergunte ao seu data protection officer quanto tempo guardar esses mesmos logs e obterá uma resposta diferente, porque estão repletos de endereços, identificadores e, por vezes, corpos completos de pedidos. Cinco fontes regulatórias fornecem cinco números diferentes, e nenhuma delas fornece um número universal.
Fonte: My full breakdown · cyberacademy.net
A minha análise
O que as cinco pedem em alternativa é a mesma coisa: um período ligado a uma finalidade, documentado com uma justificação. O erro habitual é definir a retenção por ferramenta, porque "o SIEM guarda 90 dias" é uma decisão de licenciamento disfarçada de medida de segurança. Em vez disso, defina por finalidade: deteção, investigação, responsabilização por acessos privilegiados, prazo legal mínimo, e deixe ganhar o mais exigente que consiga efetivamente justificar. Depois utilize os dois controlos que ninguém toca: registe o evento sem o registo em si, e classifique o armazenamento por níveis para que menos pessoas consigam aceder aos dados mais antigos. Um padrão que vejo em quase todas as auditorias que realizo: o DPO nunca foi consultado. O artigo 38 indica que deveria ter sido.
Uma falha com pontuação de 2.7 desligou os logs, e ninguém a teria corrigido.
A Broadcom atribui ao CVE-2026-41709 uma pontuação de 2.7 em 10. Trata-se de uma falha de registo insuficiente no VMware ESX que permite a alguém que já detém acesso de administrador num host executar determinadas operações sem que estas apareçam nos logs. A 28 de outubro, a CrowdStrike revelou que o grupo ligado à China Warp Panda o tinha utilizado como zero-day no início de 2026, durante intrusões de espionagem contra escritórios de advogados norte-americanos, especificamente para reduzir o que o registo de auditoria mostraria. A Broadcom disponibilizou uma correção a 29 de julho. A CISA adicionou-o ao catálogo de vulnerabilidades exploradas conhecidas no mesmo dia em que a CrowdStrike publicou, com um prazo federal de 11 de novembro.
Fonte: CrowdStrike · 2026 Legal Threat Landscape Report, 28 Oct 2026
A minha análise
Leia este ponto em conjunto com o anterior e o par constitui o problema completo. Pode calibrar a retenção com precisão, consultar o seu DPO, documentar a finalidade e o período, e ainda assim ficar cego, porque alguém desligou a gravação por baixo de si ao nível do hypervisor. Depois veja o que o seu próprio processo teria feito com isso. Uma pontuação de 2.7 fica abaixo do limiar da maioria das políticas de correção, pelo que nunca teria entrado na fila. A Broadcom corrigiu em julho e nada se moveu até um relatório de inteligência de ameaças identificar o grupo três meses depois. Vale a pena uma verificação adicional: as fontes públicas nem sequer concordam na pontuação, e algumas listam-na como 7.6. Uma diferença de cinco pontos no mesmo CVE decide se a sua política alguma vez o deteta.