Laura Santeusanio
Diretor Regional para a Europa do Sul
Uma executiva internacional com mais de 20 anos de experiência na promoção do crescimento empresarial, da expansão de mercado e da transformação em toda a Europa. Diretora-geral com experiência comprovada na ampliação de operações, na formação de equipas de alto desempenho e na execução de estratégias para alcançar resultados mensuráveis.
Principais conclusões:
Uma recente violação de segurança numa empresa de fintech, amplamente divulgada, não envolveu qualquer intrusão técnica: os atacantes utilizaram uma conta de e-mail governamental comprometida para solicitar dados de clientes, e a empresa entregou-os, acreditando que o pedido era legítimo.
Segundo consta, este padrão prolongou-se durante meses antes de alguém o detetar, não porque um e-mail tenha escapado a um filtro, mas porque o próprio processo de verificação não tinha forma de detetar uma falsificação bem autenticada.
A autenticação técnica de e-mail (SPF, DKIM, DMARC) confirma que uma mensagem provém de um domínio genuíno. Não diz nada sobre se a pessoa específica que a enviou estava autorizada a fazê-lo, nem se o pedido em si é legítimo.
Vários dos detalhes mais dramáticos que ainda circulam — o volume exato de dados, o valor do resgate, há quanto tempo a conta governamental em questão estava comprometida — provêm das próprias alegações do atacante e continuam por confirmar por qualquer entidade oficial.
A solução não é um filtro de spam mais eficaz. É uma etapa de verificação documentada e obrigatória precisamente para esta categoria de pedidos, uma etapa que exista no papel e que seja efetivamente seguida mesmo sob pressão.
O que realmente aconteceu
A reconstituição dos factos que emergiu do jornalismo de investigação é simples, e é precisamente isso que a torna inquietante. Um atacante assumiu o controlo de uma conta de e-mail pertencente a um órgão governamental real. A partir dessa conta, enviou à empresa de fintech pedidos de informações sobre clientes, apresentados como exigências das autoridades policiais. Os pedidos provinham de um domínio governamental genuíno, pelo que passaram nas verificações técnicas que normalmente sinalizam a usurpação de identidade, e foram encaminhados através do processo normal da empresa para o tratamento de consultas governamentais e das autoridades policiais.
A empresa tratou os pedidos como legítimos e divulgou os dados. Posteriormente, descreveu o incidente como um esquema externo de falsificação de identidade, em vez de uma violação dos seus próprios sistemas, e essa interpretação resiste a um exame minucioso: não há provas públicas de uma intrusão na rede, e a empresa afirmou que os fundos dos clientes e os sistemas centrais nunca foram comprometidos. O que aconteceu foi, de facto, uma violação de dados pessoais e, segundo a própria definição do RGPD, isso é verdade independentemente de ter sido afetado um único servidor. A divulgação não autorizada à entidade errada constitui a violação, ponto final.
Um remetente verificado não é o mesmo que um pedido autorizado
A conclusão incómoda subjacente a este incidente é algo que a maioria das organizações ainda não teve plenamente em conta: a autenticação e a autorização são problemas distintos, e a maioria dos processos de verificação apenas verifica o primeiro.
O SPF, o DKIM e o DMARC existem para responder a uma pergunta: esta mensagem veio realmente do domínio de onde alega ter vindo? São eficazes nessa função. Não dizem nada sobre se a pessoa específica que a enviou estava autorizada a fazer este pedido em particular, se a base jurídica que invocam se aplica efetivamente, ou se o volume e a natureza do que estão a solicitar correspondem a um pedido legítimo. Uma conta comprometida dentro de um domínio governamental real passa facilmente pelas três verificações. O domínio é genuíno. A pessoa por trás dele, nesta ocasião, não é.
Os pedidos do governo e das autoridades policiais trazem consigo um tipo específico de confiança institucional que agrava esta lacuna, em vez de a resolver. Um pedido que parece oficial tende a ser processado mais rapidamente e a ser menos questionado, o que é exatamente a suposição com que um atacante conta.
O aspeto que deve preocupar mais as equipas de conformidade do que a própria violação
Um único e-mail fraudulento que consegue passar já é um dia mau. O que alegadamente aconteceu neste caso é diferente: o mesmo padrão de pedidos continuou, sem ser detetado, durante um período prolongado. Não se trata de um caso em que um e-mail tenha escapado a um filtro. Trata-se de um processo de verificação que não dispunha de qualquer mecanismo para detetar uma falsificação bem autenticada, mesmo depois de esta já ter funcionado mais do que uma vez.
A maioria das organizações pode apontar para uma política que estipula que os pedidos governamentais devem ser tratados com cuidado. Muito menos organizações conseguem demonstrar que essa política inclui um passo específico e obrigatório, como a confirmação do pedido através de um canal de contacto independente — e não aquele fornecido no próprio pedido —, antes de qualquer informação ser divulgada. Sem esse passo por escrito e efetivamente aplicado, "tratado com cuidado" transforma-se silenciosamente em "processado como qualquer outro pedido", e ninguém repara até que já tenha acontecido repetidamente.
O que está confirmado e o que ainda é apenas uma alegação
Parte de escrever sobre um incidente em tempo real de forma responsável consiste em ser honesto quanto aos detalhes que são confirmados e aos que ainda não o são. À data da redação deste artigo:
Razoavelmente bem estabelecido: Um atacante utilizou uma conta de e-mail governamental comprometida para enviar pedidos fraudulentos para obter dados de clientes. A empresa divulgou os dados em resposta a esses pedidos, acreditando que fossem legítimos. Os sistemas da própria empresa e os fundos dos clientes não foram afetados. As autoridades estão a investigar o caso.
Noticiado pelos meios de comunicação social, mas não confirmado oficialmente: o número específico de clientes afetados e qual a conta exata de uma entidade governamental que foi comprometida.
Alegado apenas pelo atacante, não verificado por qualquer entidade oficial: o volume total de dados alegadamente obtidos, o período de tempo durante o qual a conta governamental em questão terá estado comprometida e o valor do resgate exigido. As práticas de governação são claras neste ponto: as alegações do próprio autor da ameaça sobre o que possui constituem uma estratégia de marketing para a tentativa de extorsão, e não provas, até que sejam confirmadas por uma fonte independente.
O que isto significa caso a sua organização venha a receber um pedido das autoridades
Quase todas as organizações reguladas — sejam do setor dos serviços financeiros, da saúde ou das telecomunicações — dispõem de algum processo para responder a pedidos de dados por parte das autoridades policiais e governamentais, uma vez que a lei, em geral, assim o exige. A questão que este incidente levanta não é se esse processo existe. É se o processo inclui uma verificação efetiva precisamente para este cenário: um pedido que parece totalmente legítimo, mas que pode não o ser.
Um controlo razoável neste contexto deve ser específico, não genérico. Algo do tipo: antes de divulgar dados pessoais em resposta a um pedido governamental, judicial ou das autoridades, verificar de forma independente a identidade e a autoridade do requerente, a base jurídica do pedido e o seu âmbito, utilizando dados de contacto obtidos de fontes independentes, em vez dos fornecidos no próprio pedido. Os pedidos em grande volume ou invulgares devem ser obrigatoriamente revistos uma segunda vez antes de qualquer informação ser divulgada.
Por escrito, isto parece óbvio. A razão pela qual falha na prática é que raramente se encontra num local onde a equipa de receção o veja efetivamente no momento, e raramente é testado face a um pedido que pareça exatamente correto.
Veja como uma etapa de verificação como esta se enquadra no seu programa de conformidade
Apresente o seu próprio processo para lidar com pedidos de autoridades governamentais ou de aplicação da lei, por mais informal que seja atualmente. Preferimos mostrar-lhe como estruturar essa verificação do que descrevê-la de forma abstrata.
Como o Formalize dá suporte a isto
Trata-se de um problema de controlo antes de ser um problema tecnológico, e o papel do Formalize é garantir que esse controlo exista efetivamente algures, para além de um documento de política que ninguém abre quando está sob pressão. Na prática, isso significa:
Um controlo documentado para divulgações a entidades governamentais e às autoridades responsáveis pela aplicação da lei, integrado nos seus outros controlos, em vez de constar de um dossier de políticas separado, com um responsável designado.
As etapas de verificação estão integradas no fluxo de trabalho, pelo que um pedido é verificado em função de critérios definidos antes da divulgação, e não depois.
Um registo de quem aprovou uma divulgação e porquê, para que, caso um pedido venha a ser questionado posteriormente, o raciocínio já esteja disponível, em vez de ter de ser reconstruído a partir da memória.
O mesmo controlo é reutilizado em diferentes frameworks, uma vez que este tipo de risco de divulgação está relacionado com o RGPD e, muitas vezes, também se sobrepõe às obrigações previstas em frameworks como o DORA ou a ISO 27001.
Nada disso substitui o bom senso. Garante apenas que o bom senso seja aplicado de forma consistente, sempre, incluindo naquela ocasião em que é mais importante.