Hello everyone, and welcome to today's SANS webcast, 2023 SANS Survey on API Security, sponsored by Akamai. My name is Marilyn Galler of SANS. Today's featured speakers are John Pescatore, Director of Emerging Security Trends at SANS, and Malcolm Malik, VP of Application and API Security Products at Akamai Technologies. If during the webcast you have any questions for our presenters, please enter them into the Q&A window at any time. Please note that this webcast is being recorded, and a copy of the slides and recording of this webcast will be available for viewing later today and can be found on the SANS registration page. With that, I'd like to hand the webcast over to our presenters.
Okay, thanks Marilyn. Welcome everyone. I'm John Pescatore. Welcome to another SANS webinar. This should be a good one on a very detailed and sort of experienced level of respondent survey we just did. Before I get to that, I hope everybody's making it through the heat waves and the forest fires. I know this time slot we often get a lot of European people participating in our webinars, and there's been fires in Greece and Canary Islands. Same here. I'm on the East Coast of the US where the smoke from the Canadian forest fires has come down to the Washington, DC area. Hopefully we're all making our way through that, and we'll start turning the corner here soon. Another thing I like to do is always, before we get going, look at any interesting things happening on this date related to technology and cybersecurity.
Lo and behold, 55 years ago today, the company Intel was formed around memory chips and ultimately microprocessor chips. That occurred just about 40 years after the first IBM mainframe computer ship. You can see some of the trends we're going to talk about here as we went from mainframe computing to today's modern distributed computing. I've been many decades in the making. Another interesting thing is right about now in 2000, and actually in 2000, I think is right about when the REST API came out as the subject of a grad student PhD thesis in UC Group and UC Irvine. I remember the end of that year working with Salesforce.com when they first came out and this mysterious way of doing computing in the cloud and APIs being heavily involved was just first starting to poke its head out from the soil.
Then in 2001, the Code Red worm hit the world and sort of brought cybersecurity to the front of global news stations and everything with sort of old-fashioned attacks against missing patches in Microsoft's operating system. The funny thing I found is the first time I can remember sort of consumer use of APIs was when Apple came out with the iCalendar API, and that was around now in 2002. If you ever noticed, Apple still uses July 17th as the emoji calendar day, as the emoji for that. That's because it came out in July 17th of 2002, over 20 years ago. With that little bit of history setting the way for where we're going to jump into modern times, let me give you an idea of what we're going to do.
What's going to happen is I'll go through some high-level introductory stuff and then sort of go through the results of the survey Barb Filkins and I did and the report we wrote at SANS that was sponsored by Akamai. Then Alka from Akamai, I'm going to toss her a few questions as we go through that. She'll be able to do some drill down. As we're going through this, I'll be trying to watch the Q&A window. If you have a question, we welcome all questions. I judge the quality of our presentation by the number of questions we get. As I'm going along, if you have a question for me or for Alka, dump them in there. I'll try to get to them as we go. If not, we'll leave time at the end and get to any and all questions then.
If you are watching a recorded version of this webinar, at the end, I'll give you an email address and send your questions to them. We'll get the right person to give you the right answer. With that, let's get started. Just about everything I do at SANS, I like to start off with a look at any sort of current attack and threat statistics. One thing I've used for a number of years, I've been at SANS 10 years, I was using ITRC data back at Gartner where I worked before I joined SANS. Here's some recent data. This is actually from their year-end 2022 data. In 2022, as far as publicly acknowledged compromises, there were about 1,800, which is a drop a little bit from 2021's levels. You see all the other statistics there.
The only things I'll point out to is supply chain attacks on the rise. If you look down towards the middle bottom, something like 60% of the attacks that succeeded were classified as supply chain, where supply chain partner was the initial entry point. Remember years ago when Target got broken into an HVAC contractor? That was sort of the start of this. Now it's been more and more common for it to be a software supply chain partner and more and more common for it to be an API-related vulnerability that's exploited at the supply chain partner, which then impacts many, many other people using that supply chain partner and may be impacting you. Now, since I did this slide, ITRC has come out with their first half of 2023 data.
The first quarter was sort of continuing a sort of reduced rate, but then all of a sudden breaches sort of exploded in the second quarter of 2023. It is now running at a quarterly rate that could show a 50% increase by the end of 2023 on the breaches happening. There has been a lot of smaller breaches, so the quantity has gone up. The number of victims has sort of gone down. Again, a lot of those smaller companies have been suppliers and supply chain people. They focused on financial services. I think for a couple of reasons, obviously that is often a lucrative area to go after. A lot of the chaos that was going on in crypto coins, you will see, has attracted a lot of attacks going against anybody doing anything related to virtual currencies.
I hate the term cryptocurrency because it really misstates what's going on there, but these virtual payment and virtual currency systems are really under attack. The key thing to take away here is this issue of supply chain attacks. While it's important to know the software you're using and the APIs you're using, as we'll get into, it's often critical to know which of your suppliers is also using those same things and are they vulnerable. I'm not going to spend a lot of time. We go through some of it in the report and give a lot of pointers, sort of the history of what APIs, but the graphic in the middle shows you really what's happened.
We've gone from sort of monolithic applications with one input and one output to these much more complicated architectures with a lot of APIs, a lot of open APIs, mobile apps and web apps, and backend systems communicating with third-party developers and all kinds of interfaces. Because this approach of using APIs and using DevOps methodologies and software application pipelines and the like has a lot of benefits to the business. Certainly faster turnarounds, more innovative approaches, newer applications, hopefully extending customer reach and resulting in higher revenue and/or higher profits, which usually come next. This migration, this moving to this has been going on for many years from the old mainframe days to client server, to departmental computing, to PC-based computing, to where we are today.
Obviously the attackers say, "Oh, if that's what you're going to do, we're going to attack you there." Every new innovation comes along with vulnerabilities. I'd like to think that at some point in the future, we're going to sort of every new innovation will be focused around secure ways of doing things. I've worked in this cybersecurity world and the physical security world my entire career, and I don't think that's going to happen anytime soon, to be honest. The APIs that are in use have definitely become an attack point. There are various numbers ranging from the average organization finds every business function has at least 12 APIs in use to typical companies. If you look everywhere, including your Windows software and everything else used, you have over 15,000 APIs in use.
That says it's a ubiquitous target, and all too often it's a lucrative target. One of the sort of poster children for this is WordPress, which is often used by smaller companies and many of your business partners to put up simple websites or simple blogs or simple social media presence. There's been all kinds of vulnerabilities and everything to do with WordPress from the application level and certainly to the API level and certainly down to the REST API level. REST API is Representational State Transfer API, you might hear it called a RESTful API.
It has a lot of security capabilities built in, authentication techniques and ways to do things, but it also has a lot of very common vulnerabilities that you think by now we'd be done with, cross-site scripting or cross-site request forgery or simple injection type vulnerabilities like we've seen with SQL and standard applications. Those have very commonly been exploited in using WordPress as the poster child and in many other uses of RESTful APIs for these bad guys on the right and these vicious things to get in and wreak havoc. I'll just use one example. There are a lot of them out there. I think we cite several in the paper. This was a hack against the HubSpot Customer Relation Management marketing application that's used by lots of small companies. I think it has over 150,000 users or so.
All of a sudden, contacts from HubSpot's accounts started showing up as bogus in people's accounts and also getting irate emails from customers. "Why did you send me this?" Essentially there was a hack that led to data breaches to lots of things. The attack was originally aimed at breaking into some—there's a little attack last year—into some Bitcoin-related type companies, cyber currency type companies. This was an example of what I call a supply chain spillover attack, where they weren't going after you, but they're going after these companies that you see listed there like BlockFi and Swan Bitcoin. They found they were able to compromise a lot of suppliers to BlockFi, Swan Bitcoin, and other targets that you might have been using. Everybody using those.
It was kind of like the SolarWinds attack, where everybody using SolarWinds was then vulnerable, even though you were not the original target of what the bad guys went after. Again, back to there's real-world attacks happening continually. APIs are everywhere. Unfortunately, they're not as strong as they should be. It's a critical area of security. I've worked in security a long time. There's a lot of constants in security. On the right, you see the Essential Eight. This was put out many years ago as sort of a spinoff of the 20 critical security controls that SANS shepherded for many years and has now been taken over by the Center for Internet Security.
The Australian government did a look and said, "If we did these eight things that you see on the right-hand side of your screen, we could eliminate 90% of even the targeted attacks, not just the simple sort of spray-out worm type attacks, but the targeted attacks." However, doing those things is not as easy as it seems. You see listed on the left-hand side sort of applying that to thinking about APIs. Certainly first, the inventory of APIs. What are we using? Which business processes use which APIs? And what are our critical business processes that we need to make sure do not get damaged and are not vulnerable? Then a threat assessment, where there are active attacks out there exploiting those vulnerabilities, which is getting to be pretty widespread information flying from lots of places.
The last place you want to learn about an active attack is like what happened in that HubSpot one is hearing from your customers or hearing from law enforcement. You want to know about the risk first. Then you want to be able to do something about it, mitigate your exposures of your critical APIs or get them fixed or get them patched or get them discontinued if they're obsolete, dangerous ones.
In the terminology, the ideal thing we want to do is shift left to get all the way back to the development cycle and turn DevOps into SecDevOps, that security is getting baked in, that as we move to these more modern methodologies and containers and pipelines and heavy use of APIs that we're thinking security through in the first place, that we're building the security functions in right, the authentication capabilities and all the other things to prevent attacks, and that they're being turned on by default. These are all parts of shift left. Realistically, we've seen very uneven progress towards that. Pace of change is so rapid that demand is often they'll get the product to ship out first, and then we'll worry about security. What I want to do here is toss it to Alka and say, "Alka, you've worked in this area.
What have you seen some of the obstacles and some of the ways of overcoming those obstacles towards realistically achieving this idea of shifting left up into the DevOps cycle?
Sure. Thank you, John. I completely agree with the bullets that you have on this slide. Many of our application customers are looking to drive efficiency, right, and improving their security posture, catching and fixing vulnerabilities in the development cycle instead of production. We all know it's not new to anyone. It's always better to fix bugs earlier in the software development lifecycle, and it's also cheaper. It's not always about money, but also the company's brand and reputation that can be put at stake if you're not diligent and vigilant about security. As we know, many organizations are currently releasing new builds daily. Developers are expected to increase the frequency of releases going out. That increases the challenges, right, around security to keep up with the rapid pace.
The real challenge I see is in how you're coordinating in real time and what's the timeline between development and your security organizations and developing some key skills, right, around secure coding and things like that. We need to incorporate security into the development side processes without slowing down our operations, right? That is really important that we don't do that. Both the teams need to be engaged from an early, right from the get-go, from early stages to establish security requirements as part of your acceptance criteria so that it's baked in and built in the product versus right from the beginning versus stitching it in later because it never is the same if you are building it right from the start. I like to keep things simple.
You have to sew a shirt, and if you had to rethink through that idea later of how you want the colors to look, it's not going to be the same if you were going to stitch it the right way to start with. Both teams need to agree on common goals and outcomes for any development project, right? Security teams need to understand the software supply chain, right, the components and the corresponding vulnerabilities to determine the risk profile. This risk profile or the risk assessment determines if a package should go into production or should it go back to the development team to address and fix issues, right? Also, the security team should review and audit the release engineering processes around securing and maintaining your build environments and your security posture around that.
You have to have continuous scanning and artifact analysis going on. It's not a one-time thing. Development teams need to understand the parameters and how they map to the corresponding authentication policies for the data that's being accessed and how attackers are using APIs to inject attacks. Developers really need to have that understanding. They cannot be separate and working in their own space. Lastly, as I just mentioned, training around secure coding is not a one-time thing. A lot of times people think, "Oh, I've done it once. Why do I have to repeat it?" It should be an annual refresher. That's what I believe in. It should be mandatory for any software security development team that is serious about security.
Okay. Good stuff. Thanks, Alka. Another thing I do for SANS, we have a program called What Works, where vendors will give me a user of their product. I'll interview them to find out how they managed to get this new capability going or how they convinced management, how they overcome obstacles. In this area, usually the biggest obstacle is, Alka said all the things, the good stuff that needs to be done, and you're saying, "Yeah, those app people never listen to us. We can never get them to do any of that stuff." The kind of success path I've seen is sort of a two-pronged one. One is increasingly the software architects are having privacy be one of their business requirements. They're trying to sell internationally or trying to meet new regulations, or somebody said, "Yeah, we really screwed up the last time.
We lost sales because of that incident we had." Privacy is often the path in. We're often finding software architects contacting the security team, "Hey, can you help us out in this area with this new app we're trying to architect right now?" The other is being proactive and convincing the software side or the app dev side or the CIO that privacy is key to actually selling product. If you just noticed the TV commercials or nobody watches TV anymore, we're still on the security content slide. They are progressing. You see companies like Apple and Microsoft and Google and Twitter, everybody starting to compete on security. It is a competitive thing, and often consumer privacy is the hook there. Now we're going to get into the details of the survey.
Let me start with one of the first questions we asked were, "What areas of risk do you think are important to the respondents?" Several hundred respondents to this. I have to say, you'll see some data coming on. This survey was a really good one in that most of the respondents are very experienced in this area. We do a lot of surveys where we get to say only 20% of people even are thinking about this. In this case, this crowd was more 80% familiar with things, which is always good to hear. Here you see the top answers in the questions we asked. You see, rightfully so, phishing and attackers exploiting missing patches were ranked as the top two highest. What you see in blue, red, green is first, second, third choices.
Phishing attacks exploiting reusable passwords is still number one across the board for any type of vulnerability. When you start getting to applications and APIs using unpatched or unupdated APIs that had known vulnerabilities, applications that have known vulnerable APIs in use, really is once they get in the first way, how they then spread and how they started getting their payloads to work and where they want to download their payloads. You see attackers exploiting vulnerabilities. The only one I quibble here with, visually, it looks like misconfigurations of services should be the fourth-rated one. The math made it turn out that denial of service attacks actually were rated a bit higher. I think probably misconfiguration of cloud-based services and the API options and things there probably is at least the fourth one. You see accidental disclosure is ranked pretty high.
I would lump that in with the misconfiguration of cloud-based services along with these two. I think you'd see it be right up there with number three. This is a pretty realistic look. Again, if you're not already working in security to get rid of reusable passwords, it's well past time to start. I do board of directors briefings, and the board is starting to say, "Well, I use it all the time for my accounts. You mean they're not using it?" That's one to try to touch base on. We ask, "How do you define risk? Do you use any common frameworks? What apply?" You see very strong usage here. Over half are using either OWASP AppSec Top 10 or the MITRE ATT&CK Framework. These are two, and the slightly lower number using the more the newer OWASP API Security Top 10.
Those are two very powerful ways. OWASP and MITRE, and often combining the two can do some very cool stuff. For example, we're seeing MITRE ATT&CK Framework used to look not just at the attacks that might be hitting you and prioritize those, but look at your defense capabilities, even your team training to see where you have holes and matching up. The framework being used as a way to evaluate readiness is pretty key. Because again, going back to that constant slide, one constant is we always do need to have mitigations in place no matter how good we get at security. There's still going to be mistakes made. You see lower down Cloud Security Alliance and the critical security controls sort of came in. Let's see.
There's a question that came in, "Can I elaborate on privacy as a competitive advantage?" The quick answer is, if you notice, there's vendors like Google and many others, Twitter, people who don't charge for their products, essentially, tend to make money by selling advertising. That tends to mean they have to do a lot of collection of data, and they have to prove they're going to handle that data safely in order for that model to work. You saw what happened to Twitter as they began to move. Are they really safe? Conversely, the Microsofts, the Apples, and a few others that charge for their products or sell hardware as part of the platform, they've been able to claim, "We don't go after your data. We don't do those things.
We don't make money off of advertising." You notice Apple's able to charge a premium and become one of the largest publicly traded companies in history by doing that. Starting to see that be sort of a selling point on the advertising they use. You can also just start to see it as cloud-type services start to compete. Everybody can deliver the same infrastructure as a service offering of a CRM package. They don't want to compete on the lowest price, so they have to compete on value when they have all the same features, privacy's often that value. That's a quick drill down into that. Whoops, let me get back to my moving things forward here. This is an excerpt from what was one of the most recent versions of the OWASP API Security Top 20.
Alka, you were involved, I think, or knowledgeable of the update that they did in the most recent version. Can you tell us what's new and throw a little color into this?
Sure. Absolutely. Yeah, this is a very interesting question. OWASP API Top 10, the cloud source, all trends and attacks and vulnerabilities, right? You're constantly looking as to what's happening in the world. API attacks are evolving, as we know. Bad actors are evolving. API attacks are becoming the most frequent attack vector, causing data breaches for enterprise web applications. APIs, as we know, directly expose functional logic and data, making them prime targets for bad actors that are targeting vulnerabilities. What we see in the 2023 updates in comparison to 2019, there were four that I can point out. One in the Broken Object Property Level Authorization. It combines actually two other ones, which are excessive data exposure and mass assignment.
They both were listed separately in 2019, but they both focus on attacks that happen by gaining unauthorized access to sensitive information. Both these techniques are based on API endpoint manipulation. That one was updated and tightened up. There were three that were added. Server-Side Request Forgery. Without this, attackers can gain access to internal network resources within a web-based environment, compromising security mechanisms within the web service. The next one is the Unrestricted Access to Sensitive Business Flows. This addresses new threats. Most of these can be mitigated by using rate limiting. This issue usually stems from a lack of having a holistic view of the API. Once you understand which business flow an API endpoint exposes and how sensitive that business flow is, that is essential in preventing the vulnerability. Last is the Unsafe Consumption of APIs.
This was added to address the emergence of attackers looking for targets' integrated services to compromise those instead of hitting the APIs of their targets directly. In a nutshell, OWASP is continuously making a continuous effort to help redirect attention to where the emerging threats are and help organizations better protect themselves from API attack vectors. It is great that OWASP is doing all the things to keep us up to date with the changes that are happening and the attacks that are happening and how we should be mitigating them. That is my answer to the question.
Okay. Great. I skewed old at the beginning by referring back to 1968 and 2000, but I remember right after Salesforce started up and started actually succeeding in the market, and then infrastructure as a service offering started to come out sort of before Amazon. If you see this one, unrestricted resource consumption at the third level and then at the bottom, unsafe consumption of APIs. The infrastructure as a service vendors in the early days quickly found out they needed to put in rate limiting, not because bad guys were attacking those APIs, but because sysadmins were saying, "Oh, cool. Look, I can spin up this. I can spin up that. Look how quick I can." They were causing essentially denial of service and resource consumption attacks against the infrastructure as a service providers.
It wasn't until after those accidental attacks that the bad guys started saying, "Oh, we don't have to do just brute force attacks. We can do these resource consumption type attacks that are harder to detect and in many cases harder to stop." Okay. Let's keep going through our results here. We asked what tools are currently in use. This is where you see we have kind of an experienced group of respondents. I'll sort of lump the levels into two levels. About more than half said, "We're already using a web application firewall that's in there somewhere. We're also doing application testing, both dynamic and/or static." Many were using both. Some were using one or the other. That overall application security testing in general. Those are higher levels than I think you'll see in reality across the market.
These survey respondents were already saying, "We're doing some things to try to attack or try to mitigate attacks against our web-based applications in use, like web app firewall. And we're trying to do some proactive stuff in testing things before we do go production to reduce the number of vulnerabilities that get out." That's sort of one level of things in use. You see at about the 30% level somewhere in there, you see application-level firewall. You see, "We're using a next-generation firewall that has application-level type capabilities." Those provide some, but not very deep protection against very specific API-type attacks. Similarly, web security gateways have lots of protection for your users and their browsers that might be some dedicated attacks, but they're not often present in application, not always present in application-application communications.
You see about 33% of you are already using application inventory discovery. The interesting question, and we'll get to some data there, is how accurate do you feel you are? If you run your application discovery tool, how does that compare with real-life applications in use? We'll get to some feelings there. You see not very much use of the DDoS appliances on-premise, but almost a third, 27%, using DDoS services that are cloud-based. Often those cloud-based DDoS services will have some, or your content delivery network will have many features that can be used to mitigate attacks. It is kind of key to think through this that there's API attacks that may be going against your cloud-based and/or internet-exposed services, others that may be going after your desktops that are accessing the web. How do you have coverage across both of those areas?
I keep clicking and it moves. There we go. Here is an interesting one. How long have you been using these tools? See that 3-10 year in red? This is probably one of the few, other than some SOCs focused surveys we've done, where I've seen some mature use of so many different types of tools. Again, if you look at the 3-10 year, the big red ones, you see WAFs, web app firewalls, and application vulnerability testings, especially the static type where you're running it on looking at just the code itself versus running applications. Pretty mature use. When you look at the one year or less, that's when you start to see the discovery tools are not quite as mature. API discovery and anything API-specific are sort of much less mature use.
This is a pretty good set of respondents that they've been using these tools already. This is something I would say you could take a lesson from to say, "This is what other people are already doing. Where do I fit in this?" Now, I had a question. Which tools or methods would you use to build an application inventory? I'm going to go to the next slide because that was another point here. I'll ask Alka to also weigh in on that question on the next slide. We did ask, "What tools are you using?" You see lots and lots of tools in use in the discovery inventory side of things, probably the shortest. You do see familiar tools like Tenable and others that are used just to find everything and a bunch of new ones.
You see scattered across here, Akamai having capabilities in many of these areas we're talking about. It's a pretty long use. I would say just since I worked at Gartner, where it says Gartner and security testing, I had no idea what they were talking about on that. Alka, can you weigh in? What sort of tools or methods do you think are critical to be building an accurate and timely application inventory?
Yeah. I'm glad to see Akamai up here. That's who. Grace. Nice job. We are using a number of tools. A lot of them are internal. There's a lot that comes to the CDN from the other side of the other organization. We do use Postman. We're using, when it comes to, we have DAST. Of course, Qualys is another one, right? We're using Snyk, which is one that we are just evaluating and bringing on board. We are also going through FedRAMP certification right now on the FedRAMP High certification. We're evaluating tools for that as well at the moment. When it comes to firewall gateways, we have Microsoft Azure. We're also using AWS. Of course, Akamai has invested and purchased a company called Linode last year.
We're doing a lot, moving a lot of our workloads to Linode as well. There's a lot of that happening. Of course, as I'm just looking through the list, we use Splunk for a number of things around monitoring. There's a variety, a plethora of tools that we use, but a lot of them are homegrown as well that we feel are valuable to our organization.
Okay. A couple of points I'll make here. Anytime you see this many tools in use, you know there's a kind of immature state of the market out there, right? It hasn't settled down to just three things in each category. In the reality for all security teams, you're not going to just use one vendor for all your tools, but you're probably not going to be able to use 30 different vendors or 15 or even 10, right? There's going to be a handful of ones. What you want to do is look for things that you can use one tool across multiple areas, or ideally, again, thinking back to the shift-left idea, that you can use tools that also the app dev side wants to use. In discovery inventory, and even in the testing tools, they often want to use these now in their DevOps methodologies.
Or the network side of things wants to analyze network traffic and has to know what's out there and know how to do load balancing and network shifting of resources and so on. You can use something in common with the NetOps side of things as well.
John, I'd like to add a bit more. We have our own web application firewall, right? Akamai has that. Also, we recently did an acquisition of a company called Neosec based more on the behavior-based API discovery visibility detection, right? Those are also as we look at our portfolio, we look at how do we strengthen the customer base, right, in terms of protections. I wanted to just add a little bit more color over there.
Okay. I had a question come in. Application vulnerability tests, is this the same as SAST or static application security testing? In the survey, so there's static, which is essentially analyzing the code. There's dynamic, which is looking at running applications. Then there's sort of the pen testing side of things. That's what we call application vulnerability testing. It's more the active sort of pen testing looking at things. Okay. Let's keep going here. Here's that question about accuracy. This was, again, pretty realistic. If you look, about 4% said, "Yeah, we don't do anything yet." About 14% were really honest and said, "I don't know." Of the ones who had an idea and came up with a guess, you see the big bulk fell between 25%-75% accuracy.
Now, I've done this for many years on application running Nessus or other things to say of the IP addresses on your network, when you run a scan, what percentage you already know about? Above 80%, you're best of breed in the real world. Where you see 25-75%, that's pretty realistic. Going 75-90, those are the best of breed folks in that side of things. And 6% of people are either lying or their system is broken, and it's just telling them it's not noticing lots of things. There's nobody out there really achieving that in a consistent manner. Again, the issue here is because of the dynamic nature of everything, whether it's IP addresses, whether it's server or whether it's cloud workloads, whether it's APIs in use, it's very hard to even get up into that 75% range.
That's something to shoot for and to know where you fall on this because, again, undiscovered things are often found by attackers before you find them. Question I'll answer here. Will there be a table data shows the most used product out there? We did not include that. That was not part of the goal of this survey. You get too many questions in a survey, you tend to get less meaningful data across all. We did not go down into sort of the market share of those tools. The one thing I will say is in other stuff I've done for SANS, I found an interesting thing that the use of open-source tools in many of these areas often correlates with the lowest turnover in SOC personnel.
It's an interesting correlation that if you have people staring at Splunk screens or SIM screens all day long, to be able to allow them to play with some open-source tools, develop some of their own detections, do some creative stuff, often helps them say, "Oh, I'm not going to go jump across to that company across town for a couple thousand dollars more. I'm having too much fun here." That's not related to the topic of our webinar, but just something that's come up that I've always thought was meaningful. Okay. Just trying to stick on our timeline here. We said if you're not using them, for the things you're not using, what are top-of-your-mind plans ones to use? You see still for those not using web security gateways and application WAFs, those came out the top. The Denial of Service on-prem was really rated the lowest.
You see everything pretty much a mix in between. I would say the API discovery and inventory discovery numbers are pretty low. It's so key to really know what you're trying to protect before you can protect anything. I know it's one of these if I don't ask, I don't have to know this depressing number. That's not a that's kind of like putting black tape on the check engine light on your car. It may feel better for a short period of time, but you can have a really expensive repair ultimately whenever the real problems do come out. Let's keep going here. I think I had another one I wanted to ask.
Actually, the last one I wanted to ask you, let's use this one as an example, Malcolm, because I was going to ask you about where do you see the best ways of making improvements in that inventory-level accuracy?
Sure. Another great question, right? How do you know how can you protect all of your APIs if you don't know where they are in the first place, right? As you mentioned, and as it shows in the survey as well, right? Visibility, knowing the lay of the land is more important, is the first key thing before you do the detection, right? You first need to know. In order to do this, you first need to have a rich data set. Typically, that's housed in a data lake or somewhere, right? True behavioral analytics requires baselining, whether it's good or bad usage over time, and not just looking at single requests and responses or short sequences of objects, right, or requests coming through. If you have a rolling 30-day window of data, that should be rich enough to build a baseline.
Once you have this baseline and this platform, right, this enables the DevSecOps teams to investigate, hunt, respond to real threats, and uncover exactly what's happened. They can then build on the discovery of the API attacks. They can build on top of that, they can build the detections and response techniques to mitigate the threats, right? Visibility is absolutely key. As the survey says, there was a decent percentage where they did not even know where some of their APIs are. Not many knew all of their APIs.
Okay. I mean, there's various techniques and ways of detecting things on networks or on signature-based things, behavioral-based things. Sometimes there's a signature-based low false positive that missed lots of things. Behavioral-based, in the old days, was false positive prone. What are some advancements in that area?
I know we have a threat research team that is actively looking, that is constantly looking at the data that's coming through. Also, we are coming up with custom rules to help mitigate. We are always looking at false positives, looking at false negatives, looking at also we have, as I mentioned, we are looking at the behavioral detections as well as behavioral analytics with the Neosec acquisition. We are integrating that product in. We also, on the DevApp side, brought in API protection. Looking at PII data, looking at Social Security numbers, phone numbers, email addresses. We have been strengthening our base as well around the WAF protections, but now complementing that more so on the behavioral side, bringing in more machine learning into the mix. That's what we've been doing in the app and API protection space at Akamai.
Okay. Another interesting thing for our audience to think about, a lot of the tools you're going to use today, whether it's web security gateways, web app firewalls, application aware firewalls, almost everything's talking about using machine learning and AI-type models to do things. I do a series of presentations to boards of directors and company-wide type things to explain the risks of machine learning and AI. One thing is every one of these things really wants you to run it on your systems, on your networks, across your applications for a while so we can train. So we can get training data of sort of a known good configuration. If you don't have a good feeling for your inventory, how do you know you're in a known good configuration? You can be training the AI models of these products to ignore existing compromises you already have running.
Keep that in mind. Let's see. Another question came in. How useful is vendor-supplied SBOM or software bill of material data? That is an area that has gotten a lot of press. It showed up in the U.S., certainly, and President Biden's executive orders in the federal government. SBOM or software bill of materials is the idea that every application piece of software you would have in use would essentially have an ingredients tag on it that can be validated cryptographically or securely as far as when it was created, who it was created, what version it is, where it came from, what components you use, all kinds of good information. It is a pretty immature area. There is definitely SBOM-type data that is good to use, but whether it is complete and accurate is a whole different issue yet. It is still a pretty immature area. Okay. Let's keep going here.
Let's get to some of the recommendations and some things that we put in the report. Obviously, in security, what we're really trying to do is move from this top line where you see we didn't find out about the incident until we started to detect command and control communications flying out or coming back in, or one of our customers said, "What the heck?" or our ISP or the FBI said, "Why are you communicating with these known ransomware sites?" We're in the incident response mode. It's better to detect, do that quickly and well. Ideally, you're detecting it well before that. That's the bottom line, earlier action. We're trying to minimize damage.
If as a minimum, we can get to the point where we're detecting things upon delivery and we're mitigating them upon delivery and we're stopping anything from happening from that point, we still have an incident, but we've greatly limited the damage. That's what we're trying to in our recommendations try to want to point in ways we can shift left to get to pre-attack mitigation and get to really proactive damage avoidance, but also in security that we react more quickly in that delivery phase there at the very latest. Let's see. Let me see a couple of questions came in here. Malcolm, I'll ask if you want to weigh in on the first one. Any thoughts or experience to share on populating Cyclone DX-like APIs and exposed services and inventory?
I do not at the moment, but I will definitely think through it. I know you said that there was an email that you would send out. I do not have an answer to this yet.
No problem. We'll try to get you an answer to the question, the personal answer question, get you an answer later on. The final question that came through, web security gateway. Again, you often hear web security gateway and secure web gateway, the terms used interchangeably, but that's basically the same thing. Going for the takeaways, and then we'll leave some time for questions. If no more questions, we'll get you some resources. Again, discovery and vulnerability assessment is always the first step. We learned this. I've talked about, what did I say? In 2001 was when Code Red hit us. Just think how many people learned back then. We better know have we patched things and what is out there that's unpatched on our network. Same is true with APIs.
Not only is the number of APIs sort of crazy higher than the number of Windows apps you were running in the old days, but the complexity of the vulnerabilities and the ability to detect if one's vulnerable or is the latest update has gotten much more complex. You need to go move beyond sort of simple whitelist checking and other static approaches. We're all guaranteed job security in this field we're all in, I think, because mitigation is always going to be used. We're a hopeful species. Humankind is a hopeful species. And software development is still hoping that, well, if I do something quickly, we'll win market share and it'll be secure enough. Not always. In fact, very rarely, actually. We're still going to need to detect attacks in process.
We're still going to need to use squishy software that the business absolutely has to use and will use that we have to mitigate as much as possible the vulnerabilities in that software. Again, proof of inventory, we'll know better what's vulnerable, but we're always going to need segmentation, shielding, mitigation, rapid detection, and so on. To be really effective, it's not just app to app or server to server. It's also internet to your users. It's also internally, in your own applications internally. If something does get on the inside and is now pretending to be your Chief Financial Officer on her PC and starts using things internally, how vulnerable are your applications from that direction as well? Let's see. A couple more questions came through here. Let's see.
Regarding API security controls, what industry standards out there are strong to follow when it comes to compliance? We listed the frameworks upfront. Obviously, the MITRE framework is not something that's a list of things to do. The OWASP Top 20, if you can show that you've mitigated or dealt with or avoided the things on the OWASP Top 20, that's a common thing. The critical security controls I mentioned. Malcolm, are there any others you can think of that are industry standards or compliance-specific things around API security?
I think you've covered them. I mean, I know we focus on the OWASP, the Top 10, for sure. Of course, the API Top 10 as well, the combination. Each vendor has their own guidance as to what they provide. I think you've pretty much covered them. That's what we go after as well and making sure what our security team tells us as well in terms of what they're seeing. Our threat research team, as I said, we are constantly updating our rules and things as we see attacks getting evolved, right? As a standard, we look at the open frameworks and what's available out there.
Okay. Sure, if you're in retail, you'll see the retail security standards and the yearly things that have to be done there. Certainly focused on application security and later versions and API security as part of that. In a survey, we did list the number of people looking at the Cloud Security Alliance. David and Nate put out a lot of things. I would say the OWASP ones are typically what? If you can say, "We've addressed those or mitigated the ones we couldn't address," then you can justify being compliant to just about any regime that's out there. That will do one more call for questions. We're nearing the end of our time frame here. There's our standard asking for more questions. I'm not seeing any more coming in. Let me go to our resource slide. Here's where you get additional information.
SANS does have a number of courses related to this. SANS Security 522, you can get information on there. There is a link to the survey paper, and I think it also went out in the chat window here. You can get the latest data. I have to do a little bit of advertising for the Cyber Start America initiative SANS has started up here in the U.S. It is also got different things going in other countries. This is something to try to help get more people into the cybersecurity field. It is aimed at late high school, last year of high school, or sort of community college, first couple of years of college-age kids. SANS gives away online training. If you have got kids or you have nieces or nephews or you know people with kids of that age, then go online, play a game.
It's a game to catch some hackers. If they score well on that game, we know they can pass SANS 100-level security courses. We let them take them for free and then go to a local community college. I think it's up to something like 46 states in the U.S. and take all those boring social studies and language and all those other courses. Then get a two-year degree from the community college with a certificate in applied cybersecurity and pretty much go out and work as a junior analyst in most companies that are dying to get stock analysts started. Or they can win four-year scholarships to a bunch of colleges that are four-year colleges that also participate. It was a very cool thing. I think it might have just closed in the cohort for this year, but there'll be another one coming in the fall.
There's Akamai's URL. Get more information on their capabilities and information on their products. If you do have a quick, if you are watching a recorded version of this and you just came up with a question or I missed answering your question or you didn't like our answer, send it to q@sans.org and we'll get the right person to get you a good answer. If you've got ideas on future webinars SANS can do or ways SANS can do these better, there's my email address. With that, I'm going to turn things back to Marilyn Gayler for any final words.
Thank you so much, John and Alka, for your great presentation and test, which helps to bring this content to the SANS community. To our audience, we greatly appreciate you listening in. For a schedule of all upcoming and archived SANS webcasts, including this one, please visit sans.org/webcasts. Until next time, take care, and we hope to have you back again for the next SANS webcast.