Resumo: IA auto-alojada para segurança do lado do cliente
- APIs de terceiros vazam: A prática padrão da indústria para IA em ferramentas de segurança é enviar as cargas úteis para a API de um modelo de terceiros, mas isso entrega discretamente o conteúdo dos scripts a um fornecedor cujas políticas de tratamento de dados se reescrevem sem consultar primeiro a sua equipa de GRC.
- Auto-alojado desde o dia um: A cside foi lançada em maio de 2024 como o primeiro produto de segurança do lado do cliente construído com LLMs no seu núcleo, executando modelos open source na sua própria cloud, de forma a que o conteúdo dos scripts nunca saia de infraestrutura controlada e nada entre num conjunto de treino.
- Em que infraestrutura corre: Antes da sua próxima revisão da política de IA, decida se analisar JavaScript ofuscado em páginas de pagamento, a par da automação dos Requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1, é uma tarefa que deve ficar a cargo do modelo partilhado de outra empresa ou de infraestrutura que responde perante si.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
Resumo
Em maio de 2024, a cside foi lançada como a primeira solução de segurança do lado do cliente a integrar IA no seu produto.
Utilizamos modelos open source auto-alojados na nossa própria infraestrutura para analisar JavaScript à procura de intenções maliciosas. Explicamos o comportamento dos scripts em linguagem simples, acompanhamos as alterações ao longo do tempo e automatizamos as revisões de conformidade de scripts do PCI DSS 4.0.1.
Ao contrário das soluções que recorrem a APIs de IA de terceiros, a nossa arquitetura evita a fuga de dados e protege a privacidade dos utilizadores finais através da utilização de LLMs open source auto-alojados. Para organizações com restrições em relação à IA, estas funcionalidades podem ser desativadas. A IA é uma camada adicional, não um requisito, mas tem-se revelado valiosa para as equipas de GRC e de segurança.
A segurança do lado do cliente na era da IA
Quando lançámos a cside em maio de 2024, queríamos detetar ataques que outros não detetavam. Por isso, tomámos uma decisão que nos distinguiu de todos os outros intervenientes no espaço da segurança do lado do cliente: integrámos a IA no núcleo do nosso produto desde o primeiro dia.
Na altura, éramos o único fornecedor de soluções a utilizar LLMs para lidar com a segurança de JavaScript do lado do cliente. Mais tarde, o resto do mercado seguiu o nosso exemplo, mas a forma como se implementa a IA é tão importante quanto a funcionalidade que ela proporciona.
Porque é que a IA é importante para a segurança do JavaScript
O JavaScript é particularmente difícil de analisar. Os fornecedores de soluções SAST também utilizam LLMs para analisar código. Mas os scripts do lado do cliente mudam constantemente, são ofuscados de forma propositada e podem comportar-se de forma diferente com base em quem os está a ver, onde estão localizados ou a que hora é.
A correspondência de padrões tradicional falha quando os atacantes tornam o seu código aleatório ou visam utilizadores específicos.
Ao contrário dos sistemas operativos, os navegadores não foram concebidos para a segurança. É por isso que a cside oferece várias abordagens para cobrir as lacunas:
- Método Script (o mais fácil): verificamos os comportamentos dos scripts no navegador e obtemos os scripts do nosso lado, confirmando depois que recebemos o mesmo script. O tráfego do seu site nunca passa pela cside. Fácil de implementar, sem impacto no desempenho, e continua a poder interromper ações de scripts ou bloquear por URL, hash ou domínio.
- Método Scan (o mais rápido): se não conseguir adicionar um script ao seu site, a cside analisa-o utilizando threat intelligence de milhares de outros sites com biliões de visitantes combinados. Rápido de configurar e útil quando a instalação de scripts não é possível.
A combinação destes modos aproxima-nos o máximo possível da cobertura total tecnicamente viável atualmente.
Os LLMs são muito bons a contextualizar JavaScript, mesmo quando este foi deturpado até se tornar irreconhecível. Um LLM consegue analisar código ofuscado, entender a sua intenção e assinalar comportamentos que a análise estática deixaria completamente passar. Essa capacidade é valiosa para a segurança do JavaScript, mas apenas se for implementada de forma responsável.
Arquitetura de IA responsável: porque nos auto-alojamos
A cside executa LLMs open source na sua própria infraestrutura de cloud. Mantemos controlo total sobre os dados que fluem através dos nossos modelos.
Muitas vezes, quando as empresas lançam funcionalidades com IA, optam por predefinição por utilizar APIs de empresas de IA conhecidas. Embora essas empresas disponham de funcionalidades que impedem que os dados sejam usados em treino sem consentimento, os dados são, ainda assim, fornecidos a terceiros. Num mundo ideal, os dados nunca saem da sua área de controlo.
Ao executarmos nós próprios modelos open source, não há risco de o conteúdo dos scripts ser fugido para fornecedores externos. Não há hipótese de os dados de clientes aparecerem num conjunto de treino.
Ao enviar JavaScript para uma API de terceiros, está a confiar nas políticas de tratamento de dados desse fornecedor, que mudam ativamente ao longo do tempo.
A cside entende os requisitos de segurança e o que é necessário para manter os seus dados seguros. Pode verificar a nossa postura de segurança por si próprio no nosso Trust Center, onde publicamos a nossa documentação SOC 2 Type II, testes de intrusão e PCI DSS AOC.
Como a cside utiliza a IA: 4 aplicações principais
Eis onde a IA funciona efetivamente no nosso produto.
1. Análise de scripts para detetar intenções maliciosas
Todos os scripts carregados no seu site são analisados tanto na forma original como após a desofuscação. O LLM procura padrões que indiquem comportamentos maliciosos:
- Roubo de tokens de sessão
- Interceção e exfiltração não autorizadas de dados
- Recolha de credenciais
- Adulteração de formulários de pagamento
Isto aplica-se tanto a scripts com aparência inofensiva como a outros mais alarmantes. Seja no bloco de JavaScript principal ou num pequeno pedido secundário.
A IA deteta ambos os casos. Entende o contexto de uma forma que as deteções baseadas em regex simplesmente não conseguem. E, ao contrário de scanners, CSP ou produtos baseados em agentes, estamos a analisar a carga útil real que os seus utilizadores recebem: sabemos que é exatamente o que o utilizador obteve. Não estamos apenas a verificar informações de threat feeds ou a esperar que armadilhas do lado do cliente sejam acionadas, embora, claro, também utilizemos esses métodos como camadas no nosso motor de deteção.
A camada de IA no nosso motor de deteção é apenas uma de muitas camadas diferentes, mas a IA pode ser altamente eficaz na deteção de comportamentos maliciosos ocultos.
2. Raciocínio de negócio sobre scripts
- Este widget de chat deve ter acesso aos dados do formulário?
- Por que motivo este script de análise está na sua página de pagamento?
- Esta ferramenta de marketing precisa de ser executada como parte do processo de checkout?
Fornecemos um motivo de negócio gerado pelo LLM, o que constitui um requisito de conformidade em algumas normas.
Isto poupa às equipas horas de investigação: em vez de revisar cada alteração de hash de um script ou tentar descobrir quem o adicionou, obtém uma explicação em linguagem simples do que cada script está a fazer.
3. Explicação das alterações ao longo do tempo
Os scripts não permanecem estáticos. Muitos são atualizados constantemente. Na semana passada, o script X realizava ações relacionadas com análise de dados. Esta semana, também está a aceder ao localStorage e a fazer pedidos para um novo domínio registado que aponta para um endereço IP residencial.
O que mudou, e isso importa?
A IA da cside gera explicações compreensíveis para as alterações dos scripts. Não precisa de ser um investigador de segurança para entender o que aconteceu entre as alterações. A plataforma diz-lhe exatamente o que é diferente e se isso levanta preocupações.
Isto é muito útil para auditorias de conformidade. Quando um auditor pergunta sobre o comportamento de um script nos últimos seis meses, tem à disposição explicações documentadas e datadas. A nossa monitorização histórica a 100% significa que nada se perde.
4. IA para automação da conformidade com o PCI DSS 4.0.1
Os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 exigem a revisão contínua dos scripts nas páginas de pagamento. A maioria das equipas trata disto manualmente: carregando a página, inspecionando os scripts, documentando tudo e repetindo o processo semanal ou mensalmente.
Com o PCI Shield, a IA faz a revisão automaticamente. Todas as alterações de scripts nas páginas de pagamento são analisadas. Se a alteração parecer benigna, não é necessária qualquer ação. Se apresentar sinais de comportamento malicioso, recebe um alerta com uma análise completa do que aconteceu.
Esta abordagem foi validada pela VikingCloud, que confirmou que a cside cumpre os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 quando implementada corretamente. Pode ler o relatório completo ou descarregá-lo a partir do nosso Trust Center.
Isto é mais do que conveniência: é a diferença entre uma resposta reativa a incidentes e uma prevenção proativa de ameaças.
A flexibilidade é a resposta
Compreendemos que nem todas as organizações estão prontas para adotar a IA em toda a sua stack tecnológica. Algumas têm políticas internas contra a utilização de IA. Outras preferem avaliar caso a caso.
É por isso que todas as nossas funcionalidades de IA podem ser desativadas. A camada está disponível se a quiser utilizar, mas não é obrigatória para executar a cside.
Continua a ter visibilidade total da carga útil, bloqueio em tempo real, monitorização histórica e relatórios de conformidade sem IA.
Quer esteja a utilizar o Método Script ou o Método Scan, a plataforma proporciona visibilidade completa dos scripts e uma conceção fail-open. A IA é um complemento e, para as equipas que a podem utilizar, a camada de IA torna tudo mais rápido e mais preciso.
Porque é que isto é importante agora
Os ataques do lado do cliente estão a tornar-se mais sofisticados. Os atacantes sabem que o lado do servidor e as suas dependências open source estáticas estão a ser cuidadosamente monitorizadas. Por isso, ajustaram a sua superfície de ataque e estão a:
- Utilizar scripts dinâmicos do lado do cliente que mudam com base no contexto do utilizador, evitando a deteção por análises estáticas.
- Ofuscar fortemente os scripts para evitar a análise estática.
- Explorar a lacuna entre o que a especificação do navegador permite e a forma como o navegador é efetivamente construído.
As ferramentas de verificação superficial não conseguem acompanhar este ritmo. As violações de CSP não revelam o que está dentro de um script e são difíceis de gerir. Os crawlers recebem cargas úteis limpas, enquanto os utilizadores reais veem cargas maliciosas. A monitorização comportamental só deteta ataques depois de estes já terem sido executados e é vulnerável a métodos de contorno.
A deteção baseada em IA, combinada com outros métodos, é a que tem melhores probabilidades: analisa o comportamento em tempo real, entende código ofuscado mesmo quando a desofuscação falha e assinala anomalias que a correspondência de padrões deixaria passar.
Modelos auto-alojados, infraestrutura isolada e nenhuma partilha de dados com terceiros. É assim que se obtêm os benefícios da IA sem introduzir novos riscos ou enfrentar resistência interna.
Pronto para conhecer a cside? Comece gratuitamente ou agende uma demonstração para conversar com a nossa equipa.
