WEBVTT

00:00.000 --> 00:08.000
Hello, the movement, but anyway, let's start.

00:08.000 --> 00:10.000
I think we are behind schedule anyway.

00:10.000 --> 00:12.000
Thank you for having me.

00:12.000 --> 00:15.000
My name is Julian, I'm the, that's quicking.

00:15.000 --> 00:18.000
I'm the development lead at the Centre for Digital Solventy

00:18.000 --> 00:22.000
and Germany, and I had to scratch an inch,

00:22.000 --> 00:25.000
and I will tell you all about it.

00:25.000 --> 00:28.000
We are seeing the supply chain change,

00:28.000 --> 00:30.000
especially in terms of delivering containers,

00:30.000 --> 00:32.000
and security information.

00:32.000 --> 00:35.000
And I want to tell you about what we did about this,

00:35.000 --> 00:38.000
and how this might impact the field

00:38.000 --> 00:41.000
on a more broader scale.

00:41.000 --> 00:43.000
I don't have it that easy as Dutch barn,

00:43.000 --> 00:45.000
but everybody knows the Centre,

00:45.000 --> 00:47.000
so quick introduction.

00:47.000 --> 00:50.000
For those who weren't here before,

00:50.000 --> 00:53.000
the previous talk asked who does no Dutch barn,

00:53.000 --> 00:55.000
because it was everyone, of course.

00:56.000 --> 01:00.000
Zenders, we are the direct,

01:00.000 --> 01:04.000
we're directly owned by the German federal government,

01:04.000 --> 01:09.000
the originally from the Ministry of Interior

01:09.000 --> 01:11.000
now for Digital Affairs,

01:11.000 --> 01:16.000
and we are tasked with bringing back digital sovereignty

01:16.000 --> 01:20.000
to Germany or the German public administration.

01:20.000 --> 01:24.000
This is a nice task, so we wonder how to do it.

01:25.000 --> 01:28.000
Two things, this is the first thing I kind of want to put forward.

01:28.000 --> 01:31.000
This is our basic, our shared infrastructure,

01:31.000 --> 01:33.000
for software development in the public administration.

01:33.000 --> 01:36.000
So one of the things we do, this is not going to be the core today,

01:36.000 --> 01:38.000
but this is something I want to mention,

01:38.000 --> 01:41.000
is we create a safe space for open source

01:41.000 --> 01:42.000
for the public administration.

01:42.000 --> 01:44.000
So in tenderness, we have an easy way,

01:44.000 --> 01:47.000
a regulated way where we can say,

01:47.000 --> 01:50.000
publish it on open code on this shared infrastructure,

01:51.000 --> 01:54.000
and we know that it is open source by policies.

01:54.000 --> 01:56.000
This is a way for us to provide feedback,

01:56.000 --> 02:01.000
provide tools for the broader ecosystem,

02:01.000 --> 02:04.000
and also for us to work ourselves.

02:04.000 --> 02:07.000
One of the things I want to mention is the security suite,

02:07.000 --> 02:10.000
because this is where I want to dive in.

02:10.000 --> 02:13.000
But first, the scratch, a ditch,

02:13.000 --> 02:19.000
bringing digital sovereignty to a federated state like Germany,

02:19.000 --> 02:24.000
is a complex thing.

02:24.000 --> 02:27.000
Regardless of which definition you follow,

02:27.000 --> 02:29.000
all definitions of digital sovereignty,

02:29.000 --> 02:32.000
it's some degree boiled down to the four freedoms.

02:32.000 --> 02:35.000
And at that sense, we don't really have a choice,

02:35.000 --> 02:36.000
but to use open source,

02:36.000 --> 02:39.000
and bring free software to the public administration,

02:39.000 --> 02:41.000
and this is what the core product of us,

02:41.000 --> 02:43.000
the open desk really does.

02:43.000 --> 02:48.000
It brings collaboration suite for office,

02:48.000 --> 02:51.000
to the administration, packaging what existed before,

02:51.000 --> 02:53.000
of course, where we didn't invent mail.

02:53.000 --> 02:56.000
We take mail systems that existed before,

