Guest: Michelle McLean
Company: Salt Security
Show: Let’s Talk

I sit down for a chat with Michelle McLean of Salt Security to discuss the key findings of their recently released State of API Security report.

In a discussion about API security, Michelle McLean, VP of Marketing at Salt Security, hits the ground running by talking about the interesting findings that came to light in their latest State of API Security report. McLean starts by commenting on the results, “It’s a combination of sentiment, how people are feeling about things through survey data and survey responses, as well as empirical data that we pull from the SaaS platform that supports our Salt customers.”

The results of the survey found several interesting attributes. They found that API traffic grew 141% over the last six months and malicious API traffic grew 348%. As a result of that growth, they found 64% of the respondents had slowed application rollouts over concerns for API security and 94% of respondents had experienced some form of an API security incident in the past 12 months. As to the survey as a whole, McLean believes that “the high rate of attack traffic, the breadth of attacks, just the fact that it’s happening across so many people and that it’s slowing down how they’re doing innovation…are the most telling results.”

Clearly, this report indicates that APIs are a big source of vulnerability, but (according to McLean) not because they are always terribly written, but because attackers have “clued in to the fact that APIs are a great place to hunt.” McLean points to the App Dev patterns over the last several years and says, “Security has kind of constantly been in catch-up mode, right? We’ve moved to Agile and DevOps and security is sort of like, “You know? Hold on, let’s go check out the security of all this stuff.” So, they’re used to being in catch-up mode.”

This places an enormous responsibility and prudence on the part of companies to ask the questions “Hey, are we really ready?” and “Have we really done everything we could on the API front?” In McLeans mind, this is a good sign that these businesses recognize the risk factor and how attractive APIs are as a hacker target.

Because we live in an API-driven world, everything is growing more and more interconnected. And every business that wants to offer more services is enabling them via APIs. To that end, according to McLean, “We’ve got to watch the back end of it. We’ve got to watch the piping if you will because again, hackers have realized an API is essentially a map straight to your most valuable data and services.” She offered up an example of the Peloton hack, where a hacker was able to get personal and private data by placing all zeroes for the birth date. She says, “That’s really where security monitoring tools need to come in to help, to recognize that this is happening. Somebody is using this API but in a really different way. And you’re not going to do that with people. And you’re not going to do that with existing technology that just takes a quick snapshot in time.”

She then addresses the difference between legacy and API security. The difference is that every API is unique to the company “and therefore, every API vulnerability is inherently a zero-day vulnerability.”

So what can companies do? The first thing companies need is awareness. As McLean puts it, “One of the things that we learned in our most recent study was that with half the organizations, there had been no awareness of the OWASP API Top 10 list.” Having a security team that takes the time to review, along with the DevOps team, what’s happening with the OWASP API Top 10 will go a long way to boost API security. And taking the old-school approach of “We know everybody in our community and everybody logging into our systems, so we’re okay” isn’t okay. Why? Because hackers break into accounts and make use of them. Because of that, it’s important to teach what forms the attacks take, how they happen, and discovering what can be really valuable from an input validation standpoint on responding to an API call.

Understanding what’s happening in an environment is key. And don’t set yourself up for forever fixing things in runtime. Get to the root of the problem.

Summary for this interview/discussion was written by Jack Wallen

Here is the edited transcript of the interview.

Swapnil Bhartiya: Hi, I’m your host Swapnil Bhartiya and welcome to TFiR Let’s Talk. Salt Security recently released their State of API Security report. And today we have with us, once again, Michelle McLean, VP of Marketing at Salt Security to talk about the report. Michelle, it’s great to have you on the show once again. Let’s deep dive into some of the key findings of this report.

Michelle McLean: You got it, Swapnil. It’s such a pleasure to be with you again. Thanks for your time. So we’ve found some really interesting findings across this report, and it’s a combination of sentiment, how people are feeling about things through survey data and survey responses, as well as empirical data that we pull from the SaaS platform that supports our Salt customers. So, we found a number of attributes that are pretty interesting. We always want to understand growth rates, right? What’s happening across API traffic, broadly speaking. So we’ve seen just in the last six months, (because we did an earlier version of this study six months ago), API traffic grew 141%, but malicious API traffic grew 348%. So, it’s really staggering. It’s still not a huge percentage of overall traffic, but it is amazing to see how attack traffic really keeps increasing at a very high rate.

As a result of that, we’ve seen almost two-thirds of survey respondents, 64%, say that they had slowed application rollouts over concerns about API security. And I think one other really telling result from the survey was that 94% of respondents had experienced some form of an API security incident in the past 12 months. So, there’s lots of detail in there. There’s dozens of findings and dozens of reports. But I think the high rate of attack traffic, the breadth of attacks, just the fact that it’s happening across so many people and that it’s slowing down how they’re doing innovation, I think those are the most telling results.

Swapnil Bhartiya: Slowing down the release because of API security concerns? Well, that could be a worrying signal but this is better than releasing unpatched or vulnerable code. But how do you look at this problem?

