Nick Rago – API Myth Busters: Five Security Myths Keeping you at Risk

Good day everybody. Thank you for joining. My name is Nick Rago.

I'm field CTO with salt security. Welcome to API MythBusters where today we are going to focus on crushing 5 API security myths that are keeping you and your apis at risk. Me personally, I've been around apis for quite a long time at this point been in the API security space prior to that in the API management space.

I've was on the Forefront of that space. I helped architect and Implement some of the largest API management digital transformation programs throughout the United States have run engineering teams involved with API design and development prior to that. So This session really is a collection of the top responses that I have gotten over the years here when I talked to organizations or ask them specifically.

What are they doing about API Security today, so we'll jump in and tackle each one of them as each one of these as we go through it. What I first wanted to do was kind of take a look at the problem and do it from more of an attacker's mindset or standpoint in terms of what the world looks like. From from their View and you know when we take a look at API attackers today, they're really taking advantage of these three facts that I'm about to show you here on the first is that apis are a different monster.

They're every endpoint provides a unique attack opportunity for you know, four would be attacker, you know, a lot of what we're seeing today and sort of the change in the world today has been around the fact that a lot of this application logic is exposed to the outside world before everything that we're seeing that sort of comprised of a business function or an application function was Embedded in functions in code behind some server on the back end and what we're seeing today with digital Transformations and app modernizations. Is that each one of those? Business functions or application logic functions is exposed as a unique endpoint each with its own unique application logic and code underneath it.

So from an attack standpoint surface standpoint this opens up a world of opportunity to to a would be attacker that coupled with the fact that apis are so frequently updated salt security recently introduced or published its state of API security report last month and one of the interesting metrics that came out of that report was that from the respondents Over a third of them are saying that apis in their organization are updated and published and change the weekly over 11% of respondents were saying that apis are actually updated in individual endpoints daily. So think about that, it's not just that there's this large attack surface. The attack surface is always changing what you know, what might not have been a good attack endpoint last week might have changed in his you know, something that is more that is more appetizing for an attacker to hit today.

So that that's an interesting, you know problem that sort of presents itself when we talk about getting in front of securing apis from application security standpoint. The second thing is Attackers are smart. They know that the security tools that were leveraging today that are typically in place today and most organization.

They they lack context and they're only looking for the known bad. a lot of the attack types that we see today and you'll see this as we go through the the time in the presentation here today in the session our application logic attacks our business logic attacks or you want to frame it and you know, if I don't know of vulnerability exists, how do I know how to detect it? How do I know how to prevent it and block it and so attackers know this so they know that the security tools in play today allow them some play so that they can do, you know application Level sort of reconnaissance.

I can talk in prod and figure out, you know for an app for and a particular API or a particular endpoint under an API where it may be vulnerable where it may be susceptible to an application Level dos type of attack again, you know attackers are understood what the limitations are from a security stack standpoint and Coupled with the third Point here and this metric is something that's derived from conversations. I've had with folks in the industry devops experts Dev psychops experts application or API management teams folks throughout the stlc involved in API production. Is that Currently today in the software development life cycle the best organizations out.

There are testing upwards to maybe 30% of application logic permutation before an API goes out the door. So think about that for a second. That means when an API sees the light of day I know what it's supposed to do and I've assured that it's doing it, you know from a functional standpoint, but I really don't know sort of the negative behaviors of that API.

If I poke in prod and Twist and Turn, you know, what are the negative behaviors that this API may bring to light out in production. So that is an interesting fact that again organizations, you know, the most the most mature organizations from a SecOps model standpoint are admitting that they're only testing about 30% application logic standpoints application Logic on these API. So again an attacker knows this they know the lack of context and the security tools that are out there and they know that you need opportunity that these endpoints are providing them.

So, you know that is a struggle for a lot of organizations, especially when you are attacking the problem from a more, you know, traditional security standpoint. So one of the you know one The first and probably the number one response. I'll get when I start talking about API security with organizations is my wife does API security and it prevents API attacks.

