A developers guide for building Zero Trust ready apps - Kaylan Krishna

afternoon everyone uh my name is kalyan krishna i'm a product manager with microsoft azure active directory or microsoft identity division i uh welcome to my talk i work very closely okay let me first fix this is because it's not really presenting the way i want to is it yep thank you thank you for coming to my talk i am going to talk to you about what zero trust means for developers and before i get started can i get like a quick uh idea of how many of you are like developers or work with developers can i see some hands okay so that's great and uh how many of you are into let's say application management like integration monitoring okay fair enough so those are like the two uh primary audience personas that we basically want to address with this and uh so let's get started so uh zero trust has been around for a few years it got a lot of traction over the last one year or so and microsoft is doing all it can to basically make sure that our products our educational material our documents our tools essentially help you those who are who are looking into it or basically rolling it out one of the things that we heard back from our customers was essentially that the developers did not really figure out where their role was whatever they're supposed to do and and then we decided to basically carve out a part of what microsoft's recommendation is for developers and i'm going to present some of it to here zero trust is a vast area we cannot do it in a single session but we will give you enough pointers so you can go and basically follow up and uh with the necessary uh idea of how to go about it so to start the session i'm basically gonna just start with a quick entry to zero trust i'm gonna assume that most of you are familiar uh it's again a topic in itself uh then we would cover touch the the important topic that basically started the conversations of the initiative in microsoft it's like how i does it actually matters for developers and then i will share a few nuggets of recommendations for developers on what they need to do what is their responsibility what are the things that their application should follow in a year to make sure that their zero trust ready app and we'll give you some pointers that as a developer as an idea admin as an application administrator you should be able to follow up to basically get our up-to-date guidance on on what how developers should indicate zero trust in their application so yep uh before even i touch up on uh zero trust and what it is uh this is the first question that we all get at least from where i i said is like hey we have been following the security development life cycle or a synonym of it in our organization for all these years so why why follow zero trust and the answer to that is that if you have been following those you have to understand first that zero trust is not a replacement for everything that you have been following today okay so if you have security fundamentals like threat modeling code reviews pen testing they stay there okay all we do have done under zero trust is that we have re-evaluated the security practices and basically aggregated them into a certain bucket and you will see that as i go through these and if you go through our entire documentation there isn't exactly a lot of new stuff it's essentially a reorganization of a lot of things that as a developers as practitioners you have been following but you have to basically pay more attention to because the the perimeter has shifted you are now using a cloud and lateral movement is actually something that we see a lot happening okay so the primary motivator for zero trust in general and that also applies for developers and it actually hits developers very hard is that the culture of implicit trust has to give away to explicit verification what does what do we even mean by that there was a time when a developer you would develop an app you would put it into your apps a company's network and maybe you integrated with windows integrated author maybe you had your own customized implementation and it was all good you really didn't worry about it that somebody would come in into your network you had firewalls you have all the security teams in place to make sure that things don't come from outside and things more or less worked and developers really didn't have to do a lot of these thinking themselves then cloud happened your applications now stay in azure and aws and gcps your app is what an attacker basically uses to start their compromise they'll move laterally so if your app is the weak point that's where the attackers will stop and that's where the developers are being now asked to essentially look into the zero trust model the zero trust practices a little bit more carefully you cannot just assume that you have developed your app you have done what your business wanted you to do and you have some basic center sense of authentication and authorization and it's all fine your basic sense of authentication on authorization is what an attacker would actually use to see if they can get into the network get into the cloud and basically start their attacks okay and this is why developers now have to basically start looking into zero test principle a little bit so what are these principles i'm gonna cover it again for you for those who are new so essentially zero trust is made up of three principles the very first principle is verify explicitly which essentially says that if something hap if something is accessing a resource a simpler way to explain if somebody is going to use an application before they can get to that application make sure that you authenticate authorized based on all data points user application device identity location device self-service and workload and classification and anomalies the good news is that it's not a developer's job but i'll explain later okay the second one is use least privilege access it has remained as a practice for a very long time it's essentially about hey if a user signs into their application do not just assume that every resource on the hosting server or every resource on the network or every every every access to the data should be just assumed as something that that that gets to every user account you have to think about hey if a user signs in if your user logs into an application if an application is making access to some data they are just getting what they need and nothing more than that if you don't have those practices in place you would be your your your application your your authentication's education session would be used to get uh a lot more done uh than than what you had assumed for example if your application all it needed to do was to read a lot of data but if you have those permissions that where they the application can unintentionally write data when your application is going to be breached or attacked that's the thing that you weren't prepared for but the attacker will make use of third is assume breach and this is something that comes as the biggest surprise as a developer what zero trust says actually it basically applies to every practitioner you can no longer work with an assumption that your application cannot be breached you have to prepare your application you have to deploy it you have to run it you have to monitor it in a way where you are able to recover your application get it back online after a breach has happened it's kind of counterintuitive but the problem is because we don't want the breach to happen but unfortunately it does happen the worst part is not that what happens after the attackers do the the worst part could be hey you are a consumer site with millions of users and you are down for hours maybe days maybe you cannot even recover because your data is now in the hands of a ransomware so you have to as a developer make sure that you have the necessary uh mechanisms in place to recover from a breach when it happens as a developer most of most probably you would not be really you know be aware of when a breach happens is more of a i.t security thing but when it happens if you have done some proactive steps it will really help them to recover your application make it online uh much quicker so that's your zero trust and as i said if you look at the verify explicitly part of the zero system most of the hard work is actually done by the identity providers if you're using azure active directory google or tapping they will do the most work of making sure that the anomalies the the device detection the device compliance and all these things are taken care of usually as a developer the first thing you should do is to make sure that you shift the authentication parameter from your application to an identity provider do you have your own login screen you are going to be attacked you are actually a very very uh nice looking target for an attacker the moment you move it to an azure active directories of the world your application does not play that big of a part because the attacker now has to attack a very robust authentication system so most of the things that you look here that we talk about especially in the verify explicitly part of it will be taken care by the identity providers i i as long as you are integrated with them you have done the first and the best part you have taken care of the best part already okay the next thing is uh it's essentially for my developers again we keep getting asking a little so why should you bother to get your zero type flap ready now that i've explained a lot but i'll give you some very unique examples uh sorry clear examples and the common examples of why we keep hearing about it and why you should bother about it so number one is the i.t is rolling out zero trust what do we mean by that because when the zero trust practices and guidelines started to get rolled out somewhere i say mid last year like in a big way it was for the it administrators even today like i would say 95 99 of the guidance and steps and work is for the i.t administrators to do when they roll out they cannot always succeed a lot of things you know setting up firewalls you don't need like developers there for the most part but there will be certain steps where if if the it admins cannot succeed in rolling out if the developers have not prepared the app for it for example if you are enforcing mfa or if you are using ip addresses to blo or block traffic from if you are enforcing user compliance they do not always require participation from developers but there are some steps and i'll cover those right in the next slide which will not work out unless the developer has put an effort in it the most common place where this happens is credential rotation you are using secrets you are using certificates breach happens something bad happens the iit administrators the security tools that your company has purchased and used they should be able to rotate those credentials mark them as inactive remove them without the app going down it actually is quite easily possible with a little bit of an effort from a developer a lot of developers don't even look at it you're like hey i have a secret in my config file i deployed and no you don't put a secret in a config file because that cannot be rotated it should be somewhere like an azure keyword or some other security system where it can be rotated easily by the it admins without your application getting affected next mfa so if if an identity provider again azure activity octa ping is throwing out an ffa challenge and they will do it not just because the application is integrated or the policy says that every authenticated session should be in mfa there is a lot lot of risk based mfa between the session i take this laptop i go to another network the next time i'm gonna i try to access the app azure id aquatic depending upon the policy he said no you need to do an mfa again because i the policy dictates so in these cases applications break because they get what what's called as a challenge from the idp they are they are coded to integrate for authentication which essentially means i'm going to send a user back to you you send me back some tokens when it happens the other way around when the azure id says nope i'm not going to send there is a special challenge that you need to do it's all uh rfcs and you know standardized but but this requires a little bit of coding effort from the developers as well the third one is a little bit of microsoft specific how how many of you are familiar with microsoft graph okay so microsoft graph essentially is the api behind which most of an organization data sets think about all your users all your security groups all your policies all your data sharepoint site teams channels one drive everything sits behind it now microsoft graph has a permission model i cannot cover it in this session but sometimes if you have let's say an application that reads uh data from microsoft graph and all it needs to do is to let's say read a bunch of security groups but let's say there is a permission called directory.readwrite.all if an application has that permission that basically can destroy an entire azure id tenant if they wanted to they can make any easily so if your application is is coded to ask for permission like directly or rewrite or all when all it needed was security groups dot read which is a much lower privilege permission then the application is going to be a good vector for attackers so in these cases there are tools now and there are iit administrators who are basically getting very careful about what permission and application request on the various apis behind which the organization's data sets and in those cases as a developer you should be looking at hey i'm not going to take the biggest permission out because developers have that mindset if i'm on a laptop i should be an admin and well you need to be an admin to develop i agree but in a production your application might not need to be an admin it just needs the exact set of permissions and the privileges to actually get its job done and that mindset had to be developed because a lot of developers don't get it very easily unless they run into this consent problem that we call it okay this is something that came out as a surprise but we saw that we basically rolled out deprecating the basic authentication it's one of the protocols that's like super popular out there but it's turned out to be mostly quite insecure and we started asking developers to move to something like saml and open id and oauth if if you want to switch off basic authentication across your organization your app developers have to at least stop using it first okay so these are good cases some cases on where as a developer you would start to look into why your app should be zero trust ready is because uh reasons like this and more would would affect you okay i'm just gonna stop here is does anybody have any any similar initiatives or as a developer you have run into some some of these things or anybody wants to talk about it it's all new we've configured ews is so just to repeat what the question here uh he has third-party applications and please correct feel free to correct me if i'm wrong third-party app which basically are using aws which is the exchange web service which uses basic auth and it's super popular as well and ews has been trying to actually deprecate basic auth for a very long time they want everybody to move to the microsoft graph and open id that's question number one question number two is you have all these applications that you have in your azure id tenant to be specific and they have a bunch of permissions with microsoft graph and you're looking for a permission view of what it is okay so i'll answer the first question is that it actually is time because about four days ago i actually did a session on twitch on how to move from ews basic auth to azure id sorry microsoft graph we i'll share the link if i can find but if you want to look into it we have a two part session one is how has an id admin you can find the applications and what you need to do and the second part is essentially how as a developer what do you exactly need to do to move from basic or ews to microsoft graph open id so both both are available the second one which is essentially hey can i have a view of permissions it is something we previewed about three to four weeks ago unfortunately you might not find because azure active directory got renamed to microsoft entra so if you look at microsoft if you do a web search of microsoft entrap permission management it has started to roll out some of those visible you know visibility on what exactly is the permission set today that's being used what you have asked for is actually one of the two top ask for my with microsoft graph today number one is that we don't have a any request logs for microsoft graph usage which is something that a lot of the i.t admins and developers find frustrating and the second one is hey there is no visibility of how many applications and which permissions they are and can we get so we have we are rolling out a few more things apart from permission management hopefully in future things will come to a point where we can tell you can generate a report which says that this application has these many permissions but never uses more than you know it has 10 permissions but only uses two so you can go and ask the developers that i can i get rid of this other eight is because you're unnecessarily over permission so but but it's coming it's not there half it's basically started to roll out just just so that's exactly what we want to do is if a developer said hey i need these 10 permissions or the app breaks there is very little an id admin can basically have are you going to specifically look at every line of code and every api call it's not really possible so what we are working on is a report that essentially says that this application over the last seven days or a month has only used these permissions so this is the least amount that they actually need of the consent that has been provided for the entire set so but it's gonna take some time it's something that we are really very actively working on uh and and uh we hope to make it available it's a very well known problem we know it we are working towards it but it basically requires going through a lot of data and that's where things get a little slowed down when we try to bring it to you thank you any other questions observations okay cool next [Music] so basically i had covered it like as an introduction so it goes beyond id policy you know it's earlier code security was mostly about hey i write my code i write it properly it's if you deploy it on cloud if now it's security your application can be the the attack vector that that attackers would use to basically make a lateral movement so it's not just about your code anymore you have to as a developer rise up and basically embrace a few more practices and this is why it has become a practice that we want developers to start looking into so how to make zero trust apparently now i cannot go through all of it uh it's a huge it's not a huge but it's a substantial amount of information uh the but the most before we start talking about the various practices i want to call this out is that even with developer space the implementation is evolving uh so i'm gonna share the links where we microsoft publishes the latest bids uh please make it a habit or you know to go through there every three months maybe and and to make sure that you are up to date with the latest guidance that we have out there so the very first is the zero trust guidance center so this is an overall guidance center for uh for all of the zero trust work that microsoft has out there there is a part that we have started to develop for uh sorry developer developers itself so that's that's the link to this uh it's a big long one but that's wha