Webinar Recording

Technological Approaches to a Zero Trust Security Model

Name: Technological Approaches to a Zero Trust Security Model
Uploaded: 2021-06-18T12:00:00+02:00
Duration: 58 min 50 s
Description: The traditional model of enforcing security at the network perimeter is no longer valid as employees, devices and workloads move outside the corporate network. A Zero Trust model offers an alternative that secures data while ensuring it is accessible from wherever employees are working. But finding the right technological approaches to Zero Trust is challenging.

Richard Meeus

Director of Security Technology and Strategy, EMEA

Posted on Jun 18, 2021

The traditional model of enforcing security at the network perimeter is no longer valid as employees, devices and workloads move outside the corporate network. A Zero Trust model offers an alternative that secures data while ensuring it is accessible from wherever employees are working. But finding the right technological approaches to Zero Trust is challenging.

Webinar presentation, KuppingerCole

Webinar presentation, Akamai

Lead Sponsor

Video Description

Show Transcript

Good morning. I'm John Tolbert, a lead analyst here at KuppingerCole and for today's webinar, our topic is "Technological approaches to a zero trust security model". And I'm joined today by Richard Meeus, director of security technology and strategy for the EMEA region from Akamai. Welcome Richard. So a few announcements before we begin, we have some other KClive events coming up in the near future. And the next one here will be managing digital workflows and service. Now on June 23rd, this is about it service management tools.

Then the next one will be cloud strategy optimization, ensuring efficient and secure collaboration and cloud on July 7th. And then we're happy to have our flagship event, European identity and cloud conference happening this September 13th through 16th in Munich, it will also be hybrid. So there will be an in-person part to it as well as available online and really looking forward to that and hoping that you can join us for these upcoming events.

So some logistics information: we're recording the webinar and both the recording of the webinar and the slides that you see today will be available later, probably by tomorrow. We will have a Q&A session at the end. So there's a questions blank in the GoToWebinar control panel, feel free to type up questions and put them in the blank. And we will address those at the end of the presentations today.

And to be a little bit more interactive, we have a couple of poll questions and we'll pause during the presentation to allow you an opportunity to answer the polls, which will then show the results and discuss with you. So again, I'm John Tolbert, I'm gonna kick it off and talk about just an overview of what we mean by zero trust architecture and how and why identity digital identity is a key component of that.

Then I'll turn it over to Richard and Richard will talk about things like multifactor authentication and FIDO2, and really get down into some of the details about what does least privilege mean at the network application layer. And then we'll do those Q&A at the end. So we'll start with a poll question and you considered zero trust for your organization. So just feel free to check yes or no, or if you're not sure if this is right for you and just kind of get a feel for where everyone is on their zero trust journey, if, if you're on your zero trust journey. Okay.

So we'll take a look at that later. So zero trust, what do we mean rethinking security? Why do we need to rethink security?

Well, as you can imagine, if you'd been watching the headlines, we know that cybersecurity breaches and attacks, ransomware, all these things are really big stories these days. And for good reason, they are on the increase.

2021 has just been a year where different kinds of cyber attacks have been happening practically every day, every week, something else dominating, even there, the regular news cycles, some of it may have been sponsored by state actors, but there's, you know, a huge component of justice cybercriminals with doing things like ransomware and him trying to get credentials and commit from, you know, and as a result of the pandemic, naming more organizations have been allowing people to work from home.

We've been trying to deal with, bring your own device for a number of years, but this has really been escalated by the pandemic. And when you don't have corporate control over the devices or the environments in which your employees or partners are working, then that tends to decrease the overall security posture and requires us to think about, well, what are some other measures that we can put into place to make it safer to get work done?

And, you know, cloud has been on the, on the rise for many years as well, but again, like many other things it's been accelerated by the pandemic. A lot of companies are choosing to do cloud first.

You know, I have a new application to deploy. We're going to put it in public cloud, or we're going to run something in private cloud. This is pretty much the way forward, you know, for most major deployments of applications and infrastructure today, and, you know, years ago, waterfall morphed into agile, agile required dev ops to get the incremental releases out in a quicker fashion.

And now we call it dev sec ops, making sure that security is a part of the release cycle, not to slow down the release cycle necessarily, but it requires a different way of thinking about, you know, how do you secure a ever-changing environment application, user base infrastructure? So we've probably seen many times trust, but verify used in conjunction with zero trust.

What we really mean as contextual authentication and authorization, we'll start theoretically with a zero trust, but we use methods to try to increase the identity assurance of individuals and applications and devices that then get access to resources that we're managing. So really zero trust is an architectural model. It's a concept. It's a way of thinking. It's not just a product. It has to be a combination of not just the products, but also various processes and new types of technologies that we need to integrate into our environments to make this happen. And it's more than just network.

