TL;DR: critérios de compra de segurança do lado do cliente para instituições financeiras
- As instituições financeiras são alvos de estados-nação, pelo que uma ferramenta client-side de camada única não é uma postura de segurança, é apenas uma caixa de verificação de conformidade. Os agentes maliciosos analisam especificamente os mecanismos de proteção para os contornar.
- A cside combina a instrumentação de scripts em tempo de execução com verificações outside-in e um endpoint CSP, possui as certificações SOC 2 Tipo 2 e PCI DSS SAQ-D, e a sua equipa contribui para o W3C, o IETF e o TC39, em vez de acrescentar o lado do cliente como uma funcionalidade secundária de um WAF.
- Se o teu modelo de risco trata um painel de scanner como cobertura, um atacante direcionado vai transformá-lo num honeypot. Se procuras camadas sobrepostas que resistam a tentativas de bypass em tempo real, esta é a solução certa.
TL;DR:
- Dada a sensibilidade à conformidade, os melhores fornecedores para instituições financeiras têm de ter certificações SOC2 Tipo 2, PCI DSS SAQ-D e muito mais.
- As instituições financeiras são alvos de estados-nação para agentes maliciosos. Por isso, os melhores fornecedores de segurança para este setor investem para estar na vanguarda da capacidade técnica. Bom o suficiente não é suficiente. Um indicador da atitude correta em relação à vanguarda é a contribuição para organizações de normalização como o W3C, o IETF e o TC39.
- A segurança está na estratificação: um fornecedor que oferece um modelo de segurança multicamadas ajuda as empresas a manterem-se seguras quando agentes maliciosos tentam construir formas de contornar as camadas de segurança.
- Conclusão: a melhor solução para as instituições financeiras é a abordagem multicamadas da cside.
O que é a segurança do lado do cliente?
A segurança do lado do cliente é a prática de proteger as dependências de JavaScript, os dados dos utilizadores e os comportamentos executados dentro do navegador do visitante.
Isto inclui:
- Scripts próprios: ficheiros JavaScript carregados a partir do teu próprio domínio
- Scripts de terceiros: de ferramentas de analytics, anúncios, chatbots, gestores de tags, ferramentas de testes A/B
- Scripts inline, conteúdo incorporado como widgets e SDKs
- Dados processados ou obtidos pelo navegador
Tudo o que acontece depois da resposta HTML inicial do servidor web é uma ação do lado do cliente. Os atacantes usam cada vez mais o navegador para executar ações maliciosas na tentativa de obter informações sensíveis. Quando os dados são obtidos a partir de um domínio de terceiros, os scripts servem frequentemente conteúdo diferente consoante o IP, os cabeçalhos do pedido, a hora do dia, a localização, etc.
Por exemplo: uma ferramenta de marketing recolhe dados diferentes na Europa e nos EUA, para cumprir os requisitos de privacidade de dados.
Especialmente para alvos de alto valor, usar um pedido do lado do cliente para injetar uma carga maliciosa é uma ação comum, porque é muito mais difícil de detetar e o agente malicioso pode passar despercebido durante muito tempo, a menos que esteja a ser usada uma solução de segurança em tempo de execução do lado do cliente.
Por que é que as instituições financeiras são classificadas como alvos de estados-nação?
Alguns agentes maliciosos não procuram apenas ganhar dinheiro rápido. Podem ser patrocinados pelo Estado, incentivados a causar estragos e a desestabilizar os serviços essenciais necessários ao funcionamento das economias.
As instituições financeiras são um alvo privilegiado e, com a sua dimensão e exposição, surge um risco adicional e, portanto, uma oportunidade para os agentes maliciosos. Quando os bancos caem, a economia cai com eles.
As instituições financeiras estão no mesmo patamar dos ambientes de TI governamentais, dos grandes prestadores de cuidados de saúde e das infraestruturas críticas, como os transportes públicos e os fornecedores de energia.
Para construir credibilidade no setor financeiro, as marcas passam por um processo significativo de vários anos para obter a confiança de clientes de vários tipos. Com isso vem uma dívida técnica significativa, resultante de aplicações legadas.
Infraestruturas vastas e legadas aumentam a superfície de ataque
Não é segredo do setor que muitas das grandes instituições financeiras ainda funcionam sobre COBOL. Um artigo de investigação escrito por um membro da equipa técnica da PayPal descreve o problema com muita clareza: "A infraestrutura bancária tradicional está frequentemente desatualizada e tem dificuldade em satisfazer as crescentes exigências de serviços digitais contínuos e em tempo real."
Isto significa que as aplicações web legadas são frequentemente sobrepostas por tecnologias mais modernas, o que aumenta a superfície de ataque necessária para lançar novas experiências de utilizador. Ao explorarem back-ends vulneráveis para injetar scripts do lado do cliente ou ao visarem dependências legadas para se infiltrarem na cadeia de fornecimento, os agentes maliciosos podem causar danos graves às economias globais.
Os ataques do lado do cliente visam ativos específicos
Os ataques do lado do cliente contra instituições financeiras visam geralmente:
- Credenciais de utilizador e tokens de sessão, para obter acesso às contas
- Informações de cartões de pagamento
- Extratos bancários e informações de identidade sensíveis
Requisitos regulatórios e de conformidade rigorosos
As instituições financeiras estão sujeitas a uma lista substancial de estruturas de conformidade para poderem operar; a sua licença bancária depende dessa conformidade. Isto vai desde o cumprimento do PCI DSS, DORA, leis de privacidade locais como a CCPA ou o RGPD, até certificações que são um sinal de confiança mas muitas vezes um requisito para clientes empresariais: SOC2 Tipo 2, ISO 27001…
Qual é a melhor abordagem para as instituições financeiras?
Dada a gravidade do alvo, há pouca margem para erros. Por isso, uma boa solução tem de se ajustar à aplicação como uma luva.
Por isso, uma abordagem em camadas é ideal. Especialmente se a solução em questão for personalizável e criar transparência e controlo onde antes faltava controlo.
Foi por isso que construímos a cside como uma plataforma que aproveita todas as camadas disponíveis até à data.
A cside oferece dois métodos de implementação complementares, combinados com múltiplos motores de deteção, incluindo modelos de linguagem de grande dimensão de código aberto para análise.
- Método de Script (o mais fácil): verificamos os comportamentos dos scripts no navegador e obtemos os scripts do nosso lado, depois confirmamos que recebemos o mesmo script. Não nos colocamos no caminho de um script, a menos que o peças explicitamente. Fácil de implementar, sem impacto no desempenho, e continuas a poder interromper ações de scripts ou bloquear por URL, hash ou domínio.
- Método de Verificação (o mais rápido): se não puderes adicionar um script ao teu site, a cside analisa-o usando informações sobre ameaças recolhidas de milhares de outros sites, com milhares de milhões de visitantes combinados. Rápido de configurar e útil quando a instalação de um script não é possível.
Também oferecemos um endpoint de Content Security Policy, para que os clientes possam sobrepor a aplicação nativa do navegador à deteção baseada em JavaScript da cside.
A segurança requer um modelo multicamadas
A maioria das ferramentas de segurança depende apenas de uma das camadas acima mencionadas, seja em tempo de execução, seja em verificação externa ("outside-in"). Mas o problema é que nenhuma destas camadas, isoladamente, é totalmente à prova de falhas e, por isso, não consegue fornecer uma cobertura abrangente. Ao combinar motores, aproximamo-nos cada vez mais da cobertura total.
Muitas soluções no mercado são funcionalidades secundárias de empresas maiores de segurança web. Em vez de construírem uma plataforma para segurança do lado do cliente, construíram uma pequena funcionalidade secundária. Estas soluções estão limitadas pelo foco do negócio. Frequentemente, o lado do cliente é uma área em que não estão dispostos a investir recursos substanciais e, por isso, dependem apenas da injeção de Content Security Policies no site através do seu WAF.
Algumas soluções são, na prática, apenas scanners. Os agentes maliciosos veem os scanners e não servem os scripts maliciosos durante essas verificações pontuais. Dado o valor do alvo, esta abordagem é ineficaz.
Para efeitos de conformidade, é conveniente que a solução ofereça painéis específicos para cada estrutura normativa. As estruturas normativas trazem consigo uma variedade de controlos próprios, e recolher esses dados manualmente é uma tarefa contínua e penosa.
As soluções baseadas em scanners são frequentemente contornadas por agentes maliciosos. Estes detetam o scanner e servem-lhe conteúdo limpo, para passarem despercebidos. Investigadores da ISACA, da Universidade de Brighton, da Google e da Oracle assinalaram que os scripts dinâmicos do lado do cliente contornam eficazmente a análise estática realizada pelos scanners.
A cside está sempre à procura de expandir as suas capacidades e promove ativamente vários novos padrões que permitiriam uma segurança do lado do cliente mais forte, usando funcionalidades nativas do navegador.
A equipa da cside contribui ativamente para organismos de normalização como o W3C, o IETF e o TC39.
Pronto para conheceres a cside? Começa gratuitamente ou marca uma demonstração para conversares com a nossa equipa.
