Events Add an event Speakers Talks Collections
 
RSAC 365 Virtual Summit
January 27, 2021, Online
RSAC 365 Virtual Summit
Request Q&A
RSAC 365 Virtual Summit
From the conference
RSAC 365 Virtual Summit
Request Q&A
Video
Chasing Shadows: Securing APIs in a Digital Economy
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Add to favorites
169
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About the talk

Although APIs offer the means to rapidly roll out new business models and create pleasant customer experiences, APIs have become a growing target for attackers. The session includes a case study highlighting how a company increased API visibility to reduce risk and an Aite Group study which assessed the API security maturity of 31 financial services, fintech and insurtech companies.

About speaker

Joe Krull
Senior Analyst - Cybersecurity at Aite Group

Joe Krull, CISSP, CISA, IAM, CRISC, CIPP, is a senior analyst at Aite Group specializing in cybersecurity, privacy, and IT risk. He splits his time between San Antonio, Texas, and Tel Aviv, Israel, and has more than 45 years of security experience. Mr. Krull has worked in 115 countries and has provided consulting services to large enterprises on four continents. Most recently, he was a member of Accenture Security, where he focused on the impact of cybersecurity on mergers and acquisitions and cybersecurity strategies. Prior to Accenture, his consulting experience included a leadership role with a Big Four, a senior role at an AppSec vendor, and leading his own company. Prior to consulting, he was the CISO at three Global 1000 companies, and an operations officer at seven U.S. Embassies.

View the profile
Share

Weather hyperconnect in your ecosystem and powering a distributed Workforce rapidly leveraging. Cloud iot AI or other new technologies are here to help you manage Digital Risk your way at every stage of your journey. Good day, everyone and welcome to the session. We're going to talk about API Security on Joe, Crow a senior analyst. For I take group independent research organization. I am for 2020. We did quite a lot of research and Reporting run API security and I'm pleased to show the results of that research with

you today. So why should you care about API security? Well, the reason why is that apis are just absolutely exploding in our modern Enterprises today. Last year in 2019 as an organization called Nordic apis, which is a community of API developers. They estimated that there were more than 15,000 apis in use across the globe, but what's happened in the last year or so? Is that the use of a Felix is absolutely exploded because of coke. The covid-19 pandemic and the use of automated workflows and

Boston, all different kinds of collaboration tool. No one really knows how many apis are actually in use today. But empirically it's it's somewhere around the range of a hundred thousand or more. So, this is an area that is absolutely growing and there's a guarantee that if it hasn't touched you, it's definitely going to touch you in the future. Interesting statistic from Akamai came out. That said, 83% of all internet traffic is somehow related to API Seth. We thought that was quite a while we pressed on it. The more we

believe that to be true. What are apis being used for wealth are really the backbone of the digital economy and we have something in Europe called open banking, which is a regulation that requires Banks to be able to share information, and open up to fintech companies. That's driving API. Use also digital transformation, programmes and initiatives, and even iot deployments in the driverless cars. You can't, you can't run a driverless car without using a peons. So we found them during our initial research that most enterprising than

600 internal and external apis present in their environment. But we found us, we started our research in early 2020 that security awareness run. Apis is actually very low on it. Continues to be very low. So we started off with an interviewer, 26, Social Security Architects, and digital transformation specialist, and we just simply asked him how many environment? And they really didn't know. So at last year's RSA conference in in San Francisco. We actually did a lot of discussions with Security Professionals. Those scheduled an ad hoc and discuss question kept coming up and we

found that a lot of people that probably should have known, did not know, and there was a very low visibility run API. So a lot of things that we found out during our conversations and interviews is that there was a general assumption that traditional security products, like firewalls and load balancers and web application firewall. We're providing sufficient protection against the API, right? Guy text. And even there was a misconception about what a PR gateways do. And so, based on that.

We published an initial report that talk about my visibility around apis. And I'll touch on that in a moment in a study, but after we finish that first reported research, we kind of decided. Let's go talk to the people that are actually creating and managing apis. So over the summer, we did interviews with 53 application developers and Security Professionals, representing 31 different companies. These were mostly in fintechs ensure text and financial services organization where

we assume that the level of security would be quite High. And to be able to compare apples to apples. And oranges. The oranges, we came up with a methodology where we came up with a way to come up and measure the Saturday scores against seven competencies. And we're going to share that with you and in just a few minutes, but the bottom line on that secondary research was again, we found API security awareness to be very low. So what are the threats? Well, attackers are going after apis

