 Hi everyone. Good morning. Good afternoon. I am Evelyn Lam. I am a security architect at Morgan State and thanks Max for introducing me in my background. So I'm very delighted today to share my views in authentication space about the challenges in the cloud transformation journey. Now more than ever, enterprise companies are using cloud application as an increasing workplace space. Welcome home. It's the new normal. I am doing the presentation from home right now and this trend is not going away after the pandemic ends. We all know that, right? According to a survey conducted by Setata, before the pandemic already 17% of US employees work from home at least five days per week and that increased to 44% during the pandemic and 25% of the respondents of the survey would like to continue to work from home after the pandemic. So this work from home phenomenon has made the whole cloud transformation even more demanding than before but thankfully many organizations had started to shift their technology from on-premises to cloud before the pandemic. So in the last five years, we have seen enterprise relying more and more on, you know, the business-critical SaaS application, something, you know, like Google G Suite or Office 365 and Salesforce, right? And the collaboration tools shown that we are using right now and Google Mix even becoming more crucial today to empower organizations and also not perfect organization or enterprise to survive this pandemic and embrace them to the future world of remote working. And meanwhile, there are also some enterprise that have already started to deploy their in-house application on the proper cloud surface provider. So as all we know, there are the platform like AWS, Amazon web surface and also Microsoft Azure, the big player in that area. So what made them think differently to accelerate the cloud adoption? Firstly, I do think the software as a service, the SaaS model enable the employee device to connect to not only from the company corporate network in the past but also they can use their own device to connect, to go to use the firm application from the personal device from internet is an excellent for work from home. And secondly, with the cloud technologies becoming more and more mature every day, the desire to leverage the cost and feasibility benefits of cloud has always the concern about loss of control, data stability. And we can see some more conservative and highly regulated business like the financial industry, I work in the financial industry, the healthcare sector are increasingly adopting the public health service. But talking about the cloud security, even though many companies adopted the SaaS solution more are still earlier in the game or recently started the cloud transformation journey. So now the question is, does a workable SaaS integration mean a secure SaaS integration? It does not, right? So and how many enterprise really have the strategic solution to, you know, enable the cybersecurity culture to maintain the security standards substantially is still in question and we have a lot more to learn and explore. I just want to say it's very important to note that the security vulnerabilities of the cloud usually are not about the vulnerability of the service provider environment or a lot of storage. But I would say the real threads and gaps in cloud security are about what is being put in the cloud and how the cloud environment is conflict and managed by the consumer. So I mean the cloud consumer usually I refer to the IT organization or the security department of the consumer in the company. So and they are fully responsible for managing native cloud services and infrastructure security. Indeed enforcing security practice in a company could be really tough job. And I know that. So to be effective message lead to be from top down. So make sure the company executive on board with the cybersecurity values, including if in the funding to the security project, including funding the security awareness training to view a security culture among the employee is so important. Which means that when there is a very critical architecture decision to be made to enable cloud, then the security requirement must not be real as a barrier. But instead the essential elements to support the business. So and therefore in this presentation, I will go through some common stars integration security before the risk of unmanaged cloud identity and explain why adopting an identity for what we call IDP could solve a loss of authentication problem smarter than the traditional way on prem. So now let me move to the next slide. Challenges. Let's look at the difference between a conventional on prem and while versus the cloud environment. On prem, I look at it like a road garden where business activities was conduct within the office or the network boundaries monitor and guard by explicit firewall policy. So when the application of the company a host on the internal network and only accessible from a corporate device, then the security may think, you know, the device is legitimate. And therefore, only a single factor authentication, sometimes just resume and password is good enough to authenticate a term to a high risk application, you know, to do the prey to handle payroll information of the employee very sensitive information. But in contrast, the cloud, we sigh, it is more open and share environment. So the environment is accessible to basically any user in the world with any endpoint from any location and any device way. So that is very different in terms of the tech vectors and the vulnerabilities. And that's why we need strong authentication. It's so critical to protect, you know, the application endpoint and also the public cloud environment. So one of the most common authentication in Cyphalia is when a staff in a company needs to log on to a staff application, a single sign on is not used. With a single sign on each application in the staff has its own identity store and also its own login URL and also password requirement as the average user. If they have to manually maintain multiple accounts, multiple passwords, they start to be so frustrated. And what they do, they reuse the password across the websites application. And even worse, they just reuse the same password of their corporate account and just set it as the password of the staff. And this type of issue is exactly what, you know, cyber criminal they are looking, you know, to exploit. And we're using password basically, you know, cause a wider spread of vulnerability of a single iso data breach to be able to give it to the attacker to provide access to the application and even some on-premise environment. So as I mentioned, as Max mentioned, I have years of experience in cyber security and also conducting the security assessment of the SAS integration. And one of the most important rules is to avoid, you know, the corporate staff to save their work related password to the external party. In many case, we really have no control over where and how this password is sending externally as though by the vendors and who at the vendor organization has access to the password. Because there's no guarantee that all SAS vendor or any other external party have a security team that ensure the password encrypted in transit and hash properly in storage. And well, actually, in almost all the case I have seen the actual password, it def is stored in same text. So that's great. But it's also not uncommon to see people are using outdated hashing algorithm like MD5 that has to be going away for so many years and also SHA-1 to hash the password where when they store the password in the database or, you know, LDAP or whatever. And even some of them use a more secure hashing algorithm like SHA-2 not all of them use SOT. And that, you know, SOT is really a mechanism to easily resist the push-force attack. And here, for example, in my company is treated as the mandatory requirement to protect the password in storage. So now what makes it even worse is that the access to the database during the hashed password is wide open to, for example, the database administrator in the company, which means that whoever has the access to the database could use a rainbow tape to reverse the hashed password into the original password. Well, if they are smart enough to do that. And I have also seen some SAS vendor, they do encrypt the password. Sometimes we need to encrypt the password for future use instead of hashing them. So, but and they did that in the application level. That's great. But what happened is that the encryption key itself is poorly managed. The encryption key is just saved in a subfolder of the encrypted data instead of using a really tamper proof, you know, a commercial grade key vault, right? So in that case, if you have the encrypted data in this folder and the encryption key in the subfolder, I feel like it's like you have a $10 million house, but you just put your home key in the mailbox next to the door. So that that's really bad. In the news headline, we have seen data breaches in different companies. So when your corporate employee password finally, because of different kind of data breaches, end up in the dark web. So and if they also happen to reuse the, you know, the same password as that of the corporate account, then the cyber criminal can use this compromised password to attack the company account using a technique, for example, called credential stuffing, et cetera. So and therefore to avoid the risk of password leakage, OSRs application in the firm should use a single site on solution, which is linked to a centralized directory with the federation technology. And I'm going to talk, you know, about the solution in the next couple of slides. I haven't said that in the reality, not OSRs supports single site on. And now it comes to the question that will your company refuse to sign a contract with a SAS render that does not fulfill the security requirement? It depends, right? It really depends about the company cyber security culture in some company that has the weaker cyber security culture. The choice of using the vendor application is more likely to be driven by the business needs than, you know, the security compatibility. Okay, so I talk about the first challenge. I would like to talk about the second challenge. Failing to adopt a single site on solution in cloud integration caused an other pressing problem, the rapid creation of cloud identity in multiple SAS and cloud service provider platform. So in general, when an organization has got more and more cloud services, more cloud identity will need to be created and depositioned. However, interestingly, it's also not uncommon to see for many companies, the SAS account will create and manage, you know, at the department level by the administrator in a specific department instead of having an IT system, which is linked to the HR system to control all the corporate account. And not many companies, well, I mean, at least not all companies, have a centralized inventory for the SAS subscription. And therefore, they have no idea about what employee accounts were in the SAS application and failed to delete them when somebody left the firm. So a typical P4 for the poor identity lifecycle management is Schombi SAS account when an employee leaves. Most companies managed to delete the local account for the former employee. Still, many failed to ensure that the former employee SAS application account are delete. Or, you know, at least the SAS has to be revoked, right? So somebody already left the firm should not be able to log on to a SAS application and continue to see the firm information. But that's not so obviously easily to be done. And the most dangerous Schombi account, I would say, are those with high P3, which attacker can use to get SAS to some corporate secret, to get SAS to the encryption key of some very critical data, or even to turn off some critical infrastructure like, you know, firewall, something like that, or router. In short, we don't want unused unattended accounts hanging around in the environment because that gives more targets for a attacker to go after. So managing user accounts provisioning and depositioning in the cloud environment and SAS require us to use a centralized identity management system, just like the way we handle the local account. And to audit account creation, when developers deploy application on a cloud surface provider platform, it would be really smart to use a cloud native or third party tools to regularly pull the list of user and also group their role, the permission from the cloud environment, right? So there are some tools like the PowerShell in Microsoft Azure, the AWS command line interface that are a good tool that the IT administrator or security administrator can reconcile the user data to a centralized IBM system for the SAS management and governance purpose. Now talking about the solution, in the last couple of slides, I explained the problem of not using a single sign-on solution and the risk of sending credential externally. So what is exactly an IDP for the single sign-on solution? An IDP identity provider is a service that store and verifies user identity. IDP can be on-prem, can be in cloud, and they often work with the single sign-on providers to authenticate user. With an IDP, now users no longer need to specify the credential when they do the SAS blocking or cloud platform blocking. It's not only dramatically improve the overall user experience and provides secure and an interoperate service by keeping one credential that will never need to be sent to the external party. And other benefit of using a commercial identity provider IDP is to keep the company alive with the industry standard. So I observed that company that have a long history, like more than 100 years of history, for example, they have so many legacy applications, even some still running, you know, mainframe application. And some legacy application builds generations ago that handle, you know, the authentication, username, and password themselves within the application using some homegrown authentication methodology. They're really so far away from the latest industry standard. But adopting a commercial IDP will enable the company to embrace the new standard. For example, the authentication protocol like OpenID Connect or and also SAML, right? These are the latest common computer language that can enable people seamlessly integrate with different SAS and CSP. And this kind of standardization is also reducing the vulnerability in the overall IT environment. Let me use the password hashing algorithm example in the last slide, right? I just mentioned that some people, they use SHA-1 to hash the password. And SHA-1 used to be, say, long time ago until one day, somebody successfully cracked the algorithm, be able to reverse engineer to get back the pain text password. So instead of having the IT team to upgrade the cyber library from, you know, SHA-1 to SHA-2, then if that storage, whatever, is already inside the IDP, the IDP will take care of the library upgrade for their customer. And these details really help company to minimize the overall IT environment vulnerability, you know, quicker and also help them to meet the compliance and regulatory requirements smoothly. So for example, I worked in a bank and we always need to make sure we meet, well, we met actually the regulatory requirement at the time. So and sometimes proofing to them, we use a commercial grade product that already in compliance that really help our conversation. And now, so what is a good IDP solution? I'm going to talk about something like the cloud-based IDP solution in this next slide, but in general, it's really essential to choose a good IDP solution that enable the security team to standardize the single side on connection to cloud application, to SAS, also to the on-prem application in a centralized policy framework. So everything will be centralized in monitor and the policy can be enforced, you know, systematically. So now last but not least, I would like to talk about the cloud IDP and I would like to see how we can tackle this kind of cloud authentication problem more intelligently using a cloud-based IDP solution. The most companies used cloud-based IDP solution, I think now today, we have heard about Azure Active Directory and also the Google Identity as a Service. So how is a cloud-based IDP different from an on-prem IDP? Cloud IDP is a cloud federation broker as a gateway or proxy server that all federation request should go through. So it contains one or more trust points to an on-prem IDP or a trust business partner IDP. In that case, the user authenticate with the local credential and then trust each federated application, including both on-prem and cloud host application. And a good cloud-based IDP usually has the features that I really love is to enable the administrative user to create policy that continuously assess, you know, assess the risk and enforce the policy to mitigate the risk whenever they arise in an authentication session. And that's called risk-based authentication, something even smarter than just multifactile authentication. And to explain what is risk-based authentication, let me just try to tell a story, right? Imagine now, made at light, somebody just unexpectedly knocked your door. At first, you may be hesitant to open the door, who is coming to visit me, you know, made at night. But then your friend calls you from outside, you pick up the call, you recognize your friend voice, you saw her face from a picture or the WhatsApp message, then you have confidence that, okay, the person outside is your friend, so we decided to open the door and let her in. So basically, risk-based authentication solution works in much the same way. It uses real-time intelligence to get a holistic view of the context behind each login dynamically. So when it uses fTams to login with a device or from a geolocation unknown to the system, then the system will not allow the access until the user has presented additional evidence, like authentication factor to proceed. And then go back to the previous, you know, locking door story, what if someone looks and sounds really like your friend and try to break into your home? So in the computer world, fams to machine learning, the computer knows your friend better than you do. So there's something called keystroke dynamic. It's a class of behavioral biometric that's captured the typing style of a user. So typing style, such as the factor of how long usually you type your username and password, how long you depress a key and how long, you know, you take, take you to type the success key, for example. And personal keystroke are difficult to be made and therefore can be used as a form of biometric, you know, apart from your fingerprint, apart from your iris scan, whatever. And because this kind of keystroke analysis is running at the background, so therefore, unlike the traditional multi-factor authentication that the system keeps calling you for more, more factor and information, the keystroke dynamic has no impact to the user experience. And going back again to the story, what about your friend outside is compromised? So even though the person outside sounds familiar and looks familiar, your property starts to feel suspicious because your friend called you from a number in another country, right? In a risk-based authentication, the system detects the malicious IP address and also suspicious travel. For example, suppose you signed in from Montreal three hours ago to an application and since it's not possible to make the, I mean, ah, sorry, and then the server saw that there is an other login attempt from the IP address in Russia, because it's not possible to travel from Montreal to Russia in three hours, right? In that case, the risk-based IDP shall deline your assets until you provide extra factor to verify your identity. So for the risk-based IDP, because the sensor of the risk already exists in the whole identity platform, right, throughout the authentication, they can easily be added as the behavioral biometric to integrate with the policy. And a risk-based IDP can also be conflicted to analyze the risk not only at the time you're login, but also throughout the whole authentication session. For example, imagine today, you sign in, you know, to a corporate application from a laptop and then you are connecting to the Wi-Fi in the office and you decide to just pack your laptop to go to the cafe downstairs to drink the coffee and continue to work from the cafe. But because you are using the public Wi-Fi in the cafe, your security department has concerned that you use an unencrypted Wi-Fi connection to process your company data. So they could have already conveyed the policy in the cloud IDP to block your assets because the IDP detected you have an IP extra change. And even, you know, they block you, even you are already authenticated, your session is still valid and you're connected from the same device. So the configuration of the policy is quite flexible depending on the security requirement from the ID department. And this smart and dynamic risk analysis would help users and security administrators to solve the problem about the future anywhere, anytime from any device, assessing the cloud services and also the stars more intelligently. So to summarize, managing identity and assets in cloud is, it's complex, more complicated than the traditional on-prem environment, which we've already got them by exclusive firewall policy and lots of monitoring are going on. But thanks to the latest security technologies in cloud, we can solve the problem, you know, the more complex problem, more intelligently and organization particularly for those more, you know, using more than one surface provider in cloud and also multiple stars should develop a strategic roadmap by adopting an identity provider solution to enable a secure and suspendable and scalable cloud transformation journey. That's the end of my talk.