02:56.000 --> 02:58.000
there's a tough cut in sight, of course.

02:58.000 --> 03:01.000
File sharing, video and project management,

03:01.000 --> 03:03.000
are things that pre-exist,

03:03.000 --> 03:06.000
but we make them into a coherent thing

03:06.000 --> 03:09.000
that the public administration now can rely on.

03:09.000 --> 03:14.000
That thing is surprisingly hard to,

03:14.000 --> 03:19.000
well, to formally make secure, to formally get right.

03:19.000 --> 03:20.000
But this is what I have to do.

03:20.000 --> 03:23.000
We have to put this thing into the public administration,

03:23.000 --> 03:25.000
a highly regulated thing, and people are curious,

03:25.000 --> 03:27.000
curious about security, this new thing,

03:27.000 --> 03:29.000
does it work, does it not?

03:29.000 --> 03:31.000
Just to give you a size,

03:31.000 --> 03:34.000
the open desk is 100% Kubernetes based,

03:34.000 --> 03:36.000
so all we do is contain us on hand files,

03:36.000 --> 03:39.000
and we have about 100 containers,

03:39.000 --> 03:43.000
until it scales, then it's become larger, of course.

03:43.000 --> 03:46.000
So it's a rather big thing,

03:46.000 --> 03:51.000
and that's problematic, that's problematic,

03:51.000 --> 03:54.000
because it's open source,

03:54.000 --> 03:56.000
everyone can look inside,

03:56.000 --> 03:58.000
but we have software as a service offerings,

03:58.000 --> 04:00.000
we have on premises,

04:00.000 --> 04:04.000
everyone can just check out the hand file and get cracking,

04:04.000 --> 04:06.000
that has its upside.

04:06.000 --> 04:08.000
The downside is everyone can look inside,

04:08.000 --> 04:09.000
everyone gets the containers,

04:09.000 --> 04:11.000
and everyone sees the whole supply chain,

04:11.000 --> 04:14.000
the whole code base, everything inside,

04:14.000 --> 04:17.000
and people get curious, what do I see,

04:17.000 --> 04:22.000
and they ask, is it a problem,

04:22.000 --> 04:23.000
right?

04:23.000 --> 04:27.000
There are bound to be CVs somewhere in there,

04:27.000 --> 04:29.000
and we need to manage that.

04:29.000 --> 04:31.000
So on that scale,

04:31.000 --> 04:33.000
we have to figure out a way

04:33.000 --> 04:37.000
to get into this sort of management.

04:37.000 --> 04:39.000
The next thing, by the way,

04:39.000 --> 04:42.000
some resilience actually states, you have to have an S-bomb,

04:42.000 --> 04:44.000
so people know why I have an S-bomb,

04:44.000 --> 04:46.000
they don't want to do it themselves,

04:46.000 --> 04:49.000
so how do we go about that?

04:49.000 --> 04:51.000
Quick hot take on S-bombs,

04:51.000 --> 04:54.000
and in this room, this is common knowledge,

04:54.000 --> 04:56.000
but not everywhere else.

04:56.000 --> 04:59.000
S-bombs are,

04:59.000 --> 05:02.000
to get a certain amount of S-bomb,

05:02.000 --> 05:04.000
a certain data sets of it,

05:04.000 --> 05:05.000
this is super easy,

05:05.000 --> 05:07.000
the last 20% is where things get messy,

05:07.000 --> 05:09.000
versions of mismatched packages,

05:09.000 --> 05:12.000
of wrongly identified metadata.

05:12.000 --> 05:13.000
Yeah,

05:13.000 --> 05:16.000
preaching to the choir here.

05:16.000 --> 05:19.000
Next thing is hot take about S-b-e,

05:19.000 --> 05:20.000
CV-matching is hard.

05:20.000 --> 05:23.000
It's about as annoying as the S-bomb before,

05:23.000 --> 05:25.000
and if the S-bomb before wasn't fun,

05:25.000 --> 05:28.000
it's not going to be fun as well.

05:28.000 --> 05:33.000
So, even if I succeed in creating my S-bomb,

05:33.000 --> 05:35.000
and match that with CV,