for one primary reason in a couple of secondary reasons, but the main one is there's a low probability of detection. They're able to manipulate apis and use the API streams for all kinds of Nefarious purposes because most organizations have this limited visibility and very few capabilities to disrupt that attacks surface. So, what do they do in there? Stealing sensitive data, they're messing with business operations, manipulating data streams. Are there, taking advantage of the ability to abuse business, logic,

get unauthorized access and even do denial-of-service attacks. So there are lots of threats to apis. And that's why our mission is to try to raise awareness and help people understand that if Not securing your API. It's probably just a matter of time before you'll have an issue with them. So one of the other things we learned is that this is not something that we're talking about nation-state attacks. And we're not talking about sophisticated, cyber criminals. Actually, you can do a Bil-Jax without having a high level of expertise and you can buy

tools or or you can get them free. A lot of these are or no-cost tools and you can get them in the hacker Marketplace has been widely available. Attackers can use proxy tools. They can even get Services, they can get local services to be able to support their attacks and the books. That develop these tools actually update them on a fairly frequent basis. So if they are detected by certain products or solutions, they can keep avoiding those detection. Moats. And again at the RSA conference last February. I was able

to see a 15 year old high school student, do a live API attack. Against the gift card database and based upon his description. This is not something that requires a high level of expertise. And if you just Google any one of these tools, you'll find out that they are really prevalent in, in the Domaine, in the marketplaces and the places where hackers go to get their tools. So, we're not talking about small organizations that are being breached or having to publicly acknowledge their vulnerabilities. We're

talkin big companies like Cisco and Google and Facebook Twitter Salesforce Zoom Waze, and Amazon web services. Venmo had a particularly damaging incidents of an API vulnerability. Also in retail and Hospitality also in the automotive space and the most recent attack was a few weeks ago, was one of the dating services. That was a mobile application and they were because they're API was not properly configured all. You could actually extract from the database all kinds of user profiles or you can upgrade your service with actually pay without

paying for that premium service, so, These are just two examples of API attacks and Public Service as well. The most recent one was the Biden for president campaign had a very interesting app for managing their potential voters that suffered from a number of ATI Boulder abilities. And we have also seen in recent weeks that a lot of the covid-19 tracking application which of been pushed into the marketplace. Very, very quickly based on need also suffer from a beehive older buildings. So this is an example of one that was found as part of

Uber's bug Bounty program last year. And in this particular case, what happened was there were a number of security issues with the API, which allow the attacker to actually enumerate all different kinds of information within that database. They took advantage of the fact that that was really for authorization on the API. So just simply by intercepting the stream, you could do a lot of things with the apis that you really shouldn't do. The attackers were able would could have been able to see from the error messages. All kinds of sensitive information

and what they did was an enumeration attack by on the part of the application that allows you to add a driver. By simply manipulating the API, they could actually pull information from the fleet manager and get access to all different kinds of things about the existing drivers. I like your email addresses, like their phone numbers at all of the kinds of sensitive information related to that. So this is just one simple example of an API based folder ability that could have resulted in a pretty significant

privacy and security issue for an organization like uber that really realized extensively on apis for their application. So what do we do about this? Well, as I mentioned before, I can confirm based upon a research that firewalls load balances and wax just aren't given. You sufficient visibility into API calls and traffic blows. But there's good news here. There are a number of solution providers that are rolling out new products, a new solution. These are

API security gateways, which we did a report on in the early part of the year to 2020, or seen the ability to use artificial intelligence to do traffic analysis, on apis, and also services that you can do Discovery, and all different kinds of ways to protect your API available as a web service. But from our first little research we recommended that organizations just simply make API security part of their cyber security strategy and acknowledge that they're going to need to go beyond the traditional cyberdefenses.

If they intend to provide more protection against api-based attacks. So quick case study here. I had an opportunity to speak with a security professional at a large financial services company trillion, dollars under management and more than 20,000 employees and their issue began in 2018, when they were seeing what they thought were credential stuffing attacks where, you know, what chapters were using a big stores of credentials that have been compromised to previous attacks and it was sending these in

trying to go against an API endpoint until they found one, that would give them access to the infrastructure. And what they did. When they saw these credential stuffing attacks, they had all different kinds of manual process and Technical controls and they could spin up incident response and they would open up ridgelines, what really they didn't know what was happening with the API traffic. So they had very limited ability to do anything about these attacks and they kept changing time of day, going up against different services. And what happened was in the first half of

2019. They not only their web applications were impacted, but then it extended to their mobile services as well. So the skirt confessional, I talked to said that for the better part of a year. They were running around playing whack-a-mole trying to deal with this different type of attack. So what did they do? They instituted an API enabled, traffic analysis of product, and they put it as a bribe and deployment to an API Gateway, that was already in their environment and