No laps really were not designed for the type of the type of API attacks that were typically seen today and I understand a bit of the confusion here in that, you know, if you look at some of the metrics from you know, the CDs like the atomizing cloud players of the world where they're saying a majority of you know web traffic that they're seeing as API traffic the laugh vendors, you know from, you know from a marketing standpoint have to sort of change and make sure they're addressing, you know, addressing the traffic types that are out on the internet fact in the matter is they're doing you know, only a subset of the protection that's necessary. It's a protect apis and and if we take a look at it. what a what a lack is good at they were designed originally to be run on signatures and rules to look for known bats, right one transaction at a time.

I want to be able to look for things such as SQL injections cross-site scripting code execution or script execution attempts. Now, these are the things that are why a wife is great at now with the Advent of you know, sort of Next Generation laugh our next gen laugh set of come out. These Technologies claim to build Dynamic rules and dynamic dynamic signatures.

But what we've actually seen out in the wild today is that they do not have the context to capture and to to detect a lot of the API attack types that we're seeing today specifically low and slow reconnaissance type of attacks. The behaviors of an attacker won. The vulnerability is one of the ability is found.

You know, these Technologies are looking at typically things slice of analysis time. Let's say, you know, maybe one transaction or a minute's worth of transactions and again does not have this particular technology in this way does not have the context to really have the the true ability to deserve to discern and run time on real time what the intent of a user is so what what the result of this is is when an attack is coming across the wire And it's presenting themselves with you know, multiple transactions over time. Laughs are are missing the attack altogether the second piece of this that we're seeing, you know more and more reports of is our wax that are sort of rightly, you know, they're they're raising the flag too often.

So they're filling up the you know with alerts in the sock about some some type of an anomaly that they haven't seen before and again without the context and without the large evaluation Windows to really get a good understanding of sort of the context of what an attacker or what a user is doing it's tough to nearly possible with this technology set to make a an accurate judgment column what the users actual intent ones, so Keep talking about you know Discerning user intent and and the only way to do that is to really have full context and Cloud scale compute power and Analysis power to be able to understand over a large analysis Windows. What an API consumer is actually doing over time. Is this normal?

Is this abnormal? What's the data type that they're touching? What are they done over not just in the last day, you know seconds minutes hours and days but weeks and months.

Is this something or is this a consumer that I need to be concerned? What should I block them? So this is a this is something that again laugh technology is just we're not architected to get in front of and detect especially to be able to do this, you know expected to do this in line with you know with minimal response overhead.

now the question often comes up about what is it? That is so hard about getting proper context. Why can't a laugh do this and and to understand this you have to understand to capture context.

What are the data elements that are needed in the you know, the analysis elements that are needed to really be able to discern user intent and in real time with no alert fatigue and no Miss security events. You know, let's take an API that has billions of calls per month. So the ability to actually analyze ingest take a look at not just request data, which is what most last will do but response data as well.

Convert all of that to structural metadators being understanding of how this how the request and responses are constructed the data types classifying the data types underneath it. Is this pii a social security number understanding, you know, per you know, per end point and per call the hundreds that thousands of Behavioral attributes associated with it what I mean by that is understanding, you know, how do I correlate who this particular user is? What are the what are the relationships of data parameter one always matches parameter five and the request parameter three in the request always matches a certain element of data coming back in the response being able to understand that relationship for each and every end point is important, but then being able to actually funnel that through in analyze that data across different analysis and now windows.

So again, not just looking at one transaction and comparing it to rules and signatures or comparing, you know a model against what's normal for a second or a minute of transactions, but being able to Actually provide context about understanding what's behaviorally normal over an hour day week month and Beyond. Feed That Into You Know mature algorithms and again be able to take all of this in an accurately discern in near real time what exactly the intent of the user was it's a good you know, is this a good API consumer or is this a bad API consumer? So that is something architecturally that laughs and next gen laughs just were not built to do and I think what's what's more helpful is to sort of illustrate this with with not just what others are saying in the industry like folks from governor who who come out and been on a record to basically say that hey the current architecture of laughs and you know, trying to block known attacks with rules and signatures or even you know, dynamic rules with sort of these next Generation Labs is just not sufficient and it's ineffective.