05:35.000 --> 05:37.000
my customers are going to have different tools.

05:37.000 --> 05:40.000
They had different tools in the past,

05:40.000 --> 05:42.000
so this is discussion, right?

05:42.000 --> 05:44.000
I have to discuss what exactly are we seeing,

05:44.000 --> 05:46.000
who is doing what,

05:46.000 --> 05:51.000
and there are things that are just irrelevant,

05:51.000 --> 05:53.000
I think it was last month.

05:53.000 --> 05:56.000
I had the great case of a large CD,

05:56.000 --> 05:57.000
it was, I don't know,

05:57.000 --> 05:58.000
it was 8.6,

05:58.000 --> 06:00.000
but it was a high CV-e on tar,

06:00.000 --> 06:01.000
from 2005,

06:01.000 --> 06:04.000
stating that if you unpack something with tar,

06:04.000 --> 06:09.000
it could go into the wrong places,

06:09.000 --> 06:11.000
and tar doesn't mention that in the UI,

06:11.000 --> 06:13.000
and the developer said,

06:13.000 --> 06:14.000
I don't have the UI,

06:14.000 --> 06:15.000
and the won't fix.

06:15.000 --> 06:17.000
It's there till now.

06:17.000 --> 06:20.000
There are annoying things that you just have to write,

06:20.000 --> 06:22.000
but firmly there is a large CV in it,

06:22.000 --> 06:23.000
it's annoying.

06:23.000 --> 06:26.000
So, in comes the Vax.

06:26.000 --> 06:29.000
Again, I think the room kind of knows,

06:29.000 --> 06:30.000
but Vax,

06:30.000 --> 06:33.000
this standard for basically giving that thumbs up thumbs down,

06:33.000 --> 06:38.000
is this CV-e actually a problem, or is it not?

06:38.000 --> 06:40.000
Now we can put this together.

06:40.000 --> 06:43.000
Suddenly, I have a data set that,

06:43.000 --> 06:45.000
at least, in theory,

06:45.000 --> 06:48.000
kind of solves all my problems,

06:48.000 --> 06:50.000
and this is what we now deal with the open desk.

06:50.000 --> 06:52.000
We build the S1s,

06:52.000 --> 06:54.000
first, of course, someone has to,

06:54.000 --> 06:56.000
and we distribute them.

06:56.000 --> 06:58.000
We directly distribute them as visible,

06:58.000 --> 07:00.000
as the image as well.

07:00.000 --> 07:02.000
This is just SCA, right?

07:02.000 --> 07:04.000
Everyone could have looked at the image themselves.

07:04.000 --> 07:06.000
There is no secret inside.

07:06.000 --> 07:08.000
The S1 is, of course,

07:08.000 --> 07:10.000
attested to the image.

07:10.000 --> 07:12.000
The CV information as well,

07:12.000 --> 07:15.000
with the caveat that we need to have life or else

07:15.000 --> 07:17.000
for updates, I get that.

07:17.000 --> 07:19.000
And the sample Vax.

07:19.000 --> 07:22.000
So, when I distribute an open desk image,

07:22.000 --> 07:23.000
it contains,

07:23.000 --> 07:25.000
not just the image itself,

07:25.000 --> 07:27.000
but attested to it.

07:27.000 --> 07:29.000
We have the whole S1, the whole CV,

07:29.000 --> 07:32.000
all CV is with life update,

07:32.000 --> 07:36.000
and the current Vax situation at the time of a testing.

07:36.000 --> 07:38.000
Sometimes they get updates.

07:38.000 --> 07:42.000
And this is something my users can now work with differently.

07:42.000 --> 07:45.000
Now, they get something from me.

07:45.000 --> 07:47.000
They get the assessment.

07:47.000 --> 07:50.000
They get to see what are the CVs,

07:50.000 --> 07:53.000
other problems inside, or other not.

07:53.000 --> 07:56.000
And this, I hope you can see it down there.

07:56.000 --> 07:59.000
This kind of formed our new supply chain in things.

07:59.000 --> 08:01.000
We have,

