Guest: Michelle McLean (LinkedIn)
Company: Salt Security (Twitter)
Show: Let’s Talk
Keyword: API Security

Salt Security, the API threat detection company, has released findings of the 3rd edition of its State of API Security Report. The report found that the use of APIs grew significantly over the last 12 months. According to empirical data from the Salt Security SaaS cloud platform, overall API call volume increased by 321%. At the same time, malicious API traffic increased by 681%, outpacing the growth of overall traffic and 95% of companies surveyed in the latest report said they experienced an API security incident in the past 12 months.

Michelle McLean, VP of Marketing at Salt Security, feels that companies are still not prepared for API attacks, “We’re seeing that only 11% of respondents had any kind of dedicated API testing and run time protection.” She goes on to explain, “On the other hand, we had 34% of respondents having no API security strategy in place, despite the fact that they’re running production APIs. So we have some work to do to catch up to get ahead of this threat.”

A number of high-profile companies made headlines in 2021 suffering API security incidents including Peloton, Experian, LinkedIn, Parler and John Deere. Coinbase also disclosed a bug bounty where a white-hat hacker had discovered a crisis-level flaw that would have potentially bankrupted Coinbase.

Salt Security’s API protection platform looks across millions of users and API calls building a baseline of what’s normal for any given environment. It assesses what the sequence in which they are called is, the normal amount of data to come back and where the traffic is coming from? The platform harnesses big data, AI and ML to stitch together activity over time to detect, understand and block API attacks.

Although APIs are driving innovation, McLean believes that developers are often focused on the business logic and not necessarily thinking about the variety of ways that attackers could manipulate that and that leaves APIs vulnerable to attack. The report encourages companies to take action in implementing an optimal API security strategy.

About Michelle McLean: Michelle has more than 20 years of market positioning, GTM, and demand gen experience at a variety of enterprise security and other software companies. She’s held marketing leadership roles at StackRox, ScaleArc, Silver Spring Networks, and Peribit Networks. She advised clients on technology and strategy at research firm META Group and started her career as a technology journalist. Michelle earned her BA in English from the University of California at Berkeley.

About Salt Security: Salt Security protects the APIs that form the core of every modern application. Its API Protection Platform is the industry’s first patented solution to prevent the next generation of API attacks, using machine learning and AI to automatically and continuously identify and protect APIs. Deployed in minutes, the Salt Security platform learns the granular behavior of a company’s APIs and requires no configuration or customization to pinpoint and block API attackers. Salt Security was founded in 2016 by alumni of the Israeli Defense Forces (IDF) and serial entrepreneur executives in the cybersecurity field and is based in Silicon Valley and Israel.

The summary of the show is written by Emily Nicholls.

Here is the full unedited transcript of the show:

• Swapnil Bhartiya: Hi, this is your host Swapnil Bhartiya and welcome TFiR newsroom. And today we have with us, once again, Michelle McLean, VP of marketing at Salt Security. Michelle, it’s great to have you on the show.

Michelle McLean: Always fun to talk with you, Swapnil, thank you so much for having me.

• Swapnil Bhartiya: We are going to talk about this report, but before we talk about the report, I also want to discuss quickly because a lot of things are changing in our world that whole geo particles situation we live in, very, very uncertain times. What does it mean for security, though we are going to talk specifically about API security, but I want to hear your insights in general. What are the concern, where they should be?

Michelle McLean: You raise a great point, Swapnil. It is a really unstable time and there’s no doubt that cyber is an active tool that people are using. I mean, obviously both defensively, but also offensively. So we should absolutely expect that cyber will be one of the mechanisms of attack. And this has been playing out for years at the global level. But I think that we could see civilian unrest take shape this way. People participating actively in ways where they might not have picked up a weapon, but they will sit at their keyboard and take some action. I think we could see stuff along the API front, we could see stuff along the cloud front. We could see stuff along the supply chain front, as people look to make their point of view heard in that kind of format.

• Swapnil Bhartiya: What were some of the key findings of the latest State of API Security Report?

Michelle McLean: We run this report every six months. This is our third edition of it. So we’ve been doing it about 13 months now, and we’re able to draw on two sources of data. So one is survey data where we’re seeing people’s take on things, their experience of things, what they’ve gone through and their sentiment about certain things. And the second source is actually empirical data from the Salt SaaS cloud. All of our customers, API metadata ends up in our big data pool with our AI and ML running against it. And so we’re able to discern a lot of data from that as well. And a few things really stand out, no surprise enormous growth in the use of APIs and in API call volume traffic. So we saw an overall increase in the last 12 months of 321% in terms of overall API call volume.

