 Hello, everyone, and welcome to our regular Insight IBM Research YouTube series. I'm Katja Moskvich, the head of comms at IBM Research Europe. And as usual, I'm here in our Zurich lab in Switzerland. And today we're going to have a bit of a different chat. I know lately we've been quite often talking about quantum computing and quantum is obviously very exciting and I'm still here next to our also model of a quantum computer. But today we're going to be talking about something just as important, it's security. And as we all know, of course, security, you know, doesn't matter if it's offline or online is crucial, right? For our world. So here at IBM, we've got many, many security researchers working in different labs. And before I actually introduce you to our amazing presenters today, I'd like to remind you all to please actively use the chat in YouTube as usual and send us your questions because behind the scenes here, we've got experts in the chat who will answer your questions in real time. Some of the questions we will also answer live during the show. So let's go to our presenters. We've got joining us today, Mark Stocklin who heads security research at IBM Research Europe. We've also got Ian Muloy, department head security research at the IBM TJ Watson Research Center. Then we've got Srinni, and I apologize in advance if I mispronounce your last name, Srinni Tumalapenta. I hope I got it right, CTODE IBM Security Services. And finally, later we will have Yuval Lapidot joining us as well, but you will not see him on screen just yet. So I will introduce him properly a little bit later. Welcome, everyone. Great, great to see you guys. And oh, yes, and we will have another researcher also joining us for the second part of the show because the show is not only on cybersecurity managing threat, but also on protecting yourself, like choosing the best password to protect yourself online. And that's going to be Julia Hesse. She's going to join us a tiny bit later. But for now, let's talk about cyber threats. So, Mark, first question for you. Can you tell us what's actually the role of AI in security in general? Yeah, thank you, Cathy, for the very first question. First of all, good morning, good afternoon, good evening, depending on where you're located in the world. Actually, I want to start saying something that probably all of us know that security is a cat and mouse game. And that means that we as defenders need to be always awake, regardless of where we are in the world, and need to understand how the threat landscape changes, new technologies, new attacks. Cyber criminals are typically the first ones to pick those up and leverage these threats and exploit them. And this is why we at IBM Research Security are really looking always ahead and trying to be vigilant, constantly looking for new threat vectors and how technology can affect us and can affect the security and the posture of organizations, of companies, of individuals. Now, Cathy, I really to connect directly to your question about AI and security, I think it's fair to say that over the last decade, AI technologies have become extremely powerful, also very much available, right? Open source of lots of technologies that are regularly available as libraries for people to use and also very widely adopted by many organizations. And this has a lot of benefits, but also comes with a number of challenges that we need to be aware. Like in the past, when we had new technologies that were introduced, think of web technologies or cloud or mobile, attackers have also leveraged those and have also played some malicious games around this and have used these technologies to attack us. And AI here is really no different. It is really just a technology and it uses our manifold. And I would like to quickly talk about two duels that we see, duels in the sense that attackers, and this is some things we've seen over the last recent years, have been using AI quite a bit to also boost their attacks, right, to use AI to strengthen their attacks, to harden their attacks and automate some of their attacks. On the flip side, right, what we also see, and this is a domain that is very active and we're researching very actively on and we'll talk more about this, we can use AI also to boost and improve our defenses and to automate our defenses, our detectors, et cetera, et cetera. The second duel, and we'll also quickly touch hopefully later on this webinar on this, is the use of AI itself has been very much adopted widely in many industries. AI, like I said, is a technology and is also prone to attack of vulnerability like our technology. This is what is called adversarial AIs, that attackers can attack AI. And we look into also how we can counter this adversarial AI and strengthen AI itself. So in short, right, I think very promising where we believe is AI technologies to help detection. The first part I was talking about and how we can also respond to cyber threats quickly thanks to AI technologies in threat management. Cool, thank you Mark, I liked the slide. Well, it's gone now, but I hope everybody noticed the little guy here, there in the hat. So I guess that's the typical image of a cyber criminal now. But I don't think all of them would wear hats, but you know, cool. Well, so a question for you, Srinni. You're part of MSS responsible for a platform of our IBM's managed security services business. So in other words, helping many IBM clients to detect and respond to cyber threats as a service, of course. So could you tell us what are the main challenges that the MSS team of security analysts is actually dealing with today like in your daily operations, so to speak? Great, thanks Katya. So before addressing the question, just to give a brief background about IBM managed security services, we are a security service entity within IBM. We support multi-thousand clients covering the globe and all these are multinational clients having operations in multiple parts of the world. So we provide threat management, monitoring response to all these clients. By virtue of us enabling all the security and monitoring the security technologies, we collect about 60 to 70 billion logs. We have visibility to 60 to 70 billion logs per day. That's the magnitude we have. We have visibility to multi-vendor technologies, be it network, data, applications, identity devices. We have access to multiple vendor technologies. First and foremost, our biggest challenge was to harvest the data, to get the value out of that data. So first and foremost, the collaboration happened from there. So we have a partner with Mark and Ian very closely along with other team members. We got the members from research to get access to that data in a secured fashion, in a secure territory because we got to abide by all the regulations and compliance needs. So the data will not go out, but the members will come into the data in a secured zone and harvest the data. So that's the first thing we had to overcome as a channel. To address your point about what are the challenges that are faced by the analyst community, by the internal team members, it's about alerts. It's about alert volume, okay? In terms of the, if you take the holistic approach of how an analyst processes these things, they look at low value and they look at high value. A low value alert is about something that is not of any importance for us to take a mitigation, a protection on that. It is noise, it is generated out of informational alerts or some internal activity. So, and the client previously have asked us not to escalate on that, but to close on those things. So that's the low value alerts. It's repeatable repeated tasks that the analysts would go back and close it anyway, right? Not escalated to the client. And there are some high value alerts that the analyst has to look into it, spend more time, investigate, and then provide necessary classification, notification to the client and provide recommendations to the client, right? So what has happened, what we heard from the analyst is, it's about how they process the data, how they process these alerts. They spend five minutes to triage an alert, for example. Not every alert takes five minutes, but as an example, right? They have to spend that first five minutes to alert, no, look at the low value alerts as well as the high value alerts. It's not productive use of their time looking at the low value alerts. So what we have done as a means of applying AI ML, now listening to the analysts is to apply the system, the ML AI system as an analyst. It's an analyst by itself. The system now becomes an analyst. Look through that, all those alerts, classify them into low value and high value. Learn from the past behavior of the analysts. They went and looked at these alerts and they closed it. They associated that alert to an existing investigation that is already underway. They ordered to say, let's automatically notify the client on this particular thing. So we looked at that and parsed it and applied AI ML to that and then provided the benefit back to the analyst. Now the analyst doesn't have to look at those low value alerts, they focus on the high value alerts, spend more time on the high value alerts, okay? What is the bottom line for us? The bottom line here is we got to be fast. We got to detect those things faster, respond to those activities faster, provide very, very specific recommendations of mitigations. So that's one from a client outcome standpoint. Second thing from an analyst standpoint is about that alert fatigue. It's about their job satisfaction, okay? The job satisfaction is about our analysts say that there's a good day for them at the office is when they look at something, they look at it as something happening, an attack happening or some activity happening with the client at the client environment, notify the client about that. That's the value they provide to the client. They feel happy when they do that every single day. So about the quality of experience for the analyst, the quality of experience for the client as well. That's where the problems are enhancing and improving the quality. Thereby, that's where we focus on the analyst. Okay, cool. Thanks for that, Trini. So moving on, Ian, I've got a question for you as well. So could you tell us how AI technologies can actually help security operations teams to address difficult, so-called pain points? Sure, easily, Kadi. So there are many different areas in which we can actually apply different AI technologies to some of these challenges we've seen security. One of them is on feature extraction, this continuous machine learning. Having machines that would look at the data that we talked about would automatically be able to adjudicate them, come up with different features that are important discriminatory. Instead of having the analysts come up with custom crafted rules for a specific environment, we can have the machines actually get us, look at outliers, look at anomalies, things along those lines. One of the other big areas that we actually see AI technologies applying to security is on natural language processing. We use this for threat management, for looking at different threat feeds, vulnerability reports, texts on past breaches. So all these different analysts that might be employed who are going through doing these investigations, they'll leave notes. And they're easily notes for another human to understand say, oh, this was not a real alert, or this was not a high priority for the following reasons. And if we can actually have the machine understand that, make men learn and adapt and apply that to new threats as well. One of the other main areas is on this reasoning. So Trini talked a little bit about a threat comes in. What do we wanna do? Do we want to alert on this? Do we wanna suppress it and so on? And again, we can have different machine learning models that would learn and adapt from this, but then also be able to say, well, what was potentially the next step that an attacker might take? What should I look at now? What was potentially the root cause? And really we can start pulling all this information in automatically to start reasoning about the threats, what we have to look at, what we have to be worried about, so that when we actually provide that to an analyst, it's all done, it's there, it's automated, but we can actually come up with some recommendations about what to potentially do. And this kind of hits upon the fourth main topic, which is on automation. Having machines do what machines are really good at, pulling information, doing correlations, automatically executing some mundane routine tasks that the analysts don't actually have to do it. So really it's about making them more efficient throughout the entire pipeline. Right, yeah, thanks for that, Ian. Indeed, I would imagine that this manual work by analysts should be probably really time consuming. So what do you guys think, Mark? Maybe you could tell us what you guys are working on here at IBM to actually help security analysts to cut down a bit on this manual work and speed up their ability to respond to cyber attacks. Yeah, indeed, look, it connects very well to what Srinia was mentioning before about the fatigue and Ian mentioned the same, right? There's a lot of mundane repetitive tasks and we sat down over the last few years with the teams at security services, tried to understand, okay, how do they work? What are their procedures, their playbooks when they investigate a cyber incident? And we learned quite a few things, right? And they can, the findings and their approach can be summarized as follows. So first of all, when they have a new alert that they receive, they are going to investigate basically the threat intelligence. So try to understand what does the world know about this? There are maybe IP addresses or their files are being used or certain behaviors and they do some threat research around this and use different data sources. Secondly, they look into additional local data sources, right? EDR, data lakes, logs, and try to correlate these with the past. Maybe this alert is not just in isolation but maybe something's happened before. So they have some investigation strategies. Threat hunting is another typical word that can be used in that context to investigate the attack more, identify use root causes and maybe understand the impact extent. At the end, the goal is like Trini said, to identify, do I care about it? Do I escalate it? Do I need to remediate or can I close it? Is it perhaps a false alarm? And there are in reality a lot of false alarms that these detectors generate and cause a lot of noise. Now, what we have done, and this is really, I think where we are focusing on improving the situation is to systematize the approach, right? First of all, we researched on different types of tools and methods to automate the investigation and analysis of cyber events, meaning that we're trying to systematize both the threat intelligence. So you have heard Ian said, we're using natural language processing to extract information, to curate the information and to put it into graphs that we can reason over them. And secondly also to systematize the procedures, the approaches, how we reason over incidents and how we connected to worlds to automate and provide recommendations or even to automatically close some of these alerts very quickly because we realize they are similar to some of them that we've seen in the past. And in other cases, we still hand them over to the analysts and say, look, this is an enriched version of what you have normally received, but we have taken or the machine has done some work for you on your behalf. And this now you can decide and you can use your expertise, your human expertise to connect the dots if the machine cannot do so automatically. Right. Cool, okay. And I think if I remember correctly a few days ago, you have released actually a new tool, right, XDR Connect. So would that help with threat management? Srinu, what's your view? Absolutely, no, XDR stands for extended detection and response. So the part that we've talked about till now and Ian was showing that graphic where the automation part is on the right side. So the ML AI and the human analysts augmented, AI ML augmenting the human analysts there, that will help with the detection. So it's about IBM believes in open. The other industry players are more about their products. So they built in this XDR extended detection response with their portfolio, but IBM will bring in all third party vendors, IBM along with IBM products and technologies into this XDR ecosystem, process the data. We apply that AI ML plus our analysts working on the investigations and actually ML also helping with the investigation. That's the detection part of it. And the response part of it is all these things are also helping us to provide that recommendation to go take some action, right? In some cases, we can now enable through our SOAR platform. So a response orchestration platform, we can also enable the automated response. So on a EDR technology, on a network technology or a identity technology, we can go put that policy to protect the environment. So that's the response part of it. So the combination of what we have talked about Ian and Mark talked about till now actually is being incorporated into the XDR strategy. Okay, okay, cool. So thank you for that, Shrini. Ian, a question for you. So we talked a bit about the security of AI itself earlier, right? So in this case, when AI is protecting systems, say, you know, some maybe critical infrastructure, maybe a power plant. So would criminals be able to infiltrate the AI itself and what can be done for that not to happen? Yeah, that's a great question. So Mark previously mentioned this notion of these two duels where we have adversaries both using AI and then attacking AI as well. And that's exactly what we end up seeing going all the way back to some of the initial uses of machine learning for doing, you know, host-based intrusion detection right then and there, people started looking at this and saying, hey, we can attack the AI system itself. So there are effectively four main threats that we actually look at when we talk about an AI system and adversaries can go at any one of them in order to meet their end goals. And it all really depends on what level of access the adversary has to your machine learning models, your infrastructure, your data collection, labeling system and so on. And so one of the first ones we might look at is what we call evasion. And so this is a case where you have a well-trained AI system. They didn't have any control over the training data, the training process or anything on those lines. But what they can do is they can submit queries or they can submit inputs to your system. And this could be a piece of malware going to your malware detector. And they can craft in such a way that a very, very small and perceptible change would actually cause it to come up with any different classification. So in a visual recognition sense, we like to talk about this as a panda bear versus a given or a cat guacamole and stop sign and speed limit. But the exact same threats apply to any machine learning model and security detectors are no different. So we're making some rather small changes we can completely evade the detection and these detectors that we can rely on would no longer fire a trigger. Now it becomes even more damaging when the attacker actually has control over that training data itself. And this could be done what we call poisoning where they can actually manipulate the training data or the labels. But when you have a system where the adversary has, there's submitting jobs or submitting queries and you have this constant learning of what is normal, for example. They obviously can kind of cause that to the model to drift and cause the model to start to classify their benign behavior as being, they're sorry, their malicious behavior is being completely benign. Another potential threat is what we call extraction. So just simply by submitting queries to an animal and looking at the responses they get back. An adversary can actually completely create their own kind of surrogate model. Sometimes exactly replicating other times this has comparable in the area. And you can use this to steal intellectual property but you can also use this to then have a standing model. The adversary can attack that and then apply it to your own system when we call it a transfer attack. So even if someone doesn't have control over the exact detectors in your end system by kind of observing some of these behaviors as we aside channels, they can then use that knowledge, hone their attacks and then be able to launch them in your system. And then the final one is just what we call an inference attack. And this is where the adversary can learn potentially something about the training data again by observing the input and output. And usually we look at this as having a threat to the privacy of the system itself, learning something about either the population or a particular entity there. So all of these are something that adversaries are realizing. They see AI has a lot of value instead of honing the threats on that. Okay, cool, got it. Yeah, very interesting. Thanks for that, Ian. So Srinu, back to you now. And I'd like to ask you actually about the practice at IBM security and the kind of day-to-day reality when you guys have to manage the security of IBM clients. How do you actually work together with IBM research and how do you use research for services and for products? That's a great question. As the opening, we talked about getting the team access to the data. That was never over. We act as one team among ourselves, right? So the team has access to the data. The research team has helped and is now actually helping and we are incubating a lot of ideas. We talked about that system being an analyst, right? So that's one component that the team is working on where we'll generate hypothesis, we'll generate provenance. Now what has happened in the future? Can this happen in the past? No, what has happened in the past and can this happen in the future? How do you project all things? The alert dispositioning, right? Is this, should this be closed? Should this be alerted? What is the reasoning behind it? So there is activity happening in there. And the second part of it is helping the user, the analyst with certain tools for investigation purposes. That's a threat investigator that is happening where they'll be provided with Mitre-Tac mapping, additional reasoning behind it, all the curation of the telemetry and the information required from Intel sources in one single pane of glass. So they don't have to go search for that information, providing additional information through the hypothesis generation and the provenance tracking, providing that information for hunting purposes. All of those things are part of our triage and investigation methodologies. So that's where the threat investigator comes into picture and research team has been helping on that. And then we also have the hunting language that the team has developed which is now part of our portfolio as well. So all these assets combined are what is helping us to move our security services practice as well as our product portfolio to the next phase. Great. So this threat investigator, a great name by the way. Yeah, so it's recently been made available, which is great. And if I'm not mistaken, it's part of the latest release of CloudPak for security, right? Yes, it is part of CloudPak. And next year, Connect. Okay, great. So I think you guys were gonna show us a demo, right? To kind of demonstrate how it actually works. And I believe this is when it will be great to welcome your colleague here to the show. Let me introduce our security researcher, Yuval Lapidot, Haival. And you're joining us from Haifa. And I believe you have a quick video to show us, right? Thank you very much, Katia. I will show my screen with you. So, hello everyone. I'm Yuval, a security researcher with Haifa Research Labs. And I'm happy to show you today a quick demo of the threat investigator. The threat investigator is an automatic service that leverages AI capabilities to perform security investigations. And it's part of the cases component, which takes a major part in the IBM XDR offering, as mentioned before. Investigator performs an automatic security investigation of cases that are open in XDR. It correlates between various event data sources, such as firewall, EVR, SIEM, for example, IBM's QRIDAR SIEM, network traffic analysis, antiviruses, et cetera. And it enriches the data using different knowledge bases, such as MITRE ATTEC, which is a very well-known framework in security and threat intelligence sources, for example, EXPOS. An investigator connects all the dots together to create a coherent attack story. In today's demo, we will show an investigation of the Fint 7 scenario. In this scenario, an attacker sends a phishing mail with an attachment, the file invoice.doc to an employee. The unsuspected employee opens the phishing attachment with MS Word and runs a macro. The macro extracts an encrypted script from the Word document and sets a scheduled task to execute that script. The script later calls home to the attacker's command and control server. Through an HTTP, it receives further instructions. It then collects information about the victim, such as process dumps and screenshots, and sends them back into the command and control server of the attacker. Let me now go to the Analyst Desktop where you can see the results of the analysis they automatically performed by the threat investigator. So here you can see the general tab, the general view of the analysis, where we can actually see the information about all the information we needed about the analysis. So we can start by saying the case it's connected to, it has an ID and the owner and the date it was created, and also a severity assigned by the investigator itself. Later, we can see some details about the investigation. For example, how many artifacts was in the trigger of the investigations, how many MITRE tactics were found in the investigation, how many findings were found, and how many assets were involved. Later, we can delve deeper into the MITRE tactics that we'll find within the investigation, and you can see their severity in this investigation. Later, we can see a network graph which lists the assets participating in the attack and the connection between them. In the right panel, we can see a timeline, a human readable timeline, that can show all the events and findings that were found as part of the attack. Let's scroll now through this timeline to see what the investigation found for the SPIN7 attack scenario. So the first finding that we can see that was here, a grade, it's a process created event that was created and a threat intelligence system. Let us know that the hash that was opened is malicious. So we can see here the hash, and once we click on it, we can see that the threat investigated that found it is X for exchange, and it classified it as a virus. By further looking into this event, we can see more details about the event. We can see that it's a process created event. We can see on which domain did it happen. We can see more process information, like it's PAD, it's name, and then even about this parent process, we can find some information, and we can see from which data source we received this event. In this case, we received it from a curator data source, which is the IBM SIM. Finally, we can see the raw data of the event, which is represented in this piece. Okay. Just a second. Later, we can see some more events and some more findings that we'll find. In this case, another finding is the finding that was correlated with mitre attack technique. In this case, the technique is a suspicious sketch of dust. And as you remember in the scenario, we know that the virus actually creates a suspicious scheduled task and uses it to run the code. Here, we can also see some more information. We can see that the data source collected this event comes from actually a different data source from MS Defender. And also we can see the raw event. Furthermore, we can see more events and more findings. For example, we can see a firewall accept an event that comes from the firewall, which was enriched with threat investigation. Sorry, threat information, saying that this IP is also suspected or malicious. We can see more and more findings and all is concentrated in one single panel. Next, we can also see the attack graph in a different view. We can see it in a swim lane. And we can also see all the mitre techniques and tactics that were found as part of the attack. Having all this information in one page correlated and enriched and having the ability to view all the events and alerts in an organized timeline can save hours of manual labor. This is why the investigator service is a great example of how AI-based systems can improve the work of security analysts. Okay, wonderful. Thanks, Yuval. That's definitely a great asset for security analysts for sure. Thanks for that. So now that we've learned a lot about threat management and then AI and security, how about we switch topics a bit and I'd like to invite our last speaker to join us. Julia Hesse, security researcher here at IBM Research Europe in Zurich. Hi. Hi, Katja. Hi, so I know you're gonna be talking about passwords and password security. So tell us, what's actually the problem with passwords? I mean, everybody, of course, knows by now they shouldn't put, you know, 000 or their birthday or their, I don't know, pet name as a password. So aren't people already quite aware that they should use a capital letter and a number and a symbol and how can they make their passwords even more secure than that? Yeah, I mean, I hope everybody is aware of that by now. And indeed that would be very secure passwords. But I mean, in my case, the last time I checked I had something like 36, 37 accounts that I was protecting with a password. So for me, it's really, I mean, it's really the question, if I wanted to choose my passwords in the way that you just described, how do I manage to memorize them, right? And I mean, there are certainly some tricks that you can apply for me. What works best, for example, is that I don't remember or memorize the specific characters of the password, but I remember a sentence. And then I use, you know, like the first or first and second letter of each word as a password, right? So a sentence is way easier to memorize than a chain of characters. That's one way to simplify the task of memorizing all passwords. What is also very commonly used is that you kind of use the same passwords for several accounts, right? So there was some statistics of last year or two years ago. The average password on the internet is used four times, right? So in my case, that would reduce my task of memorizing 36 passwords to memorizing only nine passwords. Still quite challenging for me, right? So yeah, so essentially password reuse is a big problem with password security. Right, yeah, no, that's for sure. So, you know, how, like, yeah, actually before, before we even jump to the next question, just something that I would like to ask people here in the broadcasting studio with me. So you guys are all security researchers, right? So I suppose your passwords probably very secure. So maybe Mark, you can tell us, do you have any tricks before Yulia tells us about her research? Thank you for picking on me for this. Well, you know, password is a challenge, obviously. I try to keep one password per one account, not to have shared passwords in the first place, also adding complexity when needed and as much as possible change it. But then, of course, there's the challenging, the challenge out there for managing this. So generally speaking, I use password manager trying to help me assisting me with that, but it is still a challenge to be frank. Okay, well, maybe Yulia will tell us now about her latest research and how to make it even better and how to create even more secure passwords. Yulia, over to you. Yeah, thanks. So let me first show you with a small slide. What the actual problem is with passwords and the internet today. So assume that I want to have a look at my email. So I log in, I wanna log into my email providers to the website of my email provider, right? So the browser will show me a prompt for my password, right? And I type it in, I hit okay. And then essentially what is going to happen is that my password is transferred to my email provider in the clear over this green channel, which essentially means that it's protected from the eyes of any observers, right? So this is called a secure communication channel. I can be assured that only the recipient in this case email provider can read my password, okay? So what is happening at the email provider? Obviously at some point I registered and I chose a password and the email provider stores some form of this password. It's called an encoding of the password or for people who know it, it's a hash of the password. And the provider is going to redo this encoding procedure with the password that I'm sending for login and essentially checks whether this is equal or not to the encoding that is stored and then grants me access or deny success to my emails, right? So this is essentially, it's called password over TLS and it's essentially how the internet works today with passwords. So it's clear text sending of my password to the provider who is supposed to verify the password. And this is okay, this would be no problem if we were not reusing passwords because now what can happen is that my email provider actually impersonates me using this password that it just learned upon login. For example, to access my cloud data for which I use the same password, right? So this is a, well, I mean, usually I would say I trust my email provider but you have to take into account that these are large companies. So by trusting your email provider you're essentially trusting the hardware that your email provider bought. You're trusting the software that your email provider is running, you're trusting every single employee, right? And that's a lot of trust. Okay, so essentially, yeah, the clear text sending or like telling the password in the clear upon login is essentially the big problem that we are facing. Okay, well, yeah, it really doesn't sound too great. And so are you saying that your research is actually about preventing, avoiding such digital identities theft? Exactly, so well, I mean, it's obvious that we cannot really force users to not reuse their passwords. Not everyone is as strict as Mark probably. I have to admit that also I reuse some passwords even though I shouldn't, or I should know better. But so the research question here is really can we somehow have the provider verify that we know the passwords without actually telling them to the provider, right? And in cryptography, we have a very neat technology which is called a zero knowledge proof system. This is pretty, it's not a new thing. It has been around for, well, I would say 30, 40 years. And it's essentially a way to prove that I know a solution to let's say a riddle without actually revealing the solution. So the only thing that I'm revealing is whether I know the solution or not, right? Does it sound magic? Sure. You wanna see an example? Why not? You wanna do a zero knowledge proof? Let's try. Okay, so I have a challenge for you. So this is a worst walley picture, right? I guess everybody knows it. I know the solution, so I know where a walley is. Do you believe me? Okay, sure. You should say no, because otherwise there would be no point in doing a zero knowledge proof now. Okay, no, I don't believe you at all. Thank you. Okay, so the point is what I wanna do now. I wanna reveal to you only essentially that I know the solution. I don't wanna reveal the solution itself. So I don't wanna point at the picture and show you where a walley is. Because for example, I would like to enjoy the experience of searching and finding him yourself, right? So what I could do, so I have here a, this is not going to be a magic trick, by the way, there's no magic happening here. So this is a cardboard, right? And I have cut a kind of walley-shaped hole in the middle here. So now the zero knowledge proof for this riddle works as follows. So I have the cardboard here. I have the picture here. I'm going to put the picture behind the cardboard. Again, no magic happening here. So I'm going to put it in a way that you cannot really see where I put it. And then, can you see him? Sorry, I don't really know. Yes, yes, I think I'm very low. Okay, so, and it was, oopsie, it was actually, so it was that picture, right? Okay, so what did you learn? Not much. But do you believe me now that I knew where he was in the picture? Yeah. Okay, so congratulations. You just verified your first zero knowledge proof. Wow, okay, well, that's really cool. And before you were saying that such proofs also exist for verifying passwords, well, it would be great to use that technique for my accounts for sure. So could you tell us how to do that? Yeah, so the good news is that these zero knowledge proofs, they don't only exist for, let's say, a bit useless things like a versus Wally, but they exist also for password verification. These are also not very new. They also have been around for 10, 20 years. And they're very, very efficient, okay? And so I also wanna use them. The thing is that we cannot really do anything, right? Because our interface to password verification at, for example, or my interface to my email provider is the browser where I get shown a password prompt, right? And it's really the underlying protocol that needs to implement zero knowledge proof instead of this, you know, what I showed you before, this clear text sending, right? So it's really not us who have to, who can change anything. It's really organizations such as the internet engineering task force, which have to first standardize these protocols, right? So that afterwards after the standardization, they can get adopted by the browser and by the service provider. And it's always, you know, both sides have to be able to run the protocol. So you could say, okay, this is kind of like, like for example, in TLS, which we usually use, this is transport layer security, this padlock which shows in the browser, which you usually use for implementing these secure channels that I was showing before. You have this very secure option and then you have like fallbacks to less secure. To less secure options. So optimally, we would have like a first option, the zero knowledge proof. And then as a fallback, we could still do the clear text sending which everybody is doing today on the internet. So currently, we are pretty far along with the standardization process. And by we, I mean, essentially the internet engineering task force, it's not only IBM who drives this, there's many, many other people, but we are pretty active there. And yeah, so afterwards, I really, really hope to see adoption by providers and by also the browsers. Because in essence, this is also useful for providers because they do not risk losing the passwords of their users, which is really something that they don't want to do, right? They don't want to put their users security at stake. So also providers should be very, very interested in deploying these strongly secure password verification protocols. Yeah, for sure. Yeah, thanks for that, Yulia. So I'd like to ask Srinni here, what do you think about what Yulia just described in terms of standardization specifically? So in terms of standardization, it's around people process technologies. Gotta have repeatable patterns, repeatable standards, now based on standards, open standards, that will help us to integrate this with the wider ecosystem of our third party vendors. So IBM has been working and research has been helping us with the open cybersecurity alliance. So defining the standards there and getting that adopted by multiple other partners will help us. So we don't have to go define this multiple times and try to adapt this multiple times. So that's what is the important part. For service providers like us, it's very, very important because we operate like with 30 different vendor technologies when a product. So standardization is very, very important. Cool, great. Thanks for that. So in the last few minutes here, just one more question. What about the massive security breaches that do happen from time to time? We read about them in the news where millions of passwords are suddenly leaked and when servers get hacked, for example, Ian, what do you think? What can we do about those? So did you wanna ask me or Julia about this? No, well, I mean, what's your view and then we can go to Julia. So when it comes to these massive password breaches, some of the times when the things we end up learning are some of the different processes and procedures and protocols that the different endpoints or the different organizations are using. Are they strictly storing passwords in the clear where they can be leaked? Are they storing passwords which have been salted in kind of a hash or digest form where it becomes slightly more difficult for them to be recovered or and then there are certain different layers. You know, what types of ciphers are using, how many rounds they performing and so on. But even when there are some of these big breaches and we hear about them all the time where they aren't storing the passwords in the clear, they are storing them, you know, salted and hashed, technology, you know, GPUs, fast accelerators have actually made it more easy, more convenient for people to actually go about and reverse engineer these, come up with very, very fast and efficient ways of actually recovering what those plain text passwords are simply by guessing. So even there, depending upon if the passwords are still weak, it can actually still expose users to some risk if there is a breach. Yeah, can I follow up on this? Thank you. Yeah, exactly. I mean, Ian, there was really a great answer and it's exactly that. I mean, what I was showing you is how we can avoid this handling of clear text passwords upon comparison, right? Or upon verification. There has been like massive security breaches where providers at some point noticed that while they were essentially logging the clear text passwords upon verification accidentally, right? They did not really know why and how that happened, but they found like millions of passwords somewhere in the storage, right? So this is one thing that we will avoid when using these more secure password verification technologies, simply because the provider will not learn anything about the password. So it has no chance to store the password into your text. The other thing that you also mentioned is while we have these, I showed it before on the slide, we have these encodings of the password that the service provider needs to somehow store because it needs some reference data to verify the password against. So this is really, I mean, it's really like a paradox. How would you verify something without actually requiring to store this data, right? And this is a huge problem, as you said. I mean, even though this might be an encoding, so it might not be clear text, but it might be encodings or salted hash, for example, the less secure passwords that you can reverse engineer so you can kind of, or you can simply guess them and this way find out a lot of passwords still. And this particular issue is actually something that the previous solution that I showed is not solving, but this was something that even the European Union got really interested in and they funded a project in their Horizon 2020 program, which is called Olympus. And IBM, in the Zurich lab at IBM Research, we were actively participating in this project and we kind of looked into how to, well, essentially what to do in this kind of paradox situation. What can we still do? And we came up with a very cool solution, which essentially, like on a very high level, what we did is we kind of split up the encoding in not really, you know, like we did not really do chunks because that would not work. We split it up in like a more intelligent way and then we distributed these pieces of information to different servers, right? And then in the password verification, all the servers need to kind of participate. So the verification procedure is a bit more interactive, but the benefit of this is if you have a security breach at one of these servers, the information that is revealed leaks zero information about the passwords, right? So you can have up to, let's say if you use like five servers, you can have up to four of them essentially breached, but the passwords will still remain secure. And by secure, I mean like 100% secure, right? So this is a very cool solution that we deployed in that project. It was a bit oversimplified. So, I mean, there's more technical challenges in that obviously, but I just like the work that we have done in this project and also the interest of the, for example, of the EU to try to find solutions for these problems. This is really motivating to me as a researcher and I really, really hope to see a lot of adoption of these technologies, in particular of the Olympus technology in the future. Oh, yeah, absolutely. Sounds great. Well, I'm afraid we're out of time. So thanks everyone for participating today and a huge thank you to our experts in the chat as well, answering questions, and of course to everybody who joined us today as well. So we'll see you next time. Thank you. Bye, thank you.