Como a descoberta contínua vê as mudanças conforme elas acontecem, é natural agrupar APIs com base em seu ciclo de vida e nível de suporte. A maioria das organizações acha que esses grupos comuns são um bom ponto de partida:
- APIs “não autorizadas” ou “não gerenciadas” estão sendo usadas ativamente, mas não foram revisadas ou aprovadas pela equipe de segurança.
- APIs “proibidas” ou “banidas” foram revisadas pela equipe de segurança e não foram aprovadas para uso dentro da organização ou de sua cadeia de suprimentos.
- APIs “monitoradas” ou “com suporte” são mantidas ativamente pela organização e supervisionadas pela equipe de segurança.
- APIs “obsoletas” ou “zumbis” foram suportadas pela organização no passado, mas existem versões mais recentes que os consumidores de API devem usar.
Quantificação de riscos de API
Quando a organização tem um inventário de API que é mantido de forma confiável em sincronia com suas APIs de tempo de execução, o desafio final da descoberta é como priorizar as APIs em relação umas às outras. Dado que cada equipe de segurança tem recursos finitos, a pontuação de risco ajuda a concentrar tempo e energia em remediações que terão o maior benefício.
Não há uma maneira padrão de calcular o risco para chamadas de API, mas as melhores abordagens são holísticas. Ameaças podem surgir de fora ou de dentro da organização, por meio da cadeia de suprimentos ou por invasores que se inscrevem como clientes pagantes ou assumem contas de usuários válidas para encenar um ataque. Os produtos de segurança de perímetro tendem a se concentrar apenas na solicitação de API, mas inspecionar solicitações e respostas de API em conjunto fornece insights sobre riscos adicionais relacionados à segurança, qualidade, conformidade e operações comerciais.