But unfortunately in the same 12 months, we saw a 681% increase in malicious traffic. So while as a fraction of traffic’s fairly small, it has stepped up and it is outpacing overall growth of API traffic. And I think there’s a few things contributing to this. APIs are a really attractive target. People realize that the whole reason you create APIs is to share valuable data and services and so bad actors understand it’s pretty lucrative to go try to attack APIs. They also, for the most part, understand that current defenses aren’t very good. So it’s a good target that’s not particularly hard to crack. I think the second element that’s at play is what I would call the copycat effect. 2021 saw an enormous number of headlines around API security incidents. And I’m sorry, but these criminal activities kind of go in waves. People definitely do copycat stuff.

So we saw Peloton, Experian, LinkedIn, major headlines, just this last year. And even a couple of weeks ago, we saw a pretty significant vulnerability that Coinbase disclosed that a bug bounty had… Bug bounty white hat hacker had found that would’ve bankrupted the platform. So people see that it’s working and it becomes a really effective place to spend their time. And our survey data shows 95% of respondents, unfortunately had an API security incident in the last 12 months. And the challenges that what hasn’t really moved very far forward, what hasn’t really progressed is our level of preparedness. We’re seeing that only 11% of respondents had any kind of dedicated API testing and run time protection. And on the other hand, we had 34% of respondents having no API security strategy in place, despite the fact that they’re running production APIs. So we have some work to do to catch up to get ahead of this threat.

• Swapnil Bhartiya: How would you define malicious traffic?

Michelle McLean: So malicious traffic, what our system does is it understands differences from normal. Our system looks across millions of users and API calls and builds a baseline of what’s normal for any given environment. What’s the sequence in which they’re called? What’s the normal amount of data that comes back? Where they… Where is traffic coming from? And we do this across hundreds and hundreds of attributes. So the first thing you’re doing is just discerning different, what is different, but you can’t decide that’s malicious right away. If there’s one thing that’s off, we don’t flag that, we don’t see that. Somebody probably just made an error. This API call always gets an email. This was not an email. Okay, but that was just somebody filling out a form incorrectly. And they’ll fill out an email, then next go around and the form will get accepted. What you want and what you’re looking for is a pattern of malicious activity.

So you’re looking for constantly going in a different order, or I’m going to invoke that same API call and I’m going to change this attribute. So we’re tracking hundreds of attributes over time to distill what’s normal and what’s not. And it isn’t just the occasionally different activity. It’s the pattern of activity over time. So this person repeated the same API call, but they’re manipulating that API call in a different way each time. That’s the kind of thing that adds up to this looks like an attack. And what we do typically with our customers is that they want the assurance that our algorithms are right. That’s valid. So what they tend to do is they want to validate that and they want to look at what’s happening and the fingerprint that we’re developing for every attacker.

So they indeed will look at the, what our ML algorithms have uncovered. And they’ll say, “Yes, this is an attack. And here’s the control mechanism to put in place.” Over time, and not very much time, they will come to trust that we are recognizing this kind of attack accurately. And then they’ll set to just be automatic so that they don’t have to pay any attention to it. So what constitutes malicious begins with what is different. And then looking at the aspect of this should not have a thousand records returned. It’s always just returning one record, but somebody manipulated the API call to pull the back a thousand records instead of one. So that’s the kind of thing that we’re tracking and our system automatically buckets the malicious from the overall traffic. And that’s where we’re getting that statistic.

Swapnil Bhartiya: You also mentioned that there is increase in, of course, legit API traffic and also malicious traffic. What kind of concerns this increase in API traffic mean for security?

Michelle McLean: So APIs are driving innovation and developers are really focused on building fast and getting stuff out the door as they always have been. And as they really should be, and they are building for, yes, they are building to enable some process in the system. But again, since APIs are created entirely to share valuable data and services, they become a magnet for looking for problems. At the end of the day, an API sequence is a mapping of application, or sorry, rather business logic down to application logic. This is the business function we’re trying to get done. We’re going to instantiate that in a series of API calls and that’s the application logic. And what’s happening is developers are thinking about what the business process is, what they want to enable the business to do, but they’re not necessarily thinking about the variety of ways that attackers could manipulate that.

