What You Need to Know about Protecting Your APIs - Webinar Recap

Below is a transcript of our webinar that originally appeared on BrightTalk in the 2022 Threatscape Summit in the track titled, "Detection and Response with Threat Hunting in APIs". 

If you do not have a BrightTalk account, you can watch this webinar on our website.

The webinar speaker is Giora Engel, co-founder and CEO of Neosec.

The host for the speaker is Edward Roberts, VP Marketing, Neosec.

Slide 1:  Introduction

Edward: Welcome to today's webinar,  What you need to know about protecting APIs.

Your attendance here indicates to us that API security is obviously a growing problem that is becoming of greater importance to organizations everywhere.

Slide 2:  The Presenter

Edward: And I'd like to take today to introduce you to today's presenter. Giora Engel is a serial entrepreneur and is the co-founder and CEO of Neosec. 

• Before Neosec, he founded the company LightCyber, which invented the XDR space. 
• After Lightcyber was acquired by Palo Alto Networks, he launched the Cortex XDR product within Palo Alto. 
• He's also the current chair of the Fraud Control Task Force for the FDX initiative. 

And so he's got a good background in security. And so with that, I'm gonna hand it over to Giora to talk to you about what you need to know about protecting your APIs.

Slide 3:  Agenda

Giora: We have a packed agenda. Hopefully, this webinar can help you take the first step of assessing your API footprint as well as provide some practical first steps of how to start protecting APIs. 

• We will start speaking about digital transformation, and how APIs are an instrumental part of it. 
• We’ll speak through the challenges of securing APIs, because they’re unlike securing other things that we had before like web traffic and other more simple environments. 
• Then we'll walk through a process of abuse case analysis, this is basically connecting your business risks into the APIs and what it means about protecting these environments and then priorities 
• Some practical steps for starting. 

So really, a lot of good items on the agenda, and hopefully, you can take what you learn today and bring it to your security environment.

Slide 4:  APIs & Digital Transformation

So let's start with the digital transformation.

Slide 5:  APIs are big deal

I think we all see these statistics of, for example, from Akamai 80% of internet traffic is made of APIs. 

I think the Gartner prediction is already happening. I think they predicted that by '22 most of the attacks that we see will be API driven. I think we're actually already seeing it today but I think it's beyond the numbers.

The questions that I hear are, what makes APIs so instrumental? Why is it [API Security]  such an important problem? It's not just that the numbers are high, and there's a lot of traffic. 

Slide 6:  Digital Transformation runs on APIs

It's really all about digital transformation. I think it goes back to the core business of which company and what types of services they are building and providing to their clients, partners, and so on. 

[Slide Build]

And really, at the end of the day, digital transformation really runs on APIs. So the API is the building block that's the communication framework that enables digital transformation.

For example, in the financial services space, where I'm quite involved, as Edward mentioned, I'm the chair of the Fraud Prevention Task Force at FDX. 

At FDX we work on defining these APIs that are exposed by financial institutions into aggregators and fintech organizations. And as you can imagine, today as consumers, we use all these different fintech services. All of that traffic is fueled by APIs, API traffic that goes from these fintechs and aggregators to the FIs [FInancial Institutions]. So this is just one use case, but it's really one of many.

[Slide Build]

Everything in healthcare moves to APIs, there's a lot of regulation that also requires that to happen. 

[Slide Build]

The payment industry is based on APIs. 

We see the growth of APIs all the time and at the end of the day, it's understanding that APIs are the building blocks of digital transformation. Because of that, they are so instrumental because digital transformation happens at a faster and faster pace in this time period, where there's so much innovation going on, on the business side.

Slide 7:  Why APIs are the next security problem?

To put it in context, when I started my previous company, LightCyber, the company that invented XDR, we dealt with attacks that were targeting the data centers. Back then, about 10 years ago, when we first heard about these cyberattacks and the corresponding information loss and so on. It was really attackers targeting the data center because all the crown jewels were sitting there. They typically found some way in and then moved laterally, gaining access to the crown jewels.

Now, in today's world, things look different from an attacker's perspective. Today, the most critical assets are actually exposed to the outside by design, through different types of APIs and applications. Attackers no longer need to look in our data centers, because honestly I believe that our data centers are less and less relevant and important. 

