APIs connect businesses, people, and things. They are everywhere nowadays, allowing developers to unlock new opportunities for innovation. The vision of any API program is a powerful developer ecosystem that enables organizations to connect with the world digitally. Both modern, as well as legacy, APIs encapsulate the business. In our case, they are the front door to our marketplace platform. eBay developers leverage our APIs to manage their business. They trust us, so our APIs must be reliable digital assets that enable growing a successful business.
Zero-trust model in developer ecosystems
Every digital technology comes with risk. Now is the age of the API gold rush, where APIs play an integral role in the digital world. We also live in the age of digital ethics and privacy. With live integrations, it is very challenging to make changes to address security concerns without impacting partners and their businesses. On the other hand, legacy APIs show their age, which requires implementation of new security principles. It makes sense to apply the concepts of a networking zero-trust model, which never assumes trust, to API programs as well. None of the entities are trusted by default. When translated to developer ecosystems, this refers to: APIs, both legacy and greenfield, actors, applications, security protections implemented in the past, systems, and humans who assess the value of integrations. The new model relies on all sorts of data and continuous auditing of APIs.
Monitoring and usage analysis
Look beyond the numbers. Around them. Through them. - Al Harrison
Ongoing monitoring and API usage analysis is essential to any API program. Near real-time scanning and alerting is vital to keep the APIs up and running. It is not always simple to estimate the usage of APIs. At eBay, it is common to have sudden seasonal and other spikes related to business events. On the other hand, an unexpected surge in traffic coming from certain integrations is often a good indicator of anomalies.
The API usage analysis is beyond operational metrics and pure insights into the API availability. Mining API traffic data for patterns is what enables API providers to have visibility into the way developers use the capabilities. By doing this, organizations can identify normal behavior, detect anomalies, assess the value the APIs bring, and understand benefits coming from third-party integrations. (If you cannot measure it, it does not exist!) And data ages like wine — the more data, the better the behavioral analysis.
Developer entity resolution
In general, entities are real-world people, businesses, or objects. They have their characteristics — entity attributes. Entity references are sets of attribute values. Entity resolution is the process that resolves entity references into entities. It answers whether the two references point to the same real-world person, business, or object.
Entity and identity resolutions are not the same. Identity attributes represent a subset of entity attributes that identify an entity. In the case of real-world people, identity set also includes biometric attributes like human fingerprints. This illustrates well the difference between entity and identity resolutions. For example, if two sets of fingerprints are found in two different rooms, simple comparison determines whether they belong to the same person. That is entity resolution. But we still do not know who that person is. Looking up fingerprints in a particular system reveals the identity of a real-world person. That is identity resolution.
Figure 1: Real vs. digital world
In the marketplace world, it is important to resolve all product references to product entities. Similar applies to user accounts — buyers and sellers. This concept is also applicable to any developer program. Third-party developers are entities in the API ecosystem. To know your developer, all analyses and assessments should be done at the customer level. It is true that understanding the API usage pattern is necessary, but it is equally important to understand who is using the APIs. In our case, this includes relationships across eBay realms: Developers Program, eBay Partner Network (EPN), and Marketplaces, which adds significant complexity.
Risk assessment strategy
To succeed, planning alone is insufficient. One must improvise as well. - Isaac Asimov
Although the focus is on being predictive rather than reactive, in risk assessment strategy, both preventive and reactive approaches are essential. Risk decision systems assess the risk to prevent fraudulent activities. Such decisions are driven by regulations and long-term policies with less volatile rules. On the other hand, fraud decision systems detect fraudulent activities. These decisions are highly volatile due to fraudster behavior changes. Whenever you think your security practices are in place, very motivated bad guys find all sorts of loopholes and another way to achieve what they need and want.Keeping the bad actors out requires constant rule modifications, iterations, and improvements.In general, all serious risk management systems follow the triple-A approach:
-
Agile
-
Adaptive
-
Analytic
Agile requires a quick response to new circumstances and an easy way to change the decision rules while staying compliant with laws and regulations. Adaptive is to find new approaches, manage trade-offs, optimize policies, run simulations, and experiment, test and learn. Analytics is to use historical data to predict the future to reduce fraudulent activities. When predictive models are combined with other data points and rules, they typically improve risk assessment and management.
Any API program should have a mechanism in place to prevent and detect evil intent and API misuse. (Otherwise, the API program becomes a playground for fraudsters.) Such a system should be on 24x7 and real-time responsive. Besides, full transparency is needed to confirm that decisions implement business requirements and that they are compliant with regulations. This also provides insights and visibility to Developer Technical Support and third-party developers, when needed.
There are two primary sets of activities here:
-
Prevent bad actors from entering the ecosystem
-
Continuous evaluation of existing developers and their integration
The first one is to control the front door to the eBay Developers Program by letting the right people in. This is also to prevent bad actors from recreating developer accounts and applications upon deactivation. Understanding related developer accounts allows evaluating risk assessment at the third-party developer-level — the developer as a customer here rather than a single account integration. The ultimate goal for sure is to take good care of good actors and avoid limiting their business. All we want is for the sky to be the limit for our trusted developers. On the other side, good actors could turn bad overnight. It is a game of cat and mouse that requires both continuous API auditing and continuous evaluation.
Finding a balance
Forces are always pushing one way or another. It is essential to find a balance between boosting adoption and maintaining fine-grained control over data and capabilities. So, it is all about balancing recall and precision. How would one prevent crime in a town? Arrest everyone. That is not the perfect strategy. Our choice is precision. Higher precision implies more good developers in the program and higher revenue in the long run. After all, the goal is not really to count the bad guys we caught. It is crucial to prevent the good actors in the ecosystem from being impacted by bad actors’ behavior. And that is what we measure.
Continuous API security
To continue with my analogy between cooking and integrating with APIs, APIs are healthy ingredients to enable the healthy business. We live in a connected digital age, and data sharing is part of our lives. So, it is essential for any API program to implement data protection principles and to address privacy concerns. APIs could easily and quickly turn against organizations. A continuous API security strategy is crucial to ensure the APIs are reliable digital assets. Keeping the APIs safe and treating API security as an enabler rather than a gate leads to preventing good actors in the API ecosystem from being affected by bad actors. Our goal is to continue opening the marketplace and at the same time, keep the eBay Developers Program secure. This is not a mountain you climb, reach the top and then sit, relax, and enjoy the view. Securing the developers’ program is a progressive journey rather than a one-time exercise. In general, the road to excellence is always under construction.