If you think about the Experian situation, the hacker discovered that if he enters all zeros for birth date, he can get back the credit score for any American. What programmer would’ve thought of that, right? The programmers like, “I’m building this API to use the date format. I know what a date format’s going to look like. Why would they think of all zeros as a birth date?” So it’s not any different from previous waves in this regard, it’s not any different from previous waves of application innovation. You just necessarily in these new constructs, tend to give rise to new avenues for attack. And there’s a lot of education needed. I think we’re going to talk a bit, or I think it’s worth talking a little bit about what do companies do in the face of this. But just for now, it’s important to understand attractive target, developers are thinking about yes, and companies need new kinds of protections to detect the malicious behavior of these attackers.

• Swapnil Bhartiya: API, they kind of pose a kind of different or unique challenge when it’s come to security as compared to, so we look at traditional security and then we look at cloud native security, and then we look at API security. So talk about what makes it a bit different and why you cannot just take some [inaudible 00:09:37] off the shelf, traditional tools for API protection.

Michelle McLean: Such a great question. And it is something that is not always obvious that it would be this way. So Swapnil, you and I first got to know each other when I was with a Container and Kubernetes security company. And what was interesting was that the way that we were developing applications had changed, but at the end of the day, attackers didn’t attack containerized apps any differently than any other app, because they didn’t know that it was containerized or running in Kube. And the attack mechanisms really didn’t change. What changed was you had to think about how you configured your containers in a protected way and things like that, but you didn’t change how you attacked apps. That’s not the case with APIs. And I think that’s a profound realization when people are looking to attack applications this way, they are very consciously thinking about how APIs work and specific mechanisms to manipulate API calls to breakthrough to this, get to new sources of data or do account takeover, within that, then launch a credential stuffing attack, that kind of thing.

So because you attack differently, it shouldn’t be a surprise that a lot of the existing tech can’t see it. And it’s important to just take a couple of seconds and think about what an attack looks like. Most of the time that we propagated application attacks, we followed a known pattern. I’m going to try SQL injection and see if it works. I’m going to try Cross-site scripting and see if it works. But it’s very one and done. I’m just going to do this transaction. And if I’m lucky, I’ll find a point in your code where this known attack will work. You can build technology to look for those known attacks relatively easily. It’s isolated to a single transaction and it’s following a known pattern, definitely not the case with APIs. First off, if there is no way for it to follow a known pattern per se, because your APIs are different to my APIs. And so the way somebody would attack your APIs is necessarily different.

So first off, you’ve got to learn the API to learn how to attack it and you’re going to attack it differently. The second thing is it takes a while to figure this out. It takes a while to build that picture of how these APIs work and therefore how I’m going to attack them. And that means your defense mechanisms have to be different. Your defense mechanisms can no longer look at one transaction at a time and have an accurate view of what’s going on because that API attack is stitched together over time. It’s a lot of different steps over time. The guy who put all zeros for Experian for birthdate, it wasn’t the thing he did, which is probably the 39th thing he did. So what you need is context over time to be good at API security.

And when in turn, what that means is that you need a lot of data. You need to be looking at a lot of data over time to see an attack that could take weeks to propagate. So that also means you’re not shoving this in a little VM, sticking in on-prem and you’re all good. It’s not going to happen that way. You can’t hold enough capacity in a single device like that sitting in your prem to be really good at API security. So know that the attacks are different, know that you’re tooling. You didn’t make a mistake. You didn’t buy the wrong tooling. It’s good for other attacks. It’s just not good for API attacks. And then understand the role of big data, AI and ML in stitching together activity over time to understand an API attack to detect and understand and block an API attack.

• Swapnil Bhartiya: An attacker has to be right only once. And you have to be right all the time if you’re protecting. So that’s a big difference. As you said, they will be trying 100 things. They have to be just right only once. But you have, if you’re protecting, you have to be right all the times. Now, you also talked about…

Michelle McLean: I’ll tell you this though, that thing about being right only once, it’s not the first thing. So that sounds scary, but you actually have time in an API world. You have time to watch this person over time because it’s not an instant result. An instant yes. “Oh, I reached my objective.” No, it’s so much trial and error that you have time to see that pattern evolve and identify and fingerprint that attacker and take action against that attacker. So that’s kind of the upside, right? The downside is every attack’s unique. The upside is you got time to respond.

• Swapnil Bhartiya: We also talked about the technological solutions, but I also want to talk a bit about cultural aspect of security because the whole with the Agile, DevOps, while we thought that we will break down old silos, but we have kind of created what I call soft silos. There are different teams who are responsible for different things. There is still DevOps, there’s still DevSecOps and there are SREs and the rules are evolving. Can you also talk about, that how is API changing the culture within company, once again, from security perspective?

