API security starts with API discovery

Because continuous discovery sees changes as they happen, it’s natural to group APIs based on their life cycle and level of support. Most organizations find these common groups to be a good starting point:

• “Rogue” or “unmanaged” APIs are actively being used, but have not been reviewed or approved by the security team.
• “Prohibited” or “banned” APIs have been reviewed by the security team, and are not approved for use inside the organization or from its supply chain.
• “Monitored” or “supported” APIs are actively maintained by the organization and supervised by the security team.
• “Deprecated” or “zombie” APIs were supported by the organization in the past, but newer versions exist that API consumers should use instead.

Quantifying API risks

When the organization has an API inventory that is kept reliably in sync with its runtime APIs, the final discovery challenge is how to prioritize APIs relative to each other. Given that every security team has finite resources, risk scoring helps focus time and energy on remediations that will have the greatest benefit.

There is no standard way to calculate risk for API calls, but the best approaches are holistic. Threats can arise from outside or inside the organization, via the supply chain, or by attackers who either sign up as paying customers, or take over valid user accounts to stage an attack. Perimeter security products tend to focus on the API request alone, but inspecting API requests and responses together gives insight into additional risks related to security, quality, conformance, and business operations.