shortly after they put that product in, they were able to see indications of the attacks against not only cookies, but also against choking. And this gave them a lot of intelligence about where they needed to go to shore up their defenses. And the product that was looking at the, this AI based product that was looking at them. They were able to produce alerts and send those to their Splunk a platform and create all kinds of new use cases related to API Beach. And this gave the security team a lot of disability but a lot of

capability to rapidly respond to when they saw things that match these use cases. And what also happened was an unintended consequence. They were finding all kinds of network issues. For instance. They found that they had. It was a troubleshooting application that had that was supposed to be disabled. When the application went to deployment that somehow never was disabled and it was constantly running tests against the application, which is impacting performance, and they found that through this API visibility capability.

So what happened was they raised awareness of API security by deploying. This is solution and they felt like they were much better stead to actually do something about it by implementing the solution. So in the summer time we decided let's go look and see how ABI development practices are done. So what we did, there was we created this methodology. We looked at, you know, what are developers doing with regards to API? How are they actually creating and how they managing them?

So, based upon the interviews, we also looked at the documentation. We looked at presentations. We looked at all different kinds of materials to be able to assess the charity against 780i competencies. And because we wanted to be fair and I measurements we use the Carnegie Mellon cnmi, which is a a rating schedule that you can be able to address maturity. And at the end of our research which took place over about a 2 and 1/2 to 3 month. We really found that security awareness even regarding what kind of

attack friends were out there in the in the environment was very low. It was slow at financial institutions, and it was really low. At been texted ensure tech companies which tend to be smaller. But we're creating these very powerful API. Piece of the seven areas. We looked at and I'll go through each one in detail, but we felt that it was important that an organization have a central point of contact for API security. We wanted to know where their tools or message to manage the inventory of external and internal and external

apri serve Define process to consummate. The archon does the company follow application security practices until they do? Those include API security? Specifically do they publish an API or did they offer an API development portal to allow those that consumed the apis to be able to implement them properly? Do they have a security training program? It doesn't include API specific content. Does a company have a process for Homeland Security incidents? And does that include app? Second API security

criteria. We thought that these seven areas. Where a good Benchmark for how does the organization manage the sific Lee API security related issues in their environment? so, The first one. So we asked, is there a designated API security point of contact? And we found an old lady one company of the 31 that we spoke to actually have a designated point of contact. 17 company said no, and we don't really have any plan to appoint. A point of contact 13 said well, we have a decentralized model were API creation is done in the various teams and his kind of

spread all around the organization. So each team is responsible for their own apis all. And we felt that from a cybersecurity stand point from wrist and point that lack of a champion can have developers doing bad things, like trying to implement API in a way that's not secure or maybe to contravene policies of the organization. So we raided them about medium-scale on this it repeatable, but they're certainly areas for improvement. So, do you and montuori

your apis? And this goes back to the visibility question. Now, from a creation and implementation standpoint. So nearly half of them, half of the companies, we spoke to they couldn't tell us how many apis that they had created or deployed over managing. They kind of had a rough number but no, real inventory and 30% had no inventory whatsoever. They say, well, we created, we manage them, but we don't keep track of him at all. So we saw inconsistencies between the use of external and internal API. So we did see one area

that we considered to be a best practice. There was an organization that says we treat all external and internal apis the same way. We put them through the same security controls and rigor regardless of whether their internal to organization or exposed out to Partners across the internet. And the reason they did that they said, well in a fast-moving business environment, an internal API can quickly become an external API, and they just treated them all the same and a pride applied, a very high level of rigor, to that. We thought that was the best practice.

But still, because they're not keeping track of the number of apis. They're creating this poor visibility, can really contribute to cyber risk. So, Arthur question was, do you have controls for third-party API? And 19 of them were actually doing some kind of due diligence on their third-party providers. 10 companies did it on a case-by-case basis but two companies, we spoke to said, we don't do any due diligence that all the developers go out. They find the API, they need they contact the

organization and they integrate these apis into their products. So what happens there is if you're implementing third-party apis, it can really have an impact on the performance. If they're fully coated all or they're not properly implemented and I can also increase cyber risk. And another thing is that if you're an attacker, you can pose as a third-party API provider and you can slip into the stream and start to do pretty bad. Thanks. So controlling third-party apis. It's something that we felt was a something that the organization

should really certain nuts. So we ask do you perform application security testing and the good news there is well, all Thirty-One company said. They're performed some type of app suggesting. So we thought that was a great idea and we solve both devops and agile, environment hybrid environments with different teams using different methodologies. Interesting. Lee enough. We did find a company's that we're doing threat modeling, which we thought was a best practice and to actually had bug Bounty programs, but of the 31 companies that we bow to

