Good, good morning. Welcome all. Glad there are still some people in the room. It's Friday, the last day. The real survivors are still here. Thanks for that. Waiting to get the slides and then we can start. Slides will come in a second.
So, as an introduction, my name is Keno Torfs. I'm a cyber security enterprise architect within BASF, taking care for the global domain of identity and access management, deciding what we're doing in BASF.
So, the presentation that I will share with you today is, we will give you a little bit of insight, what we are willing to do inside of BASF, how we translate all the theory that we see here over the past years, the nice fancy things. We try to translate that and we try to implement that in a big enterprise. For those that don't know BASF, BASF is the biggest chemical company working globally.
About 110,000 internal employees active over the globe. So, it brings a lot of nice challenges. It's a lot more difficult than just implementing something quickly, but that's what I would like to show you and how we move on with the journey.
So, as stated, first topic I will show you is, I guess you all know Zero Trust and why we have to implement Zero Trust, but I will give you a quick glance on how we understand that at BASF and what we use as a starting basis for Zero Trust within BASF. Second topic, within Zero Trust, I much more prefer the risk-based approach, and that's where I'm going to explain to you how we translate the Zero Trust in the risk-based approach and then, following on that, the journey that we're on.
So, to start with, what is Zero Trust and how do we see that? Despite advancements in each domain, their lack of integration leaves vulnerabilities unaddressed, weakening the system as a whole. Without integration, as well as central monitoring and orchestration, vulnerabilities persist. It creates cracks in the system, opening the door for threats to exploit and move laterally.
With Zero Trust and AI, integration across all domains enables faster responses, greater transparency, seamless collaboration, single source of truth, and unified decision-making, as well as a resilient security posture in an ever-evolving threat landscape. The transformation ensures that the Zero Trust principles are implemented. It assumes that all users, devices, and applications are inherently untrustworthy and must be verified before being granted access to any resources or data.
Additional layers of protection ensure that even if one layer of security is breached, there are other layers in place to prevent unauthorized access and data loss. And this is CyberShield.
So, CyberShield is a project that we are implementing within VSF across all the different domains that you just have seen. We have seven domains. The one in the middle was identity because it is a core component and an important aspect.
So, then, let's move on to the next topic. How do we translate that Zero Trust mindset towards implementation? And that is where the risk-based approach comes in because Zero Trust, as a paradigm, sounds nice, but you should not protect everything in the same quality because you don't have the resources to do that. You should really focus on what really matters. And then we have to see if we take a step back, what is actually identity and access management? What are we doing? What is the user really doing? What is the user wanting?
The user only wants one thing, access to the application, access to the information. Everything else is just bothering him. Whatever we ask on authentication, on authorization, on processes is hindering.
So, unfortunately, before the user can get access to that application, we are in between and we have to take care of a couple of essential security steps to make sure that we safeguard the intellectual property within the company. It's our goal to make that as transparent as possible, that the user can get as easy as possible access while we keep it secure. In that area, my opinion, we have three areas. We need to know who is doing something with the identity.
We need to validate that the one, the service, the person, the user who is willing to use that identity is actually eligible to use that identity. And as a third step, we need to know what is that user allowed to do?
Read, write, edit. And that is, if you go back a couple years time, that was all more or less in a binary perspective, where either you had access or you did not have access. And we are moving that to a varying level of trust. Varying level of trust, how do we see that?
Again, the same three pillars on the left, access to the application here on the right, the most important topic. And that is where we ask the business application owner to run a PRA, Protection Requirement Analysis, which is an organizational process that we implemented, where the business application owner is running through a questionnaire of questions and with that defining the risk of his application. And this is really the core, because this risk that we define for that application will then derive, define the required mitigations on identity, on authentication, on authorization.
What does that mean? If you're talking about critical information, critical applications, we will put high requirements. If you're talking about public, low-risk information, we'll put low requirements, making it more convenient for the user and easier for the user to access it.
That, as the basis, is the principle that we use in the general journey. If you then take a look at that journey, we're going in a couple of different steps. We started a couple of years ago with setting the risk-based foundation. And if you want to go on such a journey, you need to know, what do we want to do? Where are we today? Where do we want to move to? And that's where we created the risk-based framework. If you want to work on that framework, you have to create that framework. You need to know, what does that mean? You have to describe that.
That's where we got inspired by the NIST 863 Digital Identity Framework. If you don't know it, take a look at it. It's really valuable. We were inspired by that. We did not copy it one-on-one, but we then translated that into our own corporate requirements. We created our own privileged access management framework, how to deal with that. And it was the guideline that the complete company knows how to act in future within the company. If you want to implement this kind of thing, you also need to have a risk engine. You need to have the technical platform.
And that's where we decided a couple of years ago to take a look at Entra ID, because we have a lot of Microsoft stuff running in the company. We need a risk engine close to the IDP. And that's where Entra, for us, made the most sense. Entra is in the cloud. Before we can go to the cloud, we had to do a complete in-depth risk assessment, mitigate all the residual risks, and then we could go live with Entra as an identity as a service.
We initially did this in a federated mode a couple of years ago, where September last year, we switched from the federated mode towards the managed authentication. Together with the managed authentication, we had then the full suite available, risk engine available for all of the users. And this is actually the foundation and the basis that we had. If you take it one step deeper on that federation, how did it look like? A long time ago, we started with one single sign-on federation system. We started with NetAQ Access Manager, where most of our applications were connected to.
Single sign-on, we have a set of authentication methods. That's it. We introduced Microsoft 365. We introduced cloud applications connected to the Microsoft stack. Those applications were connected towards Entra, federated to ADFS on-premise. We needed ADFS because we were also using Windows Hello for Business. Microsoft made it difficult for us. That's why we needed to have ADFS. Based on the decision that we took, we're going in two steps. One step is application migration, migrating everything from NetAQ to Entra. Most applications migrated.
What we have to do right now is the most complex and difficult ones. The federated authentication from ADFS towards Entra was done in September last year, leaving us with the new platform, one Entra ID as a single IDP in the cloud, with one set of authentication methods. That gives us, as the benefits, the full Microsoft security suite that we can use with the conditional access rules, all the defender suites. It gives us that zero-trust platform and all the risk engines. Also important, it gives us the cloud-native authentication options, which are quite useful in the rest of our journey.
Again, basis. Based on that, we took the next step, which is the passwordless journey. I guess all of you know passwords are bad, so you have to get rid of the passwords. That's where, in the first step, we decided no more password-only logins. We still had several applications that had password-only because, in several use cases, people don't have our authenticators. But we made sure that everyone in the company has an MFA factor. We made MFA mandatory overall to get rid of that password, and we're even willing to go a step further to say goodbye to the passwords, also as a second factor.
So, go completely without passwords as any kind of authentication means. That means we're going to a passwordless future.
For that, we need solutions. That's where we are introducing passkeys. We are looking to introduce FAUDO. We have introduced the device-bound passkeys, and then welcome phishing-resistant authenticators. I guess it sounds reasonable for a lot of you, but that's the journey we're on, having good success. But that's also a critical part that we need for the next step, in the authentication assurance level. Authentication assurance level, inspired by NIST, means not every MFA equals to MFA. There is a lot of difference in strength between a FAUDO token, for example, and a TLTP.
That means we need to classify those different levels. If you classify that on paper, it's fine, but that's also where you need to be able to implement it on a platform. That's where Entra comes in for us, with the authentication strengths and the conditional access policies, where the AAL was defined. That's where, September last year, we went live with our AAL concept. We went live for 140,000 users.
About 2,000 applications have been defined through that workflow that I just explained before. Meaning, before September, we had the situation where your application either required basic authentication or multi-factor authentication. Basic authentication in very limited cases. We almost demand, if it's over the internet, always MFA. But that MFA, since September, fell apart in three different classes, where we right now have a weak MFA, a default MFA, and a strong MFA.
So again, depending on the application, if you would like to access our research database, you only get in with a strong MFA factor. If you would like to get access to a simple collaboration database, we can be very substantive. So depending on that risk, again, we decide on what factor is required. Went live last year, September. That's an overview of the different authenticators. We have four different risk scores, EAM risk score 1, 2, 3, 4, corresponding to the AAL from NIST. NIST is calling them AAL 1, 2, 3. We split that in 1, 2A, 2B, and 3. It's not 100% identical.
Very simplified stated, going from 1 to 2A means you add a second factor. Going from 2A to 2B means you need to have a single instance of that authenticator. Going from 2B to 3, you have an end-to-end encryption of your authenticator, and then you end up with the phishing-resistant authenticators. Security is increasing with more going to the right. Convenience, basic authentication, you can use that everywhere. Easy.
So whatever you have to use on MFA is bothering the users, and that's where you also see if you go, for example, for Windows Hello for Business, what we have, or if you go to POSKEYS, they're making that easier again. So we think that also the convenience is increasing while also the security is increasing. Those at the bottom are also the authenticators which are available within BASF to be used in that classification. And that ends the authentication story. This was implemented last year. Then we decided to move on to the next step, which is the next pillar.
Besides authentication, we have the identity. And on identity, we're willing to do the same stuff.
Again, differentiation based on trust within the identity. How do we do that? How do you want to do that? Introduction of remote identity-proofing. If you take a look again, you have the same risk scores again. You have on the left side the identity. If you would like to collaborate, you can do that. If you want to collaborate on a simple collaboration database, any BASF employee can invite somebody they know, a John Doe. They can invite, welcome, collaboration is working.
If, however, you need access to that research database again, we need to have a fully proven identity, which means, yes, you can invite that person. But before we grant authorization, you first have to upgrade your identity with remote identity-proofing. We are currently in the progress of implementing that remote identity-proofing. I guess you all know the principle, but just in short for those that don't know it, you have a quick ID scan. You have a liveliness test. Based on that liveliness test and the scan of the identity, you get verified attributes that will result in verified identity.
Based on that, we will deploy a secure verifiable credential, which can then be used in further process as well. This is the basis to then deploy that verifiable credential, which can be used for authentication, which can be used for other purposes, and which is giving us that assurance for the identity. We don't stop there. If you think even further towards the future, we are looking at the decentralized identity. Taking a look at decentralized identity, that means why should we duplicate identities if you already are existing?
There's only one k-notorious real person, so why do we need multiple digital identities? It's a critical factor that we state within the company. There shall only be one digital identity, but why do we have to accept that across the ecosystems? That's where we would like to reuse existing IDs. That's what we're going to investigate, how we can do that, where we would like to build trust chains to see which kind of identities can we reuse. You see there in the middle also reuse existing identities. You see LinkedIn, Facebook. Are we going to trust Facebook as a secure identity? Probably not.
If you come in for a low risk, possible. If you come in for a high risk, no, we will not accept this. We will have to build up the trust chain. If you think about a governmental identity, we can trust that.
Facebook, probably not. That means we're going to build up trust networks which end up in trust factories, which at the end can bring us to the idea of a self-sovereign identity, where at the end the user is in charge of his identity. Is all of that possible? How can we proceed with that?
Yes, honestly said, I think that all is realizable. And if you go a couple years back, if you take a look at the COVID case, which I think was quite interesting, at a certain point in time we needed to close everything. Events were closed, gyms were closed, travel was banned. It was a complete lockdown. You were not allowed to go anywhere. Authorization taken away. A few times, a couple times later, the disease got under control and then the question is, how do we grant authorization again to those people?
Imagine that you would have to go through the same process as you're requesting SAP access to request access to go to the Greek restaurant with your family. I guess a lot of those restaurants would have been bankrupt. So what happened, at least within Europe, there was something which was called the COVID app, which is actually some kind of a digital wallet, which is having a digital identity, which is having several attributes. You went with that application to the event you wanted to go to.
On the fly, they checked your digital identity, they checked your attributes, and on the fly, that COVID wallet gave you access into the event, the store, the travel, all of that was possible again. Access was not granted per target, but it was done based on those attributes that were issued before. No pre-administration was needed in advance, which is quite interesting here.
And that is, if we translate that in our vision, that's where our vision for the future would be, that we have people having such a wallet, having identity, having a lot of attributes, which can then define what kind of authorizations you can get on a lot of your applications. And I put here the enterprise applications.
Of course, we have to start with simple applications, but the longer we proceed, we should go in that direction. That's the story. Thanks a lot for your attention. If you have questions, please. Thank you so much for the insight. There are a couple of questions in the chat, but I cannot take all of them.
So, I will take one, and I would encourage you to reach out to Kino afterwards and raise the questions. And one question is, in BISF, how do you manage deviations from the desired state when it is not possible to fix them quickly? Maybe a quick answer to that, if that's possible. Deviation from the desired states? Which deviation from the desired states? The business application owner is responsible for the PRA, setting the requirement assessment, is responsible for setting the security on that. At the end, the business is responsible for that.
If they cannot reach that level, we have an exception procedure where the business application owner can request for that exception, but then they have to carry on the risk for that. They have to run through the process. All right. Thank you so much. Thanks for your time. Thank you.