It has to address the data layer, take into account digital identities. And again, that's not just user identities of which, you know, there are many different kinds of user identities. It could be employee partner, but also devices and things like that. And then network network is an important component of zero trust. It's just how these things fit together. And we'll dive into that here in the next few minutes, zero trust of course, is something we've all probably heard about and it has been hyped up quite a bit. And with good reason, it's a, it's a great architectural principle.

It's, it's definitely something that can help increase overall security, posture and organizations. If you, if you get on a zero trust journey and begin updating your environment, it's, it's a good trend, but I think it's really important to remember. There's no single product that gives you zero trust, you know, regardless of what vendors, how they may want to position their products, it's much bigger than that. It's the architecture, not just the product. And like I said, it's more than the networking. It has to be authentication and authorization of every interaction in your environment.

So it's also, you know, an architectural blueprint, you know, as you're offering new services or building up new infrastructure, it's a, you know, a guiding principle that you can use to design a new environments to meet new business requirements. And then fortunately there are lots of standards that apply at different levels and layers that can help facilitate zero trust. This also helps with interoperability as multiple products, get support these different standards. You can have pick and choose or do best of breed, product selections, as long as they're using the appropriate standards.

So kind of looking at the major components of, you know, the, the users, the devices, they come from, the resources that trying to access, you know, users can be employees. It can be your business partners or contractors that you have working for you for a short time and in different places too, it may not be all within your environment. They may be originating from their own enterprises and then there are consumers.

So you probably have different kinds of access controls and different resources that consumers would be trying to get to as opposed to employees, partners, or contractors, but around all of these, you have to have good processes and tools for provisioning, the users, deep provisioning, those users conducting access audits periodically to see if they have just the right amount of access to different resources and then governing the overall identity life cycle.

Then there's also compromised credential intelligence, which can help reduce with both the insider threat as well as predominantly consumer-based fraud. Knowing if our credentials, when use fraudulent, like some other sites recently, that was something that could feed into a risk analysis engine. Then devices will commonly.

We think of, you know, these requests either coming from desktop laptop or maybe a mobile phone now, but there's also IOT, many IOT devices are associated with user credentials, whether they be employee users for let's say, industrial IOT or consumer devices for, you know, home automation where most of the things like that, they can also be part of the overall authentication context.

So you need to consider, you know, things about the environment where the request originates, you know, IP addresses, network information, device intelligence, you know, there are services that provide a device reputation information. And then in some cases, SDKs allow you to look at information about the devices to, you know, does it have an identity associated with it is a patch. You know, this is their running. Some sort of anti-malware, what's the reputation. All this can be factored into the risk analysis decision and then there's resource attributes.

You know, where's it coming from things about the data itself, you know, criticality, sensitivity classification. And on top of that, we layer things like policy based access controls to say which kinds of users, and in which context should they be granted access to different resources? And this of course requires data access governance because you know, the sensitivity of a file and the types of users that need to be able to use it changes over the information objects lifecycle to sort of the core tenants of zero trust.

And so looking at the different kinds of resources, you know, there are many kinds of devices don't forget about bringing your own devices. This has become a big consideration.

And, you know, we have to embrace hybrid environments in most cases today. I mean, there are some places, sometimes organizations where it can enforce rigid control, but that's less and less likely in most organizations today, communication has to be secured encryption access per session.

You know, maybe in the old days, 10, 15 years ago, you'd might grant somebody access based on single log-in and allow them to move freely about your network for the next eight hours. But that, that can't be the case anymore. There really needs to be a good authentication event. The constrains, the user to least privilege to get, get done only what they need to get done and then do it per session. And that this access control should be policy-based.

Again, it's all about the risk analysis decision, you know, at long time with each request, skip over here to continuous authentication and authorization, because in order to do this, you need to be able to look at other factors other than just a login event.

You know, looking at the context, looking at, you know, are they, is the, this requests coming from the same device, has anything changed since the last time they tried to make an access and you can build it in this continuous authentication by looking at lots of the surrounding context, without necessarily having to ask the user to perform another authentication event. So let's say, you know, you're monitoring any different kinds of attributes about the user's behavior, and if nothing changes, then in, in many cases you may not want to interrupt the user's workflow.

You may have say, okay, I can accept the risk because nothing seems to have changed the same person doing the same work, but, you know, depending on the type of resource they access, you may say, okay, I really want to force another authentication event just to make sure it's the right user on the other end.