Instead, these APIs and applications expose our core business to the outside by design. So the attackers can focus on these new environments. And actually they can get to the data by accessing API environments directly. 

So I think this is a huge shift in, from a security perspective, and this is exactly what makes APIs the main area today, where attacks happen. And that's a huge shift, because it's a completely different environment.

Slide 8:  APIs and Digital Transformation

Now, when we think about digital transformation, there are typically some common steps that companies go through when they release some new services. 

• Typically, there's a new business idea, or a new business need, or customers need some things such as some kind of new access, new partnership, a new product that you want to provide to the customers. So it doesn't matter if you're a financial organization or a travel agency or any other type of business. You always have new types of products or new types of business, in order to stay in business in order to be relevant.
• Now, the first step is typically creating some kind of new implementation, new APIs that enable that. These APIs can then be exposed through some kind of web portal. But it can also be a B2B API and so on. 
• Once the API is authored and ready to be used, typically it gets open to be used by these partners or users. And this is all part of a business process: there's typically some business urgency to expose these APIs to be able to offer that new service.
• And it's not that security is secondary. But security by design is lagging behind: It's not going to be another build that needs to go through security and so on. It's just an incremental improvement of the business offering, and so on. So what we see is that most companies struggle with that transition from stage three to stage four: actually securing APIs.

Audience Question

Edward: A question has come in, Giora. Can you explain more why you think most companies are only at stage three? And do you see that changing?

Giora: I think one of the biggest differences between what we've seen in enterprise security and what we see in application security is that the business cannot wait for a security process. And I think it's part of the new battlefield: There's no longer a long build process where everything is approved in advance and so on. 

Business is running at a different pace. And the business space is what sets the pace! The security team needs to somehow find a way to influence the security process in an effective way but without delaying the business process even by a bit because if the business process is delayed the whole operation can fail.

This creates an inherent catch-up from a security perspective, And it prompts for a different way of thinking. You can't expect to approve and authorize everything. So we need a different way to monitor.

Slide 9:  Challenges in Securing APIs

Moving forward to the challenges of APIs, I want to touch on a few areas of difference between APIs and some other things that we deployed before.

Slide 10:  Basic API Security is Necessary, But Not Sufficient

For example, the crucial difference between APIs and web traffic. What are we doing today to secure these environments? We have microservices in the middle. And we do some security testing, by most application security teams who are part of the development lifecycle.

[Slide Build]

We use CDNs [beyond their core content distribution function, we can depend on their security functions] mostly for DDoS protection or volumetric attacks.

[Slide Build]

We use WAF [Web Application Firewalls] for some known signatures and so on. 

[Slide Build]

And we even use API gateways, typically implemented by the developer teams or DevOps. They're not security products by themselves but they can provide some level of API management.

With all these controls, these green lines represent the normal accepted traffic that passes authentication authorization and goes directly to these microservices. But the green traffic is actually the riskiest traffic, because it has access to these microservices; it has access to the PII, to financial records, financial transactions, and money movement.

Once the traffic is authenticated and authorized, there is nothing to stop it. There are no security controls implemented on top of API traffic unless it's hard-coded in the application itself. So API traffic is really the most risky and most sensitive, but it's not really monitored today. There are really no good controls on that traffic. And this is really the main challenge that we see today.

The other controls visible on the slide were designed against random bot traffic or random vulnerability scanners. Or, as another example, unprotected WordPress sites. These are attacks that a WAF can stop. 

But APIs are different.  They're more business-specific. There's nothing that the WAF can do for that. So that's where existing controls fall short.

Slide 11:  New Challenges in API Architectures

Thinking about the differences between protecting web or mobile applications, and between protecting B2B APIs, there are some major differences that I want to highlight here. 

One of the differences is that typically, when you have a web application that you expose to your customers, one big challenge is that you need to manage it very well. 

In contrast, when you expose B2B APIs, you expose quite a few of them. And the APIs create multiple channels that have different types of information exposed, different access types, and so on. This is much more complicated.

With web clients, you typically can run your own code on the client side, and even sometimes running an SDK on the mobile device. 

