Jessica Marie – API Catalog: The First Step in Protecting your APIs

Hello everyone. Welcome to today's presentation. My name is Jessica and I'm a security evangelist here at traceable.

And today's session is about API catalogs. This is the first step in protecting your apis. So just for some setup here as we know every business is a software business.

And apis are the building block of all modern software. And to secure our software business we need to secure the apis through which software is accessed both internally and externally. And API security begins with being able to automatically catalog and track changes to those apis and they're distributed interactions in real time.

So in this session we talk about the need for an actionable API catalog some of the functionality that such a catalog needs to provide. And how your security teams can go about creating one? So let's get started.

Let's start with the with answering the question. Why do you need an API catalog? for some background API catalogs are a concept that's broadly understood.

usually within the API management Market and it's used in the development of complex applications delivering Services externally and to other teams via apis API change and risk management vulnerability analysis, like all kinds of stuff, right? But when it comes to the security industry, there's some other considerations. Basically, you need an API catalog because apis connect everything literally everything you have thousands of apis running on multiple clouds, and they're all growing at a rapid pace.

There was a actually a popular. Phrase for many years ago probably 10 years ago now software is eating the world. Which was definitely true at the time now, it's all about apis apis are actually eating the world.

And this phenomenon is known as API sprawl most companies simply don't have visibility into how many apis they have. Where those apis reside? And what those apis are actually doing?

And this brings a huge amount of risk to the organization. So some other considerations for lack of visibility, bear with me for a moment and development teams. They will use multiple tools to rapidly build an update apis.

They often use practices like cicd. And drive constant and frequent changes. This could be exposure via a kubernetes or the abstract team and because of this we're not always able to see any unknown or Shadow apis being released to production or existing apis being updated without informing the security teams.

Those frequent updates to apis can result in. Usually versioning and documentation issues beyond that. We all know that apis are prone to fraud and malicious behavior.

External apis have to be validated continuously for trust. And you know kind of a scary example is that internal API keys can be compromised there have been examples in the industry of that being able to give attackers access to critical infrastructure. And if we look at something like Solutions like API gateways Ingress controllers Sidecar proxies.

They can enable some pretty effective management of. like intra cluster API architectures But they're not they're not sufficient when it comes to managing intercluster API sprawl. And what this does is that it creates a known exposure and unknown attack surface and therefore additional risk.

So here are some questions that you might want to ask yourself just as you're evaluating your current environment. Do you know how many apis you have in your organization? Do you know which new apis have been recently introduced?

And which apis are external facing versus internal facing? And so to really solve for to begin to solve for API sprawl you need to start with a solution that can be that single source of truth that tracks all apis provides automatic discovery. proper versioning and documentation You need to assess API to API connectivity and uniform and have uniform monitoring of API reliability.

And and basically this is where you know API catalog is coming is that you have to you need to have a an accurate inventory of your web assets that belong to the organization and protect them accordingly. So what makes Discovery so challenging there's several reasons, but these are really the top ways that can make the discovery of apis more difficult. so the first is about deployment options.

They're just there's numerous options now and there is the public cloud on-prem and hybrid deployments depending on what your organization needs. Next is that applications are distributed. And specifically microservice architectures have made applications.

massively distributed and finally, we talked a little bit about this already but agile releases. So development teams are releasing multiple times per week. What we've seen actually in larger organizations more culturally and technologically sophisticated environments development teams will be huge and will release multiple times an hour.

We typically see this In particular Industries, like fintech where apis and applications are super important for delivering services to their customers. So basically the boundaries are just being eliminated, especially with these microservices and Cloud capabilities. And so the bottom line around this is that what is internal and external just isn't as clear as it used to be.

And because of this it's becoming increasingly more important to have complete visibility into all those apis so you can make better security decisions. now let's talk about What you should look for in API Discovery solution this information might be helpful as you embark on your journey and looking for API security platforms. So the first is really a given you need to automatically discover all of your API endpoints.

You need to be able to group your apis by apps Services domains. So your security teams can analyze the information and make better security decisions. Next you should be able to classify those apis either as external internal or third party.

And finally automatically catalog new apis and updates to existing apis and this is all done even as your environment changes. But what's really the difference between API Discovery and an API catalog, so there's several important points here to consider. for starters and API catalog is giving a much more robust and comprehensive View.

Of your organization's API risk posture and it's a tax surface. Whereas Discovery is typically only providing an inventory of your apis and many of the capabilities beyond that might end up being really manual rather than automated which, you know security teams definitely don't need. So there are things like in an API catalog that's giving you that single pane of glass around your API activity.