So that's how, what we mean about continuous authentication, how risk analysis fits into that, then there's the context and metadata, especially on the attributes side, metadata is a good way for adding, you know, the sensitivity classification kinds of information to unstructured data objects, but this needs to be managed because like I said, you know, that kind of information changes from time to time as well, but it should be factored into these runtime risk analysis decisions. I know this is a really busy looking chart, but what I wanted to really show is zero trust is an architecture.

It touches these four major components of what we deal with in it every day.

You know, whether it's endpoint, the networks that the devices reside upon the identity and identity and access management system and that even the data, and you see that a lot of the terms that we use in it, things that we're responsible for, but we SIM or sor, you know, SIM all of these different devices, different systems needed to be able to send information about immense that are happening, you know, log files to a centralized place for analysis and, and be able to perform things like using behavioral analysis on that, which then gets fed back into, you know, authorization policy engines, risk engines.

So you see, there are probably even more lines that I can draw to show the dependencies, but really just trying to illustrate that there are many components in an it infrastructure today, many it security components, and they all really need to be working together to achieve zero trust. So since authentication is one of the key things for zero trust, I thought we'd take a minute and look at what I think, you know, five key considerations are regulatory compliance.

So, you know, depending on where you are in the world, what industry you're operating in, different kinds of regulations apply. There could be financial regulations, obviously privacy regulations and their proliferating, really. And I think that's a good thing to protect both, you know, individual privacy and then even things like export control laws are needed to be codified into authentication. So that also affects security policies that companies or organizations might want to put into place.

Sometimes companies will say, well, we're operating in multiple jurisdictions and it would just be easier if we take the least common denominator and make that our corporate words, security policy. So you take the most restrictive regulatory jurisdiction by that across an enterprise or in some cases, you know, make it so that it depends on the location of the request and the, the country of origin for the user.

So you can see how regulatory compliance feeds into the development of corporate or organizational security policies, which then becomes a real strong driver for what level of authentication insurances and even there's risk adaptive and risk appropriate authentication that we need to consider. You know, we putting too much friction on the user, making them authenticate multiple times, you know, have an actual authentication event where they have to type in something or do something you can impede the workflow, but there are times when it's necessary and even expected.

You know, if I was a consumer and trying to transfer a large amount of money, I welcomed some sort of second factor authentication event assures me that the bank is doing what they're supposed to be doing. Same thing, you know, in a corporate context, if you're responsible for financial things that your business it's good to, you know, require one additional layer of assurance before conducting some sort of high value transaction.

But, you know, don't do that unless it's necessary. And a lot of the background processes this contextual and continuous authentication can allow your authentication systems to monitor what's happening and only interrupt the user when they really need to be.

If, if things change, you know, attribute based access controls are great. It allows you to put some emphasis on the resource and decide, you know, what assurance level is needed to be able to access the resource. So your authentication systems really need to be interoperable with authentic authorization systems.

And this is where looking at how these play together at the network at the cloud, the application level, you know, look for those products that's for not only the functional mechanisms that you need for authentication and authorization, but the ones that can communicate with your consuming systems. And some of those might be legacy systems.

Lastly, ease of use is oftentimes the back seat in requirements, but it's also important. You don't want to deter users from being able to use the system. You just want to improve the overall security posture without making it too burdensome for the user. There are lots of different authentication options that are out there. We've known for a long time. Things like knowledge-based authentication security questions. It's a terrible method. Don't use passwords or anything insecure. We know that like 80 or 85% of all breaches are involve bad passwords.

A lot of users have gotten used to SMS OTP, but that has its security problems too. But then we're left with things like PKI hardware, token smart cards, which, you know, PKI can be difficult to use an administer hardware, tokens and smart cards, things that you can use, which you can also lose. We see a preference not only on the consumer side, but you know, in what we call the consumerization of it, a preference for using mobile apps and mobile biometrics in an enterprise context.

So lastly, the building blocks for zero trust, just to kind of recap, it's user looking at the identity management component, the identity life cycle, being able to offer strong authentication and then risk-based authentication and authorization throughout their interactions within your environment device, managing the endpoint, making sure that it's secure, getting information about the network is important as well. Communication should be encrypted. All sessions on the network should be authenticated and authorized. Don't forget the systems and applications.

This means ongoing access governance, access reconciliations using the user behavioral analysis, using your other security infrastructure like Sims and sores. And then also at the data layer itself, you know, making sure that the data is protected, it's classified, it's categorized and there's data access governance to keep those bits of information metadata that's up to date as well.

So then I'd like to turn it over to Richard, John, thank you very much, indeed for excellent overview of, of zero trust and some, some key points that we're going to allude to in the, the second session that we're going to do now. So first of all, well ahead of the, the poll question, and we'll give you a couple of seconds to, to answer that one, has the pandemic increased the adoption of zero trust for remote access?