Michelle McLean: It’s actually one of the areas where we take a lot of heart in terms of the survey response or have a lot of hope. So what we’ve seen is that the vast majority of organizations are seeing a change between how security and Dev teams work together because of API security. So first off, that is fantastic. We’re still seeing challenges around people trying to push this all onto developers and say, “It’s a Dev problem to solve, developers write APIs. Therefore, they should secure APIs.” It’s not that simple. A lot of the shift-left tooling is limited in what it can do, right. Code scanning is only going to get you so far. We talked about the fact that what’s really going on is this mapping of business logic to application logic and an API vulnerability at the end of the day is not a CVE. It’s a gap in business logic. It’s a problem in business logic flow. And you’re not going to see that in code scanning.

So you always need to apply some balance of, how much can developers do with the fact that we need to get protected in run time. That’s super important because the shift-left initiatives super valuable have two overall problems. The first is the time to value. We just came through another wave of application innovation with containers and Kubernetes where security was very dependent on developers. Security teams couldn’t roll out container and Kube security independently. They needed people who had access to the Kube clusters to deploy that tooling. That’s hard. With API security, you have the ability to do both. You have the ability for security teams to take control over their own destiny, roll out the platforms they need. Get protected now, get safe now in run time and be that good corporate citizen and feed insights into the development team to get better over time. But waiting for developers to deal with that whole backlog of API vulnerabilities that you’ve discovered, you don’t want to have to wait for them to work through all those code changes for you to get safe.

So if you try to do just shift-left, just proactive stuff, you’re going to be waiting a long time. So you’re going to have a longer time to value. And you’re going to have lower overall value because, again, the amount that you can cover in like scanning and testing is only going to go so far. You need to see the APIs exercised to see everything that you need to do to protect it and run time. And you always want to be running run time protection because nobody codes perfectly. Nobody avoids all mistakes. And so get safe now and then add in the shift-left over time. But the good news is they are working together more. We’re seeing more security people embedded in DevOps teams. We’re seeing more collaboration. We’re seeing more sign off between security teams and API design teams. All of this is really goodness for the industry.

• Swapnil Bhartiya: Another thing that you were showed was preparedness of the companies. We have been talking about security for so long. You and I been like sitting on this almost one or two years, whatever it is. So it’s kind of surprising and worrisome that is still we feel the companies are not prepared. So what is the reason because we do hear about security a lot, but is it because of the lack of awareness or the fact is that everybody wants security, but the things are so complicated already in the cloud network that it becomes overwhelming. And then you also rightly said, software security bugs, misconfiguration is going to be part of the writing the software, deploying it. We cannot eliminate those. So talk about what can be done so that companies are more prepared because things are going to get even tougher for everybody.

Michelle McLean: Yeah, fully agree, Swapnil. And a couple of parameters, one thing is the education phase itself, right? So there is a need for the people on the Dev side to understand what API attacks look like. It’s really hard for them to imagine the variety of ways that somebody could try to manipulate the call, if they’re not manipulate their API calls, if they’re not really familiar with the form of API tax. We have seen a good increase in the number of organizations using the OWASP API Top 10 as at least a starting point. For framing, what do attacks look like? So I think first off, there’s a developer education phase. The inverse is also true. Security teams need to understand more about API incidents. We’ll have teams, maybe they’ve been a customer for a few months and they’ll be this sheepish embarrassed call where they’re like, “Our SecOps teams don’t really understand what they’re looking at when they’re seeing an API incident. Can you teach our team how to get good at this?” No fault of anybody, right. Who grew up knowing what API calls would look like?

So that reverse education needs to happen as well, where SecOps teams need to become proficient in and at least the basics of how APIs are written, what call response pairs look like, what normal looks like and what an attack looks like. So there’s definitely that education phase. The second thing that’s needed is, again, we shouldn’t be surprised when the application landscape evolves, the security tooling has to evolve. Nothing wrong with the existing tech. They do what they were designed to do, but they weren’t designed for this. And so complimenting the education with the tooling that’s ML and AI based, you’re never going to have humans that can totally keep up. And the cloud scale big data, so that you have a big picture that you need to really understand what’s happening on the attack run.

• Swapnil Bhartiya: Michelle, thank you so much for taking time out today and of course, not only talk about this reports, the finding, but also share your insights on how companies can improve their API security posture. So thanks for those insights. And I would love to have you back on the show, but we should not keep this much gap between our discussions. We should do it more frequently. So I look forward to our next call. Thank you.

Michelle McLean: Excellent. Thank you, Swapnil. A pleasure to be with you again.