WEBVTT 00:00.000 --> 00:01.400 Thanks for joining the session today. 00:01.400 --> 00:03.840 Today we are going to talk about Zero Trust. 00:03.920 --> 00:10.240 Zero Trust has become one of the security or cybersecurity latest buzzword. 00:10.800 --> 00:15.780 So it's imperative to understand what Zero Trust is and what Zero Trust isn't. 00:15.780 --> 00:25.820 So without further delay, let me share my screen and start talking about what Zero Trust, especially in the cloud, when we are all talking about moving to the cloud. 00:26.500 --> 00:30.860 So before we deep dive into the topic, let me brief about myself. 00:30.860 --> 00:32.300 I am Vandana Verma Sehgal. 00:32.300 --> 00:39.020 My day job is with one of the multinational companies as a product security architect. 00:39.180 --> 00:42.360 And apart from that, I root for Pro Bono Work. 00:42.360 --> 00:45.060 I am one of the global board of directors for OWASP. 00:45.060 --> 00:47.840 OWASP is Open Web Application Security Project. 00:48.300 --> 00:57.300 Apart from that, I also root for Diversity Initiatives, wherein I've trained over 4,000 women around the world on cybersecurity. 00:57.540 --> 01:01.280 And I run an organization called InfoSec Girls. 01:01.280 --> 01:03.480 I'm the president for InfoSec Girls. 01:03.520 --> 01:09.080 I also work with multiple other communities to bring diversity in cybersecurity. 01:09.800 --> 01:13.160 This is what we call it as a traditional security model. 01:13.160 --> 01:21.080 We assume all the good guys, all the good people are inside the castle and all the bad people are outside. 01:21.080 --> 01:29.080 It's like a castle, wherein castle is protected by a lot of people outside and everything inside is all good. 01:29.300 --> 01:38.340 This approach lacked depth and breadth, which we needed, especially in the dynamic digital world we are in. 01:38.340 --> 01:47.160 So the castle and moth model ensures cyber defenses against external threats, but no defense against the insider threats. 01:47.240 --> 01:56.540 The castle and moth model ensures cyber defense against the external threats, but there is no defense against the insider threats. 01:56.980 --> 02:07.950 Those who have the access to the organization or internal network or have gained the privileges or internal access can actually steal the credentials. 02:09.080 --> 02:15.420 And how about if there is an admin whose credentials gets lost? 02:15.420 --> 02:17.060 What will happen? 02:17.060 --> 02:28.600 So anyone who's inside the network can move around in the internal network or in the organization network and can perform any task. 02:29.640 --> 02:42.900 This might look similar to you, especially when we all have worked on creating all these network diagrams, understanding the architecture, all the segregation between the firewalls. 02:42.900 --> 02:53.940 So under this particular trust model, it is assumed that a user's identity is never compromised and that we all are trusted or supposed to act responsibly. 02:53.940 --> 02:55.700 But can we do that? 02:55.700 --> 02:58.220 Can we trust everyone or anyone? 02:58.620 --> 03:04.060 So traditional network security model, it was all segregated by the different firewalls. 03:04.060 --> 03:10.220 There were different zones, especially contained by one or more firewalls. 03:10.220 --> 03:13.160 Every zone was like one or more firewalls. 03:13.160 --> 03:20.960 Each zone is granted some level of access, but that determines the network resources, access, or permissions. 03:20.960 --> 03:38.260 So through this model, protection is given by building multiple lines of defenses where an attacker must go past, especially before getting into the network, while possible insider threats are not taken into the consideration. 03:38.260 --> 03:40.920 So this trust model continued to be abused. 03:40.920 --> 03:52.300 The traditional castle and moth model of cybersecurity is no more the combat to modern cyber threats that we are dealing with all the APDs and whatnot we are dealing with nowadays. 03:52.980 --> 04:03.340 So the question arises, trust insiders, what about the threats which are caused by the insiders? 04:03.960 --> 04:11.880 Only one door, because we have, let's say if someone loses the credentials, anyone can come and access it. 04:11.880 --> 04:13.120 Is it practical? 04:13.120 --> 04:14.800 I don't think so. 04:15.200 --> 04:21.950 We should protect everything from outsider, but how about the cost of protecting non-critical information? 04:22.560 --> 04:24.660 It's a huge amount of money. 04:25.060 --> 04:28.640 So the current landscape has also changed. 04:28.860 --> 04:34.560 In the old model, network packet firewalls were there to protect and tightly control the network. 04:34.680 --> 04:40.740 All traffic could be traced back and can be marked as insider or outside traffic. 04:41.060 --> 04:48.640 But this has changed over the years, and especially when the workforce has changed, move outside. 04:48.660 --> 04:51.080 Right now, we are all working from home. 04:51.080 --> 04:53.700 It's been so many months we're all working from home. 04:53.740 --> 04:56.900 And we're all connecting to the network from outside. 04:56.900 --> 05:02.820 We're all dependent on some other technology which can connect us to the office network. 05:03.240 --> 05:10.480 So especially when we talk about business trips, we are all remote, like we are right now. 05:10.560 --> 05:14.840 So how can actually internal network can be protected? 05:14.840 --> 05:17.460 Or how can organization be protected? 05:17.520 --> 05:22.700 And especially when we say, as today's network is different. 05:22.820 --> 05:31.840 Privileged access not only covers the infrastructure, databases, and network devices, but is extended to cloud environments as well. 05:31.840 --> 05:41.360 We're all talking about hybrid environments, multi-cloud environments, some sort of managing SaaS environments. 05:41.360 --> 05:44.540 So how should we handle all of those things? 05:45.000 --> 05:48.300 It also includes big data projects. 05:48.300 --> 05:51.300 It must be automated for DevOps. 05:51.320 --> 05:59.320 And it now needs to cover hundreds of containers or microservices to represent what used to be a single server. 05:59.340 --> 06:02.800 So you can see that everything has modified. 06:02.800 --> 06:04.700 Everything has changed. 06:05.160 --> 06:21.640 And as I said, on top of this, we now live in a world of advanced persistent threats or APDs that create a growing and changing risk to the organizations, financial assets, intellectual property, and reputation, the most of all. 06:21.760 --> 06:28.660 Expanding access and obtaining credentials, it's an essential part of most APDs. 06:28.660 --> 06:39.580 Talk about 80% of the thefts happen or data breach happens because of privileged access abuse or credentials abuse. 06:40.340 --> 06:46.940 So access has become a kind of a crown jewel for any organization over the years. 06:46.940 --> 06:49.880 Let's talk about some breach statistics. 06:50.100 --> 07:03.840 And when we are spending so much money on the security products each year or creating or setting up the security team in our organization, but we're still actually less secure. 07:04.220 --> 07:10.840 Zero Trust provides a better framework to look at the cybersecurity and rethink the way we are doing security. 07:11.440 --> 07:30.100 As for cybersecurity, the cybersecurity cost, which was $3 trillion that was in 2015, will now be $6 trillion in 2021 or 2021 or maybe more. 07:30.800 --> 07:36.200 Average cost of a data breach would be $3.62 million. 07:36.760 --> 07:38.680 That's a huge number. 07:38.680 --> 07:41.580 And that's quoted by Ponemon Research Institute. 07:42.080 --> 07:45.640 And there's a new research that has come up recently. 07:46.140 --> 07:56.280 Now, as I said, there's another research by Forrester, which estimates that 80% of the data breaches which happen because of privileged access abuse. 07:56.520 --> 07:57.660 That's a good number. 07:57.660 --> 07:59.700 That's a huge, huge number. 07:59.940 --> 08:06.380 So these figures come despite of organizations spending a lot on the cybersecurity. 08:07.280 --> 08:14.080 And there are more and more efforts that are going in the cybersecurity or securing the organization. 08:14.080 --> 08:26.300 But the worrisome picture comes is when we talk about that there is an organization which has breached once, but then that happens not just once, but multiple times. 08:26.680 --> 08:31.280 We are spending more money, but we are becoming less secure. 08:31.280 --> 08:32.720 How come that's happening? 08:32.720 --> 08:36.560 We're spending money on tools, people and whatnot. 08:37.260 --> 08:42.020 But the point comes is, are we spending the money on the right things? 08:42.020 --> 08:44.040 Or the right kind of a framework? 08:44.880 --> 08:49.960 Because I wouldn't say that what we were doing earlier was wrong or right. 08:49.960 --> 08:57.660 But I will say I'm just my point is that every year, there's something new that is coming up. 08:57.720 --> 09:03.680 Not just every year, every month, every day is something new that is coming up. 09:03.680 --> 09:05.380 We have to tackle that. 09:05.400 --> 09:08.420 And we have to make sure our organization is secure. 09:08.420 --> 09:14.160 No organization is ever 100% secure, but we can take baby steps towards it. 09:14.780 --> 09:17.220 So I have some questions for you. 09:17.260 --> 09:22.920 When we talk about client, do we say that client is secure? 09:22.920 --> 09:25.760 The people, the users are secure? 09:26.840 --> 09:28.740 No, they're not. 09:28.740 --> 09:30.020 We've seen that. 09:30.360 --> 09:31.900 How about a server? 09:31.900 --> 09:34.440 Can we say that the server is secure? 09:35.300 --> 09:36.220 No. 09:36.680 --> 09:39.000 How about the whole network? 09:39.000 --> 09:40.940 Can we just depend on that? 09:41.740 --> 09:43.240 What do you say? 09:43.240 --> 09:45.400 We're all working remote. 09:45.400 --> 09:49.640 So are we dependent on network and can we just trust it? 09:49.640 --> 09:50.580 No. 09:50.580 --> 09:56.780 So if we don't do that, so simply don't trust and what shall we do? 09:56.780 --> 10:01.880 So if we have to trust, what should we verify? 10:01.880 --> 10:04.920 It's like trust but verify. 10:05.340 --> 10:08.250 But is it safe to say that trust but verify? 10:09.460 --> 10:18.760 So here, if zero trust sounds similar to you or familiar to you, it's because zero trust has been around for a while. 10:18.880 --> 10:23.520 But it's really hitting the nail right now, or hitting the rhythm right now. 10:23.520 --> 10:28.940 The old model was, oh, you are in the network, we're going to trust you. 10:29.000 --> 10:33.860 The new model says, never trust and always verify. 10:34.280 --> 10:43.260 So this actually flips the mantra from trust but verify to never trust and always verify. 10:43.960 --> 10:49.880 It says, trust no one, not even the users behind the firewall. 10:50.140 --> 10:56.580 While we are talking about zero trust, let's learn about how it all came into picture. 10:56.780 --> 11:01.460 So over the years, security models have matured or have transitioned. 11:01.760 --> 11:05.420 Many of us have first seen access control list. 11:05.520 --> 11:10.260 Then came role-based access control, which still exists in some form. 11:10.580 --> 11:16.180 And then came principles of least privilege, and especially it was at all rates. 11:16.960 --> 11:36.600 But the problem with R-backwards or role-based access control, and even subsequently with least privilege as well, was actually, it just allowed all the subjects to be assigned multiple roles and multiple commissions, which eventually loosened to a point wherein it defeated the purpose it was meant for, 11:36.600 --> 11:40.600 or intended the control it was meant for. 11:41.220 --> 11:53.960 And when we talk about introduction to cloud and diverse SaaS offerings, especially for our core applications, how are we going to implement and manage this effectively? 11:54.320 --> 12:01.820 If as an admin, I lead the organization today, how soon are we removing the accesses? 12:01.820 --> 12:07.660 Or let's say if I move from one team to another, how soon are we managing those accesses? 12:07.820 --> 12:09.500 It's really, really hard. 12:09.800 --> 12:13.260 So those things are really important to be managed. 12:13.640 --> 12:17.980 And security parameter has become a thing of the past, whatever we say. 12:17.980 --> 12:25.800 Especially with the cloud adoption and advancement in technologies, enterprise must assume that the environment is hostile. 12:26.320 --> 12:33.520 And that's how when we go to the public cloud, we have something in mind that we are putting our data into the public cloud. 12:33.700 --> 12:35.840 And we have to take some ownership. 12:35.840 --> 12:44.300 We have to talk about the shared responsibility model, that what's the cloud provider's responsibility, what's our responsibility. 12:44.360 --> 12:47.860 And that's the core tenet of Zero Trust. 12:48.040 --> 12:56.620 And it provides a better framework to look at cybersecurity and rethink the way we are working towards cybersecurity. 12:56.720 --> 13:07.340 It's essentially established a model of trust, verification, and continuous evaluation of trust for further access and later moment. 13:08.260 --> 13:13.960 Now, when we say Zero Trust, how's the architecture? 13:14.000 --> 13:22.620 If you can see in the picture, the whole system or the supporting system in the whole architecture is called a control plane. 13:22.620 --> 13:29.760 And every component is referred to as a data plane, which is being coordinated and configured by the control plane. 13:29.760 --> 13:34.160 In Zero Trust, we first identify a protect surface. 13:34.160 --> 13:35.940 Now , what is a protect surface? 13:36.660 --> 13:47.020 It's made up of the organization's or network's most critical and valuable data, assets, applications, services. 13:47.880 --> 13:55.760 So once we identify, now why we need to identify because it's unique to every organization. 13:55.760 --> 13:59.660 No two organizations can have the same crown jewels. 13:59.660 --> 14:04.860 So we need to first identify those unique critical infrastructure. 14:04.860 --> 14:22.360 When we have identified that, we can identify how the traffic moves around the organization, understanding who the users are, which applications they're trying to access, and how they are connecting to the network, and enforcing the policies based on that. 14:23.320 --> 14:44.860 Once we have the basic understanding of interdependencies between data, application, users, services, we can put controls, especially when we say that these protect surfaces need the control as soon as possible, creating a micro perimeter around it. 14:44.860 --> 14:59.780 And we can create a micro perimeter by deploying a segmentation gateway, more commonly known as a next generation firewall, especially to ensure only known allowed traffic or legitimate applications have access to the product surface. 15:00.160 --> 15:11.720 The segmentation gateway can actually provide us granular visibility into the traffic, and enforce additional layer of security, especially layer 7 security that we've been talking about. 15:12.300 --> 15:20.780 And people always talk about network segmentation, but application segmentation is also equally important. 15:20.780 --> 15:27.640 So we need to have application segmentation, application gateway segmentation, or network segmentation in place. 15:27.640 --> 15:31.100 We continue to monitor and maintain in real time. 15:31.740 --> 15:35.160 Still, we are actually lacking a lot of things. 15:35.780 --> 15:40.380 First, we identify one perimeter, secure that. 15:40.480 --> 15:41.600 Move ahead. 15:41.600 --> 15:43.940 We need to go phase by phase. 15:44.340 --> 15:47.580 We cannot say that we are going to do everything at once. 15:47.760 --> 15:51.860 That's not quite humanly possible, or even with machines possible. 15:51.860 --> 15:53.660 Everything takes time. 15:53.660 --> 15:55.720 We need to understand the environment. 15:55.720 --> 15:58.780 We need to start understanding what's happening in the organization. 15:58.780 --> 16:00.080 What assets do we have? 16:00.080 --> 16:01.880 What network do we have? 16:02.200 --> 16:11.920 So at the same time, implementing zero trust in an enterprise network is predicted on the organization's network itself. 16:12.000 --> 16:32.300 It establishes where boundaries can be placed, and enforcing access controls to shield the specific applications, sensitive applications, such as which are on-premise applications, data centers, safeguarding it from unauthorized access, and lateral movements that I mentioned. 16:32.320 --> 16:44.020 Most companies have applications and data spread across the multiple locations, and don't have insight on who's accessing their application, how data is being stored. 16:44.240 --> 16:53.720 So to address all these things, companies have often accessed multiple resources, use multiple technologies around. 16:53.980 --> 17:06.520 And when cloud came into picture, everybody needed, like, we need information stored secretly, safeguardly, on the on-premise servers. 17:06.520 --> 17:13.640 And when we are moving to the cloud, a public cloud, private cloud, SaaS applications, we have started using. 17:13.640 --> 17:16.420 So how shall we leverage all those things? 17:16.420 --> 17:18.480 We started talking about CASB. 17:18.640 --> 17:25.740 We started talking about inbound proxy, virtualized firewall, software-defined perimeter. 17:25.920 --> 17:42.860 So this is a mix of technology, which actually creates a segmented security architecture, where we can actually, which might be difficult to be sure what policies are in place, or how data can be secured. 17:43.380 --> 17:49.140 So to succeed, we all need to have a single unified security architecture. 17:49.140 --> 17:54.260 This is our network, where the users are accessing these applications. 17:54.600 --> 17:58.060 This is how data is flowing across the public cloud. 17:58.240 --> 18:01.880 These are my SaaS applications, and this is how they are interacting. 18:02.540 --> 18:06.080 This is my private cloud, and this is my data center. 18:06.500 --> 18:15.280 There are controls and limits who has access to what information, what assets, how they can use it. 18:15.280 --> 18:28.840 If we are dealing with any third-party vendor, how much access they will have, whether they will have read-only access, they'll have write access, inspect the traffic, and enforce security policies. 18:30.120 --> 18:34.040 The first thing, we should categorize the data. 18:34.320 --> 18:39.360 Ultimately, security teams are focused on protecting the data, whatever we say. 18:39.500 --> 18:49.020 Where possible, data should be safe, even when it leaves the organization, leave the device, app, infrastructure, network. 18:49.480 --> 19:01.380 The controls that we have in place, data should be classified, labeled, encrypted, and access restrict based on all of these things. 19:01.700 --> 19:04.960 So, what should we do in that case? 19:04.960 --> 19:07.600 We should first understand the current setup. 19:08.180 --> 19:17.140 Take a detailed look at what current data we have, what locations we have, do we have any regulations in place? 19:17.300 --> 19:28.380 And data classification also is important because it allows organizations to manage the data more effectively and accurately. 19:28.620 --> 19:34.880 The organizations might be facing issues, okay, my assets are lying all over there. 19:34.880 --> 19:40.780 But if you think about, there's a crown jewel, and we have not marked it as a crown jewel. 19:40.780 --> 19:48.820 There's a low-hanging fruit, and we don't know whether it's or that might be a critical device for some of the teams. 19:49.280 --> 19:59.100 So, it's very important to label it, whether it's restricted, internal, external, confidential, private, or what kind of data it is. 19:59.840 --> 20:01.900 Principles of least privilege. 20:02.240 --> 20:09.780 And you must be hearing it from like, ages back, okay, we should have principles of least privilege. 20:09.780 --> 20:11.740 Did we implement it? 20:11.740 --> 20:17.180 Least privilege access rights is a fundamental principle of zero-trust security. 20:17.300 --> 20:24.580 Overly excessive access is one of the key issues causing the insider threat to become insider incidents. 20:24.580 --> 20:29.620 Zero-trust networks only allow access rights as and when necessary. 20:30.200 --> 20:34.200 Covering the access is no longer appropriate. 20:34.320 --> 20:39.300 So, authenticating and verifying on all access is important. 20:39.300 --> 20:43.300 User access to cloud resources must be first authenticated. 20:44.420 --> 20:48.060 Certificate-only based authentication is a weak solution. 20:48.260 --> 20:50.320 As a certificate can be stolen. 20:50.320 --> 20:53.500 If I have your certificate, I can log into the environment. 20:53.560 --> 21:01.300 Another insecure approach would be insecure access method to jump host or bastion host. 21:01.680 --> 21:11.340 So, what we can do is we can have multi-factor authentication which can be integrated with LDAP or any other solution which can be there. 21:11.340 --> 21:16.240 And we can have single sign-on which can improve the authentication strength. 21:16.540 --> 21:23.340 However, authentication itself or alone is not sufficient. 21:23.420 --> 21:31.860 Users accessing the cloud resources must be authorized once we have authenticated. 21:31.860 --> 21:34.980 So, the fine-grained control can be applied. 21:34.980 --> 21:46.500 And less lateral movements of a user can make it even if someone try and access the network, we have fine-grained access, the access can be stopped then and there. 21:47.620 --> 21:50.520 User account with least privileges. 21:51.120 --> 21:54.960 Especially if an employee leaves an organization. 21:55.900 --> 21:58.120 How about removing their access? 21:58.120 --> 22:02.400 It becomes very important to remove their access. 22:02.540 --> 22:13.300 With the principles of least privilege, an employee whose job is to enter the data center, the person can actually add or modify the records. 22:13.300 --> 22:18.940 If the person's laptop is infected with a malware, what could go wrong? 22:18.960 --> 22:25.560 The system can actually install a malware on other systems, infect the database. 22:25.940 --> 22:33.620 If the person has root credentials, the infection can actually spread the system-wise and spread in the network. 22:33.740 --> 22:38.620 I'll give you an example which happened with me, wherein a person was working with me. 22:38.620 --> 22:42.120 The person was a network person who was handling the firewalls. 22:42.120 --> 22:45.460 His job was to monitor and work on the firewall rules. 22:46.120 --> 22:51.320 So, the person can monitor and make changes to the firewall or ACS. 22:51.320 --> 22:54.180 But suddenly, the person moves to security team. 22:55.000 --> 23:03.740 Now, the person's job is to manage the firewall logs, which is like a quite different thing. 23:04.660 --> 23:13.900 Now, the person who's managing the firewall logs suddenly gets a request, that can you please modify this access for me in the firewall? 23:13.980 --> 23:15.720 And the person does it. 23:16.660 --> 23:21.580 Practically, the person should have access to the network or network firewall? 23:21.660 --> 23:26.480 No, the person should not be even having access to it. 23:26.740 --> 23:29.000 Lead the modifying part. 23:29.520 --> 23:35.940 So, it becomes important to have all those rights checked at the regular intervals. 23:35.940 --> 23:38.160 We can have just-in-time privilege. 23:38.160 --> 23:46.160 If a user who really needs access to the root credentials, reducing privileges, especially when they don't need it. 23:47.000 --> 23:49.680 We can use disposable credentials. 23:49.860 --> 23:52.100 We can enable a function. 23:52.100 --> 23:56.800 Okay, these are the six hours or six days a person needs access to this environment. 23:56.800 --> 24:00.220 And after six days, let's remove the access. 24:00.980 --> 24:03.000 So, all of these things can be done. 24:03.000 --> 24:10.780 And we can actually stop the lateral movement of all those attacks that are happening, might be spreading across the network. 24:11.500 --> 24:18.560 And this is one of the things that the primary thing that a pen tester can leverage. 24:18.560 --> 24:23.000 If all those privileges and rights are not there, that can be exploited. 24:24.000 --> 24:29.660 And as a security researcher, if these things are not there, I am going to target that. 24:30.020 --> 24:45.240 If we zone off what the team or what the malicious actors might get access to, we can stop the attack because they will be only able to infect a certain zone, not the whole area. 24:46.320 --> 24:56.380 So, if the public cloud we are using, we have to have principles of least privilege. 24:56.380 --> 25:05.900 We have to have a principle to build the cloud network, which can result in an isolated island of a lot of different networks. 25:06.520 --> 25:21.560 If one network is breached, we have other networks which can be safeguarded, because it's impossible to gain access to those networks, which can actually reduce the attack surface. 25:22.040 --> 25:28.100 Now, tell me one thing, how many of you have multiple accounts, multiple passwords? 25:28.100 --> 25:28.940 I have. 25:28.940 --> 25:35.280 I have like tons and tons of username passwords, tons and tons of accounts on multiple websites. 25:35.720 --> 25:38.040 So, what could go wrong? 25:39.220 --> 25:42.700 Earlier, the identities were not defined. 25:42.700 --> 25:44.640 There were all internal applications. 25:44.640 --> 25:46.200 There were many passwords. 25:46.640 --> 25:51.800 Then, in mid-90s, identities, we started defining. 25:51.940 --> 25:57.060 We started uniquely identifying who has access to what. 25:57.060 --> 26:03.400 We started talking about single sign-on, password policies, role-based access controls. 26:03.400 --> 26:12.680 Then came an era where we started talking about how about having a multi-factor authentication, because we saw so many breaches. 26:12.700 --> 26:17.160 With banks, with financial institutions and whatnot, healthcare industry. 26:18.440 --> 26:24.240 We made sure that we have to have something in place which can reduce the privileges. 26:24.260 --> 26:27.560 So, we came up with principles of least privilege. 26:27.720 --> 26:30.520 Then came a point that that's not necessary. 26:30.520 --> 26:35.020 How about understanding what could be the risk score? 26:35.480 --> 26:38.740 How are we handling the risk of an application? 26:38.740 --> 26:42.060 How are we handling the risk scores? 26:42.060 --> 26:49.960 Adaptive access, context-aware access, authorization, application-only access. 26:50.220 --> 26:54.100 And now, we're talking about, let's go password-less. 26:54.400 --> 26:59.260 We're talking about QR code scans and whatnot, FIDO2. 26:59.260 --> 27:08.480 So, all of those things are actually contributed towards maturing the organization IAM strategy. 27:08.920 --> 27:11.940 Now, what is context-aware security? 27:11.940 --> 27:14.220 And why are we even talking about it? 27:14.220 --> 27:20.160 So, if we look at 10 years back, MFO was just a pain. 27:20.220 --> 27:25.660 People would cringe and say that, I don't want to use multi-factor authentication. 27:25.840 --> 27:28.320 We will all stick to the old world. 27:28.460 --> 27:35.920 Today, with all the modern solutions that we have, especially with cloud, can we just have a username and password? 27:35.920 --> 27:42.400 I have, on one of the projects, wherein the organization was using six-digit characters. 27:42.920 --> 27:45.480 Should we use that small character password? 27:45.480 --> 27:46.220 No. 27:46.280 --> 27:52.380 When you talk about moving to cloud, we have to be sure that we are using a strong password. 27:52.460 --> 27:54.900 We have to have a strong password policy. 27:54.920 --> 28:07.740 We have to have multi-factor authentication to verify during login or password checkout, especially at the time of privilege elevation. 28:08.960 --> 28:12.140 Multi-factor authentication is a must-have. 28:12.140 --> 28:15.180 We cannot counter that with anything. 28:15.300 --> 28:17.200 Passwords are not good enough. 28:17.200 --> 28:19.900 Let's face it, whatever we say. 28:20.240 --> 28:29.540 And even if we talk about the listening to this talk, we can say that half of our passwords are the dictionary passwords. 28:29.540 --> 28:37.580 The passwords of somebody who we know, on months, with ad123, ad06, or whatever. 28:38.200 --> 28:40.180 All of that is there. 28:40.480 --> 28:44.980 So the good news is, multi-factor authentication is an easy way. 28:45.020 --> 28:48.140 We have, as I said, FIDO2. 28:48.160 --> 28:51.220 We have Google Authenticator. 28:51.220 --> 28:57.860 And many authenticators are available, which can actually help us in securing our applications, securing our data. 28:59.640 --> 29:05.980 With context-aware access, we can figure out where we are trying to access, which device we are using. 29:06.380 --> 29:12.420 If we're using a device for so long, there is a context that has been built for the device. 29:12.420 --> 29:14.300 And suddenly we change the device. 29:14.480 --> 29:24.740 The application should ask us for blocking or for asking for a step of authentication and saying that, okay, let's re-authenticate you. 29:25.980 --> 29:35.520 If I am in India right now, if I'm in Bangalore, suddenly I log in from US, UK, or any other location. 29:35.520 --> 29:37.100 Am I supposed to log in? 29:37.100 --> 29:38.880 No, I'm not. 29:38.880 --> 29:40.800 Practically, it's not possible. 29:40.800 --> 29:42.360 So what shall we do? 29:43.000 --> 29:44.780 Block the access. 29:45.600 --> 29:48.820 And adaptive access can be on applications and services. 29:48.900 --> 30:06.900 At the same time, when we have adaptive access, how about monitoring that, which means enabling the right users or right user to have the right access to the right data for the right reason from the right location. 30:07.060 --> 30:23.540 So what I said, enabling the right users to have the right access to the right data for the right reason for the right location, which includes device, network, workload, and application, all at the same time. 30:23.640 --> 30:35.300 Now, when we say monitoring and logging, we can build identity-based network context, like creating micro-parameters that are based on identifying the users. 30:35.360 --> 30:43.840 This is also known as zoning, where we can automatically continuously monitor and manage the data between the zones. 30:44.620 --> 30:51.200 Authentication and authorization can actually give us a good view of both these zones. 30:51.980 --> 31:04.040 Besides users and accounts, every device owned by the organization should be uniquely identifiable in a single device directory, wherein we can say, okay, these are the devices which are in use. 31:04.040 --> 31:07.540 If there is a phishy device, let's remove it from the network. 31:08.400 --> 31:13.380 And whosoever is trying to access it from a malicious device, let's block their access. 31:13.680 --> 31:16.760 And let's face it that hacking is inevitable. 31:16.840 --> 31:18.400 Attack will happen. 31:18.720 --> 31:21.100 The systems will get compromised. 31:21.940 --> 31:25.680 But we should have an idea what's our blast radius. 31:25.920 --> 31:27.840 What's our network? 31:28.560 --> 31:35.200 Then, if we find that there's something malicious going on, we can stop it or prevent it to happen. 31:35.200 --> 31:37.420 Are the alerts being managed? 31:37.460 --> 31:41.640 How much automation we have in place to detect the incidents? 31:41.640 --> 31:47.560 We're talking about orchestration, creating the playbooks relevant to our organization. 31:47.560 --> 31:54.060 So it becomes important to monitor and lock all the data which is going on in the network. 31:54.780 --> 32:03.040 Then comes, how about we architect our own zero trust architecture, micro parameters. 32:03.040 --> 32:11.840 Once we know our data, our flow, what's happening in the network, we can create the optimal micro networks around each of them. 32:11.880 --> 32:20.560 Separate production data from dev and test can really, really help us in segmenting the whole network. 32:20.860 --> 32:27.940 We can have separate cloud accounts, which can be a best practice for having isolation. 32:29.060 --> 32:31.220 What can we do? 32:31.220 --> 32:37.880 We can define the micro parameter zones and segmentation, especially around sensitive data. 32:37.880 --> 32:42.780 We can enforce segmentation using physical and virtual security controls. 32:42.780 --> 32:47.800 Establish access based on these controls and micro parameter designs. 32:47.800 --> 32:52.440 We can encrypt all the network traffic regardless of origin. 32:52.560 --> 32:56.640 But it has to be checked what is relevant. 32:56.640 --> 33:00.360 Now, another important aspect is policies and procedures. 33:00.680 --> 33:07.880 Identity governance and policies are very important, but must be comprehended across the applications. 33:07.880 --> 33:14.340 We also have to take into the account the legacy applications or legacy applications that we have. 33:14.340 --> 33:16.100 Do we have support from them? 33:16.100 --> 33:22.900 How are we going to handle them when we talk about cloud or the advanced or latest technologies that we have? 33:22.900 --> 33:44.260 Legacy apps can be run in virtualized environments or containers or can be segmented from the rest of the network so that if something happens, if they are compromised, the malicious users cannot pivot and move laterally to compromise the rest of the systems or infrastructure. 33:44.540 --> 33:59.880 So what we can do as part of implementing, starting with categorizing data with least privilege, network management, segmentation, policies and procedures, all of this that's there. 33:59.880 --> 34:02.920 But how should we take a step forward? 34:03.680 --> 34:11.940 Especially when we have remote access, we have a BYOD, we have default deny or so many other policies. 34:11.940 --> 34:14.380 How are we going to handle that? 34:14.560 --> 34:19.460 We can implement it wherein we identify what type of applications are there. 34:19.480 --> 34:21.880 And that's the fundamental step. 34:21.880 --> 34:28.580 If we know our infrastructure, we have categorized it, we know what's public, what's internal, what's confidential. 34:29.480 --> 34:35.380 We can define the zones, we can have micro-parameters come in and help us. 34:35.960 --> 34:42.780 We can suggest that, okay, let's create a chunk of data that represents that own micro-parameter. 34:42.900 --> 34:46.700 Then we can map the flows of the sensitive data. 34:47.440 --> 35:00.980 We can have, okay, this is the segment which can be multi-directional, which can be bidirectional, or it should be accessible to the rest of the world, which can actually optimize our data flows. 35:01.400 --> 35:04.600 Then how about creating the boundaries? 35:05.200 --> 35:11.960 Once we all know this all micro-network, we can design them. 35:11.960 --> 35:16.020 We can say, okay, this is what fits for the security. 35:16.680 --> 35:24.980 And this also take into consideration that, okay, we have a nice posture in our organization. 35:24.980 --> 35:27.960 We have a mature posture in our organization. 35:27.960 --> 35:33.060 We can continuously monitor and log the traffic. 35:33.520 --> 35:44.440 It can actually provide us the data analytics for malicious activities across the entire micro-parameter ecosystem. 35:44.460 --> 35:50.400 We can embrace automation, which might not be really possible because we don't know our network. 35:50.600 --> 35:55.400 So we can have a lot of automation orchestration policies, procedures in place. 35:56.840 --> 36:01.640 So as I said, should we trust or don't trust? 36:02.080 --> 36:05.080 Zero trust is more of a perspective than a product. 36:05.080 --> 36:09.760 Someone says it's a product, sorry, that's not the case. 36:09.860 --> 36:12.340 And technology moves very fast. 36:12.420 --> 36:17.580 We can never think that we've just gotten to where we know everything about our organization. 36:18.140 --> 36:21.920 There has to be something which might be failing. 36:22.080 --> 36:27.700 So no single technology which is associated with zero trust architecture. 36:28.140 --> 36:32.920 There are multiple technologies, multiple processes which are there. 36:32.920 --> 36:36.260 It also defines the maturity of our organization. 36:37.520 --> 36:44.000 It's a holistic approach to cybersecurity, which contains multiple principles and technologies. 36:44.840 --> 36:53.240 So can we say that identity is a security perimeter or a new security perimeter? 36:53.980 --> 36:56.240 Can we see that now? 36:56.400 --> 37:01.180 So there are things that we've been doing. 37:01.180 --> 37:02.860 There are things that we can do. 37:02.920 --> 37:05.040 But we can take the baby steps. 37:05.040 --> 37:08.300 We can take the steps towards the zero trust journey. 37:09.360 --> 37:15.240 And the first step comes in when we start thinking about it, that what are things we can do? 37:15.400 --> 37:18.900 We can talk about verifying the users. 37:18.900 --> 37:22.100 We can have single sign-on, multi-factor authentication everywhere. 37:22.100 --> 37:23.940 We can have user behavior analysis. 37:23.940 --> 37:26.160 We can have risk scoring for accesses. 37:26.160 --> 37:28.260 We can validate the devices. 37:28.260 --> 37:32.160 It could be device and app management, device context. 37:32.220 --> 37:35.980 We can have endpoint privilege management properly. 37:35.980 --> 37:41.220 Then principles of least privilege, which we can never remove. 37:41.220 --> 37:47.980 We can have granular role-based access, which can actually limit literal moments. 37:48.340 --> 37:57.780 Then how about learning from the architecture that we have and adapting to the new architecture using machine learning, AI. 37:59.180 --> 38:08.380 These are some of the references that I have looked through and researched of some amazing corporations. 38:09.020 --> 38:12.200 You can reach me on Twitter, LinkedIn. 38:12.200 --> 38:13.420 That's my email address. 38:13.420 --> 38:18.140 I'm very much reachable on all the platforms if you have feedback, if you want to have a discussion. 38:18.640 --> 38:21.180 And then we're all good. 38:22.180 --> 38:23.680 Thank you so much. 38:23.680 --> 38:26.140 This is Namaste from India. 38:26.140 --> 38:26.820 Thank you.