 Hello and welcome to Cloud Native Security Day. My name is Adora and I am so excited to be giving this talk to you today. And the title of my talk is Design Secure Cloud Applications. It's 2020 and we have moved or are currently moving all of our computing to the cloud in different forms and this comes with a few benefits. You don't need to download anything to any particular software anymore. Your applications and utilities are over the internet. You can manipulate and configure your apps online and you have on-demand self-service and a lot of other benefits for moving to the cloud. But the truth is, with all of these benefits comes some kind of responsibility. With all of these benefits also come some disadvantages that we need to be aware of so that we can control. And to that effect, I'm going to play a short video that describes this problem I'm about to talk about in layman terms. Hey there, I'm going to tell you a story about what happens when you do not protect public resources. This house has water supply in form of a bucket at the compound. This is a housemate who actually needs water. He gets on into his ball and goes back inside. This second person who happens not to be a housemate comes to the public area where the water is and makes it unfit for everyone to use by washing her hands inside. This housemate happened to be walking in the direction of the water and accidentally kicked it. Now all the water is gone. Why did this happen? Because access to the water wasn't properly regulated. How do we fix this? Take the bucket away and keep it in a safe place. Secure the house to prevent outsiders walking by from tampering with resources only meant for housemates. Connect a tap so that housemates get water in a structured way. The end. So as we can see from that story, not properly securing our cloud resources can lead to things like human error where the actual developer is even the one that makes the mistake like a very random example here would be not properly securing your resources used in production and a developer on your team goes there and accidentally deletes it. Malicious attacks, that's a very common example where you have people that are not supposed to have access to the system gain attack and do very ridiculous things to your application and to your data. You can also fall into legal or compliance issues where you are having different lawsuits because your customers feel that their data is not secure and you're using their data for unspeakable things. It might just be the case that you're actually not using their data for unspeakable things but your application is not secure enough and their data is not secure. So somehow, some way things are just getting wrong and everything isn't going right. And in this talk, I'm going to be listing a few ways that you can secure your cloud applications. I'll be talking about three security cloud patterns and I'll also be talking about a few things that you can do beyond these patterns when you are coding, when you are designing and in other software engineering steps. But before I start to do that, I would want to quickly introduce myself. My name is Adora and I am a software engineer at the Microsoft Mixed Reality team. I'm a tech content creator at Adora Hack. Adora Hack is a blog that I started myself. I write articles and I also publish YouTube videos under the brand Adora Hack. I am the co-founder of Unstack which is a community where we focus more on hands-on workshops as opposed to just normal talks because we feel that many people learn more by doing... I'm also on the advisory board of VRAR Nigeria which is a local chapter, a Nigerian chapter of the VRAR community and I believe this makes sense for me because as someone that is very excited about mixed reality and what we can do with that technology I would expect that personally myself I would be in a community of... I would be running or at least be in a community where I have mixed reality developers and I am also surrounded by people enthusiastic about this technology and what we can do with it in the future. I am also popular in Twitter as Adoramodo you can check me out, my Twitter handle will be on the screen. So before you start building your application you would think what kind of application am I building and you might need to run some kind of security checklist so that you can basically analyze and understand how your application needs to be secured if your application even needs to be secured and there are some questions that you might ask yourself which is will my app contain sensitive customer data? Where and how is my application's data stored? Will this application be available over the internet or just internally? How do I plan to verify my user's identity? What sensitive tasks are performed in my application? Does my application perform any risky software activities? And these questions would help you understand what the security requirements of your application are asking yourself these six key questions and more if possible but these six key questions would actually help you understand what is required in your system in terms of security So when you say will my app contain sensitive data and if your app does contain sensitive data then you should be thinking about a data protection method for your application If sensitive tasks are going to be performed in your application you might be thinking about authentication and authorization and you might also be thinking about multiple steps in the process which you'd have to do for example if you're going to be performing a sensitive task like transferring money Yes, you would want to authenticate the user I mean to the app itself but you might also want to do one kind of extra verification step before the money is transferred So these are a few things that you might want to think about and these would help you understand the level of security And based on these six questions I went ahead to break down these questions and put them into different blocks that I felt were similar and these six questions come down into two different major umbrellas One being data protection and the other being identity management And based on that I'm going to be talking about like I said three security patterns in this talk The data protection pattern will be the gatekeeper pattern The two identity management patterns I will be talking about will be the federated identity pattern and the valet key pattern So now let's talk about the gatekeeper pattern Applications functionality are usually exposed when they accept and process a client's request If the system is compromised and a malicious user gains access or sensitive data will be exposed So in cases like this you have to introduce a gatekeeper that helps with request validation and what this gatekeeper does basically is that it's as the name implies the gatekeeper it's in the middle of the client and the actual host and the gatekeeper exposes one endpoint to the client and that's the end point that the client would always call and when the client calls that endpoint the gatekeeper validates and just sanitizes the request checks that based on all the requirements that I have based on what a sane request should be I have validated this request and I've sanitized it it's in case there's any, you know, web queries or anything funny or weird going on that shouldn't be going on and then based on that I can now call the host and then I make that, you know, call and then the host goes ahead to access my data access the service and access all that stuff and a real life example for that you can implement the gatekeeper in different ways you can have a gatekeeper role which would have like a limited privilege role and then you can also have a trusted role which is like in full privileged mode and the gatekeeper role exposes a public endpoint to the client and the public endpoint is what the client calls and once the client calls that endpoint like we've said the request is sanitized and the request is validated and then the internal endpoint is called and the internal endpoint is the endpoint that in turn makes you reach the service, you know, reach out to the service the next one for me will be the valet key pattern and this is an identity management scenario the valet key pattern actually helps you securely control access to data by using a token that expires after a period of time so this key or token can be used for authentication and authorization and the steps, the way this works is first of all, the user makes a request to the application for a particular resource and once the user makes that resource the application, you know, validates the request and generates a token and returns that token back to the user and now the user can use that token to access that resource but after a period of time, the token becomes invalid so the user would have to, you know, make another request again so an example of this would be, you know, requesting a particular resource and then getting SAS tokens after a while, your SAS tokens become invalid and you'd have to request another token so that's basically, you know how this works and these tokens would usually have some kind of access that you get so if you have read access to Azure Storage, for example if you get a token that gives you read access to Azure Storage you know that you can only read blogs read resources, read data read anything from Azure Storage but you cannot at any point write to that storage because you only have read permissions with the token that's available to you and I got this code from the Microsoft website the Microsoft documentation and this code shows you a sample of how you can generate a SAS token for a storage for Azure Storage so the first thing that happens is that, you know, yes, you create your blog status client and your blog container the method is called get shared access reference for a bloat and then we've defined the struct which is a storage entity SAS and that's what we want to return at the end of the day our storage entity SAS has our credentials which is our token and the blob URI that we actually want the URL to the blob that we want access to so we go ahead and we, you know, get the blobs and then we create a storage key credential we go ahead and specify a blob SAS builder we pass the name of the blob container we pass the name of the blob we specify the resource and we put a time constraint so this is when it should start and this is when you should get access and this is when your access should be revoked so for this particular example your access will be revoked after 10 minutes and the user has write access so we go ahead, create the SAS and then we return the SAS and the URI of the blob and then in other parts of the code you can take that and get access to, you know, Azure storage and write whatever you want to write to the storage because you are able to get write permissions the final pattern I will be talking about is the federated identity pattern which is also under the identity management scenario and this pattern allows you separate user authentication from application source code and delegates authentication to an external provider so how this works is, and this is sort of like claims based access control so how this works is your service is using some kind of an ID provider or some kind of STS and a user authenticates and requests an STS token and they get a token back from STS and then the user presents the token to the service and based on that the user is authenticated and based on, you know, what roles the user has and how, you know, you've implemented role-based access control basically and what data is in each claim what the user is able to do is now controlled and this is helpful for, you know, like single enterprise sign-on when you have multiple partners and when you have SAS applications so you can decide to be like, okay I'm going to provide this sort of I'm going to provide this sort of service to users in this particular tenant in this particular enterprise so if you try to access this thing and you are not under this tenant then I should kick you out basically so yeah, this is what this means as well I have explained these three security patterns and now I want to move on to the other ways that you can enforce security the first way is using multi-factor authentication this is very important nowadays just one password is no longer enough we have people that want to always just constantly break into things and take as much data, as much information as much things as they can take and for whatever reason if it's social media, if it's finance applications whatever it is that requires authentication depending on the level of importance and the level of security that you're going for using multi-factor authentication is very important and this could be in form of a third-party authenticator app this could be in form of sending OTPs to a user this could be in form of some kind of security question this could be in form of different codes that you give the user and the user could only use one code once and then once that code is used in authentication the code is now invalid and when the user has exhausted all their 10 codes for example, they can always regenerate new ones different ways, think of creative ways to just help secure the user's data secure the user's profile secure the application a lot more is that you should consider implementing JIT access for resources I talked about the developer possibly being the one to make the mistake at the beginning of this talk and one way to prevent that is by enforcing JIT on production resources for example for anyone to get access to production resources they need JIT access everyone by default doesn't have access and that way you can at least minimize and control the amount of times that all your data is deleted or your whole service goes away or everything is missing because not everyone just has random access to production resources and can do what they like with it another thing that is very important is to use stable authentication and authorization platforms and this is one of the reasons why the federated identity pattern is in existence requiring re-authentication for some actions as well for financial transactions once you've logged in I am great but if you want to transfer I don't know 1 million pounds or something it's always safe to re-authenticate the person before you go ahead with that transaction it's important to require I think it's mostly financial transactions that do this one other very important thing again is reducing your attack surface it could be something as small as just a machine that you are not using if you don't need that VM remove it the bigger your attack surface is the easier it is for unauthorized for unauthorized users to gain access and do malicious things on your application because now they have different points to try out if they try to gain access to your system through one point and it did not work out they will go somewhere else to try and then they will go somewhere else to try so you should try and make your attack surface as small as possible if you are not using any VM if there's anything that is in the cloud that you're supposed to be using but for whatever reason you are not using remove it until you need it and then you can always bring it back probably handle errors and exceptions this doesn't directly help with securing your system but it helps with telemetry it helps with monitoring why something is not working as it should in your system it helps with if something happens for example and the whole system crashed you know why it crashed it might be for a security reason it might be for other reasons different software could crash for different reasons but if you properly handle errors and exceptions it would help your debugging process and this also ties into the next point which is properly monitor your service and trigger alerts about issues so if there are serious issues you want to trigger alerts so that people can attend to them and fix them as fast as they can and your response time is pretty fast also encrypt sensitive data which I think is very important store sensitive things in a secret manager you can use Azure Key Vault for example or any other ones that you're interested in but do not for whatever reason had code important information don't have code sensitive data implement fail-safe measures if or whatever reason your application fails or crashes you want it to go back you know to a state that is safe and then somebody can try again or retry another thing is that you should consider threat modeling threat modeling is helpful especially in the initial process of trying to design your applications because it helps you understand the possible threats the same way initially I talked about asking yourself these questions that you can understand your security requirements with threat modeling you are analyzing your system and analyzing the flow of data the flow of operations in your system and understanding a possible area where you could get attacked a possible area where there could be a security breach and trying to mitigate that in your design before you start implementation and I'm going to be talking about the stride threat modeling and I'm going to be taking each threat and talking about it so let's talk about the first one if spoofing attacks would be the threat for example which means that it's an issue on authentication and one of the possible mitigations would be enforced you know HTTP connection if it's that somebody could possibly tamper with resources then it's a problem it's an integrity issue and then you should make sure that you're using valid SSL and TL certificate if reputation is a threat then you know you should consider enabling monitoring and doing proper instrumentation in your application if information disclosure is a threat then it's a serious threat and it's a confidentiality problem which you need to fix and one of the ways to fix that depending on how your application is set up is that you might decide to encrypt sensitive data or you might decide to implement data protection methods because you want to keep your data as you know confidential as possible if NAL of service is a threat then that's an availability problem and you might want to enable proper monitoring and proper instrumentation so that you can look at the logs of your application you can look at the metrics and you can see how well your availability is doing and possibly try and improve on that and it will give you like a clear view of what you're looking at evaluation of privilege is the threat then authorization is the problem and one way that you can mitigate this issue is by using like really secure identity management and going back to that the federated identity pattern is a way to help with this particular problem so other ways that you can implement security is by using libraries that are secure if you have to use open source libraries make sure that these libraries are actively maintained and if you can contribute to them that would be very nice as well but make sure these libraries are actively maintained and also update your service dependencies and prevent vulnerabilities and avoid hard coding I've talked about this before if you have any important data, any secrets, any keys make sure you are referencing them from some kind of secrets manager if you want to learn more about security I would suggest that you look at any of these links on the screen they'll be really helpful to you thank you for watching this talk like I said earlier I am truly honored to be giving this talk today thank you for watching this talk and enjoy the rest of your day