Again, in contrast, when you expose B2B APIs, you can't really run anything on the client-side. You actually have no control over the client. You don't know what the API user is going to implement. Rather, you expose the APIs and require some kind of authentication model, but that's it. So we really have no visibility of what's going on in the client-side.

And, traditional web applications typically are very focused on end users. 

While, again in contrast, B2B APIs are focused on partners. Plus, varying API access controls are more complicated and nuanced. So there is typically more access per client and again, very hard to monitor whether an API is being done right (correctly) or used for the right purpose.

And maybe the most difficult of them all is the fact that when you have a web or mobile application, you can assume that there's an interactive user on the other side. 

So, as a programmer, if you're in doubt, you demand some form of multi factor authentication (MFA). 

But for machine-to-machine, B2B APIs, you can't rely on MFA. You still need to give access to sensitive information. Without MFA, the developer has a lot of challenges to getting security right.

Then finally, breaking down the application into microservices is another component here that adds complexity because, on one hand, it simplifies each microservice. But on the other hand, it makes it harder to see the bigger picture. This means that each microservice can only see its own picture. It can’t make decisions based on the bigger picture, because the microservice lacks it. So, it really prompts for a better way to look at the bigger picture. 

Slide 12:  Business Risk

At the end of the day, we want to protect against business risk. We want to avoid data leakage, such as PII or PHI, we want to avoid monetary loss as a result of bad money movement via API abuse, and so on.

So these are the things that we want to focus on. It's not a technical infrastructure question that we're protecting against. It's really about the business risk, and, again, protecting our core business functionality. And that also makes it a bit more broad than kind-of-simple infrastructure-based security.

Slide 13:  API Security Flaws Result in Data Breaches

We see a lot of these recent attacks. There are a lot of different examples. Just summarizing the state of API security, it's pretty clear that right now we're seeing many more of these API-driven attacks. Because the money is there, the information is there. Therefore, attackers are targeting these API infrastructures, that by design expose that information to the outside. Of course, sensitive data should be exposed only to authorized users. But again, an authorized user can get compromised, so attackers typically focus on getting a user compromised and abusing API-based applications.

Slide 14:  API abuse case analysis

Let’s take a look at abuse case analysis. If we take a step back, after everything that I've presented so far, there is a structural or systematic way to reduce that business risk. I think when we implement API security, it's not about just technical controls, it's really understanding the business risk and reducing that business risk.

At Neosec we came up with that framework. We call it abuse case analysis.  It's basically the opposite of describing the use cases that the APIs implement. For every API, and every corresponding business use case, there is also a set of abuse cases that can be attached to that API if the access is in the wrong hands. Or, if it's used incorrectly and have adverse effects on our business.

Slide 15:  API abuse case analysis

We created a relatively simple process of going through that abuse case analysis. And abuse case analysis is more like a risk analysis task: it’s not super technical. It's not like writing code or configuring a system. It's really about understanding your business risk and how it relates to your APIs. And I think this is the most important starting point.

1. The first step is really identifying what you expose. Is it a new account creation for a financial institution? Or is it paying invoices or accessing invoices. Is it authenticating endpoints that are exposed to the outside creating reservations? These are just some examples that we see in our customer's environments. Typically, there's more than one type of service that you've exposed to the outside, but you usually know about the most important services that you expose because that's part of your core business.
2. The next question is, which entity is using these APIs? In other words, who are the clients of these APIs? Is it an end customer? Is it a B2B partner? Is it some other type of entity? Identifying these entities is key.
3. The next questions are: What happens if that entity becomes compromised? What's the risk? Do we work with just one or two partners where API usage is very controlled? Or, are we working with 1,000 partners because that's part of our business model? Because then, the likelihood of a partner getting compromised is actually very likely. Understanding what happens if the entity becomes compromised is key. Another risk type is what happens if the entity misuses or abuses the APIs. Again, in some cases, it's not necessarily that a legitimate entity is trying to hurt you. But sometimes partners or customers may try to do things that are beyond what you expected them to do with the APIs. APIs are typically very accommodating: they provide access to different types of objects, and so on. So they can typically allow the user to do more than is strictly needed. This is another area where some mistakes or some misuses of the APIs can also have an adverse effect.
4. The last question here is, what is the potential loss? Let's say if that client becomes compromised, can somebody use it to access PII? Can somebody use it to create or cancel some financial transactions? So this is where you can have some monetary loss, and so on.