08:01.000 --> 08:05.000
so maybe one thing I have to emphasise,

08:05.000 --> 08:09.000
the most components from the open desk are vendor driven.

08:09.000 --> 08:11.000
As I said, we didn't invent mail.

08:11.000 --> 08:14.000
We use someone who does mail for us.

08:14.000 --> 08:16.000
So, this is what I call a vendor,

08:16.000 --> 08:17.000
and they have experts.

08:17.000 --> 08:19.000
Whenever there's any CV popping up,

08:19.000 --> 08:20.000
and I want, I ask,

08:20.000 --> 08:21.000
is that a problem?

08:21.000 --> 08:24.000
They, in a second, they say yes or no.

08:24.000 --> 08:25.000
Right?

08:25.000 --> 08:26.000
This is expert knowledge.

08:26.000 --> 08:28.000
Now, the first step we did is,

08:28.000 --> 08:32.000
okay, we centralized the concept of building

08:32.000 --> 08:34.000
S-bombs, matching CVEs,

08:34.000 --> 08:36.000
because we don't want 10 different tools.

08:36.000 --> 08:39.000
Take a central tool just to do that.

08:39.000 --> 08:42.000
And all I want is your expert information.

08:42.000 --> 08:43.000
Give me that.

08:43.000 --> 08:45.000
Give me that expert information.

08:45.000 --> 08:46.000
Give me the Vax.

08:46.000 --> 08:49.000
And I'm just redistributing it to my users.

08:49.000 --> 08:52.000
Maybe I have to layer it a little bit,

08:52.000 --> 08:54.000
it's on the next slide.

08:54.000 --> 08:56.000
Ideally, and this is something,

08:56.000 --> 09:00.000
some of the supplies are already moving towards.

09:00.000 --> 09:02.000
They do it themselves, of course.

09:02.000 --> 09:03.000
Right?

09:03.000 --> 09:04.000
They have to supply,

09:04.000 --> 09:06.000
they make the S-bombs themselves.

09:06.000 --> 09:08.000
So, we are slowly changing from I,

09:08.000 --> 09:09.000
make the S-bombs,

09:09.000 --> 09:11.000
and I make the CV management,

09:11.000 --> 09:13.000
to they supply it.

09:13.000 --> 09:14.000
They create themselves,

09:14.000 --> 09:15.000
and still we are working

09:15.000 --> 09:17.000
about OCI organizations.

09:17.000 --> 09:19.000
All the data still works directly,

09:20.000 --> 09:21.000
runs with the image.

09:21.000 --> 09:23.000
It's as public S, the image.

09:23.000 --> 09:25.000
If it wasn't an in public image,

09:25.000 --> 09:27.000
it's about a hidden aspect.

09:27.000 --> 09:28.000
That's the ideal.

09:28.000 --> 09:30.000
This is where we slowly moving towards.

09:30.000 --> 09:32.000
So, you can see, if I come from here,

09:32.000 --> 09:34.000
I just inject the concept of,

09:34.000 --> 09:35.000
this is S-ca.

09:35.000 --> 09:36.000
So, this is the S-bombs.

09:36.000 --> 09:37.000
This is the matching.

09:37.000 --> 09:40.000
All I really need from you is the expert knowledge.

09:40.000 --> 09:42.000
And the next step,

09:42.000 --> 09:44.000
if you want to enhance this,

09:44.000 --> 09:45.000
because like there is,

09:45.000 --> 09:48.000
there are more customers asking the same questions.

09:48.000 --> 09:52.000
I'm just consuming your data then.

09:52.000 --> 09:55.000
And the need part about this process,

09:55.000 --> 09:56.000
and I think this is something

09:56.000 --> 09:58.000
that hasn't been stressed enough in the recent times.

09:58.000 --> 10:00.000
This is completely recursive.

10:00.000 --> 10:02.000
And I'm just talking about containers at the moment.

10:02.000 --> 10:04.000
This can of course apply to packages,

10:04.000 --> 10:07.000
but what we find very important is

10:07.000 --> 10:09.000
it applies even to,

10:09.000 --> 10:11.000
to instances, for instance.

