[00:00.000 --> 00:04.240]  Thanks for joining the session today. Today we are going to talk about Zero Trust. Zero
[00:04.240 --> 00:12.160]  Trust has become one of the security or cybersecurity latest buzzword. So it's imperative to understand
[00:12.160 --> 00:18.160]  what Zero Trust is and what Zero Trust isn't. So without further delay, let me share my
[00:18.160 --> 00:23.700]  screen and start talking about what Zero Trust, especially in the cloud, when we are all talking
[00:23.700 --> 00:29.280]  about moving to the cloud. So before we deep dive into the topic, let
[00:29.280 --> 00:34.700]  me brief about myself. I am Vandana Verma Sehgal. My day job is with one of the multinational
[00:34.700 --> 00:42.360]  companies as a product security architect. And apart from that, I root for Pro Bono Work.
[00:42.360 --> 00:46.820]  I am one of the global board of directors for OWASP. OWASP is Open Web Application Security
[00:46.820 --> 00:52.780]  Project. Apart from that, I also root for Diversity Initiatives, wherein I've trained
[00:52.780 --> 01:01.280]  over 4,000 women around the world on cybersecurity. And I run an organization called InfoSec Girls.
[01:01.280 --> 01:06.220]  I'm the president for InfoSec Girls. I also work with multiple other communities to bring
[01:07.040 --> 01:13.160]  diversity in cybersecurity. This is what we call it as a traditional security model.
[01:13.160 --> 01:19.960]  We assume all the good guys, all the good people are inside the castle and all the bad people are
[01:19.960 --> 01:26.920]  outside. It's like a castle, wherein castle is protected by a lot of people outside and everything
[01:26.920 --> 01:35.260]  inside is all good. This approach lacked depth and breadth, which we needed, especially in the
[01:35.260 --> 01:42.820]  dynamic digital world we are in. So the castle and moth model ensures cyber defenses against
[01:42.820 --> 01:48.780]  external threats, but no defense against the insider threats. The castle and moth model
[01:48.780 --> 01:54.500]  ensures cyber defense against the external threats, but there is no defense against
[01:54.500 --> 02:02.680]  the insider threats. Those who have the access to the organization or internal network or have
[02:02.680 --> 02:07.950]  gained the privileges or internal access can actually steal the credentials.
[02:09.080 --> 02:17.060]  And how about if there is an admin whose credentials gets lost? What will happen?
[02:17.060 --> 02:22.420]  So anyone who's inside the network can move around in the internal network
[02:22.420 --> 02:28.600]  or in the organization network and can perform any task.
[02:29.640 --> 02:36.280]  This might look similar to you, especially when we all have worked on creating all these
[02:36.280 --> 02:42.900]  network diagrams, understanding the architecture, all the segregation between the firewalls.
[02:42.900 --> 02:48.720]  So under this particular trust model, it is assumed that a user's identity is never compromised
[02:49.590 --> 02:56.380]  and that we all are trusted or supposed to act responsibly. But can we do that? Can we trust
[02:56.380 --> 03:02.800]  everyone or anyone? So traditional network security model, it was all segregated by the
[03:02.800 --> 03:10.220]  different firewalls. There were different zones, especially contained by one or more firewalls.
[03:10.220 --> 03:17.100]  Every zone was like one or more firewalls. Each zone is granted some level of access,
[03:17.100 --> 03:22.320]  but that determines the network resources, access, or permissions. So through this model,
[03:22.320 --> 03:28.860]  protection is given by building multiple lines of defenses where an attacker must go past,
[03:28.860 --> 03:35.540]  especially before getting into the network, while possible insider threats are not taken
[03:35.540 --> 03:41.940]  into the consideration. So this trust model continued to be abused. The traditional castle
[03:41.940 --> 03:48.460]  and moth model of cybersecurity is no more the combat to modern cyber threats that we are dealing
[03:48.460 --> 03:56.840]  with all the APDs and whatnot we are dealing with nowadays. So the question arises, trust insiders,
[03:57.080 --> 04:03.340]  what about the threats which are caused by the insiders?
[04:03.960 --> 04:08.890]  Only one door, because we have, let's say if someone loses the credentials,
[04:09.680 --> 04:16.980]  anyone can come and access it. Is it practical? I don't think so. We should protect everything
[04:16.980 --> 04:21.950]  from outsider, but how about the cost of protecting non-critical information?
[04:22.560 --> 04:30.200]  It's a huge amount of money. So the current landscape has also changed. In the old model,
[04:30.200 --> 04:34.560]  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:46.760]  But this has changed over the years, and especially when the workforce has changed,
[04:46.760 --> 04:52.380]  move outside. Right now, we are all working from home. It's been so many months we're all
[04:52.380 --> 04:57.540]  working from home. And we're all connecting to the network from outside. We're all dependent
[04:57.540 --> 05:05.140]  on some other technology which can connect us to the office network. So especially when we talk
[05:05.140 --> 05:13.920]  about business trips, we are all remote, like we are right now. So how can actually internal network
[05:13.920 --> 05:19.280]  can be protected? Or how can organization be protected? And especially when we say,
[05:19.280 --> 05:26.300]  as today's network is different. Privileged access not only covers the infrastructure,
[05:26.300 --> 05:32.820]  databases, and network devices, but is extended to cloud environments as well. We're all talking
[05:32.820 --> 05:41.680]  about hybrid environments, multi-cloud environments, some sort of managing SaaS environments. So how
[05:41.680 --> 05:49.800]  should we handle all of those things? It also includes big data projects. It must be automated
[05:49.800 --> 05:56.400]  for DevOps. And it now needs to cover hundreds of containers or microservices to represent
[05:56.400 --> 06:03.660]  what used to be a single server. So you can see that everything has modified. Everything has
[06:03.660 --> 06:10.300]  changed. And as I said, on top of this, we now live in a world of advanced persistent threats
[06:10.300 --> 06:16.860]  or APDs that create a growing and changing risk to the organizations, financial assets,
[06:16.860 --> 06:25.220]  intellectual property, and reputation, the most of all. Expanding access and obtaining credentials,
[06:25.220 --> 06:33.900]  it's an essential part of most APDs. Talk about 80% of the thefts happen or data breach happens
[06:33.900 --> 06:44.000]  because of privileged access abuse or credentials abuse. So access has become a kind of a crown
[06:44.000 --> 06:50.940]  jewel for any organization over the years. Let's talk about some breach statistics. And when we are
[06:50.940 --> 06:58.100]  spending so much money on the security products each year or creating or setting up the security
[06:58.100 --> 07:06.060]  team in our organization, but we're still actually less secure. Zero Trust provides a better framework
[07:06.060 --> 07:13.980]  to look at the cybersecurity and rethink the way we are doing security. As for cybersecurity,
[07:13.980 --> 07:26.720]  the cybersecurity cost, which was $3 trillion that was in 2015, will now be $6 trillion in 2021
[07:26.720 --> 07:36.200]  or 2021 or maybe more. Average cost of a data breach would be $3.62 million.
[07:36.760 --> 07:41.580]  That's a huge number. And that's quoted by Ponemon Research Institute.
[07:42.080 --> 07:49.380]  And there's a new research that has come up recently. Now, as I said, there's another research
[07:49.380 --> 07:54.720]  by Forrester, which estimates that 80% of the data breaches which happen because of privileged
[07:54.720 --> 08:02.160]  access abuse. That's a good number. That's a huge, huge number. So these figures come despite of
[08:02.160 --> 08:10.040]  organizations spending a lot on the cybersecurity. And there are more and more efforts that are going
[08:10.040 --> 08:18.620]  in the cybersecurity or securing the organization. But the worrisome picture comes is when we talk
[08:18.620 --> 08:23.760]  about that there is an organization which has breached once, but then that happens not just
[08:23.760 --> 08:31.760]  once, but multiple times. We are spending more money, but we are becoming less secure. How come
[08:31.760 --> 08:39.120]  that's happening? We're spending money on tools, people and whatnot. But the point comes is,
[08:39.120 --> 08:44.040]  are we spending the money on the right things? Or the right kind of a framework?
[08:44.880 --> 08:51.200]  Because I wouldn't say that what we were doing earlier was wrong or right. But I will say I'm
[08:51.200 --> 08:59.880]  just my point is that every year, there's something new that is coming up. Not just every year,
[08:59.880 --> 09:05.960]  every month, every day is something new that is coming up. We have to tackle that. And we have to
[09:05.960 --> 09:13.020]  make sure our organization is secure. No organization is ever 100% secure, but we can take baby steps
[09:13.020 --> 09:22.260]  towards it. So I have some questions for you. When we talk about client, do we say that client is
[09:22.260 --> 09:31.900]  secure? The people, the users are secure? No, they're not. We've seen that. How about a server?
[09:31.900 --> 09:40.940]  Can we say that the server is secure? No. How about the whole network? Can we just depend on that?
[09:41.740 --> 09:49.640]  What do you say? We're all working remote. So are we dependent on network and can we just trust it?
[09:49.640 --> 09:59.540]  No. So if we don't do that, so simply don't trust and what shall we do? So if we have to trust,
[09:59.540 --> 10:08.250]  what should we verify? It's like trust but verify. But is it safe to say that trust but verify?
[10:09.460 --> 10:16.940]  So here, if zero trust sounds similar to you or familiar to you, it's because zero trust has
[10:16.940 --> 10:22.700]  been around for a while. But it's really hitting the nail right now, or hitting the rhythm right
[10:22.700 --> 10:30.740]  now. The old model was, oh, you are in the network, we're going to trust you. The new model says,
[10:30.740 --> 10:40.760]  never trust and always verify. So this actually flips the mantra from trust but verify to never
[10:40.760 --> 10:49.880]  trust and always verify. 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:03.780]  So over the years, security models have matured or have transitioned. Many of us have first seen
[11:03.780 --> 11:10.700]  access control list. Then came role-based access control, which still exists in some form. And
[11:10.700 --> 11:17.600]  then came principles of least privilege, and especially it was at all rates. But the problem
[11:17.600 --> 11:23.740]  with R-backwards or role-based access control, and even subsequently with least privilege as well,
[11:23.740 --> 11:30.680]  was actually, it just allowed all the subjects to be assigned multiple roles and multiple
[11:30.680 --> 11:36.600]  commissions, which eventually loosened to a point wherein it defeated the purpose it was meant for,
[11:36.600 --> 11:44.440]  or intended the control it was meant for. And when we talk about introduction to cloud
[11:44.440 --> 11:51.700]  and diverse SaaS offerings, especially for our core applications, how are we going to implement
[11:51.700 --> 12:00.060]  and manage this effectively? If as an admin, I lead the organization today, how soon are we
[12:00.060 --> 12:06.520]  removing the accesses? Or let's say if I move from one team to another, how soon are we managing those
[12:06.520 --> 12:14.260]  accesses? It's really, really hard. So those things are really important to be managed. And security
[12:14.260 --> 12:19.840]  parameter has become a thing of the past, whatever we say. Especially with the cloud adoption and
[12:19.840 --> 12:26.940]  advancement in technologies, enterprise must assume that the environment is hostile. And that's how
[12:26.940 --> 12:32.140]  when we go to the public cloud, we have something in mind that we are putting our data into the
[12:32.140 --> 12:38.920]  public cloud. And we have to take some ownership. We have to talk about the shared responsibility
[12:38.920 --> 12:44.300]  model, that what's the cloud provider's responsibility, what's our responsibility.
[12:44.360 --> 12:50.400]  And that's the core tenet of Zero Trust. And it provides a better framework to look at
[12:50.400 --> 12:57.760]  cybersecurity and rethink the way we are working towards cybersecurity. It's essentially
[12:58.400 --> 13:05.780]  established a model of trust, verification, and continuous evaluation of trust for further access
[13:05.780 --> 13:15.120]  and later moment. Now, when we say Zero Trust, how's the architecture? If you can see in the
[13:15.120 --> 13:21.680]  picture, the whole system or the supporting system in the whole architecture is called a
[13:21.680 --> 13:27.760]  control plane. And every component is referred to as a data plane, which is being coordinated
[13:27.760 --> 13:34.360]  and configured by the control plane. In Zero Trust, we first identify a protect surface.
[13:34.360 --> 13:41.140]  Now, what is a protect surface? It's made up of the organization's or network's most critical
[13:41.140 --> 13:52.500]  and valuable data, assets, applications, services. So once we identify, now why we need to identify
[13:52.500 --> 13:59.660]  because it's unique to every organization. No two organizations can have the same crown jewels.
[13:59.660 --> 14:06.860]  So we need to first identify those unique critical infrastructure. When we have identified that,
[14:06.860 --> 14:11.380]  we can identify how the traffic moves around the organization,
[14:11.380 --> 14:15.300]  understanding who the users are, which applications they're trying to access,
[14:15.300 --> 14:22.360]  and how they are connecting to the network, and enforcing the policies based on that.
[14:23.320 --> 14:29.440]  Once we have the basic understanding of interdependencies between data, application,
[14:29.440 --> 14:38.860]  users, services, we can put controls, especially when we say that these protect surfaces
[14:38.860 --> 14:44.860]  need the control as soon as possible, creating a micro perimeter around it.
[14:44.860 --> 14:49.020]  And we can create a micro perimeter by deploying a segmentation gateway,
[14:49.460 --> 14:55.420]  more commonly known as a next generation firewall, especially to ensure only known
[14:55.420 --> 14:59.780]  allowed traffic or legitimate applications have access to the product surface.
[15:00.160 --> 15:06.120]  The segmentation gateway can actually provide us granular visibility into the traffic,
[15:06.120 --> 15:10.160]  and enforce additional layer of security, especially layer 7 security that we've been
[15:10.160 --> 15:18.040]  talking about. And people always talk about network segmentation, but application segmentation
[15:18.040 --> 15:24.580]  is also equally important. So we need to have application segmentation, application gateway
[15:24.580 --> 15:31.100]  segmentation, or network segmentation in place. We continue to monitor and maintain in real time.
[15:31.740 --> 15:39.180]  Still, we are actually lacking a lot of things. First, we identify one perimeter,
[15:39.180 --> 15:45.960]  secure that. Move ahead. We need to go phase by phase. We cannot say that we are going to do
[15:45.960 --> 15:51.860]  everything at once. That's not quite humanly possible, or even with machines possible.
[15:51.860 --> 15:56.780]  Everything takes time. We need to understand the environment. We need to start understanding
[15:56.780 --> 16:01.880]  what's happening in the organization. What assets do we have? What network do we have?
[16:02.200 --> 16:09.240]  So at the same time, implementing zero trust in an enterprise network is predicted on the
[16:09.240 --> 16:16.420]  organization's network itself. It establishes where boundaries can be placed, and enforcing
[16:16.420 --> 16:22.200]  access controls to shield the specific applications, sensitive applications,
[16:22.200 --> 16:29.780]  such as which are on-premise applications, data centers, safeguarding it from unauthorized access,
[16:29.780 --> 16:34.900]  and lateral movements that I mentioned. Most companies have applications and data spread
[16:34.900 --> 16:42.000]  across the multiple locations, and don't have insight on who's accessing their application,
[16:42.000 --> 16:48.860]  how data is being stored. So to address all these things, companies have often accessed
[16:49.600 --> 16:56.420]  multiple resources, use multiple technologies around. And when cloud came into picture,
[16:56.420 --> 17:06.520]  everybody needed, like, we need information stored secretly, safeguardly, on the on-premise servers.
[17:06.520 --> 17:12.320]  And when we are moving to the cloud, a public cloud, private cloud, SaaS applications,
[17:12.320 --> 17:18.480]  we have started using. So how shall we leverage all those things? 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:32.540]  So this is a mix of technology, which actually creates a segmented security architecture,
[17:33.390 --> 17:41.200]  where we can actually, which might be difficult to be sure what policies are in place, or how
[17:41.200 --> 17:49.140]  data can be secured. So to succeed, we all need to have a single unified security architecture.
[17:49.140 --> 17:56.080]  This is our network, where the users are accessing these applications. This is how data is flowing
[17:56.080 --> 18:01.880]  across the public cloud. These are my SaaS applications, and this is how they are interacting.
[18:02.540 --> 18:10.240]  This is my private cloud, and this is my data center. There are controls and limits who has
[18:10.240 --> 18:16.760]  access to what information, what assets, how they can use it. If we are dealing with any
[18:17.940 --> 18:23.760]  third-party vendor, how much access they will have, whether they will have read-only access,
[18:23.760 --> 18:28.840]  they'll have write access, inspect the traffic, and enforce security policies.
[18:30.120 --> 18:36.520]  The first thing, we should categorize the data. Ultimately, security teams are focused on
[18:36.520 --> 18:43.660]  protecting the data, whatever we say. Where possible, data should be safe, even when it
[18:43.660 --> 18:51.320]  leaves the organization, leave the device, app, infrastructure, network. The controls that we have
[18:51.320 --> 19:00.080]  in place, data should be classified, labeled, encrypted, and access restrict based on all of
[19:00.080 --> 19:07.600]  these things. So, what should we do in that case? We should first understand the current setup.
[19:08.180 --> 19:15.400]  Take a detailed look at what current data we have, what locations we have, do we have any
[19:15.400 --> 19:23.740]  regulations in place? And data classification also is important because it allows organizations
[19:23.740 --> 19:32.480]  to manage the data more effectively and accurately. The organizations might be facing issues, okay,
[19:32.480 --> 19:38.700]  my assets are lying all over there. But if you think about, there's a crown jewel, and we have
[19:38.700 --> 19:43.840]  not marked it as a crown jewel. There's a low-hanging fruit, and we don't know whether it's
[19:43.840 --> 19:51.880]  or that might be a critical device for some of the teams. So, it's very important to label it,
[19:51.880 --> 19:59.100]  whether it's restricted, internal, external, confidential, private, or what kind of data it is.
[19:59.840 --> 20:05.560]  Principles of least privilege. And you must be hearing it from like,
[20:05.560 --> 20:11.740]  ages back, okay, we should have principles of least privilege. Did we implement it?
[20:11.740 --> 20:17.700]  Least privilege access rights is a fundamental principle of zero-trust security. Overly
[20:17.700 --> 20:24.580]  excessive access is one of the key issues causing the insider threat to become insider incidents.
[20:24.580 --> 20:31.520]  Zero-trust networks only allow access rights as and when necessary. Covering the access is
[20:31.520 --> 20:39.300]  no longer appropriate. 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:50.660]  Certificate-only based authentication is a weak solution. As a certificate can be stolen. If I
[20:50.660 --> 20:55.840]  have your certificate, I can log into the environment. Another insecure approach would be
[20:55.840 --> 21:03.640]  insecure access method to jump host or bastion host. So, what we can do is we can have
[21:03.640 --> 21:09.660]  multi-factor authentication which can be integrated with LDAP or any other solution
[21:09.660 --> 21:16.240]  which can be there. And we can have single sign-on which can improve the authentication strength.
[21:16.540 --> 21:26.700]  However, authentication itself or alone is not sufficient. Users accessing the cloud resources
[21:26.700 --> 21:34.980]  must be authorized once we have authenticated. So, the fine-grained control can be applied.
[21:34.980 --> 21:42.360]  And less lateral movements of a user can make it even if someone try and access the network,
[21:42.360 --> 21:46.500]  we have fine-grained access, the access can be stopped then and there.
[21:47.620 --> 21:54.960]  User account with least privileges. Especially if an employee leaves an organization.
[21:55.900 --> 22:02.400]  How about removing their access? It becomes very important to remove their access.
[22:02.540 --> 22:09.200]  With the principles of least privilege, an employee whose job is to enter the data center,
[22:10.100 --> 22:15.960]  the person can actually add or modify the records. If the person's laptop is infected
[22:15.960 --> 22:23.600]  with a malware, what could go wrong? The system can actually install a malware on other systems,
[22:23.600 --> 22:30.820]  infect the database. If the person has root credentials, the infection can actually spread
[22:30.820 --> 22:35.880]  the system-wise and spread in the network. I'll give you an example which happened with me,
[22:35.880 --> 22:41.380]  wherein a person was working with me. The person was a network person who was handling the
[22:41.380 --> 22:48.400]  firewalls. His job was to monitor and work on the firewall rules. So, the person can monitor and
[22:48.400 --> 22:54.180]  make changes to the firewall or ACS. 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:10.300]  Now, the person who's managing the firewall logs suddenly gets a request,
[23:10.300 --> 23:15.720]  that can you please modify this access for me in the firewall? And the person does it.
[23:16.660 --> 23:22.560]  Practically, the person should have access to the network or network firewall? No,
[23:22.560 --> 23:29.000]  the person should not be even having access to it. Lead the modifying part.
[23:29.520 --> 23:36.500]  So, it becomes important to have all those rights checked at the regular intervals. We can have
[23:36.500 --> 23:42.960]  just-in-time privilege. If a user who really needs access to the root credentials, reducing
[23:42.960 --> 23:50.500]  privileges, especially when they don't need it. We can use disposable credentials. We can enable
[23:51.300 --> 23:56.800]  a function. Okay, these are the six hours or six days a person needs access to this environment.
[23:56.800 --> 24:03.620]  And after six days, let's remove the access. So, all of these things can be done. And we can
[24:03.620 --> 24:08.840]  actually stop the lateral movement of all those attacks that are happening, might be spreading
[24:08.840 --> 24:17.580]  across the network. And this is one of the things that the primary thing that a pen tester can
[24:17.580 --> 24:24.840]  leverage. If all those privileges and rights are not there, that can be exploited. And as a security
[24:24.840 --> 24:33.120]  researcher, if these things are not there, I am going to target that. If we zone off what the team
[24:33.120 --> 24:37.420]  or what the malicious actors might get access to,
[24:37.980 --> 24:45.240]  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:03.320]  We have to have a principle to build the cloud network, which can result in an isolated island
[25:03.320 --> 25:11.440]  of a lot of different networks. If one network is breached, we have other networks which can
[25:11.440 --> 25:18.600]  be safeguarded, because it's impossible to gain access to those networks, which can actually
[25:18.600 --> 25:26.920]  reduce the attack surface. Now, tell me one thing, how many of you have multiple accounts,
[25:26.920 --> 25:32.880]  multiple passwords? I have. I have like tons and tons of username passwords, tons and tons
[25:32.880 --> 25:42.700]  of accounts on multiple websites. So, what could go wrong? Earlier, the identities were not defined.
[25:42.700 --> 25:50.700]  There were all internal applications. There were many passwords. Then, in mid-90s, identities, we started
[25:50.700 --> 25:58.860]  defining. We started uniquely identifying who has access to what. We started talking about single
[25:58.860 --> 26:04.940]  sign-on, password policies, role-based access controls. Then came an era where we started
[26:04.940 --> 26:12.680]  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.620]  We made sure that we have to have something in place which can reduce the privileges. So, we
[26:24.620 --> 26:31.040]  came up with principles of least privilege. Then came a point that that's not necessary. How about
[26:32.060 --> 26:38.740]  understanding what could be the risk score? How are we handling the risk of an application?
[26:38.740 --> 26:46.460]  How are we handling the risk scores? Adaptive access, context-aware access, authorization,
[26:47.700 --> 26:54.100]  application-only access. And now, we're talking about, let's go password-less.
[26:54.400 --> 27:03.820]  We're talking about QR code scans and whatnot, FIDO2. So, all of those things are actually
[27:03.820 --> 27:11.940]  contributed towards maturing the organization IAM strategy. Now, what is context-aware security?
[27:11.940 --> 27:20.160]  And why are we even talking about it? 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:32.320]  We will all stick to the old world. Today, with all the modern solutions that we have,
[27:32.320 --> 27:38.080]  especially with cloud, can we just have a username and password? I have, on one of the projects,
[27:38.080 --> 27:44.580]  wherein the organization was using six-digit characters. Should we use that small character
[27:44.580 --> 27:51.420]  password? No. When you talk about moving to cloud, we have to be sure that we are using a strong
[27:51.420 --> 27:57.620]  password. We have to have a strong password policy. We have to have multi-factor authentication to
[27:57.620 --> 28:07.740]  verify during login or password checkout, especially at the time of privilege elevation.
[28:08.960 --> 28:15.180]  Multi-factor authentication is a must-have. We cannot counter that with anything.
[28:15.300 --> 28:22.060]  Passwords are not good enough. Let's face it, whatever we say. And even if we talk about the
[28:22.060 --> 28:29.540]  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:44.980]  All of that is there. So the good news is, multi-factor authentication is an easy way.
[28:45.020 --> 28:51.220]  We have, as I said, FIDO2. We have Google Authenticator.
[28:51.220 --> 28:55.880]  And many authenticators are available, which can actually help us in securing our applications,
[28:56.420 --> 29:04.260]  securing our data. With context-aware access, we can figure out where we are trying to access,
[29:04.260 --> 29:10.860]  which device we are using. If we're using a device for so long, there is a context that
[29:10.860 --> 29:16.040]  has been built for the device. And suddenly we change the device. The application should
[29:16.040 --> 29:23.040]  ask us for blocking or for asking for a step of authentication and saying that, okay, let's
[29:23.040 --> 29:33.680]  re-authenticate you. If I am in India right now, if I'm in Bangalore, suddenly I log in from US,
[29:33.680 --> 29:40.800]  UK, or any other location. Am I supposed to log in? No, I'm not. Practically, it's not possible.
[29:40.800 --> 29:47.800]  So what shall we do? Block the access. And adaptive access can be on applications and
[29:47.800 --> 29:54.680]  services. At the same time, when we have adaptive access, how about monitoring that,
[29:54.680 --> 30:02.140]  which means enabling the right users or right user to have the right access to the right data
[30:03.040 --> 30:10.740]  for the right reason from the right location. So what I said, enabling the right users to
[30:10.740 --> 30:17.080]  have the right access to the right data for the right reason for the right location, which includes
[30:17.080 --> 30:25.800]  device, network, workload, and application, all at the same time. Now, when we say monitoring and
[30:25.800 --> 30:33.040]  logging, we can build identity-based network context, like creating micro-parameters that
[30:33.040 --> 30:39.320]  are based on identifying the users. This is also known as zoning, where we can automatically
[30:39.320 --> 30:43.840]  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 --> 30:58.380]  Besides users and accounts, every device owned by the organization should be uniquely identifiable
[30:59.100 --> 31:04.140]  in a single device directory, wherein we can say, okay, these are the devices which are in use. If
[31:04.140 --> 31:10.380]  there is a phishy device, let's remove it from the network. And whosoever is trying to access it
[31:10.380 --> 31:16.760]  from a malicious device, let's block their access. And let's face it that hacking is inevitable.
[31:16.840 --> 31:23.280]  Attack will happen. The systems will get compromised. But we should have an idea
[31:23.280 --> 31:31.360]  what's our blast radius. What's our network? Then, if we find that there's something malicious going
[31:31.360 --> 31:38.540]  on, we can stop it or prevent it to happen. Are the alerts being managed? How much automation
[31:38.540 --> 31:45.340]  we have in place to detect the incidents? We're talking about orchestration, creating the playbooks
[31:45.340 --> 31:50.840]  relevant to our organization. So it becomes important to monitor and lock all the
[31:51.360 --> 32:00.340]  data which is going on in the network. Then comes, how about we architect our own zero trust
[32:00.340 --> 32:07.300]  architecture, micro parameters. Once we know our data, our flow, what's happening in the network,
[32:07.300 --> 32:14.560]  we can create the optimal micro networks around each of them. Separate production data from dev
[32:14.560 --> 32:21.900]  and test can really, really help us in segmenting the whole network. We can have
[32:21.900 --> 32:27.940]  separate cloud accounts, which can be a best practice for having isolation.
[32:29.060 --> 32:36.280]  What can we do? We can define the micro parameter zones and segmentation, especially around
[32:36.280 --> 32:42.780]  sensitive data. We can enforce segmentation using physical and virtual security controls.
[32:42.780 --> 32:48.660]  Establish access based on these controls and micro parameter designs. We can encrypt
[32:48.660 --> 32:56.640]  all the network traffic regardless of origin. But it has to be checked what is relevant.
[32:56.640 --> 33:03.140]  Now, another important aspect is policies and procedures. Identity governance and policies are
[33:03.140 --> 33:10.180]  very important, but must be comprehended across the applications. We also have to take into the
[33:10.180 --> 33:15.140]  account the legacy applications or legacy applications that we have. Do we have support
[33:15.140 --> 33:20.500]  from them? How are we going to handle them when we talk about cloud or the advanced or latest
[33:20.500 --> 33:26.900]  technologies that we have? Legacy apps can be run in virtualized environments or containers
[33:26.900 --> 33:35.460]  or can be segmented from the rest of the network so that if something happens, if they are compromised,
[33:36.540 --> 33:42.640]  the malicious users cannot pivot and move laterally to compromise the rest of the systems
[33:42.640 --> 33:49.480]  or infrastructure. So what we can do as part of implementing, starting with
[33:49.480 --> 33:57.340]  categorizing data with least privilege, network management, segmentation, policies and procedures,
[33:57.340 --> 34:05.140]  all of this that's there. But how should we take a step forward? Especially when we have
[34:05.140 --> 34:12.980]  remote access, we have a BYOD, we have default deny or so many other policies. How are we going
[34:12.980 --> 34:19.460]  to handle that? We can implement it wherein we identify what type of applications are there.
[34:19.480 --> 34:25.380]  And that's the fundamental step. If we know our infrastructure, we have categorized it,
[34:25.380 --> 34:32.440]  we know what's public, what's internal, what's confidential. We can define the zones, we can have
[34:32.440 --> 34:39.280]  micro-parameters come in and help us. We can suggest that, okay, let's create a chunk of data
[34:39.280 --> 34:46.700]  that represents that own micro-parameter. Then we can map the flows of the sensitive data.
[34:47.440 --> 34:52.500]  We can have, okay, this is the segment which can be multi-directional,
[34:52.500 --> 34:57.740]  which can be bidirectional, or it should be accessible to the rest of the world,
[34:57.740 --> 35:04.600]  which can actually optimize our data flows. Then how about creating the boundaries?
[35:05.200 --> 35:14.000]  Once we all know this all micro-network, we can design them. We can say, okay, this is what fits
[35:14.000 --> 35:21.360]  for the security. And this also take into consideration that, okay,
[35:21.960 --> 35:27.960]  we have a nice posture in our organization. We have a mature posture in our organization.
[35:27.960 --> 35:37.420]  We can continuously monitor and log the traffic. It can actually provide us the data analytics
[35:38.480 --> 35:45.400]  for malicious activities across the entire micro-parameter ecosystem. We can embrace
[35:45.400 --> 35:50.400]  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:05.080]  So as I said, should we trust or don't trust? Zero trust is more of a perspective than a product.
[36:05.080 --> 36:12.340]  Someone says it's a product, sorry, that's not the case. 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:25.160]  There has to be something which might be failing. So no single technology which is associated
[36:25.160 --> 36:32.920]  with zero trust architecture. 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 --> 37:02.860]  Can we see that now? So there are things that we've been doing. There are things that we can do.
[37:02.920 --> 37:08.300]  But we can take the baby steps. We can take the steps towards the zero trust journey.
[37:09.360 --> 37:15.800]  And the first step comes in when we start thinking about it, that what are things we can do? We can
[37:15.800 --> 37:22.100]  talk about verifying the users. We can have single sign-on, multi-factor authentication everywhere.
[37:22.100 --> 37:27.400]  We can have user behavior analysis. We can have risk scoring for accesses. We can validate the
[37:27.400 --> 37:34.180]  devices. It could be device and app management, device context. We can have endpoint privilege
[37:34.180 --> 37:41.720]  management properly. Then principles of least privilege, which we can never remove. We can have
[37:41.720 --> 37:50.360]  granular role-based access, which can actually limit literal moments. Then how about learning
[37:50.360 --> 37:56.840]  from the architecture that we have and adapting to the new architecture using machine learning,
[37:56.840 --> 38:05.300]  AI. These are some of the references that I have looked through and researched of
[38:05.300 --> 38:13.640]  some amazing corporations. You can reach me on Twitter, LinkedIn. That's my email address. I'm
[38:13.640 --> 38:18.140]  very much reachable on all the platforms if you have feedback, if you want to have a discussion.
[38:18.640 --> 38:26.820]  And then we're all good. Thank you so much. This is Namaste from India. Thank you.