With these four simple steps, you can go through the different types of services that are exposed to the outside, even without having a full API inventory, just understanding what is exposed to the outside. And you can, by answering these questions, come up with a good risk analysis that maps different APIs or the different types of APIs that you expose to the outside maps them to the business risk.

And this is really the first step to understanding where your business risk lies. The first step of understanding where you really need to focus, from an API security perspective. 

And this is also the best way to get the budget and attention for API security because it's your core business to protect. It's not just another infrastructure or another buzzword. It's not just another container environment or configuration of something, this is our core business that we're protecting. So just understanding that linkage between the core business and these exposed APIs, and the need to monitor them is really key to plan for securing the APIs.

Slide 16:  Abuse cases are not always vulnerabilities

I have a note here about the difference between vulnerabilities and abuse cases. Abuse cases are much broader than vulnerabilities, where you have some imperfection or design flaw or error in your API implementation that makes it more susceptible for being attacked.

Abuse cases are more, from a business perspective, what could the attacker want to achieve? Is it credential stuffing? Which refers to guessing usernames and passwords and having access to their information. Is it the creation of fraudulent reservations or fraudulent transactions? Vulnerabilities are only one small component here. Our goal is not just to avoid vulnerabilities, I think it's an important goal. But it's also to understand these abuse cases.

Audience Question

Edward: This question came in: I can only imagine which business problems are occurring in our APIs. I have no idea which APIs my organization has exposed. Will you be addressing that and how do I solve that problem?

Giora: The question touched on a very important point: The first step really is understanding what APIs are exposed and mapping them to business risks. We'll cover that in the next slides. 

Slide 17:  API priorities

Let's go one step forward and speak about these different types of APIs and how we identify what we expose.

Slide 18:  What is your API landscape?

When we think about our API landscape, we have different types of APIs that are exposed. We can broadly speak about three different groups of APIs by priority:

1. The first priority is definitely the North-South APIs. These are the APIs that we expose to the outside and to our customers or partners. It can be through a web application that we expose or a mobile application. But it can also be machine to machine B2B APIs. These APIs are the most risky naturally because we don't really control the client. Anyone can access them, albeit with some gates and controls. We spoke about account takeover and compromised partners or customers. These are typically the most important to look at, and where you would start.
2. The second priority is typically understanding your East-West environment. Meaning, that understanding your API traffic between different applications and between different business units. This is more like control APIs that are used between your own systems you have control over both sides. But getting that visibility is important for understanding what type of information passes. And, crucially, if there's any type of abuse or wrong access to the data between these systems.
3. The third priority is typically outbound APIs.These are the cases where your own code is calling outbound services on the outside. And perhaps transferring data to the outside. Having some control over that is also important. But it's typically the last priority because you kind of have the control on your side in what you're sending and what you're doing.

We see that in most organizations, the majority of the focus is on the outbound, or North-South, APIs. Importantly, they can be authenticated. But, of course, the authenticated ones are the most critical ones. Because they have access to sensitive data and information that needs to be used only in a certain way and can be abused.

Slide 19: Which API problems?

What are the API problems that we see? That kind of goes back to the same question of how do I discover my APIs? So the first problem is a lack of discovery or lack of inventory: we call them shadow APIs, that are not well documented and you lack a good inventory of them. Or the documentation you have may not be up-to-date or maybe there are new parameters, or new APIs, and so on.

We have found that in most cases this represents a huge problem. We see that the majority of the APIs are typically in the shadows, meaning that they're not well documented. And I think it's also important to say that it's a continuous process: It's not enough to just go in and create an inventory once or get the documentation from the developer team once because we have seen that APIs are changing all the time. So this is definitely a recurring problem and typically the first problem that you need to solve.

Once you have the inventory, or, ideally, continuous inventory, you face the additional problem of finding API sensitivities and vulnerabilities. In other words, finding the security posture of these APIs. The goal is to find vulnerable APIs, and fix or improve their implementation or deployment to make them less vulnerable or less prone to different types of attacks.