but outside of what others are saying is to actually see an illustration of a of a particular attack type and what I'm showing you on the screen here is Ed, you know example of an attack. This is a requesting a response if you're taking a look at the screen here and this is a typical attack type that we're seeing today an attacker. Maybe he's done some reconnaissance or stumbled on the vulnerability in the API now from a lab standpoint.

Nothing here is going to raise a laugh flag if I take a look at the request users authenticated in from a schema perspective. Everything looks great from a request response perspective. No malformed data.

No SQL injection attempts. No code no script alerts or anything or code execution. That's nothing like that.

So, you know for for known attack types of laps not going to raise a flag. For the next gen lapse they may be looking for certain things like in my scene parameters getting a numerated. Let's say over the last minute nothing like that here as well what the attacker figured out here was that there's a single ID Bola so broken object level authorization type of attack over 40% of API attacks that we that we see in the wild today or the bowl of variety where you know, I'm getting access to data to somebody else's day or data that I shouldn't be entitled to.

And in this particular case the attacker figured out that wait a second if I just changed, you know in, you know, this payments ID and the string here. I can get access to another user's banking information or private information through here now, behaviorally what the attackers do is they will not enumerate stay low and slow rather than do this, you know, a lot of transactions, you know in a second or a minute. I'm gonna kind of trickle the request over time hoping that my request kind of, you know, kind of get lost in the noise and and a lot of these low and slow type of attacks that we're seeing today.

That's exactly what's happening. So perhaps don't have the ability as their architected to be able to kind of crunch all the data as a as a kind of show to the previous that's in the previous slide before and to to make distinctions like this and this particular case. This is a a real time alert that's coming back and saying hey this payment ID prayer it was called with over 100 distinct values by the same user not the last minute or our second but in the last day 300% larger than normal.

And this user has consumed an enormously high amount of sensitive data in that time frame. So again, it's not just the behavior what they're doing but the type of data that they're touching as well that that, you know, a proper API security platform is going to be able to come back and and evaluate whether or not this is something that should be alerted to in the sock. For example The other thing is sort of the analysis over time.

So I mentioned we're looking at these small timeframes in from a WAP standpoint from from the analysis perspective is the ability to actually get that big picture of what an API consumer is doing over time and to have you know mature ML and AI models in place that that will accurately alert you when you need to be alerted back to the matter is, you know, the analysis that we've done, you know, a vast majority of anomalous activity or behaviors over the why or against an API are gonna are going to be it's going to be anomalous behavior that I don't want to be alerted to a developer mistakenly's bad thing. It's something on the keyboard. There was a glitch on the network whatever it may be but I do want to be able to you know, watch the behavior of particular API consumer over time and model it so that in compare that to you know, my my normal uses so that I can get A better understanding of exactly what they're trying to do is this just the you know it developer who's just has bad coding practices or is this someone who's doing reconnaissance against my apis?

Is this someone who's trying to who's trying to act out an application Level dos against particular endpoints or microservices. I may have exposed. So again, this is another big differentiator.

Versus you know, what what is needed from an API security Point standpoint versus what a laugh and a next-gen wow can offer from from a security standpoint? The next thing that we hear that I hear a lot is Hey listen, I have an identity provider. I have an API Gateway that does some security and in conjunction with my wife I should be you know, I should be protected.

I mentioned the state of API security report from Salt a little bit earlier one of the one of the interesting metrics that came out of there is that A majority of the respondents came back and said this was the security stock that was in play in their organization. You know, we have the API Gateway. We have an identity provider.

We have our laugh in place the other interesting metric that came out of that study was that 94% of the respondents came back and said that they've experienced security problems in production in the last year and 20% whether publicly or privately suffered a daily data breach resulting from an API security Gap with the security stock that they're using. If I sort of illustrate this just with kind of a with the with a graphic here and we kind of take a look at specifically the OS API top 10 type of threats that we see out in the wild today. A lot of these are behavioral type of attacks on on apis.

