A tecnologia continua avançando em um ritmo sem precedentes. O desenvolvimento e uso de Application Programming Interfaces (APIs) é um exemplo particularmente notável.
O mais recente Relatório de segurança da API do Salt Labs constatou que o tráfego geral da API aumentou 168% em 12 meses, com o tráfego de ataque da API aumentando 117% no mesmo período. Talvez compreensivelmente, muitos CISOs estão lutando para acompanhar.
De acordo com o mesmo relatório, 94% das organizações sofreram um incidente de segurança de API ao longo de 12 meses. Incluídos neste agrupamento, estão nomes conhecidos como Experian, Peloton e Starbucks. Até mesmo a Lego teve uma chance, corrigindo uma vulnerabilidade de API potencialmente catastrófica no final do ano passado. Grandes empresas, com grandes orçamentos de segurança, sempre sofrem com incidentes de segurança de API. Claramente, as técnicas tradicionais de segurança de aplicativos simplesmente não são suficientes quando se trata de proteger APIs.
Com isso em mente, conversamos com Yaniv Balmas, vice-presidente de pesquisa da Salt Security para esclarecer algumas das perguntas mais frequentes sobre segurança de API.
BN: A arquitetura de confiança zero pode proteger APIs?
YB: Infelizmente, muitos riscos de API não podem ser mitigados por confiança zero. O objetivo da confiança zero é restringir o acesso, enquanto as APIs precisam de acesso para funcionar. A maioria das APIs são públicas ou abertas, projetadas para serem consumidas pela internet como um todo e uma grande base de clientes, apresentando desafios únicos para confiança zero.
Além disso, os ataques de API geralmente ocorrem em canais confiáveis e sessões autenticadas. Os invasores sabem que, se conseguirem obter as chaves ou credenciais de um usuário autorizado, poderão acessar dados valiosos. Pegando carona ou sequestrando sessões autenticadas com cookies de sessão ativa roubados, tokens de autenticação, desafios de autenticação de dois fatores, chaves de API e outros materiais de autenticação, os hackers não são prejudicados pela arquitetura de confiança zero. Lembre-se de que, de acordo com o relatório State of API Security, impressionantes 94% das explorações ocorrem contra APIs autenticadas.
Quando se trata de confiança zero, as organizações devem ir além dos princípios de autenticação e autorização. Eles exigem proteção de tempo de execução da API para validar continuamente o acesso e os comportamentos de um usuário autorizado em relação aos recursos da API, identificar as anomalias e identificar os agentes mal-intencionados.
BN: As ofertas de segurança em nuvem podem proteger as APIs?
YB: Embora alguns provedores de segurança em nuvem forneçam ferramentas como gerenciamento de API ou gateways de API, produtos pontuais como esses não são suficientes para proteger empresas contra ataques de API. Essas ferramentas têm recursos de segurança de API limitados tanto no aplicativo quanto na camada de API, deixando as APIs desprotegidas. Os ataques de API são efetivamente explorações de dia zero, o que significa que as ferramentas de segurança projetadas para procurar comportamentos”ruins”conhecidos-assinaturas ou IPs na lista negra, por exemplo-nunca serão capazes de proteger adequadamente as APIs. Também vale a pena notar aqui que, como as APIs são lógicas de aplicativos, os clientes da nuvem têm a responsabilidade final de protegê-los dentro do modelo de responsabilidade compartilhada para segurança.
BN: Por que IAM, WAFs ou API não podem gateways protegem APIs?
YB: Embora IAM, WAFs e gateways de API sejam ferramentas necessárias e importantes na pilha de segurança de todas as organizações, eles ficam aquém de proteger APIs-principalmente porque não protegem fornecem a visibilidade necessária ou os controles de segurança.
Os invasores contornam consistentemente os controles de acesso, bem como coletam chaves e tokens. Os hackers contemporâneos são especialistas em contornar os controles de acesso, pegando carona em uma sessão de usuário autenticado ou coletando material de autenticação do tráfego, armazenamento do dispositivo ou código do aplicativo Essas técnicas de ataque não podem ser detectadas por soluções IAM, API ou WAF.
Essas ferramentas também falham na detecção de problemas específicos de API-abuso de lógica de negócios e explorações de autorização, por exemplo-porque dependem de assinaturas e regras para detecção de ataques. Para piorar a situação, os componentes de gerenciamento de API inerentes a eles também podem ser exploráveis.
Além disso, IAM, WAFs e gateways de API dependem de proxy. Como os modelos de proxy retardam a comunicação da API, as organizações geralmente falham em mediar todas as APIs em uso com um gateway ou WAF, especialmente para APIs internas ou internas. Isso resulta em falta de visibilidade de como essas APIs estão sendo usadas.
BN: As APIs podem ser protegidas com proteção de carga de trabalho?
YB: Segurança da carga de trabalho As proteções fornecem muitos benefícios. Entre outras coisas, eles ajudam a fornecer segurança de infraestrutura para garantir que você não esteja executando cargas de trabalho em versões de software vulneráveis e também são úteis para bloquear o acesso a uma carga de trabalho para usuários externos. No entanto, eles ficam aquém de fornecer API ou contexto de nível de aplicativo, falhando, portanto, em proteger as próprias APIs.
BN: Qual é a eficácia do shift-left para proteger APIs?
YB: Embora a implementação da segurança no estágio de desenvolvimento seja uma prática válida, o suporte shift-left não significa que todas as APIs serão protegidas na pré-produção. As ferramentas de teste do desenvolvedor simplesmente não conseguem identificar todas as vulnerabilidades. Muitos problemas comuns de segurança de API não podem ser identificados como parte de verificações automatizadas de projeto, desenvolvimento e construção com análise de segurança comum e ferramentas de teste–falhas de lógica de negócios não podem ser detectadas a menos que as APIs sejam exercidas.
Crédito da foto: Panchenko Vladimir/Shutterstock