API Security Evaluation Guide
Understanding what “good” looks like in API Security so you can mitigate API attacks
Modern applications are built on APIs, and application security practices now heavily depend on API security practices. As with any new technology, organizations don't always know how to evaluate what “good” looks like and measure what features or security controls may be most beneficial.
Any API security offering you consider should be built as a platform of capabilities and not a one-off tool, like a simple scanner. API security strategy demands a full life cycle approach since security issues, vulnerabilities, logic flaws, misconfigurations, and other challenges will arise through the stages of API design, development, delivery, and operation.
Another foundational principle is that architecture matters. Any platform you are considering should leverage cloud-scale big data to collect and store really large amounts of API telemetry, correlate API traffic, provide context, and power fast attack detection and response. The platform must also leverage AI/ML so that it can continuously extract useful, actionable signals for development, operations, and security teams.
Time-in-market is another key consideration – AI and ML algorithms need time to see hundreds of environments and learn from them as training – these data sets are enriched by the network effect, with an ever-increasing number of users and API calls. When leveraged properly, such aggregated, anonymized data benefits all consumers of the API security platform while still preserving privacy.
Based on Salt customer requirements, collective experience, and industry security best practices, we’ve defined the following design criteria and capability areas as critical for any API security offering that an organization may be considering.
Design and architecture
Any API security offering should be built with automation and cloud-scale capacity in mind. Realistically, to do so requires a cloud-native design, making use of technologies under the hood such as auto-scaling infrastructure components, cloud storage, cloud analytics, containers, and serverless technology. No API security offering that deploys as a stand-alone, on-premises service can retain enough data necessary to inform baselines, drive analysis engines, and identify anomalous API traffic that indicates potential attack, privacy impact, or other type of incident.
When considering an API security platform, verify that it exhibits the following architectural attributes:
- Environment agnostic: An API security offering should support modern and legacy technologies regardless of where they are hosted. The offering also needs to work in environments where traffic is encrypted since TLS is pushed readily as security best practice but has an unintended side effect of reduced security visibility.
- Independence from client-side code, server agents, and additional proxies: An API security offering should not require additional server agents or network proxies and should avoid the use of client-side code or controls to stop attacks.
- Cloud-scale storage and analytics: An API security offering should make use of cloud-scale storage and data analytics, oftentimes referred to more simply as Big Data, to retain enough data necessary to inform baselines of API behaviors and consumption patterns, drive analysis engines, and identify anomalous events.
- AI/ML-based analysis: An API security offering should use AI/ML to analyze all the data and telemetry that are collected, produce meaningful signals, and inform security capabilities in the offering. Machine-assisted analysis helps reduce high false positive rates that are far too common with traditional security tooling.
Learn what it takes to secure APIs, how to evaluate API security offerings, and the capabilities needed to protect your business.
Download NowAPI and sensitive data discovery
One long-standing security principle also applies to APIs: you can’t secure what you can’t see. It’s a simple concept, but maintaining an accurate API inventory is incredibly challenging for most organizations given the rate of change and distributed nature of most APIs. This is critically important when it comes to the large range of personally identifiable information (PII) and also other data types that are subject to regulation including protected health information (PHI) as defined by the Health Insurance Portability and Accountability Act (HIPAA) and cardholder data as defined by the Payment Card Industry Data Security Standard (PCI DSS).
Beyond the inventory of API count, you also need to understand the attributes of each API. While most existing scanning tools focus on IP address and host information, effective API discovery and cataloging must also include all appropriate API metadata such as API endpoints, API functions, path structures, message body structures, and more. Discovery and cataloging capabilities also provide benefits beyond just security and can help satisfy governance, compliance, and privacy requirements.
For discovery of APIs and sensitive data they expose, look for the following key capabilities:
- Continuous, automated API discovery: An API security offering should be able to automatically collect data and metadata about APIs across environment types, correlate it and organize the catalog continuously.
- Identification of shadow or undocumented APIs: An API security offering should be able to identify shadow APIs, also referred as unknown or undocumented APIs, that have flown under the radar of operations and security teams.
- Identification of zombie or out-of-date APIs: An API security offering should be able to identify zombie APIs, also referred to as outdated or deprecated APIs. Zombie API endpoints can contain buggy or vulnerable code, may expose excessive data or functionality, may no longer be monitored, and may lack production mitigations from other infrastructure.
- Identification of sensitive data: As part of the discovery functionality, an API security offering should be able to identify sensitive data types in API parameters and payloads as well as tag API endpoints appropriately. Failing to protect sensitive data can result in fees from regulatory bodies, severe brand damage, or lost customers.
- Identification of third-party API consumption: An API security offering should be able to identify third-party API consumption and distinguish it from first-party API traffic. Modern design patterns are often a spiderweb of API interconnectedness, and it is common to see direct API communication and machine identities consuming data and functionality of third-party APIs.
API attack detection
Traditional security control approaches fall short on detecting API attacks. Web application firewalls (WAFs) use a proxy architecture that sees only one transaction at a time and cannot correlate data over time. API gateways see only the APIs within their platform. Effective API attack detection requires the ability to identify attackers early in their reconnaissance phases. Platforms should also support API schema analysis for design-time detection, along with the ability to work independently of such schema. , It should also correlate anomalous API behaviors and attacker campaigns and work independently of traditional threat intelligence and malicious IP address feeds.
For complete defense, ensure the API security platform provides:
- Attacker correlation: An API security offering should be able to aggregate and correlate attack behavior per source IP address, per user ID, and per session ID. And an API security offering should also make that information readily consumable for API and security teams within the organization.
- Static metadata independence: An API security offering should not be dependent on static data sources such as threat intelligence (TI) feeds or API schema definitions.
- Behavior analysis and anomaly detection: An API security offering should be able to programmatically parse API business logic and behaviors in runtime in order to assess impacts to an organization’s API security posture and detect a wide range of API abuses where API consumption patterns deviate from the baseline, or “normal.”
- Early attacker identification: Passive analysis techniques – like reverse engineering front-end interactions with back-end APIs – typically appear as legitimate traffic. An API security offering should be able to detect subtle variations in normal consumption patterns that result from automation scripts and reverse engineering tools employed by attackers, and it should be able to do it quickly, continuously and early.
API attack prevention and blocking
Application security tooling such as static or dynamic analyzers and other forms of pre-prod scans help identify only a limited subset of API security issues and miss most business logic flaws. These tactics also cannot stop attackers from exploiting those limited API vulnerabilities they do uncover. Look for an API security offering that will stop attackers that exploit or abuse issues defined in the OWASP API Security Top 10. An ideal solution will also block malicious requests while learning and profiling and stop credential stuffing and brute force attacks as well as application-layer denial of service (DoS) attacks.
Core capabilities you should look for in an API security offering for attack prevention include:
- Stop attacks that exploit OWASP API Security Top 10 (2019) issues: An API security offering should be able to stop attackers that target the exploitable issues defined in the OWASP API Security Top 10 including those that target authentication and authorization. An offering should also be able to detect excessive data exposure, lack of resource or rate limiting, security misconfigurations, injection flaws, and mass assignment flaws.
- Block malicious requests while learning and profiling: An API security offering should be able to block or mitigate API attacks while profiling API traffic and learning the organization’s unique business logic powered by APIs, including injection-style attacks and excessive API consumption.
- Stop account takeover (ATO) attacks: An API security offering should be able to stop automated attacks like credential stuffing and brute forcing that can result in account takeover.
- Stop application-layer denial of service (DoS) attacks: An API security offering should be able analyze an organization’s APIs and API traffic to effectively prevent application-layer DoS.
API-centric incident response
While API protection is key to defending your APIs in runtime, the organization’s ability to respond in the event of an attack is just as critical. Any API security offering you consider should support basic alerting methods. More importantly, an API security offering should provide integrations with the organization’s pre-existing IT systems and workflows. Look for integrations and automation that support your already overwhelmed security operations center (SOC) analysts or augment what your managed security service provider (MSSP) is able to provide.
To enable API-centric incident response, look for the following capabilities in an API security offering:
- Intelligent ITSM, SIEM and SOAR integration: An API security offering should provide integration into commonly found IT and SecOps systems, not limited to a basic “log feed” or “data dump”. It should intelligently prioritize events, provide actionable security alerts, support the work streams of a modern SOC and IT workforce, and be able to trigger workflow within external SIEM and SOAR offerings and external ITSM for ticketing.
- Customizable response actions: Rather than depending on a native integration, an API security offering should provide APIs or webhooks to integrate with a wider range of external IT systems. Integration should support customizable response actions, and complex, multi-party workflows.
- Ability to tailor for multiple IT personas: An API security offering should provide a role-based access control model that allows for varied levels of view and control. The UI and UX should be customizable for various roles so that only desirable data and functionality is presented, and it should be possible to delegate functions to different users or groups of users.
API vulnerability identification and remediation insights
An ideal API security offering should use a combination of techniques to assess the security of internal, external, and third-party APIs . An API security offering should be able to passively analyze API traffic that flows through numerous points of enterprise architecture on and off-premises, and it should also be able to analyze API schema definitions. The solution should also provide remediation guidance tailored to developer and operations perspectives, tie into external defect tracking, and provide mechanisms to integrate with development, build, and release systems.
To power API vulnerability identification and remediation, make sure the API security offering includes:
- API vulnerability and weakness identification: An API security offering should use a combination of techniques to assess the security of the APIs that the organization hosts, integrates and consumes, passively analyze API traffic that flows through numerous points of enterprise architecture on and off-premises, and analyze API schema definitions when available.
- Remediation guidance tailored to developer and operations perspectives: An API security offering should provide remediation guidance focused on code-level fixes for development perspectives as well as infrastructure configurations for operations perspectives.
- Integration with external defect tracking: An API security offering should provide basic remediation tracking for identified issues, and it should integrate with external defect tracking systems in order to support pre-existing security and development workflows for remediation.
- Code repository, build system, and delivery system integration: An API security offering should provide a mechanism to integrate with development, build, and release systems. Ideally, integration is provided via API, webhook, or native integration with the relevant build system as opposed to command line invocation.
Conclusion
The underlying design and architecture of an API security offering matters. Any offering you are considering should be architected as a platform and address the full life cycle of APIs to secure them appropriately. API security requires cloud-scale big data to effectively correlate the myriad of API attributes that must be tracked, and scanning and other “shift left only” capabilities are insufficient for protecting against API attacks. Download the API Security Evaluation Guide from Salt Security to discover what it takes to adequately secure APIs and for guidance on what to look for in a given API security offering.
If you’re interested in seeing the Salt Security API Protection Platform in action, contact us for a customized demo today!
