A discussion with Traceable AI CTO and co-founder Sanjay Nagaraj on a new platform designed from the ground up to define, manage, secure, and optimize the API underpinnings for so much of what drives today’s digital business.
podcast
Traceable AI Platform Builds Usage Knowledge that Detects And Thwarts API Vulnerabilities
Transcript
Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.
The rapidly expanding use of application programming interfaces (APIs) to accelerate application development and advanced business services has created a vast constellation of interrelated services — now often called the API Economy.
Yet the speed and complexity of this API adoption spree has largely outrun the capability of existing tools and methods to keep tabs on the services topology — let alone keep these services secure and resilient.
Stay with us as we explore a new platform designed from the ground up specifically to define, manage, secure, and optimize the API underpinnings for so much of what drives today’s digital business.
To learn more about how Traceable AI aims to make APIs reach their enormous potential safely and securely, please welcome Sanjay Nagaraj, Chief Technology Officer (CTO) and Co-Founder at Traceable AI. Welcome, Sanjay.
Sanjay Nagaraj: Thanks, Dana, for having me.
Gardner: Why is addressing API security different from the vulnerabilities of traditional applications and networks? Why do we need a different way to head off API vulnerabilities?
Nagaraj: If you compare this to the analogy of protecting a house, previously there was a single house with a single door. You only had to protect that door to block someone from coming into the house. It was a lot easier.
Now, you have to multiply that because there are many rooms in the house, each with an open window. That means an attacker can come in through any of these windows, rather than only through a single door to the house.
To extend the analogy across the API economy, most businesses today are API-driven businesses. They expose APIs. They also use third-party libraries that connect to even more APIs. All of these APIs are powering the business but are also interacting with both internal and third-party APIs.
APIs and services are everywhere. The microservices are developed to power an entire application, which is then powering a business. That’s why it is getting so complex compared to what used to be a typical network security or a basic application security solution. Before, you would take care of the perimeter for a particular application and secure the business. Now, that extends to all these services and APIs.
And when you look at network security, that operated at a different layer. It used to be more static. You therefore had a good understanding of how the network was set up and where the different application components were deployed.
Nowadays, with rapidly changing services coming online all the time, and APIs coming online all the time, there is no single perimeter. In this complex world, where it is all APIs across the board, you must take into consideration more aspects to understand the security risks for your APIs, and — in turn — what your business risks are. Business is riskier when it comes to today’s security.
Because it’s so very complex, the older security solutions can’t keep up. We at Traceable AI choose to take care of security by looking at the data that comes in as part of the calls hitting the URLs. We take into consideration more context to detect whether something is an attack or some anomaly that is not necessarily malicious but may be a reconnaissance-type of attack.
All of these issues mean we need more sophisticated solutions that frankly the industry hasn’t caught up to even though developer and development, security, and operations
(DevSecOps) advances have moved a lot faster.
Gardner: And, of course, these are business-critical services. We’re talking about mission-critical data moving among and between these APIs, in and out of organizations and across their perimeters. With such critical data at hand, the reputation of your business is at stake because you could end up in a headline tomorrow.
Data is everywhere, exposed
Nagaraj: Exactly. At the end of the day, APIs are exposing data to their business users. That means the data flowing through might be part of the application, or it might be from another business-to-business API. You might be taking the user’s data and pushing it to a third-party service.
We’ve all seen the attacks on very sophisticated technology companies. These are very hard problems. As a developer myself, I can tell you what keeps me up most of the time: Am I doing the right thing when it comes to the functionality of my application? Am I doing the right thing when it comes to the overall quality of it? Am I doing the right thing when it comes to delivering the right kind of performance? Am I meeting the performance expectations of my users?
What do I, as a developer, think about the security of every single API that I’m writing? At the end of the day, it’s about the data that is getting exposed through these APIs. It’s important now to understand how this data is getting used. How is this data getting passed around through internal services and third-party APIs? That’s where the risk associated with your API is.
Gardner: Given that we have a different type of security problem to solve, what was your overarching vision for making APIs both powerful and robust? What is it in your background that helped you get to this vision of how the world should be?
Nagaraj: If you dial back the clock for myself and Jyoti Bansal, my co-founder at Traceable, we built the company AppDynamics, which was on the forefront of helping developers and DevOps teams understand their applications’ performance. When that product started, there was a basic understanding of how applications performed and were delivered to the customers. Over time, we started to think about this in a different way. One of the goals at AppDynamics was to understand applications from the ground up. You had to understand how these applications with their modules and sub-modules, and with the sub-services, were interacting with each other.
A basic understanding was required to learn if the end-user experience was being delivered with the expected performance. That gave rise to application performance management (APM) in terms of a fuller understanding of an application’s underlying performance itself.
From an AppDynamics’ perspective, it was very important for us to know how the services were impacting each other. That means when a call gets made from service A to service B, you should understand how much time was consumed on the call and what was happening between the two, as well as how much time was spent within the service, between the services, and how much total time was spent delivering the data back to the user.
This is all in the performance context. But one of the key things we clearly knew as we started Traceable AI was that APIs were exploding. As we talked about with the API Economy, every one of the customers Traceable started to talk to asked us about more than just the performance aspects of APIs. They also wanted to know whether these APIs and applications were secure. That’s where they were having a difficult time. As much as developers like to make sure that APIs are secure, they are unable to do it simply because they don’t understand what goes into securing APIs.
That’s when we started to think about how to bring some of the learning we had in the past around application performance for developers and DevOps teams, and bring that to an understanding of APIs and services. We had to think about application security in a new way.
We started Traceable AI to find the best way to understand applications and the interactions of the applications, as well as understanding the uses. The way to do it was the technology built over the last decade for distributed tracing. By helping us trace the calls from one service to another, we were able to tap the data flowing through the services to understand the context of the data and services.
From the context and the data, you can learn who the users of these APIs are, what type of data is flowing, and which APIs are interacting with each other. You can see which APIs are getting called as part of a single-user session, for example, and from which third-party APIs the data is being pulled from or pushed to.
This overall context is what we wanted to understand. That’s where we started, and we built on the existing tracing technology to deliver an open-source platform, called Hypertrace. Developers can easily use it for all kinds of tracing use cases, including performance. We have quite a few customers that have started to use it as an open-source resource.
But the goal for us was to use that distributed tracing technology to solve application security challenges. It all starts with so many customers saying, “Hey, I don’t even know where my APIs exist. Developers seem to be pushing out a lot of APIs, and we don’t understand where these APIs are. How are they impacting our overall business in terms of security? What if some of these things get exposed, what happens then? If you must do a forensic analysis of these, what happens then?”
See it to secure it with tracing
We said, “Let’s use this technology to understand the applications from the ground up, detect all these APIs from the ground up.” If the customers don’t understand where the APIs exist, and what the purpose of these APIs are, then they won’t be able to secure them. For us, the basic concept was bringing the discovery of these applications and APIs into focus so that customers can understand it. That’s the vision of where we started.
Then, based on that, we said, “Once they discover and understand what APIs they have, let’s go further to understand what the normal behavior of these APIs are.”
Once APIs are published there are tools to document those APIs in the form of an OpenAPI or a Swagger spec. But if you talk to most enterprises, there are rarely maintained records of those things. What developers do very well is ship code. They ship good functionality; they try to ship bug-free code that performs well.
But, at the same time, the documentation aspects of it are where it gets weak because they’re continuously shipping. Because the code is changing continuously, from a continuous integration/continuous delivery (CI/CD) perspective, the developers are not able to continuously keep the spec documentation up-to-date, especially as it continuously gets deployed and redeployed into production.
The whole DevSecOps movement needs to come together so the security practitioners are embedded with the developer and DevOps teams. That means the security folks have to have a continuous understanding of the security practices to ensure the APIs that are coming online continuously are understood.
Our customers now also are expecting our solution to help them automate these things. They want to automatically understand the risks of APIs — which APIs should be blocked from being deployed into production and which APIs should be monitored more. There needs to be a cycle of observing these APIs on a continuous basis. It’s very, very critical.
From our perspective, once we build this ongoing understanding of the APIs – as we discover and build an understanding of the APIs – we then want to protect those APIs before they get into production.
The inability to properly protect these APIs is not because some small company doesn’t have the technology skills or the proper engineering. It’s not about developers not having the right kind of training. We are talking about capable companies like Facebook, Shopify, and Tesla. These are technology-rich companies that are still having these issues because the APIs are continuously evolving. And there are still siloed pieces of development. That means in some cases they might understand the dependencies of the services, but in a lot of cases they don’t fully understand the dependencies and the security implications because of those dependencies.
This reality exposes a lot of different types of attacks, such as business logic attacks, as you and Jyoti talked about in your previous conversations. We know why those are very, very critical, right?
How do you protect against these business logic vulnerabilities? The API discovery and understanding the API risk are very key. Then, on top of those, the protection aspects are very, very key. So, that was where we started. This is part of the vision that we have built out.
Because of the way our new platform has been built, we enable all these understandings. We want to expose these understandings to our customers so they can go and hunt for different types of attacks that may be lurking. They can also use and analyze this information not just for heading off prospective attacks but to help influence all the different types of development and security activities.
This was the vision we began with. How do you bring observability into application security? That’s what we built. We help evolve their overall application security practices.
Gardner: In now understanding your vision, and to avoid a firehose of data and observations, how did you design the Traceable platform to attain automation around API intelligence? How did you make API observability a value that scales?
Continuous comprehension
Nagaraj: One of the key aspects of building a solution is to not just throw data at your customers. That means you’re correcting the data; you’re not just presenting a data lake and asking them to slice and dice and analyze it using manual processes. The goal from the get-go for us was to understand the APIs and to categorize them in useful ways.
That means we must understand which APIs are external-facing, which are internal-facing, and where the sensitive data is. What amount and type of sensitive data is getting carried through these APIs? Who are the users of these APIs? What roles do they have with an API?
We are also building a wealth of insights into how the APIs themselves behave. This helps our customers know what to focus on. It is not just about the data. Data forms a basis for all these other insights. It’s not about presenting the data to the customers and saying, “Hey, go ahead and figure things out yourself.”
We bring insights that enable the security and operations teams — along with the developers and DevSecOps teams — to know what security aspects to focus on. That was a key principle we started to build the product on.
The second principle is that we know the security and operations teams are very swamped. Most of the time they are under-resourced in terms of the right people. It was therefore very important that the data we present to those teams is actionable. The types of protection we provide from detection of anomalies must have very low levels of false positives. That was one of the key aspects of building our solution as well.
A third guiding principle for us, from the DevSecOps team’s perspective, is to give them actionable data to understand the code that is being deployed even when the services are deployed in a cloud-native fashion. How do you understand at the code level, which ones are making a database call and where that data is flowing to? How do you know which cloud-based APIs are making third-party API calls to know if there are vulnerabilities? That is also very important to manage.
We have taken these principles very seriously as we built the solution. We bring our deep understanding of these APIs together with artificial intelligence (AI) and machine learning (ML) on top of the data to extract the right insights — and make sure those are actionable insights for our users. That is how we built the platform from the ground up. Because continuous delivery (CD) is how applications are deployed today, it’s very important that we are continuously providing these insights.
It’s not enough to just say, “Hey, here are your APIs. Here are the insights on top of those, and here is where you should be focusing from a risk perspective.” We must also continuously adjust and gain new insights as the APIs evolve and change.
There was one last thing we set out to do. We knew our customers are in a journey to microservices. That means we must provide the solution across diverse infrastructures, for customers fully in a cloud-native microservices environment as well as customers making their journey from legacy, monolithic applications; and everything in-between. We must provide a bridge for them to get to their destinations regardless of where they are.
Gardner: Yes, Traceable AI recently released your platform’s first freely available offering in August. Now that it’s in the marketplace, you’re providing a strong value to developers, by helping them to iterate, improve, and catch mistakes in their APIs design and use. Additionally, by being able to define vulnerabilities in production, you’re also helping security operations teams. They can limit the damage when something goes wrong.
By serving both of those two constituencies, you’re able to bridge the gap between them. Consequently, there’s a cultural assimilation value between the developers and the security teams. Is that cultural bond what you expected?
Reduce risk with secure interactions
Nagaraj: Absolutely. I think you said it right. In a lot of cases, these organizations are rapidly getting bigger and bigger. Typically, today’s microservices-based, API-driven development teams have six to eight members building many pieces of functionality, which eventually form an overall application. That’s the case internally at Traceable AI, too, as we build out our product and platform.
And so, in those cases, it’s very important that there is an understanding around how API requests come into an overall application. How do they translate across all the different services deployed? What are the services – defined as part of those small teams — and how are they interacting with each other to deliver a single customer’s request? That has a huge impact on understanding the overall risk to the application itself.
The overall risk in a lot of cases is based on a combination of factors driven by all the APIs being exposed to those applications. But knowing all the APIs interacting with these services — and the data that’s going through these services — is very important to get a holistic understanding of the application, and the overall application infrastructure, to make sure you’re delivering security at an application level.
It’s no longer enough just to say, “Yes, we are secure. We’re practicing all the secure-coding practices.” You must also ask, “But what are the interactions with the rest of the organization?” That’s why it was essential for us to build what we call API Intelligence from the ground up based on the actual data. We attain a deeper understanding of the data itself.
That intelligence now helps us say, “Hey, here are all the APIs used across your organization. Here’s how they’re interacting with each other. Here’s how the data goes between them. Here are the third-party APIs being accessed as part of those services.”
We get that holistic understanding. That broad and inclusive view is very important because it’s just not about external APIs being accessed. It includes all the internal APIs being built and used, as well, from the many small teams.
Customers often tell me after using our solution that their developers are shocked there are so many APIs in use. In some cases, they thought they were duplicate APIs. They never expected those APIs to show up as part of any single service. It feels good to hear that we are bringing that level of visibility and realization.
Next, based on our API Intelligence, comes the understanding of the risks. And that is so very important because once the developers understand the risks associated with a particular API, the way they go about protecting them also becomes very important. It means the vulnerabilities are going to get prioritized and then the fixes are going to be prioritized the right way, too. The ways they protect the APIs and put in the guards against these API vulnerabilities will change.
At the end of the day, the goal for us is to bring together the developers and the DevOps and security teams. Whether you look at them as a single team or separate teams, it doesn’t matter for an organization. They all must work together to make security happen. We wanted to provide a single pane of glass for them to all see the same types of data and insights.
Gardner: I have been impressed that the single pane view can impact so many different roles and cultures. I also was impressed with the interface. It allows those different personas to drill down specific to the context of their roles and objectives.
Tell us how that drilling down capability within the Traceable AI user interface (UI) gives the developers an opportunity to compress the time of gaining an understanding of what’s going on in API production and bring that knowledge back into pre-production for the next iteration?
Ounce of pre-production prevention
Nagaraj: One of the key things in any development lifecycle is the stages of testing you go through. Typically, applications get tested in the development and quality assurance (QA) stages along the way.
But one of the “testing” opportunities that can get missed in pre-production is to learn from the production data itself. That is what we are addressing here. As a developer, I like to think that all the tests being written in my pre-production environment cover all the use cases. But the reality is that the way customers use the applications in production can be different than expected. And the type of data that flows through can be different too.
This is even more true now because of API-driven applications. With API-driven applications, the developer has an intent of how their APIs are used, and most of their tests mimic that intent. But once you give the APIs to third-party developers – or hackers — they might see the same APIs that the developer sees yet use them in unintended ways. Once they gain an understanding of how the API logic has been built internally the external users might be able to get a lot more information than they should be able to.
This is where it gets complex. This means that rather than treating production and pre-production as silos, the thought process is to bring the production learnings and knowledge to help improve the application’s security posture in pre-production because we know how certain APIs are actually being used.
If we understand the true risks associated with these APIs in use, we can present that in-production use knowledge back into pre-production, such as users accessing APIs they aren’t supposed to be accessing. That means decisions about which APIs need to be protected differently can be made by using the right kinds of controls.
The core benefit to customers is that they can understand their API risks earlier so that they can protect their APIs better.
Gardner: The good news is there’s new value in post-production and pre-production. But who oversees bringing the Traceable AI platform into the organization? Who signs the PO? Who are the people who should be most aware of this value?
APIs behavior in a single pane of glass
Nagaraj: Yes, there are typically various types of organizations at work. It’s no longer a case of a central security team making all the decisions. There are engineering-driven, DevOps teams that are security-conscious. That means many of our customers are engineering leaders who are making security their top priority. It means that the Traceable AI deployment aspects also come to pre-production and production as part of their total development lifecycle.
One of the things we are exploring as part of our August launch is to make the solution increasingly self-service. We’ve provided low friction way for developers and DevOps teams to get value from Traceable AI in their pre-production and production systems, to make it part of their full lifecycle. We are heavily focused on enabling our customers to have easy deployment as a self-service experience.
On the other hand, when the security and operations teams need to encourage the developers or DevOps teams to deploy Traceable AI, then, of course, that ease-of-use experience is also very important.
A big value for the developers is that they get a single pane of glass, that means they are seeing the same information that the security teams are seeing. It is no longer the security people saying, “There are these vulnerabilities which is a problem;” or, “There are these attacks we are seeing,” and the developers don’t have the same data. Now, we are offering the same types of data by bringing observability from a security perspective to provide the same analysis to both sides of the equation. This makes everyone into a more effective team solving the security problems.
Gardner: And, of course, you’re also taking advantage of the ability to enter an organization through the open-source model. You have a free open-source edition, in addition to your commercial edition, that invites people to customize, experiment, and tailor the observability to their particular use cases — and then share that development back. How does your open-source approach work?
Nagaraj: We built a distributed tracing platform, which was needed to support all the security use cases. That forms a core component for our platform because we wanted to bring in tracing and observability for API security.
That distributed tracing platform, called Hypertrace, as part of the Traceable AI solution, will enable developers to adopt the distributed tracing element by itself. As you mentioned we are making it available for free and as open source.
We’ve also launched a free tier of the Traceable AI security solution which includes the basic versions of API discovery, risk monitoring, and basic protection, for securing your applications. This is available to everybody.
Our idea was we wanted to democratize access to good API security tools, to help developers easily get the functionality of API observability and risk assessment so that everyone can be a pro-active part of the solution. To do this we launched the Free tier and the Team tier, which includes more of the functionality that our Enterprise tier includes.
That means, as a DevOps team, you’re able to understand your APIs and the risks associated with them, and to enable basic protections on those APIs. We’re very excited about opening this up to everyone.
But the thing that excites the engineer in me is that we are making our distributed tracing platform source code available for people to go build solutions on top of. They can use it in their own environments. At the end of the day, the developers can solve their own business problems. We are in the business of helping them solve the security problems, and they can solve their other business needs.
For us, it is about how do we secure their APIs. How do we help them understand their APIs? How can they best discover and understand the risks associated with those APIs? And that’s our core. We are putting it out there for developers and DevOps teams to use.
Gardner: Sanjay, going back to your vision and the rather large task you set out for yourselves, as Traceable AI becomes embedded in organizations, is there an opportunity for the API economy to further blossom?
How big of an impact do you expect to have over the next few years, and how important is that for not only the API economy, but the whole economy?
Economy thrives with continuous delivery
Nagaraj: From an API economy perspective, it’s thriving because of the robust use of these APIs and the reuse of services. Any time we hear news about APIs getting hacked or data getting lost, there is an inclination to say, “Hey, let’s stop the code from shipping,” or, “Let’s not ship too many features,” or, “Let’s make sure it is secure enough before it ships.”
But that means the continuous delivery benefits powering the API economy are not going to work. We, as a community of developers, must come up with ways of ensuring security and privacy so we can continue to maintain the pace of a continuous software development life cycle. Otherwise, this will all stall. And these challenges will only get bigger because APIs are here to stay. The API economy is here to stay. APIs will be continuously evolving, and they will be delivering more and more functionality on a continuous basis.
The only way we can get better at this is by bringing in the technology that enables the continuous delivery of code that is secured in pre-production and not just at runtime. And that’s the goal from our perspective, to build that long-term and viable solution for enterprises.
Gardner: I’m afraid we’ll have to leave it there. You’ve been listening to a sponsored BriefingsDirect discussion on how the rapidly expanding use of APIs to advance business services has created a complex constellation of interrelated services.
And we’ve learned how an AI-enabled security capability in a new platform from Traceable AI is designed from the ground up to discover, secure, and optimize the API underpinnings of today’s digital businesses for teams across the full lifecycle of development.
So, a big thank you to our guest, Sanjay Nagaraj, Chief Technology Officer and Co-Founder at Traceable.ai. Thank you so much, Sanjay.
Nagaraj: Thanks a lot.
Gardner: And a big thank you as well for our audience for joining this BriefingsDirect API resiliency discussion. I’m Dana Gardner, Principal Analyst at Interarbor Solutions, your host throughout this series of Traceable AI-sponsored BriefingsDirect interviews.
Thanks again for listening. Please pass this along to your business community and do come back for our next chapter.