Michelle McLean: Well I think what it speaks to, is just that people recognize that APIs are a big source of vulnerability, not because they’re just always terribly written or anything like that. But I think in large part because attackers have really clued into the fact that APIs are a great place to hunt. And I think companies are realizing that it’s hard sometimes to get a handle on what’s happening on the API front. Think about App Dev patterns over the last several years! Security has kind of constantly been in catch-up mode, right? We’ve moved to Agile and DevOps and all this, and security is sort of like, “You know? Hold on, let’s go check out the security of all this stuff.” So, they’re used to being in catch-up mode.

I think it’s actually an enormous sign of responsibility and prudence on the part of these companies that they would take the time to say, “Hey, are we really ready? Have we really done everything we could on the API front?” So, I see it as a good sign that they recognize the risk factor, they recognize how attractive APIs are as a hacker target and they’re looking to be responsible about how they innovate. I think the onus is on the industry then, to help companies be more efficient in tracking their APIs, understanding the status of their APIs, getting that runtime protection in place so that they can know that they can innovate pretty fast and yet still be safe. I think we just need to get to the next level of process, people, tooling to one level more mature. And then, I think the innovation can resume quite quickly.

Swapnil Bhartiya: Will it be wrong to say that we kind of live in an API-driven world because  everything is being driven by APIs around us? How do you look at it from a security perspective? 

Michelle McLean: You’re so right about us living in an API world. I was just trying to explain to my dad the other day what we do and he was like, “Well, what’s an API?” And I was like, “Okay dad, do you ever do mobile check deposits?” He’s like, “Oh yeah, yeah.” And he’s really proud of himself. Like, I have a mobile app on my phone and I can deposit checks. And I’m like, “Every time you launch that app, dozens of APIs.” I say, “You know, I take Lyft to the airport, dozens of APIs. I went traveling with some friends and we settled up a bill. I paid my friend over Venmo, dozens of APIs.” So as consumers, every day, we’re encountering hundreds of APIs. And it’s been an incredible driver of innovation. Think about all the connectivity that it’s enabled for.

It’s amazing what you can do on a platform today. And all of these businesses that want to give us more services and give us more functionality, they’re all enabling it via APIs. So, there is an enormous opportunity for innovation, an enormous opportunity for simplicity. It’s just that we’ve got to watch the back end of it. We’ve got to watch the piping if you will, because again, hackers have realized an API is essentially a map straight to your most valuable data and services. So if I’m going to go poke around and see how I might break into you, this is a great place to do it because they’ve realized existing security tooling doesn’t fit the bill. They can’t detect API attacks. They’re very different. They’re very deliberate.

And they’re very conscious because what a hacker has to do is understand… What did the programmer mean for this API to do? And if I do something slightly different with it, what’ll happen? Think about the headlines we’ve read. So many headlines around API breaches. The Peloton attack was an interesting one. This person was able to get all this personal data, private data of Peloton users. And in the end, what he figured out was if I just put all zeros for the birth date, then I can get back the information of any number of users. That was not the first thing he tried, right? That was like the 20th thing, 25th thing.

And it’s that low and slow, it’s that reconnaissance activity. That’s really where security tooling needs to come in to help, to recognize that this is happening. Somebody is using this API, but in a really different way. And you’re not going to do that with people. And you’re not going to do that with existing technology that just takes a quick snapshot in time. This transaction… Is this okay? Yeah, it’s probably fine. The fact that my birthdate is all zeros. Well, they’re all numbers, right? That looks okay. So you need another level of sophistication to even see what people are doing because they have to understand the business logic to hack an API. And you need technology to help you identify that reconnaissance activity.

Swapnil Bhartiya: How different or unique is security when we look at APIs? Because sometimes when things are running in your infrastructure, your workload, you have full control but with APIs, things change dramatically. So where does the buck stop? Who is responsible and how? Basically what I want to understand is, how different is the challenge that APIs pose versus the traditional ones?

Michelle McLean: You make a great point because in a lot of areas of security, we’re kind of all universally at risk, right? If there’s a problem in a Mac software package, then all of us running that software package have that vulnerability, or if they figure out a problem in a lower level OS. You know, “Hey, there’s this vulnerability in Linux.” Then all of us running Linux are susceptible to that. I think the biggest thing that’s different about security in APIs is that every API is unique to the company. And therefore, every API vulnerability is unique to the company and is inherently a zero-day vulnerability.

And the way that you protect yourself against zero-day vulnerabilities is very different. You’re not going to find it in static code analysis, because it’s through the running of the API that the hacker can make sense of things and can try to figure out what you’re doing, and then manipulate things to pull back interesting information, for example. So it’s a fundamentally different problem. It’s not a set of published vulnerabilities, and it’s not a set of known attacks. It’s not like, “Well, this is how cross-site scripting works. So, if I protect myself against cross-site scripting, I’m going to be good.” Every API is unique. Every API vulnerability is unique. Every API attack is unique. So, you need to be understanding the context over time of what’s happening in the usage of your APIs to even begin to combat the problem of API attacks.