You'll get a good visualization of where wax gateways in either even governance by like OAS or Swagger docs fall short across a lot of these different attack types and again if I If I sort of illustrate this with an attack and kind of look at this from the frame of a y and identity provider and an API Gateway in this particular in this particular shot here, we're looking at a request against a customer's endpoint users authenticated in with the with the valid job token. I can see request payload response data coming back response had a response response headers response status codes here. The interesting thing here is that this is an entity a user that has proper authority to use this particular endpoint.

Now from a lab standpoint again, no flag would have been raised here. No malformed data. No code execution.

No script across state scripting or anything like that that's going to raise a laugh flag no data enumerations or anything like that. From a Gateway perspective user has the right to use this schematically the request the responses perfectly fine from Identity perspective the same thing. This is a user who has a valid token all the claims match up and they're allowed to actually use the particular endpoint.

Now the interesting thing here is this is an example of another Bowl. This is a dual life debola attack where the attacker figured, you know, wait a second once I'm authenticated And if I'm kind of highlighted on the left hand side here my user id claim inside the jaw token once I'm authenticated. All I have to do is change a cookie parameter and now I'm not getting my data back.

I'm getting somebody else's data back. So from an API Gateway standpoint, I'm going to stay low and slow. I'm gonna exfiltrate this data out of the organization over time and you know, no one's none the wiser in the API tax that we typically see in the wild today.

A vast majority of them over 95% of the attacks are coming from an authenticated entity that has access rights and execution rights for that particular API endpoint. Another thing that I frequently hear another response that I frequently here is that they listen this is something that we are going to and we are addressing in our SecOps pipeline. We have a very mature SecOps pipeline.

We're flushing out where you know any API security vulnerabilities in that Pipeline and in order addressing that in the SCLC today, these are organizations that also have very secure SecOps pipes and they suffered they suffer to breach if we take a look at a couple of them on the screen here in the case of experience. That was a partner API where if I put in information essentially from a phone book a name address and a name address and then I put up birth date as all zeros. I'm getting credit risk factors information.

I shouldn't about that particular consumer back to me through the API. That was an application logic flaw that with everything that was in that pipeline from on stlc standpoint and see I see perspective. That no one thought to test or was able to capture a test that was able to say what happens if I put in zeros as a birthday am I getting access, you know to data I shouldn't and the case of Facebook.

That was an interesting one because that was the merging of two sort of microservices are endpoints API endpoints hitting together. That was a view as API in a video upload API and that particular case the attacker figured out is if I sort of exercise these in a proper way kind of poking in prodding and kind of finding the right combination The View as API and Facebook was actually returning back with the viewed as entity and access token for the view and as entity so this was a breach that occurred over 18 months that Facebook with you know, all the Telemetry and you know in the in the mature pipe that they had in place did not detect for over 18 months at that particular point the attack or harvested, you know tens of millions of access tokens for account take over a purposes. But you know, the damage was done and a lot of cases it's not even your applic.

Nation that's the problem at the end of the day you may have you might have sort of flushed out all of sort of the the major API security vulnerabilities, but it could be an outside or an external Factor on the right hand side of the screen here. We've seen we've seen in the Press lately about app developers, you know away from the API development, you know cycle itself, but an app developer leaving access tokens in a manifest of somebody that sort of reverse engineers and mobile app gets access to those tokens. They're able to actually misuse the API we've seen studies about medical records applications that doctors, you know, small doctors offices uses and a lot of those medical record applications are having the same issues.

We're developers we're putting in in the Manifest API keys in the clear that a developer was able to take are able to take and get access to other folks medical record information again in those particular case the apis doing exactly what it's supposed to be doing, but there just was not an ability to detect that the API abuse was actually occurring And so we take a look at the at the CI/CD pipeline that we that most organizations are typically employing today. There's a lot of great stuff here. All of this is very necessary when I you know, when I plan and design my API, it goes through code analysis or you know code scanning and my build process.

