WEBVTT 00:00.000 --> 00:14.680 200-20,000 employees spanning over 100 or multiple hundreds of subsidiaries, depending on 00:14.680 --> 00:24.000 at least 7,000 IT applications and services, running 60,000 containers and virtual service, 00:24.000 --> 00:30.240 using more than 100,000 open source components. 00:30.240 --> 00:37.520 And we need to know, in real time, which exact component is used to wear and how, in which 00:37.520 --> 00:41.240 version, in which application. 00:41.240 --> 00:46.480 So this session will cover program that a few colleagues and I have been conducting over 00:46.480 --> 00:50.280 the past two years roughly. 00:50.280 --> 00:56.920 The first time expectation management, this session will not cover the entirety of cyber 00:56.920 --> 00:59.240 resilience act. 00:59.240 --> 01:05.080 But we show a subset of it, which we consider as a, or I will show it, which we consider 01:05.080 --> 01:09.600 as a quite challenging part of it that is now in the implementation phase. 01:09.600 --> 01:13.080 And I won't have the time today to go into all the details. 01:13.080 --> 01:17.200 I would love to show you everything that we implemented so far in our roadmap. 01:17.200 --> 01:21.600 So I will try to focus here on the strategy, how we set up the program, what the reason is 01:21.600 --> 01:22.600 behind. 01:22.600 --> 01:27.440 I will give a second session tomorrow, and the S-BOOM deafroom going more into the technical 01:27.440 --> 01:28.440 details. 01:28.440 --> 01:33.600 So you're welcome to join here, so here it's rather on the high-level view. 01:33.600 --> 01:35.480 Now, let me give you some context. 01:35.480 --> 01:37.880 Two of you hasn't heard of Deutsche Beignet. 01:37.880 --> 01:39.880 Oh, thank you. 01:39.880 --> 01:42.120 Come on, we can skip this slide. 01:42.120 --> 01:46.520 And now, what's interesting here, basically, is just the size and the diversity of the organization, 01:46.520 --> 01:53.840 the size of the IT, but also of the professions behind of the people and the complexity. 01:53.840 --> 01:57.560 But what has this to do with the CRA? 01:57.560 --> 02:04.360 So in our understanding, or you will share that, the Sutter Resilience Act has many obligations 02:04.360 --> 02:09.640 for the different roads in IT, in software and security. 02:09.640 --> 02:11.080 And I will not touch all of them. 02:11.080 --> 02:19.360 Some of them, I would say, are basic principles of good IT software development and operations. 02:19.360 --> 02:25.600 My topic today, and I will take this out, is the question of getting transparency over 02:25.600 --> 02:28.760 supply chains using S-BOOM. 02:28.760 --> 02:32.920 This is the sub that are set that I will concentrate on today. 02:32.920 --> 02:37.760 S-BOOM's for Deutsche Bahn are not entirely new as for most organizations properly. 02:37.800 --> 02:43.480 So, earlier, we used the mostly for open source license compliance, but we never put them 02:43.480 --> 02:49.520 in a really larger context together with other governance owners with security organizations. 02:49.520 --> 02:50.880 And this changed. 02:50.880 --> 03:01.080 And so, cyber-resilience Act gave us the possibility to put this on a new level, more or less. 03:01.080 --> 03:05.160 What is this level, or what is this context that we are talking about? 03:05.160 --> 03:10.480 So when we think about transparent supply chains, it is really easy to set them, especially 03:10.480 --> 03:18.360 if you want to suit many use cases and regulations and requirements internally and externally. 03:18.360 --> 03:23.640 And one thing to consider here is that Deutsche Bahn is not being a software company, 03:23.640 --> 03:28.680 still holds in software from so many different streams. 03:28.680 --> 03:31.120 So we build software ourselves. 03:31.120 --> 03:35.760 And this is not only the apps that you are using to travel with in Germany, DB Navigator, 03:35.760 --> 03:42.480 or so, this is not only websites, this is also embedded stuff being on the tracks in the 03:42.480 --> 03:45.160 station, small tiny things and so on. 03:45.160 --> 03:50.400 This is also a lot of internal IT, of course, that we sell within or move within the Deutsche 03:50.400 --> 03:51.920 Bahn crew. 03:51.920 --> 03:57.760 We buy software, obviously a lot, and operate that in the most different places, like I said 03:57.760 --> 04:04.680 already, embedded devices in the cloud, container, search service, actual service, some 04:04.680 --> 04:09.640 of them probably still under deaths and we are on-premises as well. 04:09.640 --> 04:15.360 So we have to know what our mission is and that goes beyond cyber-resilience Act is to 04:15.360 --> 04:21.800 find out which software is running where exactly and ideally who is responsible for that 04:21.800 --> 04:24.440 how can we fix it if something is wrong. 04:24.440 --> 04:30.480 So can we find a common language to not only have an inventory of the software, but actually 04:30.480 --> 04:33.680 also to work with it, to make it usable. 04:33.680 --> 04:36.600 And you wouldn't be surprised that this language is S-bombs. 04:36.600 --> 04:41.120 So for us, S-bombs is not a tool, it's not an obligation just by the cyber-resilience 04:41.120 --> 04:42.120 Act. 04:42.120 --> 04:45.600 It's a common methodology to tackle multiple challenges. 04:45.600 --> 04:46.920 I won't go through all of them. 04:46.920 --> 04:51.080 I said we started with open-source license compliance, it's just to fulfill the regulations 04:51.080 --> 04:56.360 but it's also much more, we can support so many things if we do it right. 04:56.360 --> 05:05.440 So in my view, S-bombs must become some kind of a common methodology, a common language 05:05.440 --> 05:11.040 or even a shared infrastructure among our organizations and beyond. 05:11.040 --> 05:16.880 So the full potential of S-bombs can also be used to integrate it with other standards 05:16.960 --> 05:21.760 and I would like to pick out one of them and that, for me, is Vex. 05:21.760 --> 05:24.560 Will the ability exploit the ability exchange? 05:24.560 --> 05:29.200 That's a perfect match and there are a few more perhaps, but this is great because it 05:29.200 --> 05:36.440 allows users of teams or organizations to create a machine-readable format in order to 05:36.440 --> 05:42.920 communicate whether I, as a team, as an organization, am affected by no insecurity vulnerability. 05:42.920 --> 05:44.640 So like a C-V-E. 05:44.640 --> 05:49.320 So I can have a perfect inventory or a good inventory of my software, match it with 05:49.320 --> 05:56.280 my database of non-runabilities and I can have a machine-readable format in order to figure 05:56.280 --> 06:02.120 out whether the team and this very context would decide that, or manufacture, would decide 06:02.120 --> 06:04.240 that the vulnerability is exploitable. 06:04.240 --> 06:09.080 And that again reduces burden for teams for the whole integration because there will be 06:09.080 --> 06:12.000 a lot of findings. 06:12.000 --> 06:17.120 In our organization, like with many other organizations, especially since we are so federated 06:17.120 --> 06:22.200 and not a real software company in the sense, that doesn't happen easily to get these 06:22.200 --> 06:27.840 different methodologies into our organization. 06:27.840 --> 06:31.560 So now we are coming to the strategy part, how do we actually do that? 06:31.560 --> 06:36.540 So instead of looking only at a single use case, like for instance open source license 06:36.540 --> 06:41.920 compliance, we knew that we need a more holistic approach to it. 06:41.920 --> 06:47.960 And that isn't quite easy, but what helped us is to find a few principles that guide us 06:47.960 --> 06:49.240 along the way. 06:49.240 --> 06:54.720 And I would split them into the, I would say rather procedural principles and the technical 06:54.720 --> 06:56.720 or architectural ones. 06:56.720 --> 06:59.520 There are many, but I take out the most important ones for me. 06:59.520 --> 07:03.320 The first is from the procedures to think big. 07:03.320 --> 07:05.360 I said it already, we need a holistic approach. 07:05.360 --> 07:08.920 It doesn't bring us anywhere if we do S-bomb's year and S-bomb's there and it doesn't 07:08.920 --> 07:11.200 match really. 07:11.200 --> 07:18.200 So we think big, but we iterate our goal, our methodology, our processes that we thought 07:18.200 --> 07:23.560 of quickly by talking with internal stakeholders by talking, also gathering feedback 07:23.560 --> 07:25.920 by others. 07:25.920 --> 07:29.360 Another second important factor was to not talk in tools. 07:29.360 --> 07:34.080 When we started, we had the, I don't know, the urge to talk in tools that we already 07:34.080 --> 07:38.920 had within the enterprise architecture and things like how can we integrate it. 07:38.920 --> 07:45.000 But it was a game changer when we started to think in the capabilities of these systems. 07:45.000 --> 07:49.000 So how do they bundle together, how can they fit together in order to suit the needs 07:49.000 --> 07:51.960 that we actually have? 07:51.960 --> 07:57.200 Then on the rather architectural side, it was clear that we had to support all the different 07:57.200 --> 07:58.200 sourcing streams. 07:58.200 --> 08:04.080 So not only the stuff which we would be reliable or obligated by the several resilience 08:04.080 --> 08:05.720 act, but more. 08:05.720 --> 08:08.400 So we wanted to make this really common. 08:08.400 --> 08:13.880 And therefore also consider all the different S-bomb types that can basically describe 08:13.880 --> 08:14.880 that. 08:14.880 --> 08:19.800 And for us, architecturally, it was important to have a modular approach. 08:19.800 --> 08:23.760 So we didn't make really good experiences with having a model lift in this, but rather 08:23.760 --> 08:30.040 modular approaches, with open standards, open formats, and good interfaces in between. 08:30.040 --> 08:38.080 And what came out was rather a mental model of the S-bomb life cycle in our organization. 08:38.080 --> 08:45.000 So you will see that on the sourcing of S-bombs, or where the S-bombs are flowing in, 08:45.000 --> 08:47.760 we consider that this cannot be done centrally. 08:47.760 --> 08:51.600 And I guess many of you will have the same picture in mind. 08:51.600 --> 08:59.000 So given our very complex, not only IT, but also structure and processes and guidelines, 08:59.000 --> 09:03.440 was clear that we had to acknowledge the fact that S-bombs would come from everywhere. 09:03.440 --> 09:07.360 And we cannot have a central tool or so to make this possible. 09:07.360 --> 09:11.840 Tomorrow I would explain a bit how we get to the same quality baseline, but yeah, that's 09:11.840 --> 09:13.280 the picture here. 09:13.280 --> 09:17.520 But the central part will be to store all S-bombs in one inventory. 09:17.520 --> 09:24.200 You can imagine that this is just a database, a large database, with good APIs around it. 09:24.200 --> 09:28.880 So all S-bombs have to be in one place, that is a rule for us, a golden rule because 09:28.880 --> 09:34.200 otherwise we would be lost in many databases where we would have to look at in emergency 09:34.200 --> 09:35.800 cases, for instance. 09:35.800 --> 09:42.400 We can then enrich these S-bombs or connect them with other information, like from knowing 09:42.400 --> 09:47.280 what our IT applications are, thereby knowing who is responsible for this piece of code 09:47.280 --> 09:52.360 or for this S-bombs or what this S-bombs described basically. 09:52.360 --> 09:58.000 So here we have really good context information that the S-bomelone wouldn't give us. 09:58.000 --> 10:02.560 But then on the analysis of the S-bombs, this is again decentralized. 10:02.560 --> 10:10.720 So we will have many use cases that we can handle with these inventories of S-bombs. 10:10.720 --> 10:16.720 So this is the simplified version that I showed here, that is more the little bit more complex 10:16.720 --> 10:17.720 version. 10:17.720 --> 10:18.720 I will not go over it. 10:18.720 --> 10:19.720 But that's our guiding star. 10:19.720 --> 10:24.400 We call it S-bombs Blueprints, and German S-bombs here, but that's just just the way 10:24.400 --> 10:30.200 how we connect or how we see our world, how the life cycle or how the flows of S-bombs 10:30.200 --> 10:33.880 and Vex information is going through our systems. 10:33.880 --> 10:35.680 And again, this is not tools. 10:35.680 --> 10:41.160 I mean, you can put tool names perhaps here, but this is rather about capabilities on an abstract 10:41.160 --> 10:42.160 level. 10:42.160 --> 10:47.960 I will upload this slide, so you don't have to take pictures here, but anyway. 10:47.960 --> 10:51.600 So how do we actually translate that into reality? 10:51.600 --> 10:56.480 So this is nice to have. 10:56.480 --> 11:00.360 So it's clear that we cannot do this overnight. 11:00.360 --> 11:04.640 This takes time because it's really, we have to put this into an existing architecture 11:04.640 --> 11:08.320 and existing IT systems and processes. 11:08.320 --> 11:15.800 So we started this with going with a mix of priorities, so based on priorities that we had 11:15.800 --> 11:22.720 for instance by the CRA, but also to be honest, by pragmatic look for low hanging fruits. 11:22.760 --> 11:30.640 So, but in general, our strategy was with S-bombs, that we didn't look for the perfect 11:30.640 --> 11:32.960 S-bombs in the beginning. 11:32.960 --> 11:38.200 And this is perhaps different to what some tool makers or some other positions are. 11:38.200 --> 11:42.520 They say, well, we have to go, we have to describe the reality one hundred percent. 11:42.520 --> 11:47.480 The problem is if you only describe like a teeny tiny subset of your reality and perfectly 11:47.480 --> 11:51.720 well with all the information, this doesn't bring us any further if we have emergency 11:51.760 --> 11:55.480 cases or other things where we need this large inventory. 11:55.480 --> 11:59.080 So we started with it to be honest, quick and direct here approach. 11:59.080 --> 12:06.240 So what we did was we, what we currently are already doing is we know for all our source 12:06.240 --> 12:12.120 repostries and a lot of the built pipelines that we are having and also S-bombs that we get 12:12.120 --> 12:16.600 from some of the manufacturers, we have these S-bombs already. 12:16.600 --> 12:19.720 And then we are stacking up the quality. 12:19.720 --> 12:23.720 These by piece, knowing what we are the portfolios, positives, we are the missing pieces, 12:23.720 --> 12:29.440 how can we get, how can we increase the quality, for instance, regarding licensing information. 12:29.440 --> 12:33.880 And this year we will concentrate for getting S-bombs more from the one-time systems, 12:33.880 --> 12:40.360 so from containers and from our virtual service, also physical service. 12:40.360 --> 12:46.520 And on the road map as well is to get the S-bombs and to create S-bombs for OT, for operational 12:46.520 --> 12:50.160 technology, or IT that is very close to hardware. 12:50.160 --> 12:55.280 You can imagine as Deutsche Bahn and a lot of infrastructure we are having, we have a lot 12:55.280 --> 12:56.280 of that. 12:56.280 --> 13:00.600 And that's complicated, but we need to know that as well, we have infrastructure and 13:00.600 --> 13:06.480 software that is supposed to run for 40, 50, 70 years or so. 13:06.480 --> 13:10.400 And this is a challenge, but we need to know that. 13:10.400 --> 13:14.600 So for the exact tools, how we, how we, how we run the path and what we are planning, 13:14.600 --> 13:19.160 I have to refer to this session tomorrow because we are almost already running out of time. 13:19.160 --> 13:23.840 But here are some numbers that we pulled out just a few days ago. 13:23.840 --> 13:30.880 So we quickly analyzed 80,000 S-bombs that we had, again, from source and build S-bombs. 13:30.880 --> 13:35.840 And in the middle of basically a key number, this is the number, like more than 100,000 open source 13:35.840 --> 13:38.800 components that we are using. 13:38.800 --> 13:42.520 And if you take in the different versions and I don't know architectures, you have 13:42.520 --> 13:45.200 to factor of 5 or 6, I'm sure anymore. 13:45.200 --> 13:50.480 So this is the size that we are speaking of, and we want to increase that, or we will increase 13:50.480 --> 13:55.440 that to many more S-bombs if we take in the whole runtime containers and more projects. 13:55.440 --> 13:58.320 Another key number here is the 7.7. 13:58.320 --> 14:08.640 7.7% of the code projects that we analyzed with S-bombs contain the same most used dependency. 14:08.640 --> 14:14.000 So if we had to replace this dependency, this single one, or if it, I don't know, had 14:14.000 --> 14:18.480 a critical security vulnerability, for whatever reason we would have to replace it, we would 14:18.480 --> 14:21.880 have to touch 7.7% of our projects. 14:21.880 --> 14:27.600 And that's interesting because this can lead us to making strategic decisions. 14:27.600 --> 14:31.080 Do we want to have that dependency, do we have to support that, do we have to engage 14:31.080 --> 14:40.640 with the community, for instance, or should we rather replace that? 14:40.640 --> 14:44.520 Regardless of tooling, which I will talk tomorrow about, what I find interesting here to 14:44.520 --> 14:50.000 note is that tools and architectures are not sufficient. 14:50.000 --> 14:52.760 What we really need is people. 14:52.760 --> 14:57.040 So if we want to make S-bombs a common methodology for the whole organization, we have to 14:57.040 --> 14:59.000 think about the users. 14:59.000 --> 15:06.280 Users can be teams, developers, operators, governance owners, even management, right? 15:06.280 --> 15:10.080 And our goal should be if we do that to make them happy. 15:10.080 --> 15:16.520 And I noted here down some of the learnings I already said that adoption before perfection 15:16.520 --> 15:21.360 or that we have to support the different workflows, how software is created or operated. 15:21.360 --> 15:24.080 That's very important. 15:24.080 --> 15:32.520 And governance, and I mean with that open source, license, compliance, CSOS, and business continuity 15:32.520 --> 15:35.920 management, whoever, they also play an important role here. 15:35.920 --> 15:41.200 Because with S-bombs, we have a transparency that we aren't really used. 15:41.200 --> 15:45.560 And if we now take a look at it, some people are surprised. 15:45.560 --> 15:51.280 So we have to help them in order to prioritize the findings and make good actions instead of 15:51.280 --> 15:55.640 overburdening the teams and the people who work with this data. 15:55.640 --> 16:03.280 So governance owners, how I would call them, they have the ability here to, or what they have 16:03.280 --> 16:12.280 to do in order to not, to take the people with them is to help them prioritize issues and 16:12.280 --> 16:13.280 findings. 16:13.280 --> 16:16.680 S-bombs will create a lot of findings if you have that. 16:16.680 --> 16:23.560 So help them prioritize this and establish automated compliance wherever possible. 16:23.560 --> 16:24.560 And this must be the goal. 16:24.560 --> 16:29.400 We cannot just add S-bombs and Vex information on top and leave the rest of the engineers 16:29.400 --> 16:30.400 to do that. 16:30.400 --> 16:33.240 We have to take people with us. 16:33.240 --> 16:37.760 What's interesting here, what's helpful here, is to have a risk-based approach. 16:37.760 --> 16:42.800 So really think about what are the risks that may materialize, that really happen, that 16:42.800 --> 16:48.080 may really affect my organization or my context that I'm in, and act accordingly, and 16:48.080 --> 16:55.200 leave behind perhaps again the risk-defining and security vulnerabilities that you consider 16:55.200 --> 16:57.920 to not be as critical as the others. 16:57.920 --> 17:03.560 So this is really how we can make progress in the field. 17:03.560 --> 17:08.360 So as I'm running out of time, I come already to my conclusions. 17:08.360 --> 17:12.240 Most importantly, I would say, again, that S-bombs are not a product. 17:12.240 --> 17:13.240 It's not a tool. 17:13.240 --> 17:14.240 It's a methodology. 17:14.240 --> 17:20.600 It should be a common understanding how we do professional IT. 17:20.600 --> 17:25.880 And if we have this understanding in our minds, then we know that as any methodology, 17:25.880 --> 17:33.640 we can only implement that incrementally and modular and also delightful for the people 17:33.640 --> 17:38.160 that are perhaps then even forced to use it. 17:38.160 --> 17:42.960 So please internalize if you're working in an organization, internalize this knowledge 17:42.960 --> 17:45.760 and these skills and the methodology. 17:45.760 --> 17:48.840 Do not externalize it, do not outsource it, it won't work. 17:48.840 --> 17:55.280 So you have to know how can I implement this in my organization and build this from Krantop. 17:55.280 --> 17:58.360 And for us, here in the room, and beyond, let's collaborate. 17:58.360 --> 18:05.120 Not only on the tools, we do that already, rather well, but also show share your learning, 18:05.200 --> 18:09.320 your lessons learned, your pitfalls, and exchange on the methodology. 18:09.320 --> 18:11.920 So thank you already. 18:11.920 --> 18:14.280 I invite you to join my talk tomorrow. 18:14.280 --> 18:16.760 There's a certain overlap that a lot more on tooling. 18:16.760 --> 18:19.680 And yeah, thank you for your attention and looking forward to your questions. 18:19.680 --> 18:31.800 Do we have time for questions? 18:31.800 --> 18:38.920 All right, thank you for the talk was very interesting. 18:38.920 --> 18:45.280 So one thing that's very striking to me is that this looks like it was and it is a very 18:45.280 --> 18:48.640 big project to get all of this in place. 18:48.640 --> 18:53.680 And how do you, but when you look at the obligation in the CRA, it's not obvious that 18:53.680 --> 18:55.880 this is a lot of work to many people. 18:55.880 --> 19:01.160 And so do you have any advice on how you can convince stakeholders that they should actually 19:01.160 --> 19:06.440 set up such a large project to do this properly, rather than just tell all of their projects 19:06.440 --> 19:11.880 like generate an S-bomb and put it somewhere in your wherever and do it sloppy that way. 19:11.880 --> 19:12.880 Yeah. 19:13.120 --> 19:18.720 Two things, I think, first of all, CRA is a leverage, like we are quite compliant 19:18.720 --> 19:20.400 driven organization. 19:20.400 --> 19:23.840 So you set leverage, you can add importance to whatever you do. 19:23.840 --> 19:28.320 And secondly, don't expect top management to act and say, oh, we set up an S-bomb project. 19:28.320 --> 19:30.800 What we did here was a bottom up project. 19:30.800 --> 19:37.000 We set together, especially open source compliance dudes like me and security people. 19:37.000 --> 19:41.040 And we set together and said, we need to do something because otherwise we will never 19:41.040 --> 19:44.600 get on the train to reach a zero A compliance. 19:44.600 --> 19:48.880 So these were our strategies, but we can also exchange later if you want to know more 19:48.880 --> 19:51.600 for your context. 19:51.600 --> 19:55.520 What is your strategy regarding third party suppliers? 19:55.520 --> 20:01.880 How do they put in their S-bombs and how is their data quality? 20:01.880 --> 20:10.520 The data quality, I start with that, is from OK-ish to CRAP and how we do, do we do that? 20:10.520 --> 20:14.200 I mean, we cannot rely on the several resilience act mostly. 20:14.200 --> 20:16.520 We try that on contractual basis. 20:16.520 --> 20:21.640 So to change our contracts, our standards contracts, and to write something about S-bombs 20:21.640 --> 20:28.640 and the quality, the minimum quality inside of these requirements, the contractual ones. 20:28.640 --> 20:33.280 And then following up, that will be the idea to also assess the quality later. 20:33.280 --> 20:39.640 And I have to say in the automotive industry, that's since a long time, I'm a common thing. 20:39.640 --> 20:40.640 Awesome. 20:40.640 --> 20:41.640 Thank you so much. 20:41.640 --> 20:42.640 Unfortunately, we are at time.