Yes, no. Or unsure. I want to discuss with you an approach that addresses some of the points that John covered. And as you mentioned, Zimmer trust is, is kind of a philosophy. And so when we start looking to refine that into actual sort of architect, we need to look at our requirements and there are many excellent frameworks such as those laid out by the NCSC and the zero trust principles and also ness in P 800 dash 2 0 7 that cover this in great detail. And there are various methods of addressing VTA or ZTE, which is zero trust access as laid out in the next drop.

And that was concerning concepts, such as STP, which is software defined perimeter and micro segmenting. Both of these have their on a very relevant, in many cases.

However, what I want to really cover today is the architecture that has had the most development behind it. And certainly the one most suited to remote access, which is seen as one of the biggest drivers with zero trust adoption due to the recent events. So firstly, I would like to remind people about this statement from the us government reprioritize federal information services towards a zero trust model. So the reason I said us government and not the white house or the president is that this is not from a recent executive order from Joe Biden that you've probably all heard about.

This is from the committee on of, on oversight and government reform on the office of personnel Mandarin data breach in 2016. This is about incidents that happened in the preceding two years, where they lost 21 million records of government, us government employees, the security name, address fingerprints, all of the manner of personal information, the five-years on. And we have a similar statement, but now the white house as a little bit more encompassing covers a lot more of the digital transformation and cloud aspects that occurred over the last five years.

And that's in a similar sort of concept. So why is this, why do we have to sort of reemphasize is matched in terms of zero trust benefits, from a security perspective, we know what the risks are. We seen what's happened. And what's happened in light of recent ransomware attacks, how attackers have got into networks and we've got all the way around inside and extra large amounts of data. We know what has happened before, is it the breach fatigue? Yeah. Do we see it as few tiles?

You know, that the hackers are going to get in whatever we do. Hey, maybe you'll have more impact this time. Yeah. Maybe people can play a lot more relevance when you're talking about this. When the relevance is, is when you can actually say X, now it's patchable or as gasoline that's affecting rather than personal data, but fundamentally this, this is, this is really all about trust. You know, it's who you trust and what you trust and how that trust is established.

And the first thing is that location most definitely cannot be an arbitrage trust NIST 802 0 7 states that zero trust assumes there is no implicit trust granted or assets or user counts based solely on their physical or network location. And if we have learned anything from the last 15 months is that our users are going to be increasingly mobile and accessing applications and data from an increasing array of networks with dubious levels of security or oversight.

We know that our users will be shown the network with smart fridges and Towson and doorbells and a huge amount of tablets, gaming devices, all probably with the same username and password, because that's just what the majority of people do. So in other words, the networks should be treated as hostile and probably compromised at least to a certain degree. We know that we're not going back to everyone being in the office, the genie's out the bottle for that hybrid, working in varying degrees is going to be here to stay.

And this means enabling and protecting your users while also not turning your network into a colander with connections made into environment from a myriad of different networks. So as our users can be anywhere and everywhere, we need to look at providing the same level of access wherever they may be never before has the Axiom work is what you do, not where you go over, be more true. So we need to move away from stitching the user's network with all their own trustworthy devices into the corporate network. Do we need to talk connecting machines to networks?

We need to focus on connecting users to applications because when we connect users, machines, and network, this is where the risk is. The majority of compromises come from phishing attacks, compromised users and devices. If we can address these issues, we can drastically reduce our response to access at the IP level is no longer required. So instead of we need to focus on the user and the application, and we can leverage the internet as a conduit here, the main concept, we will cover something called identity aware proxy.

Now zero trust has been used as a term for many, many years now and has been applied in lots of different network and security tools. But the cloud based identity are proxy is a very well-defined solution to a problem that sort of exploded in 2020. This allows users to, to work from anywhere.

It is, it has an inherent security and performance benefits over legacy network architectures that stretch far for the than just better remote access it's primary delivered, ideally at the edge and as close to your end users as possible wherever they may be. So if we look at this slide and look at the traditional scenario of an organization where everything is centralized, we have the VPN, the organization, and all of our remote users out on the lap.

Once that user on the left is connected on their VPN, they essentially have the same level of access as the user on the right, except as we discussed before the you, the network, the user on the left is using the one with all the IOT and bad password management might be compromised. So how can we make this smarter? How can we make sure, how can we make this so that the user on the left can access the applications on the right in a more secure or, and more scalable?

What, well, firstly, we can do authentication before the user is connected to the application. Now this will still be seen with the VPA. And as Joel mentioned, you know, once you connect it, you're in for that session and that could be eight hours or 12 hours or a week. And one of the key tenants of, of zero trust was continuous for authentication authorization. This is why this is different. This time we are checking when they want to access the actual application.

