Relatório FireTail descobre que as violações de segurança da API são poucas, mas letais

Notícias

LarLar / Notícias / Relatório FireTail descobre que as violações de segurança da API são poucas, mas letais

Apr 28, 2023

Relatório FireTail descobre que as violações de segurança da API são poucas, mas letais

Home » Security Boulevard (Original) » Relatório FireTail encontra segurança de API

Home » Security Boulevard (Original) » Relatório FireTail descobre que as violações de segurança da API são poucas, mas letais

Uma análise de violações de segurança cibernética em 2022 conduzida pela FireTail, fornecedora de uma plataforma para proteger interfaces de programação de aplicativos (APIs), encontrou apenas 12 violações registradas publicamente envolvendo APIs, com mais seis sendo divulgadas até agora em 2023.

No entanto, o tamanho médio médio da exposição de violação de dados da API é superior a 10 milhões de registros por incidente. Com o custo total de um único registro violado sendo de US$ 180, o custo total das violações de segurança da API facilmente pode chegar a US$ 85 bilhões, segundo o relatório.

As duas principais categorias de violações de dados envolvendo segurança de API são autorização em 135 milhões de registros, ou 28% de todos os registros violados, e autenticação, em 105 milhões de registros, ou 22% de todos os registros violados.

O CEO da FireTail, Jeremy Snyder, disse que, com mais de 85% do tráfego da Internet passando por APIs, agora é apenas uma questão de tempo até que o número de violações de segurança da API e o custo total aumentem. Infelizmente, o nível de foco na segurança da API não é compatível com o risco potencial para os negócios, acrescentou.

Além disso, o nível de especialização em segurança de API disponível permanece limitado. Por exemplo, uma consideração frequentemente negligenciada no processo de autenticação é a necessidade de validar credenciais de autenticação repetidamente e vincular credenciais a uma sessão ativa. Credenciais de longa duração, como chaves de API estáticas, estão sujeitas à proliferação de segredos. Alguns mecanismos de autenticação comuns podem até introduzir vulnerabilidades nas APIs.

Como tal, é importante que as APIs sejam projetadas para forçar a autenticação regularmente, em vez de apenas verificar se um token está em conformidade com o formato esperado.

Nem sempre está claro quem é o responsável pela segurança da API. Mas como os cibercriminosos apreciam a quantidade de dados que podem ser extraídos por meio de uma API, há claramente uma necessidade de mais colaboração entre as equipes de segurança cibernética encarregadas de proteger essas APIs e os desenvolvedores que as criam.

Mais desafiador ainda, o número de APIs implantadas em ambientes de produção aumentou muito, principalmente graças ao surgimento de aplicativos baseados em microsserviços que fazem uso extensivo deles. Também não é incomum que os desenvolvedores tenham implantado a chamada API zumbi que não é mais suportada, mas ainda pode ser acessada e manipulada por agentes externos de ameaças. Além disso, muitas vezes existem APIs não autorizadas que foram configuradas sem que ninguém da TI as conhecesse. O maior problema que as equipes de segurança cibernética encontrarão com as APIs é que não é possível proteger o que elas não conhecem, observou Snyder.

Em teoria, pelo menos, as equipes de desenvolvimento de aplicativos que adotam práticas de DevSecOps para criar e implantar aplicativos assumirão mais responsabilidade pela proteção de APIs, mas sempre será a equipe de segurança cibernética a responsável por qualquer violação. No entanto, historicamente, as equipes de segurança cibernética têm se concentrado mais em proteger perímetros e endpoints, portanto, a maior parte do orçamento alocado para segurança cibernética não está sendo aplicada a APIs.

Isso pode mudar nos próximos meses, à medida que as violações de API se tornarem mais comuns. Enquanto isso, as equipes de segurança cibernética devem, no mínimo, criar um inventário das APIs que conhecem e são responsáveis ​​por proteger, independentemente de quem as criou.