Welcome to the Talking Security podcast. We will talk about items related to Microsoft's security. Hi everyone, welcome at a new recording of the Talking Security podcast. My name is Frans Oudendorp, and together with my co-host Pouyan, we are back with a new recording. This time we have a nice, severe, glass time. We talked about Defender for DevOps or DevOps security within Defender for Cloud. What topic do we have today? And what is the guest that we have Pouyan?
Yeah, it's great to be back again, Frans. The last week we had in the great session on the whole DevOps set up on Defender for Cloud. And today we are going to have a great host where we talk about Defender for API, which we will touch later on. Well, Ajinkya, last time we met Defender for API was announced, even yet. Can you please short introduce yourself and the team? Yeah, definitely. So, first of all, guys, thank you so much for inviting me.
I'm super, ready to be here and talk about the cool innovations we're doing for API security in Microsoft. So, I'm a product manager with Defender for API's team. So, Defender for API is one of the API focused security solutions. We are adding to our Cloud Native Application Protection Platform, which is Microsoft Defender 4 Cloud. So, it's going to be one of the new different plans that customers can enable to start adding that application or API specific security into their Cloud architecture.
Amazing. Thanks for taking, making time for us to join us today. Well, I think today's topic is really interesting and important. Definitely in the time that we are in with Cloud. And lots of development happening and lots of microservices going on. Cloud technologies. And I think what that is a lot important to have a lot of visibility, definitely when it comes to our APIs.
But before we dive deep into the Defender for API and the great features and it has, maybe it's good to start by for all our listeners to defining what is an API. And when our APIs typically use, can we give us a general overview for our listeners? Yeah, I think that is a great starting point to level set everyone's understanding of the artifact we aim to protect with different of our APIs.
An API which stands for Application Programming Interface is essentially a set of rules and protocols that allow one piece of software to interact with another. You can think of it like a waiter in a restaurant. You give the waiter your order or request and they take it to the kitchen and bring back the food or the data that you asked for. The waiter acts as a middleman ensuring that a smooth communication between you and the kitchen happens without you needing to know how the food was made.
Like similarly, API acts as a middleman between different software systems or services. API has a everywhere in today's digital age and have become the default mode of communication between application components. When you use an app on your phone to check whether book of flight or send a message, you're often interacting with multiple APIs behind the scene.
For example, a travel booking app may use one API to check flight availability, another one to process payments and yet another one to send you confirmation email. Businesses today rely on APIs to interact, to integrate with other systems, expand their functionality and enhance user experiences. They are crucial in modern software development, playing role in everything from cloud applications to internet of things devices to mobile apps and so much more.
Amazing. So, APIs are actually used everywhere in all kind of scenarios. As you explained, do you also see an increase in the uses of APIs in the time that we are in at the moment? Yeah, right now, like you mentioned, right? So earlier we had like monolithic application architecture, right? So where you had maybe tens of hundreds of requests going to one or handful of servers.
Now as microservices have become the default architectural paradigm and people are constructing much smaller nimble applications that are independent for independent quite a bit, APIs have become like I said, the mode of communication for these individual components, right? So now you have hundreds and thousands of requests going to hundreds and thousands of different microservices.
So in effect, the complexity of our applications has increased exponentially and also with that the shared amount of APIs that we developed has increased significantly. Yeah. And well, with all that microsignation is of course, so you can also say a lot of things are isolated. So why is APIs security then so important? Okay, give us some examples of the risks associated with APIs. Yeah, absolutely. Like, APIs security is a better amount, right, for any organization.
Because I mentioned earlier, APIs act as the gateways for different software systems to communicate. If an API is not secured correctly, it can become a vulnerable entry point for malicious actors to exploit, gain an authorized access and potentially compromise the system. One of the reports from Akamai mentioned that a staggering 83% of web traffic today is coming from APIs, right? So that's significant percentage.
This isn't surprising though, like I said, given the recent technological shifts, we are seeing towards migration to cloud adoption of microservices, right? So this is expected to happen. And the beauty of microservices is that they are independent, you're they are independent, right? So this approach while incredibly powerful and flexible brings with it a heightened level of complexity. You should think about the sheer volume of interactions that are happening between microservices.
It's exponential. And it's not just about internal communications. The plurif, the pluriferation of apps and demand of interconnectivity means that publicly exposed APIs are skyrocketing, right? So now the communication is not just happening internally within your application or within your VNet, enterprises are exposing APIs for external public as well, right? Current projections suggest that we will see over 1 billion APIs. It's basically exposed APIs by 2030.
Now just imagine the security implications of that number, right? So and one more thing, why API security is important is APIs by their very nature deal with sensitive data, right? A bridge in an API doesn't just risk exposing this data, the consequences can be catastrophic. We have seen instances of full accountic hours, disruptions and services and data breaches.
If you look at the most recent API related attacks, a clear pattern will emerge and it's very apparent to see that the threat is really real and no organization, irrespective of their size, bigger small, no one is immune from this threat, right? So the aftermath of a compromised API isn't just technical. It really has a ripple effect, right?
It can lead to loss of customer trust, it can damage a company's PR, there is significant financial repercussions, in forms of regulatory fines or revenue losses, right? And in some cases, we're talking about millions of dollars. So the cost of a API breach is pretty high. Some organizations can sustain it, not every organization can take that on their bad and sheets and still operate as if nothing's happened, right? So yeah. So yeah, if you want to even talk about specific risks, right?
Yeah, so indeed, so the research you mentioned, I think it's really also common in the time that we are in with organization going towards the cloud and facing that everything is now publicly has a public endpoint, I think that's in the same similar as what you are describing with the APIs. And also that there is no total visibility, everything is micro segmented and you don't have a fully charged, what we had in the data center time, everything was behind the firewall.
So if this is such a big topic for organization, if the numbers are so high and rising constantly and the rest I'll bring with it, like you mentioned, like one API can lead towards data leak and getting the whole platform compromised and all kinds of scenarios. Then the question raises, like, is it what are the challenges for organizations? Because to face and protect their APIs, is it that hard for them to do it or what are the common challenges in that?
Yeah, I think that's a great question and you tell me how much time do we have covered this. So there are so many, so many, right? So if you guys have become integral to modern business processes, right? And while they bring many benefits, they also introduce unique challenges when it comes to protection. Think about the complicity of more modern architecture. We talked about a bit, right?
So the shift to microservices and decentralized architecture means there are often many more APIs to manage. Imagine, you know, organization, how many developers are writing code versus how many security personnel you have, protecting that threat surface, right? So each one represents a each API represents a potential attacker, a vector, making the task of protection more complex. Then there is lack of visibility, which is a big one, right?
Many organizations don't have a comprehensive understanding of all the APIs that they have, right? It's like a wild waste for them. There are certain APIs. It really comes down to like the, the organization culture and how deldaged application development teams are in the reporting and documenting the APIs, right?
So at any given point, if you're a security operator, you need to have a very comprehensive understanding of which APIs are being developed, why are they being developed, what kind of data do they access, who has access to that data, right? So it becomes a very complex problem. So there is lack of visibility. Then you think about rapid development cycles, right?
So when speed to market is of critical essence, right, for business to have a very thriving presence in the market, when almost for everything that you have has several other alternatives, rapid application development is of critical essence for innovation. And then how do you keep your security practices at peace with that rate of development is another challenge, right?
The question we can talk about is inconsistencies, insecurity policies, right, adopted by different teams, that can lead to vulnerability. So you could have as the scale of organization increases, it's obviously a lot more difficult to have really consistent security standards implemented, right? So then you start getting a very patchy or you get to develop blind spots in your security strategy. So there's a system, that's a big one.
So right now, I think we've been in the shift from lexas systems to cloud architecture for over a decade now and it's still not, it's still an ongoing trend, right? So many businesses still rely on older systems that are not designed with modern security mindset, right? So integrating those old lexas systems with the new API is or introducing API is to do that into integration also introduces vulnerabilities. And there are more of these things, right?
There is third party integrations where you bring in maybe some functionality from an external party. So with that comes vulnerabilities that you don't even know about that may exist in your architecture. So there are so many more challenges, right? So like I said, we can do a full podcast, just talk about challenges in our, or maybe a few more initial updates. So the first point that you mentioned was really interesting is the giving the security teams the access to see what's going on.
And I think that aspect is also applicable for the whole developers, but also here. I mean giving the security team, letting them assess and react on certain incidents is really important that working together is really key. So what are some real word examples of the case, take a share of some of those incidents or attacks on APIs that highlighted the need for improvement in security? Are there any known cases that you can share with us?
Yeah, like see these are happening day in day out, right? And like there is plenty of examples I can share. But let's focus on some of the high profile attacks that have happened in recent years, right? So like right before we started our podcast recording, we're talking about optos in Australia, right? So in September 2022 optos is Australia's third largest telecommunications company.
So for the data breach of victims, of current customers and for more customers through an unprotected and publicly exposed API, what it meant is this API did not require any user authentication before facilitating a connection.
So anyone that could have discovered the API on the internet could connect to it without submitting a username or password, right? So that's one example that comes to mind. Overall the amount of customers that got impacted, they are proportional to like 40% of Australia's population, right? So that's huge. Yeah, then you talk about Facebook and Cambridge Analytica, right? So this is probably the most infamous example because it got a lot of media attention.
But Cambridge Analytica harvested personal data of millions of Facebook users without consent, all made possible through Facebook's API. So now technically this is not a breach since the API worked as intended. It's a cautionary tale about the need for strong access controls and understanding the downstream consequences of data access.
And then there was when more data leak that happened, when more which is a popular payment sample left its transaction API open to public. As a result, a researcher was able to scrape details of nearly 7 million transactions, including using names and transaction descriptions, right? And then go on and on with the list of like high profile attacks that have happened. And this is that's why I said, early or that the 30s very real and really no one is immune from it.
Yeah, that because software development and development of infrastructure is good and so on is much more and more. So the need for an security system that is controlling and monitoring APIs must be there. And we're talking about
the Fender for API within Defender for Cloud. It's a public preview at moment of recording that where we have this recording. What can you say about Defender for API? How that is helping protecting organizations within API with the APIs that they are facing or that they are using.
Yeah, definitely. So I would love to talk about different of the APIs, but maybe we should also talk about types of security risks, right? So I know we are an asked about this question and I skipped over it, but what kind of security risks exist right with API.
So before diving into what the solution is, what are the risks? Let's talk about the problem. Yeah, let's talk about the problem, right? So we talked a bit about information exposure, right? That has happened in the recent attacks. That's very real. Then there is second problem of broken authentication or authorization, right? So if APIs don't implement robust authentication mechanisms attackers can impersonate legitimate users leading to an authorized access to data, right?
And this can be your customers sensitive data like PI information. It could be your organizations in selection icon, right? So anything that you've that is very critical to the success of the business can get compromised. There are injection attacks. So just like databases or web apps, APIs are susceptible to injection attacks where attackers and malicious data as input in the API to trick it to behave as a certain way and do unintended outcomes get on ended outcomes.
And also, APIs can be extruded for like if there is no proper late rate limiting on how many requests a specific user should get or how do you handle that certain spike in request right? So without proper rate limiting an attacker can send a large number of requests to APIs in the short amount of time potentially leading to a denial of service attack, right? So those are like some of the risks that exist.
And there is no like there are secretary solutions that do bits and pieces of coverage for this, but there really you cannot use like one size fits all solution when it comes to APIs, right? And you need to understand how an API behaves and what it uses patterns are and then have a very purposeful solution for it. So with that I'll take a pause and then we can talk about different for APIs.
I mean to sum it up, I think, can we say that the fan of our API does partially security, I mean when it comes to API security, it's partially configuration partially an only detection like what behavior, so something can be felt but misused in certain ways. And you also mentioned things like injecting like adding data to proper sorts of some kind of SQL injection behavior but baselines API wise.
Right, yeah, so also so these problems for exist like the APIs and the way we are approaching this right so for let's talk about different of API's still here. So now the time how is the vendor for API is exactly going to fix this or help us. So we talked about the security risks that exist with the APIs. Now let's dive into how different of our APIs is crafted to comprehensively protect your API infrastructure, right, especially in environments like Azure.
So I talk about first the security posture piece, right, so this is where you want to understand your API landscape first, so we help with building a unified inventory of APIs. So like we talked about the disparity in number of developers building APIs was a security operator so trying to protect the landscape. So with different of our APIs, organizations can achieve central visibility into all the APIs management Azure API management.
Now once we have detected these APIs and brought into a single pane of class, we look at security insights and API hardening, right, so we tell you what can we learn about these APIs.
So we are able to pinpoint APIs directly exposed and they are no longer in use, so this could be APIs that you assume were deprecated, maybe they are legacy API versions that shouldn't be lingering around which typically do not receive the most latest security patches, for example, then we can easily point them out and as a security persona, you can work with the development team should duplicate those.
Different of APIs is comfortable at identifying high risk misconfigurations, especially scenarios where there are no authentications are in that equitly authentication is set up, right, so. And the last piece in API hardening is very alertly assist the security controls of Azure API management gateway against recognized best practices, right, so that's the secure posture piece. Another aspect here is also around sensitive data classification, so you know how.
So we use the same classification that customers define to classify APIs based on data they're handling that way you have the visibility into data in motion. So that's the secure posture piece. Next there is like proactive threat hunting right so with different CCS PM cloud secure posture management plan.
And then we have integration into cloud security explorer and attack attack path analysis, so security personals can swiftly prioritize and mitigate risks by querying different particular aspects of APIs to look at what vulnerabilities may exist in the organization. And the last piece is around threat detection and with continuous monitoring. Different of the APIs is equipped to detect top OS API threats.
We have a set of machine learning based models and full based models to detect active threats against your API APIs and generate an alert based on it. So based on that again, since we are part of the MDC platform, Microsoft different to the cloud. All of these insights that we generate or alerts that we generate can be streamed into your popular seam solution. And then instant response teams can respond or trigger a predefined automation to to remediate that vulnerability.
Protection technologies that you describe. And before we dive more in details later on on the technologies and I think what are the most important options is when it comes to security these days is integration. You mentioned at the end for example the integration with Sentinel. What other marks of security products does the Fender for API integrates but gave us also some ideas on what we can achieve after those integrations.
Yeah, like three things come to mind, right, so the current offering that we have comes with initial set of integrations and we will be adding more. The first one is like I talked about Microsoft Sentinel integration. So as Microsoft cloud native seam which is security information and event management solution.
Sentinel offers fast thread detection and response capabilities different for APIs feeds its recommendations and alerts into Sentinel allowing for a holistic view of the threat landscape and called in into response across various platforms. So that's the first one. Second is integration with Azure API management. So different for APIs is not just another both on solution. It's natively integrated into Azure API management portal.
This integration means that the user do not have to have between multiple platforms to get a comprehensive view of API security. By providing this native experience in the AP importal different for API ensures that developers operation teams and security professionals was centralized familiar and efficient environment to manage and secure the APIs.
And then one of the third integrations which is under works right now or may be live by the time you publish this podcast is different for APIs, leverages Microsoft overview again for data discovery and classification capabilities to better understand the types of data that APIs handle. And this would provide added protection for sensitive or regulated data types ensuring that API endpoint handling such data are easily identified for risk prioritization.
And last time we talked about the depth of security there was really easy to put that on was a one checkmark for example. How easy is it for the API security within different for cloud to enable that for customers so how easy is it to start with different the 5 p.r. Yeah, it's a great question right so getting started with different for APIs is designed to be straightforward and seamless, especially for those who are already familiar with Microsoft different for cloud.
Different for APIs shows up as one of the new different plans in the different in different of a cloud customers can navigate to the different plan space to review planned details in enable API security at a subscription level. Today you can select which APIs you would like to protect from a given subscription. Soon we will also add an option for customers to protect all APIs under a given subscription at scale. Likewise there is also a native experience in Azure API management.
Where on the side navigation under security there's a new of new label for different of a cloud and customers can follow that link within the Azure API management portal. To enable different of APIs right so there is a native experience there in itself. So it's really straightforward for customers to enable that at the moment in public preview. Yes, that is correct.
Yeah, it's amazing to see how easy is some complex and issue can be fixed by just going towards the developer cloud and enabling some settings. So I think you mentioned a lot of the security risk and I was curious is like what is in your opinion the significance of an of API security in today's digital world and why should organizations pay special attention to as you mentioned a lot of the risks. But what would be the key for you to focus on?
Yeah, like in today's hyper connected digital world the role of APIs has never been more prominent right so making APIs the securities most paramount problem to solve right so. I think it was a god news study that pointed out that APIs are the top at a vector that bad actors use for exploiting an enterprise right so we talked about flow reflux.
So we talked about digital transformation so as companies adopt more and more cloud infrastructure or microservices and they are dealing with legacy systems. So these APIs are fueling a lot of that transformation so again that is important there is sensitive data handling through APIs. And I think one thing that we haven't touched upon is the regulatory scrutiny right so again with data protection laws like GDPR, CCPA or hip and others coming into play.
So there are under stringent regulations to protect users data right in security, peers can lead to non compliance. Result in heavy fines and legal ramifications so again like that like underscores the motivations for the organization to invest in a security. And and if you if you would look on the organizations type which type of business organization will benefit the most in your opinion from max of the fan of right at the moment.
Yeah I think that's a great question and I have a lot of relays to go through right so. The the great thing is that a different for APIs is designed with versatility versatility in mind right so aiming to address broad spectrum of api security concerns that organizations face today. So that's it let's look at specific sectors or businesses right that can really benefit so first is large enterprises right especially those with complex art IT infrastructure.
So the API spanning across different departments or branches will find significant value the centralized visibility aspect that we bring is like a boom for security operator. Financial institutions is another one think about banks payment gateways or when they start up that rely heavily on API is for transactions data transfer or third party integrations. Other organizations with APIs facilitating data exchange between medical devices patient record systems another Health platforms.
Data privacy and meeting regulatory standards like hip hop, become crucial. commerce platforms. These are businesses relying on APIs for payment processing inventory management, customer data handling, telecommunications like we talked about optas in Australia. So, that's one area. Start up in innovators like we talked about large organizations on the top end, smaller organizations as well, who are especially those in the take-dome in right. So, often building their
entire business models around digital platforms. These young companies can establish strong security foundations early on by leveraging solutions like different FIAPIs. So, really, the answer is almost everyone can benefit. That was almost my real-time. Yeah. Exactly. So, it's awesome to see that to hear also that the product is developed not only for the enterprise, but also accessible for a youngware and a smaller organization. That means that you guys have simplified the stepping
for those organizations as well. And the product is able to do advanced configuration for enterprises, for example, maybe. So, now we talked about the organization types. Maybe it's also also some to deep a little bit deeper into the product and how the vendor for API operates as well. For instance, what technologies or methodologies are used for trade detection response? Right. Let's see, what can I share? I can't talk a ton about the products
interworking thread now because we are in the preview phase. But at the heart of different for API's thread detection mechanism is a combination of advanced machine learning models. These models analyze API patterns and identify anomalies that deviate from the baseline. For example, if there is a certain spike in the request volume or unexpected data transfer,
the system recognizes it as anomalous and triggers an alert. Once a thread is detected, customers can orchestrate trade response via custom logic apps or workflow automation. So, this could include isolating the affected API blocking malicious IP addresses or initiating a predefined recovery protocol. Similarly, one of the cool things is around sensitive data classification. So, the data from a organization perspective are like ground
jewels and they invest a lot in protecting data in different storages. So, that's data at rest. What we bring to the table is same type of data classification or identification when the data is in motion through APIs. Now, you get that complete picture of how the data resides in different storages. At the same time, while it's transiting through APIs, we are able to use the same classification that you may have defined to call that out.
Amazing. So, all this technology that is used on there is also technologies for example, used by products that you mentioned like perfue. I mean, this is because there is a lot of integration
going on. And looking towards the future, looking at the products and the integration that are now in place, like you mentioned integration with seam building your own response there or integration with perfue or other topics, what are the future developments and what can we expect to see even more based on what you can share, of course, in the Fender for API.
Yeah. Like, without giving too many specifics, right? So, I think in general, like API security space, spans across or short span across full API lifecycle, right? Which includes discovery of APIs, understanding what you can learn about those APIs, then there is protection, what can you do to protect your existing threat landscape, detection, which is runtime. How do you monitor APIs, what's flowing through the APIs, who's accessing those and then response, right? So, if you detect and anomaly,
you're a threat, how do you respond to it? So, we will continue investing along all of those areas, right? So, from a discovery side, for example, today we support APIs managed in Azure API management. So, we'll look to add even more sources of APIs, depending on
where we feel is the biggest customer ask. So, there is will expand our discovery capabilities, in terms of understanding, we'll look at understanding the context of access or understanding the intent behind an API creation, for example. In terms of protection or I think shift left is another thing that is interesting for us, right? So, how can you find vulnerabilities before the end-up introduction? That's an area of interest. And lastly, the detection piece, right? So, we already have a robust
set of machine learning detections. So, we'll continue finding tuning those in terms of accuracy and adding more actionability to those detections. And then what more can we do in terms of finding new threats that keep evolving? Amazing. I think a lot of good to look forward for. I think definitely listening to you and then hearing that so many APIs are around the world, definitely taking it to a broader scene or giving more coverage over the APIs would be really awesome.
Yeah, I think we covered a lot. You covered a lot today. If you look into the future, I want to take the opportunity to make another appointment, maybe in a few months or in a half year or so. Can we come back and do another recording later on if the product is GA for example in the next future, because we're now still in public preview. Somewhere, it will be GA. If it's GA, can we do another one as well to talk about what's new and how we can
organize that? Yeah, definitely. I would love to come back and speak with you and your audiences about the cool innovations we continue to do on the platform. It's exciting space. We are innovating every single day. So, there will always be more to talk about. So, I would love to come back sometime in the future.
Shall we? Let's do that. One last question. Is there some remark for our listeners that you want to make or is there a highlight that you want to point out regarding the Fender for API or is a call or a call to action or something else? Is there something you want to say to our listeners? Yeah, I would keep it simple. Great. I go right out. We are like like to say typically when I go talk to customers. We are on the ground floor right now.
Right? So, this is the time when you get to touch and feel the product and shape it. So, try it out. Give us feedback and we'll act on it. I mean, it's really easy to turn it on. Yeah, actually. Yeah, thank you, Jinkha, for joining us today. I think it's some really great topic. Also for our listeners, at least to be aware of the fact that this is going on. I think a lot of organizations aren't aware of this topic or that it's good to point it out.
Thanks for joining us. Thanks for sharing your feedback to our listeners. How to get started? What to watch for? The importance of this topic for us for all of us. Yeah, thank you. And thanks, Jinkha. Thank you, as a listener. Thanks for listening to this episode. I'm listening because we don't have a video of this at the moment, but later on we will do that as well.
But hopefully we see each other next time. But before next time, when we record, you can hit the subscribe button on YouTube or on our podcast platforms to subscribe. Because if you do that, you know when the latest recording will be online. So please do that. If you have feedback on our recordings, please let us know that there can be on our socials or on our website talkingsure.nl. You can see everything about it.
And yeah, we continue this Defender for Cloud series. Next time, probably with a Defender for Containers or Defender for OT. Let's see a lot of great sessions in the planning. So yeah, we have a lot of a lot to do. So thank you for now. And let's see each other next time. Thank you.