This week we discuss API security trends with a community, James Higginbotham, an independent expert and entrepreneur in the software industry with a strong focus on APIs. James also created LaunchAny, a consulting firm that specializes in digital transformation through APIs, microservices, cloud-native architecture, containerization and serverless, IoT, and edge computing. In this post, we discuss key elements for a successful API security strategy in the digital era.
We all agree that APIs are building blocks for digital transformation of organizations in all industries. But with the rising number of cyber-attacks and data breaches, APIs are an emerging vulnerability because of today’s more sophisticated threats. What is the strategy for an organization to take, in order to face these challenges and protect their entire API ecosystem?
James Higginbotham (JH): Until recently, organizations used a combination of batch file integration along with service-based integration using technologies such as SOAP and XML-RPC. Integration between organizations was often a custom, one-to-one job. This allowed the integrations to be highly controlled and managed. The addition of whitelisted IPs and client certificate authentication (aka two-way SSL) ensured we knew who was making the call and that the access was limited only to authorized, known third parties. And often a single third party.
Now, organizations launch API platforms that are more open, shifting the control to API consumers. IT teams have less control and insight over how APIs are used once access is granted and data is used. Just look at the recent Facebook + Cambridge Analytica issue as an example. Organizations can no longer assume their API is being used as intended. They need a comprehensive API security strategy that includes proper authentication and role-based authorization, protection against common exploits such as SQL injection, role-based access control, and review processes prior to granting access to endpoints that surface PII and NPI data.
MK: This is interesting, indeed. So, let’s go more into detail with the technical aspects. You said that foundational API security is no longer enough to protect an organization against cyber attacks. Can you share your best practices in terms of technology deployment for API security trends, especially to detect and automatically block any API attack?
JH: As with any security model, I recommend a layered approach to protecting your API. Of course, using TLS throughout is important to ensure all data is encrypted while in motion. Placing an API management layer in front of your API is the critical next step and a common API security trend. API management layers enforce access control at the edge of your network. They can also provide protection from common attack vectors, such as code injection. At the outer-most layer, I recommend using a CDN to protect against DDoS attacks at network layers four and seven.
Finally, organizations must monitor not just who is using the API, but how they are using it. They need to be able to detect when an authorized party is using the API in a new way. It may be that there is a legitimate change in how they are using the API, or it may be a result of compromised access credentials. This kind of detection and insight is challenging at best, so we are seeing exploration in log analysis tools and the application of machine learning to address this kind of usage monitoring.
MK: Digital business involves having a huge number of applications and connected devices running inside of the organization, as well as with its suppliers, partners and other members of the ecosystem. How would you define the role and security approach of these different types of APIs: internal, public and partner?
JH: We have found that the best strategy is a combination of automated and manual processes to address the varying needs of today’s API program. Automation options include the installation of an API management layer or an API gateway alongside a web application firewall (WAF) to detect basic attack vectors. Some organizations opt to install multiple instances of these layers: one for public APIs, one for partners and one for internal APIs. Each instance is configured with only the endpoints that need to be exposed, thereby limiting the API surface area available for attack.
Listen to the webinar: Lessons in Transforming the Enterprise to an API Platform | LaunchAny & SmartBear Webinar
We have also seen organizations apply manual security processes for onboarding suppliers and partners, including a default stance of limiting API access to only the specific endpoints needed to avoid exposing unnecessary endpoints; creating customized endpoints that provide only the necessary data required by partner integrations; and concierge services to assist partners in ensuring proper care is taken to secure access tokens and reduce the chances of accidental DDoS attacks through developer error.
MK: Thank you, that’s very helpful. If you could give your three top tips for organizations to enhance their API security strategies, what would they be?
JH: Of course! Here they are:
- #1 – Perform a comprehensive security review of your API portfolio. This is particularly important when the audience for your API changes from internal to partners or external customers. Identify endpoints that provide access to critical PII/NPI data or sensitive business processes. This is especially important for APIs that drive web and mobile apps, as many of these APIs are considered “hidden” and “internal” and receive less attention.
- #2 – Review your API access policies. Some organizations have taken shortcuts by using access tokens that never expire, hard-coded API tokens, or skip proper authentication and authorization entirely. If necessary, roll out a revised plan that includes proper access control with rotating access tokens that limit exposure to compromised credentials. Also, remember to revoke tokens for ex-employees, ex-partners, and ex-customers.
- #3 – Finally, look for ways to monitor real-time access to your API. Review access logs to identify improper usage or compromised access tokens. We are seeing organizations evaluate products such as Elastic Beam that applies AI to detect different API consumption usage patterns, detecting malicious API usage from single or multiple IP addresses. In some cases, you can plug into an Identity Provider like Okta or Ping Identity to keep authentication/authorization policies for your API centralized and consistent across the organization.
MK: Wonderful insights! Thank you very much, James, for your time. I’m sure Axway’s customers and partners will be inspired by your vision and advice around API security trends! I wish you all the best and see you next time.
Read also API security and AI (Artificial Intelligence)-Webinar.