26 of them were not specifically testing their API. What they were doing is waiting until the product was done, or the APR was was complete and they were doing penetration testing, and it was our feeling that finding these things during penetration testing just shortly before going to production or making it. API visible was probably too late in the development change. Really have much impact on it. Next we ask do you publish an API catalog 15 of the 31 companies said they

don't publish a catalog and we don't provide development portal to help people implement the apis. That we create. So why you want to do this? Well, you do catalogs. So you can help your own developers quickly. Find out what approved apis already available within your organization and development portal, actually, help your customers or your users. You give them guidance on. How is the best way I can implement this API and how should I secure it? So what happens when you don't have it? Is that a developer may go out

and create a duplicate or similar API? And because it's duplicate it doesn't go through any kind of proper testing and approval. And we found that one of the biggest issues with development of apis is that the developers continue to have questions or issues or challenges related to authentication and authorization and this is an area that can really be problematic both from an API creation and a management standpoint. So we asked about application security training and we saw the wide variance and how training

is done for developers 14 of the 31 companies that will we do training but it's really high level training its compliance. We do it because our customers require. It really doesn't provide much in the way of apps that guidance. It's mostly around. What are the company policies, password management and stuff like that. We really didn't feel that that was going to be. Sufficiently targeted for creation of APR 13 of the company's specifically mentioned that they use the old washed-up 10 in their training but interesting Lee enough. Only two of the 31 companies we

spoke to said that they were aware that OS but actually come up with a separate top 10 for API Security in 2019, and they were quite surprised when we pointed them to go to. Look at that resource. None of the companies that we spoke to provided any API security specific training to their developers. This was one of the more interesting findings from our research. Not one was providing any API security training. So do you have message to identify and Report security incidents?

Well, neither the company said pretty good document and processes that we heard of them we've reviewed and it was good for handling security incidents with. It was good. Somebody's been have received shards and they had call trees and all the things you would expect when you were talking about identifying reporting Security in what 11 of those companies say, well, we don't have anything like that will just handle these things as they pop up. And chain companies didn't have anything at all. In fact, check. It was kind of foreign to them to even consider that they needed to have processes

for handling security incident. None of the companies we spoke to and none of the materials that we reviewed had any guidance at all specifically related to a p. I So two companies said they had actually had API security related incidents that have been reported to them. They didn't find them. It was their customers that found them and 20 of the company's 20 of the 31 said, yep, we had problems, but we found it during third-party penetration testing. And as I say, that's pretty late in the

process to be able to find vulnerabilities. So, our recommendations ways to improve API security. These were the things we put in our reports. We think that every organization that is either producing or consuming a p. I should have a knowledgeable representative Ray, KY security. We think that organization should Implement an API management platform. This is beyond keeping track with apis and spreadsheets or other. Manual means there are tools that you can use the manager. A pyats. We believe that

they should conduct thorough due diligence. On third-party API. They should Implement an API catalog and developer portal. It's not as hard as it sounds organization should expose all developers API security Concepts and this includes what kind of attacks are out there. What are the methodologies? What are the tactics of what are the procedures that the attackers are using to be forewarned? Is to be forearm. And to create and disseminate procedures for security incidents and include API specific details in there. Such as if there's an incident

or an anomaly that is actually an API. How do you quickly identify who developed it or who is responsible for managing that API? So you can do troubleshooting and or take the necessary measures to stop that particular attack? And finally, to include API security testing as fart of the software development life cycle. So these were our recommendations. We hope that we've been able to raise awareness, run API security, because apis are going to continue to be used all across the infrastructure, all

across different markets in different verticals and now is the time to start to focus on how to check. So I encourage you to know. If you have anything you'd like to go deeper onto, you want to enter that into the chat window? We can discuss that as we go along. So I thank you very much for your participation today. And I look forward to additional questions and additional conversation around the subject of API security.

Cackle comments for the website

Buy this talk

Access to the talk “Chasing Shadows: Securing APIs in a Digital Economy”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Ticket

Get access to all videos “RSAC 365 Virtual Summit”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Ticket

Similar talks

Jennifer Czaplewski
Director of the Product Security at Target
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Jason Rivera
Director, Strategic Threat Advisory Group at CrowdStrike
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Jamie Dicken
Director, Security Assurance at Resilience
+ 1 speaker
Aaron Rinehart
Co-founder, CTO at Verica
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Buy this video

Video
Access to the talk “Chasing Shadows: Securing APIs in a Digital Economy”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
843 conferences
34172 speakers
12918 hours of content