Another set of problems with nuances. Perhaps problems with the rate-limiting, or problems with authentication and authorization. Cases where sensitive information is passed in a way that if information is compromised. There are a lot of different practices that can be missed.

Even more complicated is that it's not only the code of that API, it's not only the implementation, it's also related to the way it's deployed. If an API is deployed without proper controls, or without proper authentication or rate-limiting, it's still vulnerable. So it actually depends on a few different teams that are involved in the process.

The third type of problem is even harder to solve, but it's also really important. Even if your APIs are perfect, meaning that they don't have any vulnerabilities, they're deployed in the best way, they're well documented, you have all of that figured out, they can still be abused. If somebody takes over your customer's credentials, or performs an account takeover on your partners, they can still abuse their access and manipulate your data and your transactions.

So being able to avoid API abuse is a bit harder because it's not something that you can avoid in advance. Rather, you need to see how your APIs are being used. And you can't not expose these APIs, because that's part of the business. These issues can come up as a result of wrong use of APIs, or abusing these APIs, by attackers. It can be data scraping or manipulating some transactions, or money movement. There are all sorts of cases where APIs can be used against you. And that's a huge set of problems that you need to solve. You are seeing three main buckets or categories of issues.

Slide 20: Practical Guide: Where to start

So, with that, I wanted to maybe talk through some practical steps of what you can do and where to start. So you can answer the question of, what can I do in order to start addressing or solve that problem?

Slide 21:  API security maturity model

Based on discussions and work with our customers, we came up with this maturity model, which delivers a model, that is, a step by step model and plan that can take you from base zero, where you are today from an API security posture or maturity standpoint, and take you all the way to full maturity. I think it represents actual steps that you can ask yourself “do I do that or do I not do that?” “Do I have that visibility or not? So let's start from the beginning.

The most critical step to even start that discussion is having that basic visibility, without which you can't even know your inventory. A way to get visibility is accessing the logs that represent exposed APIs and how they're used. Access logs exist for compliance purposes, which is what we see in our customer environments: Most companies already have access logs for critical services exposed to the outside. Basic compliance drives a logging policy, which typically states a requirement to log incoming API calls.

But we see that log verbosity is not good enough. The logs are present, but you can’t do a lot with them. For example, we see this common mistake: the IP address is logged, but it’s the address of your CDN or your proxy. This is an internal IP address that can’t be traced back to who actually called the API. Another common mistake is that the timestamps are not good enough. In general, there's not enough verbosity in terms of parameters.

Such small details need to be reviewed and addressed. The good news there is that moving from less than perfect logs to really good logs is actually not that hard, because you already have that component that creates them: your WAF, your CDN, or API gateway, or one of these components. You just need to set up the right logging policy, typically just a few parameters to tweak. That's a step that you can take today. It doesn't take too long. You just need to know what to expect and what parameters to look for.

Audience Question

Edward: Another question that's come in says, looking at all our logs for APIs sounds impossible and time-consuming. Is it actually even feasible to have somebody looking at those?

Giora: It's impossible to look at all the data manually. You need technology to do it for you. But no technology can do any good without the data. So starting by having the logs is really important. And the logs can also be very useful if an incident happens so you can investigate. Without proper logs, you won't be able to investigate.

For investigation purposes, I think it's really important to get the log straight. But to answer that question directly, in order to do proper analytics through the logs, you need some kind of behavioral analytics product that employs AI and can analyze the logs in depth. Otherwise it's really hard to do it manually.

Edward: Thank you.

Giora: Now, the second step is the discovery process, creating an inventory of all your APIs. This is a critical step: without an inventory, you don't know what you need to protect, and you don't really have a plan. So getting that inventory is important as a first step,but it's also important to do it continuously.

Here are some guiding questions: 

• Do you have good knowledge of all of your microservices?
• Do you have a list of APIs?
  • Do you know all their parameters?
  • Do you have their Swagger files? 

Typically, you have some partial answers to that: some Swagger files for some of your APIs, and so on.

Working with our customers we discovered that there is a big gap between what they think they know and what they actually have. Finding the right technology to give you continuous discovery is important, because that's your way of always being on top of it. Thinking back to the digital transformation steps earlier: Instead of playing catch up with the developer team to provide the documentation, then maybe get it or not get it on time.