I continuously thereafter, ideally we'd also use MFA multi-factor authentication and using a token generator that is tied or linked to the user's laptop. This would be to prevent man in the middle attack. So it just happened at Twitter famously last year. And more than later, this means that without proper authentication, I cannot even see the application. I cannot access the first page of the application. Authentication happens before that, but this is very important.

I would have massively helped with the recent exchange and FYI vulnerabilities and zero day exploits protecting those assets against attacks, which required no credentials and were open to the internet. We know that there were lots of systems with both of these vulnerabilities, still exposed to the internet for many, many weeks after the patches were released. But if you had authentication before you could get access to them, you will be protected from the vulnerability.

It doesn't mean you shouldn't patch in much the same way that a while after the next year's Paul code, but it was still protect you until you can fix it. Now you'll notice on this load. We haven't actually got the, the identity provider in it because it, because it can be used in a number of different situations, you can use an, an on-premise IDP. You could use a cloud-based IDB. If you're using this for business to business, working with contractors and, and third parties, then you can actually have the IDP within the IAP itself entirely possible.

It really depends on what you want to do, and you can use multiple IDPs within this configuration. And next we can look at authorization. And this goes back to the other point that John mentioned about least privilege, you know, should I have access if I work in HR for the sale, better base. If I work in sales, should I have access to the HR database so we can further reduce the risk by following the principle of least privilege.

Now, obviously this is an important security design. Why they're relevant here.

Again, it goes back to our issue of machines being connected to networks. Now, if I want a VPN, I work in sales. I might be able to navigate to the HR database or the finance better base might not have a login for those applications, but if I'm a bad guy on a compromised system, I can see them. I have network level. I can see the IP address. What ports are open, what version of iOS and application is running. So I can check if it is patched, or if there are any vulnerabilities that I can exploit.

If we can use a system that checks to see if I'm authorized to access an application before even connecting to that application, then this reduces that risk because the actual number of visible reachable applications is hugely reduced. Sometimes significantly. Think about how many applications are in your organization. How many thousands of them are, how many you actually use think now about that compromise.

And now, now that we have drastically reduced what they can see and how that can have a huge effect on the potential blast radius, the connectivity is accomplished through an outbound only connect to that. You can see on the right-hand side here and each location where you have the applications. And this is a very simple device that does not allow inbound connections. So another security benefit instead they connect outbound to the cloud IAP to create a link for traffic emanating from the IAP back into the applications.

And then finally, how about if we don't actually connect the device to the server, the application applications running on at all, our remote users not actually connected the application is proxying that connection and allowing the device directly to the application without physical network access. Then if the user device is compromised, all, they can see the IP address of the cloud proxy of the cloud IAP, not the application. So we focus on the security elements so far blocking access to the actual network and just connecting users to applications.

This in itself will be a massive bonus of most organizations, but there are many of the benefits as we're not connecting machines or devices to networks, we don't need the majority of VPNs that exist in organizations. This means that we can remove that bottleneck.

Also, as we discussed at the beginning, applications are being moved to the cloud. This is not an issue, but identity where proxy, we don't care about where the app is located. We don't care about why the user was located. We can just connect with two together through the cloud proxy, update the origin on the proxy and the users will seamlessly connect to the new cloud app just as they did when they existed, though in DC. Also as the location of the user is irrelevant to the connection.

Then whenever the user is working, they will get the same level of service even in the office, which now just essentially needs to resemble a hotspot rather than a dedicated lab. And when they connect to the new app in the cloud, they do not have to go through the central DC, so no more happening or tromboning of data, no more having to VPN into the office when the majority of our apps are located elsewhere. Now we can connect to the app directly to the proxy. This means that it is frequently quicker and also reduce the bandwidth requirements.

So the head office, another benefit is that with the additional security at the outset, you have the flexibility to use more devices, even BYO devices. So if you're juggling homeschooling and don't have enough devices, then you can log it on your iPad or your personal phone to relevant and applicable applications. This is also very relevant. When you think of users who would never normally have a laptop and use a desktop at work, if they need to work from home, why can't they use their own devices?

If you can provide the application securely and safely and within governance, then why not running our cloud proxy? We just don't utilize many other services that lend themselves to this architect, such as a CDN for application acceleration, very important for global organizations, which users now having to VPN across the globe to try and access devices and databases and services on the other side of the planet. And they suffer massively latency doing that.