10:11.000 --> 10:14.000
We now have a layered system of,

10:14.000 --> 10:18.000
a fixed, of a fixed image of a fixed state.

10:18.000 --> 10:20.000
So, I can, for instance, say,

10:20.000 --> 10:22.000
my upstream supplier,

10:22.000 --> 10:24.000
the upstream project, anyone,

10:24.000 --> 10:27.000
has a vulnerability that is true.

10:27.000 --> 10:29.000
A true vulnerability.

10:29.000 --> 10:31.000
And even the vendor, for instance, couldn't fix it.

10:31.000 --> 10:33.000
It's still in the certain use case.

10:33.000 --> 10:34.000
It's still a true vulnerability.

10:34.000 --> 10:36.000
I just wouldn't have the use case.

10:36.000 --> 10:39.000
That use case, for instance, for me,

10:39.000 --> 10:42.000
once it's part of the open test,

10:42.000 --> 10:43.000
maybe if it gets changed,

10:43.000 --> 10:45.000
we fix this vulnerability.

10:45.000 --> 10:46.000
So, we can untick this,

10:46.000 --> 10:49.000
or in the hand file, then we can tick it as well.

10:49.000 --> 10:51.000
So, this is really what we do, right?

10:51.000 --> 10:54.000
We attest to the image, all the hand file.

10:54.000 --> 10:57.000
The idea of whether or not something is,

10:57.000 --> 11:00.000
the concept of the response and the vulnerability

11:00.000 --> 11:02.000
management, because this is exactly the scratch

11:02.000 --> 11:04.000
we have to each at the moment.

11:04.000 --> 11:07.000
And our users get exactly this information.

11:07.000 --> 11:09.000
So, they get live information on what is affected,

11:09.000 --> 11:10.000
what not.

11:10.000 --> 11:13.000
The whole idea is just to reduce the workload.

11:13.000 --> 11:16.000
CVEs shouldn't be large numbers,

11:16.000 --> 11:18.000
that you just don't ignore it.

11:18.000 --> 11:19.000
Just ignore it.

11:19.000 --> 11:23.000
They have to be broken down wherever they come up.

11:23.000 --> 11:27.000
And just two positives should tick it down.

11:27.000 --> 11:29.000
So, ideally, and this is really what we do,

11:29.000 --> 11:33.000
the last instance should only on rare occasions.

11:33.000 --> 11:35.000
When a true CVEs really comes around,

11:35.000 --> 11:37.000
get that notification.

11:37.000 --> 11:39.000
Everything else shouldn't even reach the last instance.

11:39.000 --> 11:42.000
And this is exactly what we're doing at the moment.

11:42.000 --> 11:47.000
This is exactly the target that we are currently working with.

11:47.000 --> 11:50.000
I said, tool chain.

11:50.000 --> 11:53.000
What we use is a tool called DeafGuard.

11:53.000 --> 11:55.000
This is basically an HGPL.

11:55.000 --> 11:57.000
Five minutes, yes.

11:57.000 --> 12:00.000
An HGPL project from OSP.

12:00.000 --> 12:04.000
It's, of course, I said we have the shared infrastructure

12:04.000 --> 12:06.000
that's available for the public administration.

12:06.000 --> 12:09.000
As a hosted service, there are various other instances as well.

12:09.000 --> 12:13.000
And this is our attempt to create a free reference

12:13.000 --> 12:17.000
tooling for security metadata, especially for CVEs.

12:17.000 --> 12:20.000
Because this is one of the problems we are going to face

12:20.000 --> 12:22.000
with the several zillions, right?

12:22.000 --> 12:24.000
If everyone is starting to create S-bombs,

12:24.000 --> 12:27.000
especially looking into open solutions.

12:27.000 --> 12:31.000
And we don't have one algorithmic thing that works.

12:31.000 --> 12:34.000
Everyone's going to just have different answers.

12:34.000 --> 12:36.000
And this, I don't think, is the right thing.

12:36.000 --> 12:39.000
So what we do with DeafGuard, we put the focus

12:39.000 --> 12:41.000
into what really is CV matching.

12:41.000 --> 12:42.000
Not yet the S-bombs.