But in fact the developer team also has limited visibility. They know what they develop, but they don't necessarily know how it's exposed, how it's configured, and so on. They don't necessarily have all the answers all the time. So you need more of an automated approach here that takes a look at your logs and gives you the complete picture of everything that is exposed, everything that is out there. This is the key for API discovery. In order to do it, well, you need to focus on the breadth of discovery. I'll speak about it on the next slide.

Once you have a full API inventory the next step is the risk audit, finding API sensitivities and vulnerabilities. This is also a continuous process, because we have seen that APIs keep updating. The goal here is to find evidence or telling signs that we can improve in the APIs that typically fall in the OWASP Top 10 or OWASP API top 10 categories. But remember that the OWASP Top 10 lists are only high level, top 10 lists of vulnerabilities.

We want to be able to detect specific cases or occurrences of these vulnerabilities. There are many specific flavors of these vulnerabilities and therefore, you need a systematic way to do it. The goal of the risk audit is to make sure that everything is well known and you can find a list of vulnerabilities or a list of prioritized fixes, which can then be implemented, improving API security or the security posture of your APIs.

But we have not discussed runtime API abuse. You can do discovery and risk analysis based on the runtime data. That's the beauty of having a very rich runtime data set.

And the next step is doing behavioral detection, which goes back to the abuse cases, to identify the different cases where the APIs can be used against us. We need to ensure we have a good way to detect these abnormalities. Ideally, we want to be able to detect them automatically. And if we detect, of course, we also want to be able to respond to them automatically.

For example, if we detect a credential stuffing attack, where somebody is trying to guess usernames and passwords, we want to simply know about it. But we also want to automatically respond and block that IP range or significantly rate-limit it for a certain amount of time, to try to make sure that they don't succeed. 

But we also want to make sure that if they do succeed, we know about it, and we can actually reset and potentially contact the compromised users. This is an example of the detection and response process for credential stuffing. The model can be applied to other types of attacks.

But the only way to do it at scale is somewhat similar to the way that XDR works: If you can investigate and to threat hunt, basically the ability to improve the detection process, create better responses, and investigate cases where you find something.

Threat hunting is critical: It relies on good data and good access to the data. Without the right data you cannot really investigate. With the right data and the right technology, then you can investigate it: you can threat hunt.

Audience Question

Edward: I've got a question here that says, Where do you think most companies are today on this model? Are any specific industries further along than others or is it just random, just depending on the company?

Giora: We see that most companies are still focused on step two: They have some logging, and there's always something, or sometimes, even a lot, to improve. But step one is really easy: once you focus on it you can get through it pretty quickly.

The discovery piece is hard because all of a sudden you have hundreds and hundreds of APIs or hundreds of services that have many APIs each. Coming up with a good plan for these APIs will take time and technology, because it’s not possible to convert logs to an API inventory without technology that takes some implementation. But once you have the inventory, you can actually start asking the right questions about API security posture and behavioral analytics.

We definitely have seen cases of more mature organizations that have, for example, a smaller number of very high-value services. In such cases the focus is not necessarily the discovery part. Rather, it's more about detecting and responding to different types of threats that happen to them on a daily basis.

One thing that is important to realize is that API attacks are unlike what we're used to. We are accustomed to enterprise security and attackers with lateral movement moving across our networks. APIs are different, they are already exposed to the outside where the attackers already are. In this situation the question is: what information they can gain and whether or not they could compromise your users. In many cases attackers can gain some information, and can compromise a few users. These types of attacks don't necessarily take down your business, but definitely cause damage, which can be quantified in different ways.

In these use cases, it's not always “all”, for example, losing your entire customer base, or “nothing”, meaning that you’re fully protected. There are many cases where you get attacked and lose something, but not necessarily everything. You still want to avoid cases where you lose something because such cases can accumulate. But, every time you lose something you can translate it to monetary loss in different ways or potential loss. So you want to avoid even these use cases, unlike a big breach which requires advertising in the media.

Slide 22: API Discovery: Breadth of coverage matters most

A few words about the breadth of discovery: I think it's clear to understand that discovering your APIs is important. But I think what a lot of people miss is the fact that the most important parameter in discovery is how much you cover: Do you really see all of your different microservices, or do you focus only on one microservice or one environment that you already know about?

