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.
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:
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:
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:
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:
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:
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:
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.
It’s extremely important to make sure your OAuth implementation is secure. The fix is just one line of code away. We sincerely hope the information shared in our blog post series will help prevent major online breaches and help web service owners better protect their customers and users.
We want to thank our customers, partners and friends for the calls and messages to our team showing your concern and support.