(For a quick catch-up on the ascent of API security as a current industry topic, please see this recent blog post. The guidance below picks up there and helps outline what you can do about it.)
Supplement Your API Gateway with a Security Gateway
The explosive growth of APIs is driving new markets for both API gateways and API security. While these may consolidate in the future, today you can front your API gateway with a capable web application firewall (WAF) to mitigate threats. WAFs can block known bad traffic before it hits your API gateway by using out-of-the-box features such as IP intelligence, attack signatures, malicious bot detection, and OWASP Top 10 rule sets. More mature WAFs, such as F5 Advanced WAF, have dedicated capabilities and can customize security policies to protect multiple APIs within a single domain, not just a global per-domain rule set.
In addressing present and emerging needs, here are three items to remember:
- API gateways have become strategic control points. As technology transitions prompt even more non-human traffic, the API becomes the focal point of the business. API gateways sit at the edge and are the ingress point to all API traffic. API security requires richer context, analytics, caller ID, and correlation capabilities to be effective.
- The gap between the API gateway and API security offerings is sizable. Traditional app security vendors lack the minimum API gateway features such as versioning, orchestration, and metering. Most API gateway solutions lack the standard security controls available in most WAF solutions. You’ll need both for adequate functionality and security.
- This gap can be addressed with a security gateway. The addition of an Advanced WAF with API protection capabilities can help overcome the security deficiencies of most API gateways. F5 Advanced WAF has extended its security capabilities to include APIs and microservices. While this cannot replace the extended functionality of an API gateway, it can improve and enforce common security controls. The F5 Advanced WAF also supports declarative APIs so that API security policy can be orchestrated and automated for agile environments.
Security Gateways Can Compensate for Security Lapses, But Don’t Get Lazy
As the technology matures, API gateways will help to address additional API security concerns, but we are not quite there yet. Planning and best practices will go a long way to help keep your APIs adequately protected in the short-term. To be effective in protecting your APIs, don’t forget to:
- Use a security gateway every time. Don’t enable clients to have unauthenticated direct access to your API. Force all traffic through a security gateway or proxy that can drop known bad traffic. Leverage an existing WAF if you have one. Even a basic WAF can work in pinch while you consider a more comprehensive solution.
- Keep it simple. Have DevOps and SecOps agree upon a set of standards (e.g., OpenAPI/Swagger) for developing APIs. Standards will help you document and test your APIs. OpenAPI 3.0 has dedicated security components that can be reused to help with the implementation of secure design. Using OpenAPI standards also enables the use of auditing and conformance tools such as Crunch42, to automate design and security testing.
- Define security requirements. The scope of API requirements usually includes only the desired functionality for the API—that is, defining what capabilities the API should do. API requirements should also include security requirements (what the API should NOT be able to do). With security as part of the design specifications, security becomes part of the functional testing of the API.
- Create threat models for API services – API clients and servers. Performing threat modeling of the proposed system will help to identify key assets/components and threat categories. Security design requirements can then be added to mitigate the identified threats. Ensure that controls are in alignment with a desired risk model for the API and app.
- Offload authentication and authorization. Utilize the API gateway for modern authentication and authorization. All APIs need to have authentication as part of the deployment. There is no need to build this into the app itself (and not a best practice, as forwarding unauthenticated traffic directly to the API can leave it vulnerable to attacks). There are several forms of authentication that can be utilized, and a risk-based approach can help your selection. Oauth 2.0 is generally considered as a best option for REST APIs. F5 BIG-IP APM is a good solution for implementing these controls.
- Encrypt everything. No excuses not to use encryption. SSL/TLS is approaching 100% for all internet traffic. All public API traffic needs to be encrypted. If possible, use ephemeral keys for added security (remember Heartbleed?). If your API gateway cannot handle the cryptographic workload due to performance or price, consider offloading the workload to a dedicated system such as F5 SSL Orchestrator.
- Discourage developer “creativity” around security. Security is hard to do right; the security community has been doing this for decades, yet we still keep finding flaws. Although your developers may be brilliant, be extremely wary of them inventing customized security controls such as a new encryption model. To avoid security “creativity” of this sort, be sure to provide DevOps with standardized and well-vetted baseline security controls. If there’s a need for specifically tailored security controls, the SecOps team should be consulted.
The use of APIs has the potential to be transformative by enabling new business models and revenue streams. Implemented without adequate guardrails, however, APIs also have the potential to disrupt and put businesses at risk. While API security may still be considered a somewhat fledgling technology area, the practices outlined above can help address the present API security gaps as the surrounding solutions mature.