There is a VPN also you can add in a wife and afford the same degree of protection or your internal applications as you do for your accent or facing ones with a web application and fault. And then lastly, and one of the key tenants that John mentioned earlier is that a policy there may not be times when access for authenticate an authorized user may not be suitable. Yeah. What are the IPN roads making? The connection is known to be malicious. It has been talking to a tour node. What if XDR detection has picked up an anomaly device?

Part has always been included in money, zero trust architecture discussions, and that ability to understand if a device could have access to that application based upon the sensitivity of the data and the status of the device is very, very important. And tying that into a scalable policy that can take telemetry from multiple sources to make that decision, rather than just the, the legacy check to see if the user's fall was on an a V was an AVS installed. If you can do this, then you have a very powerful engine to decide whether that user I can get access to that application.

We're also thinking about for device with posture perspective, what of his patch Tuesday and do all your users have the latest updates installed? What about the ones on a poor internet connection?

You say, well, you haven't got the patches installed. Do you block them? Or do you allow them access to maybe less sensitive data? In the meantime, allowing them to continue working whilst downloading the patches, the IAP to very simple architecture, to addressing many of the current security and accessibility issues of our time, leveraging the cloud and the edge to give scale coverage and redundancy ensures a service that enables our users to protect them and our businesses. But as with all things with identity, it does have areas, but it can become a victim of human fallibility.

And this is where we start talking about a few of the things that John picked up on previously in terms of identification. So the three core components of NFL, something, you know, something you have and something you are, we all know this. The first one is the bane of security personnel everywhere, especially with breaches and spills.

Very, very common 9th of June. This year 3.2 billion usernames and passwords were leaked from multiple databases. And the attack was, it was dub Roku, 2021, the 3.2 billion. When you think there's only 4.6 billion internet users in the world, there's a good child or some bad guys are username and password relationship to every one of your employees. And they are pumping it into websites all over the world, including your own.

So we know that the username and password on its own is not enough and decades of contradicting and confusing advice on passwords has made users unwilling to jump through another hoop provided by the security team or the how their password to be formatted. Do we need to add another factor? That's something you have or something you are. This could be your mobile phone or your fingerprint. For example.

Now, if we were combating consumer account take care of in a retail environment, then adding an SMS text might be sufficient enough to reduce the risk and associated loss, even with no limitations. However, in a business environment, the risks are much greater and the potential loss is much, much higher. So something like SMS is not going to cut it again. We need something smarter and there has been an increase in the use of push notification for applications running on mobile phones.

However, and as I'm sure you can see where this is going, there is a risk there as well. We'll have big that.

You put a, remember the Twitter hack last July when several celebrities and personalities were compromised and seem to be sending out tweets saying that if you send them $1,000 in Bitcoin, they would double it for you. When you realized that this included people such as Barack Obama and Kim Kardashian. And then you can imagine the impact of this hat.

But although the attackers had used normal techniques to get the usernames and passwords using tools like vishing use your phone call rather than email to get the Twitter employees to visit the phishing site, to then capture the details that they could gain compromise. His account was the criminal to capture the username and password on the fishing site. They immediately use it on the actual site.

This generated the second factor requests, which the Twitter employees Julie responded to and these men do, the attackers were now in, no, it doesn't matter if the second factor, the code that they type into the phishing website because they can pass up through as well or push notification because that just go through as well as the user thought they were to just go website. They just assumed it was okay. And the problem is, is that it's quite simple to manipulate the MFA service at that point is down to the employee to make the right security decision.

As you can see in the images here, what is being generated by legitimate login and the other buyer phishing attack would, you know, when to press the green button, the issue is that many MFA services still don't bind your authentication attempt to the MFA challenge. There is a security answer for this, and it's an architecture that's called Fido two to fast identity.

Online, two, this cryptographically links, your authenticator, whatever that may be to your computer, so that when you're put at Angel's or stolen or fished, or you're caught by a man in the middle attack, it knows your computer is not actually talking to the protected asset. I dropped the connection. But through that today, you need to use physical security keys. And John mentioned these earlier, then these add lots of costs and lots of complexity and employees hate having to carry extra hardware, but they can forget, or they can lose it.

Also, I haven't looked in the bottom of your desk drawer and see how many of these you've acquired over the years, either dead or dying. And we've probably voted like there about what or where they relate to it.

So said, we need a better solution to manage this. So this can be something that you always have with you. Yeah. Your mobile phone, the familiar postal MFA process is linked to your computer. So you're not reliant on employees having to guess which push screen is valid in the previous screen because the system takes care of that for you. And only allows a connection from a device linked the phone. This fish proof design will allow users to operate more securely with seamless mobile interactions.