12:42.000 --> 12:45.000
This is what we take from other sources.

12:45.000 --> 12:49.000
And we find out what can we, what can we all agree on

12:49.000 --> 12:51.000
is a correct matching.

12:51.000 --> 12:54.000
And the rest of it is really just an interface

12:54.000 --> 12:56.000
to your attestations.

12:56.000 --> 12:58.000
At the same time, if I put enough attestations,

12:58.000 --> 13:00.000
it becomes my central hub.

13:00.000 --> 13:02.000
But this is just by accident.

13:03.000 --> 13:06.000
And apart from this, as I said, we are the,

13:06.000 --> 13:09.000
we are shared infrastructure for the public administration.

13:09.000 --> 13:12.000
We provide the CSF and the VX live feed

13:12.000 --> 13:14.000
for our projects on the platform.

13:14.000 --> 13:17.000
Such that not everyone has to provide these things

13:17.000 --> 13:20.000
and we need them for the open disk anyway.

13:20.000 --> 13:24.000
Large story ahead, the general public administration

13:24.000 --> 13:26.000
realized that the dependency, especially on containers,

13:26.000 --> 13:31.000
with a huge container or cloud strategy, is massive.

13:32.000 --> 13:36.000
Most supply chains of containers are very centralized.

13:36.000 --> 13:38.000
And not like the decentralized things

13:38.000 --> 13:40.000
that we know from operating systems in the past.

13:40.000 --> 13:44.000
And this is something we have to kind of work with.

13:44.000 --> 13:47.000
And this is a large paper SSDLC with open code

13:47.000 --> 13:52.000
and the BSI from Germany on what can be done about this.

13:52.000 --> 13:59.000
And one piece of answer of this is that the public administration

13:59.000 --> 14:03.000
started sharing their own hardened container images,

14:03.000 --> 14:06.000
following exactly the paradigm as a state it,

14:06.000 --> 14:11.000
with clear one-size-fits-all S-bombs and VX information.

14:11.000 --> 14:16.000
And the clear policy gate, if the containers are not accurately

14:16.000 --> 14:19.000
vexed, they are just not managed.

14:19.000 --> 14:21.000
So this is kind of the policy we had the moment go with,

14:21.000 --> 14:23.000
but the system is growing.

14:23.000 --> 14:28.000
And it is designed to harbor the images of entities,

14:28.000 --> 14:29.000
using their own edge for us.

14:29.000 --> 14:31.000
We distribute the things of open disk.

14:31.000 --> 14:35.000
The Ministry of Foreign Affairs does exactly the same thing

14:35.000 --> 14:38.000
as they do for their platform or the data.

14:38.000 --> 14:40.000
Management platforms.

14:40.000 --> 14:42.000
And I think this is very similar.

14:42.000 --> 14:45.000
Some of you may be know the iron bank of the US military.

14:45.000 --> 14:47.000
Similar concept.

14:47.000 --> 14:50.000
But more decentralized.

14:50.000 --> 14:54.000
I think I'm right on time, so if there are any questions,

14:54.000 --> 15:04.000
or clamping.

15:04.000 --> 15:07.000
Questions?

15:07.000 --> 15:08.000
Yes.

15:19.000 --> 15:20.000
Not yet.

15:20.000 --> 15:26.000
Sorry, the question is, can a private company join this container registry?

15:26.000 --> 15:28.000
The thing is, at the moment, not.

15:28.000 --> 15:36.000
It's designed to feed the contents to help us share the contents that we have ourselves.

15:36.000 --> 15:42.000
VIA, a public entity, containers, of course, can enter.

15:42.000 --> 15:46.000
And we are currently looking into the idea of how can we federate this.

15:46.000 --> 15:53.000
So for instance, salsa can provide a way for us to inject any source into this.

15:53.000 --> 15:56.000
But then we have to focus on the sovereignty part of things.

15:56.000 --> 15:57.000
So we are interested.

15:57.000 --> 15:59.000
We don't know how yet.

15:59.000 --> 16:01.000
Thank you very much, Julian.

16:01.000 --> 16:02.000
Sorry.