I'll introduce SAS and Das scanning there. I'll release and then I'll you know, and I'll use my whack my API Gateway everything that I have out in the out in the throughout the stlc as well. But we're finding is a lot of organizations do not have specific checks for the API.

API security vulnerabilities that we're seeing today, so it's important that organizations take a look at their Pipeline and understand first and foremost before the line of code is written do I have you know, some type of API governance program where my developers are designing with OAS or Swagger and they're adhering to a certain standard before they even write a line of code as it, you know as the apis get developed and pushed into tests again, as we as I mentioned earlier, we're not flushing out application logic flaws. We're sad, we're fuzzing we're doing our SAS and our gas can we're looking for the known bad throwing a lot of things against the wall, but you know up until recently there really was no way in the pipeline to actually do this sort of contextual API security testing where I'm sort of learning the API as it's being exercised through the pipeline and then I'm using and I'm using ML and AI technology to play the role of the attacker again this Isn't going to be a full proof and it's not a foolproof technology. But if I can get that 30% application logic permutation coverage up to something better 60 70 percent whatever it may be my risk is is lower tremendously by the time I go to deploy operate them into into production.

The other piece is that they're just hasn't been a lot of organization organizations as these applications get into production good runtime protection and good Discovery capability. So this is an important part of it as well is being able to make sure that as these apis are being pushed production. You are you are you're employing continues API Discovery data classification compliance check so that you understand.

What are the apis that are out there. How are they use? How are they structured?

They're hearing the best practice from security point but most importantly what's the data that they're ingesting and then they're possibly exposing and then the last piece here is the cloud scale contextual runtime protection. We're already talked about this sort of why this is different than what the last do today again sort of that broad context ability to understand and discern user intent when they're using an API. this is very important again, not just for sort of sniffing out vulnerabilities that may be being being hit upon or being taken advantage of in production, but being able to capture attackers when they're doing reconnaissance and being able to and being able to capture API abuse as it's occurring Real quickly here number four.

I hear a lot as well. I'm sending my access logs to Splunk or log analysis tool or some other ml that I'm writing. You're only as good as your ml your AI and the data that you're feeding it.

I don't want to put you don't want to put sensitive data inside along analysis tools and and at the end of the day you are essentially against gonna be giving yourself a lot of noise that you have to sit through. So again for a lot of organizations that tried to attack, you know attack or getting in front of API security and this manner the good news is this is you know, this is all that was available years ago over the last five six years, you know, the Advent MLA Ai and the maturity of those Technologies from API security standpoint. This is something you don't have to do anymore.

And then the last thing here and I'll sort of wrap up the session is that we hear a lot that API security is complicated. I don't know where to begin. It doesn't have to be complicated.

I always tell people just kind of look at it in three different buckets first when you're taking a look and you're trying to tackle API security. One of the first things you need to do is have the ability to discover apis. What are my apis that are out there?

How are they used? Do I have Shadow apis that I didn't even know about that are actually used in in the wild and and getting a good understanding of that. The second thing is understanding with runtime protection.

How do I sort of cast the security in that over the apis that we have in place today to make sure again that people aren't finding vulnerabilities and taking advantage of them. Like we saw in the case of Facebook example where 18 months. Nobody knew people aren't doing reconnaissance.

I want to get in front of some of the bad reconnaissance and I want to stop and get in front of the API abuse where they're using the apis intended from a functionally, but the the intent of the user itself is is not something that we like and then the last please piece is addressing shift left. How can I over time Implement and reduce risk throughout this, you know throughout the sdlc and inject into my ci/cd pipelines technology and automation that will ultimately specifically for API security when we talk about application log, you can allow the philosophy API top 10 vulnerabilities start to flush out all of us. Again.

This is a this is a lot of newer technology here that's being introduced into the pipeline. And the goal of this is to limit risk and to find as much as you can before you get to product protection. I'm sorry.

It's a production. So again all of these in conjunction with each other. There's not one.

That's a silver bullet. The Silver Bullet really is all of these three. Together so for that I thank you for your time.

I thank you for attending the session. I love talking to people about apis and API security feel free to sort of scam here and let's let's hook up and Thanks everybody.