Guaranteeing that the user's computer is the actual device connects into your estate and listings on a building, a link between your authenticator and your computer. Also allow you to look at more user enabling ideas. For example, we've always talked about using your email and password alongside your authenticated plastic to F a Y. Why can we use authenticator and maybe fingerprint recognition? This gives us two factors, something, you have something you are, and then you can dictate a password. Yeah. How great would that be?

If that password is log, it is one of the major drivers in most photo deployments as organization. So the huge benefits in removing the burden of password management. So I just liked it to wrap up, and this will cover costs of the concept that we've discussed in the various and the session today. And we've got several documents that akamai.com that cover these in a lot more detail.

We've covered off how an identity aware proxy can help you deliver on zero trust, access by enabling and protecting your users, making the access faster, more efficient, and more secure, and how it can protect your assets by implementing least privilege and protect to engage new vulnerabilities. And then lastly, we looked at how we deliver fish proof, MFA and deliver simple, secure, second factor authentication to your users.

We have a blueprint for zero trust architecture where our CTO, Charlie Darrow will walk you through how to design architect plan and deploy zero trust access for your organization. If you only read one document after this session, I really do encourage you to look at this one. You have to scan that QR code on the right, for direct link. So with that many, many thanks for listening. And I look forward to your questions. So let's go back and take a look at our poll results. So have you considered zero trust for your organization? Yes. Three quarters.

And there are some that are unshared, but very few that are saying no. That's interesting. I think it'd be interesting to sort of see what, what type different types of zeros, what are they looking at micro-segmentation or they're looking at how it's useful access, how they're looking at doing from an identity perspective. There's so many ways of doing it. As you mentioned, this is a philosophy and therefore zero trust has many different aspects. I think that the second poll, this one here is interesting is yeah, a very similar number in terms of percentages.

At three quarters of the people think that the pandemic increased adoption of zero trust because it was a, it was a key driver. People realize that, you know, the, the, the old policies of what people were using for remote access in the early days of 2020, which was the VPN and organizations rushed to give their users remote access. And it was basically, here's a blank check from the CEO. Let's go and just expand out the, the VPN. And then that's when you realize, actually this is probably not going to scale.

This is not going to be what we want for the long term, because we can't rely on this as a, as an efficient mechanism to go forward. So we need to look at something that's going to give us the, a competent user authentication that continuous authorization you have to track the sessions, be able to have a lot more control over the, the session. And also when, what happens when we do our to continue with our digital transformation, we've everything out of the cloud. How are we going to manage that without having to put VPNs into more estates? Yeah. Good point.

So let's move on to the questions here. Let's see what we have our first question. If you use fingerprints and possession of phone for access, don't you still need passwords when fingerprint doesn't work, does this put you back to the vulnerabilities of passwords?

You know, that's an excellent point. And that does seem like in most implementations, all the ones that I use. Yeah.

That's, that's exactly what the case is. You know, if you've got a fingerprint enabled on your, on your laptop or your phone, there is the fallback, especially after a reboot where you have to, to enter a password. I guess the ideas in that case is it's more about user convenience than security. I think there are ways that authentication systems can be designed that don't require a fallback to some sort of KBA or password scheme, but rarely have I seen this implemented. So excellent observation.

What, what are your thoughts are injured? No, yeah, I think there's always going to be that element of, or w how do you use fingerprint recognition and also other biometrics, because you also need to take into account inclusivity. You need to make sure that these solutions are suitable for everybody. And there are times when fingerprints are not going to be useful. So do we have to say, we can do fingerprints or we can do Iris recognition. What other biometrics can we use to make sure that all of our employees are, are able to be a part of this and afforded the same level of protection?

Yeah, that's another good point too. I mean, there are certain parts of population that have fingerprints that are very difficult to read.

And then, you know, let's say you construct your authentication scheme, such that you have multiple biometrics that you can use interchangeably based on what maybe the user preferences. So then you say, okay, we'll do facial recognition.

You know, most, a lot of people are carrying phones that can do, you know, face ID or whatever the Android equivalent is. So let's, let's use that.

Well, there's a lot of opportunity for error in that too. You know, sometimes it'll, it takes a few changes to your normal daily appearance to make it not necessarily so that it won't recognize you, but you may have to make several attempts, which then decreases the overall usability. Rarely do we see voice recognition?

I mean, it's, you know, technically in many ways it's just as unique and just as easy to put into place, but a voice recognition is very, very under utilized, I think, as is Iris scanning. You know, Iris scanning is probably from a pure technical perspective, the best biometric to use, but you certainly don't see a lot of people running around taking pictures of their eyes to authenticate these days.

And so, yeah, there's, there's ways that you can sort of chain together, various biometric factors. And then there's also, you know, behavioral biometrics, which, you know, there's a lot of development and innovation in the behavioral biometric space to sort of profile how users use their devices, you know, movement, swipe stroke, and things like that to sort of build a unique profile on a per user basis. So let me move on to another question in light of recent global outages, what risks are there in putting all application access in the hands of one provider?