It's auto-generating risk scores looking at sensitive data flows conformance analysis Etc. I'll get into more of this in a second, but those capabilities usually are missing in API Discovery Solutions and if they do if they are included. As I said, they can be they can end up being more manual.

The other way that makes an API catalog different is that it will benefit multiple teams in the organization. This is from security to devops to compliance teams for security. Those teams can start to really obtain a comprehensive view of their attack surface, which helps them prioritize any API security issues that need to be addressed.

For devops teams. This is really important is that their cicd Integrations devops teams. It allows them to really address the security issues early in production.

for early and non-production environments and you know, we definitely need both right this shift left security as well as runtime. But as we all know most of the time finding issues and production is is usually far more expensive. And then finally for compliance teams, you know, this is really helpful for you know, the governance risk and compliance individuals who are really they need to really know like what kinds of sensitive data is being transmitted via the technology or in this case via apis.

And it gives them the visibility they need into that sensitive data and in turn can help with more audit and compliance efficiency. So once we have an API catalog, let's talk about some ways to make an actionable. So open API specs having talked to literally hundreds of security teams.

We've realized that one of the most useful tools is an open API spec. It's an open standard that lets producers and consumers of apis communicate in the same language. And it also makes multiple API security related tools.

This could be testing tools documentation tools just understand each other better. And so this is just a quick a few points here to consider like if when you don't have an open API select versus when you do have have one to work with so if you don't have one, you're not really able to answer these questions accurately, right? So are you are your apis being consumed securely?

Are they being consumed as the developer intended like as they were designed to? Um, our API is exposing any unknown parameters and or responses or content types. You just can't answer those questions.

If you don't have an open API spec. If you do you will. Immediately have that single source of truth that you need and and which benefits different teams and partners.

You'll have portability between different security tools. and it's much easier to identify which apis exposed sensitive data and where so if we were to do this at scale. Open API specs organized by services and domains.

Should be available to the users to view download and use for conformance analysis. Really important to be able to perform conformance tests to detect Shadow orphan and zombie apis parameter mismatches and headers cookies requests and response bodies either on demand or scheduled. So if you're working with something like this you want to be able to upload that spec and open API format, you'd compare uploaded the uploaded spec with the observes API spec.

and then have the ability to view the results and consume the information be a reports and this can be this can be really helpful. If you need to provide just some concise reporting to your stakeholders or Executives in the organization. And sensitive data exposure.

So obviously this is probably the number one issue across every security solution in existence and certainly no conversation about API catalogs or Discovery or API security posture is complete from a security perspective without talking about sensitive data. so with so much data and often sensitive data now being transmitted via API, it puts the organization at risk of a data breach and data exposure is listed as one of the top threats for API traffic by owasp. This includes data leaks and exfiltration from origin responses.

The increase in the number of apis as well as the increase in API Tropic make this a huge problem that security and GRC teams needs to solve like yesterday. So it's very important to know the data flow and to end to understand your overall security posture. So in a situation like this, you need to have the ability to analyze usage and sensitive data for each API endpoint.

To identify where sensitive data flows end to end across those apis. And then be able to track the flow of sensitive data to identify how it got to those unexpected destinations. And finally once your apis have been discovered and cataloged.

You need to be able to take action on that information and specifically for security teams risk scoring is a non-negotiable capability. It's important to have the ability to generate risk scores that proactively identify vulnerable apis. those API risk scores that evaluate the vulnerability of apis used in your business logic.

This is a again non-negotiable capability. So being able to Continuously update endpoint risk scores based on the likelihood and impacts of a Cyber attack. Specifically here at traceable we use risk Force to provide an always updated view of your most risky API, so you can prioritize mitigate mitigating those risks.

And finally, let's do a recap. I realize this is a lot to read so it's quite the it chart but my intention was to provide you with something that maybe you can take a screenshot of or referred back to as you're seeking API catalog Solutions. So the first here again automatically discover and catalog all services and apis that includes your new releases and updates.

And open API spec creating that open API spec for each API endpoint including the schema. specific data types required parameters all kinds of stuff that that includes ci/cd integration. This is about providing, you know apis for integrating numerous functions such as risk scores and conformance Analysis in staging.

Change detection with new releases. So automatically identifying new apis and updates to existing apis. Conformance analysis.

So again analyzing usage performance vulnerabilities and sensitive data for each of your API endpoints. and capturing both upstream and downstream API dependencies identifying sensitive data exposure. So again instantly knowing what apis are exposing sensitive data and being able to block accordingly.

And then finally API risk, so again based on likelihood and impact being able to continuously assess and assign a risk score to each API endpoint and which helps your security teams manage their environment much more effectively. And that's rough. I hope this session was helpful.

Thank you so much for your time today and hope to see you next time.