Swapnil Bhartiya: Now let’s switch gears and talk about the solution areas. Of course, we can talk about Salt, but if I ask you in general what are the things that companies can do to protect themselves or prevent API-related breaches, what would those be?

Michelle McLean: You’re right. It’s not all about just the tooling, although I think that it is important because again, it’s really hard for humans to keep up. I think the first thing is awareness. One of the things that we learned in our most recent study was that with half the organizations, there had been no awareness of the OWASP API top 10 list. And just reviewing, having a security team that takes the time to review with the DevOps side what’s happening in the OWASP API top 10. Everybody’s used to the traditional OWASP top 10, but a surprising number of people don’t realize, OWASP took the time to document an entirely new set of attacks, that are API-driven attacks and teaching developers, the forms that those take, why they happen. One other statistic was that 94% of attacks happened against authenticated or end points.

So, the idea that “Well, we know everybody in our community, we know everybody who’s logging into our system, so we’re okay,” does not work, because the hackers get accounts and go make use of them. So, teaching them what forms the attacks take, how they happen, and therefore, what can be really valuable from an input validation standpoint on responding to an API call, that kind of awareness is I’d say the first priority. The second one would be assessments. And here, there may be some technology that comes into play because there’s part of what you can do with code assessment. But there’s a lot around just understanding the baseline of your APIs. How many do you have? What’s the gap between what you thought you had in terms of documentation from developers, and what some tooling can discover across your entire environment?

So we know where the gaps are? How frequently are my APIs changing? Where are my APIs exposing sensitive data? You just have to understand what’s happening in the environment first. And then I think the third element is working on that collaboration. So, how do you begin to plant the seed for security to give some input into developers around hardening APIs? You don’t want to forever fix things in runtime. You want to get to the root of the problem. We do see it as a sequencing thing where you really want to get safe in runtime, and then give those insights into developers but begin to lay the groundwork for how you’re going to build that collaboration. Are you going to develop security champions on the DevOps side? Are you going to embed security people within the DevOps teams? So, we’ve been talking about that notion for a long time of how do you build toward DevSecOps. As an industry, we’ve been talking about it for years, but you really do need to start planting those seeds because development cycles aren’t slowing down and this notion that security’s got to play catch-up is really tough and puts the business at risk. So the tighter you can make that loop, the tighter you can make that feedback loop, the earlier you get security eyes on things, the better off you’re going to be.

Swapnil Bhartiya: What would be the right technical, technological approach to API-focused security problems? And what is Salt doing in this space to help customers secure their workloads, environments, applications, as well as users?

Michelle McLean: Great question. So, the thing that I think is most fundamental from a technical standpoint, Swapnil, is this ability to deliver context. You can really only understand API hacking and manipulation if you’re watching something over time. What is everybody doing and what are the aberrations? So, the things that are different will stand out over time and can point to either, “Oh, everybody’s now doing it a different way, so this API changed…so I need to change my baseline.” Or it can point to hacker behavior. So, there’s a notion of context, just seeing the big picture so that you can understand anomalies.

There’s also then by user, having a notion of context. So, what did this person do an hour ago? A day ago? A week ago? How has that changed? Because attackers have all sorts of ways of hiding their tracks. “I’m going to do something with this IP address. Now I’m going to switch IP addresses. Now I’m going to look like I’m tunneling in from this region of the world.” But you need a way to broadly fingerprint that attacker so that everything they do, you can stitch together and correlate back to that user.

So, if you want context and you want an understanding over time, then the fundamental technology that you need, no surprise, is a combination of big data and AI and ML, and Salt actually has the broadest patent and the only patent for applying AI and ML to see API attacks and stop API attackers. And it’s really crucial technology because we’ve done tests time and time again in customer environments where they will ask us to do two things, they’ll ask us to propagate some attacks so they can understand what it looks like, or doesn’t get seen by existing technology, what it looks like in their WAF or in their gateway and most of the time it’s going right through.

And they also ask us to do one other thing, which is to actually try to hack their APIs and across those things they’re looking for, where are our vulnerabilities? What is our tooling finding? What is it not finding? Where do we need to update some of our business processes? You talked about the people components, Swapnil, and the need to not just have technology, but to feed this in. So, your SecOps teams now need to understand and be able to process an API security incident. That’s a different kind of incident.

Your developers need to be able to process tickets that have to do with, “Hey, this API has room for improvement. Instead of allowing six digits, you should always only allow five because that’s your standard format. So change the input validation to demand only five and all numbers.” That kind of thing. So, there’s a lot of work to make use of the technology, but I would say the first step is getting context through big data and AI/ML, and then adapting your people, processes to understand this information, and make use of this information so that your environment can become much more secure over time.

Swapnil Bhartiya: Michelle, thank you so much for taking time out today and talk about, of course, the findings of this report, and also share your playbook of how companies can try to at least protect or secure themselves, when it comes to API-related breaches. And as usual, I would love to have you back on the show.

Michelle McLean: Thank you so much Swapnil. It’s a pleasure to be with you again. Appreciate it.