Because if you focus on the environment where you already have a good relationship with the developers, you already know about it; they give you some documentation; maybe verifying that their documentation is current: these only solve a little bit of your problem. What about the hundred other microservices that are not well documented, and maybe some of them are legacy. Maybe for some of them, you don't have active developers maintaining them.

These other services are even more critical. And therefore, when you do API discovery, the most important thing is to focus on the breadth of coverage. And in order to do that, you need a centralized approach, it's not enough to just work with a single developer team and install sensors or do something surgical for that. You need to have a much broader access to the logs, and be able to see things across your entire infrastructure, rather than focusing on one single service. This is really a very significant learning we have gained from working with the largest and most complicated organizations: API discovery breadth makes a difference for them.

Slide 23:  Importance of data for API detection & response

Another component important to take into account is the data. I started and actually ended with the data when it showed the different steps here. 

[brief return to slide 21: API security maturity model]

 I started with access to the logs and I ended with access to good investigation, that is, good use of that data.

[return to slide 23: The Importance of data for API detection & response]

It's really all about your data. My previous experience building XDR: The huge evolution the enterprise security space went through: the huge transformation was from anti-viruses and the use of more and more signatures, accumulating more and more signatures on and then evolving to a different methodology that just uses the data in a much better way: Behavioral analytics that give you a much more fundamental way of finding these problems. Rather than looking at each specific instance or each specific attacker, and any other unique signature.

The same principle applies here. You need to have rich data that represents user or client behavior. In addition to the data, you need to make sure that you also have the needed focus so that you can actually go back and look at your data, for example, at least in the last 30 days. I can't imagine any investigation that doesn't take into account the last 30 days. The window of enriched [data], good that [it] is kept, and including the right way is critical.

There are a lot of different approaches but the only approach that can work at scale is one that leaves you with both the data and the ability to investigate and threat hunt, because you investigate only some cases. But without that capability, you can't really scale these investigations in your organization. That's really important.

Slide 24:  Reinventing API Security

Some closing words: At Neosec, we're going through different stages. We’ve created a SaaS platform that can take every organization from log analysis, understanding what you have today through API discovery which happens continuously, API posture, detection, and response. And then, of course, investigation and threat hunting. 

We created a platform that does it from the beginning to end. It's a data analytics platform. It's not something that you can just deploy and expect it to operate on your data and just emit alerts. Rather, we do analytics to do it right.

Slide 25: Learn More

Edward: I just want to remind people that we have some white papers for you to download:

• The dos and don'ts of modern API security. 
• 12 questions to ask your API security vendor 

These papers are quick ways to give context for thinking about API security.

Audience Question

Do you have any real-world examples of API abuse that you've seen, that might illuminate this problem for us?

The real-life problems are exactly those soft cases, where we all hear about the breaches, such as headlines saying, Some kind of exposed API that nobody discovered. There are so many of those that we can search for them on the internet. I think the more practical examples are not these extreme use cases where nobody actually did discovery.

I think it's these cases where it actually causes some damage continuously! On many platforms, we see credential stuffing, for example, with people's accounts getting compromised followed by attackers accessing their data. We see platforms where partners can get compromised, and then attackers access the partner's data and customer data as a result.

We see cases of data scraping: APIs are designed to give access to the data. So the attacker can use that acces in order to scrape and accumulate too much data. These are the kind of day-to-day examples that we see and can happen in any environment.

Audience Question

Doesn't a bot solution handle most API abuse cases on the website?

Bot detection can only help in cases where you want to differentiate between human behavior and a bot that is imitating human behavior such as in a web application or human interface. But most of the APIs that are in question today, the reason why API security is becoming so important, is because all these interfaces are actually not meant for human usage directly, they're really B2B.

Sometimes there's a human in the loop somewhere. But API’s are back-end connectivity between different businesses, and it all looks like bot traffic! It's all automated and created like machine-to-machine traffic. So bot detection doesn't do anything for these environments.

Edward: All right, thank you very much, Giora. I appreciate your time. I appreciate all your attendance today. And please go to neosec.com if you wanna learn more about this problem. Thank you very much.

Giora: Thank you.