You know, that's a nice question, too. You know, there were, there were some fairly significant IDP identity provider outages back what I think in December for quite a long period of time and this affected not only, you know, individuals, consumers, but businesses that relied upon that identity provider. And then they have, you know, another outage like within 48 hours, you know, I'll, I'll turn this over to you in a second, Richard, but you know, there there's a need for a multicloud, let's call it identic IDAs.

And there are some things in development by some vendors, but yeah, I think this question had points out the fact that, you know, big global outages can take out authentication authorization and general identity services. If you're relying on a single provider. What are your thoughts on that?

Yeah, I, I think what we have to realize is that when you're moving to the cloud, you still have the same availability concerns. They're obviously significantly reduced because the availability levels that you can normally get in the cloud are significantly higher than what you can expect to do on prem, unless you sort of spend spending an awful lot of money on, on redundancy and business continuity tools. And so I think that the, the certain element of, you know, what if, what is your uptime aspirations, where do you want to be?

And therefore, what options can you do to, to mitigate against that? I think there's also a point of, of looking at the, the, that you're using and, and working out what level of guarantees that they can provide in terms of uptime, availability, and uptime awareness, you know, they get, do they go, oh, they're going to give you a, a, an SLA to uptime. Are they going to be able to provide assurances based upon availability or geo availability or something like that, should something happen? What is the fail over options? And then you can judge your risk accordingly. Yeah. Excellent point.

Next question. How do you position MFA on a phone where users don't have company provided devices? So that's, I think that's quite an interesting one because I think it depends on the country you're in, I think a lot of countries, depending upon how, whether a mobile phone is provided by the organization, or also your attitude to using your mobile phone for authentication. I know a lot of places in Europe, I've been using multifactor authentication on their mobile phones for access to the bank accounts, for example.

And so this is not uncommon, whereas I know in the U S that MFA for, for banks is slightly less used. However, in Europe, there's also an increasing focus on privacy. And there's also the focus about whether organizations and particularly privacy focused countries want to have users using the mobile phones, their own mobile phones, even for things like SMS OTP checks.

And in those situations, I think commonly what businesses have done is they said they could, they could, they've done a combination of using the, the hard-coded authentically, the hardware authenticators alongside the mobile phone authenticators, and may let the users make their choice. And you tend to find that a lot of the time users, when they get sick of forgetting or losing the hardware authentication, they'll say, okay, well, yeah, okay. The mobile phone one actually works well, and everybody else in the company seems to be happy with it.

So there's the, does seem to be a push towards that, but you can have organizations and deployments, which can have mobile phones and hardware authenticators, and, and there's no, there's no change in the risk posture because get the, the hardware tokens are Fido two compliant as well. Yep.

Well, so I think we'll take one more question or, you know, the top of the hour. So do you think passwordless authentication will start to become more widely accepted? I think it's, it's pretty widely accepted.

It's just, it's not always available, especially on consumer facing sites. I've, you know, I would welcome that. I think most users, what, as long as you get the balance, right, between increased authentication assurance and security and convenience for the end user. And I think, you know, you were talking about Fido too. I think that there are options there that will make this a lot more palatable to larger user populations. Absolutely.

I thought, I think the, once we, I know that there's a, especially with consumer applications is becoming more popular and it can be easily developed, delivered in a consumer environment. Obviously there's a lot more constraints within a business environment, but I, they, the possibility to do passwordless is there, and we know the risks associated with having passwords, as you pointed out before the huge amounts of breaches that are associated to leak passwords.

So if we can move away from that gaping hole that you can drive a truck through, then I think it will be adopted pretty, pretty quickly. We'll do that one last quick and pretty easy to answer question, I'll take it is mobile phone identification based on the, I MBI number, answer to that is in many cases, it is to an extent, but it's certainly not the only device identifier, many authentication systems will, you know, place, you know, cookies, certificates, all sorts of different things on a device itself. And in some cases, identity providers don't have access to the IMEA number.

So in those cases, it's not part of the device identification at all. You know, it depends on either being able to read that number, you know, with your SDK or getting the information from the mobile network operator. So quick answer. Sometimes it can be part of it, but it's not necessarily part of the overall mobile device identifier. And with that, I'd like to thank Richard for being with us on the webinar today. Thank all of our attendees. We will have the recording and slides available later, and thanks for your participation in the polls and have a good rest of your day.

Thank you very much.

Like this?

Don't like this?

Why don't you like this?

Technological Approaches to a Zero Trust Security Model