 Thank you. Thank you for the introduction, Mike, and this is a really good introduction. It saves me time because I even removed the slide about me from the presentation, and I'll just directly jump to the contents. So today we're going to be talking about sharing cyber threat intelligence. First, an intro, what is cyber threat intelligence? You probably know, you might think you know, but hopefully you'll learn a bit more. What are the challenges of sharing CTI, or short for cyber threat intelligence, and then one example. And the examples that I'll be providing here in the use case, it's based on true stories, so to say, but of course many details are abstracted away. And so first we're going to talk about a kind of naive example, naive but still very useful of sharing CTI with confidential computing. And then another example, which is more work in progress, but also has very concrete applications about more privacy preserving aspects of sharing CTI. And then of course some thoughts about the road ahead. So what is CTI? So it might be straightforward to think that it's like, okay, it's some sort of specific information about attacks and so on, but that it's actually a very broad concept and very nebulous, just data. So specifically cyber threat intelligence, it's a subset of threat intelligence, so threat intelligence is a very broad domain. But here in this case, we're specifically focusing on digital threats and cyber security, so we don't care about physical threats and so on. And normally it includes whole lot, and it includes like anything from very detailed things like network logs and activity logs about processing, running on individual workstations, servers, networks and so on, malware reports. It also contains all sorts of unstructured information from hacker forums, all sorts of reports from government agencies and other agencies. So it's a whole lot and it's a funnel. So all the way from the top very unstructured information discussions, ideas, gossip and so on, all the way down to specific, I don't know, processes running on a specific workstation. And it can be used in different ways, it can be used to kind of understand the trends. It can also be used to understand the tactics, techniques that adversaries or specific attackers are using today, are developing, are working on and so on. And it also allows to identify quickly enough the specific malware strains, vulnerabilities and known exploits. So just like viruses in the real world, in the biological viruses that attack us, malware also evolves all the time, but this time it's like people actually working actively to evolve them. So that's actually where the similarity ends. So in most cases, this kind of data involves sensitive, either personal data or business critical data, which makes the whole subject really touching. And also because in many cases cyber threats either indicate that a specific attack has happened or when was successful perhaps, and then nobody wants to really talk about that or some enterprise or some organization has been targeted, even that is additional information. So it's really, really difficult to work with. But in the same time, organizations need to share this and need to collect this from others and share and so on because this helps prepare incident response, helps them be ready, helps improve their capabilities and so on and also eventually reduce the impact of cyber incidents when bad things actually happen. And so also knowing emerging threats helps them make informed decisions instead of just say like, okay, let's keep investing in cybersecurity endlessly, nobody ever said that. But at least this helps argue why specific measures need to be taken and so on given the trends and the developments in let's say new malware strains. And so it's an ever-evolving threat, as I said, things are not static, things change from day to day. And so that's why organizations, even though they are even competing perhaps, those all sorts of security organizations, they might be competing, but they also need to collaborate. And then there's even another model where there might be, I don't know, organizations that are not directly competing such as let's say the region of Bilbao or actually Basque, I don't know, the exact region here. And then another region in a different country might want to exchange information about what is actually happening to their networks because if there's an attack on a public administration in Spain, there might be a similar attack coming up in Belgium or Italy or any other country. But then here you come to a different type of difficulties because then this means transferring potential personal information over borders, which adds a whole lot of new challenges. So sharing city eyes far from straightforward. In the same time, it's really, really necessary. As I mentioned, organizations prefer to keep it secret because this often risks damaging the public images, nobody wants to look like they had some sort of incident. They prefer to keep things nice and easy. And of course, there are a number of standards and there's a bunch of projects to make city eyes sharing easier, but it's far from guaranteed that they're actually always applicable. Because as I said, it's a problem that is difficult to solve not only technically, it's not only about the data model of specific, how do you share this information. And for that you have this OECS defined standards. But it's also about other aspects, about data protection, about getting the OECS from the data protection officer in the organization to share this potentially business critical or personal information across organizational borders, across national borders. It all becomes like a multi-dimensional problem, which is different from other, let's say, settings when you have the, I don't know, bunch of IoT sensors and you need to protect that data from adversaries. And then, of course, now everybody talks about AI and machine learning. And the issue with this is that this really helps improve things because the issues so far with the threat intelligence analysis is that it's a human issue. It needs to be analyzed by humans, by SOC operators, like security operations centers operators. And the single biggest issue with that is burnout. People just get burned out. There's so much information they need to react really fast and so on. It's still necessary. But then, of course, you have machine learning and deep learning to help that as a tool and perhaps reduce the amount of information and help their decision. So it's a very good decision support tool. The thing with it is that, given that the threat is ever evolving, they need a lot of data all the time. So this even further highlights the need to share data. And sharing data is difficult, as I mentioned until now. So in summary, sharing big amounts of CTI data is complex. Why? So first of all, data is heterogeneous. There's all this stack from, from let's say, process information all the way to discussions on all sorts of forums. Potentially, it's very sensitive. It's business sensitive. It's personal information sensitive and so on. There are, of course, always commercial offerings, say like, okay, just like, you know, combine and upload all your data here and share in our big data warehouse, like whatever. However, they rely on blind trust. Just close your eyes, like, yes, sure, things are good. Of course, they can also rely on very long legal negotiations that are absolutely unenforceable because you can never ever actually prove something went one way or another. So in that case, only legal stuff wins because they get a lot of budget. Or in some other cases, nothing is happening. And then we get less information. We don't know what's happening. We cannot keep up with the new tactics of the adversaries. So in brief, the way I see it right now, there are no good solutions. There are workarounds. There are better or worse workarounds, but it's all workarounds. Quite often, like, blind trust is the winner. Like, we see blind trust everywhere. And so if we look at it on a higher level, let's imagine some sort of hospital or whatever provider of network logs or like the public administration of the city of Bilbao, they need to collect information from their networks and so on. And they do that, but they don't really obviously have the expertise to extract threat intelligence from that. And they collaborate usually with some sort of a security provider with a managed security service and so on. And here we care about privacy because in many cases or in most cases, let's say they have some sort of monitoring tools on their workstations, on their networks, and these monitoring tools are installed on the, let's say, laptops or workstations of individual employees. And if you are able to see all the processes that are running, all the tabs that are open and so on, well, it kind of contains very sensitive information, you know, who's sort of from Facebook instead of working and so on. So it's very touchy. You cannot just like send it over to a managed security service provider, potentially located in a different country. And here we care about the collection phase. So we care about input privacy. When the data is collected, what kind of data is collected? And then it's somehow processed. Right now we abstract from like where it's processed, who is processing. It's somehow anonymized. And I put it in quotes because anonymization is such a topic that, yeah, it's, yeah, there's, we could call it pseudo anonymization. And then there's the sharing phase, which is more about the output privacy. What do you release? What kind of views or what kind of queries do you allow and what kind of views of data you allow based on the process information? And this really like the, let's say, the setup and how this is solved really depends on where the organizational boundary is. Is all this processing and pre-processing and pseudo anonymization happening on the side of the managed security service or on the side of the data owner service? And so here, this organization boundary can be shifting. And depending on this setup, you have very, very different trust relations. And I know we have a trust, machine trust expert in the room. I'm reading your book right now, Mike. And this really affects how things are set up, negotiated, and so on. And so how confidential computing can be solved in one case? Well, of course, using confidential computing, we can agree that a certain software with a certain configuration would be processing the data. And then a certain, let's say, subset of information from that data would be released to the managed security service. And then both organizations can verify and use some sort of attestation service. In this case, well, the service that we have, but it could be project amber from Intel or others, in order to validate that certain software with a certain configuration that has been whitelisted and agreed upon with certain policies and so on, is processing the data and is releasing a certain type of information that is anonymized, pseudo anonymized, and has been given an OK by the data protection officer. So this is, let's say, a simple implementation which is still useful and it raises the bar. And most importantly, it raises the, let's say, the chances that the managed security services provider can convince their potential customer, the city of Bilbao, that they will not gain too much information about the too much private data about the employees of the public administration. And instead, they will be able to extract this valuable cyber threat intelligence information. So this is, let's say, a canonical, almost example of using computational computing to protect, on one hand, the data, but also potentially the algorithms or even the configuration data of the software. And the software that does the processing can be proprietary, can be an open source project that has been configured in some way and so on. So yeah, here, the same thing. Again, it depends on where this processing is happening. It can also be used, the same model can be used to place this preprocessing software created or configured by the managed security service provider on the network of the administration, because then it would also help them reduce the amount of data collected. Because a big issue with collecting cyber threat intelligence is that it's a lot of data, it's petabytes of data. And these guys here who are collecting and processing the cyber threat intelligence, they don't need all this data. It's costly, it's a lot of trouble protecting it and so on. They would rather have the pure information that they need. On the other hand, if they place their potentially proprietary algorithms to detect attacks on the networks of their customers, well, they might lose control over it because they don't trust these networks actually. So computational computing can help in this sense. But then there are, okay, so this basically summarizes it. But there are more complex scenarios. So in this case, the first conclusion here that confidential computing is not magic, but can help. And even if it helps here, there are still very complex trust relationships that are still involved between the data owner, let's say the public administration of the city of Bilbao, the managed security service provider, and whoever runs the, let's say, attestation service, the policies for this attestation service and so on. But then you might have other cases, as I mentioned, where several public administrations, for example, might want to collaborate in order to collaboratively train a machine learning model for threat intelligence collection and so on. And here we have an example of what Sven mentioned of combining or stacking the technologies of confidential computing with some other pets. And in this case, of course, federated learning with homomorphic encryption or secure aggregation based on the homomorphic encryption helps address this. So this is an example where the two technologies are stacked. And I'll explain very soon why we need to stack them. So the example here is that we have two example organizations, organization one and N, we can have many, but in this drawing there are just two. And the organizations collect these logs. And these logs, as I mentioned, can contain very sensitive information. And usually they do. And they need to be protected both due to business reasons and due to personal data protection reasons. And then very different people decide on these issues. And these two organizations generally trust each other on sharing cyber threat intelligence information, but don't really trust each other on sharing data. And they cannot even trust each other. They're prevented by law or by regulations from trusting, from sharing personal information simply due to GDPR or other regulations. Yeah. So there are a bunch of secure aggregation schemes for federated learning. And we went through many of them. We chose one. We found that it's very scalable. But then it has quite a lot of constraints because it only supports additive operations and it has other constraints. And then we realized like, hey, actually, we don't need scalability. Because many of these secure aggregation schemes, especially based on federated learning, they are built for scalability. But if we have, let's say, 10s of organizations, we don't care about scalability. Yeah, perfect. We don't care about scalability. We can trade scalability for, let's say, for performance or for other security properties. And so in this case, we designed a different secure aggregation scheme. And this comes back to the point of using, let's say, NPC and other pets that Sven was making. And one issue with this is that it's brittle. It's brittle. And it quite often needs to be fine tuned to the use case. And it's quite a lot of fiddling there. So that is a big challenge to their more massive adoption. But in any case, they are very useful. However, however, this is great. But homomorphic encryption has one very big massive Achilles heel is that it only provides confidentiality. It takes good care of confidentiality and great everything is encrypted, but integrity is not there. And this is exactly the case where we also need integrity because we want to be able to rely on this information and know that not only it's protected at all times, but it's also trustworthy that, of course, the organizations might trust each other to provide correct information, but will they trust the aggregator, whoever runs the aggregator? How is the aggregator running? And this is another case where confidential computing can help. And this is the case for stacking up the technologies where confidential computing can be used to protect the aggregation service for the federated learning model in this case, combined with homomorphic encryption that is used for secure aggregation of the model parameters. Yeah. So in summary or looking ahead, I would say that, well, I think there is not yet the realization. I think it will still take time, but I think blind trust should no longer be an option. Well, I think it's still quite a lot an option, especially when we look at all the services that we use and even enterprise services that businesses use. Blind trust is still an option, and it works remarkably fine. But I think the regulations that are coming up are slowly catching up with this, and especially we see regulations in different fields, especially Europe is very much a leader in regulating things. But finance is having some really nice regulations coming up where blind trust is no longer an option. And confidential computing is a really, really powerful tool. But as I mentioned before, it's not magic. It can do a lot if it's used right. It's not necessarily easy to use it right. And it needs to be combined well stacked or even blended with other pets. And on the other hand, protecting privacy, the other aspect of this talk is also a moving target. And this is the other nice or funny or challenging aspect of of using confidential computing. It's not like we designed a solution, confidential computing, we're good. No, because even what is privacy and how it needs to be protected is evolving. It evolves you to regulations. It evolves you to interpretations of regulations, which is a funny funny thing. But every every nation state even within Europe and elsewhere as well, of course will have their own interpretations of this. And even the interpretation or understanding of local data protection officers in every organization, you know, might evolve over time. Whatever was fine today, we just told them like, we use confidential computing. So it's okay. Today is fine. And then tomorrow, the DPO will read into the, you know, we'll read some some article that was published about vulnerabilities and whatnot and say like, no, it's not not fine anymore. Like you need to do more. So this is also a moving target. So which makes the whole problem quite challenging and fun. But it's also a good challenge for the confidential computing community to keep, you know, evolving and improving and not just, you know, rely on the comfortable realization that we have confidential computing. This is this is perfect. We're done. No, we're not done, but it's a very, very good tool to work with. And that's, that's about it. Yeah. Get in touch for demo. Thank you very much indeed. Nothing's, nothing fun about confidential computing. No, you know, that's all good. Very sad topic. Any questions? I'm sure there are. It's who wants to start? Because I can, I can always come up with questions. I know. So, okay. So you've chosen your, your other PET to stack. Where are you with choices in terms of the confidential computing piece of your stack? In terms of what you're offering? Yeah. So I wonder how I should answer this question without going into details of any specific provider, because it's a very, well, not provider, but vendor, because a very, you know, vendor specific technology. But we, due to performance issues, I think this is a good way, due to performance issues, we realized that we need VM based solutions. And I see this also basically all the feedback that I've had through, from all sorts of discussions, there are some organizations that are for whatever reason, very attached to process based. But even those realized that, you know, IO is a big issue and performance is a big issue. And ultimately, performance trumps security in most use cases. And even, even no matter how stringent the security requirements, performance is still necessary. Of course, there will always be niche cases where, where security will trump performance and say like, well, we, we are fine. We are going to use just, you know, very secure stacked or amalgamated solutions. And we don't care about performance or cost. Yes. But those, those are very niche. And, and that's why we saw that VM based approaches are, let's say, more accepted. So that's a, which leads you to a whole bunch of other questions. I don't think it's time to go through. But I think I'm just going to raise here, which is that often when, when people come to us, the industry and ask about performance, they, they think it's all about how fast something runs. But actually, we've had a couple of talks which talked about IO performance. And that's really, really important. And that can be internal and external off, off die and wherever. So I'd love to see some more talks about those sorts of things in, in future ones of those, if anyone's interested. Any final questions for Nicola? I'll have my language question, if no one else. What language are you using? Rust. Yeah, that's a correct answer. Always the correct answer. So I'm a, I'm a rust convert. Excellent. Well, thank you very much indeed. Next is