200-20,000 employees spanning over 100 or multiple hundreds of subsidiaries, depending on
at least 7,000 IT applications and services, running 60,000 containers and virtual service,
using more than 100,000 open source components.
And we need to know, in real time, which exact component is used to wear and how, in which
version, in which application.
So this session will cover program that a few colleagues and I have been conducting over
the past two years roughly.
The first time expectation management, this session will not cover the entirety of cyber
resilience act.
But we show a subset of it, which we consider as a, or I will show it, which we consider
as a quite challenging part of it that is now in the implementation phase.
And I won't have the time today to go into all the details.
I would love to show you everything that we implemented so far in our roadmap.
So I will try to focus here on the strategy, how we set up the program, what the reason is
behind.
I will give a second session tomorrow, and the S-BOOM deafroom going more into the technical
details.
So you're welcome to join here, so here it's rather on the high-level view.
Now, let me give you some context.
Two of you hasn't heard of Deutsche Beignet.
Oh, thank you.
Come on, we can skip this slide.
And now, what's interesting here, basically, is just the size and the diversity of the organization,
the size of the IT, but also of the professions behind of the people and the complexity.
But what has this to do with the CRA?
So in our understanding, or you will share that, the Sutter Resilience Act has many obligations
for the different roads in IT, in software and security.
And I will not touch all of them.
Some of them, I would say, are basic principles of good IT software development and operations.
My topic today, and I will take this out, is the question of getting transparency over
supply chains using S-BOOM.
This is the sub that are set that I will concentrate on today.
S-BOOM's for Deutsche Bahn are not entirely new as for most organizations properly.
So, earlier, we used the mostly for open source license compliance, but we never put them
in a really larger context together with other governance owners with security organizations.
And this changed.
And so, cyber-resilience Act gave us the possibility to put this on a new level, more or less.
What is this level, or what is this context that we are talking about?
So when we think about transparent supply chains, it is really easy to set them, especially
if you want to suit many use cases and regulations and requirements internally and externally.
And one thing to consider here is that Deutsche Bahn is not being a software company,
still holds in software from so many different streams.
So we build software ourselves.
And this is not only the apps that you are using to travel with in Germany, DB Navigator,
or so, this is not only websites, this is also embedded stuff being on the tracks in the
station, small tiny things and so on.
This is also a lot of internal IT, of course, that we sell within or move within the Deutsche
Bahn crew.
We buy software, obviously a lot, and operate that in the most different places, like I said
already, embedded devices in the cloud, container, search service, actual service, some
of them probably still under deaths and we are on-premises as well.
So we have to know what our mission is and that goes beyond cyber-resilience Act is to
find out which software is running where exactly and ideally who is responsible for that
how can we fix it if something is wrong.
So can we find a common language to not only have an inventory of the software, but actually
also to work with it, to make it usable.
And you wouldn't be surprised that this language is S-bombs.
So for us, S-bombs is not a tool, it's not an obligation just by the cyber-resilience
Act.
It's a common methodology to tackle multiple challenges.
I won't go through all of them.
I said we started with open-source license compliance, it's just to fulfill the regulations
but it's also much more, we can support so many things if we do it right.
So in my view, S-bombs must become some kind of a common methodology, a common language
or even a shared infrastructure among our organizations and beyond.
So the full potential of S-bombs can also be used to integrate it with other standards
and I would like to pick out one of them and that, for me, is Vex.
Will the ability exploit the ability exchange?
That's a perfect match and there are a few more perhaps, but this is great because it
allows users of teams or organizations to create a machine-readable format in order to
communicate whether I, as a team, as an organization, am affected by no insecurity vulnerability.
So like a C-V-E.
So I can have a perfect inventory or a good inventory of my software, match it with
my database of non-runabilities and I can have a machine-readable format in order to figure
out whether the team and this very context would decide that, or manufacture, would decide
that the vulnerability is exploitable.
And that again reduces burden for teams for the whole integration because there will be
a lot of findings.
In our organization, like with many other organizations, especially since we are so federated
and not a real software company in the sense, that doesn't happen easily to get these
different methodologies into our organization.
So now we are coming to the strategy part, how do we actually do that?
So instead of looking only at a single use case, like for instance open source license
compliance, we knew that we need a more holistic approach to it.
And that isn't quite easy, but what helped us is to find a few principles that guide us
along the way.
And I would split them into the, I would say rather procedural principles and the technical
or architectural ones.
There are many, but I take out the most important ones for me.
The first is from the procedures to think big.
I said it already, we need a holistic approach.
It doesn't bring us anywhere if we do S-bomb's year and S-bomb's there and it doesn't
match really.
So we think big, but we iterate our goal, our methodology, our processes that we thought
of quickly by talking with internal stakeholders by talking, also gathering feedback
by others.
Another second important factor was to not talk in tools.
When we started, we had the, I don't know, the urge to talk in tools that we already
had within the enterprise architecture and things like how can we integrate it.
But it was a game changer when we started to think in the capabilities of these systems.
So how do they bundle together, how can they fit together in order to suit the needs
that we actually have?
Then on the rather architectural side, it was clear that we had to support all the different
sourcing streams.
So not only the stuff which we would be reliable or obligated by the several resilience
act, but more.
So we wanted to make this really common.
And therefore also consider all the different S-bomb types that can basically describe
that.
And for us, architecturally, it was important to have a modular approach.
So we didn't make really good experiences with having a model lift in this, but rather
modular approaches, with open standards, open formats, and good interfaces in between.
And what came out was rather a mental model of the S-bomb life cycle in our organization.
So you will see that on the sourcing of S-bombs, or where the S-bombs are flowing in,
we consider that this cannot be done centrally.
And I guess many of you will have the same picture in mind.
So given our very complex, not only IT, but also structure and processes and guidelines,
was clear that we had to acknowledge the fact that S-bombs would come from everywhere.
And we cannot have a central tool or so to make this possible.
Tomorrow I would explain a bit how we get to the same quality baseline, but yeah, that's
the picture here.
But the central part will be to store all S-bombs in one inventory.
You can imagine that this is just a database, a large database, with good APIs around it.
So all S-bombs have to be in one place, that is a rule for us, a golden rule because
otherwise we would be lost in many databases where we would have to look at in emergency
cases, for instance.
We can then enrich these S-bombs or connect them with other information, like from knowing
what our IT applications are, thereby knowing who is responsible for this piece of code
or for this S-bombs or what this S-bombs described basically.
So here we have really good context information that the S-bomelone wouldn't give us.
But then on the analysis of the S-bombs, this is again decentralized.
So we will have many use cases that we can handle with these inventories of S-bombs.
So this is the simplified version that I showed here, that is more the little bit more complex
version.
I will not go over it.
But that's our guiding star.
We call it S-bombs Blueprints, and German S-bombs here, but that's just just the way
how we connect or how we see our world, how the life cycle or how the flows of S-bombs
and Vex information is going through our systems.
And again, this is not tools.
I mean, you can put tool names perhaps here, but this is rather about capabilities on an abstract
level.
I will upload this slide, so you don't have to take pictures here, but anyway.
So how do we actually translate that into reality?
So this is nice to have.
So it's clear that we cannot do this overnight.
This takes time because it's really, we have to put this into an existing architecture
and existing IT systems and processes.
So we started this with going with a mix of priorities, so based on priorities that we had
for instance by the CRA, but also to be honest, by pragmatic look for low hanging fruits.
So, but in general, our strategy was with S-bombs, that we didn't look for the perfect
S-bombs in the beginning.
And this is perhaps different to what some tool makers or some other positions are.
They say, well, we have to go, we have to describe the reality one hundred percent.
The problem is if you only describe like a teeny tiny subset of your reality and perfectly
well with all the information, this doesn't bring us any further if we have emergency
cases or other things where we need this large inventory.
So we started with it to be honest, quick and direct here approach.
So what we did was we, what we currently are already doing is we know for all our source
repostries and a lot of the built pipelines that we are having and also S-bombs that we get
from some of the manufacturers, we have these S-bombs already.
And then we are stacking up the quality.
These by piece, knowing what we are the portfolios, positives, we are the missing pieces,
how can we get, how can we increase the quality, for instance, regarding licensing information.
And this year we will concentrate for getting S-bombs more from the one-time systems,
so from containers and from our virtual service, also physical service.
And on the road map as well is to get the S-bombs and to create S-bombs for OT, for operational
technology, or IT that is very close to hardware.
You can imagine as Deutsche Bahn and a lot of infrastructure we are having, we have a lot
of that.
And that's complicated, but we need to know that as well, we have infrastructure and
software that is supposed to run for 40, 50, 70 years or so.
And this is a challenge, but we need to know that.
So for the exact tools, how we, how we, how we run the path and what we are planning,
I have to refer to this session tomorrow because we are almost already running out of time.
But here are some numbers that we pulled out just a few days ago.
So we quickly analyzed 80,000 S-bombs that we had, again, from source and build S-bombs.
And in the middle of basically a key number, this is the number, like more than 100,000 open source
components that we are using.
And if you take in the different versions and I don't know architectures, you have
to factor of 5 or 6, I'm sure anymore.
So this is the size that we are speaking of, and we want to increase that, or we will increase
that to many more S-bombs if we take in the whole runtime containers and more projects.
Another key number here is the 7.7.
7.7% of the code projects that we analyzed with S-bombs contain the same most used dependency.
So if we had to replace this dependency, this single one, or if it, I don't know, had
a critical security vulnerability, for whatever reason we would have to replace it, we would
have to touch 7.7% of our projects.
And that's interesting because this can lead us to making strategic decisions.
Do we want to have that dependency, do we have to support that, do we have to engage
with the community, for instance, or should we rather replace that?
Regardless of tooling, which I will talk tomorrow about, what I find interesting here to
note is that tools and architectures are not sufficient.
What we really need is people.
So if we want to make S-bombs a common methodology for the whole organization, we have to
think about the users.
Users can be teams, developers, operators, governance owners, even management, right?
And our goal should be if we do that to make them happy.
And I noted here down some of the learnings I already said that adoption before perfection
or that we have to support the different workflows, how software is created or operated.
That's very important.
And governance, and I mean with that open source, license, compliance, CSOS, and business continuity
management, whoever, they also play an important role here.
Because with S-bombs, we have a transparency that we aren't really used.
And if we now take a look at it, some people are surprised.
So we have to help them in order to prioritize the findings and make good actions instead of
overburdening the teams and the people who work with this data.
So governance owners, how I would call them, they have the ability here to, or what they have
to do in order to not, to take the people with them is to help them prioritize issues and
findings.
S-bombs will create a lot of findings if you have that.
So help them prioritize this and establish automated compliance wherever possible.
And this must be the goal.
We cannot just add S-bombs and Vex information on top and leave the rest of the engineers
to do that.
We have to take people with us.
What's interesting here, what's helpful here, is to have a risk-based approach.
So really think about what are the risks that may materialize, that really happen, that
may really affect my organization or my context that I'm in, and act accordingly, and
leave behind perhaps again the risk-defining and security vulnerabilities that you consider
to not be as critical as the others.
So this is really how we can make progress in the field.
So as I'm running out of time, I come already to my conclusions.
Most importantly, I would say, again, that S-bombs are not a product.
It's not a tool.
It's a methodology.
It should be a common understanding how we do professional IT.
And if we have this understanding in our minds, then we know that as any methodology,
we can only implement that incrementally and modular and also delightful for the people
that are perhaps then even forced to use it.
So please internalize if you're working in an organization, internalize this knowledge
and these skills and the methodology.
Do not externalize it, do not outsource it, it won't work.
So you have to know how can I implement this in my organization and build this from Krantop.
And for us, here in the room, and beyond, let's collaborate.
Not only on the tools, we do that already, rather well, but also show share your learning,
your lessons learned, your pitfalls, and exchange on the methodology.
So thank you already.
I invite you to join my talk tomorrow.
There's a certain overlap that a lot more on tooling.
And yeah, thank you for your attention and looking forward to your questions.
Do we have time for questions?
All right, thank you for the talk was very interesting.
So one thing that's very striking to me is that this looks like it was and it is a very
big project to get all of this in place.
And how do you, but when you look at the obligation in the CRA, it's not obvious that
this is a lot of work to many people.
And so do you have any advice on how you can convince stakeholders that they should actually
set up such a large project to do this properly, rather than just tell all of their projects
like generate an S-bomb and put it somewhere in your wherever and do it sloppy that way.
Yeah.
Two things, I think, first of all, CRA is a leverage, like we are quite compliant
driven organization.
So you set leverage, you can add importance to whatever you do.
And secondly, don't expect top management to act and say, oh, we set up an S-bomb project.
What we did here was a bottom up project.
We set together, especially open source compliance dudes like me and security people.
And we set together and said, we need to do something because otherwise we will never
get on the train to reach a zero A compliance.
So these were our strategies, but we can also exchange later if you want to know more
for your context.
What is your strategy regarding third party suppliers?
How do they put in their S-bombs and how is their data quality?
The data quality, I start with that, is from OK-ish to CRAP and how we do, do we do that?
I mean, we cannot rely on the several resilience act mostly.
We try that on contractual basis.
So to change our contracts, our standards contracts, and to write something about S-bombs
and the quality, the minimum quality inside of these requirements, the contractual ones.
And then following up, that will be the idea to also assess the quality later.
And I have to say in the automotive industry, that's since a long time, I'm a common thing.
Awesome.
Thank you so much.
Unfortunately, we are at time.