Em resumo
- Consolidou três ferramentas distintas — oSnyk para SCA, o Sonar para análise estática e o OWASP ZAP para varredura no momento da compilação — num único componente de códigoAikido
- Utilizei o comando « reachability analysis » numa auditoria PCI para demonstrar que as nonconformidades graves que impediam a auditoria se verificavam do lado do cliente e não eram exploráveis
- Substituí os «gates» fictícios por «gates» reais que bloqueiam resultados críticos e de alto risco antes de uma fusão ou de uma compilação
- Conquistou a confiança das equipas de engenharia que eram responsáveis pelas ferramentas anteriores
- Decidiu-se avançar com a consolidação depois de o ataque à cadeia de abastecimento Shai-Hulud ter exposto a pilha antiga
Demasiadas constatações, poucas soluções
A Reward Gateway desenvolve software de envolvimento e benefícios para colaboradores, incluindo reconhecimento, recompensas, bem-estar e descontos que as empresas utilizam para cuidar dos seus colaboradores. Fundada em Londres em 2006 e atualmente parte da Edenred, funciona como uma plataforma SaaS que processa um elevado volume de transações e dados sensíveis, o que a coloca no âmbito da norma PCI. A sua plataforma chega a mais de 10 milhões de colaboradores nas organizações dos seus clientes.
Angel Indzhov é diretor de cibersegurança na Reward Gateway, onde lidera as operações de segurança, a segurança dos produtos e a luta contra a criminalidade financeira. Ele descreve um problema que a maioria dos responsáveis pela segurança já reconhece: a deteção já não é a parte mais difícil.
«Estamos a melhorar na capacidade de identificar problemas. Não estamos a melhorar na capacidade de os resolver.»
O volume continua a aumentar, especialmente com os modelos mais recentes a gerarem mais resultados, e uma base de código antiga é muito mais difícil de corrigir do que uma totalmente nova. O que a Reward Gateway precisava não era de mais resultados. Era uma forma de saber quais eram realmente importantes.
O desafio
Uma pilha cujos elementos não funcionavam em conjunto
Antes Aikido, a equipa de segurança deparou-se com três ferramentas distintas que nunca foram concebidas para funcionar em conjunto.
«Estávamos a utilizar o Sonar para a análise estática de código, o Snyk apenas para o SCA e o OWASP ZAP nos pipelines de compilação. São tantas as ferramentas que as pessoas tentam utilizar em conjunto, mas que, na verdade, não funcionam bem juntas.»
Um ataque à cadeia de abastecimento revelou isso
A fragmentação tornou-se um verdadeiro problema quando ocorreu o ataque à cadeia de abastecimento Shai-Hulud. A estrutura existente não conseguia responder às questões importantes com a rapidez necessária.
«Quando ocorreu o incidente com o Shai-Hulud no ano passado, sentimos que as nossas ferramentas não estavam à altura das necessidades. Isso levou-nos a procurar algo novo e a consolidar-nos.»
O serviço de segurança não dispunha das ferramentas
Parte da razão pela qual a pilha estava tão fragmentada deve-se ao facto de a equipa de engenharia ter adquirido cada ferramenta para resolver um problema específico na altura. A equipa de segurança não era responsável pelo processo e o orçamento vinha de outra fonte, pelo que qualquer mudança implicava, em primeiro lugar, convencer a equipa de engenharia.
«Todo este equipamento foi adquirido pelo departamento de engenharia, por isso tivemos de os convencer. Não fazia parte do nosso orçamento.»
Por que razão a Reward Gateway escolheu Aikido
Consolidação, em etapas deliberadas
A Reward Gateway não fez a transição de tudo de uma só vez. Começou por chegar à Aikido através da Safe Chain, gostou do que viu e, em seguida, realizou uma prova de conceito completa, centrada nos aspetos mais importantes — o código e a vertente de ataque —, em vez de avançar com uma implementação em grande escala que não conseguiria concluir.
Uma disponibilidade em que a equipa pudesse confiar
A funcionalidade que fez a diferença foi o reachability analysis. Com tantos resultados, muitos dos quais de baixa prioridade, a equipa precisava de uma forma de distinguir o que podia realmente ser explorado do que não podia.
«Para mim, a resposta é a acessibilidade. Mostra o que tem realmente de acontecer para se explorar uma vulnerabilidade, pelo que se sabe qual é a vulnerabilidade que vai realmente constituir um problema. Isso foi fantástico.»
Uma equipa que respondeu rapidamente
As pessoas por trás do produto destacaram-se tanto quanto o próprio produto durante a prova de conceito.
«Não há nenhum outro fornecedor com quem tenhamos trabalhado que comunique tanto e se preocupe verdadeiramente com o que dizemos. Quando levantamos uma questão, sentamo-nos a conversar e resolvemos o problema.»
Acessibilidade na auditoria PCI
A prova mais evidente surgiu durante uma auditoria PCI. A Reward Gateway tinha valores pendentes no seu repositório de pagamentos, do tipo que têm de ser resolvidos antes de uma auditoria ser aprovada, e o prazo era apertado.
«Tivemos uma auditoria PCI e, em Snyk , detetámos picos no repositório de pagamentos que tiveram de ser corrigidos muito rapidamente, mesmo antes do prazo. A verificação de acessibilidade em Aikido revelou que se tratava de problemas do lado do cliente que não afetavam de todo o lado do servidor. Isso eliminou o risco e mostrou a todos que é isto de que precisamos.»
Essa auditoria fez mais do que apenas esclarecer as conclusões. Foi o que convenceu as equipas de engenharia que utilizavam as ferramentas antigas a adotarem o « Aikido », pois mostrou-lhes onde residia o risco real e, o que foi igualmente útil, onde não residia.
Portões que realmente impedem a passagem de coisas
A acessibilidade determinou quais as conclusões que a equipa levou em consideração. Os portões determinaram o que acontecia quando alguém os atravessava.
«Antes, tínhamos controlos fictícios. Quase nada era realmente bloqueado. Agora, tudo o que é crítico e de alto nível é bloqueado. Não é possível integrar o teu PR nem compilar.»
O próximo passo consiste em aplicar as mesmas verificações de forma consistente em todas as fases, para que uma verificação que seja ignorada numa fase seja, ainda assim, detetada noutra.
Substituição total das ferramentas de ponta
Com a acessibilidade e as portas reais já implementadas, as ferramentas separadas deixaram de ter qualquer função a desempenhar.
«Estamos a utilizar o componente de código de cima a baixo: análise estática de código, análise de segredos e licenciamento. Snyk, Sonar, OWASP ZAP; estamos a substituí-los na totalidade.»
O que o futuro reserva para a Reward Gateway
O Reward Gateway executa o componente de código do Aikido em análise estática de código, análise de segredos, análise de composição de software com verificação de acessibilidade e verificação de licenças, com mecanismos de bloqueio para resultados críticos e de alto risco.
A partir daqui, a equipa está a alargar esses controlos a mais fases do pipeline. Está a avaliar o pentest de IA, embora pretenda preparar primeiro os ambientes adequados para que os resultados sejam significativos. Assinalou a proteção de dispositivos como uma prioridade elevada após um incidente, visando diretamente a lacuna nas extensões do navegador e do IDE, onde não existe fixação de versões nem consistência em que se possa confiar. A auditoria de código do Aikido também está na lista de coisas a experimentar. Nenhuma destas medidas está ainda em funcionamento.
Veredito final
A acessibilidade proporcionou à equipa um filtro, a consolidação proporcionou-lhes um único local a partir do qual trabalhar e os controlos de acesso reais proporcionaram-lhes algo que realmente impede a execução de código arriscado.
«O objetivo é ir obtendo melhorias gradualmente, e é essa a parte que mais gosto neste produto.»
