2021-12-27 05:45:03 +01:00
|
|
|
1
|
|
|
|
00:00:00,880 --> 00:00:04,719
|
|
|
|
and I'll pass over the mic all right
|
|
|
|
|
|
|
|
2
|
|
|
|
00:00:02,638 --> 00:00:07,278
|
|
|
|
thank you
|
|
|
|
|
|
|
|
3
|
|
|
|
00:00:04,719 --> 00:00:09,599
|
|
|
|
yeah great, good morning good afternoon
|
|
|
|
|
|
|
|
4
|
|
|
|
00:00:07,278 --> 00:00:12,719
|
|
|
|
and even good evening for some of you
|
|
|
|
|
|
|
|
5
|
|
|
|
00:00:09,599 --> 00:00:14,879
|
|
|
|
um so um i'm really glad and uh
|
|
|
|
|
|
|
|
6
|
|
|
|
00:00:12,718 --> 00:00:16,480
|
|
|
|
we are glad to present about MISP today
|
|
|
|
|
|
|
|
7
|
|
|
|
00:00:14,880 --> 00:00:18,719
|
|
|
|
and so it's a
|
|
|
|
|
|
|
|
8
|
|
|
|
00:00:16,480 --> 00:00:20,240
|
|
|
|
double series of workshops so we start
|
|
|
|
|
|
|
|
9
|
|
|
|
00:00:18,719 --> 00:00:20,799
|
|
|
|
with a workshop of the introduction and
|
|
|
|
|
|
|
|
10
|
|
|
|
00:00:20,239 --> 00:00:22,799
|
|
|
|
we go
|
|
|
|
|
|
|
|
11
|
|
|
|
00:00:20,800 --> 00:00:23,839
|
2022-02-06 17:25:12 +01:00
|
|
|
more deeper tomorrow in that second
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
12
|
|
|
|
00:00:22,800 --> 00:00:26,160
|
|
|
|
workshop
|
|
|
|
|
|
|
|
13
|
|
|
|
00:00:23,839 --> 00:00:27,359
|
2022-02-06 17:25:12 +01:00
|
|
|
um i'm alexander noah I do work for
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
14
|
|
|
|
00:00:26,160 --> 00:00:30,640
|
|
|
|
CIRCL and
|
|
|
|
|
|
|
|
15
|
|
|
|
00:00:27,359 --> 00:00:34,800
|
|
|
|
i work in the MISP {inaudible}
|
|
|
|
|
|
|
|
16
|
|
|
|
00:00:30,640 --> 00:00:37,520
|
|
|
|
so today uh the agenda is the following
|
|
|
|
|
|
|
|
17
|
|
|
|
00:00:34,799 --> 00:00:38,78
|
|
|
|
uh we will do a quick introduction to
|
|
|
|
|
|
|
|
18
|
|
|
|
00:00:37,520 --> 00:00:41,920
|
|
|
|
MISP
|
|
|
|
|
|
|
|
19
|
|
|
|
00:00:38,79 --> 00:00:43,679
|
|
|
|
a kind of of one-hour sessions with
|
|
|
|
|
|
|
|
20
|
|
|
|
00:00:41,920 --> 00:00:46,239
|
|
|
|
all the detail about MISP and then a
|
|
|
|
|
|
|
|
21
|
|
|
|
00:00:43,679 --> 00:00:49,359
|
|
|
|
more like kind of usage deep dive
|
|
|
|
|
|
|
|
22
|
|
|
|
00:00:46,238 --> 00:00:52,558
|
|
|
|
of one hour where we do hands-on together
|
|
|
|
|
|
|
|
23
|
|
|
|
00:00:49,359 --> 00:00:55,519
|
|
|
|
um for the logistic aspect um
|
|
|
|
|
|
|
|
24
|
|
|
|
00:00:52,558 --> 00:00:55,839
|
|
|
|
in the chat room we will share with you
|
|
|
|
|
|
|
|
25
|
|
|
|
00:00:55,520 --> 00:00:57,520
|
|
|
|
uh
|
|
|
|
|
|
|
|
26
|
|
|
|
00:00:55,840 --> 00:00:59,520
|
|
|
|
all the details how to access the MISP
|
|
|
|
|
|
|
|
27
|
|
|
|
00:00:57,520 --> 00:01:00,399
|
|
|
|
instance so during the sessions in the
|
|
|
|
|
|
|
|
28
|
|
|
|
00:00:59,520 --> 00:01:02,239
|
|
|
|
workshop
|
|
|
|
|
|
|
|
29
|
|
|
|
00:01:00,399 --> 00:01:03,840
|
|
|
|
you can connect to a dedicated MISP
|
|
|
|
|
|
|
|
30
|
|
|
|
00:01:02,238 --> 00:01:05,840
|
|
|
|
system that we set up for you
|
|
|
|
|
|
|
|
31
|
|
|
|
00:01:03,840 --> 00:01:07,680
|
|
|
|
and this one will be used for all the
|
|
|
|
|
|
|
|
32
|
|
|
|
00:01:05,840 --> 00:01:10,79
|
|
|
|
hands-on that we will
|
|
|
|
|
|
|
|
33
|
|
|
|
00:01:07,680 --> 00:01:12,240
|
2022-02-06 17:25:12 +01:00
|
|
|
we do as I just mentioned we have a
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
34
|
|
|
|
00:01:10,79 --> 00:01:14,158
|
|
|
|
small short break of 15 minutes
|
|
|
|
|
|
|
|
35
|
|
|
|
00:01:12,239 --> 00:01:15,679
|
|
|
|
and then we will continue in the end
|
|
|
|
|
|
|
|
36
|
|
|
|
00:01:14,159 --> 00:01:18,960
|
|
|
|
{inaudible}
|
|
|
|
|
|
|
|
37
|
|
|
|
00:01:15,680 --> 00:01:20,880
|
|
|
|
depending of how far we are today uh
|
|
|
|
|
|
|
|
38
|
|
|
|
00:01:18,959 --> 00:01:22,959
|
|
|
|
we will maybe talk about the community
|
|
|
|
|
|
|
|
39
|
|
|
|
00:01:20,879 --> 00:01:24,719
|
|
|
|
building aspect but this is a topic for
|
|
|
|
|
|
|
|
40
|
|
|
|
00:01:22,959 --> 00:01:26,239
|
|
|
|
tomorrow obviously
|
|
|
|
|
|
|
|
41
|
|
|
|
00:01:24,719 --> 00:01:28,640
|
|
|
|
but if we have some time remaining we
|
|
|
|
|
|
|
|
42
|
|
|
|
00:01:26,239 --> 00:01:29,280
|
|
|
|
might uh talk about this and then we
|
|
|
|
|
|
|
|
43
|
|
|
|
00:01:28,640 --> 00:01:31,920
|
|
|
|
have a
|
|
|
|
|
|
|
|
44
|
|
|
|
00:01:29,280 --> 00:01:33,280
|
|
|
|
q&a sessions uh to discuss about the
|
|
|
|
|
|
|
|
45
|
|
|
|
00:01:31,920 --> 00:01:35,359
|
|
|
|
different {inaudible} and so on
|
|
|
|
|
|
|
|
46
|
|
|
|
00:01:33,280 --> 00:01:37,439
|
|
|
|
so don't hesitate to to put your
|
|
|
|
|
|
|
|
47
|
|
|
|
00:01:35,359 --> 00:01:39,438
|
|
|
|
question to zoom
|
|
|
|
|
|
|
|
48
|
|
|
|
00:01:37,438 --> 00:01:42,319
|
|
|
|
uh directly and we will try to answer live
|
|
|
|
|
|
|
|
50
|
|
|
|
00:01:40,799 --> 00:01:45,600
|
|
|
|
all those questions that you are asking
|
|
|
|
|
|
|
|
51
|
|
|
|
00:01:42,319 --> 00:01:45,599
|
|
|
|
during uh during this session
|
|
|
|
|
|
|
|
52
|
|
|
|
00:01:46,319 --> 00:01:50,239
|
|
|
|
so first of all welcome all as well from
|
|
|
|
|
|
|
|
53
|
|
|
|
00:01:48,478 --> 00:01:53,519
|
|
|
|
me so i'm Andras Iklody i'm
|
|
|
|
|
|
|
|
54
|
|
|
|
00:01:50,239 --> 00:01:56,798
|
|
|
|
also working at CIRCL working on MISP
|
|
|
|
|
|
|
|
55
|
|
|
|
00:01:53,519 --> 00:01:57,280
|
2022-02-06 17:25:12 +01:00
|
|
|
um to just kick things off um I think
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
56
|
|
|
|
00:01:56,799 --> 00:01:58,719
|
|
|
|
it's a good
|
|
|
|
|
|
|
|
57
|
|
|
|
00:01:57,280 --> 00:02:00,79
|
|
|
|
good moment to start a little bit about
|
|
|
|
|
|
|
|
58
|
|
|
|
00:01:58,718 --> 00:02:02,78
|
|
|
|
the history of how this whole thing
|
|
|
|
|
|
|
|
59
|
|
|
|
00:02:00,78 --> 00:02:04,879
|
|
|
|
started how MISP came about
|
|
|
|
|
|
|
|
60
|
|
|
|
00:02:02,78 --> 00:02:06,839
|
|
|
|
so just a quick introduction of where we
|
|
|
|
|
|
|
|
61
|
|
|
|
00:02:04,879 --> 00:02:09,519
|
|
|
|
came from and where where we are
|
|
|
|
|
|
|
|
62
|
|
|
|
00:02:06,840 --> 00:02:10,399
|
|
|
|
nowadays uh initially this whole thing
|
|
|
|
|
|
|
|
63
|
|
|
|
00:02:09,520 --> 00:02:13,520
|
|
|
|
for us with MISP
|
|
|
|
|
|
|
|
64
|
|
|
|
00:02:10,399 --> 00:02:14,959
|
|
|
|
started as part of a of a series of
|
|
|
|
|
|
|
|
65
|
|
|
|
00:02:13,520 --> 00:02:17,360
|
|
|
|
incidents that we had in
|
|
|
|
|
|
|
|
66
|
|
|
|
00:02:14,959 --> 00:02:19,759
|
|
|
|
back in 2012 between national and
|
|
|
|
|
|
|
|
67
|
|
|
|
00:02:17,360 --> 00:02:22,480
|
|
|
|
military CSIRTS at the time
|
|
|
|
|
|
|
|
68
|
|
|
|
00:02:19,759 --> 00:02:24,799
|
|
|
|
where we were basically investigating umattacks
|
|
|
|
|
|
|
|
70
|
|
|
|
00:02:23,520 --> 00:02:27,120
|
|
|
|
that were hitting several of the
|
|
|
|
|
|
|
|
71
|
|
|
|
00:02:24,800 --> 00:02:28,319
|
|
|
|
institutions at the at the time
|
|
|
|
|
|
|
|
72
|
|
|
|
00:02:27,120 --> 00:02:30,400
|
|
|
|
and one of the interesting things that
|
|
|
|
|
|
|
|
73
|
|
|
|
00:02:28,318 --> 00:02:31,759
|
|
|
|
we found was that even though we had
|
|
|
|
|
|
|
|
74
|
|
|
|
00:02:30,400 --> 00:02:33,519
|
|
|
|
something called the malware analysis
|
|
|
|
|
|
|
|
75
|
|
|
|
00:02:31,759 --> 00:02:35,120
|
|
|
|
working group which was this which is a
|
|
|
|
|
|
|
|
76
|
|
|
|
00:02:33,519 --> 00:02:37,360
|
|
|
|
group that was regularly meeting and
|
|
|
|
|
|
|
|
77
|
|
|
|
00:02:35,120 --> 00:02:39,680
|
|
|
|
discussing ongoing incidents
|
|
|
|
|
|
|
|
78
|
|
|
|
00:02:37,360 --> 00:02:40,720
|
|
|
|
we still had a massive gap in between
|
|
|
|
|
|
|
|
79
|
|
|
|
00:02:39,680 --> 00:02:42,80
|
|
|
|
those meetings
|
|
|
|
|
|
|
|
80
|
|
|
|
00:02:40,719 --> 00:02:44,318
|
|
|
|
where everyone was working in their own
|
|
|
|
|
|
|
|
81
|
|
|
|
00:02:42,80 --> 00:02:45,920
|
|
|
|
silo on basically the same attack and
|
|
|
|
|
|
|
|
82
|
|
|
|
00:02:44,318 --> 00:02:47,759
|
|
|
|
and doing reverse engineering of the
|
|
|
|
|
|
|
|
83
|
|
|
|
00:02:45,919 --> 00:02:50,0
|
|
|
|
165.92 --> 170
|
|
|
|
same attacks without
|
|
|
|
|
|
|
|
84
|
|
|
|
00:02:47,759 --> 00:02:53,439
|
|
|
|
having the ways, the means or the processes
|
|
|
|
|
|
|
|
86
|
|
|
|
00:02:51,120 --> 00:02:55,39
|
|
|
|
to directly share with our peers so we
|
|
|
|
|
|
|
|
87
|
|
|
|
00:02:53,439 --> 00:02:55,919
|
|
|
|
ended up with a lot of duplication of
|
|
|
|
|
|
|
|
88
|
|
|
|
00:02:55,39 --> 00:02:57,759
|
|
|
|
work which ended
|
|
|
|
|
|
|
|
89
|
|
|
|
00:02:55,919 --> 00:02:59,199
|
|
|
|
which was obviously frustrating from uh
|
|
|
|
|
|
|
|
90
|
|
|
|
00:02:57,759 --> 00:03:01,439
|
|
|
|
for many of us
|
|
|
|
|
|
|
|
91
|
|
|
|
00:02:59,199 --> 00:03:03,598
|
|
|
|
so Christophe Vandeplas at the time he
|
|
|
|
|
|
|
|
92
|
|
|
|
00:03:01,439 --> 00:03:06,318
|
|
|
|
was working at the belgian
|
|
|
|
|
|
|
|
93
|
|
|
|
00:03:03,598 --> 00:03:08,399
|
|
|
|
ministry of defense um in his free time
|
|
|
|
|
|
|
|
94
|
|
|
|
00:03:06,318 --> 00:03:10,318
|
|
|
|
wrote a platform called {inaudible}
|
|
|
|
|
|
|
|
95
|
|
|
|
00:03:08,400 --> 00:03:11,519
|
|
|
|
that later on ended up becoming MISP so
|
|
|
|
|
|
|
|
96
|
|
|
|
00:03:10,318 --> 00:03:13,280
|
|
|
|
the initial idea was
|
|
|
|
|
|
|
|
97
|
|
|
|
00:03:11,519 --> 00:03:14,800
|
|
|
|
really for reverse engineers to share
|
|
|
|
|
|
|
|
98
|
|
|
|
00:03:13,280 --> 00:03:15,439
|
|
|
|
the output of their work directly with
|
|
|
|
|
|
|
|
99
|
|
|
|
00:03:14,800 --> 00:03:18,719
|
|
|
|
their peers
|
|
|
|
|
|
|
|
100
|
|
|
|
00:03:15,439 --> 00:03:22,158
|
|
|
|
in a hosted platform and since then
|
|
|
|
|
|
|
|
101
|
|
|
|
00:03:18,719 --> 00:03:24,158
|
|
|
|
obviously MISP has evolved and changed
|
|
|
|
|
|
|
|
102
|
|
|
|
00:03:22,158 --> 00:03:25,840
|
|
|
|
the scope of what we were nowadays doing
|
|
|
|
|
|
|
|
103
|
|
|
|
00:03:24,158 --> 00:03:26,798
|
|
|
|
with MISP and what sort of information
|
|
|
|
|
|
|
|
104
|
|
|
|
00:03:25,840 --> 00:03:28,640
|
|
|
|
we're sharing
|
|
|
|
|
|
|
|
105
|
|
|
|
00:03:26,799 --> 00:03:30,159
|
|
|
|
but it all started with this and since
|
|
|
|
|
|
|
|
106
|
|
|
|
00:03:28,639 --> 00:03:30,878
|
|
|
|
then it has been an ongoing effort
|
|
|
|
|
|
|
|
107
|
|
|
|
00:03:30,158 --> 00:03:33,199
|
|
|
|
basically by
|
|
|
|
|
|
|
|
108
|
|
|
|
00:03:30,878 --> 00:03:35,199
|
|
|
|
a large community of different
|
|
|
|
|
|
|
|
109
|
|
|
|
00:03:33,199 --> 00:03:37,359
|
|
|
|
requirements and different needs
|
|
|
|
|
|
|
|
110
|
|
|
|
00:03:35,199 --> 00:03:39,359
|
|
|
|
and that has been building both the
|
|
|
|
|
|
|
|
111
|
|
|
|
00:03:37,360 --> 00:03:42,159
|
|
|
|
ideas that go into MISP as well as the
|
|
|
|
|
|
|
|
112
|
|
|
|
00:03:39,360 --> 00:03:42,159
|
|
|
|
software itself
|
|
|
|
|
|
|
|
113
|
|
|
|
00:03:43,919 --> 00:03:47,839
|
|
|
|
next slide please
|
|
|
|
|
|
|
|
114
|
|
|
|
00:03:48,479 --> 00:03:51,919
|
|
|
|
yeah so what is the background and why
|
|
|
|
|
|
|
|
115
|
|
|
|
00:03:51,199 --> 00:03:53,839
|
|
|
|
we are doing
|
|
|
|
|
|
|
|
116
|
|
|
|
00:03:51,919 --> 00:03:56,79
|
2022-02-06 17:25:12 +01:00
|
|
|
MISP it uh I think like Andras
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
117
|
|
|
|
00:03:53,840 --> 00:03:56,640
|
|
|
|
mentioned it started from a with a kind
|
|
|
|
|
|
|
|
118
|
|
|
|
00:03:56,80 --> 00:03:59,40
|
|
|
|
of
|
|
|
|
|
|
|
|
119
|
|
|
|
00:03:56,639 --> 00:04:00,479
|
|
|
|
{inaudible} project for a small set of
|
|
|
|
|
|
|
|
120
|
|
|
|
00:03:59,39 --> 00:04:03,598
|
|
|
|
CIRCL
|
|
|
|
|
|
|
|
121
|
|
|
|
00:04:00,479 --> 00:04:04,959
|
|
|
|
CIRCL is nowadays
|
|
|
|
|
|
|
|
122
|
|
|
|
00:04:03,598 --> 00:04:07,359
|
|
|
|
the CERT for the private sector, the
|
|
|
|
|
|
|
|
123
|
|
|
|
00:04:04,959 --> 00:04:08,959
|
|
|
|
community {inaudible} in luxembourg
|
|
|
|
|
|
|
|
124
|
|
|
|
00:04:07,360 --> 00:04:11,200
|
|
|
|
and we basically deal with the
|
|
|
|
|
|
|
|
125
|
|
|
|
00:04:08,959 --> 00:04:12,158
|
|
|
|
development of MISP not only for our use
|
|
|
|
|
|
|
|
126
|
|
|
|
00:04:11,199 --> 00:04:15,359
|
|
|
|
case but for many
|
|
|
|
|
|
|
|
127
|
|
|
|
00:04:12,158 --> 00:04:18,319
|
|
|
|
different users so we are called as
|
|
|
|
|
|
|
|
128
|
|
|
|
00:04:15,360 --> 00:04:19,439
|
|
|
|
a CERT we basically operate the
|
|
|
|
|
|
|
|
129
|
|
|
|
00:04:18,319 --> 00:04:22,478
|
|
|
|
development and we operate
|
|
|
|
|
|
|
|
130
|
|
|
|
00:04:19,439 --> 00:04:22,478
|
|
|
|
{inaudible} communities
|
|
|
|
|
|
|
|
131
|
|
|
|
00:04:23,600 --> 00:04:26,960
|
|
|
|
so a little bit about our involvement
|
|
|
|
|
|
|
|
132
|
|
|
|
00:04:26,639 --> 00:04:28,478
|
|
|
|
and
|
|
|
|
|
|
|
|
133
|
|
|
|
00:04:26,959 --> 00:04:30,79
|
|
|
|
why we're doing this in the first place
|
|
|
|
|
|
|
|
134
|
|
|
|
00:04:28,478 --> 00:04:32,560
|
|
|
|
so we as CIRCL we're funded by the
|
|
|
|
|
|
|
|
135
|
|
|
|
00:04:30,79 --> 00:04:35,680
|
|
|
|
Ministry of Economy to basically build
|
|
|
|
|
|
|
|
136
|
|
|
|
00:04:32,560 --> 00:04:37,600
|
|
|
|
security for the private sector uh and a
|
|
|
|
|
|
|
|
137
|
|
|
|
00:04:35,680 --> 00:04:39,199
|
|
|
|
lot of what we do involves uh open
|
|
|
|
|
|
|
|
138
|
|
|
|
00:04:37,600 --> 00:04:39,840
|
|
|
|
source software development so we're
|
|
|
|
|
|
|
|
139
|
|
|
|
00:04:39,199 --> 00:04:42,160
|
|
|
|
basically
|
|
|
|
|
|
|
|
140
|
|
|
|
00:04:39,839 --> 00:04:44,79
|
|
|
|
the funding that we get for the uh for
|
|
|
|
|
|
|
|
141
|
|
|
|
00:04:42,160 --> 00:04:45,199
|
|
|
|
activities also cover our development
|
|
|
|
|
|
|
|
142
|
|
|
|
00:04:44,79 --> 00:04:47,918
|
|
|
|
focus
|
|
|
|
|
|
|
|
143
|
|
|
|
00:04:45,199 --> 00:04:49,360
|
|
|
|
we're also uh besides just building the
|
|
|
|
|
|
|
|
144
|
|
|
|
00:04:47,918 --> 00:04:50,159
|
|
|
|
tools like {inaudible} mentioned we're
|
|
|
|
|
|
|
|
145
|
|
|
|
00:04:49,360 --> 00:04:52,479
|
|
|
|
also
|
|
|
|
|
|
|
|
146
|
|
|
|
00:04:50,160 --> 00:04:53,919
|
|
|
|
basically involved in a lot of sharing
|
|
|
|
|
|
|
|
147
|
|
|
|
00:04:52,478 --> 00:04:55,839
|
|
|
|
activities as well as our day-to-day
|
|
|
|
|
|
|
|
148
|
|
|
|
00:04:53,918 --> 00:04:58,399
|
|
|
|
operations we're users of the
|
|
|
|
|
|
|
|
149
|
|
|
|
00:04:55,839 --> 00:05:00,478
|
|
|
|
tool primarily as well we basically host
|
|
|
|
|
|
|
|
150
|
|
|
|
00:04:58,399 --> 00:05:02,719
|
|
|
|
a bunch of different communities for the
|
|
|
|
|
|
|
|
151
|
|
|
|
00:05:00,478 --> 00:05:05,439
|
|
|
|
uh national C-Certs for the
|
|
|
|
|
|
|
|
152
|
|
|
|
00:05:02,720 --> 00:05:07,919
|
|
|
|
luxembourgish private sector community
|
|
|
|
|
|
|
|
153
|
|
|
|
00:05:05,439 --> 00:05:09,680
|
|
|
|
for law enforcement uh organizations
|
|
|
|
|
|
|
|
154
|
|
|
|
00:05:07,918 --> 00:05:10,959
|
|
|
|
financial institutions and so on and so
|
|
|
|
|
|
|
|
155
|
|
|
|
00:05:09,680 --> 00:05:14,319
|
|
|
|
forth
|
|
|
|
|
|
|
|
156
|
|
|
|
00:05:10,959 --> 00:05:16,239
|
|
|
|
so so we're kind of uh
|
|
|
|
|
|
|
|
157
|
|
|
|
00:05:14,319 --> 00:05:18,240
|
|
|
|
in the game on both sides so to say that
|
|
|
|
|
|
|
|
158
|
|
|
|
00:05:16,240 --> 00:05:21,120
|
|
|
|
both as a
|
|
|
|
|
|
|
|
159
|
|
|
|
00:05:18,240 --> 00:05:22,0
|
|
|
|
318.24 --> 322
|
|
|
|
producer and as a consumer, also and the
|
|
|
|
|
|
|
|
160
|
|
|
|
00:05:21,120 --> 00:05:24,79
|
|
|
|
project was
|
|
|
|
|
|
|
|
161
|
|
|
|
00:05:22,0 --> 00:05:25,759
|
|
|
|
322 --> 325.759
|
|
|
|
co-financed by the European Union
|
|
|
|
|
|
|
|
162
|
|
|
|
00:05:24,79 --> 00:05:29,120
|
|
|
|
under the CEF project
|
|
|
|
|
|
|
|
163
|
|
|
|
00:05:25,759 --> 00:05:30,400
|
|
|
|
uh so this is also one of the sources of
|
|
|
|
|
|
|
|
164
|
|
|
|
00:05:29,120 --> 00:05:33,120
|
|
|
|
the income that we got basically to
|
|
|
|
|
|
|
|
165
|
|
|
|
00:05:30,399 --> 00:05:34,560
|
|
|
|
build the tool and as a FIRST member you
|
|
|
|
|
|
|
|
166
|
|
|
|
00:05:33,120 --> 00:05:36,79
|
|
|
|
have access to a MISP instance that is
|
|
|
|
|
|
|
|
167
|
|
|
|
00:05:34,560 --> 00:05:38,478
|
|
|
|
operated and
|
|
|
|
|
|
|
|
168
|
|
|
|
00:05:36,79 --> 00:05:40,0
|
|
|
|
336.08 --> 340
|
|
|
|
co-maintained by FIRST and CIRCL that
|
|
|
|
|
|
|
|
169
|
|
|
|
00:05:38,478 --> 00:05:41,680
|
|
|
|
you can get access to
|
|
|
|
|
|
|
|
170
|
|
|
|
00:05:40,0 --> 00:05:43,519
|
|
|
|
340 --> 343.52
|
|
|
|
so you just need to to use your
|
|
|
|
|
|
|
|
171
|
|
|
|
00:05:41,680 --> 00:05:45,680
|
|
|
|
traditional credential or
|
|
|
|
|
|
|
|
172
|
|
|
|
00:05:43,519 --> 00:05:47,359
|
|
|
|
access at first and you get access to
|
|
|
|
|
|
|
|
173
|
|
|
|
00:05:45,680 --> 00:05:49,600
|
|
|
|
this instance with information
|
|
|
|
|
|
|
|
174
|
|
|
|
00:05:47,360 --> 00:05:51,439
|
|
|
|
that you can use and so on we will talk
|
|
|
|
|
|
|
|
175
|
|
|
|
00:05:49,600 --> 00:05:54,160
|
|
|
|
about that later on
|
|
|
|
|
|
|
|
176
|
|
|
|
00:05:51,439 --> 00:05:55,600
|
2022-02-06 17:25:12 +01:00
|
|
|
so the main question and I think it's
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
177
|
|
|
|
00:05:54,160 --> 00:05:58,80
|
|
|
|
coming from this story uh
|
|
|
|
|
|
|
|
178
|
|
|
|
00:05:55,600 --> 00:05:59,600
|
|
|
|
as Andras mentioned from the early days
|
|
|
|
|
|
|
|
179
|
|
|
|
00:05:58,79 --> 00:06:01,758
|
|
|
|
MISP was
|
|
|
|
|
|
|
|
180
|
|
|
|
00:05:59,600 --> 00:06:03,840
|
|
|
|
focusing from a very specific aspect
|
|
|
|
|
|
|
|
181
|
|
|
|
00:06:01,759 --> 00:06:07,120
|
|
|
|
which was malware reversing and so on
|
|
|
|
|
|
|
|
182
|
|
|
|
00:06:03,839 --> 00:06:08,799
|
|
|
|
nowadays it's a threat intelligence sharing platforms we
|
|
|
|
|
|
|
|
183
|
|
|
|
00:06:07,120 --> 00:06:11,38
|
|
|
|
are basically sharing any kind of
|
|
|
|
|
|
|
|
184
|
|
|
|
00:06:08,800 --> 00:06:13,38
|
|
|
|
intelligence through uh through MISP
|
|
|
|
|
|
|
|
185
|
|
|
|
00:06:11,38 --> 00:06:14,478
|
|
|
|
um because we had an evolution of the
|
|
|
|
|
|
|
|
186
|
|
|
|
00:06:13,38 --> 00:06:16,399
|
|
|
|
time for the different things so
|
|
|
|
|
|
|
|
187
|
|
|
|
00:06:14,478 --> 00:06:18,879
|
|
|
|
and our main goals and that's very
|
|
|
|
|
|
|
|
188
|
|
|
|
00:06:16,399 --> 00:06:21,439
|
|
|
|
important for us it's an open source
|
|
|
|
|
|
|
|
189
|
|
|
|
00:06:18,879 --> 00:06:23,120
|
|
|
|
software so that means MISP will always
|
|
|
|
|
|
|
|
190
|
|
|
|
00:06:21,439 --> 00:06:23,519
|
|
|
|
remain an open source project we even
|
|
|
|
|
|
|
|
191
|
|
|
|
00:06:23,120 --> 00:06:26,0
|
|
|
|
383.12 --> 386
|
|
|
|
take
|
|
|
|
|
|
|
|
192
|
|
|
|
00:06:23,519 --> 00:06:26,879
|
|
|
|
some decisions within the project to
|
|
|
|
|
|
|
|
193
|
|
|
|
00:06:26,0 --> 00:06:29,120
|
|
|
|
386 --> 389.12
|
|
|
|
keep it as
|
|
|
|
|
|
|
|
194
|
|
|
|
00:06:26,879 --> 00:06:30,639
|
|
|
|
open source and that's that's really a
|
|
|
|
|
|
|
|
195
|
|
|
|
00:06:29,120 --> 00:06:32,720
|
|
|
|
key for us so it's really uh
|
|
|
|
|
|
|
|
196
|
|
|
|
00:06:30,639 --> 00:06:34,800
|
|
|
|
something that you can download yourself
|
|
|
|
|
|
|
|
197
|
|
|
|
00:06:32,720 --> 00:06:37,39
|
|
|
|
run on your infrastructure and so on
|
|
|
|
|
|
|
|
198
|
|
|
|
00:06:34,800 --> 00:06:38,240
|
|
|
|
you can really have the full control on
|
|
|
|
|
|
|
|
199
|
|
|
|
00:06:37,38 --> 00:06:40,639
|
|
|
|
the software stack
|
|
|
|
|
|
|
|
200
|
|
|
|
00:06:38,240 --> 00:06:42,0
|
|
|
|
398.24 --> 402
|
|
|
|
when you are using MISP and one of the
|
|
|
|
|
|
|
|
201
|
|
|
|
00:06:40,639 --> 00:06:43,38
|
|
|
|
goals of the software itself is to
|
|
|
|
|
|
|
|
202
|
|
|
|
00:06:42,0 --> 00:06:46,240
|
|
|
|
402 --> 406.24
|
|
|
|
collect information
|
|
|
|
|
|
|
|
203
|
|
|
|
00:06:43,38 --> 00:06:48,159
|
|
|
|
from other partners, from in the {inaudible}
|
|
|
|
|
|
|
|
204
|
|
|
|
00:06:46,240 --> 00:06:49,280
|
|
|
|
from automatic tools from different
|
|
|
|
|
|
|
|
205
|
|
|
|
00:06:48,160 --> 00:06:50,800
|
|
|
|
fields and so on
|
|
|
|
|
|
|
|
206
|
|
|
|
00:06:49,279 --> 00:06:53,198
|
|
|
|
that was really one of the initial goal
|
|
|
|
|
|
|
|
207
|
|
|
|
00:06:50,800 --> 00:06:55,680
|
|
|
|
of MISP is like being able to collect
|
|
|
|
|
|
|
|
208
|
|
|
|
00:06:53,199 --> 00:06:57,360
|
|
|
|
to get all this information into
|
|
|
|
|
|
|
|
209
|
|
|
|
00:06:55,680 --> 00:06:59,38
|
|
|
|
one place
|
|
|
|
|
|
|
|
210
|
|
|
|
00:06:57,360 --> 00:07:00,560
|
|
|
|
and then afterwards what you can do with
|
|
|
|
|
|
|
|
211
|
|
|
|
00:06:59,38 --> 00:07:02,719
|
|
|
|
it is to normalize
|
|
|
|
|
|
|
|
212
|
|
|
|
00:07:00,560 --> 00:07:03,839
|
|
|
|
correlate this information, extend the
|
|
|
|
|
|
|
|
213
|
|
|
|
00:07:02,720 --> 00:07:06,560
|
|
|
|
information and enrich
|
|
|
|
|
|
|
|
214
|
|
|
|
00:07:03,839 --> 00:07:08,879
|
|
|
|
information with more information and then
|
|
|
|
|
|
|
|
216
|
|
|
|
00:07:07,199 --> 00:07:10,800
|
|
|
|
really benefit from the sharing aspect
|
|
|
|
|
|
|
|
217
|
|
|
|
00:07:08,879 --> 00:07:13,120
|
|
|
|
of MISP and you can allow
|
|
|
|
|
|
|
|
218
|
|
|
|
00:07:10,800 --> 00:07:13,840
|
|
|
|
teams and community to collaborate
|
|
|
|
|
|
|
|
219
|
|
|
|
00:07:13,120 --> 00:07:16,478
|
|
|
|
and we have
|
|
|
|
|
|
|
|
220
|
|
|
|
00:07:13,839 --> 00:07:18,318
|
|
|
|
seen MISP for example use not only
|
|
|
|
|
|
|
|
221
|
|
|
|
00:07:16,478 --> 00:07:20,159
|
|
|
|
within different organizations but even
|
|
|
|
|
|
|
|
222
|
|
|
|
00:07:18,319 --> 00:07:21,759
|
|
|
|
within a single organization you can, for
|
|
|
|
|
|
|
|
223
|
|
|
|
00:07:20,160 --> 00:07:24,240
|
|
|
|
example run multiple MISP
|
|
|
|
|
|
|
|
224
|
|
|
|
00:07:21,759 --> 00:07:25,120
|
|
|
|
to collaborate directly on different
|
|
|
|
|
|
|
|
225
|
|
|
|
00:07:24,240 --> 00:07:28,79
|
|
|
|
investigations
|
|
|
|
|
|
|
|
226
|
|
|
|
00:07:25,120 --> 00:07:29,519
|
|
|
|
incidents and cases and obviously when
|
|
|
|
|
|
|
|
227
|
|
|
|
00:07:28,79 --> 00:07:31,279
|
|
|
|
you have all this information and all
|
|
|
|
|
|
|
|
228
|
|
|
|
00:07:29,519 --> 00:07:33,758
|
|
|
|
these analytic platform into MISP
|
|
|
|
|
|
|
|
229
|
|
|
|
00:07:31,279 --> 00:07:34,638
|
|
|
|
you are ready to use this information to
|
|
|
|
|
|
|
|
230
|
|
|
|
00:07:33,759 --> 00:07:36,960
|
|
|
|
for example
|
|
|
|
|
|
|
|
231
|
|
|
|
00:07:34,639 --> 00:07:39,840
|
|
|
|
feed your automatic protective tools
|
|
|
|
|
|
|
|
232
|
|
|
|
00:07:36,959 --> 00:07:42,0
|
|
|
|
456.96 --> 462
|
|
|
|
like intrusion detection systems,
|
|
|
|
|
|
|
|
233
|
|
|
|
00:07:39,839 --> 00:07:43,279
|
|
|
|
firewalls whatever and to feed
|
|
|
|
|
|
|
|
234
|
|
|
|
00:07:42,0 --> 00:07:45,598
|
|
|
|
462 --> 465.599
|
|
|
|
automatically those
|
|
|
|
|
|
|
|
235
|
|
|
|
00:07:43,279 --> 00:07:46,799
|
|
|
|
information to basically make protective
|
|
|
|
|
|
|
|
236
|
|
|
|
00:07:45,598 --> 00:07:50,319
|
|
|
|
measures
|
|
|
|
|
|
|
|
237
|
|
|
|
00:07:46,800 --> 00:07:50,319
|
|
|
|
in your environment
|
|
|
|
|
|
|
|
238
|
|
|
|
00:07:51,199 --> 00:07:55,840
|
|
|
|
so, start from the starting point that we
|
|
|
|
|
|
|
|
239
|
|
|
|
00:07:54,478 --> 00:07:57,680
|
|
|
|
already mentioned basically how we
|
|
|
|
|
|
|
|
240
|
|
|
|
00:07:55,839 --> 00:08:00,638
|
|
|
|
started out with MISP
|
|
|
|
|
|
|
|
241
|
|
|
|
00:07:57,680 --> 00:08:02,800
|
|
|
|
let's have a quick look at how uh the
|
|
|
|
|
|
|
|
242
|
|
|
|
00:08:00,639 --> 00:08:04,400
|
|
|
|
user base of MISP evolved in terms of
|
|
|
|
|
|
|
|
243
|
|
|
|
00:08:02,800 --> 00:08:06,0
|
|
|
|
482.8 --> 486
|
|
|
|
the different types of stakeholders
|
|
|
|
|
|
|
|
244
|
|
|
|
00:08:04,399 --> 00:08:08,560
|
|
|
|
within our own organizations and other organizations
|
|
|
|
|
|
|
|
246
|
|
|
|
00:08:07,120 --> 00:08:10,319
|
|
|
|
the reason for that is obviously that
|
|
|
|
|
|
|
|
247
|
|
|
|
00:08:08,560 --> 00:08:12,560
|
|
|
|
this drives the development process as well
|
|
|
|
|
|
|
|
249
|
|
|
|
00:08:10,800 --> 00:08:14,400
|
|
|
|
so the way MISP grows over time really
|
|
|
|
|
|
|
|
250
|
|
|
|
00:08:12,560 --> 00:08:14,800
|
|
|
|
depends on the type of users that are using
|
|
|
|
|
|
|
|
252
|
|
|
|
00:08:16,478 --> 00:08:18,319
|
|
|
|
the type of users that are requesting new
|
|
|
|
|
|
|
|
253
|
|
|
|
00:08:16,478 --> 00:08:20,159
|
|
|
|
features or that are providing pull
|
|
|
|
|
|
|
|
254
|
|
|
|
00:08:18,319 --> 00:08:22,639
|
|
|
|
requests on the project and providing code
|
|
|
|
|
|
|
|
256
|
|
|
|
00:08:20,720 --> 00:08:23,759
|
2022-02-06 17:25:12 +01:00
|
|
|
for the project so I said before
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
257
|
|
|
|
00:08:22,639 --> 00:08:26,160
|
|
|
|
initially
|
|
|
|
|
|
|
|
258
|
|
|
|
00:08:23,759 --> 00:08:27,759
|
|
|
|
the scope of MISP was very limited it
|
|
|
|
|
|
|
|
259
|
|
|
|
00:08:26,160 --> 00:08:29,360
|
|
|
|
was basically just the output of malware
|
|
|
|
|
|
|
|
260
|
|
|
|
00:08:27,759 --> 00:08:31,199
|
|
|
|
reversers which meant
|
|
|
|
|
|
|
|
261
|
|
|
|
00:08:29,360 --> 00:08:32,479
|
|
|
|
raw indicators that we were extracting
|
|
|
|
|
|
|
|
262
|
|
|
|
00:08:31,199 --> 00:08:34,560
|
|
|
|
during the process and that we're
|
|
|
|
|
|
|
|
263
|
|
|
|
00:08:32,479 --> 00:08:36,639
|
|
|
|
sharing directly
|
|
|
|
|
|
|
|
264
|
|
|
|
00:08:34,559 --> 00:08:38,79
|
|
|
|
with our partners, this meant very little
|
|
|
|
|
|
|
|
265
|
|
|
|
00:08:36,639 --> 00:08:39,519
|
|
|
|
analysis was done on each of these
|
|
|
|
|
|
|
|
266
|
|
|
|
00:08:38,80 --> 00:08:41,599
|
|
|
|
individual indicators there was very
|
|
|
|
|
|
|
|
267
|
|
|
|
00:08:39,519 --> 00:08:43,440
|
|
|
|
little information in terms of
|
|
|
|
|
|
|
|
268
|
|
|
|
00:08:41,599 --> 00:08:45,200
|
|
|
|
of why those data points are relevant in
|
|
|
|
|
|
|
|
269
|
|
|
|
00:08:43,440 --> 00:08:47,360
|
|
|
|
the long term how they are meant to be used
|
|
|
|
|
|
|
|
271
|
|
|
|
00:08:45,759 --> 00:08:49,519
|
|
|
|
from detection perspective they were
|
|
|
|
|
|
|
|
272
|
|
|
|
00:08:47,360 --> 00:08:52,480
|
|
|
|
really just the raw output
|
|
|
|
|
|
|
|
273
|
|
|
|
00:08:49,519 --> 00:08:54,0
|
|
|
|
529.519 --> 534
|
|
|
|
from the analysis process or the
|
|
|
|
|
|
|
|
274
|
|
|
|
00:08:52,480 --> 00:08:56,80
|
|
|
|
reversing process
|
|
|
|
|
|
|
|
275
|
|
|
|
00:08:54,0 --> 00:08:57,519
|
|
|
|
534 --> 537.519
|
|
|
|
now one of the side effects of this when
|
|
|
|
|
|
|
|
276
|
|
|
|
00:08:56,80 --> 00:08:59,440
|
|
|
|
you start building a collection within
|
|
|
|
|
|
|
|
277
|
|
|
|
00:08:57,519 --> 00:09:01,360
|
|
|
|
your organization of this information
|
|
|
|
|
|
|
|
278
|
|
|
|
00:08:59,440 --> 00:09:02,880
|
|
|
|
the security analysts are feeding your
|
|
|
|
|
|
|
|
279
|
|
|
|
00:09:01,360 --> 00:09:04,320
|
|
|
|
various protective tools become
|
|
|
|
|
|
|
|
280
|
|
|
|
00:09:02,879 --> 00:09:05,838
|
|
|
|
interested in that data set
|
|
|
|
|
|
|
|
281
|
|
|
|
00:09:04,320 --> 00:09:08,0
|
|
|
|
544.32 --> 548
|
|
|
|
because obviously whatever is targeting
|
|
|
|
|
|
|
|
282
|
|
|
|
00:09:05,839 --> 00:09:10,160
|
|
|
|
your organization or your direct peers
|
|
|
|
|
|
|
|
283
|
|
|
|
00:09:08,0 --> 00:09:11,360
|
|
|
|
548 --> 551.36
|
|
|
|
are probably the most relevant piece of
|
|
|
|
|
|
|
|
284
|
|
|
|
00:09:10,159 --> 00:09:13,39
|
|
|
|
information that you can use for
|
|
|
|
|
|
|
|
285
|
|
|
|
00:09:11,360 --> 00:09:16,159
|
|
|
|
detection
|
|
|
|
|
|
|
|
286
|
|
|
|
00:09:13,39 --> 00:09:19,39
|
|
|
|
so one of the first steps that we opened
|
|
|
|
|
|
|
|
288
|
|
|
|
00:09:16,958 --> 00:09:20,479
|
|
|
|
up to was basically involving our own
|
|
|
|
|
|
|
|
289
|
|
|
|
00:09:19,39 --> 00:09:23,278
|
|
|
|
security analyst with our
|
|
|
|
|
|
|
|
290
|
|
|
|
00:09:20,480 --> 00:09:24,320
|
|
|
|
own organizations so they can hook
|
|
|
|
|
|
|
|
291
|
|
|
|
00:09:23,278 --> 00:09:27,360
|
|
|
|
the output of
|
|
|
|
|
|
|
|
292
|
|
|
|
00:09:24,320 --> 00:09:30,80
|
|
|
|
of the reverse engineering team
|
|
|
|
|
|
|
|
293
|
|
|
|
00:09:27,360 --> 00:09:31,360
|
|
|
|
up to their SIEMs to their IDSs to
|
|
|
|
|
|
|
|
294
|
|
|
|
00:09:30,80 --> 00:09:33,360
|
|
|
|
their firewalls
|
|
|
|
|
|
|
|
295
|
|
|
|
00:09:31,360 --> 00:09:35,440
|
|
|
|
and to feed this data directly into
|
|
|
|
|
|
|
|
296
|
|
|
|
00:09:33,360 --> 00:09:36,720
|
|
|
|
their protective measures
|
|
|
|
|
|
|
|
297
|
|
|
|
00:09:35,440 --> 00:09:38,720
|
|
|
|
now one of the interesting things when
|
|
|
|
|
|
|
|
298
|
|
|
|
00:09:36,720 --> 00:09:40,800
|
|
|
|
you start doing that though is that you
|
|
|
|
|
|
|
|
299
|
|
|
|
00:09:38,720 --> 00:09:42,560
|
|
|
|
generate a new type of output which is
|
|
|
|
|
|
|
|
300
|
|
|
|
00:09:40,799 --> 00:09:44,559
|
|
|
|
timeliness for the data, freshness for
|
|
|
|
|
|
|
|
301
|
|
|
|
00:09:42,559 --> 00:09:45,838
|
|
|
|
the data as well as feedback on how
|
|
|
|
|
|
|
|
302
|
|
|
|
00:09:44,559 --> 00:09:47,838
|
|
|
|
useful the data was
|
|
|
|
|
|
|
|
303
|
|
|
|
00:09:45,839 --> 00:09:50,240
|
|
|
|
so we're very often when you're
|
|
|
|
|
|
|
|
304
|
|
|
|
00:09:47,839 --> 00:09:53,40
|
|
|
|
extracting information
|
|
|
|
|
|
|
|
305
|
|
|
|
00:09:50,240 --> 00:09:55,360
|
|
|
|
by sandboxing for example a lot of the
|
|
|
|
|
|
|
|
306
|
|
|
|
00:09:53,39 --> 00:09:57,679
|
|
|
|
data generated will be noise in the end
|
|
|
|
|
|
|
|
307
|
|
|
|
00:09:55,360 --> 00:09:59,759
|
|
|
|
and this noise will generate false
|
|
|
|
|
|
|
|
308
|
|
|
|
00:09:57,679 --> 00:10:02,159
|
|
|
|
positive alerts for example
|
|
|
|
|
|
|
|
309
|
|
|
|
00:09:59,759 --> 00:10:04,319
|
|
|
|
in your detection tools. Now feeding this
|
|
|
|
|
|
|
|
310
|
|
|
|
00:10:02,159 --> 00:10:06,559
|
|
|
|
information back
|
|
|
|
|
|
|
|
311
|
|
|
|
00:10:04,320 --> 00:10:10,559
|
|
|
|
to data gave it a whole new type of value
|
|
|
|
|
|
|
|
313
|
|
|
|
00:10:07,519 --> 00:10:12,159
|
|
|
|
we had freshness so if an older
|
|
|
|
|
|
|
|
314
|
|
|
|
00:10:10,559 --> 00:10:14,159
|
|
|
|
indicator was reused
|
|
|
|
|
|
|
|
315
|
|
|
|
00:10:12,159 --> 00:10:15,439
|
|
|
|
over time we saw that that is still
|
|
|
|
|
|
|
|
316
|
|
|
|
00:10:14,159 --> 00:10:18,160
|
|
|
|
something that is actively to be monitored
|
|
|
|
|
|
|
|
318
|
|
|
|
00:10:16,559 --> 00:10:19,838
|
|
|
|
and if we saw that something turned out
|
|
|
|
|
|
|
|
319
|
|
|
|
00:10:18,159 --> 00:10:21,199
|
|
|
|
to be a cleaned up host
|
|
|
|
|
|
|
|
320
|
|
|
|
00:10:19,839 --> 00:10:23,440
|
|
|
|
in the meanwhile or something was a
|
|
|
|
|
|
|
|
321
|
|
|
|
00:10:21,200 --> 00:10:25,200
|
|
|
|
false positive from the get-go
|
|
|
|
|
|
|
|
322
|
|
|
|
00:10:23,440 --> 00:10:28,399
|
|
|
|
we could feed that information back as well
|
|
|
|
|
|
|
|
324
|
|
|
|
00:10:27,399 --> 00:10:31,759
|
|
|
|
so suddenly once you have timeliness as
|
|
|
|
|
|
|
|
325
|
|
|
|
00:10:28,399 --> 00:10:33,759
|
|
|
|
well as the the raw data itself
|
|
|
|
|
|
|
|
326
|
|
|
|
00:10:31,759 --> 00:10:35,278
|
|
|
|
you get the intelligence analyst
|
|
|
|
|
|
|
|
327
|
|
|
|
00:10:33,759 --> 00:10:36,399
|
|
|
|
interested that are tracking the
|
|
|
|
|
|
|
|
328
|
|
|
|
00:10:35,278 --> 00:10:42,0
|
|
|
|
movements and the changes of how attackers operate
|
|
|
|
|
|
|
|
330
|
|
|
|
00:10:39,519 --> 00:10:42,639
|
|
|
|
uh over time so that means that usually
|
|
|
|
|
|
|
|
332
|
|
|
|
00:10:45,360 --> 00:10:47,199
|
|
|
|
back then especially in 2012 in most of our
|
|
|
|
|
|
|
|
333
|
|
|
|
00:10:45,360 --> 00:10:48,560
|
|
|
|
organizations the people that are doing
|
|
|
|
|
|
|
|
334
|
|
|
|
00:10:47,200 --> 00:10:50,560
|
|
|
|
intelligence and the people that were
|
|
|
|
|
|
|
|
335
|
|
|
|
00:10:48,559 --> 00:10:52,239
|
|
|
|
doing operations and security for the
|
|
|
|
|
|
|
|
336
|
|
|
|
00:10:50,559 --> 00:10:55,680
|
|
|
|
operations were usually working in their own silos
|
|
|
|
|
|
|
|
338
|
|
|
|
00:10:53,440 --> 00:10:57,40
|
|
|
|
so while there was obviously interaction
|
|
|
|
|
|
|
|
339
|
|
|
|
00:10:55,679 --> 00:10:58,958
|
|
|
|
between the teams, it was not as
|
|
|
|
|
|
|
|
340
|
|
|
|
00:10:57,39 --> 00:11:01,919
|
|
|
|
ingrained to work together
|
|
|
|
|
|
|
|
341
|
|
|
|
00:10:58,958 --> 00:11:03,599
|
|
|
|
between those type of roles but this
|
|
|
|
|
|
|
|
342
|
|
|
|
00:11:01,919 --> 00:11:04,0
|
|
|
|
661.92 --> 664
|
|
|
|
changed over time and one of the changes
|
|
|
|
|
|
|
|
344
|
|
|
|
00:11:04,0 --> 00:11:08,78
|
|
|
|
664 --> 668.079
|
|
|
|
that we saw happened was that the output
|
|
|
|
|
|
|
|
345
|
|
|
|
00:11:06,240 --> 00:11:10,240
|
|
|
|
of what the security analysts
|
|
|
|
|
|
|
|
346
|
|
|
|
00:11:08,78 --> 00:11:12,159
|
|
|
|
and the reversers and the analysts were
|
|
|
|
|
|
|
|
347
|
|
|
|
00:11:10,240 --> 00:11:14,480
|
|
|
|
outputting basically from the operation side
|
|
|
|
|
|
|
|
349
|
|
|
|
00:11:12,879 --> 00:11:16,399
|
|
|
|
became more and more interesting for the
|
|
|
|
|
|
|
|
350
|
|
|
|
00:11:14,480 --> 00:11:17,839
|
|
|
|
intelligence analysts that meant that
|
|
|
|
|
|
|
|
351
|
|
|
|
00:11:16,399 --> 00:11:19,919
|
|
|
|
if they were tracking a certain threat
|
|
|
|
|
|
|
|
352
|
|
|
|
00:11:17,839 --> 00:11:21,600
|
|
|
|
actor and they could attribute certain
|
|
|
|
|
|
|
|
353
|
|
|
|
00:11:19,919 --> 00:11:23,439
|
|
|
|
actions that they were seen in the
|
|
|
|
|
|
|
|
354
|
|
|
|
00:11:21,600 --> 00:11:25,519
|
|
|
|
network of the organization
|
|
|
|
|
|
|
|
355
|
|
|
|
00:11:23,440 --> 00:11:26,959
|
|
|
|
to the certain threat actor they could
|
|
|
|
|
|
|
|
356
|
|
|
|
00:11:25,519 --> 00:11:29,278
|
|
|
|
monitor for example how
|
|
|
|
|
|
|
|
357
|
|
|
|
00:11:26,958 --> 00:11:30,879
|
|
|
|
the given actor was changing how fast
|
|
|
|
|
|
|
|
358
|
|
|
|
00:11:29,278 --> 00:11:32,78
|
|
|
|
they were changing infrastructure
|
|
|
|
|
|
|
|
359
|
|
|
|
00:11:30,879 --> 00:11:34,0
|
|
|
|
690.88 --> 694
|
|
|
|
whether they were switching up their
|
|
|
|
|
|
|
|
360
|
|
|
|
00:11:32,78 --> 00:11:36,78
|
|
|
|
methodology and this
|
|
|
|
|
|
|
|
361
|
|
|
|
00:11:34,0 --> 00:11:37,519
|
|
|
|
694 --> 697.519
|
|
|
|
gave them a lot of idea of useful data
|
|
|
|
|
|
|
|
362
|
|
|
|
00:11:36,78 --> 00:11:39,199
|
|
|
|
of improving their libraries of the
|
|
|
|
|
|
|
|
363
|
|
|
|
00:11:37,519 --> 00:11:40,799
|
|
|
|
threat actors that they were tracking
|
|
|
|
|
|
|
|
364
|
|
|
|
00:11:39,200 --> 00:11:41,920
|
|
|
|
so suddenly we got this group interests
|
|
|
|
|
|
|
|
365
|
|
|
|
00:11:40,799 --> 00:11:43,838
|
|
|
|
as well and they were obviously
|
|
|
|
|
|
|
|
366
|
|
|
|
00:11:41,919 --> 00:11:44,879
|
|
|
|
producing data as well so nowadays if
|
|
|
|
|
|
|
|
367
|
|
|
|
00:11:43,839 --> 00:11:47,279
|
|
|
|
you look at MISP
|
|
|
|
|
|
|
|
368
|
|
|
|
00:11:44,879 --> 00:11:49,200
|
|
|
|
going from a raw indicator sharing platform
|
|
|
|
|
|
|
|
369
|
|
|
|
00:11:47,278 --> 00:11:50,399
|
|
|
|
that MISP was initially
|
|
|
|
|
|
|
|
370
|
|
|
|
00:11:49,200 --> 00:11:52,160
|
|
|
|
nowadays you have a lot of the high
|
|
|
|
|
|
|
|
371
|
|
|
|
00:11:50,399 --> 00:11:53,759
|
|
|
|
level threat intel information included
|
|
|
|
|
|
|
|
372
|
|
|
|
00:11:52,159 --> 00:11:56,720
|
|
|
|
with the data as well so you will see threat reports
|
|
|
|
|
|
|
|
374
|
|
|
|
00:11:54,879 --> 00:11:58,720
|
|
|
|
you will see interconnected information
|
|
|
|
|
|
|
|
375
|
|
|
|
00:11:56,720 --> 00:12:04,399
|
|
|
|
about threat actors modus operandi
|
|
|
|
|
|
|
|
377
|
|
|
|
00:12:01,839 --> 00:12:06,79
|
|
|
|
infrastructure impact and so on so forth
|
|
|
|
|
|
|
|
378
|
|
|
|
00:12:04,399 --> 00:12:07,360
|
|
|
|
these extra layers of information that
|
|
|
|
|
|
|
|
379
|
|
|
|
00:12:06,78 --> 00:12:08,719
|
|
|
|
we were missing initially
|
|
|
|
|
|
|
|
380
|
|
|
|
00:12:07,360 --> 00:12:10,0
|
|
|
|
727.36 --> 730
|
|
|
|
so this was the biggest change that we
|
|
|
|
|
|
|
|
381
|
|
|
|
00:12:08,720 --> 00:12:11,440
|
|
|
|
had over time within our own
|
|
|
|
|
|
|
|
382
|
|
|
|
00:12:10,0 --> 00:12:13,919
|
|
|
|
730 --> 733.92
|
|
|
|
organizations but
|
|
|
|
|
|
|
|
383
|
|
|
|
00:12:11,440 --> 00:12:15,519
|
|
|
|
obviously as a CSIRT that has
|
|
|
|
|
|
|
|
384
|
|
|
|
00:12:13,919 --> 00:12:17,199
|
|
|
|
different constituencies
|
|
|
|
|
|
|
|
385
|
|
|
|
00:12:15,519 --> 00:12:18,799
|
|
|
|
we're also interacting with the security
|
|
|
|
|
|
|
|
386
|
|
|
|
00:12:17,200 --> 00:12:20,720
|
|
|
|
teams of other organizations and one of
|
|
|
|
|
|
|
|
387
|
|
|
|
00:12:18,799 --> 00:12:22,319
|
|
|
|
the things we noticed early on was
|
|
|
|
|
|
|
|
388
|
|
|
|
00:12:20,720 --> 00:12:24,160
|
|
|
|
there's a lot of the issues that other
|
|
|
|
|
|
|
|
389
|
|
|
|
00:12:22,320 --> 00:12:25,600
|
|
|
|
types of organizations had internally
|
|
|
|
|
|
|
|
390
|
|
|
|
00:12:24,159 --> 00:12:28,800
|
|
|
|
with information sharing are very similar to ours
|
|
|
|
|
|
|
|
392
|
|
|
|
00:12:26,879 --> 00:12:30,958
|
|
|
|
so initially the first use case that we
|
|
|
|
|
|
|
|
393
|
|
|
|
00:12:28,799 --> 00:12:32,799
|
|
|
|
got that was different and from our
|
|
|
|
|
|
|
|
394
|
|
|
|
00:12:30,958 --> 00:12:36,719
|
|
|
|
normal security use case
|
|
|
|
|
|
|
|
395
|
|
|
|
00:12:32,799 --> 00:12:38,399
|
|
|
|
was basically the various financial
|
|
|
|
|
|
|
|
396
|
|
|
|
00:12:36,720 --> 00:12:39,920
|
|
|
|
organizations reaching out to us saying
|
|
|
|
|
|
|
|
397
|
|
|
|
00:12:38,399 --> 00:12:41,759
|
|
|
|
that their fraud teams were
|
|
|
|
|
|
|
|
398
|
|
|
|
00:12:39,919 --> 00:12:43,599
|
|
|
|
running into similar sort of issues with
|
|
|
|
|
|
|
|
399
|
|
|
|
00:12:41,759 --> 00:12:45,759
|
|
|
|
sharing between their teams,
|
|
|
|
|
|
|
|
400
|
|
|
|
00:12:43,600 --> 00:12:47,839
|
|
|
|
sharing with other partner teams,
|
|
|
|
|
|
|
|
401
|
|
|
|
00:12:45,759 --> 00:12:50,319
|
|
|
|
information about mule accounts and
|
|
|
|
|
|
|
|
402
|
|
|
|
00:12:47,839 --> 00:12:51,519
|
|
|
|
about other fraud related information
|
|
|
|
|
|
|
|
403
|
|
|
|
00:12:50,320 --> 00:12:53,680
|
|
|
|
so they reached out to us and
|
|
|
|
|
|
|
|
404
|
|
|
|
00:12:51,519 --> 00:12:54,480
|
|
|
|
basically their security teams reached
|
|
|
|
|
|
|
|
405
|
|
|
|
00:12:53,679 --> 00:12:57,199
|
|
|
|
out to us and said
|
|
|
|
|
|
|
|
406
|
|
|
|
00:12:54,480 --> 00:12:58,639
|
|
|
|
can't we just try to help them also
|
|
|
|
|
|
|
|
407
|
|
|
|
00:12:57,200 --> 00:13:00,0
|
|
|
|
777.2 --> 780
|
|
|
|
to share that sort of information
|
|
|
|
|
|
|
|
408
|
|
|
|
00:12:58,639 --> 00:13:01,759
|
|
|
|
through MISP directly, I mean we already
|
|
|
|
|
|
|
|
409
|
|
|
|
00:13:00,0 --> 00:13:03,200
|
|
|
|
780 --> 783.2
|
|
|
|
had the tooling in place
|
|
|
|
|
|
|
|
410
|
|
|
|
00:13:01,759 --> 00:13:05,200
|
|
|
|
it was just a question of changing the data model
|
|
|
|
|
|
|
|
412
|
|
|
|
00:13:05,200 --> 00:13:08,639
|
|
|
|
so we we started doing that for uh together
|
|
|
|
|
|
|
|
413
|
|
|
|
00:13:07,120 --> 00:13:10,480
|
|
|
|
with the financial sector initially
|
|
|
|
|
|
|
|
414
|
|
|
|
00:13:08,639 --> 00:13:12,0
|
|
|
|
788.639 --> 792
|
|
|
|
where we expanded the data model of MISP
|
|
|
|
|
|
|
|
415
|
|
|
|
00:13:10,480 --> 00:13:13,519
|
|
|
|
when we allowed for modeling of new
|
|
|
|
|
|
|
|
416
|
|
|
|
00:13:12,0 --> 00:13:15,919
|
|
|
|
792 --> 795.92
|
|
|
|
custom data types
|
|
|
|
|
|
|
|
417
|
|
|
|
00:13:13,519 --> 00:13:17,679
|
|
|
|
and it's even surprising to us at the
|
|
|
|
|
|
|
|
418
|
|
|
|
00:13:15,919 --> 00:13:20,319
|
|
|
|
time turned into a success
|
|
|
|
|
|
|
|
419
|
|
|
|
00:13:17,679 --> 00:13:21,599
|
|
|
|
very rapidly so nowadays we're involved
|
|
|
|
|
|
|
|
420
|
|
|
|
00:13:20,320 --> 00:13:22,959
|
|
|
|
with quite a few different types of
|
|
|
|
|
|
|
|
421
|
|
|
|
00:13:21,600 --> 00:13:25,519
|
|
|
|
organizations out there
|
|
|
|
|
|
|
|
422
|
|
|
|
00:13:22,958 --> 00:13:26,879
|
|
|
|
replicating the same scenario where for
|
|
|
|
|
|
|
|
423
|
|
|
|
00:13:25,519 --> 00:13:30,320
|
|
|
|
example law enforcement, where we initially had
|
|
|
|
|
|
|
|
425
|
|
|
|
00:13:28,320 --> 00:13:32,79
|
|
|
|
mostly contact with their security teams
|
|
|
|
|
|
|
|
426
|
|
|
|
00:13:30,320 --> 00:13:36,240
|
|
|
|
and helping them build data sets for bootstrapping their forensic
|
|
|
|
|
|
|
|
429
|
|
|
|
00:13:34,399 --> 00:13:38,480
|
|
|
|
investigations nowadays we have all
|
|
|
|
|
|
|
|
430
|
|
|
|
00:13:36,240 --> 00:13:40,959
|
|
|
|
sorts of information sharing involving
|
|
|
|
|
|
|
|
431
|
|
|
|
00:13:38,480 --> 00:13:45,278
|
|
|
|
uh for example uh seized goods information sharing from
|
|
|
|
|
|
|
|
433
|
|
|
|
00:13:42,639 --> 00:13:48,799
|
|
|
|
border control agencies uh law enforcement agencies
|
|
|
|
|
|
|
|
435
|
|
|
|
00:13:46,879 --> 00:13:51,120
|
|
|
|
sharing information about passenger information
|
|
|
|
|
|
|
|
436
|
|
|
|
00:13:48,799 --> 00:13:53,359
|
|
|
|
so a lot of the type of data
|
|
|
|
|
|
|
|
437
|
|
|
|
00:13:51,120 --> 00:13:55,360
|
|
|
|
sharing that was very unusual for us as
|
|
|
|
|
|
|
|
438
|
|
|
|
00:13:53,360 --> 00:13:58,79
|
|
|
|
a CSIRT initially
|
|
|
|
|
|
|
|
439
|
|
|
|
00:13:55,360 --> 00:13:58,879
|
|
|
|
now once you get all this data in a
|
|
|
|
|
|
|
|
440
|
|
|
|
00:13:58,78 --> 00:14:01,39
|
|
|
|
system and you
|
|
|
|
|
|
|
|
441
|
|
|
|
00:13:58,879 --> 00:14:04,399
|
|
|
|
started building a data set from your community
|
|
|
|
|
|
|
|
443
|
|
|
|
00:14:02,480 --> 00:14:06,79
|
|
|
|
you start to see trends in the data set
|
|
|
|
|
|
|
|
444
|
|
|
|
00:14:04,399 --> 00:14:07,839
|
|
|
|
and this is what gets
|
|
|
|
|
|
|
|
445
|
|
|
|
00:14:06,78 --> 00:14:09,759
|
|
|
|
for example our risk analysis team
|
|
|
|
|
|
|
|
446
|
|
|
|
00:14:07,839 --> 00:14:11,440
|
|
|
|
interested in it the moment that you're
|
|
|
|
|
|
|
|
447
|
|
|
|
00:14:09,759 --> 00:14:12,639
|
|
|
|
seeing how attackers are changing their
|
|
|
|
|
|
|
|
448
|
|
|
|
00:14:11,440 --> 00:14:15,199
|
|
|
|
trends over time
|
|
|
|
|
|
|
|
449
|
|
|
|
00:14:12,639 --> 00:14:18,719
|
|
|
|
you can better advise your constituency your customers and so on
|
|
|
|
|
|
|
|
451
|
|
|
|
00:14:17,360 --> 00:14:22,160
|
|
|
|
about the different risks that they might be facing and the
|
|
|
|
|
|
|
|
453
|
|
|
|
00:14:20,958 --> 00:14:24,879
|
|
|
|
different risks that they should be preparing for
|
|
|
|
|
|
|
|
455
|
|
|
|
00:14:23,278 --> 00:14:26,958
|
|
|
|
and preparing the organizations for
|
|
|
|
|
|
|
|
456
|
|
|
|
00:14:24,879 --> 00:14:29,519
|
|
|
|
based on what the same sector is facing
|
|
|
|
|
|
|
|
457
|
|
|
|
00:14:26,958 --> 00:14:31,359
|
|
|
|
perhaps in the same geographic location
|
|
|
|
|
|
|
|
458
|
|
|
|
00:14:29,519 --> 00:14:33,120
|
|
|
|
so suddenly you get a lot of knowledge
|
|
|
|
|
|
|
|
459
|
|
|
|
00:14:31,360 --> 00:14:35,120
|
|
|
|
out of the collected data as long as
|
|
|
|
|
|
|
|
460
|
|
|
|
00:14:33,120 --> 00:14:36,720
|
2022-02-06 17:25:12 +01:00
|
|
|
data is well contextualized and I think
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
461
|
|
|
|
00:14:35,120 --> 00:14:38,78
|
|
|
|
this will be one of the main topics that
|
|
|
|
|
|
|
|
462
|
|
|
|
00:14:36,720 --> 00:14:41,519
|
|
|
|
we're going to be talking about quite a bit today and tomorrow
|
|
|
|
|
|
|
|
464
|
|
|
|
00:14:39,679 --> 00:14:43,599
|
|
|
|
is contextualizing the information and
|
|
|
|
|
|
|
|
465
|
|
|
|
00:14:41,519 --> 00:14:47,600
|
|
|
|
making the information actually usable
|
|
|
|
|
|
|
|
466
|
|
|
|
00:14:43,600 --> 00:14:47,600
|
|
|
|
and turning data really into knowledge
|
|
|
|
|
|
|
|
467
|
|
|
|
00:14:49,600 --> 00:14:55,40
|
|
|
|
yeah so like Andras mentioned
|
|
|
|
|
|
|
|
468
|
|
|
|
00:14:52,639 --> 00:14:56,240
|
|
|
|
we have a pretty large set of different
|
|
|
|
|
|
|
|
469
|
|
|
|
00:14:55,39 --> 00:15:00,0
|
|
|
|
895.04 --> 900
|
|
|
|
communities using MISP
|
|
|
|
|
|
|
|
470
|
|
|
|
00:14:56,240 --> 00:15:02,159
|
2022-02-06 17:25:12 +01:00
|
|
|
and over the time it became I think more
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
471
|
|
|
|
00:15:00,0 --> 00:15:03,759
|
|
|
|
900 --> 903.76
|
|
|
|
complicated to handle all those requests
|
|
|
|
|
|
|
|
472
|
|
|
|
00:15:02,159 --> 00:15:07,120
|
|
|
|
from different organizations
|
|
|
|
|
|
|
|
473
|
|
|
|
00:15:03,759 --> 00:15:10,0
|
|
|
|
903.76 --> 910
|
|
|
|
um so we came with a model of governance
|
|
|
|
|
|
|
|
474
|
|
|
|
00:15:07,120 --> 00:15:12,240
|
|
|
|
even if it's a very lightweight one we
|
|
|
|
|
|
|
|
475
|
|
|
|
00:15:10,0 --> 00:15:13,839
|
|
|
|
910 --> 913.839
|
|
|
|
decided to have this kind of models to
|
|
|
|
|
|
|
|
476
|
|
|
|
00:15:12,240 --> 00:15:15,680
|
|
|
|
still benefit from the open source
|
|
|
|
|
|
|
|
477
|
|
|
|
00:15:13,839 --> 00:15:17,199
|
|
|
|
community model and then
|
|
|
|
|
|
|
|
478
|
|
|
|
00:15:15,679 --> 00:15:19,278
|
|
|
|
bring all the experience from a
|
|
|
|
|
|
|
|
479
|
|
|
|
00:15:17,198 --> 00:15:21,198
|
|
|
|
different community into systems where
|
|
|
|
|
|
|
|
480
|
|
|
|
00:15:19,278 --> 00:15:22,720
|
|
|
|
it allows us to develop and extend the
|
|
|
|
|
|
|
|
481
|
|
|
|
00:15:21,198 --> 00:15:24,958
|
|
|
|
software so we decided to
|
|
|
|
|
|
|
|
482
|
|
|
|
00:15:22,720 --> 00:15:26,240
|
|
|
|
create this kind of models where we
|
|
|
|
|
|
|
|
483
|
|
|
|
00:15:24,958 --> 00:15:28,879
|
|
|
|
basically
|
|
|
|
|
|
|
|
484
|
|
|
|
00:15:26,240 --> 00:15:30,320
|
|
|
|
take care of all the features and
|
|
|
|
|
|
|
|
485
|
|
|
|
00:15:28,879 --> 00:15:33,679
|
|
|
|
requests that we receive from different organizations
|
|
|
|
|
|
|
|
487
|
|
|
|
00:15:31,679 --> 00:15:36,599
|
|
|
|
so we use this kind of priority list of different features
|
|
|
|
|
|
|
|
489
|
|
|
|
00:15:35,600 --> 00:15:38,720
|
|
|
|
and we get that feedback from {inaudible}
|
|
|
|
|
|
|
|
491
|
|
|
|
00:15:38,720 --> 00:15:42,879
|
2022-02-06 17:25:12 +01:00
|
|
|
one of the {inaudible} one I would say is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
492
|
|
|
|
00:15:40,639 --> 00:15:44,480
|
|
|
|
Github so we get the feed from
|
|
|
|
|
|
|
|
493
|
|
|
|
00:15:42,879 --> 00:15:46,399
|
|
|
|
the different issue that we receive from
|
|
|
|
|
|
|
|
494
|
|
|
|
00:15:44,480 --> 00:15:48,639
|
2022-02-06 17:25:12 +01:00
|
|
|
Github I mean on the if you look at on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
495
|
|
|
|
00:15:46,399 --> 00:15:50,320
|
|
|
|
Github you'll see that we have a
|
|
|
|
|
|
|
|
496
|
|
|
|
00:15:48,639 --> 00:15:52,320
|
|
|
|
significant number of issues and those
|
|
|
|
|
|
|
|
497
|
|
|
|
00:15:50,320 --> 00:15:54,800
|
|
|
|
issue are usually for us a way to track down
|
|
|
|
|
|
|
|
499
|
|
|
|
00:15:52,799 --> 00:15:56,879
|
|
|
|
all the different requests of features
|
|
|
|
|
|
|
|
500
|
|
|
|
00:15:54,639 --> 00:15:59,120
|
|
|
|
in MISP and that's one way to get it.
|
|
|
|
|
|
|
|
501
|
|
|
|
00:15:56,879 --> 00:16:02,639
|
|
|
|
Another way and this one is a quite a common one
|
|
|
|
|
|
|
|
503
|
|
|
|
00:16:00,639 --> 00:16:05,39
|
|
|
|
is basically a training or session like
|
|
|
|
|
|
|
|
504
|
|
|
|
00:16:02,399 --> 00:16:06,799
|
|
|
|
this where people are providing feedback,
|
|
|
|
|
|
|
|
505
|
|
|
|
00:16:05,39 --> 00:16:09,39
|
|
|
|
bug reports, future requests and so on
|
|
|
|
|
|
|
|
506
|
|
|
|
00:16:06,799 --> 00:16:10,879
|
|
|
|
directly during the training and for us
|
|
|
|
|
|
|
|
507
|
|
|
|
00:16:09,39 --> 00:16:12,958
|
2022-02-06 17:25:12 +01:00
|
|
|
uh I think really practical and we can
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
508
|
|
|
|
00:16:10,879 --> 00:16:15,39
|
|
|
|
get all this information needed for us
|
|
|
|
|
|
|
|
509
|
|
|
|
00:16:12,958 --> 00:16:16,0
|
|
|
|
972.959 --> 976
|
|
|
|
to improve the software. Another thing
|
|
|
|
|
|
|
|
510
|
|
|
|
00:16:15,39 --> 00:16:17,759
|
|
|
|
that we do and
|
|
|
|
|
|
|
|
511
|
|
|
|
00:16:16,0 --> 00:16:19,839
|
|
|
|
976 --> 979.839
|
|
|
|
that's maybe for the audience some
|
|
|
|
|
|
|
|
512
|
|
|
|
00:16:17,759 --> 00:16:21,39
|
|
|
|
people are interested in that one
|
|
|
|
|
|
|
|
513
|
|
|
|
00:16:19,839 --> 00:16:22,560
|
|
|
|
we know that there are plenty of
|
|
|
|
|
|
|
|
514
|
|
|
|
00:16:21,39 --> 00:16:24,399
|
|
|
|
different MISP of groups that we don't
|
|
|
|
|
|
|
|
515
|
|
|
|
00:16:22,559 --> 00:16:28,319
|
|
|
|
control and that we don't manage that's
|
|
|
|
|
|
|
|
516
|
|
|
|
00:16:24,399 --> 00:16:29,679
|
|
|
|
great we have for example ISACs, ISAO
|
|
|
|
|
|
|
|
517
|
|
|
|
00:16:28,320 --> 00:16:31,360
|
|
|
|
doing really those kind of things where
|
|
|
|
|
|
|
|
518
|
|
|
|
00:16:29,679 --> 00:16:33,838
|
|
|
|
you have those kind of user groups
|
|
|
|
|
|
|
|
519
|
|
|
|
00:16:31,360 --> 00:16:35,600
|
|
|
|
and what we do we participate on a
|
|
|
|
|
|
|
|
520
|
|
|
|
00:16:33,839 --> 00:16:37,279
|
|
|
|
regular basis to one of those groups for
|
|
|
|
|
|
|
|
521
|
|
|
|
00:16:35,600 --> 00:16:39,0
|
|
|
|
995.6 --> 998
|
|
|
|
example on a quarterly basis on a yearly basis
|
|
|
|
|
|
|
|
523
|
|
|
|
00:16:38,0 --> 00:16:41,759
|
|
|
|
998 --> 1001.759
|
|
|
|
and we do a collection of requirements
|
|
|
|
|
|
|
|
524
|
|
|
|
00:16:40,240 --> 00:16:44,240
|
|
|
|
from those different groups
|
|
|
|
|
|
|
|
525
|
|
|
|
00:16:41,759 --> 00:16:46,720
|
|
|
|
during one session and that's really
|
|
|
|
|
|
|
|
527
|
|
|
|
00:16:44,958 --> 00:16:48,799
|
|
|
|
i think useful for us because it's a way
|
|
|
|
|
|
|
|
528
|
|
|
|
00:16:46,720 --> 00:16:50,720
|
|
|
|
to to gather information so for example
|
|
|
|
|
|
|
|
529
|
|
|
|
00:16:48,799 --> 00:16:52,78
|
|
|
|
Andras mentioned those
|
|
|
|
|
|
|
|
530
|
|
|
|
00:16:50,720 --> 00:16:53,519
|
|
|
|
financial groups where people are
|
|
|
|
|
|
|
|
531
|
|
|
|
00:16:52,78 --> 00:16:54,559
|
|
|
|
sharing information about bank account
|
|
|
|
|
|
|
|
532
|
|
|
|
00:16:53,519 --> 00:16:56,480
|
|
|
|
detail and so on
|
|
|
|
|
|
|
|
533
|
|
|
|
00:16:54,559 --> 00:16:57,919
|
|
|
|
and that's where we basically gather all
|
|
|
|
|
|
|
|
534
|
|
|
|
00:16:56,480 --> 00:16:59,278
|
|
|
|
those requirements
|
|
|
|
|
|
|
|
535
|
|
|
|
00:16:57,919 --> 00:17:01,39
|
|
|
|
so if you are setting up a group
|
|
|
|
|
|
|
|
536
|
|
|
|
00:16:59,278 --> 00:17:03,278
|
|
|
|
somewhere in US or
|
|
|
|
|
|
|
|
537
|
|
|
|
00:17:01,39 --> 00:17:04,318
|
|
|
|
in the world about sharing information
|
|
|
|
|
|
|
|
538
|
|
|
|
00:17:03,278 --> 00:17:06,0
|
|
|
|
1023.279 --> 1026
|
|
|
|
and so on and you want to
|
|
|
|
|
|
|
|
539
|
|
|
|
00:17:04,318 --> 00:17:07,759
|
|
|
|
invite us at some point in time it's a
|
|
|
|
|
|
|
|
540
|
|
|
|
00:17:06,0 --> 00:17:12,160
|
|
|
|
1026 --> 1028.959
|
|
|
|
way for us to gather those kind of requirements
|
|
|
|
|
|
|
|
542
|
|
|
|
00:17:08,959 --> 00:17:13,759
|
|
|
|
we do a summit which is a yearly event
|
|
|
|
|
|
|
|
543
|
|
|
|
00:17:12,160 --> 00:17:15,600
|
|
|
|
usually it was physical but nowadays
|
|
|
|
|
|
|
|
544
|
|
|
|
00:17:13,759 --> 00:17:18,0
|
|
|
|
1033.76 --> 1038
|
|
|
|
it's virtual trainings
|
|
|
|
|
|
|
|
545
|
|
|
|
00:17:15,599 --> 00:17:19,918
|
|
|
|
so it's basically every user or
|
|
|
|
|
|
|
|
546
|
|
|
|
00:17:18,0 --> 00:17:21,199
|
|
|
|
1038 --> 1041.199
|
|
|
|
organizations using MISP presenting what
|
|
|
|
|
|
|
|
547
|
|
|
|
00:17:19,919 --> 00:17:22,959
|
|
|
|
they are doing
|
|
|
|
|
|
|
|
548
|
|
|
|
00:17:21,199 --> 00:17:24,558
|
|
|
|
it's a way for us to to see the
|
|
|
|
|
|
|
|
549
|
|
|
|
00:17:22,959 --> 00:17:26,480
|
|
|
|
interactions and see what
|
|
|
|
|
|
|
|
550
|
|
|
|
00:17:24,558 --> 00:17:28,480
|
|
|
|
can be improved in MISP and see {inaudible}
|
|
|
|
|
|
|
|
551
|
|
|
|
00:17:26,480 --> 00:17:29,759
|
|
|
|
in the community behind
|
|
|
|
|
|
|
|
552
|
|
|
|
00:17:28,480 --> 00:17:31,839
|
|
|
|
and then we have a kind of 20%
|
|
|
|
|
|
|
|
553
|
|
|
|
00:17:29,759 --> 00:17:35,200
|
|
|
|
project around in MISP
|
|
|
|
|
|
|
|
554
|
|
|
|
00:17:31,839 --> 00:17:38,558
|
|
|
|
1051.84 --> 1056
|
|
|
|
where we design new functionalities and we test
|
|
|
|
|
|
|
|
556
|
|
|
|
00:17:36,0 --> 00:17:39,919
|
|
|
|
1056 --> 1059.919
|
|
|
|
them out for example one of those is the
|
|
|
|
|
|
|
|
557
|
|
|
|
00:17:38,558 --> 00:17:41,200
|
|
|
|
detailing of indicators
|
|
|
|
|
|
|
|
558
|
|
|
|
00:17:39,919 --> 00:17:42,400
|
|
|
|
which was a request from different
|
|
|
|
|
|
|
|
559
|
|
|
|
00:17:41,200 --> 00:17:43,919
|
|
|
|
organizations but it was kind of
|
|
|
|
|
|
|
|
560
|
|
|
|
00:17:42,400 --> 00:17:45,919
|
|
|
|
difficult to design
|
|
|
|
|
|
|
|
561
|
|
|
|
00:17:43,919 --> 00:17:48,240
|
|
|
|
and with this kind of models where we
|
|
|
|
|
|
|
|
562
|
|
|
|
00:17:45,919 --> 00:17:50,480
|
|
|
|
designed first as a kind of prototype
|
|
|
|
|
|
|
|
563
|
|
|
|
00:17:48,240 --> 00:17:52,558
|
|
|
|
multiple iterations uh we did a multiple
|
|
|
|
|
|
|
|
564
|
|
|
|
00:17:50,480 --> 00:17:56,0
|
|
|
|
1070.48 --> 1076
|
|
|
|
research paper on that and then finally
|
|
|
|
|
|
|
|
565
|
|
|
|
00:17:52,558 --> 00:17:57,918
|
|
|
|
this become part of the MISP core software
|
|
|
|
|
|
|
|
566
|
|
|
|
00:17:56,0 --> 00:17:59,679
|
|
|
|
1076 --> 1079.679
|
|
|
|
we will show that later on but so we
|
|
|
|
|
|
|
|
567
|
|
|
|
00:17:57,919 --> 00:18:01,679
|
|
|
|
have a lightweight governance model
|
|
|
|
|
|
|
|
568
|
|
|
|
00:17:59,679 --> 00:18:03,840
|
|
|
|
but really the goal is to gather as
|
|
|
|
|
|
|
|
569
|
|
|
|
00:18:01,679 --> 00:18:05,280
|
|
|
|
much feedback from the user so don't
|
|
|
|
|
|
|
|
570
|
|
|
|
00:18:03,839 --> 00:18:08,599
|
|
|
|
hesitate if you have any bug reports, ideas and so on
|
|
|
|
|
|
|
|
571
|
|
|
|
00:18:05,279 --> 00:18:09,319
|
|
|
|
either open an issue,
|
|
|
|
|
|
|
|
573
|
|
|
|
00:18:08,319 --> 00:18:11,918
|
|
|
|
get in touch with us.
|
|
|
|
|
|
|
|
575
|
|
|
|
00:18:11,919 --> 00:18:16,400
|
|
|
|
You are more than welcome to basically
|
|
|
|
|
|
|
|
576
|
|
|
|
00:18:13,279 --> 00:18:16,399
|
|
|
|
share such kind of information.
|
|
|
|
|
|
|
|
577
|
|
|
|
00:18:17,119 --> 00:18:22,719
|
|
|
|
Yeah, now addressing the elephant in the room
|
|
|
|
|
|
|
|
579
|
|
|
|
00:18:20,720 --> 00:18:24,160
|
|
|
|
when you bring so many different
|
|
|
|
|
|
|
|
580
|
|
|
|
00:18:22,160 --> 00:18:25,759
|
|
|
|
organizations together and build a large
|
|
|
|
|
|
|
|
581
|
|
|
|
00:18:24,160 --> 00:18:27,200
|
|
|
|
community of sharing with different
|
|
|
|
|
|
|
|
582
|
|
|
|
00:18:25,759 --> 00:18:28,558
|
|
|
|
needs and requirements
|
|
|
|
|
|
|
|
583
|
|
|
|
00:18:27,200 --> 00:18:31,200
|
|
|
|
you're obviously going to have to run
|
|
|
|
|
|
|
|
584
|
|
|
|
00:18:28,558 --> 00:18:32,720
|
|
|
|
into conflicting requirements as well
|
|
|
|
|
|
|
|
585
|
|
|
|
00:18:31,200 --> 00:18:34,240
|
|
|
|
so one of the most obvious ones that
|
|
|
|
|
|
|
|
586
|
|
|
|
00:18:32,720 --> 00:18:36,640
|
|
|
|
that we're dealing with very often with
|
|
|
|
|
|
|
|
587
|
|
|
|
00:18:34,240 --> 00:18:38,720
|
|
|
|
information sharing and something that
|
|
|
|
|
|
|
|
588
|
|
|
|
00:18:36,640 --> 00:18:39,840
|
|
|
|
that we're working on tackling ,
|
|
|
|
|
|
|
|
590
|
|
|
|
00:18:38,839 --> 00:18:43,599
|
|
|
|
basically since we started with MISP, is dealing
|
|
|
|
|
|
|
|
591
|
|
|
|
00:18:42,79 --> 00:18:45,279
|
|
|
|
with a different requirement of
|
|
|
|
|
|
|
|
592
|
|
|
|
00:18:43,599 --> 00:18:46,879
|
|
|
|
of what you count as valuable
|
|
|
|
|
|
|
|
593
|
|
|
|
00:18:45,279 --> 00:18:47,519
|
|
|
|
information depending on your use case
|
|
|
|
|
|
|
|
594
|
|
|
|
00:18:46,880 --> 00:18:51,599
|
|
|
|
so this is different also within
|
|
|
|
|
|
|
|
596
|
|
|
|
00:18:50,400 --> 00:18:53,360
|
|
|
|
different analysts, different roles
|
|
|
|
|
|
|
|
597
|
|
|
|
00:18:51,599 --> 00:18:56,79
|
|
|
|
within the same organization as
|
|
|
|
|
|
|
|
598
|
|
|
|
00:18:53,359 --> 00:18:58,720
|
|
|
|
well so for example, for us as a CSIRT in general
|
|
|
|
|
|
|
|
600
|
|
|
|
00:18:57,38 --> 00:19:00,240
|
|
|
|
uh detection is the most important
|
|
|
|
|
|
|
|
601
|
|
|
|
00:18:58,720 --> 00:19:04,640
|
|
|
|
matter so we're interested
|
|
|
|
|
|
|
|
602
|
|
|
|
00:19:00,240 --> 00:19:08,880
|
|
|
|
in in using indicators to detect if our constituency
|
|
|
|
|
|
|
|
604
|
|
|
|
00:19:06,880 --> 00:19:10,0
|
|
|
|
1146.88 --> 1150
|
|
|
|
is affected by something that the
|
|
|
|
|
|
|
|
605
|
|
|
|
00:19:08,880 --> 00:19:12,880
|
|
|
|
information is being
|
|
|
|
|
|
|
|
606
|
|
|
|
00:19:10,0 --> 00:19:14,160
|
|
|
|
1150 --> 1154.16
|
|
|
|
shared about or whether uh any of the
|
|
|
|
|
|
|
|
607
|
|
|
|
00:19:12,880 --> 00:19:17,200
|
|
|
|
the infrastructure that we're
|
|
|
|
|
|
|
|
608
|
|
|
|
00:19:14,160 --> 00:19:17,840
|
|
|
|
responsible for is infected
|
|
|
|
|
|
|
|
609
|
|
|
|
00:19:17,200 --> 00:19:22,639
|
|
|
|
on the other hand if you're talking to an isp
|
|
|
|
|
|
|
|
611
|
|
|
|
00:19:19,919 --> 00:19:22,640
|
|
|
|
one of the large
|
|
|
|
|
|
|
|
612
|
|
|
|
00:19:22,720 --> 00:19:26,720
|
|
|
|
requirements from an isp basically will
|
|
|
|
|
|
|
|
613
|
|
|
|
00:19:24,640 --> 00:19:29,38
|
|
|
|
be able to protect their users
|
|
|
|
|
|
|
|
614
|
|
|
|
00:19:26,720 --> 00:19:30,79
|
|
|
|
from potential harm so that means that
|
|
|
|
|
|
|
|
616
|
|
|
|
00:19:30,79 --> 00:19:34,480
|
|
|
|
if there are any urls, websites, and so on
|
|
|
|
|
|
|
|
618
|
|
|
|
00:19:34,480 --> 00:19:38,480
|
|
|
|
that they should block for their users they
|
|
|
|
|
|
|
|
619
|
|
|
|
00:19:36,880 --> 00:19:39,679
|
|
|
|
need to be able to generate a block list
|
|
|
|
|
|
|
|
620
|
|
|
|
00:19:38,480 --> 00:19:41,440
|
|
|
|
out of the data
|
|
|
|
|
|
|
|
621
|
|
|
|
00:19:39,679 --> 00:19:43,600
|
|
|
|
that is considered to be malicious
|
|
|
|
|
|
|
|
622
|
|
|
|
00:19:41,440 --> 00:19:45,360
|
|
|
|
enough now if you compare these two use cases
|
|
|
|
|
|
|
|
623
|
|
|
|
00:19:43,599 --> 00:19:48,240
|
|
|
|
with each other detection versus blocking
|
|
|
|
|
|
|
|
625
|
|
|
|
00:19:46,240 --> 00:19:49,359
|
|
|
|
you will immediately see that the effect
|
|
|
|
|
|
|
|
627
|
|
|
|
00:19:49,359 --> 00:19:53,359
|
|
|
|
of having a false positive in the data
|
|
|
|
|
|
|
|
628
|
|
|
|
00:19:51,200 --> 00:19:56,160
|
|
|
|
set or data that is no longer fresh
|
|
|
|
|
|
|
|
629
|
|
|
|
00:19:53,359 --> 00:19:57,119
|
|
|
|
has a completely different impact
|
|
|
|
|
|
|
|
630
|
|
|
|
00:19:56,160 --> 00:19:58,960
|
|
|
|
sure for us when
|
|
|
|
|
|
|
|
631
|
|
|
|
00:19:57,119 --> 00:20:00,719
|
|
|
|
that are mostly in the detection game
|
|
|
|
|
|
|
|
632
|
|
|
|
00:19:58,960 --> 00:20:02,400
|
|
|
|
it's annoying we get a false positive
|
|
|
|
|
|
|
|
633
|
|
|
|
00:20:00,720 --> 00:20:04,400
|
|
|
|
alert it has to be handled
|
|
|
|
|
|
|
|
634
|
|
|
|
00:20:02,400 --> 00:20:05,759
|
|
|
|
and it takes time and effort it also
|
|
|
|
|
|
|
|
635
|
|
|
|
00:20:04,400 --> 00:20:07,200
|
|
|
|
introduces something called alert fatigue
|
|
|
|
|
|
|
|
636
|
|
|
|
00:20:05,759 --> 00:20:09,319
|
|
|
|
that i'm sure many of you are familiar with
|
|
|
|
|
|
|
|
638
|
|
|
|
00:20:08,319 --> 00:20:12,79
|
|
|
|
if you're getting a lot of false
|
|
|
|
|
|
|
|
639
|
|
|
|
00:20:09,440 --> 00:20:15,120
|
|
|
|
positive alerts you're more likely to ignore the
|
|
|
|
|
|
|
|
641
|
|
|
|
00:20:13,119 --> 00:20:16,798
|
|
|
|
next alert that you get but besides that
|
|
|
|
|
|
|
|
642
|
|
|
|
00:20:15,679 --> 00:20:20,879
|
|
|
|
it has no real operational impact on us
|
|
|
|
|
|
|
|
644
|
|
|
|
00:20:19,119 --> 00:20:22,879
|
|
|
|
on the other hand for an isp that ends up blocking
|
|
|
|
|
|
|
|
645
|
|
|
|
00:20:20,880 --> 00:20:24,880
|
|
|
|
something that is uh
|
|
|
|
|
|
|
|
646
|
|
|
|
00:20:22,880 --> 00:20:27,400
|
|
|
|
potentially a false positive might have a catastrophic impact
|
|
|
|
|
|
|
|
648
|
|
|
|
00:20:26,400 --> 00:20:33,600
|
|
|
|
imagine if someone accidentally, for example shares
|
|
|
|
|
|
|
|
650
|
|
|
|
00:20:29,599 --> 00:20:35,759
|
|
|
|
facebook.com as an indicator that might
|
|
|
|
|
|
|
|
651
|
|
|
|
00:20:33,279 --> 00:20:39,119
|
|
|
|
basically cause a riot with their users or it might {inaudible}
|
|
|
|
|
|
|
|
653
|
|
|
|
00:20:37,279 --> 00:20:41,519
|
|
|
|
but it's a different story
|
|
|
|
|
|
|
|
654
|
|
|
|
00:20:39,119 --> 00:20:44,479
|
|
|
|
but with that in mind, you see that these
|
|
|
|
|
|
|
|
655
|
|
|
|
00:20:41,519 --> 00:20:47,679
|
|
|
|
two use cases are already conflicting
|
|
|
|
|
|
|
|
656
|
|
|
|
00:20:44,480 --> 00:20:49,360
|
|
|
|
now if you also take the perspective of
|
|
|
|
|
|
|
|
657
|
|
|
|
00:20:47,679 --> 00:20:52,400
|
|
|
|
intelligence analysts that are tracking
|
|
|
|
|
|
|
|
658
|
|
|
|
00:20:49,359 --> 00:20:52,798
|
|
|
|
threat actor movements in to account
|
|
|
|
|
|
|
|
660
|
|
|
|
00:20:52,798 --> 00:20:56,400
|
|
|
|
that's an even more lax use case
|
|
|
|
|
|
|
|
662
|
|
|
|
00:20:56,400 --> 00:21:02,159
|
|
|
|
where you care about whether something is a fresh indicator still or not
|
|
|
|
|
|
|
|
664
|
|
|
|
00:21:00,79 --> 00:21:03,439
|
|
|
|
even less than the other two groups.
|
|
|
|
|
|
|
|
665
|
|
|
|
00:21:02,159 --> 00:21:04,880
|
|
|
|
The reason for that is you're interested in
|
|
|
|
|
|
|
|
666
|
|
|
|
00:21:03,440 --> 00:21:07,120
|
|
|
|
the historical movements of a threat actor, for example.
|
|
|
|
|
|
|
|
668
|
|
|
|
00:21:07,119 --> 00:21:11,439
|
|
|
|
So even if something is no longer
|
|
|
|
|
|
|
|
669
|
|
|
|
00:21:08,240 --> 00:21:13,38
|
|
|
|
an indicator because and an infected
|
|
|
|
|
|
|
|
670
|
|
|
|
00:21:11,440 --> 00:21:14,960
|
|
|
|
website was cleaned up
|
|
|
|
|
|
|
|
671
|
|
|
|
00:21:13,38 --> 00:21:17,38
|
|
|
|
since the time when the indicator was
|
|
|
|
|
|
|
|
672
|
|
|
|
00:21:14,960 --> 00:21:18,880
|
|
|
|
shared they still want to see
|
|
|
|
|
|
|
|
673
|
|
|
|
00:21:17,38 --> 00:21:20,558
|
|
|
|
how long, for example a threat actor was
|
|
|
|
|
|
|
|
674
|
|
|
|
00:21:18,880 --> 00:21:22,80
|
|
|
|
using that infrastructure,
|
|
|
|
|
|
|
|
675
|
|
|
|
00:21:20,558 --> 00:21:25,119
|
|
|
|
how quickly they changed to something
|
|
|
|
|
|
|
|
676
|
|
|
|
00:21:22,79 --> 00:21:27,519
|
|
|
|
else and what methods they used
|
|
|
|
|
|
|
|
677
|
|
|
|
00:21:25,119 --> 00:21:28,239
|
|
|
|
back when they were exploiting it.
|
|
|
|
|
|
|
|
679
|
|
|
|
00:21:27,240 --> 00:21:31,839
|
|
|
|
So if you bring these different requirements on board on
|
|
|
|
|
|
|
|
680
|
|
|
|
00:21:30,480 --> 00:21:36,959
|
|
|
|
the same platform is difficult and there are some
|
|
|
|
|
|
|
|
682
|
|
|
|
00:21:35,200 --> 00:21:38,960
|
|
|
|
things that we can do to alleviate these
|
|
|
|
|
|
|
|
683
|
|
|
|
00:21:36,960 --> 00:21:40,720
|
|
|
|
issues. For example what we do with
|
|
|
|
|
|
|
|
684
|
|
|
|
00:21:38,960 --> 00:21:42,798
|
|
|
|
MISP
|
|
|
|
|
|
|
|
685
|
|
|
|
00:21:40,720 --> 00:21:44,480
|
|
|
|
we have a system called warning list
|
|
|
|
|
|
|
|
686
|
|
|
|
00:21:42,798 --> 00:21:46,480
|
|
|
|
system that allows us to filter out
|
|
|
|
|
|
|
|
687
|
|
|
|
00:21:44,480 --> 00:21:50,640
|
|
|
|
obvious false positives
|
|
|
|
|
|
|
|
688
|
|
|
|
00:21:46,480 --> 00:21:54,798
|
|
|
|
so we maintain these lists of
|
|
|
|
|
|
|
|
689
|
|
|
|
00:21:50,640 --> 00:21:56,720
|
|
|
|
most common websites, empty hash lists,
|
|
|
|
|
|
|
|
690
|
|
|
|
00:21:54,798 --> 00:21:58,319
|
|
|
|
public dns resolvers and all these
|
|
|
|
|
|
|
|
691
|
|
|
|
00:21:56,720 --> 00:22:00,558
|
|
|
|
typical things that end up in
|
|
|
|
|
|
|
|
692
|
|
|
|
00:21:58,319 --> 00:22:04,399
|
|
|
|
the sets while doing automatic extraction for example
|
|
|
|
|
|
|
|
694
|
|
|
|
00:22:02,400 --> 00:22:06,80
|
|
|
|
that end up being false positives but
|
|
|
|
|
|
|
|
695
|
|
|
|
00:22:04,400 --> 00:22:07,720
|
|
|
|
with that said this is just one part of the story
|
|
|
|
|
|
|
|
697
|
|
|
|
00:22:06,720 --> 00:22:10,79
|
|
|
|
So if you're looking at the different
|
|
|
|
|
|
|
|
698
|
|
|
|
00:22:08,480 --> 00:22:12,880
|
|
|
|
use cases up there that doesn't solve our issue
|
|
|
|
|
|
|
|
700
|
|
|
|
00:22:10,880 --> 00:22:15,600
|
|
|
|
of having different requirements
|
|
|
|
|
|
|
|
701
|
|
|
|
00:22:14,0 --> 00:22:17,558
|
|
|
|
1334 --> 1336.559
|
|
|
|
from the data set based on what you do with it
|
|
|
|
|
|
|
|
703
|
|
|
|
00:22:16,558 --> 00:22:20,319
|
|
|
|
and this is where contextualization
|
|
|
|
|
|
|
|
704
|
|
|
|
00:22:18,558 --> 00:22:22,158
|
|
|
|
becomes more important again
|
|
|
|
|
|
|
|
705
|
|
|
|
00:22:20,319 --> 00:22:24,0
|
|
|
|
1340.32 --> 1344
|
|
|
|
if we can supply the information together with the data,
|
|
|
|
|
|
|
|
707
|
|
|
|
00:22:23,0 --> 00:22:26,880
|
|
|
|
1344 --> 1346.88
|
|
|
|
why this data is relevant and what context you're
|
|
|
|
|
|
|
|
708
|
|
|
|
00:22:25,440 --> 00:22:28,640
|
|
|
|
supposed to be using it
|
|
|
|
|
|
|
|
709
|
|
|
|
00:22:26,880 --> 00:22:30,480
|
|
|
|
then the consumers of the data can make
|
|
|
|
|
|
|
|
710
|
|
|
|
00:22:28,640 --> 00:22:33,440
|
|
|
|
those decisions for themselves based on
|
|
|
|
|
|
|
|
711
|
|
|
|
00:22:30,480 --> 00:22:35,279
|
|
|
|
whatever they want to use
|
|
|
|
|
|
|
|
712
|
|
|
|
00:22:33,440 --> 00:22:38,640
|
|
|
|
the data for in any of those different use cases
|
|
|
|
|
|
|
|
714
|
|
|
|
00:22:36,640 --> 00:22:42,720
|
|
|
|
so one of our main efforts with MISP has been
|
|
|
|
|
|
|
|
716
|
|
|
|
00:22:40,720 --> 00:22:44,0
|
|
|
|
1360.72 --> 1364
|
|
|
|
to be able to provide these different
|
|
|
|
|
|
|
|
717
|
|
|
|
00:22:42,400 --> 00:22:47,519
|
|
|
|
structures together with the data and to
|
|
|
|
|
|
|
|
718
|
|
|
|
00:22:44,0 --> 00:22:48,519
|
|
|
|
1364 --> 1367.52
|
|
|
|
be able to label data well enough. Back to you.
|
|
|
|
|
|
|
|
720
|
|
|
|
00:22:48,880 --> 00:22:54,720
|
|
|
|
Yeah so and that's iI think important regarding the
|
|
|
|
|
|
|
|
721
|
|
|
|
00:22:52,960 --> 00:22:56,720
|
|
|
|
different kind of use cases and so on
|
|
|
|
|
|
|
|
722
|
|
|
|
00:22:54,720 --> 00:22:59,360
|
|
|
|
and we try to support those different use cases and
|
|
|
|
|
|
|
|
725
|
|
|
|
00:22:59,759 --> 00:23:03,679
|
|
|
|
that's sometimes challenging for us but luckily
|
|
|
|
|
|
|
|
726
|
|
|
|
00:23:01,679 --> 00:23:06,320
|
|
|
|
we are at the same time
|
|
|
|
|
|
|
|
727
|
|
|
|
00:23:03,679 --> 00:23:07,840
|
|
|
|
part of various community so we can see
|
|
|
|
|
|
|
|
728
|
|
|
|
00:23:06,319 --> 00:23:09,279
|
|
|
|
the different use cases, especially
|
|
|
|
|
|
|
|
729
|
|
|
|
00:23:07,839 --> 00:23:13,480
|
|
|
|
regarding the handling of false positive which is
|
|
|
|
|
|
|
|
731
|
|
|
|
00:23:12,480 --> 00:23:16,558
|
|
|
|
an ongoing challenge but we will show
|
|
|
|
|
|
|
|
732
|
|
|
|
00:23:14,880 --> 00:23:17,840
|
|
|
|
you how to handle that
|
|
|
|
|
|
|
|
733
|
|
|
|
00:23:16,558 --> 00:23:20,0
|
|
|
|
1396.559 --> 1400
|
|
|
|
and at the same time we basically
|
|
|
|
|
|
|
|
734
|
|
|
|
00:23:17,839 --> 00:23:22,79
|
|
|
|
operate those different communities.
|
|
|
|
|
|
|
|
735
|
|
|
|
00:23:20,0 --> 00:23:24,159
|
|
|
|
1400 --> 1404.159
|
|
|
|
So for example we operate a pretty large
|
|
|
|
|
|
|
|
736
|
|
|
|
00:23:22,79 --> 00:23:26,798
|
|
|
|
one for the private sector
|
|
|
|
|
|
|
|
737
|
|
|
|
00:23:24,159 --> 00:23:30,559
|
|
|
|
where we have a lot of organizations,
|
|
|
|
|
|
|
|
739
|
|
|
|
00:23:28,558 --> 00:23:32,158
|
|
|
|
more than 1200 organizations are basically connected there.
|
|
|
|
|
|
|
|
740
|
|
|
|
00:23:30,880 --> 00:23:35,440
|
|
|
|
It's pretty large and we see an active
|
|
|
|
|
|
|
|
742
|
|
|
|
00:23:35,440 --> 00:23:38,400
|
|
|
|
community sharing information and
|
|
|
|
|
|
|
|
743
|
|
|
|
00:23:36,798 --> 00:23:40,400
|
|
|
|
there is plenty of different communities
|
|
|
|
|
|
|
|
744
|
|
|
|
00:23:38,400 --> 00:23:41,840
|
|
|
|
some that we don't know even about
|
|
|
|
|
|
|
|
745
|
|
|
|
00:23:40,400 --> 00:23:43,278
|
|
|
|
because you can even run your own
|
|
|
|
|
|
|
|
746
|
|
|
|
00:23:41,839 --> 00:23:44,558
|
|
|
|
private communities without telling anyone, that's fine.
|
|
|
|
|
|
|
|
|
|
|
|
748
|
|
|
|
00:23:44,558 --> 00:23:49,759
|
|
|
|
That's part of the system but if you want to have different kind of communities
|
|
|
|
|
|
|
|
750
|
|
|
|
00:23:48,759 --> 00:23:55,839
|
|
|
|
you can connect those automatically then you have I would say
|
|
|
|
|
|
|
|
753
|
|
|
|
00:23:54,240 --> 00:23:57,798
|
|
|
|
different kind of model you have those kind of
|
|
|
|
|
|
|
|
755
|
|
|
|
00:23:56,798 --> 00:24:00,480
|
|
|
|
fully island mode communities.
|
|
|
|
|
|
|
|
756
|
|
|
|
00:23:58,798 --> 00:24:01,679
|
|
|
|
Those kind of trusted groups so for example for the
|
|
|
|
|
|
|
|
758
|
|
|
|
00:24:00,679 --> 00:24:05,519
|
|
|
|
intelligence community it's very common for them to run MISP
|
|
|
|
|
|
|
|
759
|
|
|
|
00:24:03,759 --> 00:24:09,759
|
|
|
|
in an island mode so having air gap system and so on
|
|
|
|
|
|
|
|
761
|
|
|
|
00:24:07,759 --> 00:24:11,919
|
|
|
|
sometimes they are partially connected
|
|
|
|
|
|
|
|
762
|
|
|
|
00:24:09,759 --> 00:24:13,599
|
|
|
|
with third parties to share partial
|
|
|
|
|
|
|
|
763
|
|
|
|
00:24:11,919 --> 00:24:15,400
|
|
|
|
information so for example we know some organizations
|
|
|
|
|
|
|
|
765
|
|
|
|
00:24:14,400 --> 00:24:18,640
|
|
|
|
or for example border controls or customs
|
|
|
|
|
|
|
|
767
|
|
|
|
00:24:18,640 --> 00:24:21,919
|
|
|
|
are using MISP but they still need to
|
|
|
|
|
|
|
|
768
|
|
|
|
00:24:20,79 --> 00:24:24,319
|
|
|
|
share some small information and that
|
|
|
|
|
|
|
|
770
|
|
|
|
00:24:22,319 --> 00:24:24,158
|
|
|
|
partially connected system.
|
|
|
|
|
|
|
|
771
|
|
|
|
00:24:23,319 --> 00:24:28,0
|
|
|
|
1464.32 --> 1468
|
|
|
|
MISP freely supports those kind of models
|
|
|
|
|
|
|
|
772
|
|
|
|
00:24:26,159 --> 00:24:29,679
|
|
|
|
and then you have community that are
|
|
|
|
|
|
|
|
773
|
|
|
|
00:24:28,0 --> 00:24:31,359
|
|
|
|
1468 --> 1471.36
|
|
|
|
more broad and more large
|
|
|
|
|
|
|
|
774
|
|
|
|
00:24:29,679 --> 00:24:33,278
|
|
|
|
for example in the financial sector and
|
|
|
|
|
|
|
|
775
|
|
|
|
00:24:31,359 --> 00:24:35,240
|
|
|
|
I think the CSIRT Luxembourg has some banks
|
|
|
|
|
|
|
|
777
|
|
|
|
00:24:34,240 --> 00:24:39,599
|
|
|
|
we are involved in various sharing communities
|
|
|
|
|
|
|
|
779
|
|
|
|
00:24:37,599 --> 00:24:41,519
|
|
|
|
at European level and worldwide level
|
|
|
|
|
|
|
|
780
|
|
|
|
00:24:40,480 --> 00:24:45,759
|
|
|
|
where for example we know some ISACs that are dedicated to
|
|
|
|
|
|
|
|
782
|
|
|
|
00:24:43,759 --> 00:24:48,200
|
|
|
|
the financial sector are using it as a sharing mechanism
|
|
|
|
|
|
|
|
784
|
|
|
|
00:24:47,200 --> 00:24:51,278
|
|
|
|
you have some organizations that are really
|
|
|
|
|
|
|
|
785
|
|
|
|
00:24:49,38 --> 00:24:52,480
|
|
|
|
dedicated to a payment processing system
|
|
|
|
|
|
|
|
786
|
|
|
|
00:24:51,278 --> 00:24:54,519
|
|
|
|
that are using this to share automatically
|
|
|
|
|
|
|
|
788
|
|
|
|
00:24:53,519 --> 00:24:57,519
|
|
|
|
information and so on or analysis
|
|
|
|
|
|
|
|
790
|
|
|
|
00:24:57,519 --> 00:25:01,519
|
2022-02-06 17:25:12 +01:00
|
|
|
One of the I would say pretty large community too is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
791
|
|
|
|
00:24:59,278 --> 00:25:04,960
|
|
|
|
with the military organization and international organizations
|
|
|
|
|
|
|
|
793
|
|
|
|
00:25:02,960 --> 00:25:06,720
|
|
|
|
FIRST for example, you have a lot of FIRST members using
|
|
|
|
|
|
|
|
794
|
|
|
|
00:25:05,359 --> 00:25:08,639
|
|
|
|
MISP for sharing their information
|
|
|
|
|
|
|
|
796
|
|
|
|
00:25:08,640 --> 00:25:13,759
|
|
|
|
but there are plenty of networks, national governmental networks
|
|
|
|
|
|
|
|
798
|
|
|
|
00:25:11,759 --> 00:25:15,278
|
|
|
|
a military one intelligence, one or even NATO for example are using
|
|
|
|
|
|
|
|
800
|
|
|
|
00:25:15,278 --> 00:25:19,599
|
|
|
|
using MISP so maybe some of you are eligible to access those ones
|
|
|
|
|
|
|
|
802
|
|
|
|
00:25:19,599 --> 00:25:23,399
|
|
|
|
so we have on the MISP an interface a way to connect to those
|
|
|
|
|
|
|
|
804
|
|
|
|
00:25:22,400 --> 00:25:26,240
|
|
|
|
community and you can reach out to the
|
|
|
|
|
|
|
|
805
|
|
|
|
00:25:24,319 --> 00:25:27,200
|
|
|
|
different community by asking for access for example
|
|
|
|
|
|
|
|
807
|
|
|
|
00:25:27,200 --> 00:25:30,319
|
|
|
|
then you have very specific communities
|
|
|
|
|
|
|
|
808
|
|
|
|
00:25:28,960 --> 00:25:33,720
|
|
|
|
that are set up by security vendors it's not uncommon
|
|
|
|
|
|
|
|
810
|
|
|
|
00:25:32,720 --> 00:25:35,759
|
|
|
|
tp see for example a security vendor
|
|
|
|
|
|
|
|
811
|
|
|
|
00:25:34,0 --> 00:25:37,359
|
|
|
|
1534 --> 1537.36
|
|
|
|
services their own MISP
|
|
|
|
|
|
|
|
812
|
|
|
|
00:25:35,759 --> 00:25:39,119
|
|
|
|
we have seen for example some
|
|
|
|
|
|
|
|
813
|
|
|
|
00:25:37,359 --> 00:25:41,319
|
|
|
|
{inaudible} agents vendors running a dedicated MISP
|
|
|
|
|
|
|
|
815
|
|
|
|
00:25:40,319 --> 00:25:44,480
|
|
|
|
or even some operators of specific cloud
|
|
|
|
|
|
|
|
816
|
|
|
|
00:25:42,798 --> 00:25:46,400
|
|
|
|
services running a MISP instance
|
|
|
|
|
|
|
|
817
|
|
|
|
00:25:44,480 --> 00:25:49,360
|
|
|
|
to share information amongst
|
|
|
|
|
|
|
|
818
|
|
|
|
00:25:46,400 --> 00:25:49,320
|
|
|
|
their different customers.
|
|
|
|
|
|
|
|
819
|
|
|
|
00:25:49,359 --> 00:25:52,798
|
|
|
|
Then you have communities that are
|
|
|
|
|
|
|
|
820
|
|
|
|
00:25:50,319 --> 00:25:55,38
|
|
|
|
i would say very specific on the topic
|
|
|
|
|
|
|
|
821
|
|
|
|
00:25:52,798 --> 00:25:59,79
|
|
|
|
for example you have about sick information uh false news
|
|
|
|
|
|
|
|
823
|
|
|
|
00:25:58,79 --> 00:26:02,278
|
|
|
|
and stuff like that you have communities doing that
|
|
|
|
|
|
|
|
825
|
|
|
|
00:26:01,278 --> 00:26:04,720
|
|
|
|
for example we cooperate one called the COVID-19 MISP
|
|
|
|
|
|
|
|
827
|
|
|
|
00:26:04,720 --> 00:26:09,839
|
|
|
|
which is really targeting COVID-19 as a topic
|
|
|
|
|
|
|
|
828
|
|
|
|
00:26:07,919 --> 00:26:10,720
|
|
|
|
and then you have 10 different subtopics like
|
|
|
|
|
|
|
|
829
|
|
|
|
00:26:09,839 --> 00:26:12,399
|
|
|
|
cyber security, health related topics and so on.
|
|
|
|
|
|
|
|
831
|
|
|
|
00:26:12,400 --> 00:26:15,679
|
|
|
|
So you can see that MISP can be really used on
|
|
|
|
|
|
|
|
832
|
|
|
|
00:26:13,919 --> 00:26:17,440
|
|
|
|
different model of communities
|
|
|
|
|
|
|
|
833
|
|
|
|
00:26:15,679 --> 00:26:19,440
|
|
|
|
you can bridge those communities,
|
|
|
|
|
|
|
|
834
|
|
|
|
00:26:17,440 --> 00:26:21,360
|
|
|
|
you can interconnect those with together,
|
|
|
|
|
|
|
|
835
|
|
|
|
00:26:19,440 --> 00:26:23,759
|
|
|
|
you can keep it for yourself, so it's
|
|
|
|
|
|
|
|
836
|
|
|
|
00:26:21,359 --> 00:26:25,839
|
|
|
|
really a matter of models.
|
|
|
|
|
|
|
|
837
|
|
|
|
00:26:23,759 --> 00:26:27,759
|
|
|
|
Worldwide there are I would say a lot of
|
|
|
|
|
|
|
|
838
|
|
|
|
00:26:25,839 --> 00:26:31,199
|
|
|
|
communities that we are not aware of
|
|
|
|
|
|
|
|
839
|
|
|
|
00:26:27,759 --> 00:26:33,599
|
|
|
|
but we as CIRCL operates
|
|
|
|
|
|
|
|
840
|
|
|
|
00:26:31,200 --> 00:26:35,120
|
|
|
|
around 20 communities nowadays, that you
|
|
|
|
|
|
|
|
841
|
|
|
|
00:26:33,599 --> 00:26:37,839
|
|
|
|
can basically get access
|
|
|
|
|
|
|
|
842
|
|
|
|
00:26:35,119 --> 00:26:39,839
|
|
|
|
and Andras just sharing in the chat the
|
|
|
|
|
|
|
|
843
|
|
|
|
00:26:37,839 --> 00:26:42,439
|
|
|
|
access to the COVID-19 MISP and if you want to get access to
|
|
|
|
|
|
|
|
845
|
|
|
|
00:26:41,440 --> 00:26:46,320
|
|
|
|
that one you can connect on the main page and self-register and
|
|
|
|
|
|
|
|
847
|
|
|
|
00:26:46,319 --> 00:26:49,519
|
|
|
|
you can request access to that community
|
|
|
|
|
|
|
|
849
|
|
|
|
00:26:48,519 --> 00:26:53,38
|
|
|
|
so you see that MISP has different groups different communities
|
|
|
|
|
|
|
|
851
|
|
|
|
00:26:53,38 --> 00:26:56,640
|
|
|
|
and it's up to you at the end to decide
|
|
|
|
|
|
|
|
852
|
|
|
|
00:26:55,359 --> 00:26:58,879
|
|
|
|
which kind of community you want to {inaudiable either be/visit}
|
|
|
|
|
|
|
|
854
|
|
|
|
00:27:01,38 --> 00:27:04,798
|
|
|
|
So, a little bit besides all the technical things
|
|
|
|
|
|
|
|
856
|
|
|
|
00:27:04,798 --> 00:27:06,839
|
|
|
|
that we talked about, that we do with MISP,
|
|
|
|
|
|
|
|
857
|
|
|
|
00:27:06,480 --> 00:27:09,919
|
|
|
|
and that we try to solve with it.
|
|
|
|
|
|
|
|
858
|
|
|
|
00:27:07,839 --> 00:27:11,278
|
|
|
|
In terms of sharing, there are obviously
|
|
|
|
|
|
|
|
859
|
|
|
|
00:27:09,919 --> 00:27:12,720
|
|
|
|
going to be other hurdles that you have
|
|
|
|
|
|
|
|
860
|
|
|
|
00:27:11,278 --> 00:27:14,159
|
|
|
|
to overcome whenever it comes to information sharing
|
|
|
|
|
|
|
|
862
|
|
|
|
00:27:14,159 --> 00:27:17,679
|
|
|
|
one of the the toughest things to
|
|
|
|
|
|
|
|
863
|
|
|
|
00:27:16,0 --> 00:27:18,880
|
|
|
|
1636 --> 1638.88
|
|
|
|
overcome and this is where no tool can really help you
|
|
|
|
|
|
|
|
865
|
|
|
|
00:27:18,880 --> 00:27:23,679
|
|
|
|
is to get enough trust in a community to
|
|
|
|
|
|
|
|
866
|
|
|
|
00:27:22,79 --> 00:27:24,319
|
|
|
|
be able to share your information with them
|
|
|
|
|
|
|
|
868
|
|
|
|
00:27:24,319 --> 00:27:27,918
|
|
|
|
So the only way to facilitate this is really social interactions
|
|
|
|
|
|
|
|
870
|
|
|
|
00:27:27,919 --> 00:27:32,0
|
|
|
|
1647.919 --> 1652
|
|
|
|
so sadly though we're living in times
|
|
|
|
|
|
|
|
871
|
|
|
|
00:27:30,398 --> 00:27:33,278
|
|
|
|
where social interactions are tougher than usual
|
|
|
|
|
|
|
|
873
|
|
|
|
00:27:33,278 --> 00:27:37,440
|
|
|
|
but for example events like FIRST conferences
|
|
|
|
|
|
|
|
874
|
|
|
|
00:27:35,679 --> 00:27:38,880
|
|
|
|
are great ways to get to know your community and to
|
|
|
|
|
|
|
|
876
|
|
|
|
00:27:38,880 --> 00:27:43,200
|
|
|
|
build this trust and build those
|
|
|
|
|
|
|
|
877
|
|
|
|
00:27:41,440 --> 00:27:44,159
|
|
|
|
social relationships that you need
|
|
|
|
|
|
|
|
879
|
|
|
|
00:27:44,159 --> 00:27:47,679
|
|
|
|
to be able to really exchange meaningful
|
|
|
|
|
|
|
|
880
|
|
|
|
00:27:45,839 --> 00:27:49,918
|
|
|
|
information with the community
|
|
|
|
|
|
|
|
881
|
|
|
|
00:27:47,679 --> 00:27:52,0
|
|
|
|
1667.679 --> 1672
|
2022-02-06 17:25:12 +01:00
|
|
|
so I really encourage everyone that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
882
|
|
|
|
00:27:49,919 --> 00:27:53,360
|
|
|
|
wants to partake in information sharing communities
|
|
|
|
|
|
|
|
884
|
|
|
|
00:27:53,359 --> 00:27:57,278
|
|
|
|
to be social, to reach out, and to get to know your community
|
|
|
|
|
|
|
|
886
|
|
|
|
00:27:57,278 --> 00:28:00,79
|
|
|
|
because that's the biggest facilitator for sharing in the first place.
|
|
|
|
|
|
|
|
888
|
|
|
|
00:28:00,79 --> 00:28:03,599
|
|
|
|
Other than that, there are obviously some
|
|
|
|
|
|
|
|
889
|
|
|
|
00:28:01,919 --> 00:28:05,360
|
|
|
|
legal restrictions that you have
|
|
|
|
|
|
|
|
890
|
|
|
|
00:28:03,599 --> 00:28:06,398
|
|
|
|
that might come up in the entire process.
|
|
|
|
|
|
|
|
891
|
|
|
|
00:28:05,359 --> 00:28:08,79
|
|
|
|
We see this very often with organizations where the first
|
|
|
|
|
|
|
|
893
|
|
|
|
00:28:08,79 --> 00:28:10,918
|
|
|
|
questions that they ask us when they join
|
|
|
|
|
|
|
|
895
|
|
|
|
00:28:09,919 --> 00:28:16,240
|
|
|
|
in our communities okay how does this
|
|
|
|
|
|
|
|
896
|
|
|
|
00:28:13,38 --> 00:28:18,558
|
|
|
|
fit into GDPR for example.
|
|
|
|
|
|
|
|
897
|
|
|
|
00:28:16,240 --> 00:28:21,38
|
|
|
|
If my legal team asks me why I am sharing
|
|
|
|
|
|
|
|
898
|
|
|
|
00:28:18,558 --> 00:28:22,720
|
|
|
|
an information out what can i
|
|
|
|
|
|
|
|
899
|
|
|
|
00:28:21,38 --> 00:28:24,798
|
|
|
|
give them as an explanation of why i'm
|
|
|
|
|
|
|
|
900
|
|
|
|
00:28:22,720 --> 00:28:25,159
|
|
|
|
supposed to or allowed to do this.
|
|
|
|
|
|
|
|
901
|
|
|
|
00:28:25,198 --> 00:28:28,319
|
|
|
|
So if you need any help with that we
|
|
|
|
|
|
|
|
902
|
|
|
|
00:28:26,159 --> 00:28:29,840
|
|
|
|
have a bunch of compliance documentation
|
|
|
|
|
|
|
|
903
|
|
|
|
00:28:28,319 --> 00:28:33,240
|
|
|
|
and that we've been working on together with a bunch of partners
|
|
|
|
|
|
|
|
905
|
|
|
|
00:28:32,240 --> 00:28:36,798
|
|
|
|
and so we have descriptions for how
|
|
|
|
|
|
|
|
906
|
|
|
|
00:28:34,640 --> 00:28:37,919
|
|
|
|
MISP fits into the GDPR, the NIS directive
|
|
|
|
|
|
|
|
908
|
|
|
|
00:28:37,919 --> 00:28:41,360
|
|
|
|
and some other frameworks so just
|
|
|
|
|
|
|
|
909
|
|
|
|
00:28:40,79 --> 00:28:43,119
|
|
|
|
have a look there and if you have any
|
|
|
|
|
|
|
|
910
|
|
|
|
00:28:41,359 --> 00:28:44,0
|
|
|
|
1721.36 --> 1724
|
|
|
|
questions or if you feel that anything is not covered
|
|
|
|
|
|
|
|
912
|
|
|
|
00:28:44,0 --> 00:28:47,599
|
|
|
|
1724 --> 1727.6
|
|
|
|
let us know and we keep updating our documentation
|
|
|
|
|
|
|
|
914
|
|
|
|
00:28:47,599 --> 00:28:51,519
|
|
|
|
based on on feedback of what's missing
|
|
|
|
|
|
|
|
915
|
|
|
|
00:28:49,679 --> 00:28:52,559
|
|
|
|
or ideas that we should be incorporating in there
|
|
|
|
|
|
|
|
917
|
|
|
|
00:28:52,558 --> 00:29:00,640
|
|
|
|
but generally , once your legal team is more
|
|
|
|
|
|
|
|
919
|
|
|
|
00:28:58,880 --> 00:29:01,360
|
|
|
|
familiar with the process and why this
|
|
|
|
|
|
|
|
920
|
|
|
|
00:29:00,640 --> 00:29:02,80
|
2022-02-06 17:25:12 +01:00
|
|
|
is {inaudible done/tied}
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
921
|
|
|
|
00:29:01,359 --> 00:29:05,759
|
|
|
|
why ensuring security for your
|
|
|
|
|
|
|
|
922
|
|
|
|
00:29:04,79 --> 00:29:06,798
|
|
|
|
organization and for the data that you
|
|
|
|
|
|
|
|
923
|
|
|
|
00:29:05,759 --> 00:29:08,960
|
|
|
|
have to secure is important then it's seen more as a
|
|
|
|
|
|
|
|
925
|
|
|
|
00:29:08,960 --> 00:29:13,360
|
|
|
|
benefit than a hurdle really
|
|
|
|
|
|
|
|
926
|
|
|
|
00:29:10,640 --> 00:29:15,278
|
|
|
|
but it obviously takes time to get
|
|
|
|
|
|
|
|
927
|
|
|
|
00:29:13,359 --> 00:29:16,240
|
|
|
|
this into your processes to define why you're
|
|
|
|
|
|
|
|
929
|
|
|
|
00:29:16,240 --> 00:29:19,679
|
|
|
|
doing what you're doing
|
|
|
|
|
|
|
|
930
|
|
|
|
00:29:18,398 --> 00:29:21,199
|
|
|
|
your retention periods,
|
|
|
|
|
|
|
|
931
|
|
|
|
00:29:19,679 --> 00:29:22,960
|
|
|
|
describing how you're going to handle data and so on
|
|
|
|
|
|
|
|
933
|
|
|
|
00:29:22,960 --> 00:29:26,399
|
|
|
|
so this obviously has some ramp up time
|
|
|
|
|
|
|
|
935
|
|
|
|
00:29:26,398 --> 00:29:29,439
|
|
|
|
but we have a lot of documentation that will help you with that.
|
|
|
|
|
|
|
|
937
|
|
|
|
00:29:29,440 --> 00:29:32,558
|
|
|
|
There are also some practical restrictions that we hear from
|
|
|
|
|
|
|
|
938
|
|
|
|
00:29:30,960 --> 00:29:34,79
|
|
|
|
organizations so very often when
|
|
|
|
|
|
|
|
939
|
|
|
|
00:29:32,558 --> 00:29:35,440
|
|
|
|
organizations reach out to us
|
|
|
|
|
|
|
|
940
|
|
|
|
00:29:34,79 --> 00:29:37,199
|
|
|
|
the first thing they say is we don't
|
|
|
|
|
|
|
|
941
|
|
|
|
00:29:35,440 --> 00:29:39,120
|
|
|
|
really have any information to share,
|
|
|
|
|
|
|
|
942
|
|
|
|
00:29:37,200 --> 00:29:40,880
|
|
|
|
we don't have the capability for example
|
|
|
|
|
|
|
|
943
|
|
|
|
00:29:39,119 --> 00:29:42,639
|
|
|
|
to build those highly vetted threat reports that we're so used to
|
|
|
|
|
|
|
|
945
|
|
|
|
00:29:42,640 --> 00:29:46,960
|
|
|
|
from feed providers and obviously very few organizations do.
|
|
|
|
|
|
|
|
947
|
|
|
|
00:29:46,960 --> 00:29:51,200
|
|
|
|
With that said information sharing comes
|
|
|
|
|
|
|
|
948
|
|
|
|
00:29:49,919 --> 00:29:54,600
|
|
|
|
in many different shapes and sizes for example going back
|
|
|
|
|
|
|
|
950
|
|
|
|
00:29:53,599 --> 00:29:58,558
|
|
|
|
to the initial use case about
|
|
|
|
|
|
|
|
951
|
|
|
|
00:29:55,200 --> 00:30:00,0
|
|
|
|
1795.2 --> 1800
|
|
|
|
providing feedback from your analysts
|
|
|
|
|
|
|
|
952
|
|
|
|
00:29:58,558 --> 00:30:02,240
|
|
|
|
about the data that you receive from
|
|
|
|
|
|
|
|
953
|
|
|
|
00:30:00,0 --> 00:30:03,839
|
|
|
|
1800 --> 1803.84
|
|
|
|
your community is already valuable
|
|
|
|
|
|
|
|
954
|
|
|
|
00:30:02,240 --> 00:30:05,599
|
|
|
|
information sharing so if someone for
|
|
|
|
|
|
|
|
955
|
|
|
|
00:30:03,839 --> 00:30:07,278
|
|
|
|
example provides sightings
|
|
|
|
|
|
|
|
956
|
|
|
|
00:30:05,599 --> 00:30:09,839
|
|
|
|
I've also seen this indicator at this given time
|
|
|
|
|
|
|
|
958
|
|
|
|
00:30:09,839 --> 00:30:13,359
|
|
|
|
that can already help you tune the data set
|
|
|
|
|
|
|
|
960
|
|
|
|
00:30:13,359 --> 00:30:16,879
|
|
|
|
for what goes into your working data
|
|
|
|
|
|
|
|
961
|
|
|
|
00:30:15,119 --> 00:30:18,319
|
|
|
|
sets for detection and blocking and so on.
|
|
|
|
|
|
|
|
963
|
|
|
|
00:30:18,319 --> 00:30:22,960
|
|
|
|
Also providing information on false
|
|
|
|
|
|
|
|
964
|
|
|
|
00:30:20,839 --> 00:30:24,319
|
|
|
|
positives and some information that
|
|
|
|
|
|
|
|
965
|
|
|
|
00:30:22,960 --> 00:30:26,640
|
|
|
|
you provided to the community turns out to be false
|
|
|
|
|
|
|
|
967
|
|
|
|
00:30:26,640 --> 00:30:30,960
|
|
|
|
or something that is no longer relevant
|
|
|
|
|
|
|
|
968
|
|
|
|
00:30:28,880 --> 00:30:33,39
|
|
|
|
getting information that is valid as
|
|
|
|
|
|
|
|
969
|
|
|
|
00:30:30,960 --> 00:30:35,278
|
|
|
|
well so pretty much everyone has
|
|
|
|
|
|
|
|
970
|
|
|
|
00:30:33,38 --> 00:30:36,398
|
|
|
|
information to share by just using the information and running
|
|
|
|
|
|
|
|
972
|
|
|
|
00:30:36,398 --> 00:30:44,0
|
|
|
|
1836.399 --> 1844
|
|
|
|
into frustration with the data by itself.
|
|
|
|
|
|
|
|
973
|
|
|
|
00:30:40,720 --> 00:30:44,640
|
|
|
|
Also besides not having information to share
|
|
|
|
|
|
|
|
975
|
|
|
|
00:30:44,640 --> 00:30:50,399
|
|
|
|
there comes also the issue of time.
|
|
|
|
|
|
|
|
976
|
|
|
|
00:30:48,398 --> 00:30:51,759
|
|
|
|
Most of us are overburdened with
|
|
|
|
|
|
|
|
977
|
|
|
|
00:30:50,398 --> 00:30:52,798
|
|
|
|
the different tasks that we are facing nowadays
|
|
|
|
|
|
|
|
979
|
|
|
|
00:30:52,798 --> 00:30:57,599
|
|
|
|
so taking extra time out of the day to
|
|
|
|
|
|
|
|
981
|
|
|
|
00:30:57,599 --> 00:31:02,38
|
|
|
|
encode information and to share it out in the community
|
|
|
|
|
|
|
|
983
|
|
|
|
00:31:01,38 --> 00:31:04,558
|
|
|
|
is obviously going to be an extra burden
|
|
|
|
|
|
|
|
984
|
|
|
|
00:31:02,640 --> 00:31:05,600
|
|
|
|
there is no way around it.
|
|
|
|
|
|
|
|
985
|
|
|
|
00:31:03,558 --> 00:31:07,440
|
|
|
|
What we try to do with MISP
|
|
|
|
|
|
|
|
986
|
|
|
|
00:31:05,599 --> 00:31:09,38
|
|
|
|
is to make this process as minimal as
|
|
|
|
|
|
|
|
987
|
|
|
|
00:31:07,440 --> 00:31:11,0
|
|
|
|
1867.44 --> 1870
|
|
|
|
possible but it is going to be a time investment in the end, after all
|
|
|
|
|
|
|
|
989
|
|
|
|
00:31:10,0 --> 00:31:13,839
|
|
|
|
1870 --> 1873.84
|
|
|
|
especially if you want to vet the data if you want to ensure that
|
|
|
|
|
|
|
|
992
|
|
|
|
00:31:13,839 --> 00:31:19,240
|
|
|
|
the right data reaches the right recipients
|
|
|
|
|
|
|
|
994
|
|
|
|
00:31:18,240 --> 00:31:26,240
|
|
|
|
This always has a time drain on you as well but in return this
|
|
|
|
|
|
|
|
996
|
|
|
|
00:31:24,480 --> 00:31:29,79
|
|
|
|
is offset by what you gain by sharing that information we're
|
|
|
|
|
|
|
|
998
|
|
|
|
00:31:28,79 --> 00:31:31,359
|
|
|
|
going to talk about this a little bit
|
|
|
|
|
|
|
|
999
|
|
|
|
00:31:29,440 --> 00:31:33,759
|
|
|
|
more during the community building part
|
|
|
|
|
|
|
|
1000
|
|
|
|
00:31:31,359 --> 00:31:35,278
|
|
|
|
about what effects you're going to see
|
|
|
|
|
|
|
|
1001
|
|
|
|
00:31:33,759 --> 00:31:36,640
|
|
|
|
if you're sharing information and why it is relevant for you
|
|
|
|
|
|
|
|
1003
|
|
|
|
00:31:36,640 --> 00:31:41,120
|
|
|
|
but to basically sum it up in one sentence
|
|
|
|
|
|
|
|
1005
|
|
|
|
00:31:41,119 --> 00:31:44,239
|
|
|
|
and whatever affects your organization
|
|
|
|
|
|
|
|
1006
|
|
|
|
00:31:42,960 --> 00:31:45,679
|
|
|
|
is probably the most important information for you and if you get
|
|
|
|
|
|
|
|
1008
|
|
|
|
00:31:45,679 --> 00:31:49,759
|
|
|
|
feedback on that, what you're seeing in your network
|
|
|
|
|
|
|
|
1010
|
|
|
|
00:31:49,759 --> 00:31:52,398
|
|
|
|
and more eyes on it, more perspectives
|
|
|
|
|
|
|
|
1013
|
|
|
|
00:31:52,398 --> 00:31:58,159
|
|
|
|
and perhaps more sophisticated methods of
|
|
|
|
|
|
|
|
1014
|
|
|
|
00:31:56,79 --> 00:31:59,519
|
|
|
|
research from other organizations
|
|
|
|
|
|
|
|
1015
|
|
|
|
00:31:58,159 --> 00:32:01,600
|
|
|
|
then that will probably just improve
|
|
|
|
|
|
|
|
1016
|
|
|
|
00:31:59,519 --> 00:32:03,519
|
|
|
|
your own security posture the best way it can.
|
|
|
|
|
|
|
|
1018
|
|
|
|
00:32:03,519 --> 00:32:08,880
|
|
|
|
Now, besides timeliness and basically having information to share
|
|
|
|
|
|
|
|
1020
|
|
|
|
00:32:07,519 --> 00:32:10,960
|
|
|
|
there's also the issue of different
|
|
|
|
|
|
|
|
1021
|
|
|
|
00:32:08,880 --> 00:32:12,240
|
|
|
|
classification models so classification
|
|
|
|
|
|
|
|
1022
|
|
|
|
00:32:10,960 --> 00:32:16,159
|
|
|
|
not just in a sense of of deciding who we share information with
|
|
|
|
|
|
|
|
1025
|
|
|
|
00:32:16,159 --> 00:32:19,278
|
|
|
|
but how we classify information really
|
|
|
|
|
|
|
|
1026
|
|
|
|
00:32:18,79 --> 00:32:22,798
|
|
|
|
in terms of contextualizating it we are all used
|
|
|
|
|
|
|
|
1029
|
|
|
|
00:32:22,798 --> 00:32:28,159
|
|
|
|
to naming things a certain way in our organizations in
|
|
|
|
|
|
|
|
1030
|
|
|
|
00:32:26,319 --> 00:32:31,38
|
|
|
|
our communities and we've probably
|
|
|
|
|
|
|
|
1031
|
|
|
|
00:32:28,159 --> 00:32:35,839
|
|
|
|
been doing it for longer than digital information systems exist
|
|
|
|
|
|
|
|
1034
|
|
|
|
00:32:34,558 --> 00:32:37,599
|
|
|
|
so we're probably using a lot of those
|
|
|
|
|
|
|
|
1035
|
|
|
|
00:32:35,839 --> 00:32:38,639
|
|
|
|
vocabularies that we've been using for decades
|
|
|
|
|
|
|
|
1037
|
|
|
|
00:32:38,640 --> 00:32:43,600
|
|
|
|
and what one of the things that we
|
|
|
|
|
|
|
|
1038
|
|
|
|
00:32:41,119 --> 00:32:45,678
|
|
|
|
wanted to avoid with MISP is to
|
|
|
|
|
|
|
|
1039
|
|
|
|
00:32:43,599 --> 00:32:46,639
|
|
|
|
get these communities to switch to a
|
|
|
|
|
|
|
|
1041
|
|
|
|
00:32:46,640 --> 00:32:51,360
|
|
|
|
different way of describing things so if you already
|
|
|
|
|
|
|
|
1042
|
|
|
|
00:32:49,119 --> 00:32:52,959
|
|
|
|
have your set methods, your set processes
|
|
|
|
|
|
|
|
1043
|
|
|
|
00:32:51,359 --> 00:32:54,479
|
|
|
|
how you define things, we don't want to alter that so one of
|
|
|
|
|
|
|
|
1045
|
|
|
|
00:32:54,480 --> 00:32:57,278
|
|
|
|
the things that we do with MISP and we are
|
|
|
|
|
|
|
|
1046
|
|
|
|
00:32:55,839 --> 00:32:58,798
|
|
|
|
going to talk a fair bit about, tomorrow mostly
|
|
|
|
|
|
|
|
1048
|
|
|
|
00:32:58,798 --> 00:33:03,679
|
|
|
|
is that you have ways to describe your
|
|
|
|
|
|
|
|
1049
|
|
|
|
00:33:01,519 --> 00:33:06,0
|
|
|
|
1981.519 --> 1986
|
|
|
|
own taxonomies and your own vocabularies
|
|
|
|
|
|
|
|
1050
|
|
|
|
00:33:03,679 --> 00:33:07,120
|
|
|
|
to use those in your community so very
|
|
|
|
|
|
|
|
1051
|
|
|
|
00:33:06,0 --> 00:33:08,558
|
|
|
|
1986 --> 1988.559
|
|
|
|
often when you're spinning up a
|
|
|
|
|
|
|
|
1052
|
|
|
|
00:33:07,119 --> 00:33:09,199
|
|
|
|
community and when you're starting out
|
|
|
|
|
|
|
|
1053
|
|
|
|
00:33:08,558 --> 00:33:10,879
|
|
|
|
with the sharing community,
|
|
|
|
|
|
|
|
1055
|
|
|
|
00:33:10,880 --> 00:33:14,320
|
|
|
|
a national sharing community, sectorial one, whatever
|
|
|
|
|
|
|
|
1056
|
|
|
|
00:33:12,480 --> 00:33:16,399
|
|
|
|
then one of the first tasks is basically
|
|
|
|
|
|
|
|
1057
|
|
|
|
00:33:14,319 --> 00:33:18,720
|
|
|
|
defining those common vocabularies
|
|
|
|
|
|
|
|
1058
|
|
|
|
00:33:16,398 --> 00:33:20,639
|
|
|
|
that you're going to be using
|
|
|
|
|
|
|
|
1059
|
|
|
|
00:33:18,720 --> 00:33:22,319
|
|
|
|
now apart from the vocabularies
|
|
|
|
|
|
|
|
1060
|
|
|
|
00:33:20,640 --> 00:33:25,38
|
|
|
|
themselves there is also the issue of
|
|
|
|
|
|
|
|
1061
|
|
|
|
00:33:22,319 --> 00:33:25,839
|
|
|
|
of us speaking many different languages
|
|
|
|
|
|
|
|
1063
|
|
|
|
00:33:25,839 --> 00:33:29,519
|
|
|
|
in terms of of our tools using different formats
|
|
|
|
|
|
|
|
1065
|
|
|
|
00:33:28,640 --> 00:33:33,919
|
|
|
|
so that means even within our own organization which is
|
|
|
|
|
|
|
|
1066
|
|
|
|
00:33:32,79 --> 00:33:34,639
|
|
|
|
rather small we have a set of different tools
|
|
|
|
|
|
|
|
1068
|
|
|
|
00:33:34,640 --> 00:33:38,559
|
|
|
|
that will ingest data in different formats
|
|
|
|
|
|
|
|
1070
|
|
|
|
00:33:38,558 --> 00:33:42,240
|
|
|
|
or will prefer to ingest data in given
|
|
|
|
|
|
|
|
1071
|
|
|
|
00:33:40,558 --> 00:33:43,119
|
|
|
|
format so one of the things we also try to do with MISP
|
|
|
|
|
|
|
|
1073
|
|
|
|
00:33:43,119 --> 00:33:46,798
|
|
|
|
is to act as a hub for all your different tools
|
|
|
|
|
|
|
|
1075
|
|
|
|
00:33:46,798 --> 00:33:51,519
|
|
|
|
that will get their data translated into
|
|
|
|
|
|
|
|
1076
|
|
|
|
00:33:49,200 --> 00:33:52,960
|
|
|
|
the format that they can best ingest.
|
|
|
|
|
|
|
|
1077
|
|
|
|
00:33:51,519 --> 00:33:55,839
|
|
|
|
Obviously this is something where we cannot be completely
|
|
|
|
|
|
|
|
1079
|
|
|
|
00:33:55,839 --> 00:34:01,519
|
|
|
|
100 percent covering all the other
|
|
|
|
|
|
|
|
1080
|
|
|
|
00:33:59,119 --> 00:34:02,879
|
|
|
|
things that exist out there.
|
|
|
|
|
|
|
|
1081
|
|
|
|
00:34:01,519 --> 00:34:04,558
|
|
|
|
So one of the things we try to do with MISP
|
|
|
|
|
|
|
|
1082
|
|
|
|
00:34:02,880 --> 00:34:06,399
|
|
|
|
is make it as modular as possible and
|
|
|
|
|
|
|
|
1083
|
|
|
|
00:34:04,558 --> 00:34:07,278
|
|
|
|
it's easy to encode your own formats as possible.
|
|
|
|
|
|
|
|
1085
|
|
|
|
00:34:07,278 --> 00:34:13,440
|
|
|
|
We're not going to go deeply into how to do this during the training
|
|
|
|
|
|
|
|
1087
|
|
|
|
00:34:11,358 --> 00:34:15,39
|
|
|
|
but if anyone is interested about that just
|
|
|
|
|
|
|
|
1089
|
|
|
|
00:34:15,39 --> 00:34:17,599
|
|
|
|
let us know and we'll point you in the
|
|
|
|
|
|
|
|
1090
|
|
|
|
00:34:16,398 --> 00:34:19,598
|
|
|
|
right direction where you can find
|
|
|
|
|
|
|
|
1091
|
|
|
|
00:34:17,599 --> 00:34:20,159
|
|
|
|
documentation on how to modularize and
|
|
|
|
|
|
|
|
1093
|
|
|
|
00:34:19,599 --> 00:34:24,159
|
|
|
|
how to build import and export in MISP.
|
|
|
|
|
|
|
|
1094
|
|
|
|
00:34:26,760 --> 00:34:30,560
|
|
|
|
So just one side note, all the training
|
|
|
|
|
|
|
|
1095
|
|
|
|
00:34:28,639 --> 00:34:32,320
|
|
|
|
materials are available online
|
|
|
|
|
|
|
|
1096
|
|
|
|
00:34:30,559 --> 00:34:33,599
|
2022-02-06 17:25:12 +01:00
|
|
|
like {inaudible} mentioned we have a Github
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1097
|
|
|
|
00:34:32,320 --> 00:34:35,599
|
|
|
|
repository with a pretty extensive README files with all
|
|
|
|
|
|
|
|
1099
|
|
|
|
00:34:35,599 --> 00:34:41,39
|
|
|
|
the material that we provide, there is a MISP book too which includes a
|
|
|
|
|
|
|
|
1101
|
|
|
|
00:34:41,39 --> 00:34:45,838
|
|
|
|
lot of reference to MISP as you know MISP has a
|
|
|
|
|
|
|
|
1103
|
|
|
|
00:34:45,838 --> 00:34:50,159
|
|
|
|
pretty large topic coming from technical aspect and
|
|
|
|
|
|
|
|
1105
|
|
|
|
00:34:50,159 --> 00:34:54,480
|
|
|
|
you will see that in a minute about the project overview.
|
|
|
|
|
|
|
|
1107
|
|
|
|
00:34:54,480 --> 00:34:57,519
|
|
|
|
So don't hesitate to go there on the MISP training
|
|
|
|
|
|
|
|
1109
|
|
|
|
00:34:57,519 --> 00:35:00,639
|
|
|
|
page on Github this one is a good
|
|
|
|
|
|
|
|
1110
|
|
|
|
00:34:59,358 --> 00:35:02,639
|
|
|
|
reference because it's really pointing
|
|
|
|
|
|
|
|
1111
|
|
|
|
00:35:00,639 --> 00:35:05,920
|
|
|
|
to the different elements
|
|
|
|
|
|
|
|
1112
|
|
|
|
00:35:02,639 --> 00:35:06,239
|
|
|
|
that we have. We have a huge slide deck of
|
|
|
|
|
|
|
|
1114
|
|
|
|
00:35:06,239 --> 00:35:10,559
|
|
|
|
close to 500 pages of slide deck on the
|
|
|
|
|
|
|
|
1115
|
|
|
|
00:35:08,559 --> 00:35:11,679
|
|
|
|
MISP book we have close to 500 pages. I
|
|
|
|
|
|
|
|
1116
|
|
|
|
00:35:10,559 --> 00:35:13,440
|
|
|
|
would not mention the number of pages
|
|
|
|
|
|
|
|
1117
|
|
|
|
00:35:11,679 --> 00:35:14,719
|
|
|
|
for taxonomies, galaxies and so on. It's quite large too
|
|
|
|
|
|
|
|
1119
|
|
|
|
00:35:14,719 --> 00:35:19,39
|
|
|
|
but really look at this as a kind of way
|
|
|
|
|
|
|
|
1120
|
|
|
|
00:35:17,519 --> 00:35:22,239
|
|
|
|
to shape it to what you like.
|
|
|
|
|
|
|
|
1121
|
|
|
|
00:35:19,39 --> 00:35:23,519
|
|
|
|
So it's really there to help you and if
|
|
|
|
|
|
|
|
1122
|
|
|
|
00:35:22,239 --> 00:35:25,439
|
|
|
|
you see something missing
|
|
|
|
|
|
|
|
1123
|
|
|
|
00:35:23,519 --> 00:35:26,800
|
|
|
|
let us know but we have slides,
|
|
|
|
|
|
|
|
1125
|
|
|
|
00:35:26,800 --> 00:35:31,200
|
|
|
|
for example system requirements, things like
|
|
|
|
|
|
|
|
1126
|
|
|
|
00:35:29,838 --> 00:35:32,960
|
|
|
|
for example building community that
|
|
|
|
|
|
|
|
1127
|
|
|
|
00:35:31,199 --> 00:35:35,439
|
|
|
|
we'll talk tomorrow, that's
|
|
|
|
|
|
|
|
1128
|
|
|
|
00:35:32,960 --> 00:35:37,599
|
|
|
|
part of it but for more the
|
|
|
|
|
|
|
|
1129
|
|
|
|
00:35:35,440 --> 00:35:40,320
|
|
|
|
programmatic aspect, API
|
|
|
|
|
|
|
|
1130
|
|
|
|
00:35:37,599 --> 00:35:41,200
|
2022-02-06 17:25:12 +01:00
|
|
|
how to integrate with MISP {inaudible JSON/taxono},
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1131
|
|
|
|
00:35:40,320 --> 00:35:43,39
|
|
|
|
how to extend it too
|
|
|
|
|
|
|
|
1132
|
|
|
|
00:35:41,199 --> 00:35:44,799
|
|
|
|
there are plenty of slides regarding that
|
|
|
|
|
|
|
|
1133
|
|
|
|
00:35:43,39 --> 00:35:46,800
|
|
|
|
so it's really a good reference
|
|
|
|
|
|
|
|
1134
|
|
|
|
00:35:44,800 --> 00:35:48,560
|
2022-02-06 17:25:12 +01:00
|
|
|
and thanks to {inaudible} to share this
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1135
|
|
|
|
00:35:46,800 --> 00:35:50,800
|
|
|
|
information on the chat
|
|
|
|
|
|
|
|
1136
|
|
|
|
00:35:48,559 --> 00:35:52,719
|
|
|
|
so to just give a quick overview of the MISP project and really to show that
|
|
|
|
|
|
|
|
1138
|
|
|
|
00:35:52,719 --> 00:35:56,399
|
|
|
|
the project is quite large nowadays
|
|
|
|
|
|
|
|
1139
|
|
|
|
00:35:55,199 --> 00:35:59,838
|
|
|
|
we basically have like four pillars of things in MISP
|
|
|
|
|
|
|
|
1141
|
|
|
|
00:35:59,838 --> 00:36:03,199
|
|
|
|
one is obviously the open software itself
|
|
|
|
|
|
|
|
1143
|
|
|
|
00:36:03,199 --> 00:36:08,78
|
2022-02-06 17:25:12 +01:00
|
|
|
so the initial version in {inaudible} it was
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1144
|
|
|
|
00:36:06,239 --> 00:36:10,239
|
|
|
|
the small first small block there
|
|
|
|
|
|
|
|
1145
|
|
|
|
00:36:08,79 --> 00:36:11,440
|
|
|
|
the MISP core software which is like just the software
|
|
|
|
|
|
|
|
1147
|
|
|
|
00:36:11,440 --> 00:36:16,400
|
|
|
|
mainly for the LMAP aspect where
|
|
|
|
|
|
|
|
1148
|
|
|
|
00:36:14,800 --> 00:36:17,920
|
|
|
|
you have the backend, the web interface,
|
|
|
|
|
|
|
|
1149
|
|
|
|
00:36:16,400 --> 00:36:19,760
|
|
|
|
and so on but over the time the project extended
|
|
|
|
|
|
|
|
1151
|
|
|
|
00:36:19,760 --> 00:36:23,40
|
|
|
|
with multiple things so if you look on the Github
|
|
|
|
|
|
|
|
1152
|
|
|
|
00:36:20,960 --> 00:36:24,800
|
|
|
|
repository of mid project we have around 50 repositories so
|
|
|
|
|
|
|
|
1154
|
|
|
|
00:36:24,800 --> 00:36:28,720
|
|
|
|
it's pretty large. Just to summarize what
|
|
|
|
|
|
|
|
1155
|
|
|
|
00:36:27,519 --> 00:36:31,119
|
|
|
|
are the different one
|
|
|
|
|
|
|
|
1156
|
|
|
|
00:36:28,719 --> 00:36:31,919
|
|
|
|
we have for example the MISP modules um
|
|
|
|
|
|
|
|
1158
|
|
|
|
00:36:31,920 --> 00:36:35,119
|
|
|
|
which is an easy way to extend MISP so the behavior of MISP
|
|
|
|
|
|
|
|
1160
|
|
|
|
00:36:35,119 --> 00:36:40,880
|
|
|
|
on the expansion side on the import, export and so on by just writing
|
|
|
|
|
|
|
|
1162
|
|
|
|
00:36:40,880 --> 00:36:44,480
|
|
|
|
python modules it's super easy to develop and use
|
|
|
|
|
|
|
|
1164
|
|
|
|
00:36:44,480 --> 00:36:47,920
|
|
|
|
and the idea behind is obviously to
|
|
|
|
|
|
|
|
1165
|
|
|
|
00:36:46,0 --> 00:36:50,960
|
|
|
|
2206 --> 2210.96
|
|
|
|
extend MISP without knowing
|
|
|
|
|
|
|
|
1166
|
|
|
|
00:36:47,920 --> 00:36:51,440
|
|
|
|
the core details about the system
|
|
|
|
|
|
|
|
1167
|
|
|
|
00:36:50,960 --> 00:36:55,358
|
|
|
|
then we have a library called PyMISP and this
|
|
|
|
|
|
|
|
1168
|
|
|
|
00:36:53,440 --> 00:36:58,639
|
|
|
|
PyMISP library is basically a
|
|
|
|
|
|
|
|
1169
|
|
|
|
00:36:55,358 --> 00:37:02,319
|
|
|
|
python library to expose the new MISP platform API
|
|
|
|
|
|
|
|
1171
|
|
|
|
00:37:02,320 --> 00:37:07,39
|
|
|
|
so MISP has a large REST api this one can be quite large but
|
|
|
|
|
|
|
|
1173
|
|
|
|
00:37:05,199 --> 00:37:11,679
|
2022-02-06 17:25:12 +01:00
|
|
|
by MISP is really helping you to for example {inaudible jest/Get} events
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1174
|
|
|
|
00:37:09,599 --> 00:37:13,200
|
|
|
|
create feeds and stuff like that so it's
|
|
|
|
|
|
|
|
1175
|
|
|
|
00:37:11,679 --> 00:37:15,358
|
|
|
|
really important if you want to
|
|
|
|
|
|
|
|
1176
|
|
|
|
00:37:13,199 --> 00:37:17,39
|
|
|
|
extend MISP to have a look at PyMISP that
|
|
|
|
|
|
|
|
1177
|
|
|
|
00:37:15,358 --> 00:37:18,480
|
|
|
|
is not the only library for extending
|
|
|
|
|
|
|
|
1179
|
|
|
|
00:37:18,480 --> 00:37:23,440
|
|
|
|
MISP some in golang you have some
|
|
|
|
|
|
|
|
1180
|
|
|
|
00:37:21,519 --> 00:37:24,639
|
|
|
|
other in python too, you have others in java and so on
|
|
|
|
|
|
|
|
1182
|
|
|
|
00:37:24,639 --> 00:37:28,0
|
|
|
|
2244.64 --> 2248
|
|
|
|
but the PyMISP one is the one that
|
|
|
|
|
|
|
|
1183
|
|
|
|
00:37:26,400 --> 00:37:31,199
|
|
|
|
is maintained by the author of MISP so it is maintained by us
|
|
|
|
|
|
|
|
1186
|
|
|
|
00:37:31,199 --> 00:37:34,399
|
|
|
|
and you can have a look at this one it's
|
|
|
|
|
|
|
|
1187
|
|
|
|
00:37:32,480 --> 00:37:36,0
|
|
|
|
2252.48 --> 2256
|
|
|
|
really the one that's up to date it's
|
|
|
|
|
|
|
|
1188
|
|
|
|
00:37:34,400 --> 00:37:38,0
|
|
|
|
2254.4 --> 2258
|
|
|
|
really core and part of the system too
|
|
|
|
|
|
|
|
1189
|
|
|
|
00:37:36,0 --> 00:37:40,400
|
|
|
|
2256 --> 2260.4
|
|
|
|
because we use it for our own tests
|
|
|
|
|
|
|
|
1190
|
|
|
|
00:37:38,0 --> 00:37:42,320
|
|
|
|
2258 --> 2262.32
|
|
|
|
within MISP then we have different
|
|
|
|
|
|
|
|
1191
|
|
|
|
00:37:40,400 --> 00:37:43,358
|
2022-02-06 17:25:12 +01:00
|
|
|
repository I will just mention one which is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1193
|
|
|
|
00:37:43,358 --> 00:37:46,559
|
|
|
|
dashboard, the dashboard is an extension module
|
|
|
|
|
|
|
|
1195
|
|
|
|
00:37:46,559 --> 00:37:51,838
|
|
|
|
in MISP using what we call the ZeroMQ feed in MISP
|
|
|
|
|
|
|
|
1196
|
|
|
|
00:37:49,838 --> 00:37:54,159
|
|
|
|
so we have a kind of way to have kind of a real-time feed
|
|
|
|
|
|
|
|
1198
|
|
|
|
00:37:54,159 --> 00:37:58,799
|
2022-02-06 17:25:12 +01:00
|
|
|
in MISP you can {inaudible} and
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1199
|
|
|
|
00:37:56,400 --> 00:38:00,639
|
|
|
|
so on but we wanted to show an example
|
|
|
|
|
|
|
|
1200
|
|
|
|
00:37:58,800 --> 00:38:02,240
|
|
|
|
application for that and the MISP
|
|
|
|
|
|
|
|
1201
|
|
|
|
00:38:00,639 --> 00:38:04,879
|
|
|
|
dashboard is exactly that
|
|
|
|
|
|
|
|
1202
|
|
|
|
00:38:02,239 --> 00:38:06,559
|
|
|
|
is a way to really get all the
|
|
|
|
|
|
|
|
1203
|
|
|
|
00:38:04,880 --> 00:38:08,960
|
|
|
|
information that you have in MISP
|
|
|
|
|
|
|
|
1204
|
|
|
|
00:38:06,559 --> 00:38:09,920
|
|
|
|
into a very nice dashboard and so on
|
|
|
|
|
|
|
|
1205
|
|
|
|
00:38:08,960 --> 00:38:11,760
|
|
|
|
this is really to have a good example of what you can do
|
|
|
|
|
|
|
|
1207
|
|
|
|
00:38:11,760 --> 00:38:14,240
|
|
|
|
with information within MISP and how you can use it
|
|
|
|
|
|
|
|
1209
|
|
|
|
00:38:14,239 --> 00:38:17,519
|
|
|
|
so that's the main pillar you have
|
|
|
|
|
|
|
|
1210
|
|
|
|
00:38:15,519 --> 00:38:18,79
|
|
|
|
plenty of other projects but those one are the main ones
|
|
|
|
|
|
|
|
1212
|
|
|
|
00:38:18,79 --> 00:38:22,400
|
|
|
|
on top of that you have
|
|
|
|
|
|
|
|
1213
|
|
|
|
00:38:20,880 --> 00:38:23,358
|
|
|
|
what we call the intelligent and knowledge database of
|
|
|
|
|
|
|
|
1215
|
|
|
|
00:38:23,358 --> 00:38:27,119
|
|
|
|
MISP and just mentioned about the difficulty
|
|
|
|
|
|
|
|
1217
|
|
|
|
00:38:27,119 --> 00:38:31,280
|
|
|
|
sometimes in some organizations to use a
|
|
|
|
|
|
|
|
1218
|
|
|
|
00:38:29,199 --> 00:38:33,519
|
2022-02-06 17:25:12 +01:00
|
|
|
{inaudible proper/corporate} classification and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1219
|
|
|
|
00:38:31,280 --> 00:38:35,40
|
|
|
|
and we try to ease this in this
|
|
|
|
|
|
|
|
1220
|
|
|
|
00:38:33,519 --> 00:38:36,639
|
|
|
|
different organization by having a kind
|
|
|
|
|
|
|
|
1221
|
|
|
|
00:38:35,39 --> 00:38:37,279
|
|
|
|
of library of all the taxonomies that exist
|
|
|
|
|
|
|
|
1223
|
|
|
|
00:38:37,280 --> 00:38:41,519
|
|
|
|
so we started as a very simple one where
|
|
|
|
|
|
|
|
1224
|
|
|
|
00:38:39,679 --> 00:38:43,358
|
|
|
|
it was just including for example a
|
|
|
|
|
|
|
|
1225
|
|
|
|
00:38:41,519 --> 00:38:45,440
|
|
|
|
taxonomy like the traffic light protocol one, FIRST is using it
|
|
|
|
|
|
|
|
1227
|
|
|
|
00:38:45,440 --> 00:38:49,119
|
|
|
|
and it's a commonly used classification but over
|
|
|
|
|
|
|
|
1228
|
|
|
|
00:38:47,838 --> 00:38:50,320
|
|
|
|
the time we have seen that many
|
|
|
|
|
|
|
|
1229
|
|
|
|
00:38:49,119 --> 00:38:52,720
|
|
|
|
organizations have different
|
|
|
|
|
|
|
|
1230
|
|
|
|
00:38:50,320 --> 00:38:54,320
|
|
|
|
classification and so on. So we already
|
|
|
|
|
|
|
|
1231
|
|
|
|
00:38:52,719 --> 00:38:55,838
|
|
|
|
in advance we prepare all those taxonomies in
|
|
|
|
|
|
|
|
1233
|
|
|
|
00:38:55,838 --> 00:38:59,599
|
2022-02-06 17:25:12 +01:00
|
|
|
possible information {inaudible} expose MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1234
|
|
|
|
00:38:58,159 --> 00:39:02,399
|
|
|
|
and you can enable the one that you want
|
|
|
|
|
|
|
|
1235
|
|
|
|
00:38:59,599 --> 00:39:05,39
|
|
|
|
so we have around 150 libraries now
|
|
|
|
|
|
|
|
1236
|
|
|
|
00:39:02,400 --> 00:39:05,680
|
|
|
|
ranging from classifications, specific one for
|
|
|
|
|
|
|
|
1238
|
|
|
|
00:39:05,679 --> 00:39:10,559
|
|
|
|
intelligence communities and some
|
|
|
|
|
|
|
|
1239
|
|
|
|
00:39:08,159 --> 00:39:12,399
|
|
|
|
other activities so this one is our
|
|
|
|
|
|
|
|
1240
|
|
|
|
00:39:10,559 --> 00:39:13,440
|
|
|
|
really useful label and you can just
|
|
|
|
|
|
|
|
1241
|
|
|
|
00:39:12,400 --> 00:39:15,39
|
2022-02-06 17:25:12 +01:00
|
|
|
{inaudible share/pick} the one that you want and we maintain those one
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1243
|
|
|
|
00:39:15,39 --> 00:39:18,880
|
|
|
|
so we have some that are coming from
|
|
|
|
|
|
|
|
1244
|
|
|
|
00:39:16,960 --> 00:39:21,39
|
|
|
|
third party, some that we are collecting
|
|
|
|
|
|
|
|
1245
|
|
|
|
00:39:18,880 --> 00:39:23,39
|
|
|
|
as each projects are creating.
|
|
|
|
|
|
|
|
1246
|
|
|
|
00:39:21,39 --> 00:39:24,719
|
|
|
|
It's really usually a good source to see
|
|
|
|
|
|
|
|
1247
|
|
|
|
00:39:23,39 --> 00:39:26,838
|
|
|
|
how other communities are using
|
|
|
|
|
|
|
|
1248
|
|
|
|
00:39:24,719 --> 00:39:28,639
|
|
|
|
classifying and contextualizing the
|
|
|
|
|
|
|
|
1249
|
|
|
|
00:39:26,838 --> 00:39:30,480
|
|
|
|
information, there nevertheless the
|
|
|
|
|
|
|
|
1250
|
|
|
|
00:39:28,639 --> 00:39:35,759
|
|
|
|
taxonomy itself was like kind of labels, those labels were quite small
|
|
|
|
|
|
|
|
1253
|
|
|
|
00:39:33,519 --> 00:39:36,960
|
|
|
|
so it was not like completely extensive information so
|
|
|
|
|
|
|
|
1255
|
|
|
|
00:39:36,960 --> 00:39:41,39
|
|
|
|
over the time we maintain a kind of more extensive one called the galaxy
|
|
|
|
|
|
|
|
1257
|
|
|
|
00:39:41,39 --> 00:39:47,279
|
|
|
|
you will hear the term very often
|
|
|
|
|
|
|
|
1258
|
|
|
|
00:39:44,79 --> 00:39:49,200
|
|
|
|
those galaxies are defining many things
|
|
|
|
|
|
|
|
1259
|
|
|
|
00:39:47,280 --> 00:39:51,40
|
|
|
|
for example one of the most common one is the threat actor
|
|
|
|
|
|
|
|
1261
|
|
|
|
00:39:50,39 --> 00:39:54,400
|
|
|
|
we have a huge database of threat actors but a lot of
|
|
|
|
|
|
|
|
1262
|
|
|
|
00:39:52,800 --> 00:39:56,400
|
|
|
|
times it was extended
|
|
|
|
|
|
|
|
1263
|
|
|
|
00:39:54,400 --> 00:39:58,320
|
|
|
|
for example, Microsoft is not using
|
|
|
|
|
|
|
|
1264
|
|
|
|
00:39:56,400 --> 00:39:59,358
|
|
|
|
threat actors for example there is this activity group is part of the
|
|
|
|
|
|
|
|
1266
|
|
|
|
00:39:59,358 --> 00:40:05,119
|
|
|
|
galaxy, it's really one that we
|
|
|
|
|
|
|
|
1267
|
|
|
|
00:40:02,400 --> 00:40:05,760
|
|
|
|
use for different and you can represent whatever
|
|
|
|
|
|
|
|
1269
|
|
|
|
00:40:05,760 --> 00:40:09,280
|
|
|
|
galaxy you want so you have a predefined
|
|
|
|
|
|
|
|
1270
|
|
|
|
00:40:07,358 --> 00:40:10,960
|
|
|
|
set of existing one but you can create your own
|
|
|
|
|
|
|
|
1272
|
|
|
|
00:40:10,960 --> 00:40:14,400
|
|
|
|
so if you have your own threat actor database
|
|
|
|
|
|
|
|
1273
|
|
|
|
00:40:12,880 --> 00:40:16,480
|
|
|
|
you can create your own from scratch or
|
|
|
|
|
|
|
|
1274
|
|
|
|
00:40:14,400 --> 00:40:17,280
|
|
|
|
you can reuse and fork existing ones so
|
|
|
|
|
|
|
|
1275
|
|
|
|
00:40:16,480 --> 00:40:18,480
|
|
|
|
that's really those kind of things that we manage in
|
|
|
|
|
|
|
|
1277
|
|
|
|
00:40:18,480 --> 00:40:21,920
|
|
|
|
the project is not only code and software
|
|
|
|
|
|
|
|
1278
|
|
|
|
00:40:20,318 --> 00:40:23,39
|
|
|
|
we manage those kind of knowledge base
|
|
|
|
|
|
|
|
1280
|
|
|
|
00:40:23,39 --> 00:40:27,759
|
2022-02-06 17:25:12 +01:00
|
|
|
for intelligent {inaudible} organization
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1281
|
|
|
|
00:40:26,79 --> 00:40:29,200
|
|
|
|
we have some specific one like the notice list
|
|
|
|
|
|
|
|
1283
|
|
|
|
00:40:28,899 --> 00:40:32,480
|
|
|
|
this one is a pretty small one that you use for the GDPR aspect
|
|
|
|
|
|
|
|
1285
|
|
|
|
00:40:32,480 --> 00:40:36,480
|
|
|
|
but this one can be used for anything you want,
|
|
|
|
|
|
|
|
1287
|
|
|
|
00:40:35,480 --> 00:40:40,960
|
|
|
|
It's for informing the analyst or the user of MISP when he
|
|
|
|
|
|
|
|
1288
|
|
|
|
00:40:39,358 --> 00:40:41,440
|
|
|
|
touched some specific information in MISP
|
|
|
|
|
|
|
|
1290
|
|
|
|
00:40:41,440 --> 00:40:45,280
|
|
|
|
that could impact for example the legal framework and so on
|
|
|
|
|
|
|
|
1292
|
|
|
|
00:40:44,280 --> 00:40:49,280
|
|
|
|
it's actively use in the intelligence community,
|
|
|
|
|
|
|
|
1293
|
|
|
|
00:40:47,119 --> 00:40:50,960
|
|
|
|
law enforcement and so on maybe less in
|
|
|
|
|
|
|
|
1294
|
|
|
|
00:40:49,280 --> 00:40:52,880
|
|
|
|
security operation center but it's
|
|
|
|
|
|
|
|
1295
|
|
|
|
00:40:50,960 --> 00:40:54,880
|
|
|
|
coming more and more due to the legal
|
|
|
|
|
|
|
|
1296
|
|
|
|
00:40:52,880 --> 00:40:56,240
|
|
|
|
side of information sharing and
|
|
|
|
|
|
|
|
1297
|
|
|
|
00:40:54,880 --> 00:40:58,480
|
|
|
|
especially storing information that might contain personal information
|
|
|
|
|
|
|
|
1299
|
|
|
|
00:40:58,480 --> 00:41:02,480
|
|
|
|
then we have another one called the
|
|
|
|
|
|
|
|
1300
|
|
|
|
00:40:59,679 --> 00:41:08,159
|
|
|
|
warning list and Andras quickly mentioned this kind of recurring problems or false positives
|
|
|
|
|
|
|
|
1303
|
|
|
|
00:41:06,559 --> 00:41:12,719
|
|
|
|
and the one in MISP are basically list of existing potential false positives
|
|
|
|
|
|
|
|
1305
|
|
|
|
1306
|
|
|
|
00:41:12,719 --> 00:41:17,439
|
|
|
|
for example we have lists of well-known IP addresses from Microsoft, for example.
|
|
|
|
|
|
|
|
1308
|
|
|
|
00:41:17,440 --> 00:41:20,800
|
|
|
|
We have list of things like domain names used by Google and so on
|
|
|
|
|
|
|
|
1310
|
|
|
|
00:41:20,800 --> 00:41:25,599
|
|
|
|
that's already helping users to find out
|
|
|
|
|
|
|
|
1311
|
|
|
|
00:41:23,519 --> 00:41:27,119
|
|
|
|
if something might be a false positive
|
|
|
|
|
|
|
|
1312
|
|
|
|
00:41:25,599 --> 00:41:28,559
|
|
|
|
and we do that automatically and we
|
|
|
|
|
|
|
|
1313
|
|
|
|
00:41:27,119 --> 00:41:30,800
|
2022-02-06 17:25:12 +01:00
|
|
|
maintain those libraries because one {inaudible MISP/reason} they're automatically updated regularly
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1315
|
|
|
|
00:41:30,800 --> 00:41:34,79
|
|
|
|
I think we have around 50 lists nowadays
|
|
|
|
|
|
|
|
1318
|
|
|
|
00:41:34,79 --> 00:41:38,160
|
|
|
|
It's really useful when you do on a day-to-day basis and creating events and
|
|
|
|
|
|
|
|
1320
|
|
|
|
00:41:38,159 --> 00:41:41,838
|
|
|
|
so on you can really find and spot things that might be a false positive in advance
|
|
|
|
|
|
|
|
1323
|
|
|
|
00:41:41,838 --> 00:41:48,0
|
|
|
|
2503.119 --> 2508
|
|
|
|
by having those warning lists enabled
|
|
|
|
|
|
|
|
1324
|
|
|
|
00:41:45,280 --> 00:41:49,839
|
|
|
|
and again it's up to the user to select
|
|
|
|
|
|
|
|
1325
|
|
|
|
00:41:48,0 --> 00:41:53,39
|
|
|
|
2508 --> 2511.04
|
2022-02-06 17:25:12 +01:00
|
|
|
one {inaudible} warning list or to enable everything depending on the different use case
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1328
|
|
|
|
00:41:52,800 --> 00:41:55,920
|
2022-02-06 17:25:12 +01:00
|
|
|
so that's one of those {inaudible} pillar
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1329
|
|
|
|
00:41:54,480 --> 00:41:57,519
|
2022-02-06 17:25:12 +01:00
|
|
|
knowledge base I mean a lot of
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1330
|
|
|
|
00:41:55,920 --> 00:41:57,519
|
|
|
|
contributions coming from threat parties
|
|
|
|
|
|
|
|
1332
|
|
|
|
00:41:57,519 --> 00:42:02,480
|
|
|
|
are coming from that aspect so it's not really programmers
|
|
|
|
|
|
|
|
1333
|
|
|
|
00:42:00,719 --> 00:42:03,679
|
|
|
|
or coders that are contributing there
|
|
|
|
|
|
|
|
1334
|
|
|
|
00:42:02,480 --> 00:42:05,599
|
|
|
|
but it's more analysts and people doing really threat intelligence
|
|
|
|
|
|
|
|
1336
|
|
|
|
00:42:05,599 --> 00:42:10,160
|
|
|
|
or classification and so on
|
|
|
|
|
|
|
|
1337
|
|
|
|
00:42:08,318 --> 00:42:12,79
|
|
|
|
is really something that is useful for everyone
|
|
|
|
|
|
|
|
1338
|
|
|
|
00:42:10,159 --> 00:42:14,159
|
|
|
|
without being your direct contributions on the code
|
|
|
|
|
|
|
|
1340
|
|
|
|
00:42:14,159 --> 00:42:18,719
|
|
|
|
then over the times we we we became a kind of de facto standard and
|
|
|
|
|
|
|
|
1342
|
|
|
|
00:42:18,719 --> 00:42:22,480
|
|
|
|
uh nowadays is even more than a de facto standard, is a standard
|
|
|
|
|
|
|
|
1344
|
|
|
|
00:42:22,480 --> 00:42:27,199
|
|
|
|
We published as an interesting engineering task force draft
|
|
|
|
|
|
|
|
1346
|
|
|
|
00:42:27,199 --> 00:42:31,439
|
|
|
|
all those documents especially the core format
|
|
|
|
|
|
|
|
1348
|
|
|
|
00:42:31,440 --> 00:42:35,200
|
|
|
|
and to ease that for the development of external tools
|
|
|
|
1350
|
|
|
|
00:42:35,199 --> 00:42:39,279
|
|
|
|
integration and so on.
|
|
|
|
|
|
|
|
1351
|
|
|
|
00:42:38,0 --> 00:42:40,119
|
|
|
|
2558 --> 2561.119
|
|
|
|
So if you're interested you can go to the
|
|
|
|
|
|
|
|
1352
|
|
|
|
00:42:39,280 --> 00:42:42,319
|
|
|
|
MISP platform website where we describe the different standards that we
|
|
|
|
|
|
|
|
1354
|
|
|
|
00:42:42,318 --> 00:42:47,199
|
|
|
|
published. We even co-host standards that are for people
|
|
|
|
|
|
|
|
1356
|
|
|
|
00:42:47,199 --> 00:42:51,598
|
|
|
|
integrating with MISP
|
|
|
|
|
|
|
|
1357
|
|
|
|
00:42:50,480 --> 00:42:53,599
|
|
|
|
and we have specific standards for example for the object template
|
|
|
|
|
|
|
|
1359
|
|
|
|
00:42:53,599 --> 00:42:56,800
|
|
|
|
and that's something that we will talkabout but that's something that was
|
|
|
|
|
|
|
|
1360
|
|
|
|
00:42:54,800 --> 00:42:58,79
|
|
|
|
|
|
|
|
1361
|
|
|
|
00:42:56,800 --> 00:42:59,839
|
|
|
|
really a need for us from the early beginning of MISP
|
|
|
|
|
|
|
|
1363
|
|
|
|
00:42:59,838 --> 00:43:02,799
|
|
|
|
a lot of organizations want to have their own structure of information
|
|
|
|
|
|
|
|
1365
|
|
|
|
00:43:02,800 --> 00:43:06,880
|
|
|
|
about objects and so on and we have a flexible model in MISP to
|
|
|
|
|
|
|
|
1367
|
|
|
|
00:43:06,880 --> 00:43:11,358
|
|
|
|
really create your own data models and this one is standardized too
|
|
|
|
|
|
|
|
1369
|
|
|
|
00:43:11,358 --> 00:43:15,358
|
|
|
|
and it's really helping sharing communities to
|
|
|
|
|
|
|
|
1371
|
|
|
|
00:43:15,358 --> 00:43:20,318
|
|
|
|
extend MISP as they wish and their models without breaking the
|
|
|
|
|
|
|
|
1373
|
|
|
|
00:43:20,318 --> 00:43:24,79
|
|
|
|
the standards itself so that's really interesting for for showing you new models
|
|
|
|
|
|
|
|
1376
|
|
|
|
00:43:24,79 --> 00:43:28,79
|
|
|
|
and then next to that we will do everything possible to help community
|
|
|
|
|
|
|
|
1378
|
|
|
|
00:43:28,79 --> 00:43:31,359
|
|
|
|
and Andras just mentioned the question of the
|
|
|
|
|
|
|
|
1380
|
|
|
|
00:43:31,358 --> 00:43:35,679
|
2022-02-06 17:25:12 +01:00
|
|
|
legal aspect and I think maybe some of
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1381
|
|
|
|
00:43:33,599 --> 00:43:38,640
|
|
|
|
you already have this order to
|
|
|
|
|
|
|
|
1382
|
|
|
|
00:43:35,679 --> 00:43:40,399
|
|
|
|
seek legal team about the information sharing policies and so on
|
|
|
|
|
|
|
|
1384
|
|
|
|
00:43:40,400 --> 00:43:44,880
|
|
|
|
we try to make it easier so we publish this kind of compliance document
|
|
|
|
|
|
|
|
1386
|
|
|
|
00:43:44,880 --> 00:43:48,160
|
|
|
|
and so on it's part of the MISP project
|
|
|
|
|
|
|
|
1387
|
|
|
|
00:43:46,719 --> 00:43:50,879
|
|
|
|
everything is open source again so everything we do is open source and
|
|
|
|
|
|
|
|
1389
|
|
|
|
00:43:50,880 --> 00:43:55,760
|
|
|
|
on open access. You can reuse it and so on. We have for example a specific
|
|
|
|
|
|
|
|
1391
|
|
|
|
00:43:55,760 --> 00:44:01,679
|
|
|
|
document about building communities which is something that we do within the X-ISAC project
|
|
|
|
|
|
|
|
1394
|
|
|
|
00:44:01,679 --> 00:44:08,960
|
|
|
|
and it's containing kind of best practices what are kind of agreement that you can
|
|
|
|
|
|
|
|
1397
|
|
|
|
00:44:08,960 --> 00:44:11,119
|
|
|
|
use when doing a setup of sharing communities.
|
|
|
|
|
|
|
|
1399
|
|
|
|
00:44:11,119 --> 00:44:15,440
|
|
|
|
Up to things about how to do contextualization and so on
|
|
|
|
|
|
|
|
1400
|
|
|
|
00:44:13,280 --> 00:44:17,40
|
|
|
|
so that's that's maybe something that
|
|
|
|
|
|
|
|
1401
|
|
|
|
00:44:15,440 --> 00:44:17,519
|
|
|
|
for an organization that wants to boost up an ISAC or sharing communities they can
|
|
|
|
|
|
|
|
1404
|
|
|
|
00:44:19,760 --> 00:44:23,760
|
|
|
|
look at those documents and so on so it's again a thing that we try to help
|
|
|
|
|
|
|
|
1406
|
|
|
|
00:44:23,760 --> 00:44:30,800
|
|
|
|
for example we produce kind of OSINT feeds of existing reports and so on to
|
|
|
|
|
|
|
|
1408
|
|
|
|
00:44:30,800 --> 00:44:36,880
|
|
|
|
not only have software ready but to have some content and to show what kind of
|
|
|
|
|
|
|
|
1411
|
|
|
|
00:44:36,880 --> 00:44:42,559
|
|
|
|
information can be shared within different MISP communities.
|
|
|
|
|
|
|
|
1413
|
|
|
|
00:44:42,559 --> 00:44:48,880
|
|
|
|
So let us some get some of the naming conventions out of the way
|
|
|
|
|
|
|
|
1415
|
|
|
|
00:44:48,880 --> 00:44:52,880
|
|
|
|
before we start with the hands-on stuff and
|
|
|
|
|
|
|
|
1416
|
|
|
|
00:44:50,400 --> 00:44:58,719
|
|
|
|
just a quick explanation of the different uh data points and uh and naming conventions
|
|
|
|
|
|
|
|
1419
|
|
|
|
00:44:57,119 --> 00:45:00,400
|
|
|
|
that we use for them so it's a bit easier afterwards
|
|
|
|
|
|
|
|
1421
|
|
|
|
00:45:00,400 --> 00:45:08,0
|
|
|
|
this can be a bit overwhelming, don't worry we'll go through everything step by step also
|
|
|
|
|
|
|
|
1424
|
|
|
|
00:45:04,639 -->
|
|
|
|
during the hands-on part
|
|
|
|
|
|
|
|
1426
|
|
|
|
00:45:05,519 --> 00:45:13,440
|
|
|
|
So basically all the data that goes into MISP, we separate into two main layers
|
|
|
|
|
|
|
|
1427
|
|
|
|
00:45:11,358 --> 00:45:14,880
|
|
|
|
one we call data layer which is really everything it has to do with
|
|
|
|
|
|
|
|
1429
|
|
|
|
00:45:14,880 --> 00:45:22,0
|
|
|
|
individual data points their compositioning and so on
|
|
|
|
|
|
|
|
1432
|
|
|
|
00:45:20,400 --> 00:45:23,358
|
|
|
|
So everything that we share in MISP in general in this regard
|
|
|
|
|
|
|
|
1433
|
|
|
|
00:45:22,0 --> 00:45:25,199
|
|
|
|
2722 --> 2725.2
|
|
|
|
starts with something that we call an event, these are our general
|
|
|
|
|
|
|
|
1435
|
|
|
|
00:45:25,199 --> 00:45:28,559
|
|
|
|
envelopes for information so that means that
|
|
|
|
|
|
|
|
1437
|
|
|
|
00:45:28,559 --> 00:45:32,960
|
|
|
|
whenever we're describing an incident, we're describing a threat report
|
|
|
|
|
|
|
|
1439
|
|
|
|
00:45:32,960 --> 00:45:36,0
|
|
|
|
2732.96 --> 2736
|
|
|
|
we're describing a watch list that we recurringly update
|
|
|
|
|
|
|
|
1441
|
|
|
|
00:45:36,0 --> 00:45:40,400
|
|
|
|
2736 --> 2740.4
|
|
|
|
and they will all be grouped into something that we call an event
|
|
|
|
|
|
|
|
1443
|
|
|
|
00:45:40,400 --> 00:45:45,680
|
|
|
|
So the name is a little bit controversial at times, we try to pick a name
|
|
|
|
|
|
|
|
1445
|
|
|
|
00:45:45,679 --> 00:45:49,519
|
|
|
|
that is the least amount of a loaded term that we could find
|
|
|
|
|
|
|
|
1448
|
|
|
|
00:45:51,440 --> 00:45:56,240
|
|
|
|
but obviously even with that there it can be a bit confusing but just consider
|
|
|
|
|
|
|
|
1450
|
|
|
|
00:45:56,239 -->
|
|
|
|
it as a generic container for data that has some contextual linking
|
|
|
|
|
|
|
|
1453
|
|
|
|
00:45:59,39 --> 00:46:06,318
|
|
|
|
then each of these events is populated with lists of attributes.
|
|
|
|
|
|
|
|
1455
|
|
|
|
00:46:05,318 --> 00:46:09,838
|
|
|
|
So attributes are the most basic data points in MISP
|
|
|
|
|
|
|
|
1457
|
|
|
|
00:46:09,838 --> 00:46:13,279
|
|
|
|
an attribute can describe for example an IP address
|
|
|
|
|
|
|
|
1459
|
|
|
|
00:46:13,280 --> 00:46:21,199
|
|
|
|
you can describe a file hash or it can describe a car plate number for example
|
|
|
|
|
|
|
|
1462
|
|
|
|
00:46:21,199 --> 00:46:27,759
|
|
|
|
It's basically just an individual data point with some basic context around it
|
|
|
|
|
|
|
|
1465
|
|
|
|
00:46:27,760 --> 00:46:30,800
|
|
|
|
such as describing in what context this was seen in
|
|
|
|
|
|
|
|
1467
|
|
|
|
00:46:30,800 --> 00:46:32,960
|
|
|
|
what type we're using to describe the attribute,
|
|
|
|
|
|
|
|
1469
|
|
|
|
00:46:32,960 --> 00:46:39,679
|
|
|
|
for example that we're using an MD5 hash to describe the hash of a file
|
|
|
|
|
|
|
|
1471
|
|
|
|
00:46:39,679 --> 00:46:44,318
|
|
|
|
would be one of those descriptions, hopefully not used as much these days
|
|
|
|
|
|
|
|
1473
|
|
|
|
00:46:44,318 --> 00:46:51,920
|
|
|
|
but that's just an example and then we can take these individual attributes
|
|
|
|
|
|
|
|
1476
|
|
|
|
00:46:49,599 --> 00:46:55,318
|
|
|
|
and composite them into what we call objects that are describing multifaceted concepts.
|
|
|
|
|
|
|
|
1478
|
|
|
|
00:46:54,318 --> 00:46:59,440
|
|
|
|
For example, a file object would be described by a list of attributes
|
|
|
|
|
|
|
|
1480
|
|
|
|
00:46:59,440 --> 00:47:05,760
|
|
|
|
including a file name, different file hashes, maybe file entropy and so on and so forth.
|
|
|
|
|
|
|
|
1484
|
|
|
|
00:47:05,760 --> 00:47:11,440
|
|
|
|
Each of these individual objects and attributes can then be further interlinked by what we call references.
|
|
|
|
|
|
|
|
1487
|
|
|
|
00:47:11,440 --> 00:47:15,119
|
|
|
|
So that means that most of the time when we're describing data in MISP
|
|
|
|
|
|
|
|
1489
|
|
|
|
00:47:15,119 --> 00:47:20,0
|
|
|
|
we're trying to tell a story so we're thinking graphs instead of individual data points
|
|
|
|
|
|
|
|
1492
|
|
|
|
00:47:20,0 --> 00:47:24,559
|
|
|
|
2840 --> 2844.559
|
|
|
|
that means that we can for example, describe the entire flow of an attack
|
|
|
|
|
|
|
|
1494
|
|
|
|
00:47:24,559 --> 00:47:28,79
|
|
|
|
from the initial attack vector all the way to the exploitation
|
|
|
|
|
|
|
|
1496
|
|
|
|
00:47:28,79 --> 00:47:33,599
|
|
|
|
using the interconnected graphs using these references so we could say
|
|
|
|
|
|
|
|
1498
|
|
|
|
00:47:33,599 --> 00:47:36,960
|
|
|
|
initially it all started with an email that was received
|
|
|
|
|
|
|
|
1500
|
|
|
|
00:47:36,960 --> 00:47:40,559
|
|
|
|
that contained for example a malicious sample which then had to send this effect
|
|
|
|
|
|
|
|
1503
|
|
|
|
00:47:42,480 --> 00:47:45,838
|
|
|
|
in our infrastructure so all of these different steps can be then described
|
|
|
|
|
|
|
|
1506
|
|
|
|
00:47:45,0 --> 00:47:53,519
|
|
|
|
2868 --> 2873.52
|
|
|
|
via different references there then to aggregate this information
|
|
|
|
|
|
|
|
1508
|
|
|
|
00:47:53,519 --> 00:47:58,79
|
|
|
|
into and aggregate the sightings of this information via structure
|
|
|
|
|
|
|
|
1510
|
|
|
|
00:47:58,79 --> 00:48:02,280
|
|
|
|
that basically captures sightings from our different information sources
|
|
|
|
|
|
|
|
1512
|
|
|
|
00:48:01,280 --> 00:48:05,760
|
|
|
|
that means if you have an IDS that is generating alerts
|
|
|
|
|
|
|
|
1514
|
|
|
|
00:48:05,760 --> 00:48:10,640
|
|
|
|
you can feed information back on when individual attributes were seen
|
|
|
|
|
|
|
|
1516
|
|
|
|
00:48:10,639 --> 00:48:16,159
|
|
|
|
in your network, in your premises or at your partners and so on
|
|
|
|
|
|
|
|
1518
|
|
|
|
00:48:16,159 --> 00:48:21,920
|
|
|
|
so this is basically it for the data layer, these are our main building blocks for that.
|
|
|
|
|
|
|
|
1521
|
|
|
|
00:48:21,920 --> 00:48:27,599
|
|
|
|
now in order to contextualize this information, we have different tools at our disposal.
|
|
|
|
|
|
|
|
1523
|
|
|
|
00:48:27,599 --> 00:48:32,160
|
|
|
|
The most simple one is what we call tags these are basic text labels that
|
|
|
|
|
|
|
|
1525
|
|
|
|
00:48:31,159 --> 00:48:35,598
|
|
|
|
we attach on individual data points or entire events
|
|
|
|
|
|
|
|
1527
|
|
|
|
00:48:35,599 --> 00:48:39,440
|
|
|
|
and these can either be created freely or most commonly they come from what we call taxonomies.
|
|
|
|
|
|
|
|
1530
|
|
|
|
00:48:41,519 --> 00:48:46,400
|
|
|
|
They're basically standardized vocabularies and that are either shared
|
|
|
|
|
|
|
|
1532
|
|
|
|
00:48:46,400 --> 00:48:54,880
|
|
|
|
by us so the MISP project at large or by individual communities to their members so
|
|
|
|
|
|
|
|
1535
|
|
|
|
00:48:53,119 --> 00:48:57,39
|
|
|
|
these vocabularies can include anything from for example something is simple and
|
|
|
|
|
|
|
|
1537
|
|
|
|
00:48:57,39 --> 00:49:01,279
|
|
|
|
and commonly used as TLP to national classifications
|
|
|
|
|
|
|
|
1540
|
|
|
|
00:49:01,279 --> 00:49:08,719
|
|
|
|
to various different sectoral classifications and so on
|
|
|
|
|
|
|
|
1541
|
|
|
|
00:49:06,318 --> 00:49:12,79
|
|
|
|
now if you wanted to provide more high-level information instead of just simple
|
|
|
|
|
|
|
|
1544
|
|
|
|
00:49:12,559 --> 00:49:16,640
|
|
|
|
labels for the information we can use what we call galaxy clusters
|
|
|
|
|
|
|
|
1546
|
|
|
|
00:49:16,639 --> 00:49:20,400
|
|
|
|
so galaxy cluster is basically a knowledge based element that we use as a label
|
|
|
|
|
|
|
|
1549
|
|
|
|
00:49:21,199 --> 00:49:24,879
|
|
|
|
these can be either coming from standard libraries
|
|
|
|
|
|
|
|
1551
|
|
|
|
00:49:24,880 --> 00:49:28,480
|
|
|
|
such as the ones that we maintain or you can create them ad-hoc in MISP.
|
|
|
|
|
|
|
|
1553
|
|
|
|
00:49:28,480 --> 00:49:30,0
|
|
|
|
That means if you're describing a threat actor
|
|
|
|
|
|
|
|
1555
|
|
|
|
00:49:30,0 --> 00:49:35,358
|
|
|
|
you could create create a threat actor galaxy cluster that describes the various metadata
|
|
|
|
|
|
|
|
1557
|
|
|
|
00:49:35,358 --> 00:49:38,558
|
|
|
|
about the threat actor and then use this to label your data whenever you think
|
|
|
|
|
|
|
|
1560
|
|
|
|
00:49:38,880 --> 00:49:42,160
|
|
|
|
that whatever you're describing is associated with a threat actor
|
|
|
|
|
|
|
|
1562
|
|
|
|
00:49:42,159 --> 00:49:46,480
|
|
|
|
you can also create for example a galaxy cluster describing the different
|
|
|
|
|
|
|
|
1564
|
|
|
|
00:49:46,480 --> 00:49:53,760
|
|
|
|
target sectors and then interlink using cluster relationships
|
|
|
|
|
|
|
|
1566
|
|
|
|
00:49:53,760 --> 00:50:04,559
|
|
|
|
the threat actor galaxy clusters with target sectors with exploited TTP and so on and so forth
|
|
|
|
|
|
|
|
1569
|
|
|
|
00:50:03,440 --> 00:50:07,39
|
|
|
|
So these are the high level structures that you can put on top of your data
|
|
|
|
|
|
|
|
1572
|
|
|
|
00:50:06,719 --> 00:50:14,838
|
|
|
|
basically to further contextualize it. Alex
|
|
|
|
|
|
|
|
1574
|
|
|
|
00:50:15,119 --> 00:50:21,39
|
|
|
|
Yeah, so just to summarize it and that's always a lot of people are asking about it
|
|
|
|
|
|
|
|
1577
|
|
|
|
00:50:21,199 --> 00:50:26,319
|
|
|
|
how do you summarize it about, for example in easy way you have to see really
|
|
|
|
|
|
|
|
1580
|
|
|
|
00:50:26,318 --> 00:50:29,838
|
2022-02-06 17:25:12 +01:00
|
|
|
MISP {inaudible environment/development} as an envelope and then you
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1581
|
|
|
|
00:50:28,79 --> 00:50:32,318
|
|
|
|
have information inside and then what Andras describe is basically
|
|
|
|
|
|
|
|
1583
|
|
|
|
00:50:32,318 --> 00:50:34,800
|
|
|
|
different component that you have within that envelope and then you have
|
|
|
|
|
|
|
|
1586
|
|
|
|
00:50:35,760 --> 00:50:42,480
|
|
|
|
contextual layers on that envelope and relationship that are basically based on on that.
|
|
|
|
|
|
|
|
1589
|
|
|
|
00:50:42,880 --> 00:50:50,400
|
|
|
|
So, another thing that is very often and I think it is good to explain it, is about the
|
|
|
|
|
|
|
|
1592
|
|
|
|
00:50:48,960 --> 00:50:53,119
|
|
|
|
terminology between indicators, attributes, and so on that is
|
|
|
|
|
|
|
|
1594
|
|
|
|
00:50:53,119 --> 00:50:57,358
|
|
|
|
a different especially indicator of compromise and so on
|
|
|
|
|
|
|
|
1596
|
|
|
|
00:50:57,358 --> 00:51:01,440
|
|
|
|
In MISP, an attribute is close to an indicator
|
|
|
|
|
|
|
|
1598
|
|
|
|
00:51:01,440 --> 00:51:05,599
|
|
|
|
and we have this kind of flexible models where
|
|
|
|
|
|
|
|
1600
|
|
|
|
00:51:05,599 --> 00:51:09,200
|
|
|
|
maybe some of you are familiar with observables in MISP
|
|
|
|
|
|
|
|
1602
|
|
|
|
00:51:09,199 --> 00:51:13,440
|
|
|
|
we call it attributes and those observables are basically depending on the type
|
|
|
|
|
|
|
|
1605
|
|
|
|
00:51:13,440 --> 00:51:20,0
|
|
|
|
So, we have a specific flag in attributes which is basically defining
|
|
|
|
|
|
|
|
1608
|
|
|
|
00:51:20,0 --> 00:51:23,599
|
|
|
|
3080 --> 3083.599
|
|
|
|
if information can be used automatically for detection
|
|
|
|
|
|
|
|
1610
|
|
|
|
00:51:23,599 --> 00:51:29,960
|
2022-02-06 17:25:12 +01:00
|
|
|
and that's I think one of the most important aspects when we talk about attribute in MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1613
|
|
|
|
00:51:28,880 --> 00:51:34,119
|
|
|
|
an attribute can become an observable or become an indicator of compromise
|
|
|
|
|
|
|
|
1615
|
|
|
|
00:51:33,119 --> 00:51:37,880
|
|
|
|
depending on the simple flag and this is quite important because
|
|
|
|
|
|
|
|
1618
|
|
|
|
00:51:37,280 --> 00:51:43,599
|
|
|
|
a lot of analysis and so on will depend on that and especially all you will use that afterwards
|
|
|
|
|
|
|
|
1621
|
|
|
|
00:51:43,599 --> 00:51:48,39
|
|
|
|
if you plan for example to use the data into a protective systems and so on
|
|
|
|
|
|
|
|
1624
|
|
|
|
00:51:48,39 --> 00:51:54,79
|
2022-02-06 17:25:12 +01:00
|
|
|
the IDS flags need to be set so the thing is if I take an example
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1626
|
|
|
|
00:51:54,79 --> 00:51:56,480
|
|
|
|
you reverse the malware and this malware is connected to google.com for testing the connectivity
|
|
|
|
|
|
|
|
1629
|
|
|
|
00:51:59,519 --> 00:52:04,79
|
|
|
|
obviously you will have an attribute for example www.google.com
|
|
|
|
|
|
|
|
1632
|
|
|
|
00:52:03,79 --> 00:52:09,440
|
|
|
|
and this one is an interesting indicator for information for the analyst
|
|
|
|
|
|
|
|
1634
|
|
|
|
00:52:09,440 --> 00:52:14,0
|
|
|
|
so like that you can for example maybe cluster those kind of malware together as in this kind of behavior
|
|
|
|
|
|
|
|
1637
|
|
|
|
00:52:14,0 --> 00:52:19,279
|
|
|
|
3134 --> 3136.64
|
|
|
|
nevertheless you are not really interested in that information as an indicator of compromise
|
|
|
|
|
|
|
|
1641
|
|
|
|
00:52:19,280 --> 00:52:23,480
|
|
|
|
because it will generate a huge amount of false positive
|
|
|
|
|
|
|
|
1644
|
|
|
|
00:52:23,480 --> 00:52:28,640
|
|
|
|
but if for example at some point you have an IP address that is really dedicated to that malware
|
|
|
|
|
|
|
|
1646
|
|
|
|
00:52:28,639 --> 00:52:39,719
|
|
|
|
then you will set the IDS flag, so the thing is when you define in MISP these flags
|
|
|
|
|
|
|
|
1649
|
|
|
|
00:52:38,760 --> 00:52:41,599
|
|
|
|
and we will show you later on it's very important because it will define what you can do
|
|
|
|
|
|
|
|
1652
|
|
|
|
00:52:41,599 --> 00:52:48,639
|
|
|
|
3164 --> 3166.64
|
|
|
|
with information later on if you're going to automate and so on like
|
|
|
|
|
|
|
|
1655
|
|
|
|
00:52:48,159 --> 00:52:52,239
|
|
|
|
In MISP, what we try to do too instead of having just indicators
|
|
|
|
|
|
|
|
1657
|
|
|
|
00:52:52,239 --> 00:52:57,280
|
2022-02-06 17:25:12 +01:00
|
|
|
it's very common and I think many of you know about it you might see for example
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1660
|
|
|
|
00:52:57,280 --> 00:53:01,599
|
|
|
|
a list of hashes so like for example MD5 hashes without any context
|
|
|
|
|
|
|
|
1662
|
|
|
|
00:53:01,599 --> 00:53:05,280
|
|
|
|
and sometimes it's difficult to know exactly what we are talking about
|
|
|
|
|
|
|
|
1664
|
|
|
|
00:53:05,280 --> 00:53:11,599
|
|
|
|
Are we talking about MD5 of malicious sample, are we talking about md5 of legitimate software,
|
|
|
|
|
|
|
|
1667
|
|
|
|
00:53:11,599 --> 00:53:17,39
|
|
|
|
are we talking about the MD5 value of the X.509 certificate,
|
|
|
|
|
|
|
|
1669
|
|
|
|
00:53:17,39 --> 00:53:29,719
|
|
|
|
are we talking about an MD5 as a mutex in memory
|
|
|
|
|
|
|
|
1670
|
|
|
|
00:53:19,679 --> 00:53:25,759
|
|
|
|
we have plenty of way of seeing those kind of MD5 so we try in MISP to have what we call the
|
|
|
|
|
|
|
|
1673
|
|
|
|
00:53:25,759 --> 00:53:30,318
|
2022-02-06 17:25:12 +01:00
|
|
|
kind of I would not say {inaudible keep shine/kill shine} but at least contextualization a category that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1675
|
|
|
|
00:53:30,318 --> 00:53:35,279
|
|
|
|
help to see in which context this has been seen
|
|
|
|
|
|
|
|
1677
|
|
|
|
00:53:35,280 --> 00:53:41,119
|
|
|
|
and as for example if 1 MD5 might have a payload delivery, telling that in which scope this has been set
|
|
|
|
|
|
|
|
1680
|
|
|
|
00:53:40,559 --> 00:53:45,440
|
|
|
|
So that means in MISP we have always and complementary type
|
|
|
|
|
|
|
|
1682
|
|
|
|
00:53:45,440 --> 00:53:52,639
|
|
|
|
so for example for an MD5 files you can say that this one is from a file or is an md5 of a fingerprint thing
|
|
|
|
|
|
|
|
1686
|
|
|
|
00:53:52,639 --> 00:53:59,679
|
|
|
|
So that means, always in MISP try to have as an indicator all those three information together
|
|
|
|
|
|
|
|
1689
|
|
|
|
00:53:59,679 --> 00:54:06,639
|
|
|
|
so it is giving at least more context and if you cannot set this context MISP will try to automatically set it.
|
|
|
|
|
|
|
|
1692
|
|
|
|
00:54:05,639 --> 00:54:12,239
|
|
|
|
So attributes are equal to indicators but with a bit more of information which is useful for you
|
|
|
|
|
|
|
|
1695
|
|
|
|
00:54:12,239 --> 00:54:19,358
|
|
|
|
At least being in a way to understand what is in a position to understand what you have in front of you
|
|
|
|
|
|
|
|
1699
|
|
|
|
00:54:19,358 --> 00:54:28,400
|
|
|
|
when you have to treat those attributes.
|
|
|
|
|
|
|
|
1700
|
|
|
|
00:54:25,358 --> 00:54:29,920
|
|
|
|
So this is just a brief view of what this looks like.
|
|
|
|
|
|
|
|
1702
|
|
|
|
00:54:29,920 --> 00:54:36,239
|
|
|
|
We're going to see this more in practice basically the idea is that all the data that we have in MISP
|
|
|
|
|
|
|
|
1705
|
|
|
|
00:54:36,239 --> 00:54:43,798
|
|
|
|
if it's well defined allows us to draw a graph out of the data and allows us to tell a story more easily
|
|
|
|
|
|
|
|
1708
|
|
|
|
00:54:42,880 --> 00:54:55,798
|
|
|
|
So here we see a simple example that basically shows the bank account that is associated with the threat actor
|
|
|
|
|
|
|
|
1712
|
|
|
|
00:54:54,480 --> 00:55:00,679
|
|
|
|
With all the various different data points with it and then we can basically relate these
|
|
|
|
|
|
|
|
1715
|
|
|
|
00:54:59,280 --> 00:55:03,200
|
|
|
|
different data points to each other and give the relationship a term as well
|
|
|
|
|
|
|
|
1718
|
|
|
|
00:55:04,880 --> 00:55:08,160
|
|
|
|
So in this case we see from the chart immediately there that that person is the owner of that
|
|
|
|
|
|
|
|
1720
|
|
|
|
00:55:08,159 --> 00:55:13,119
|
|
|
|
bank account with all those different data points for us as humans it's it's generally much more
|
|
|
|
|
|
|
|
1724
|
|
|
|
00:55:13,119 --> 00:55:18,839
|
|
|
|
easily understood if we look at a graph like that and tell the story that way
|
|
|
|
|
|
|
|
1727
|
|
|
|
00:55:17,839 --> 00:55:22,480
|
|
|
|
then if we look at a tabularized view of the data.
|
|
|
|
|
|
|
|
1728
|
|
|
|
00:55:20,798 --> 00:55:24,239
|
|
|
|
So one of the goals and something that we hope that we get out of
|
|
|
|
|
|
|
|
1731
|
|
|
|
00:55:24,239 --> 00:55:32,480
|
|
|
|
going through trainings like these is to really convert also the participants
|
|
|
|
|
|
|
|
1732
|
|
|
|
00:55:29,679 --> 00:55:38,558
|
|
|
|
to to see the value of producing data in that way instead of just sharing raw indicator lists for example.
|
|
|
|
|
|
|
|
1735
|
|
|
|
00:55:40,0 --> 00:55:45,199
|
|
|
|
3340 --> 3343.2
|
|
|
|
And that's again what we think that's really important is the contextualization again.
|
|
|
|
|
|
|
|
1738
|
|
|
|
00:55:45,280 --> 00:55:50,480
|
2022-02-06 17:25:12 +01:00
|
|
|
So I mentioned we have the galaxies in MISP and we have plenty of representation
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1741
|
|
|
|
00:55:50,318 --> 00:55:55,838
|
|
|
|
threat actors and so on and obviously one that is quite important is the MITRE Attack one
|
|
|
|
|
|
|
|
1744
|
|
|
|
00:55:54,719 --> 00:55:57,759
|
2022-02-06 17:25:12 +01:00
|
|
|
so MITRE Attack is {inaudible stored/performed} as a galaxy
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1746
|
|
|
|
00:55:57,760 --> 00:56:01,520
|
2022-02-06 17:25:12 +01:00
|
|
|
and we have this flexible {inaudible mosaic/table} in MISP that you can represent those kind of
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
748
|
|
|
|
00:56:01,519 --> 00:56:07,39
|
|
|
|
matrix-like model which is a case for Attack which is a very convenient way of representing the
|
|
|
|
|
|
|
|
1752
|
|
|
|
00:56:07,679 --> 00:56:14,480
|
|
|
|
different techniques in a progressive way used by the attackers and that's exactly what we can do in MISP.
|
|
|
|
|
|
|
|
1755
|
|
|
|
00:56:14,159 --> 00:56:22,79
|
|
|
|
So you have this kind of model and we have different model formats so again we have an advanced
|
|
|
|
|
|
|
|
1758
|
|
|
|
00:56:22,79 --> 00:56:30,838
|
|
|
|
i would say integration with Attack but you can extend it with multiple different kinds of galaxies which are
|
|
|
|
|
|
|
|
1762
|
|
|
|
00:56:30,0 --> 00:56:33,838
|
|
|
|
3390 --> 3393.839
|
|
|
|
similar to Attack or complementary for example we have the Industrial Control System of Attack,
|
|
|
|
|
|
|
|
1765
|
|
|
|
00:56:34,400 --> 00:56:39,440
|
|
|
|
it's a separated galaxy, you can even create a custom one directly in the system
|
|
|
|
|
|
|
|
1768
|
|
|
|
00:56:39,440 --> 00:56:46,519
|
2022-02-06 17:25:12 +01:00
|
|
|
and then you can filter out your data and so on and that's exactly the thing why we are I would say
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1771
|
|
|
|
00:56:46,880 --> 00:56:51,480
|
|
|
|
in bracket pushing people to do more contextualization, it would be useful forthem at the end
|
|
|
|
|
|
|
|
1774
|
|
|
|
00:56:51,599 --> 00:56:58,960
|
|
|
|
because this kind of information is really showing you for example your gap in your defense
|
|
|
|
|
|
|
|
1778
|
|
|
|
00:56:58,960 --> 00:57:02,720
|
|
|
|
your specific things that the techniques that are not used by an attacker
|
|
|
|
|
|
|
|
1780
|
|
|
|
00:57:02,719 --> 00:57:05,279
|
|
|
|
you might ask why, maybe because you are missing a specific detection point that you cannot
|
|
|
|
|
|
|
|
1783
|
|
|
|
00:57:05,279 --> 00:57:12,239
|
|
|
|
detect this kind of attacks or things like that so it's really actively using the data
|
|
|
|
|
|
|
|
1786
|
|
|
|
00:57:12,239 --> 00:57:15,759
|
2022-02-06 17:25:12 +01:00
|
|
|
to show something meaningful with it and I think Attack is one of the way
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1788
|
|
|
|
00:57:15,760 --> 00:57:19,119
|
|
|
|
but if you can combine this with additional information like site links,
|
|
|
|
|
|
|
|
1789
|
|
|
|
00:57:19,119 --> 00:57:22,239
|
|
|
|
contextualization of the relationship between different objects and so on
|
|
|
|
|
|
|
|
1792
|
|
|
|
00:57:22,239 --> 00:57:26,558
|
|
|
|
basically everything in hand to improve your posture and secure it.
|
|
|
|
|
|
|
|
1794
|
|
|
|
00:57:26,559 --> 00:57:29,0
|
|
|
|
Yeah perhaps something to add to this as well,
|
|
|
|
|
|
|
|
1796
|
|
|
|
00:57:29,0 --> 00:57:33,838
|
|
|
|
some of the additional advantages is the moment that you encode all this information along
|
|
|
|
|
|
|
|
1798
|
|
|
|
00:57:33,838 --> 00:57:39,39
|
|
|
|
with the data you can start asking those those questions from your tool basically
|
|
|
|
|
|
|
|
1800
|
|
|
|
00:57:39,39 --> 00:57:47,838
|
|
|
|
for example show me what sort of threats my constituency is facing over the past year
|
|
|
|
|
|
|
|
1804
|
|
|
|
00:57:45,760 --> 00:57:49,760
|
|
|
|
and overlayed over how what sort of threats it was facing a year ago
|
|
|
|
|
|
|
|
1806
|
|
|
|
00:57:49,760 --> 00:57:52,319
|
|
|
|
what are the trends that have evolved since then
|
|
|
|
|
|
|
|
1808
|
|
|
|
00:57:52,318 --> 00:57:58,960
|
|
|
|
the other thing that it really helps with is it also gives you a high level overview of individual reports
|
|
|
|
|
|
|
|
1811
|
|
|
|
00:57:56,400 --> 00:58:06,78
|
|
|
|
that means if I'm looking at an event in MISP and it has 800 different attributes described in there
|
|
|
|
|
|
|
|
1815
|
|
|
|
00:58:06,79 --> 00:58:10,719
|
|
|
|
making any sense out of that quickly is very difficult, but getting a high level overview using MITRE Attack
|
|
|
|
|
|
|
|
1818
|
|
|
|
00:58:10,719 --> 00:58:16,239
|
|
|
|
where you say oh okay this has to deal with spearphishing, it has to deal with information exfiltration,
|
|
|
|
|
|
|
|
1821
|
|
|
|
00:58:16,239 --> 00:58:22,79
|
|
|
|
so these immediately tell me the story of what i'm dealing with without having to dig deeper into the data itself
|
|
|
|
|
|
|
|
1825
|
|
|
|
00:58:22,79 --> 00:58:27,480
|
|
|
|
so it is incredibly useful for an analyst that is trying to make sense of the data that you're sharing.
|
|
|
|
|
|
|
|
1828
|
|
|
|
00:58:27,480 --> 00:58:36,0
|
2022-02-06 17:25:12 +01:00
|
|
|
Also, as for the sharing itself I mean one of the main goals with MISP is obviously to share information,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1831
|
|
|
|
00:58:36,0 --> 00:58:43,280
|
|
|
|
We haven't really talked about the sharing mechanisms yet, we basically have a bunch of different functionalities in MISP
|
|
|
|
|
|
|
|
1834
|
|
|
|
00:58:42,880 --> 00:58:48,639
|
|
|
|
that we're going to see over the next two days the deal with distributing the information.
|
|
|
|
|
|
|
|
1838
|
|
|
|
00:58:48,639 --> 00:58:55,280
|
|
|
|
One of the most obvious ones to tackle is basically who is to be the recipient of information that we're sharing
|
|
|
|
|
|
|
|
1842
|
|
|
|
00:58:55,280 --> 00:59:04,400
|
|
|
|
so basically MISP, we can basically set the distribution settings for each individual data point individually
|
|
|
|
|
|
|
|
1846
|
|
|
|
00:59:04,400 --> 00:59:10,760
|
|
|
|
or for entire collections of data in one shot so that means if we create an event we can decide who we share the event with
|
|
|
|
|
|
|
|
1849
|
|
|
|
00:59:09,760 --> 00:59:15,160
|
|
|
|
but we can further restrict individual attributes or objects further.
|
|
|
|
|
|
|
|
1854
|
|
|
|
00:59:14,838 --> 00:59:26,79
|
|
|
|
Now, who we share the information with gets decided on using one of two different means,
|
|
|
|
|
|
|
|
1857
|
|
|
|
00:59:25,79 --> 00:59:29,39
|
|
|
|
one of them is a simple system where we tell MISP you are allowed to distribute it to everyone
|
|
|
|
|
|
|
|
1858
|
|
|
|
00:59:28,440 --> 00:59:31,280
|
|
|
|
that has access to this community, for example.
|
|
|
|
|
|
|
|
1860
|
|
|
|
00:59:31,280 --> 00:59:39,440
|
|
|
|
Or to everyone that is directly connected to my community but you can also define more strict distribution lists
|
|
|
|
|
|
|
|
1863
|
|
|
|
00:59:37,838 --> 00:59:44,400
|
|
|
|
what we call sharing groups where you individually name the organizations that are to be the recipients.
|
|
|
|
|
|
|
|
1868
|
|
|
|
00:59:44,400 --> 00:59:52,159
|
|
|
|
Now on top of that, one of the things that we often struggle with is especially if you're in some of those communities
|
|
|
|
|
|
|
|
1872
|
|
|
|
00:59:51,159 --> 01:00:01,39
|
|
|
|
or you're taking part or assisting some of the communities where sharing any information might lead to reputation or financial loss.
|
|
|
|
|
|
|
|
1876
|
|
|
|
01:00:01,39 --> 01:00:04,318
|
|
|
|
For example in the financial sector we have these worries very often
|
|
|
|
|
|
|
|
1878
|
|
|
|
01:00:04,318 --> 01:00:08,318
|
|
|
|
where if a financial organization were to share any information out
|
|
|
|
|
|
|
|
1880
|
|
|
|
01:00:08,318 --> 01:00:11,838
|
|
|
|
it could be misconstrued as a successful attack against them.
|
|
|
|
|
|
|
|
1882
|
|
|
|
01:00:11,838 --> 01:00:15,719
|
|
|
|
So instead, they choose to basically even if it was something completely benign
|
|
|
|
|
|
|
|
1884
|
|
|
|
01:00:14,719 --> 01:00:20,239
|
|
|
|
that they caught in their sandboxes, in their honeypots, whatever
|
|
|
|
|
|
|
|
1887
|
|
|
|
01:00:19,199 --> 01:00:24,399
|
|
|
|
and they decide not to share it out of fear of incurring this reputation loss.
|
|
|
|
|
|
|
|
1889
|
|
|
|
01:00:24,399 --> 01:00:29,440
|
|
|
|
So one of the things that we have in MISP is this system called Delegation
|
|
|
|
|
|
|
|
1891
|
|
|
|
01:00:29,440 --> 01:00:31,920
|
|
|
|
where you can, for example appoint your ISAC,
|
|
|
|
|
|
|
|
1892
|
|
|
|
01:00:29,679 --> 01:00:38,558
|
|
|
|
your central authority for a community, a national CSIRT, whatever
|
|
|
|
|
|
|
|
1893
|
|
|
|
01:00:38,558 --> 01:00:41,599
|
|
|
|
with the responsibility of taking over the data that you produce
|
|
|
|
|
|
|
|
1898
|
|
|
|
01:00:41,599 --> 01:00:43,480
|
|
|
|
and to share it out in their name
|
|
|
|
|
|
|
|
1900
|
|
|
|
01:00:43,480 --> 01:00:48,838
|
|
|
|
so that way, it's basically a semi anonymized information sharing
|
|
|
|
|
|
|
|
1901
|
|
|
|
01:00:48,559 --> 01:00:50,880
|
|
|
|
where you are completely removed from the data that is shared out
|
|
|
|
|
|
|
|
1903
|
|
|
|
01:00:50,880 --> 01:00:55,500
|
|
|
|
so the only two parties that will know who the originator of the data is you
|
|
|
|
|
|
|
|
1904
|
|
|
|
01:00:55,500 --> 01:01:01,500
|
|
|
|
and whoever is taking over the data and taking over responsibility for the data.
|
|
|
|
|
|
|
|
1909
|
|
|
|
01:01:02,0 --> 01:01:05,280
|
|
|
|
On top of that, one of the things that we wanted to achieve with MISP
|
|
|
|
|
|
|
|
1911
|
|
|
|
01:01:05,280 --> 01:01:08,720
|
|
|
|
was basically to build a collaboration with our different partners
|
|
|
|
|
|
|
|
1913
|
|
|
|
01:01:08,719 --> 01:01:11,519
|
|
|
|
so it means that whenever we're sharing information we don't want it to
|
|
|
|
|
|
|
|
1915
|
|
|
|
01:01:11,519 --> 01:01:14,358
|
|
|
|
be a one-way communication, so we don't want to have
|
|
|
|
|
|
|
|
1916
|
|
|
|
01:01:13,358 --> 01:01:17,500
|
|
|
|
this whole feed, provider and consumers relationship
|
|
|
|
|
|
|
|
1919
|
|
|
|
01:01:17,500 --> 01:01:20,798
|
|
|
|
but we want everyone to be able to chip in with their ideas
|
|
|
|
|
|
|
|
1920
|
|
|
|
01:01:20,798 --> 01:01:24,559
|
|
|
|
so while anything that you produce in MISP will only be tied and editable
|
|
|
|
|
|
|
|
1921
|
|
|
|
01:01:24,559 --> 01:01:28,719
|
|
|
|
by your organization, others can make proposals or counter analysis to it.
|
|
|
|
|
|
|
|
1924
|
|
|
|
01:01:28,719 --> 01:01:32,919
|
|
|
|
So proposals are a system where you can basically flag information
|
|
|
|
|
|
|
|
1926
|
|
|
|
01:01:32,919 --> 01:01:37,0
|
|
|
|
as incorrect and provide feedback on how to improve it
|
|
|
|
|
|
|
|
1928
|
|
|
|
01:01:37,0 --> 01:01:40,0
|
|
|
|
or how you can add your own perspective to an event,
|
|
|
|
|
|
|
|
1930
|
|
|
|
01:01:40,0 --> 01:01:42,0
|
|
|
|
so if you receive an event from a third party you can say
|
|
|
|
|
|
|
|
1931
|
|
|
|
01:01:42,0 --> 01:01:44,400
|
2022-02-06 17:25:12 +01:00
|
|
|
oh I can improve it and {inaudible listen/discern} this way
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
1932
|
|
|
|
01:01:44,400 --> 01:01:46,8
|
|
|
|
please incorporate these changes in the event
|
|
|
|
|
|
|
|
1933
|
|
|
|
01:01:46,318 --> 01:01:49,500
|
|
|
|
and then the original producer can make the decision
|
|
|
|
|
|
|
|
1935
|
|
|
|
01:01:48,500 --> 01:01:51,519
|
|
|
|
whether to incorporate it or discard your changes.
|
|
|
|
|
|
|
|
1936
|
|
|
|
01:01:51,519 --> 01:01:55,358
|
|
|
|
As for counter analysis, this is what we call extend events.
|
|
|
|
|
|
|
|
1938
|
|
|
|
01:01:55,358 --> 01:01:59,358
|
|
|
|
You can basically create an event that latches onto an original
|
|
|
|
|
|
|
|
1940
|
|
|
|
01:01:59,358 --> 01:02:03,38
|
|
|
|
shared by a third party and provide your own perspective of it.
|
|
|
|
|
|
|
|
1942
|
|
|
|
01:02:03,0 --> 01:02:06,160
|
|
|
|
and then you keep full control of the data and you become the owner
|
|
|
|
|
|
|
|
1945
|
|
|
|
01:02:06,160 --> 01:02:09,440
|
|
|
|
of whatever the extension is that you produce to the original event.
|
|
|
|
|
|
|
|
1946
|
|
|
|
01:02:09,440 --> 01:02:17,280
|
|
|
|
This happens very often for us, for example when a vendor shares out a report.
|
|
|
|
|
|
|
|
1949
|
|
|
|
01:02:17,280 --> 01:02:21,0
|
|
|
|
For example, we get a report from say kaspersky and we have additional information
|
|
|
|
|
|
|
|
1951
|
|
|
|
01:02:20,0 --> 01:02:25,519
|
|
|
|
or we have a different opinion on something,
|
|
|
|
|
|
|
|
1954
|
|
|
|
01:02:25,519 --> 01:02:29,960
|
|
|
|
then we might create an extended event that we share out to our constituency
|
|
|
|
|
|
|
|
1957
|
|
|
|
01:02:28,960 --> 01:02:33,358
|
|
|
|
which if they have access to the original report will latch onto it
|
|
|
|
|
|
|
|
1958
|
|
|
|
01:02:33,358 --> 01:02:37,0
|
|
|
|
and it will show our perspective on top of the original.
|
|
|
|
|
|
|
|
1960
|
|
|
|
01:02:37,519 --> 01:02:41,440
|
|
|
|
Now as for the exchange itself, every organization is free to host their own
|
|
|
|
|
|
|
|
1962
|
|
|
|
01:02:41,440 --> 01:02:44,960
|
|
|
|
MISP instance and then they can decide who they want to interconnect with
|
|
|
|
|
|
|
|
1964
|
|
|
|
01:02:44,960 --> 01:02:48,240
|
|
|
|
if both parties agree, a synchronization link is established
|
|
|
|
|
|
|
|
1966
|
|
|
|
01:02:48,239 --> 01:02:51,838
|
|
|
|
between the two MISP instance and sharing can start flowing between them.
|
|
|
|
|
|
|
|
1968
|
|
|
|
01:02:51,838 --> 01:02:55,0
|
|
|
|
Now this sharing is still governed by those distribution lists
|
|
|
|
|
|
|
|
1970
|
|
|
|
01:02:54,500 --> 01:02:59,199
|
|
|
|
and by some other mechanism that we'll talk about more tomorrow
|
|
|
|
|
|
|
|
1972
|
|
|
|
01:02:59,199 --> 01:03:04,0
|
|
|
|
but basically MISP exchanges information between the individual nodes
|
|
|
|
|
|
|
|
1974
|
|
|
|
01:03:02,798 --> 01:03:06,880
|
|
|
|
in kind of a mesh network way.
|
|
|
|
|
|
|
|
1976
|
|
|
|
01:03:06,880 --> 01:03:10,0
|
|
|
|
We also have feed system that allows us to generate feeds
|
|
|
|
|
|
|
|
1977
|
|
|
|
01:03:10,0 --> 01:03:11,960
|
|
|
|
and to share those feeds with larger communities.
|
|
|
|
|
|
|
|
1979
|
|
|
|
01:03:11,960 --> 01:03:15,559
|
|
|
|
So we as CIRCL we provide another SIEM feed, for example
|
|
|
|
|
|
|
|
1980
|
|
|
|
01:03:15,280 --> 01:03:20,0
|
|
|
|
that we make freely available in our infrastructure
|
|
|
|
|
|
|
|
1981
|
|
|
|
01:03:20,0 --> 01:03:22,440
|
|
|
|
anyone can just point their MISP to it and adjust the data
|
|
|
|
|
|
|
|
1983
|
|
|
|
01:03:22,440 --> 01:03:26,119
|
|
|
|
and keep it updated using the feed system, this is also great
|
|
|
|
|
|
|
|
1985
|
|
|
|
01:03:26,119 --> 01:03:30,0
|
|
|
|
if you have ever have the need of sharing information between air gap systems.
|
|
|
|
|
|
|
|
1986
|
|
|
|
01:03:29,559 --> 01:03:37,0
|
|
|
|
You can just generate a feed based on certain filter rules and basically
|
|
|
|
|
|
|
|
1989
|
|
|
|
01:03:37,0 --> 01:03:43,0
|
|
|
|
share it through say a flash drive or something like that, with an internal system
|
|
|
|
|
|
|
|
1993
|
|
|
|
01:03:44,0 --> 01:03:48,720
|
|
|
|
Now all of these filtering options are basically user defined
|
|
|
|
|
|
|
|
1994
|
|
|
|
01:03:48,0 --> 01:03:50,880
|
|
|
|
and they rely heavily also on the contextualization
|
|
|
|
|
|
|
|
1997
|
|
|
|
01:03:50,880 --> 01:03:54,0
|
|
|
|
so very often what we're doing and especially
|
|
|
|
|
|
|
|
1998
|
|
|
|
01:03:53,639 --> 01:03:57,0
|
2022-02-06 17:25:12 +01:00
|
|
|
if you were ever signing up for the COVID instance that I mentioned before
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2000
|
|
|
|
01:03:57,0 --> 01:04:00,559
|
|
|
|
is you can also make those decisions based on the context,
|
|
|
|
|
|
|
|
2002
|
|
|
|
01:04:00,559 --> 01:04:02,960
|
|
|
|
what data you're interested in, what date you're interested in sharing out.
|
|
|
|
|
|
|
|
2004
|
|
|
|
01:04:02,960 --> 01:04:06,400
|
|
|
|
For example, if you connect to COVID instance, we categorize all of the
|
|
|
|
|
|
|
|
2006
|
|
|
|
01:04:06,400 --> 01:04:10,79
|
|
|
|
information into three categories, health related information
|
|
|
|
|
|
|
|
2008
|
|
|
|
01:04:9,79 --> 01:04:12,720
|
|
|
|
so basically information about the spread of the pandemic,
|
|
|
|
|
|
|
|
2010
|
|
|
|
01:04:12,719 --> 01:04:16,399
|
|
|
|
information about misinformation targeting COVID,
|
|
|
|
|
|
|
|
2012
|
|
|
|
01:04:16,400 --> 01:04:22,0
|
|
|
|
and also cyber security threats that are targeting, that are now basically
|
|
|
|
|
|
|
|
2014
|
|
|
|
01:04:21,0 --> 01:04:27,0
|
|
|
|
abusing the whole COVID situation with remote work and so on.
|
|
|
|
|
|
|
|
2016
|
|
|
|
01:04:27,0 --> 01:04:30,0
|
|
|
|
so if you're only interested in one or two of these three different topics,
|
|
|
|
|
|
|
|
2019
|
|
|
|
01:04:30,0 --> 01:04:36,0
|
|
|
|
then you can set up your filters to only ingest data coming from a subset of the data set
|
|
|
|
|
|
|
|
2021
|
|
|
|
01:04:36,0 --> 01:04:39,0
|
|
|
|
Very often what we do as well is we have these internal MISP clusters
|
|
|
|
|
|
|
|
2023
|
|
|
|
01:04:38,480 --> 01:04:44,0
|
|
|
|
in our own organization as well, where we collect information from different sources
|
|
|
|
|
|
|
|
2026
|
|
|
|
01:04:43,798 --> 01:04:48,798
|
|
|
|
so we have a dedicated MISP instance where we purely collect spam information for example
|
|
|
|
|
|
|
|
2029
|
|
|
|
01:04:48,798 --> 01:04:52,0
|
|
|
|
So for a constituency, anyone can forward their spam to us
|
|
|
|
|
|
|
|
2031
|
|
|
|
01:04:52,0 --> 01:04:55,358
|
|
|
|
and we'll just generate events out of those in that MISP.
|
|
|
|
|
|
|
|
2032
|
|
|
|
01:04:55,358 --> 01:04:56,38
|
|
|
|
Generally this information
|
|
|
|
|
|
|
|
2033
|
|
|
|
01:04:56,38 --> 01:05:00,480
|
|
|
|
is really not interesting for a day-to-day detection use, for example.
|
|
|
|
|
|
|
|
2036
|
|
|
|
01:05:00,480 --> 01:05:03,679
|
|
|
|
But what we do is we cache this information and we can cross-correlate
|
|
|
|
|
|
|
|
2038
|
|
|
|
01:05:03,679 --> 01:05:05,759
|
|
|
|
this information with our operational instance
|
|
|
|
|
|
|
|
2040
|
|
|
|
01:05:05,760 --> 01:05:11,839
|
|
|
|
that means if we start the analysis process and we start an investigation
|
|
|
|
|
|
|
|
2042
|
|
|
|
01:05:11,839 --> 01:05:14,239
|
|
|
|
then we immediately see the moment we start encoding data points
|
|
|
|
|
|
|
|
2044
|
|
|
|
01:05:14,239 --> 01:05:18,598
|
|
|
|
oh this is something that was already flagged once in our spam instance
|
|
|
|
|
|
|
|
2046
|
|
|
|
01:05:18,598 --> 01:05:210,359
|
|
|
|
this information that that instance knows about,
|
|
|
|
|
|
|
|
2048
|
|
|
|
01:05:210,359 --> 01:05:24,840
|
|
|
|
then we can pivot over to that instance and fetch the information
|
|
|
|
|
|
|
|
2049
|
|
|
|
01:05:24,840 --> 01:05:28,400
|
|
|
|
related to that same data point that we're also seeing in our current incident
|
|
|
|
|
|
|
|
2052
|
|
|
|
01:05:28,400 --> 01:05:32,0
|
|
|
|
and perhaps get more information that is relevant for us from there.
|
|
|
|
|
|
|
|
2054
|
|
|
|
01:05:32,0 --> 01:05:35,79
|
|
|
|
3932 --> 3936.079
|
|
|
|
So basically very often we have these multi MISP internal enclaves
|
|
|
|
|
|
|
|
2057
|
|
|
|
01:05:35,79 --> 01:05:42,0
|
|
|
|
that help us basically to separate different concerns and
|
|
|
|
|
|
|
|
2058
|
|
|
|
01:05:41,0 --> 01:05:44,0
|
|
|
|
different collection mechanisms into their own instances.
|
|
|
|
|
|
|
|
2060
|
|
|
|
01:05:45,440 --> 01:05:49,39
|
|
|
|
Just in that scope and I think is linked to the question that we had
|
|
|
|
|
|
|
|
2062
|
|
|
|
01:05:49,39 --> 01:05:52,799
|
|
|
|
regarding the multi MISP internal enclave
|
|
|
|
|
|
|
|
2064
|
|
|
|
01:05:52,798 --> 01:05:57,599
|
|
|
|
someone was asking about synchronizing with an existing MISP and so.
|
|
|
|
|
|
|
|
2066
|
|
|
|
01:05:57,599 --> 01:06:00,720
|
|
|
|
You have this kind of local enclave options, where you can synchronize to MISP
|
|
|
|
|
|
|
|
2068
|
|
|
|
01:06:00,719 --> 01:06:05,199
|
|
|
|
like they behave in the same organization, that's one of the interesting options.
|
|
|
|
|
|
|
|
2071
|
|
|
|
01:06:05,199 --> 01:06:09,358
|
|
|
|
By the way, I would just give the mic to Josh that will explain a bit more about
|
|
|
|
|
|
|
|
2074
|
|
|
|
01:06:09,358 --> 01:06:16,0
|
2022-02-06 17:25:12 +01:00
|
|
|
the question and answer in zoom, to have directly the ability to answer the question answering the Zoom {inaudible}
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2077
|
|
|
|
01:06:18,400 --> 01:06:20,639
|
|
|
|
I just want to jump in real quick, yeah if you have any questions
|
|
|
|
|
|
|
|
2080
|
|
|
|
01:06:20,639 --> 01:06:26,400
|
|
|
|
please direct them at the Q&A board versus the chat room
|
|
|
|
|
|
|
|
2081
|
|
|
|
01:06:26,400 --> 01:06:28,0
|
|
|
|
that way we can kind of keep a monitor of that
|
|
|
|
|
|
|
|
2082
|
|
|
|
01:06:28,0 --> 01:06:32,0
|
|
|
|
and other people can actually see the questions and the answer directly in that area
|
|
|
|
|
|
|
|
2085
|
|
|
|
01:06:32,0 --> 01:06:38,0
|
|
|
|
so if you have questions feel free to use the Q&A board and that's all
|
|
|
|
|
|
|
|
2086
|
|
|
|
01:06:38,0 --> 01:06:43,199
|
|
|
|
thank you josh that's very useful so we can keep track of them and we can answer live or
|
|
|
|
|
|
|
|
2090
|
|
|
|
01:06:43,199 --> 01:06:44,700
|
|
|
|
directly in the chat.
|
|
|
|
|
|
|
|
2091
|
|
|
|
01:06:44,700 --> 01:06:49,520
|
|
|
|
Okay great, so you see that the sharing aspect of MISP is like pretty extensive
|
|
|
|
|
|
|
|
2094
|
|
|
|
01:06:49,520 --> 01:06:53,279
|
|
|
|
and you have different models of of usage of MISP
|
|
|
|
|
|
|
|
2097
|
|
|
|
01:06:53,279 --> 01:06:58,318
|
|
|
|
some people have this pre-conception about MISP being like oh I need to share with MISP
|
|
|
|
|
|
|
|
2099
|
|
|
|
01:06:58,318 --> 01:07:01,119
|
|
|
|
no, it's depending on what you want to do with your MISP instance
|
|
|
|
|
|
|
|
2101
|
|
|
|
01:07:01,119 --> 01:07:05,500
|
|
|
|
and the core functionality of MISP is really to give, I would say the freedom
|
|
|
|
|
|
|
|
2104
|
|
|
|
01:07:05,500 --> 01:07:11,0
|
|
|
|
to each of the organizations to decide what to do with the data, if they want to share or not
|
|
|
|
|
|
|
|
2106
|
|
|
|
01:07:11,0 --> 01:07:17,359
|
|
|
|
and we always design MISP that everyone can be kind of consumers
|
|
|
|
|
|
|
|
2109
|
|
|
|
01:07:17,359 --> 01:07:21,838
|
|
|
|
so that basically getting data from different fields or producer or contributors
|
|
|
|
|
|
|
|
2110
|
|
|
|
01:07:21,838 --> 01:07:29,0
|
|
|
|
Andras mentioned a different way of contributing like sightings, making proposals, things like that
|
|
|
|
|
|
|
|
2114
|
|
|
|
01:07:29,0 --> 01:07:34,240
|
|
|
|
but it's up to the original contributors to decide if they want to share
|
|
|
|
|
|
|
|
2117
|
|
|
|
01:07:34,240 --> 01:07:41,119
|
|
|
|
that's really the thing, with MISP you can set up a MISP for like just pulling data, getting the data and that's it
|
|
|
|
|
|
|
|
2120
|
|
|
|
01:07:41,119 --> 01:07:46,480
|
|
|
|
and if at one point in time you want to like push some data you can just enable it and that's it
|
|
|
|
|
|
|
|
2123
|
|
|
|
01:07:46,480 --> 01:07:51,0
|
|
|
|
so it's really, it's just a matter of just tuning the configuration ,
|
|
|
|
|
|
|
|
2126
|
|
|
|
01:07:51,0 --> 01:07:53,0
|
|
|
|
the filtering really on the synchronization, if you want to share.
|
|
|
|
|
|
|
|
2128
|
|
|
|
01:07:53,0 --> 01:07:55,838
|
|
|
|
So you don't have to change anything in your MISP instance
|
|
|
|
|
|
|
|
2129
|
|
|
|
01:07:55,838 --> 01:07:59,0
|
|
|
|
it's just a matter of of what you decide and what you need to share
|
|
|
|
|
|
|
|
2132
|
|
|
|
01:07:59,0 --> 01:08:01,500
|
|
|
|
and then the thing that is really important in MISP
|
|
|
|
|
|
|
|
2133
|
|
|
|
01:08:01,500 --> 01:08:05,760
|
|
|
|
everything can be in flex. I mean even for example that we were mentioning
|
|
|
|
|
|
|
|
2135
|
|
|
|
01:08:05,760 --> 01:08:10,240
|
|
|
|
so those kind of envelope information might change over time
|
|
|
|
|
|
|
|
2137
|
|
|
|
01:08:10,239 --> 01:08:15,0
|
|
|
|
we have seen for example some past or incident report that has been updated like
|
|
|
|
|
|
|
|
2140
|
|
|
|
01:08:15,0 --> 01:08:19,0
|
|
|
|
two years later because they discover who was the target or the threat actor behind
|
|
|
|
|
|
|
|
2142
|
|
|
|
01:08:19,0 --> 01:08:24,0
|
|
|
|
and that's the thing that's really in MISP that we really want to be flexible
|
|
|
|
|
|
|
|
2145
|
|
|
|
01:08:24,0 --> 01:08:29,500
|
|
|
|
you can really expand the information either internally, add some comment and so on
|
|
|
|
|
|
|
|
2147
|
|
|
|
01:08:29,500 --> 01:08:35,359
|
|
|
|
and to share this information in your different MISP instances and share with partners,
|
|
|
|
|
|
|
|
2150
|
|
|
|
01:08:35,359 --> 01:08:37,200
|
|
|
|
your teams and so on so.
|
|
|
|
|
|
|
|
2151
|
|
|
|
01:08:37,200 --> 01:08:42,0
|
|
|
|
Really, MISP the core functionality of MISP is distributing information
|
|
|
|
|
|
|
|
2153
|
|
|
|
01:08:42,0 --> 01:08:46,500
|
|
|
|
but if you don't want to use it it's fine you just don't enable synchronization
|
|
|
|
|
|
|
|
2156
|
|
|
|
01:08:46,500 --> 01:08:50,0
|
|
|
|
but if you want to use partially, part of synchronization and so on
|
|
|
|
|
|
|
|
2158
|
|
|
|
01:08:50,0 --> 01:08:53,838
|
|
|
|
you just set up this kind of parameters.
|
|
|
|
|
|
|
|
2160
|
|
|
|
01:08:55,0 --> 01:09:00,0
|
|
|
|
So on top of collecting all this information
|
|
|
|
|
|
|
|
2161
|
|
|
|
01:09:00,0 --> 01:09:03,0
|
|
|
|
and synchronizing the information that we talked about before
|
|
|
|
|
|
|
|
2162
|
|
|
|
01:09:03,0 --> 01:09:06,0
|
|
|
|
we basically do a bunch of different stuff to improve
|
|
|
|
|
|
|
|
2164
|
|
|
|
01:09:06,0 --> 01:09:08,0
|
|
|
|
to handle the quality management of the information as well.
|
|
|
|
|
|
|
|
2165
|
|
|
|
01:09:08,0 --> 01:09:11,0
|
|
|
|
So one of the first things we do, this is something we mentioned a bit before
|
|
|
|
|
|
|
|
2167
|
|
|
|
01:09:11,0 --> 01:09:16,0
|
|
|
|
is we correlate information so we're interested in data that we've already seen before
|
|
|
|
|
|
|
|
2170
|
|
|
|
01:09:16,0 --> 01:09:18,559
|
|
|
|
we also have the feedback loop that we mentioned before with sightings
|
|
|
|
|
|
|
|
2172
|
|
|
|
01:09:18,560 --> 01:09:22,0
|
|
|
|
that means we really want to get timeliness to the information as well
|
|
|
|
|
|
|
|
2175
|
|
|
|
01:09:22,0 --> 01:09:27,439
|
|
|
|
so that we can but make better decisions on what we keep in our working data set for detection,
|
|
|
|
|
|
|
|
2177
|
|
|
|
01:09:27,439 --> 01:09:29,5
|
|
|
|
for blocking and so on.
|
|
|
|
|
|
|
|
2178
|
|
|
|
01:09:29,520 --> 01:09:33,679
|
|
|
|
The false positive management is a huge part so the warning list system
|
|
|
|
|
|
|
|
2180
|
|
|
|
01:09:33,679 --> 01:09:37,0
|
|
|
|
where we basically exclude those typical false positives
|
|
|
|
|
|
|
|
2182
|
|
|
|
01:09:37,0 --> 01:09:41,440
|
|
|
|
plays a very important role in the legal equation and this is also a community driven effort
|
|
|
|
|
|
|
|
2184
|
|
|
|
01:09:41,439 --> 01:09:46,0
|
|
|
|
so if you want to get involved with that and build and include your own infrastructure
|
|
|
|
|
|
|
|
2187
|
|
|
|
01:09:46,0 --> 01:09:48,399
|
|
|
|
for example in the warning list and so on,
|
|
|
|
|
|
|
|
2189
|
|
|
|
01:09:48,399 --> 01:09:53,0
|
|
|
|
either do it internally for your MISP or just share it with the open source community as well
|
|
|
|
|
|
|
|
2191
|
|
|
|
01:09:53,0 --> 01:09:56,719
|
|
|
|
so let us know if you want to have that included as well
|
|
|
|
|
|
|
|
2193
|
|
|
|
01:09:56,719 --> 01:09:58,500
|
|
|
|
we haven't talked about enrichment systems yet
|
|
|
|
|
|
|
|
2195
|
|
|
|
01:09:58,500 --> 01:10:00,880
|
|
|
|
but basically one of the things that we do in MISP is
|
|
|
|
|
|
|
|
2196
|
|
|
|
01:10:00,880 --> 01:10:05,238
|
|
|
|
we have connectors to all those different services that you might already be subscribed to
|
|
|
|
|
|
|
|
2199
|
|
|
|
01:10:05,238 --> 01:10:11,439
|
|
|
|
so if you have domain tools, passive total or what way or any of the other services
|
|
|
|
|
|
|
|
2202
|
|
|
|
01:10:11,439 --> 01:10:15,439
|
|
|
|
intel 471, and so on that you already subscribed to, then you can use
|
|
|
|
|
|
|
|
2205
|
|
|
|
01:10:15,439 --> 01:10:19,600
|
|
|
|
those services to enrich the data that you're working on
|
|
|
|
|
|
|
|
2208
|
|
|
|
01:10:19,600 --> 01:10:22,0
|
|
|
|
so if you have an incident and you're encoding information
|
|
|
|
|
|
|
|
2209
|
|
|
|
01:10:22,0 --> 01:10:24,640
|
|
|
|
you go out to all the services that you connect, that you have access to
|
|
|
|
|
|
|
|
2210
|
|
|
|
01:10:24,640 --> 01:10:29,600
|
|
|
|
4224.64 --> 4228
|
|
|
|
and fetch the information on what else those systems know about the different data points that you're encoding
|
|
|
|
|
|
|
|
2213
|
|
|
|
01:10:29,600 --> 01:10:33,679
|
|
|
|
so that you basically get a jump start on your investigation.
|
|
|
|
|
|
|
|
2215
|
|
|
|
01:10:33,679 --> 01:10:37,119
|
|
|
|
Now one of the most important things that we have to deal with and this is probably
|
|
|
|
|
|
|
|
2217
|
|
|
|
01:10:37,119 --> 01:10:42,559
|
|
|
|
i think about 50% of the code base of MISP
|
|
|
|
|
|
|
|
2219
|
|
|
|
01:10:42,560 --> 01:10:46,560
|
|
|
|
is basically the APIs and the libraries that deal with integrating MISP with other tools
|
|
|
|
|
|
|
|
2221
|
|
|
|
01:10:46,560 --> 01:10:50,580
|
|
|
|
so everything that we can do by the UI, MISP is also exposed to the api
|
|
|
|
|
|
|
|
2223
|
|
|
|
01:10:50,580 --> 01:10:54,960
|
|
|
|
and one of the most important things for us is to make sure that
|
|
|
|
|
|
|
|
2225
|
|
|
|
01:10:54,960 --> 01:11:00,0
|
|
|
|
you can use MISP as simply a backend for another tool as opposed to just directly using MISP itself.
|
|
|
|
|
|
|
|
2228
|
|
|
|
01:11:00,0 --> 01:11:04,640
|
|
|
|
As for timeliness, we haven't really touched on that yet.
|
|
|
|
|
|
|
|
2230
|
|
|
|
01:11:04,640 --> 01:11:10,480
|
|
|
|
Besides the sighting aspect, you can also encode information about time ranges when something was seen
|
|
|
|
|
|
|
|
2233
|
|
|
|
01:11:10,480 --> 01:11:19,200
|
|
|
|
and you can build a full timeline of the events that occurred during a cyber incident for example.
|
|
|
|
|
|
|
|
2237
|
|
|
|
01:11:19,200 --> 01:11:22,719
|
|
|
|
So if you encode this information together with all your data points
|
|
|
|
|
|
|
|
2239
|
|
|
|
01:11:22,719 --> 01:11:26,960
|
|
|
|
then you get an additional graph out of it that tells you when what happens
|
|
|
|
|
|
|
|
2241
|
|
|
|
01:11:26,960 --> 01:11:30,0
|
|
|
|
and time-based correlations are really important as well.
|
|
|
|
|
|
|
|
2243
|
|
|
|
01:11:30,0 --> 01:11:33,599
|
|
|
|
So very often when you're seeing two things happening at the same time
|
|
|
|
|
|
|
|
2245
|
|
|
|
01:11:33,600 --> 01:11:35,800
|
|
|
|
they might be related with each other and
|
|
|
|
|
|
|
|
2248
|
|
|
|
01:11:35,800 --> 01:11:40,960
|
|
|
|
they might be worth digging into whether there is a link between those two things that happened.
|
|
|
|
|
|
|
|
2250
|
|
|
|
01:11:40,960 --> 01:11:43,480
|
|
|
|
So something else that we will touch on more tomorrow
|
|
|
|
|
|
|
|
2251
|
|
|
|
01:11:43,480 --> 01:11:47,200
|
|
|
|
is we have a full indicator lifecycle management system in MISP.
|
|
|
|
|
|
|
|
2254
|
|
|
|
01:11:47,200 --> 01:11:50,0
|
|
|
|
That means you can define your own rules and tune your own rules
|
|
|
|
|
|
|
|
2256
|
|
|
|
01:11:50,0 --> 01:11:53,500
|
|
|
|
on how you're going to be scoring and decaying indicators
|
|
|
|
|
|
|
|
2257
|
|
|
|
01:11:53,500 --> 01:11:57,119
|
|
|
|
based on all the contextualization that you have,
|
|
|
|
|
|
|
|
2258
|
|
|
|
01:11:57,119 --> 01:11:58,719
|
|
|
|
based on the type of the data that you have,
|
|
|
|
|
|
|
|
2259
|
|
|
|
01:11:58,719 --> 01:12:02,439
|
|
|
|
based on source of the information that you have and so on and so forth.
|
|
|
|
|
|
|
|
2260
|
|
|
|
01:12:02,439 --> 01:12:09,0
|
|
|
|
So we're going to go into much more detail on that tomorrow. Alex.
|
|
|
|
|
|
|
|
2265
|
|
|
|
01:12:15,359 --> 01:12:20,359
|
|
|
|
Yeah, so I was just answering a question and then I will make it public in a minute
|
|
|
|
|
|
|
|
2267
|
|
|
|
01:12:20,359 --> 01:12:25,639
|
|
|
|
that's a question about the API and using MISP.
|
|
|
|
|
|
|
|
2270
|
|
|
|
01:12:25,639 --> 01:12:30,0
|
|
|
|
There are different ways to evaluate the quality of the information that you share in MISP.
|
|
|
|
|
|
|
|
2273
|
|
|
|
01:12:30,0 --> 01:12:35,238
|
|
|
|
One of those is obviously to look at statistics, There is a statistics version in MISP to see
|
|
|
|
|
|
|
|
2276
|
|
|
|
01:12:35,238 --> 01:12:40,238
|
|
|
|
for example, the kind of indicator shared by organization and so on.
|
|
|
|
|
|
|
|
2278
|
|
|
|
01:12:40,238 --> 01:12:43,279
|
|
|
|
In addition to that, there is for example
|
|
|
|
|
|
|
|
2279
|
|
|
|
01:12:43,279 --> 01:12:46,279
|
|
|
|
MISP dashboard which includes a kind of gamification of the platforms
|
|
|
|
|
|
|
|
2281
|
|
|
|
01:12:46,279 --> 01:12:53,600
|
|
|
|
and which is giving badges per organization depending on the kind of information that you share
|
|
|
|
|
|
|
|
2284
|
|
|
|
01:12:53,600 --> 01:12:59,520
|
|
|
|
and that's a nice way to to find out if you are reaching a certain level of capabilities when using MISP
|
|
|
|
|
|
|
|
2287
|
|
|
|
01:12:59,520 --> 01:13:02,360
|
|
|
|
where you basically have for example information like
|
|
|
|
|
|
|
|
2289
|
|
|
|
01:13:02,360 --> 01:13:08,960
|
|
|
|
are you using sightings, do you use objects and stuff like that.
|
|
|
|
|
|
|
|
2292
|
|
|
|
01:13:08,960 --> 01:13:12,0
|
|
|
|
For example, thing that you can really look at if you want to see
|
|
|
|
|
|
|
|
2293
|
|
|
|
01:13:12,0 --> 01:13:14,480
|
|
|
|
if the quality of information that you create in MISP
|
|
|
|
|
|
|
|
2296
|
|
|
|
01:13:14,480 --> 01:13:19,560
|
|
|
|
i would just following the standards what is following the best practices in the different organization
|
|
|
|
|
|
|
|
2297
|
|
|
|
01:13:19,560 --> 01:13:22,640
|
2022-02-06 17:25:12 +01:00
|
|
|
is to compare with the {inaudible} feed
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2300
|
|
|
|
01:13:22,640 --> 01:13:25,198
|
|
|
|
there are some goods even in the OSINT feed and
|
|
|
|
|
|
|
|
2301
|
|
|
|
01:13:25,198 --> 01:13:29,519
|
|
|
|
for example, things that are really a good indicator is to see
|
|
|
|
|
|
|
|
2303
|
|
|
|
01:13:29,520 --> 01:13:32,880
|
|
|
|
are you just using indicators and using objects,
|
|
|
|
|
|
|
|
2305
|
|
|
|
01:13:32,880 --> 01:13:35,0
|
|
|
|
are those objects linked together by using the relationship to it,
|
|
|
|
|
|
|
|
2306
|
|
|
|
01:13:35,0 --> 01:13:40,199
|
2022-02-06 17:25:12 +01:00
|
|
|
are you using galaxies, are those galaxies at the event level, {inaudible} level,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2308
|
|
|
|
01:13:40,198 --> 01:13:46,0
|
|
|
|
do you have tags, labels on specific objects or specific attributes and so on
|
|
|
|
|
|
|
|
2311
|
|
|
|
01:13:46,0 --> 01:13:52,960
|
2022-02-06 17:25:12 +01:00
|
|
|
that's different parameters and I think the question from {inaudible} is pretty good.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2315
|
|
|
|
01:13:52,960 --> 01:14:00,39
|
|
|
|
and if you really want to dive into the KPI aspect of MISP and quality of information.
|
|
|
|
|
|
|
|
2316
|
|
|
|
01:14:00,39 --> 01:14:03,239
|
|
|
|
In addition to what Andras just said
|
|
|
|
|
|
|
|
2320
|
|
|
|
01:14:03,239 --> 01:14:07,600
|
|
|
|
there are some other things about the quality of information shared within the community
|
|
|
|
|
|
|
|
2321
|
|
|
|
01:14:07,600 --> 01:14:11,920
|
|
|
|
and there's some good examples in the MISP dashboard about the different badges
|
|
|
|
|
|
|
|
2324
|
|
|
|
01:14:11,920 --> 01:14:16,0
|
|
|
|
there is even a model for sharing such kind of information.
|
|
|
|
|
|
|
|
2326
|
|
|
|
01:14:16,0 --> 01:14:19,0
|
2022-02-06 17:25:12 +01:00
|
|
|
So another thing that is I think quite useful and
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2329
|
|
|
|
01:14:19,0 --> 01:14:23,520
|
|
|
|
it was one of the core functionality of MISP was the correlation features.
|
|
|
|
|
|
|
|
2330
|
|
|
|
01:14:23,520 --> 01:14:29,119
|
|
|
|
This one is, it looks like obvious but it's not always obvious
|
|
|
|
|
|
|
|
2332
|
|
|
|
01:14:29,119 --> 01:14:32,800
|
|
|
|
I mean a lot of tools in the security field exist but they don't do automatic correlations.
|
|
|
|
|
|
|
|
2334
|
|
|
|
01:14:32,800 --> 01:14:35,679
|
2022-02-06 17:25:12 +01:00
|
|
|
For example, at the {inaudible} we are using ticketing system
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2337
|
|
|
|
01:14:37,119 --> 01:14:39,0
|
|
|
|
and sometimes it's very difficult to find if we have two correlating events
|
|
|
|
|
|
|
|
2338
|
|
|
|
01:14:39,0 --> 01:14:42,820
|
|
|
|
and what we decided in MISP which covers the cost.
|
|
|
|
|
|
|
|
2339
|
|
|
|
01:14:42,820 --> 01:14:48,800
|
|
|
|
I mean the correlation engine is maybe one of the costly aspects of using MISP on a database level.
|
|
|
|
|
|
|
|
2341
|
|
|
|
01:14:48,800 --> 01:14:49,919
|
|
|
|
but it's really useful.
|
|
|
|
|
|
|
|
2342
|
|
|
|
01:14:49,919 --> 01:14:52,500
|
|
|
|
For example, here we just have an example of
|
|
|
|
|
|
|
|
2343
|
|
|
|
01:14:52,500 --> 01:15:00,500
|
|
|
|
information about some malware spam that are used to share uh information about
|
|
|
|
|
|
|
|
2348
|
|
|
|
01:15:00,500 --> 01:15:04,239
|
|
|
|
target campaigns for the financial malware
|
|
|
|
|
|
|
|
2351
|
|
|
|
01:15:04,239 --> 01:15:09,819
|
|
|
|
and what we can see there is basically correlation on similar points
|
|
|
|
|
|
|
|
2352
|
|
|
|
01:15:09,819 --> 01:15:12,880
|
|
|
|
and those ones are mainly IP addresses of the infrastructure
|
|
|
|
|
|
|
|
2355
|
|
|
|
01:15:12,880 --> 01:15:16,0
|
|
|
|
but you can really spot interesting things there.
|
|
|
|
|
|
|
|
2357
|
|
|
|
01:15:16,0 --> 01:15:19,679
|
2022-02-06 17:25:12 +01:00
|
|
|
For example, you see that the third {inaudible bone/bin} in Germany share indicators,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2360
|
|
|
|
01:15:19,679 --> 01:15:24,0
|
|
|
|
you have a polish bank sharing the same kind of indicators
|
|
|
|
|
|
|
|
2361
|
|
|
|
01:15:24,0 --> 01:15:26,560
|
|
|
|
we were sharing such kind of indicators too
|
|
|
|
|
|
|
|
2362
|
|
|
|
01:15:26,560 --> 01:15:30,640
|
|
|
|
and even if they have different names or different contextualization
|
|
|
|
|
|
|
|
2365
|
|
|
|
01:15:30,640 --> 01:15:33,439
|
|
|
|
we can really spot similar infrastructure
|
|
|
|
|
|
|
|
2366
|
|
|
|
01:15:33,439 --> 01:15:39,198
|
|
|
|
so we can see okay, it's maybe the same actors using an infrastructure for different kind of things
|
|
|
|
|
|
|
|
2369
|
|
|
|
01:15:39,198 --> 01:15:45,679
|
|
|
|
or for example we can actually see here that we have different names of the similar malware
|
|
|
|
|
|
|
|
2372
|
|
|
|
01:15:45,679 --> 01:15:48,0
|
|
|
|
so really this is important for example another thing that is interesting is
|
|
|
|
|
|
|
|
2374
|
|
|
|
01:15:48,0 --> 01:15:53,739
|
|
|
|
for example if you have a sinkhole IP address setup by a antivirus company for example,
|
|
|
|
|
|
|
|
2377
|
|
|
|
01:15:53,739 --> 01:15:57,560
|
|
|
|
you can directly spot it. I mean if you have, I don't know, APT 29
|
|
|
|
|
|
|
|
2380
|
|
|
|
01:15:57,560 --> 01:16:01,840
|
|
|
|
and you have like three different criminals malware going on that one and so on
|
|
|
|
|
|
|
|
2383
|
|
|
|
01:16:01,840 --> 01:16:05,600
|
|
|
|
obviously it's usually not the same infrastructures but on the other hand
|
|
|
|
|
|
|
|
2385
|
|
|
|
01:16:05,600 --> 01:16:08,39
|
|
|
|
you can directly spot, okay this one is already take down
|
|
|
|
|
|
|
|
2386
|
|
|
|
01:16:08,39 --> 01:16:12,159
|
|
|
|
it's handled by this antivirus company and you can really handle it
|
|
|
|
|
|
|
|
2388
|
|
|
|
01:16:12,158 --> 01:16:20,679
|
|
|
|
so it's really a way to quickly find if it's a new threat or something that is already known in the infrastructure
|
|
|
|
|
|
|
|
2392
|
|
|
|
01:16:22,439 --> 01:16:28,640
|
|
|
|
So a little bit of the sightings themselves so we're going to see this more in practice
|
|
|
|
|
|
|
|
2395
|
|
|
|
01:16:28,640 --> 01:16:36,79
|
|
|
|
basically we have a very simple interfacing list that allows us to to tell the community
|
|
|
|
|
|
|
|
2398
|
|
|
|
01:16:36,79 --> 01:16:40,158
|
|
|
|
that we've seen an indicator, as well as when we've seen it
|
|
|
|
|
|
|
|
2401
|
|
|
|
01:16:40,158 --> 01:16:46,238
|
|
|
|
and perhaps also include information on what tool we've picked up, what context we've seen,
|
|
|
|
|
|
|
|
2402
|
|
|
|
01:16:46,238 --> 01:16:50,359
|
|
|
|
so sightings can have some metadata on top of just being a sighting.
|
|
|
|
|
|
|
|
2406
|
|
|
|
01:16:50,359 --> 01:16:54,79
|
|
|
|
We can also flag something that we call negative sightings which is a false positive sighting
|
|
|
|
|
|
|
|
2409
|
|
|
|
01:16:54,79 --> 01:16:59,0
|
|
|
|
where we indicate that we've seen it but it produced issues for us so it was a false positive.
|
|
|
|
|
|
|
|
2412
|
|
|
|
01:16:59,0 --> 01:17:05,520
|
|
|
|
We can also indicate that something is potentially going to be expired at a certain date,
|
|
|
|
|
|
|
|
2415
|
|
|
|
01:17:05,520 --> 01:17:10,0
|
|
|
|
so this is interesting, for example, if we're in talks with a provider
|
|
|
|
|
|
|
|
2418
|
|
|
|
01:17:10,0 --> 01:17:11,519
|
|
|
|
and we know that there is going to be a takedown
|
|
|
|
|
|
|
|
2420
|
|
|
|
01:17:11,519 --> 01:17:17,0
|
|
|
|
then we can already indicate that okay, this is no longer an indicator after a certain point in time.
|
|
|
|
|
|
|
|
2422
|
|
|
|
01:17:17,0 --> 01:17:21,679
|
|
|
|
Apart from that if you are ever dealing with bulk sightings,
|
|
|
|
|
|
|
|
2424
|
|
|
|
01:17:21,679 --> 01:17:28,0
|
|
|
|
so if you want to for example just capture any IP address seen in your network or something like that
|
|
|
|
|
|
|
|
2427
|
|
|
|
01:17:28,0 --> 01:17:34,560
|
|
|
|
there is another tool called SightingDB, which is developed by Devo, it's also an open source tool.
|
|
|
|
|
|
|
|
2430
|
|
|
|
01:17:34,560 --> 01:17:38,79
|
|
|
|
It's really recommended to use that, it allows you to to capture massive massive amounts of data
|
|
|
|
|
|
|
|
2432
|
|
|
|
01:17:38,79 --> 01:17:45,539
|
|
|
|
so if you're capturing the entire network flow of your constituency and or your organization
|
|
|
|
|
|
|
|
2436
|
|
|
|
01:17:45,539 --> 01:17:49,920
|
|
|
|
and just dumping all the data somewhere this is a great place to do it
|
|
|
|
|
|
|
|
2439
|
|
|
|
01:17:49,920 --> 01:17:53,760
|
|
|
|
and it's a very fast lookup database that is integrated with MISP
|
|
|
|
|
|
|
|
2441
|
|
|
|
01:17:53,760 --> 01:17:58,500
|
|
|
|
where MISP can automatically just query it for any of the indicators that you're seeing in MISP,
|
|
|
|
|
|
|
|
2445
|
|
|
|
01:17:58,500 --> 01:18:05,359
|
|
|
|
and whether it was seen in your network, and in which time range it was seen in.
|
|
|
|
|
|
|
|
2446
|
|
|
|
01:18:03,0 --> 01:18:07,500
|
|
|
|
interesting thing with that is it's also for historical values
|
|
|
|
|
|
|
|
2448
|
|
|
|
01:18:07,500 --> 01:18:14,238
|
|
|
|
so if you're just doing bulk collection of all the observables in your network
|
|
|
|
|
|
|
|
2451
|
|
|
|
01:18:14,238 --> 01:18:26,500
|
|
|
|
and then even half a year later if it turns out that a indicator is being shared with you
|
|
|
|
|
|
|
|
2454
|
|
|
|
01:18:26,500 --> 01:18:27,0
|
|
|
|
that correlates with an observable that SightingDB from half a year ago
|
|
|
|
|
|
|
|
2456
|
|
|
|
01:18:27,0 --> 01:18:30,0
|
|
|
|
then you know that you might need to launch an investigation into something
|
|
|
|
|
|
|
|
2459
|
|
|
|
01:18:30,0 --> 01:18:34,0
|
|
|
|
that happened half a year ago in logs and so on based on the historic look up.
|
|
|
|
|
|
|
|
2460
|
|
|
|
01:18:38,0 --> 01:18:41,0
|
|
|
|
Alex
|
|
|
|
|
|
|
|
2462
|
|
|
|
01:18:41,0 --> 01:18:44,500
|
|
|
|
Just complementary notes regarding sightings and
|
|
|
|
|
|
|
|
2464
|
|
|
|
01:18:44,500 --> 01:18:49,439
|
|
|
|
that's something that is basically maybe the easiest way of sharing additional information
|
|
|
|
|
|
|
|
2467
|
|
|
|
01:18:49,439 --> 01:18:53,839
|
|
|
|
it costs nothing and if you are connected to a MISP instance
|
|
|
|
|
|
|
|
2468
|
|
|
|
01:18:53,839 --> 01:18:56,319
|
|
|
|
and you can tell someone else that you have seen it
|
|
|
|
|
|
|
|
2469
|
|
|
|
01:18:56,319 --> 01:18:59,900
|
|
|
|
it's really a quick thing that can be useful for many organizations.
|
|
|
|
|
|
|
|
2473
|
|
|
|
01:18:59,900 --> 01:19:04,500
|
|
|
|
So the sighting itself sounds like a very small feature
|
|
|
|
|
|
|
|
2474
|
|
|
|
01:19:04,500 --> 01:19:10,399
|
|
|
|
but at the end, it's a an easy one for contributing and helping the others to know
|
|
|
|
|
|
|
|
2478
|
|
|
|
01:19:10,399 --> 01:19:15,0
|
|
|
|
if an indicator is still valuable and so on, so sighting is really something that
|
|
|
|
|
|
|
|
2481
|
|
|
|
01:19:15,0 --> 01:19:22,920
|
|
|
|
can basically be a kind of of entry-level things to do when sharing information
|
|
|
|
|
|
|
|
2484
|
|
|
|
01:19:22,920 --> 01:19:28,500
|
|
|
|
Something else that we have in MISP, this one is I think becoming more and more important
|
|
|
|
|
|
|
|
2487
|
|
|
|
01:19:28,500 --> 01:19:32,239
|
|
|
|
and we will do a quick demo later regarding that.
|
|
|
|
|
|
|
|
2489
|
|
|
|
01:19:32,238 --> 01:19:37,0
|
2022-02-06 17:25:12 +01:00
|
|
|
It's a timeline, I mean when we do analysis and so on,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2490
|
|
|
|
01:19:37,0 --> 01:19:40,0
|
2022-02-06 17:25:12 +01:00
|
|
|
it's really I would say common to have a first seen, last seen
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2492
|
|
|
|
01:19:40,0 --> 01:19:42,159
|
|
|
|
to see the evolution of things over time.
|
|
|
|
|
|
|
|
2494
|
|
|
|
01:19:42,159 --> 01:19:45,198
|
|
|
|
In the example that you see on the screen there
|
|
|
|
|
|
|
|
2496
|
|
|
|
01:19:45,198 --> 01:19:47,319
|
|
|
|
It's based on specific threat actors
|
|
|
|
|
|
|
|
2497
|
|
|
|
01:19:47,319 --> 01:19:54,839
|
|
|
|
that sends a significant numbers of spear phishing
|
|
|
|
|
|
|
|
2499
|
|
|
|
01:19:54,839 --> 01:20:00,0
|
|
|
|
and those spear phishing are very well known when we collect those timestamps and so on.
|
|
|
|
|
|
|
|
2503
|
|
|
|
01:20:00,0 --> 01:20:03,0
|
|
|
|
So you can really see and trace the evolution of a specific group and so on.
|
|
|
|
|
|
|
|
2506
|
|
|
|
01:20:03,0 --> 01:20:07,500
|
|
|
|
This can be done automatically, for example passive dns records
|
|
|
|
|
|
|
|
2507
|
|
|
|
01:20:07,500 --> 01:20:13,0
|
|
|
|
I have very often the first seen, last seen and automatically you can really build
|
|
|
|
|
|
|
|
2510
|
|
|
|
01:20:13,0 --> 01:20:18,0
|
|
|
|
and create this kind of timeline because it can be really cumbersome if you have to do it manually
|
|
|
|
|
|
|
|
2514
|
|
|
|
01:20:18,0 --> 01:20:22,239
|
|
|
|
So we have a nice view like that so that means every time you set a first seen, last seen
|
|
|
|
|
|
|
|
2516
|
|
|
|
01:20:22,239 --> 01:20:26,0
|
|
|
|
on any attribute, object, and so on; it automatically populate on the timeline
|
|
|
|
|
|
|
|
2518
|
|
|
|
01:20:26,0 --> 01:20:31,7
|
|
|
|
and it's an easy way to to see evolution, trend and so on for your analysis
|
|
|
|
|
|
|
|
2521
|
|
|
|
01:20:31,700 --> 01:20:39,280
|
|
|
|
and this is a completely interactive so you can navigate over that.
|
|
|
|
|
|
|
|
2522
|
|
|
|
01:20:39,280 --> 01:20:42,0
|
|
|
|
We will show that later.
|
|
|
|
|
|
|
|
2524
|
|
|
|
01:20:43,0 --> 01:20:47,39
|
|
|
|
So for life cycle management, again this is something that we show briefly but
|
|
|
|
|
|
|
|
2527
|
|
|
|
01:20:47,39 --> 01:20:49,480
|
|
|
|
we're going to way more depth about that tomorrow
|
|
|
|
|
|
|
|
2528
|
|
|
|
01:20:49,480 --> 01:20:53,519
|
|
|
|
is basically here we see some examples of some attributes
|
|
|
|
|
|
|
|
2531
|
|
|
|
01:20:53,519 --> 01:20:58,800
|
|
|
|
that have scores applied to them coming from different scoring models.
|
|
|
|
|
|
|
|
2532
|
|
|
|
01:20:58,800 --> 01:21:03,0
|
|
|
|
So we see there an IDS simple decaying model and then a custom model
|
|
|
|
|
|
|
|
2533
|
|
|
|
01:21:03,0 --> 01:21:08,800
|
|
|
|
titled "Model 5" that are basically running on each of those indicators
|
|
|
|
|
|
|
|
2535
|
|
|
|
01:21:08,800 --> 01:21:13,500
|
|
|
|
and they generate a score taking into account for things such as labels that are attached to them,
|
|
|
|
|
|
|
|
2536
|
|
|
|
01:21:13,500 --> 01:21:17,0
|
|
|
|
the timestamp on when the attribute was created
|
|
|
|
|
|
|
|
2537
|
|
|
|
01:21:17,0 --> 01:21:21,0
|
|
|
|
as well as the timestamp of the different sightings that came in so generally
|
|
|
|
|
|
|
|
2544
|
|
|
|
01:21:21,0 --> 01:21:24,0
|
|
|
|
if something is still being actively seen in your network
|
|
|
|
|
|
|
|
2545
|
|
|
|
01:21:24,0 --> 01:21:28,0
|
|
|
|
that is still relevant despite the indicator itself being perhaps older
|
|
|
|
|
|
|
|
2546
|
|
|
|
01:21:28,0 --> 01:21:33,520
|
|
|
|
and then using the score that gets generated from these different models that you define
|
|
|
|
|
|
|
|
2551
|
|
|
|
01:21:33,520 --> 01:21:37,500
|
|
|
|
you can basically then make those decisions when you're exporting data to only include
|
|
|
|
|
|
|
|
2554
|
|
|
|
01:21:37,500 --> 01:21:43,0
|
|
|
|
data above a certain threshold when you're feeding your SIEM for example.
|
|
|
|
|
|
|
|
2556
|
|
|
|
01:21:44,79 --> 01:21:48,500
|
|
|
|
Yeah, and this one is quite interesting because you can really define
|
|
|
|
|
|
|
|
2557
|
|
|
|
01:21:48,500 --> 01:21:52,159
|
|
|
|
so the thing that is really important with the decaying of indicators
|
|
|
|
|
|
|
|
2559
|
|
|
|
01:21:52,159 --> 01:21:58,920
|
|
|
|
you are not modifying that actually you are really just updating and overlapping
|
|
|
|
|
|
|
|
2564
|
|
|
|
01:21:58,920 --> 01:22:01,759
|
|
|
|
and you can just define those kind of models so that means for example
|
|
|
|
|
|
|
|
2566
|
|
|
|
01:22:01,759 --> 01:22:05,39
|
|
|
|
even within a team where you don't agree on a specific model, you can have both models.
|
|
|
|
|
|
|
|
2569
|
|
|
|
01:22:05,39 --> 01:22:09,679
|
|
|
|
It's very common, for example, to have models for intrusion detection systems
|
|
|
|
|
|
|
|
2571
|
|
|
|
01:22:09,679 --> 01:22:16,719
|
2022-02-06 17:25:12 +01:00
|
|
|
and specific models for I don't know, endpoint, {inaudible} or endpoint protection device
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2574
|
|
|
|
01:22:16,719 --> 01:22:20,639
|
|
|
|
and in MISP you have even a models or kind of simulator
|
|
|
|
|
|
|
|
2575
|
|
|
|
01:22:20,639 --> 01:22:25,500
|
|
|
|
where you can simulate the different model that you want to apply
|
|
|
|
|
|
|
|
2578
|
|
|
|
01:22:25,500 --> 01:22:28,920
|
|
|
|
and to see what kind of lifetime you want to apply,
|
|
|
|
|
|
|
|
2579
|
|
|
|
01:22:28,920 --> 01:22:32,0
|
|
|
|
when it decay, when for example you have a specific threshold where
|
|
|
|
|
|
|
|
2582
|
|
|
|
01:22:32,0 --> 01:22:39,500
|
|
|
|
basically say okay you don't use anymore those kind of data and you can do the mapping with
|
|
|
|
|
|
|
|
2583
|
|
|
|
01:22:39,500 --> 01:22:45,500
|
|
|
|
specific taxonomies you can with the different types, attributes, and so on
|
|
|
|
|
|
|
|
2585
|
|
|
|
01:22:45,500 --> 01:22:49,0
|
|
|
|
directly in MISP and it is really a quick win.
|
|
|
|
|
|
|
|
2588
|
|
|
|
01:22:49,0 --> 01:22:53,500
|
|
|
|
So you are not bound, for example, we know that some TIPs for example
|
|
|
|
|
|
|
|
2591
|
|
|
|
01:22:53,500 --> 01:22:58,479
|
|
|
|
have a kind of system-wide decaying models in MISP it is not like that,
|
|
|
|
|
|
|
|
2593
|
|
|
|
01:22:56,880 --> 01:23:02,679
|
|
|
|
everyone has their models, we are sharing some models
|
|
|
|
|
|
|
|
2594
|
|
|
|
01:23:02,679 --> 01:23:06,0
|
|
|
|
and you can define what you want to use without really altering the data.
|
|
|
|
|
|
|
|
2598
|
|
|
|
01:23:06,0 --> 01:23:10,238
|
|
|
|
So that means this kind of of information there is just an overlay
|
|
|
|
|
|
|
|
2599
|
|
|
|
01:23:10,238 --> 01:23:15,0
|
|
|
|
and you actually keep your own data in the systems without having any modification.
|
|
|
|
|
|
|
|
2601
|
|
|
|
01:23:17,0 --> 01:23:24,0
|
|
|
|
And you can simulate that one.
|
|
|
|
|
|
|
|
2605
|
|
|
|
01:23:27,0 --> 01:23:31,0
|
|
|
|
So when it comes to starting out, one of the trickiest things obviously is
|
|
|
|
|
|
|
|
2606
|
|
|
|
01:23:31,0 --> 01:23:34,0
|
|
|
|
when you're starting out with MISP is if you're staring as an empty instance
|
|
|
|
|
|
|
|
2607
|
|
|
|
01:23:34,0 --> 01:23:37,198
|
|
|
|
then getting started and encoding information is really tough
|
|
|
|
|
|
|
|
2610
|
|
|
|
01:23:37,198 --> 01:23:40,0
|
|
|
|
because you don't know what is really expected from the communities out there, you don't know how.
|
|
|
|
|
|
|
|
2612
|
|
|
|
01:23:40,0 --> 01:23:44,0
|
|
|
|
It's a new tool, you don't really know how to get started.
|
|
|
|
|
|
|
|
2616
|
|
|
|
01:23:44,0 --> 01:23:50,239
|
|
|
|
So in order to ease this a little bit there are a bunch of different feeds some of those that we also provide ourselves
|
|
|
|
|
|
|
|
2619
|
|
|
|
01:23:50,239 --> 01:23:54,500
|
|
|
|
which is obviously operational information something that you can use directly
|
|
|
|
|
|
|
|
2622
|
|
|
|
01:23:54,500 --> 01:24:00,799
|
|
|
|
so these are OSINT feeds that we produce as well from our TLP white data set
|
|
|
|
|
|
|
|
2623
|
|
|
|
01:24:00,799 --> 01:24:04,0
|
|
|
|
and the idea is that this will really help with bootstrapping your processes.
|
|
|
|
|
|
|
|
2625
|
|
|
|
01:24:04,0 --> 01:24:08,0
|
|
|
|
Look at the data we consider that generally well-formed
|
|
|
|
|
|
|
|
2629
|
|
|
|
01:24:08,0 --> 01:24:12,500
|
|
|
|
and well contextualized. It should give you an idea of what data generally looks like in MISP.
|
|
|
|
|
|
|
|
2631
|
|
|
|
01:24:12,500 --> 01:24:15,500
|
|
|
|
So don't start out with a fresh instance,
|
|
|
|
|
|
|
|
2632
|
|
|
|
01:24:15,500 --> 01:24:18,0
|
|
|
|
just go to your feed menu in your MISP when you're installing it
|
|
|
|
|
|
|
|
2633
|
|
|
|
01:24:18,0 --> 01:24:22,500
|
|
|
|
and pull in some of these OSINT feeds so that you see the information already.
|
|
|
|
|
|
|
|
2636
|
|
|
|
01:24:23,500 --> 01:24:27,359
|
|
|
|
Also it's a great way to test your internal tooling
|
|
|
|
|
|
|
|
2637
|
|
|
|
01:24:27,359 --> 01:24:31,119
|
|
|
|
so if you want to test the APIs, if you want to test internal synchronization,
|
|
|
|
|
|
|
|
2640
|
|
|
|
01:24:31,119 --> 01:24:33,500
|
|
|
|
it's good to have larger data set already from the get go
|
|
|
|
|
|
|
|
2641
|
|
|
|
01:24:33,500 --> 01:24:38,679
|
|
|
|
so that you already see that the movement of the data is working as expected.
|
|
|
|
|
|
|
|
2645
|
|
|
|
01:24:38,679 --> 01:24:44,500
|
|
|
|
Yeah, the other thing that you can do and where we're going to talk about that quite a bit tomorrow
|
|
|
|
|
|
|
|
2648
|
|
|
|
01:24:44,500 --> 01:24:50,500
|
|
|
|
is basically figuring out which feeds are worth ingesting,
|
|
|
|
|
|
|
|
2650
|
|
|
|
01:24:50,500 --> 01:24:55,719
|
|
|
|
how the feeds compare to each other, running overlap analysis between them and so on
|
|
|
|
|
|
|
|
2653
|
|
|
|
01:24:55,719 --> 01:25:00,0
|
|
|
|
So this is something that this is quite a heavy topic for tomorrow.
|
|
|
|
|
|
|
|
2656
|
|
|
|
01:25:05,0 --> 01:25:08,0
|
|
|
|
You're muted alex.
|
|
|
|
|
|
|
|
2657
|
|
|
|
01:25:08,0 --> 01:25:09,500
|
2022-02-06 17:25:12 +01:00
|
|
|
Yeah just discover {inaudible this/MISP}.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2658
|
|
|
|
01:25:09,500 --> 01:25:12,0
|
|
|
|
So as you can see for MISP,
|
|
|
|
|
|
|
|
2659
|
|
|
|
01:25:12,0 --> 01:25:15,300
|
|
|
|
it's the development of MISP already done over the years,
|
|
|
|
|
|
|
|
2661
|
|
|
|
01:25:15,300 --> 01:25:19,760
|
|
|
|
based on the feedback of users and that's really one of the key elements for us.
|
|
|
|
|
|
|
|
2663
|
|
|
|
01:25:19,760 --> 01:25:22,0
|
|
|
|
We wanted a tool for us that works
|
|
|
|
|
|
|
|
2665
|
|
|
|
01:25:22,0 --> 01:25:28,879
|
|
|
|
and it's key and based on that we wanted something that works for others too
|
|
|
|
|
|
|
|
2667
|
|
|
|
01:25:28,880 --> 01:25:33,679
|
2022-02-06 17:25:12 +01:00
|
|
|
and I mean the tool is evolving over time so you see that we have plenty of functionalities
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2670
|
|
|
|
01:25:33,679 --> 01:25:37,79
|
|
|
|
On those two days of workshop we'll try to cover a part of it,
|
|
|
|
|
|
|
|
2672
|
|
|
|
01:25:37,79 --> 01:25:41,679
|
|
|
|
we had already some good questions regarding how to customize this and so on.
|
|
|
|
|
|
|
|
2675
|
|
|
|
01:25:41,679 --> 01:25:45,119
|
|
|
|
We might give you some hints how to do it and and so on,
|
|
|
|
|
|
|
|
2677
|
|
|
|
01:25:45,119 --> 01:25:47,0
|
|
|
|
so we won't be able to cover everything in those two days
|
|
|
|
|
|
|
|
2678
|
|
|
|
01:25:47,0 --> 01:25:54,0
|
|
|
|
but you'll see that you can really update MISP based on your specific use cases and so on.
|
|
|
|
|
|
|
|
2679
|
|
|
|
01:25:54,0 --> 01:26:00,500
|
|
|
|
So MISP is there as a tool, what really usually matters and are the successful,
|
|
|
|
|
|
|
|
2680
|
|
|
|
01:26:00,500--> 01:26:07,0
|
|
|
|
I would say, sharing communities depends on the practices or you do that and so on
|
|
|
|
|
|
|
|
2687
|
|
|
|
01:26:07,0 --> 01:26:11,0
|
|
|
|
and we really want at least at the end, even if it's a complex tool and so on
|
|
|
|
|
|
|
|
2690
|
|
|
|
01:26:11,0 --> 01:26:15,520
|
|
|
|
to be as easy as possible for covering different use case
|
|
|
|
|
|
|
|
2691
|
|
|
|
01:26:15,520 --> 01:26:17,500
|
|
|
|
and that's really the thing that we want to do,
|
|
|
|
|
|
|
|
2693
|
|
|
|
01:26:17,500 --> 01:26:19,520
|
|
|
|
is for example for a lot of things that we have in MISP
|
|
|
|
|
|
|
|
2694
|
|
|
|
01:26:19,520 --> 01:26:23,700
|
|
|
|
and someone just asked the questions about how can you customize MISP
|
|
|
|
|
|
|
|
2697
|
|
|
|
01:26:23,700 --> 01:26:27,119
|
|
|
|
a lot of things in MISP can be customized by just modifying some JSON files.
|
|
|
|
|
|
|
|
2700
|
|
|
|
01:26:27,119 --> 01:26:32,519
|
|
|
|
It's the case for MISP objects so if you want to create a new object you just update the json files,
|
|
|
|
|
|
|
|
2701
|
|
|
|
01:26:32,519 --> 01:26:39,500
|
|
|
|
if you want to, for example, create a new taxonomies or create a new galaxy
|
|
|
|
|
|
|
|
2706
|
|
|
|
01:26:39,50 --> 01:26:41,839
|
|
|
|
you just create those kind of json files.
|
|
|
|
|
|
|
|
2708
|
|
|
|
01:26:41,839 --> 01:26:45,500
|
|
|
|
You have other ways to update and change the behavior of MISP.
|
|
|
|
|
|
|
|
2709
|
|
|
|
01:26:45,500 --> 01:26:48,158
|
|
|
|
it's based for example on MISP modules
|
|
|
|
|
|
|
|
2710
|
|
|
|
01:26:48,158 --> 01:26:51,439
|
|
|
|
so if you want to change the behavior of the expansion and so on
|
|
|
|
|
|
|
|
2712
|
|
|
|
01:26:51,439 --> 01:26:58,800
|
|
|
|
you can just play with MISP modules and we will quickly show you some examples on these modules
|
|
|
|
|
|
|
|
2716
|
|
|
|
01:26:58,800 --> 01:27:02,80
|
2022-02-06 17:25:12 +01:00
|
|
|
but that's really simple I mean there's no {inaudible}
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2719
|
|
|
|
01:27:02,80 --> 01:27:10,239
|
|
|
|
and that's the thing that you have to understand with MISP project is not just a small open source software somewhere
|
|
|
|
|
|
|
|
2720
|
|
|
|
01:27:10,239 --> 01:27:16,800
|
|
|
|
it's really a set of combination of tool, software, packages, open standards,
|
|
|
|
|
|
|
|
2721
|
|
|
|
01:27:16,800 --> 01:27:23,799
|
|
|
|
various best practices, shared knowledge base and obviously the community is using it.
|
|
|
|
|
|
|
|
2728
|
|
|
|
01:27:23,799 --> 01:27:26,500
|
|
|
|
So that's really the thing that we will have we love with FIRST for example.
|
|
|
|
|
|
|
|
2731
|
|
|
|
01:27:26,500 --> 01:27:31,0
|
|
|
|
it is to have this kind of community, learning together, sharing information,
|
|
|
|
|
|
|
|
2732
|
|
|
|
01:27:31,0 --> 01:27:33,119
|
|
|
|
and so that's that's really a key for us.
|
|
|
|
|
|
|
|
2735
|
|
|
|
01:27:33,119 --> 01:27:41,500
|
|
|
|
We have, I think more than 500 contributors on the MISP project with even more nowadays.
|
|
|
|
|
|
|
|
2738
|
|
|
|
01:27:41,500 --> 01:27:45,500
|
2022-02-06 17:25:12 +01:00
|
|
|
So if you want to become one of the contributors it's really straightforward I mean
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2739
|
|
|
|
01:27:45,500 --> 01:27:48,800
|
|
|
|
if you have something, a problem that you want to solve,
|
|
|
|
|
|
|
|
2742
|
|
|
|
01:27:48,800 --> 01:27:51,400
|
|
|
|
for example on an object, you just do a pull request and
|
|
|
|
|
|
|
|
2743
|
|
|
|
01:27:51,400 --> 01:27:55,840
|
|
|
|
it will be in MISP immediately and you become a contributor in the project
|
|
|
|
|
|
|
|
2747
|
|
|
|
01:27:57,679 --> 01:27:58,0
|
|
|
|
so really for us, it's really key in MISP
|
|
|
|
|
|
|
|
2748
|
|
|
|
01:27:58,0 --> 01:28:02,0
|
|
|
|
is to have a kind of tool that is supporting the different use cases
|
|
|
|
|
|
|
|
2749
|
|
|
|
01:28:02,0 --> 01:28:06,238
|
2022-02-06 17:25:12 +01:00
|
|
|
Okay so before that, we do a break I will share you with you
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2750
|
|
|
|
01:28:06,238 --> 01:28:12,759
|
|
|
|
some practical details on accessing the MISP training instance because there were some questions regarding that
|
|
|
|
|
|
|
|
2755
|
|
|
|
01:28:12,759 --> 01:28:20,0
|
|
|
|
and after the break, we will do the hands-on practical session
|
|
|
|
|
|
|
|
2756
|
|
|
|
01:28:20,0 --> 01:28:25,359
|
|
|
|
with an example, so we will with a real example, so you will create the full event
|
|
|
|
|
|
|
|
2757
|
|
|
|
01:28:25,359 --> 01:28:27,359
|
|
|
|
based on some information that you receive.
|
|
|
|
|
|
|
|
2759
|
|
|
|
01:28:27,359 --> 01:28:36,500
|
|
|
|
So first of all, I will give you some details about how to access the MISP instance.
|
|
|
|
|
|
|
|
|
|
|
|
2763
|
|
|
|
01:28:36,500 --> 01:28:42,500
|
2022-02-06 17:25:12 +01:00
|
|
|
S0, first of all we have a {inaudible acting/active} page
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2764
|
|
|
|
01:28:42,500 --> 01:28:48,500
|
2022-02-06 17:25:12 +01:00
|
|
|
which I obviously share at some point in time and I will share it again.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2766
|
|
|
|
01:28:48,500 --> 01:28:54,799
|
|
|
|
Yes. So there's a page with some pages that you can even edit.
|
|
|
|
|
|
|
|
2769
|
|
|
|
01:28:54,799 --> 01:29:00,0
|
|
|
|
I will paste the link again in the chat for everyone.
|
|
|
|
|
|
|
|
2772
|
|
|
|
01:29:05,639 --> 01:29:11,319
|
|
|
|
That's the link, so we have a 50 account on the training instance.
|
|
|
|
|
|
|
|
2773
|
|
|
|
01:29:11,319 --> 01:29:14,159
|
|
|
|
Pick randomly one
|
|
|
|
|
|
|
|
2775
|
|
|
|
01:29:14,158 --> 01:29:18,0
|
|
|
|
it doesn't matter if you are multiple one using the same account but be careful
|
|
|
|
|
|
|
|
2777
|
|
|
|
01:29:18,0 --> 01:29:22,119
|
|
|
|
don't change the password because maybe some people will complain,
|
|
|
|
|
|
|
|
2780
|
|
|
|
01:29:22,119 --> 01:29:30,800
|
|
|
|
and then we have a "TrainingFIRST2021" password so super simple
|
|
|
|
|
|
|
|
2782
|
|
|
|
01:29:30,800 --> 01:29:33,600
|
|
|
|
not so secure but that's fine it's a training instance.
|
|
|
|
|
|
|
|
2785
|
|
|
|
01:29:33,600 --> 01:29:41,0
|
|
|
|
Just for the reference, for the one that doesn't want to use the training instance
|
|
|
|
|
|
|
|
2786
|
|
|
|
01:29:41,0 --> 01:29:44,0
|
|
|
|
sometimes for whatever reason you want to use your own instance.
|
|
|
|
|
|
|
|
2788
|
|
|
|
01:29:44,0 --> 01:29:50,238
|
|
|
|
We have different images, virtual box and VMware images for MISP.
|
|
|
|
|
|
|
|
2791
|
|
|
|
01:29:50,238 --> 01:29:54,158
|
|
|
|
So if you want to play with MISP locally and so on.
|
|
|
|
|
|
|
|
2793
|
|
|
|
01:29:54,158 --> 01:29:57,279
|
|
|
|
If you want to play with synchronization too, you can even connect those two
|
|
|
|
|
|
|
|
2794
|
|
|
|
01:29:59,500 --> 01:30:05,280
|
|
|
|
So and during the sessions we will connect to that instance so the instant is "iglocska.eu"
|
|
|
|
|
|
|
|
2796
|
|
|
|
01:30:05,280 --> 01:30:14,0
|
|
|
|
and when you connect, you will get access to the instance.
|
|
|
|
|
|
|
|
2799
|
|
|
|
01:30:14,0 --> 01:30:18,158
|
|
|
|
So you enter your training password so I will enter with my specific account
|
|
|
|
|
|
|
|
2802
|
|
|
|
01:30:18,158 --> 01:30:23,500
|
|
|
|
and we will use that instance for the hands-on that we will do just after the break.
|
|
|
|
|
|
|
|
2804
|
|
|
|
01:30:23,500 --> 01:30:31,0
|
2022-02-06 17:25:12 +01:00
|
|
|
So what I propose now is to do a 15 minute break and we start at 45, if it's fine for everyone
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2808
|
|
|
|
01:30:31,0 --> 01:30:39,600
|
|
|
|
and we will start by with the practical sessions with a specific email
|
|
|
|
|
|
|
|
2811
|
|
|
|
01:30:39,600 --> 01:30:43,600
|
2022-02-06 17:25:12 +01:00
|
|
|
that we will share in the {inaudible} as a practical example
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2813
|
|
|
|
01:30:43,600 --> 01:30:51,300
|
|
|
|
so thank you for the one that join us now and we will start again at 45
|
|
|
|
|
|
|
|
2814
|
|
|
|
01:30:51,300 --> 01:30:54,500
|
|
|
|
to do the hands-on session. Thank you very much.
|
|
|
|
|
|
|
|
2817
|
|
|
|
01:30:55,500 --> 01:30:57,500
|
|
|
|
Thank you.
|
|
|
|
|
|
|
|
2819
|
2022-02-06 17:25:12 +01:00
|
|
|
01:44:10,399 --> 01:44:14,0
|
|
|
|
Okay and shall we get started.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2820
|
2022-02-06 17:25:12 +01:00
|
|
|
01:44:15,0 --> 01:44:18,559
|
|
|
|
Sure, welcome back everyone.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2821
|
2022-02-06 17:25:12 +01:00
|
|
|
01:44:19,0 --> 01:44:25,399
|
|
|
|
Okay so now what we're going to be doing is we're going to look a little bit at MISP itself
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2824
|
2022-02-06 17:25:12 +01:00
|
|
|
01:44:25,399 --> 01:44:28,500
|
|
|
|
so we've talked plenty about it but we haven't actually done anything with it yet.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2825
|
2022-02-06 17:25:12 +01:00
|
|
|
01:44:28,500 --> 01:44:34,560
|
|
|
|
So I really encourage everyone that has a MISP instance to also play along and to create your own events.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2827
|
2022-02-06 17:25:12 +01:00
|
|
|
01:44:34,560 --> 01:44:39,199
|
|
|
|
What we're going to be doing is we're going to go through a set of fictional little exercise.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2830
|
2022-02-06 17:25:12 +01:00
|
|
|
01:44:39,199 --> 01:44:46,560
|
|
|
|
Assume that you receive an email from, in this case, luxembourg {inaudible} telecom
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2836
|
2022-02-06 17:25:12 +01:00
|
|
|
01:44:46,560 --> 01:44:51,80
|
|
|
|
the CSIRT of them describing an incident, of a very simplistic incident,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2838
|
2022-02-06 17:25:12 +01:00
|
|
|
01:44:51,80 --> 01:44:56,479
|
|
|
|
of what happened and what we're going to be trying to do now is to model this in MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2840
|
2022-02-06 17:25:12 +01:00
|
|
|
01:44:56,479 --> 01:45:01,839
|
|
|
|
and to explain how you can further improve it and contextualize this information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2843
|
2022-02-06 17:25:12 +01:00
|
|
|
01:45:01,839 --> 01:45:07,0
|
|
|
|
So before we start, once you're logged into the MISP instance,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2845
|
2022-02-06 17:25:12 +01:00
|
|
|
01:45:07,0 --> 01:45:11,0
|
|
|
|
such as the hosted training instance. This is what you're going to be seeing.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2848
|
2022-02-06 17:25:12 +01:00
|
|
|
01:45:11,0 --> 01:45:14,500
|
|
|
|
So it's a little bit squeezed on Alex's screen
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2850
|
2022-02-06 17:25:12 +01:00
|
|
|
01:45:14,500 --> 01:45:21,599
|
|
|
|
but the idea is that you have a list of events that are listed on the main page.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2852
|
2022-02-06 17:25:12 +01:00
|
|
|
01:45:21,599 --> 01:45:25,280
|
|
|
|
So we're in the event index, this is our landing page when we load up MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2854
|
2022-02-06 17:25:12 +01:00
|
|
|
01:45:25,280 --> 01:45:29,0
|
|
|
|
and each of these individual lines represents an event so they're describing either an attack,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2857
|
2022-02-06 17:25:12 +01:00
|
|
|
01:45:29,0 --> 01:45:39,500
|
|
|
|
or perhaps a report, recurring distribution, or a certain type of of indicator lists and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2861
|
2022-02-06 17:25:12 +01:00
|
|
|
01:45:39,500 --> 01:45:45,0
|
|
|
|
So what you're seeing here is, you have each of these events having an ID and some metadata around it
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2863
|
2022-02-06 17:25:12 +01:00
|
|
|
01:45:45,0 --> 01:45:50,500
|
|
|
|
so these metadata can be either coming from this galaxy cluster system that we mentioned.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2864
|
2022-02-06 17:25:12 +01:00
|
|
|
01:45:50,500 --> 01:45:53,500
|
|
|
|
For example describing different attacker techniques,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2867
|
2022-02-06 17:25:12 +01:00
|
|
|
01:45:53,500 --> 01:46:00,0
|
|
|
|
different types of ransomwares in this case or attack patterns that are leveraged
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2871
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:00,0 --> 01:46:04,0
|
|
|
|
and then if we scroll a bit further right so this is a bit lower resolution here that we see
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2874
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:04,0 --> 01:46:07,500
|
|
|
|
but you should have it visible on the same page.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2877
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:07,500 --> 01:46:14,239
|
|
|
|
You see the information about what this event is trying to describe to us
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2880
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:14,239 --> 01:46:17,500
|
|
|
|
it's simple to understand text-based representation.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2881
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:17,500 --> 01:46:22,500
|
|
|
|
Now this instance is used for trainings in general so it's going to be filled with a lot of junk
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2883
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:21,198 --> 01:46:26,500
|
|
|
|
interspersed with real data that is coming from our TLP white feed.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2886
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:26,500 --> 01:46:31,679
|
|
|
|
So you're going to see some obviously weird events in there.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2889
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:31,679 --> 01:46:37,199
|
|
|
|
These are just there for testing, just players playing during an exercise and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2891
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:37,199 --> 01:46:39,500
|
|
|
|
but also some real events there.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2892
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:39,500 --> 01:46:42,500
|
|
|
|
So what we're going to be doing now is we're going to create our own event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2894
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:42,500 --> 01:46:46,0
|
|
|
|
based on that email that we received it's also on the hackmd page
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2896
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:46,0 --> 01:46:52,880
|
|
|
|
so just have a look at the email itself and we need to start encoding that event.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2900
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:52,880 --> 01:46:56,0
|
|
|
|
so before we include anything in MISP, the first thing that we need to do
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2902
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:56,0 --> 01:46:59,500
|
|
|
|
is we need to create a new event so this is where everything starts.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2904
|
2022-02-06 17:25:12 +01:00
|
|
|
01:46:59,500 --> 01:47:04,0
|
|
|
|
Way to do it is to just click on add event on the left side of the menu
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2906
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:04,0 --> 01:47:07,0
|
|
|
|
and then you start with a very simplistic form
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2907
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:07,0 --> 01:47:10,800
|
|
|
|
where we can describe the event in a very high level in MISP.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2909
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:10,800 --> 01:47:14,500
|
|
|
|
so here you see the first step is very straightforward
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2911
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:14,500 --> 01:47:19,300
|
|
|
|
the things that we have to watch out for out here is we have to decide who gets to see the event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2914
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:19,300 --> 01:47:21,500
|
|
|
|
so this is the distribution level
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2915
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:21,500 --> 01:47:25,0
|
|
|
|
and that we need to set a basic description of it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2918
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:25,0 --> 01:47:31,500
|
|
|
|
As for the distribution itself, you have different ways of interacting with the data here already
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2921
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:31,500 --> 01:47:34,400
|
|
|
|
so one of the decisions that you have to make,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2922
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:34,400 --> 01:47:37,500
|
|
|
|
even if you're going to share to the wider community out there is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2925
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:37,500 --> 01:47:41,119
|
|
|
|
do I keep this internal until I am ready to share it with the community
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2926
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:41,119 --> 01:47:45,500
|
|
|
|
or do I already make it visible to anyone that has access to the data in the community.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2930
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:45,500 --> 01:47:51,500
|
|
|
|
Now keep in mind that we have a publishing process in MISP, so until an event is published
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2933
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:51,500 --> 01:47:55,118
|
|
|
|
it is not propagated out to other MISP instances,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2934
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:55,118 --> 01:47:58,0
|
|
|
|
that means anyone on the current MISP instance can see the data
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2936
|
2022-02-06 17:25:12 +01:00
|
|
|
01:47:58,0 --> 01:48:01,500
|
|
|
|
but it will not jump to a different MISP instance at this point in any way.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2939
|
2022-02-06 17:25:12 +01:00
|
|
|
01:48:01,500 --> 01:48:06,0
|
|
|
|
but if you are creating it on a hosted instance for example
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2941
|
2022-02-06 17:25:12 +01:00
|
|
|
01:48:05,439 --> 01:48:10,500
|
|
|
|
if your ISAC is running a MISP instance and you're creating it on that one directly
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2944
|
2022-02-06 17:25:12 +01:00
|
|
|
01:48:10,500 --> 01:48:13,0
|
|
|
|
then this already has an impact on who can see the data.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2946
|
2022-02-06 17:25:12 +01:00
|
|
|
01:48:13,0 --> 01:48:17,500
|
|
|
|
So the option here, either go with "Your organization only"
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2947
|
2022-02-06 17:25:12 +01:00
|
|
|
01:48:17,500 --> 01:48:20,500
|
|
|
|
and then raise the distribution level once it's ready to be released
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2949
|
2022-02-06 17:25:12 +01:00
|
|
|
01:48:20,500 --> 01:48:25,500
|
|
|
|
or you already involve addressing the process and you pick something like "This community only"
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2952
|
2022-02-06 17:25:12 +01:00
|
|
|
01:48:25,500 --> 01:48:28,319
|
|
|
|
where others can chip in with their ideas from the get-go.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2954
|
|
|
|
01:48:28,319 --> 01:48:32,559
|
2022-02-06 17:25:12 +01:00
|
|
|
So this is up to you, it's a risk versus efficiency question.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2956
|
2022-02-06 17:25:12 +01:00
|
|
|
01:48:32,560 --> 01:48:36,500
|
|
|
|
Do I want to share the information and potentially overshare a bit
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2959
|
2022-02-06 17:25:12 +01:00
|
|
|
01:48:36,500 --> 01:48:43,0
|
|
|
|
by accidentally uploading information that is not yet confirmed that it can be shared out
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2962
|
2022-02-06 17:25:12 +01:00
|
|
|
01:48:43,0 --> 01:48:47,439
|
|
|
|
versus losing out on perhaps others immediately jumping on board
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2963
|
2022-02-06 17:25:12 +01:00
|
|
|
01:48:47,439 --> 01:48:52,0
|
|
|
|
and saying okay this is also something we've seen we've already done the analysis of it here you go,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2967
|
2022-02-06 17:25:12 +01:00
|
|
|
01:48:52,0 --> 01:48:54,960
|
|
|
|
so you have to balance those two things out.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2969
|
2022-02-06 17:25:12 +01:00
|
|
|
01:48:56,0 --> 01:49:02,0
|
|
|
|
For example some CSIRT was aware of this, so when people are working on a case
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2972
|
2022-02-06 17:25:12 +01:00
|
|
|
01:49:03,359 --> 01:49:09,0
|
|
|
|
by default it is "Your organization only" {inaudible} and at one point in time the team lead
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2974
|
2022-02-06 17:25:12 +01:00
|
|
|
01:49:09,0 --> 01:49:13,0
|
|
|
|
for example decide at some point it's okay, now you can share it to a wider community
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2977
|
2022-02-06 17:25:12 +01:00
|
|
|
01:49:13,0 --> 01:49:15,0
|
|
|
|
and then you change the distribution level.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2978
|
2022-02-06 17:25:12 +01:00
|
|
|
01:49:16,0 --> 01:49:19,500
|
|
|
|
Yeah, indeed. So let's start with the organization only for now
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2980
|
2022-02-06 17:25:12 +01:00
|
|
|
01:49:19,500 --> 01:49:21,500
|
|
|
|
for different reasons that we'll get back to later on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2981
|
2022-02-06 17:25:12 +01:00
|
|
|
01:49:21,500 --> 01:49:26,500
|
|
|
|
it allows us to show off another feature afterwards that is handy, so we start with that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2983
|
2022-02-06 17:25:12 +01:00
|
|
|
01:49:26,500 --> 01:49:30,500
|
|
|
|
Then we have to describe the threat level so this is a very subjective question.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2987
|
2022-02-06 17:25:12 +01:00
|
|
|
01:49:30,500 --> 01:49:36,500
|
|
|
|
Threat level will depend a lot on what sort of an organization you are versus who you're sharing it with
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2990
|
2022-02-06 17:25:12 +01:00
|
|
|
01:49:35,500 --> 01:49:40,500
|
|
|
|
so we all have different interpretations of what we consider a high threat level.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2993
|
2022-02-06 17:25:12 +01:00
|
|
|
01:49:40,500 --> 01:49:44,500
|
|
|
|
We have some descriptions for each of these fields predefined.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2996
|
2022-02-06 17:25:12 +01:00
|
|
|
01:49:44,500 --> 01:49:46,500
|
|
|
|
If you click on the little information box,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
2997
|
2022-02-06 17:25:12 +01:00
|
|
|
01:49:46,500 --> 01:49:52,500
|
|
|
|
it will tell you that high is sophisticated APT malware or zero day attack.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3000
|
2022-02-06 17:25:12 +01:00
|
|
|
01:49:52,500 --> 01:49:56,0
|
|
|
|
Please just freely disregard this because
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3003
|
2022-02-06 17:25:12 +01:00
|
|
|
01:49:56,0 --> 01:50:00,0
|
|
|
|
nowadays a lot of information sharing happens in completely different domains,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3004
|
2022-02-06 17:25:12 +01:00
|
|
|
01:50:00,0 --> 01:50:04,500
|
|
|
|
so if a fraud team is sharing information about fraudster
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3005
|
2022-02-06 17:25:12 +01:00
|
|
|
01:50:04,500 --> 01:50:11,0
|
|
|
|
their definition of high threat level would be very different from those in cyber security for example.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3010
|
2022-02-06 17:25:12 +01:00
|
|
|
01:50:11,0 --> 01:50:14,500
|
|
|
|
So generally it's just a subjective first measure
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3011
|
2022-02-06 17:25:12 +01:00
|
|
|
01:50:14,500 --> 01:50:18,500
|
|
|
|
but a lot of organizations users use this to briefly filter out what they should tackle first
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3013
|
2022-02-06 17:25:12 +01:00
|
|
|
01:50:18,500 --> 01:50:24,500
|
|
|
|
so still use it with care. If you don't want to use this field, picking undefined is fine too.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3017
|
2022-02-06 17:25:12 +01:00
|
|
|
01:50:25,760 --> 01:50:29,500
|
|
|
|
Analysis is the next field, describes how far along you've come with the analysis process.
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
3019
|
2022-02-06 17:25:12 +01:00
|
|
|
01:50:29,500 --> 01:50:34,480
|
|
|
|
So basically with this what you're telling the community is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3020
|
2022-02-06 17:25:12 +01:00
|
|
|
01:50:34,480 --> 01:50:37,500
|
|
|
|
I'm just starting out with the analysis these are my initial findings
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3023
|
2022-02-06 17:25:12 +01:00
|
|
|
01:50:37,500 --> 01:50:41,839
|
|
|
|
versus for example saying that my analysis process is already complete
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3024
|
2022-02-06 17:25:12 +01:00
|
|
|
01:50:41,839 --> 01:50:46,500
|
|
|
|
i'm not going to be digging more for now, I consider this complete,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3026
|
2022-02-06 17:25:12 +01:00
|
|
|
01:50:46,500 --> 01:50:54,500
|
|
|
|
if you have additional information then obviously start collaborating with us.
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
3029
|
2022-02-06 17:25:12 +01:00
|
|
|
01:50:54,500 --> 01:50:59,500
|
|
|
|
So just pick whichever is most appropriate for you. Let's just go with "Initial" for now.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3032
|
2022-02-06 17:25:12 +01:00
|
|
|
01:50:59,840 --> 01:51:05,500
|
|
|
|
and then comes the most important part of this form which is describing the event info,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3035
|
2022-02-06 17:25:12 +01:00
|
|
|
01:51:05,500 --> 01:51:09,0
|
|
|
|
so this is a brief description for analysts that are looking at the data
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3036
|
2022-02-06 17:25:12 +01:00
|
|
|
01:51:09,0 --> 01:51:13,500
|
|
|
|
that best described the event that you're basically sharing
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3039
|
2022-02-06 17:25:12 +01:00
|
|
|
01:51:13,500 --> 01:51:21,0
|
|
|
|
Now be brief here and be careful about including very domain or organization specific information.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3042
|
2022-02-06 17:25:12 +01:00
|
|
|
01:51:21,0 --> 01:51:25,500
|
|
|
|
One of the mistakes that people often make here is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3043
|
2022-02-06 17:25:12 +01:00
|
|
|
01:51:25,500 --> 01:51:29,500
|
|
|
|
for example typing a ticket number or ticket id in there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3048
|
2022-02-06 17:25:12 +01:00
|
|
|
01:51:29,500 --> 01:51:35,500
|
|
|
|
so if you have a ticketing system and you basically start your investigation from your ticketing system
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3051
|
2022-02-06 17:25:12 +01:00
|
|
|
01:51:35,500 --> 01:51:39,500
|
|
|
|
sharing out something like what Alex has typed there is not very handy for anyone else
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3053
|
2022-02-06 17:25:12 +01:00
|
|
|
01:51:39,500 --> 01:51:41,500
|
|
|
|
nobody will have a clue what you mean with that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3055
|
2022-02-06 17:25:12 +01:00
|
|
|
01:51:41,500 --> 01:51:44,500
|
|
|
|
Another mistake that can happen here very often is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3056
|
2022-02-06 17:25:12 +01:00
|
|
|
01:51:44,500 --> 01:51:49,0
|
|
|
|
especially if you're starting out small and in turn initially you're only keeping the events for yourself
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3057
|
2022-02-06 17:25:12 +01:00
|
|
|
01:51:49,0 --> 01:51:56,500
|
|
|
|
and then perhaps later on you decide that you want to maybe perhaps after all share it out to a community
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3063
|
2022-02-06 17:25:12 +01:00
|
|
|
01:51:56,500 --> 01:52:59,500
|
|
|
|
then one of the things that can really hurt you at that point is if you've used different language
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3065
|
2022-02-06 17:25:12 +01:00
|
|
|
01:52:59,500 --> 01:52:03,500
|
|
|
|
for example to describe the event info so we've seen this very often
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3068
|
2022-02-06 17:25:12 +01:00
|
|
|
01:52:03,500 --> 01:52:09,0
|
|
|
|
instead of describing the things in English, we choose our own languages
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3070
|
2022-02-06 17:25:12 +01:00
|
|
|
01:52:12,0 --> 01:52:19,500
|
|
|
|
Both Alex {inaudible} and myself is hungarian, we are pretty prone to doing this in general
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3073
|
2022-02-06 17:25:12 +01:00
|
|
|
01:52:19,500 --> 01:52:23,500
|
|
|
|
and this is generally something that will hurt us in the long term
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3076
|
2022-02-06 17:25:12 +01:00
|
|
|
01:52:23,500 --> 01:52:27,500
|
|
|
|
because once you share it out with a more international community
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3077
|
2022-02-06 17:25:12 +01:00
|
|
|
01:52:25,920 --> 01:52:30,500
|
|
|
|
you either have to go through the effort of translating it
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3078
|
2022-02-06 17:25:12 +01:00
|
|
|
01:52:30,500 --> 01:52:34,500
|
|
|
|
or basically make it illegible for the recipient
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3081
|
2022-02-06 17:25:12 +01:00
|
|
|
01:52:34,500 --> 01:52:40,500
|
|
|
|
So stick to something simple, simple phrasing, be as concise as possible
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3083
|
2022-02-06 17:25:12 +01:00
|
|
|
01:52:40,500 --> 01:52:44,500
|
|
|
|
but make sure that it's still understood what you mean.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
01:52:46,500 --> 01:52:51,500
|
|
|
|
Okay, once you are done. In this case we are doing a {inaudible} spearphishing email,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3085
|
2022-02-06 17:25:12 +01:00
|
|
|
01:52:51,920 --> 01:52:55,800
|
|
|
|
we know that it's targeting the telco sector in luxembourg and we know that we have a malware sample
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3087
|
2022-02-06 17:25:12 +01:00
|
|
|
01:52:55,800 --> 01:53:00,0
|
|
|
|
so that's a pretty nice short explanation of what the event is about.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3091
|
2022-02-06 17:25:12 +01:00
|
|
|
01:53:00,0 --> 01:53:05,0
|
|
|
|
So once we click submit, we have our event created and we already see that that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3092
|
2022-02-06 17:25:12 +01:00
|
|
|
01:53:05,0 --> 01:53:09,500
|
|
|
|
our event suddenly has a lot of data that we didn't intentionally put in there yet.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3094
|
2022-02-06 17:25:12 +01:00
|
|
|
01:53:09,500 --> 01:53:11,500
|
|
|
|
So we see a bunch of tags that are applied to the event,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3098
|
2022-02-06 17:25:12 +01:00
|
|
|
01:53:11,500 --> 01:53:15,500
|
|
|
|
we see that the event already has information about
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3099
|
2022-02-06 17:25:12 +01:00
|
|
|
01:53:15,500 --> 01:53:20,500
|
|
|
|
who created the information, who the local owners is information and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3101
|
2022-02-06 17:25:12 +01:00
|
|
|
01:53:20,500 --> 01:53:25,500
|
|
|
|
So MISP basically takes a lot of {inaudible local/global} settings from the instance
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3105
|
2022-02-06 17:25:12 +01:00
|
|
|
01:53:25,500 --> 01:53:29,500
|
|
|
|
and it fills in the event when it is created with these basic datasets.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3107
|
2022-02-06 17:25:12 +01:00
|
|
|
01:53:29,500 --> 01:53:33,500
|
|
|
|
A lot of these also involve the contextualization that we start out with
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3108
|
2022-02-06 17:25:12 +01:00
|
|
|
01:53:33,500 --> 01:53:37,500
|
|
|
|
so it might seem a little bit pointless to immediately label something
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3109
|
2022-02-06 17:25:12 +01:00
|
|
|
01:53:37,500 --> 01:53:39,500
|
|
|
|
that we have not even started working on yet
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3110
|
2022-02-06 17:25:12 +01:00
|
|
|
01:53:39,500 --> 01:53:44,200
|
|
|
|
but also keep in mind that very often what we do internally in our organizations is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3111
|
2022-02-06 17:25:12 +01:00
|
|
|
01:53:44,200 --> 01:53:50,0
|
|
|
|
we have several MISP instances that already are domain specific
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3118
|
2022-02-06 17:25:12 +01:00
|
|
|
01:53:50,0 --> 01:53:55,500
|
|
|
|
So, for example we have our spam collector instance, we have our our sandboxing in MISP instance and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3121
|
2022-02-06 17:25:12 +01:00
|
|
|
01:53:55,500 --> 01:54:00,500
|
|
|
|
These already define the scope of the information that go into them
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3124
|
2022-02-06 17:25:12 +01:00
|
|
|
01:54:00,500 --> 01:54:05,0
|
|
|
|
so we can already decide okay if we are on our spam collector MISP instance
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3127
|
2022-02-06 17:25:12 +01:00
|
|
|
01:54:05,0 --> 01:54:07,500
|
|
|
|
anything that goes in there will be related to spam
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3128
|
2022-02-06 17:25:12 +01:00
|
|
|
01:54:07,500 --> 01:54:14,0
|
|
|
|
so in this case we can remove these tags because we don't actually want to include those just yet.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3131
|
2022-02-06 17:25:12 +01:00
|
|
|
01:54:14,0 --> 01:54:16,0
|
|
|
|
Maybe we can keep that one because it's still a draft,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3132
|
2022-02-06 17:25:12 +01:00
|
|
|
01:54:16,0 --> 01:54:20,500
|
|
|
|
so that means we will do an evaluation of this spam email accuracy
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3135
|
2022-02-06 17:25:12 +01:00
|
|
|
01:54:20,500 --> 01:54:25,500
|
|
|
|
and then, so we have some defined taxonomy in MISP on this instance we enabled
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3138
|
2022-02-06 17:25:12 +01:00
|
|
|
01:54:25,500 --> 01:54:30,500
|
|
|
|
for example the workflow one, this one is maybe of interest from different organizations
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3141
|
2022-02-06 17:25:12 +01:00
|
|
|
01:54:31,39 --> 01:54:35,500
|
|
|
|
is a generic one about workflow, what is the current state of things.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3142
|
2022-02-06 17:25:12 +01:00
|
|
|
01:54:35,500 --> 01:54:39,500
|
|
|
|
So don't forget, in the initial event when we created the event
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
3143
|
2022-02-06 17:25:12 +01:00
|
|
|
01:54:39,500 --> 01:54:42,500
|
|
|
|
we have information about the state and stuff like that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3144
|
2022-02-06 17:25:12 +01:00
|
|
|
01:54:42,500 --> 01:54:45,0
|
|
|
|
Now with this what we do is recommend to have taxonomies
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3150
|
2022-02-06 17:25:12 +01:00
|
|
|
01:54:45,0 --> 01:54:49,500
|
|
|
|
and you can really set up whatever you like in the misp event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3153
|
2022-02-06 17:25:12 +01:00
|
|
|
01:54:49,500 --> 01:54:55,500
|
|
|
|
to define the current state of this event so we keep "Draft" for this case.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3154
|
2022-02-06 17:25:12 +01:00
|
|
|
01:54:57,0 --> 01:55:00,500
|
|
|
|
Yup indeed, so we keep it at this
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3155
|
2022-02-06 17:25:12 +01:00
|
|
|
01:55:00,500 --> 01:55:03,500
|
|
|
|
and we scroll further down and we see that MISP warns us about a few things,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3156
|
2022-02-06 17:25:12 +01:00
|
|
|
01:55:03,500 --> 01:55:05,500
|
|
|
|
first of all, data is not published
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3158
|
2022-02-06 17:25:12 +01:00
|
|
|
01:55:05,500 --> 01:55:07,500
|
|
|
|
and second of all if we scroll a bit further down
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3159
|
2022-02-06 17:25:12 +01:00
|
|
|
01:55:07,500 --> 01:55:11,0
|
|
|
|
we see that MISP also tells us that there are no attributes in here.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3160
|
2022-02-06 17:25:12 +01:00
|
|
|
01:55:11,0 --> 01:55:13,0
|
|
|
|
So this is still an empty envelope that we are about to share
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3162
|
2022-02-06 17:25:12 +01:00
|
|
|
01:55:13,0 --> 01:55:16,500
|
|
|
|
so MISP tells us, don't share this just yet, fill it up with data first.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3165
|
2022-02-06 17:25:12 +01:00
|
|
|
01:55:16,500 --> 01:55:23,0
|
|
|
|
So at this point, we can start populating the information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3168
|
2022-02-06 17:25:12 +01:00
|
|
|
01:55:23,0 --> 01:55:30,0
|
|
|
|
So if you look at the initial document that we use as a starting point,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3171
|
2022-02-06 17:25:12 +01:00
|
|
|
01:55:30,0 --> 01:55:35,0
|
|
|
|
we see in there that we have a lot of information in there described
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3173
|
2022-02-06 17:25:12 +01:00
|
|
|
01:55:35,0 --> 01:55:38,500
|
|
|
|
we see for example that we are dealing with spearphishing,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3175
|
2022-02-06 17:25:12 +01:00
|
|
|
01:55:38,500 --> 01:55:42,500
|
|
|
|
we see that we have an email that was received at a certain point in time
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3177
|
2022-02-06 17:25:12 +01:00
|
|
|
01:55:42,500 --> 01:55:51,0
|
|
|
|
and we also see that we have an attacker that pretends to be working at the CEO's daughter school
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3181
|
2022-02-06 17:25:12 +01:00
|
|
|
01:55:51,0 --> 01:55:57,500
|
|
|
|
and sending the email from a spoofed email address.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3184
|
2022-02-06 17:25:12 +01:00
|
|
|
01:55:57,500 --> 01:56:01,500
|
|
|
|
So we can start by describing this information, by including this information.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3187
|
2022-02-06 17:25:12 +01:00
|
|
|
01:56:01,500 --> 01:56:04,500
|
|
|
|
So perhaps one of the things that we can take here is,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3188
|
2022-02-06 17:25:12 +01:00
|
|
|
01:56:04,500 --> 01:56:08,500
|
|
|
|
let's start with the most basic thing we're describing, an email, so let's start with an email object.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3191
|
2022-02-06 17:25:12 +01:00
|
|
|
01:56:08,500 --> 01:56:16,0
|
|
|
|
So we're going to add an object and we're going to select email
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3193
|
2022-02-06 17:25:12 +01:00
|
|
|
01:56:18,479 --> 01:56:21,0
|
|
|
|
So here we see that this is coming from the templating system
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3194
|
2022-02-06 17:25:12 +01:00
|
|
|
01:56:21,0 --> 01:56:27,500
|
|
|
|
where you can define different concepts with different fields
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3197
|
2022-02-06 17:25:12 +01:00
|
|
|
01:56:27,500 --> 01:56:30,500
|
|
|
|
that have to be then populated using this object templating system.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3199
|
2022-02-06 17:25:12 +01:00
|
|
|
01:56:31,760 --> 01:56:34,500
|
|
|
|
So we have a bunch of information that we can fill out here
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3200
|
2022-02-06 17:25:12 +01:00
|
|
|
01:56:34,500 --> 01:56:40,0
|
|
|
|
we see the spoofed address so we see a "From" address that we can encode
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3203
|
2022-02-06 17:25:12 +01:00
|
|
|
01:56:45,439 --> 01:56:54,500
|
|
|
|
Okay. we also have a sample that I don't know if I've uploaded it anywhere. Alex?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3205
|
2022-02-06 17:25:12 +01:00
|
|
|
01:56:54,500 --> 01:56:57,500
|
|
|
|
If not just pick any file for now because I think that's something I forgot to do.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3208
|
2022-02-06 17:25:12 +01:00
|
|
|
01:57:00,880 --> 01:57:03,500
|
|
|
|
Yeah I don't know where the sample is. Yeah maybe we should add it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3210
|
2022-02-06 17:25:12 +01:00
|
|
|
01:57:03,500 --> 01:57:08,0
|
|
|
|
Yeah just put putty.x or something if you have it
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3212
|
2022-02-06 17:25:12 +01:00
|
|
|
01:57:12,800 --> 01:57:14,500
|
|
|
|
Oops
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3213
|
2022-02-06 17:25:12 +01:00
|
|
|
01:57:16,639 --> 01:57:19,500
|
|
|
|
or we can do it as a separate object, we can just do this separately
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3215
|
2022-02-06 17:25:12 +01:00
|
|
|
01:57:19,500 --> 01:57:21,0
|
|
|
|
Yeah, we can do a separate object.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3216
|
2022-02-06 17:25:12 +01:00
|
|
|
01:57:21,0 --> 01:57:26,0
|
|
|
|
Yeah, indeed, indeed. Okay so what we can already describe here is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3219
|
2022-02-06 17:25:12 +01:00
|
|
|
01:57:26,0 --> 01:57:31,500
|
|
|
|
we can still add the name of the attachment that we had in there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3222
|
2022-02-06 17:25:12 +01:00
|
|
|
01:57:35,500 --> 01:57:38,500
|
2021-12-27 05:45:03 +01:00
|
|
|
just to fast track it a bit
|
|
|
|
|
|
|
|
3223
|
|
|
|
01:57:40,639 --> 01:57:42,880
|
|
|
|
good
|
|
|
|
|
|
|
|
3224
|
2022-02-06 17:25:12 +01:00
|
|
|
01:57:46,79 --> 01:57:48,500
|
|
|
|
so we have a timestamp too which is interesting
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3225
|
|
|
|
01:57:47,679 --> 01:57:52,319
|
2022-02-06 17:25:12 +01:00
|
|
|
um
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3226
|
|
|
|
01:57:49,760 --> 01:57:54,239
|
2022-02-06 17:25:12 +01:00
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3227
|
2022-02-06 17:25:12 +01:00
|
|
|
01:57:52,319 --> 01:57:55,500
|
|
|
|
so this one has been received at a specific date so it was the third of....
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3228
|
2022-02-06 17:25:12 +01:00
|
|
|
01:57:54,238 --> 01:57:59,0
|
|
|
|
so the "First Seen" is basically something that you can already set up
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3230
|
2022-02-06 17:25:12 +01:00
|
|
|
01:57:59,0 --> 01:58:07,500
|
|
|
|
so it was the third of February, we had a specific time if i'm not mistaken.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3231
|
|
|
|
01:58:03,920 --> 01:58:10,158
|
|
|
|
|
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
3232
|
|
|
|
01:58:07,198 --> 01:58:20,500
|
|
|
|
So in this one has been sent on, received on 15, 16,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3237
|
2022-02-06 17:25:12 +01:00
|
|
|
01:58:27,0 --> 01:58:35,500
|
|
|
|
we also see that that basically the attachment was spoofing the document
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3238
|
2022-02-06 17:25:12 +01:00
|
|
|
01:58:30,639 --> 01:58:41,0
|
|
|
|
about the report about the CEO's daughter's progress in school.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3242
|
2022-02-06 17:25:12 +01:00
|
|
|
01:58:41,0 --> 01:58:48,500
|
|
|
|
So we can pick the file name for the attachment and that is under the attachment section in the object
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3245
|
2022-02-06 17:25:12 +01:00
|
|
|
01:58:55,500 --> 01:58:57,500
|
|
|
|
Good.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3246
|
2022-02-06 17:25:12 +01:00
|
|
|
01:58:57,500 --> 01:58:59,0
|
|
|
|
I'm just clicking it. Yeah
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3247
|
2022-02-06 17:25:12 +01:00
|
|
|
01:58:59,0 --> 01:59:03,500
|
|
|
|
It is called report.doc.exe, I mean maybe it's not in the text right now.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3248
|
2022-02-06 17:25:12 +01:00
|
|
|
01:59:03,500 --> 01:59:06,500
|
|
|
|
Ah okay, it might not be in the text, might be just in the original file.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3251
|
2022-02-06 17:25:12 +01:00
|
|
|
01:59:06,500 --> 01:59:12,500
|
|
|
|
Sorry about that. So yeah report.doc.exe
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3252
|
2022-02-06 17:25:12 +01:00
|
|
|
01:59:18,0 --> 01:59:19,500
|
|
|
|
Ok yeah perfect.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3253
|
2022-02-06 17:25:12 +01:00
|
|
|
01:59:19,500 --> 01:59:26,500
|
|
|
|
And then we also know that it was received, that we have the received header ip
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
325 6
|
|
|
|
01:59:26,500 --> 01:59:34,0
|
|
|
|
so we can include that as well that's also stated in the email. It's 137.221.106.104
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
3259
|
|
|
|
01:59:41,500 --> 01:59:50,500
|
|
|
|
and we even have the hostname ,if you want to include that, that was also included in the email/report
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
3263
|
|
|
|
01:59:54,0 --> 01:59:59,500
|
|
|
|
Perfect, so as you can see here we did not fill everything out
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
3264
|
|
|
|
01:59:59,500 --> 02:00:02,500
|
|
|
|
because we don't know everything based on the report but we knew some of the fields.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
3267
|
|
|
|
02:00:02,500 --> 02:00:08,500
|
|
|
|
We also see that each of these objects basically have some requirements and we satisfy those in this case.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
3271
|
|
|
|
02:00:08,500 --> 02:00:13,0
|
|
|
|
So if you scroll all the way to the top you will see that that this object had a requirement
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3274
|
2022-02-06 17:25:12 +01:00
|
|
|
02:00:13,0 --> 02:00:17,500
|
|
|
|
any of those fields have to be filled, we've definitely met that so we can just click submit
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3276
|
2022-02-06 17:25:12 +01:00
|
|
|
02:00:16,0 --> 02:00:20,500
|
|
|
|
and we can create our object in this case
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3278
|
2022-02-06 17:25:12 +01:00
|
|
|
02:00:23,0 --> 02:00:27,500
|
|
|
|
so here we see MISP telling us if we create this object that's what it will look like.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3281
|
2022-02-06 17:25:12 +01:00
|
|
|
02:00:27,500 --> 02:00:31,0
|
|
|
|
So we have in this case created our object and now it is attached to the event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3284
|
2022-02-06 17:25:12 +01:00
|
|
|
02:00:31,359 --> 02:00:33,0
|
|
|
|
and suddenly stuff happened here
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3285
|
2022-02-06 17:25:12 +01:00
|
|
|
02:00:33,0 --> 02:00:38,500
|
|
|
|
so we see that each of these attributes already start correlating with existing events.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3288
|
2022-02-06 17:25:12 +01:00
|
|
|
02:00:38,500 --> 02:00:43,500
|
|
|
|
Now we ran this little exercise before so it correlate with some of those previous events
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3291
|
2022-02-06 17:25:12 +01:00
|
|
|
02:00:43,500 --> 02:00:48,500
|
|
|
|
but normally if this was a real case if you get a correlation
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
3293
|
2022-02-06 17:25:12 +01:00
|
|
|
02:00:48,500 --> 02:00:53,500
|
|
|
|
there is either something very similar that already happened before
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3294
|
2022-02-06 17:25:12 +01:00
|
|
|
02:00:53,500 --> 02:00:58,0
|
|
|
|
or is it something that simply might be a coincidence
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3295
|
2022-02-06 17:25:12 +01:00
|
|
|
02:00:58,0 --> 02:01:01,500
|
|
|
|
but it's still cause for investigation to check
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3296
|
2022-02-06 17:25:12 +01:00
|
|
|
02:01:01,500 --> 02:01:06,500
|
|
|
|
is this something that might help me bootstrap my investigation or is it just noise that is not relevant.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3300
|
2022-02-06 17:25:12 +01:00
|
|
|
02:01:06,500 --> 02:01:09,0
|
|
|
|
Maybe a side note because we have often the questions
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3301
|
2022-02-06 17:25:12 +01:00
|
|
|
02:01:09,0 --> 02:01:15,500
|
|
|
|
when you create such object in MISP, you see that can be cumbersome to create it manually
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3302
|
2022-02-06 17:25:12 +01:00
|
|
|
02:01:15,500 --> 02:01:19,500
|
|
|
|
so don't forget that everything that we do right now can be done through the API
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3308
|
2022-02-06 17:25:12 +01:00
|
|
|
02:01:19,500 --> 02:01:23,0
|
|
|
|
so you can use PyMISP, automatically do it and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3310
|
2022-02-06 17:25:12 +01:00
|
|
|
02:01:23,0 --> 02:01:29,500
|
|
|
|
So what we show there, if you think on the API level it can be done automatically
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3312
|
2022-02-06 17:25:12 +01:00
|
|
|
02:01:27,840 --> 02:01:34,500
|
|
|
|
so if you have tool that are extracting emails automatically from the PC mailbox, whatever
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3315
|
2022-02-06 17:25:12 +01:00
|
|
|
02:01:34,500 --> 02:01:36,500
|
|
|
|
you can automatically do it in MISP.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3317
|
2022-02-06 17:25:12 +01:00
|
|
|
02:01:36,560 --> 02:01:40,500
|
|
|
|
We just show the complete process manually but you can have a mix for some event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3320
|
2022-02-06 17:25:12 +01:00
|
|
|
02:01:40,500 --> 02:01:45,500
|
|
|
|
maybe some might be created automatically and then update it manually and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3323
|
2022-02-06 17:25:12 +01:00
|
|
|
02:01:45,500 --> 02:01:49,500
|
|
|
|
Something else that might be interesting here at this point is we've encoded this object
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3325
|
2022-02-06 17:25:12 +01:00
|
|
|
02:01:49,520 --> 02:01:57,0
|
|
|
|
and we look at it and perhaps we might want to change the distribution settings
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3328
|
2022-02-06 17:25:12 +01:00
|
|
|
02:01:57,0 --> 02:01:59,500
|
|
|
|
based on the different data points that we have in there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3330
|
2022-02-06 17:25:12 +01:00
|
|
|
02:01:59,279 --> 02:02:04,500
|
|
|
|
so most of these such as the malicious host that email is sent from
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3331
|
2022-02-06 17:25:12 +01:00
|
|
|
02:02:04,500 --> 02:02:05,759
|
|
|
|
are technical information that we can share with the broader community
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3334
|
2022-02-06 17:25:12 +01:00
|
|
|
02:02:07,279 --> 02:02:12,500
|
|
|
|
but perhaps the name of the school that our CEO's daughter attends
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3335
|
2022-02-06 17:25:12 +01:00
|
|
|
02:02:12,500 --> 02:02:13,599
|
|
|
|
is something that we don't need to share with the entire community
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3338
|
|
|
|
02:02:15,118 --> 02:02:20,0
|
2022-02-06 17:25:12 +01:00
|
|
|
so we could reduce the distribution of that individual attribute in this object
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3340
|
2022-02-06 17:25:12 +01:00
|
|
|
02:02:20,0 --> 02:02:24,500
|
|
|
|
so that we keep that, for example only for our own organization and for our own internal records.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3343
|
2022-02-06 17:25:12 +01:00
|
|
|
02:02:24,500 --> 02:02:28,500
|
|
|
|
So one of the things you can do in this case is you can edit that individual attribute
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3346
|
2022-02-06 17:25:12 +01:00
|
|
|
02:02:28,158 --> 02:02:36,500
|
|
|
|
so the from address in the object and you can set a distribution level to "Your organization only".
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3349
|
2022-02-06 17:25:12 +01:00
|
|
|
02:02:36,500 --> 02:02:40,500
|
|
|
|
In this case, once we release the event to a broader audience
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3351
|
2022-02-06 17:25:12 +01:00
|
|
|
02:02:40,500 --> 02:02:44,0
|
|
|
|
it will keep this individual attribute for an organization
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3352
|
2022-02-06 17:25:12 +01:00
|
|
|
02:02:44,0 --> 02:02:48,500
|
|
|
|
and it will not share it out with with other constituencies
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3354
|
2022-02-06 17:25:12 +01:00
|
|
|
02:02:48,500 --> 02:02:51,500
|
|
|
|
Okay, so some other stuff that happened at this point
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3355
|
2022-02-06 17:25:12 +01:00
|
|
|
02:02:51,500 --> 02:02:55,500
|
|
|
|
we see that several of you are creating events so that's great.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3358
|
2022-02-06 17:25:12 +01:00
|
|
|
02:02:55,500 --> 02:02:58,0
|
|
|
|
The correlation count really went up all of the sudden so it's good to see.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3360
|
2022-02-06 17:25:12 +01:00
|
|
|
02:02:57,359 --> 02:03:04,0
|
|
|
|
Something else that happened at this point is the event itself got correlated to other events as well
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3361
|
2022-02-06 17:25:12 +01:00
|
|
|
02:03:04,0 --> 02:03:08,500
|
|
|
|
So if you scroll up all the way, we see that the attributes that we've added
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3366
|
2022-02-06 17:25:12 +01:00
|
|
|
02:03:07,599 --> 02:03:10,0
|
|
|
|
are also showing us what other events we're correlating in.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3368
|
2022-02-06 17:25:12 +01:00
|
|
|
02:03:10,0 --> 02:03:15,500
|
|
|
|
So this is a summary of all the individual attributes, correlations from the event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3369
|
2022-02-06 17:25:12 +01:00
|
|
|
02:03:15,500 --> 02:03:18,500
|
|
|
|
that means that if this object is correlating
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3370
|
2022-02-06 17:25:12 +01:00
|
|
|
02:03:18,500 --> 02:03:22,500
|
|
|
|
or these attributes within the object are correlating to it with a certain event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3375
|
2022-02-06 17:25:12 +01:00
|
|
|
02:03:22,500 --> 02:03:25,500
|
|
|
|
and certain other objects are correlating with other events
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3377
|
2022-02-06 17:25:12 +01:00
|
|
|
02:03:25,500 --> 02:03:29,500
|
|
|
|
then this would be a full summary of all the events that you're correlating with.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3379
|
2022-02-06 17:25:12 +01:00
|
|
|
02:03:29,500 --> 02:03:31,500
|
|
|
|
You can also draw a graph out of that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3380
|
2022-02-06 17:25:12 +01:00
|
|
|
02:03:31,920 --> 02:03:34,500
|
|
|
|
If you click on the correlation graph you will see how the events are interlinked
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3382
|
2022-02-06 17:25:12 +01:00
|
|
|
02:03:35,198 --> 02:03:38,500
|
|
|
|
and you can further explore this by selecting any of the nodes
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3384
|
2022-02-06 17:25:12 +01:00
|
|
|
02:03:38,500 --> 02:03:44,0
|
|
|
|
and pressing x on that to further expand it with its own correlations.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3387
|
2022-02-06 17:25:12 +01:00
|
|
|
02:03:46,500 --> 02:03:50,500
|
|
|
|
Okay. Let's go back to the event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3388
|
2022-02-06 17:25:12 +01:00
|
|
|
02:03:52,0 --> 02:03:57,0
|
|
|
|
Yeah I don't think we have a lot of correlations there, for the other events they're all the same
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3392
|
2022-02-06 17:25:12 +01:00
|
|
|
02:03:59,679 --> 02:04:06,500
|
|
|
|
Okay now going back to our little example we have now created four attributes all together
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3395
|
2022-02-06 17:25:12 +01:00
|
|
|
02:04:06,500 --> 02:04:11,0
|
|
|
|
out of the object template but we could have done this differently as well
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3397
|
2022-02-06 17:25:12 +01:00
|
|
|
02:04:11,0 --> 02:04:16,0
|
|
|
|
what we could have done is we could also have created those attributes individually
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3398
|
2022-02-06 17:25:12 +01:00
|
|
|
02:04:16,0 --> 02:04:20,500
|
|
|
|
and added those to the event directly.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3404
|
2022-02-06 17:25:12 +01:00
|
|
|
02:04:20,500 --> 02:04:22,500
|
|
|
|
So one of the things that we can do now
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3405
|
2022-02-06 17:25:12 +01:00
|
|
|
02:04:24,319 --> 02:04:26,500
|
|
|
|
is we can go back to our report and tackle the next thing that is described there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3406
|
2022-02-06 17:25:12 +01:00
|
|
|
02:04:25,920 --> 02:04:27,500
|
|
|
|
and let's do it slightly differently.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3407
|
2022-02-06 17:25:12 +01:00
|
|
|
02:04:27,359 --> 02:04:35,500
|
|
|
|
So we also see that basically the person that is impersonated is also described
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3410
|
2022-02-06 17:25:12 +01:00
|
|
|
02:04:31,760 --> 02:04:43,500
|
|
|
|
so that is basically, in this case John Doe the teacher of the student
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3411
|
2022-02-06 17:25:12 +01:00
|
|
|
02:04:43,500 --> 02:04:46,500
|
|
|
|
So let's just create a person object and describe that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3416
|
2022-02-06 17:25:12 +01:00
|
|
|
02:04:46,500 --> 02:04:53,0
|
|
|
|
So what we can do now is instead of directly describing it as an object,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3418
|
2022-02-06 17:25:12 +01:00
|
|
|
02:04:53,0 --> 02:04:59,500
|
|
|
|
we can first add those different fields, at least a name as individual attributes.
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
3421
|
2022-02-06 17:25:12 +01:00
|
|
|
02:04:59,500 --> 02:05:02,500
|
|
|
|
So let's see how adding individual attributes work
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3422
|
2022-02-06 17:25:12 +01:00
|
|
|
02:05:00,0 --> 02:05:04,500
|
|
|
|
so we click on the little plus icon above the attribute list
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3425
|
2022-02-06 17:25:12 +01:00
|
|
|
02:05:04,500 --> 02:05:08,500
|
|
|
|
and we simply select category "Person"
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3426
|
2022-02-06 17:25:12 +01:00
|
|
|
02:05:08,500 --> 02:05:13,500
|
|
|
|
and from "Person" we select "first-name", "first-name" is John.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3428
|
2022-02-06 17:25:12 +01:00
|
|
|
02:05:13,500 --> 02:05:16,0
|
|
|
|
and here we can already define, is this an indicator?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3429
|
2022-02-06 17:25:12 +01:00
|
|
|
02:05:15,39 --> 02:05:20,0
|
|
|
|
Do we want to set it for intrusion detection system flag?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3431
|
2022-02-06 17:25:12 +01:00
|
|
|
02:05:20,0 --> 02:05:23,0
|
|
|
|
No, definitely not, this in itself is not an indicator
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3433
|
2022-02-06 17:25:12 +01:00
|
|
|
02:05:23,0 --> 02:05:29,0
|
|
|
|
In fact we want to also disable correlation on this as this is a pretty common name
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3436
|
2022-02-06 17:25:12 +01:00
|
|
|
02:05:29,0 --> 02:05:33,0
|
|
|
|
that is definitely not something to...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3437
|
2022-02-06 17:25:12 +01:00
|
|
|
02:05:33,0 --> 02:05:37,500
|
|
|
|
We don't need a comment for now, we're going to convert it into an object anyway
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3440
|
2022-02-06 17:25:12 +01:00
|
|
|
02:05:40,0 --> 02:05:44,500
|
|
|
|
So what we can do is we can also disable correlation on this we don't want to correlate on John.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3443
|
2022-02-06 17:25:12 +01:00
|
|
|
02:05:44,0 --> 02:05:48,500
|
|
|
|
Okay, doesn't matter.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3444
|
2022-02-06 17:25:12 +01:00
|
|
|
02:05:48,500 --> 02:05:58,500
|
|
|
|
We can do the same thing for the last name Doe and we can basically say that this is now "last-name".
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3447
|
2022-02-06 17:25:12 +01:00
|
|
|
02:05:58,500 --> 02:05:06,500
|
|
|
|
Now we've added these two things in there now the problem with this is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3448
|
2022-02-06 17:25:12 +01:00
|
|
|
02:05:06,500 --> 02:06:04,500
|
|
|
|
if we just had attributes instead of objects is we don't really see that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3449
|
2022-02-06 17:25:12 +01:00
|
|
|
02:06:04,500 --> 02:06:07,500
|
|
|
|
"John" and "Doe" in this case are the first name and last name belong together.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3455
|
2022-02-06 17:25:12 +01:00
|
|
|
02:06:07,500 --> 02:06:11,500
|
|
|
|
So if I were to describe several people in the same event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3456
|
2022-02-06 17:25:12 +01:00
|
|
|
02:06:11,500 --> 02:06:18,500
|
|
|
|
you would have a list of first names and a list of last names with no connection between the two things
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3457
|
2022-02-06 17:25:12 +01:00
|
|
|
02:06:18,500 --> 02:06:24,500
|
|
|
|
so it's better to use objects in general whenever you're describing multiple aspects of the same thing.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3463
|
2022-02-06 17:25:12 +01:00
|
|
|
02:06:24,500 --> 02:06:27,500
|
|
|
|
Obviously if you just have a list of file hashes that you got from a feed
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3464
|
2022-02-06 17:25:12 +01:00
|
|
|
02:06:27,500 --> 02:06:30,500
|
|
|
|
and you just encode those and you don't have any other information with them
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3465
|
2022-02-06 17:25:12 +01:00
|
|
|
02:06:30,500 --> 02:06:33,500
|
|
|
|
you might as well just create flat attributes out of them
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3466
|
2022-02-06 17:25:12 +01:00
|
|
|
02:06:33,500 --> 02:06:36,500
|
|
|
|
because there is nothing else to describe from your perspective.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3471
|
2022-02-06 17:25:12 +01:00
|
|
|
02:06:36,880 --> 02:06:40,500
|
|
|
|
But even in that case it's arguable whether you don't want to start with an object
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3474
|
2022-02-06 17:25:12 +01:00
|
|
|
02:06:40,500 --> 02:06:44,0
|
|
|
|
from the get go but what we can do in this case if we did start with this way
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3476
|
2022-02-06 17:25:12 +01:00
|
|
|
02:06:44,0 --> 02:06:48,500
|
|
|
|
or if you receive information in this format or your tools parse the data out in this format is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3479
|
2022-02-06 17:25:12 +01:00
|
|
|
02:06:48,500 --> 02:06:51,500
|
|
|
|
you can select those two attributes by clicking the little check marks next
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3480
|
2022-02-06 17:25:12 +01:00
|
|
|
02:06:51,500 --> 02:06:57,500
|
|
|
|
or little tick boxes next to them and then clicking on "Group selected Attributes into an Object"
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3485
|
2022-02-06 17:25:12 +01:00
|
|
|
02:06:56,500 --> 02:07:01,500
|
|
|
|
and here MISP will propose, okay these are the different object templates
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3486
|
2022-02-06 17:25:12 +01:00
|
|
|
02:07:01,500 --> 02:07:05,500
|
|
|
|
that satisfy the list of attributes that you've selected,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3488
|
2022-02-06 17:25:12 +01:00
|
|
|
02:07:05,500 --> 02:07:09,500
|
|
|
|
there's a person object that we can use so let's just pick that one for now.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3492
|
2022-02-06 17:25:12 +01:00
|
|
|
02:07:09,500 --> 02:07:16,500
|
|
|
|
So here we see if we were to combine these two things they would be merged into an object
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3495
|
2022-02-06 17:25:12 +01:00
|
|
|
02:07:16,500 --> 02:07:24,500
|
|
|
|
that is fine with us we see first name will become the first name of the object,last name, the last name
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3499
|
2022-02-06 17:25:12 +01:00
|
|
|
02:07:24,500 --> 02:07:25,500
|
|
|
|
so let's merge it,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3500
|
2022-02-06 17:25:12 +01:00
|
|
|
02:07:28,960 --> 02:07:35,0
|
|
|
|
Now we basically have a person object, now we also know that this person that we're dealing with here
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3501
|
2022-02-06 17:25:12 +01:00
|
|
|
02:07:35,0 --> 02:07:38,0
|
|
|
|
is impersonating the teacher of the CEO's daughter
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3503
|
2022-02-06 17:25:12 +01:00
|
|
|
02:07:38,0 --> 02:07:42,500
|
|
|
|
so the impersonated person is a teacher of the CEO's daughter
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3506
|
2022-02-06 17:25:12 +01:00
|
|
|
02:07:42,500 --> 02:07:48,0
|
|
|
|
so we added the object and we also see that we can add just another text field.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3509
|
2022-02-06 17:25:12 +01:00
|
|
|
02:07:48,0 --> 02:07:51,500
|
|
|
|
Yeah, just text field works, where we can describe it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3510
|
2022-02-06 17:25:12 +01:00
|
|
|
02:07:51,500 --> 02:07:55,500
|
|
|
|
i just want to first disable the correlation because different {inaudible}
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3513
|
2022-02-06 17:25:12 +01:00
|
|
|
02:07:55,500 --> 02:07:56,500
|
|
|
|
Okay yeah sure.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3514
|
2022-02-06 17:25:12 +01:00
|
|
|
02:08:08,238 --> 02:08:12,500
|
|
|
|
Yeah that works and we just add a text, description of the identity of the person
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3516
|
2022-02-06 17:25:12 +01:00
|
|
|
02:08:12,500 --> 02:08:14,500
|
|
|
|
we can just say teacher of the ceo's daughter.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3518
|
2022-02-06 17:25:12 +01:00
|
|
|
02:08:14,500 --> 02:08:27,0
|
|
|
|
Okay, now we're done. We have now added the additional attribute
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3520
|
2022-02-06 17:25:12 +01:00
|
|
|
02:08:27,0 --> 02:08:30,500
|
|
|
|
and now we know what this object is actually about without having a description in there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3522
|
2022-02-06 17:25:12 +01:00
|
|
|
02:08:30,500 --> 02:08:34,500
|
|
|
|
but we still just have an email and a person described in here
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3524
|
2022-02-06 17:25:12 +01:00
|
|
|
02:08:34,500 --> 02:08:38,500
|
|
|
|
but we don't know anything else, we don't know that this email is spoofing to be that person
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3526
|
2022-02-06 17:25:12 +01:00
|
|
|
02:08:38,500 --> 02:08:40,500
|
|
|
|
so we should add a relationship between the two.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3528
|
2022-02-06 17:25:12 +01:00
|
|
|
02:08:40,500 --> 02:08:46,500
|
|
|
|
Mow for this we can switch over to the event graph view so that is a little bit further up.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3531
|
2022-02-06 17:25:12 +01:00
|
|
|
02:08:46,719 --> 02:08:50,500
|
|
|
|
This one allows us to create connected graphs out of our individual data points
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3533
|
2022-02-06 17:25:12 +01:00
|
|
|
02:08:50,500 --> 02:08:56,500
|
|
|
|
so we see that we have two unreferenced objects, so we explode that node by pressing x.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3536
|
2022-02-06 17:25:12 +01:00
|
|
|
02:08:56,500 --> 02:09:03,0
|
|
|
|
and we can draw an edge between those two nodes by clicking edit and add reference
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
3539
|
2022-02-06 17:25:12 +01:00
|
|
|
02:09:03,0 --> 02:09:07,500
|
|
|
|
and drawing a line between the two from the email to the person.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3542
|
2022-02-06 17:25:12 +01:00
|
|
|
02:09:07,500 --> 02:09:15,500
|
|
|
|
When you do, that MISP will propose a list of relationship types between these two different nodes.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3546
|
2022-02-06 17:25:12 +01:00
|
|
|
02:09:15,500 --> 02:09:20,500
|
|
|
|
There is also a custom one there so if you don't want to select anything from the list that is fine too
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3548
|
2022-02-06 17:25:12 +01:00
|
|
|
02:09:20,500 --> 02:09:26,500
|
|
|
|
but for now we can just use the "impersonates" relationship which already exists in the default library.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3552
|
2022-02-06 17:25:12 +01:00
|
|
|
02:09:26,500 --> 02:09:33,500
|
|
|
|
Just click on submit and now we have a relationship set between those two.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3554
|
2022-02-06 17:25:12 +01:00
|
|
|
02:09:33,500 --> 02:09:38,500
|
|
|
|
So we started telling our story by basically having a connected graph between these two points.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3557
|
2022-02-06 17:25:12 +01:00
|
|
|
02:09:37,520 --> 02:09:46,500
|
|
|
|
Now let's further look at our original email and see what else we can get out of the text from there.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3561
|
2022-02-06 17:25:12 +01:00
|
|
|
02:09:47,520 --> 02:09:52,500
|
|
|
|
We also see that the malicious file was contained in the email as well as an attachment
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3563
|
2022-02-06 17:25:12 +01:00
|
|
|
02:09:52,500 --> 02:09:55,500
|
|
|
|
So let's upload an attachment now to MISP.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3564
|
2022-02-06 17:25:12 +01:00
|
|
|
02:09:54,0 --> 02:09:59,500
|
|
|
|
I hope you have put in the text there or something because I forgot to {inaudible} it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3565
|
2022-02-06 17:25:12 +01:00
|
|
|
02:09:59,500 --> 02:10:02,500
|
|
|
|
{inaudible} Perfect .
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3567
|
2022-02-06 17:25:12 +01:00
|
|
|
02:10:02,500 --> 02:10:07,500
|
|
|
|
So as an attachment and this is where things become a little bit tricky.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3568
|
2022-02-06 17:25:12 +01:00
|
|
|
02:10:07,500 --> 02:10:12,500
|
|
|
|
There's a quick question there on the chat i'll just quickly answer that then we can get back to this.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3573
|
2022-02-06 17:25:12 +01:00
|
|
|
02:10:12,500 --> 02:10:13,500
|
|
|
|
Where can I create reference?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3574
|
2022-02-06 17:25:12 +01:00
|
|
|
02:10:13,500 --> 02:10:18,0
|
|
|
|
If you go above the attribute list there is an event graph button if you click on that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3575
|
2022-02-06 17:25:12 +01:00
|
|
|
02:10:18,0 --> 02:10:23,0
|
|
|
|
you get the event graph and on the top left side you click on edit and then add reference
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3577
|
2022-02-06 17:25:12 +01:00
|
|
|
02:10:23,0 --> 02:10:24,0
|
|
|
|
Like I can show it again now.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3580
|
2022-02-06 17:25:12 +01:00
|
|
|
02:10:24,0 --> 02:10:26,500
|
|
|
|
Yeah that's a bit better, yeah.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3581
|
2022-02-06 17:25:12 +01:00
|
|
|
02:10:26,500 --> 02:10:33,500
|
|
|
|
So you have this kind of gray bar there with event graph so you can basically collapse or expand it
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3583
|
2022-02-06 17:25:12 +01:00
|
|
|
02:10:33,500 --> 02:10:39,500
|
|
|
|
and then there you can select one of those reference objects you press x
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3589
|
2022-02-06 17:25:12 +01:00
|
|
|
02:10:39,500 --> 02:10:49,500
|
|
|
|
to expand all those reference objects then you can just select one object that you want to add
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3591
|
2022-02-06 17:25:12 +01:00
|
|
|
02:10:49,500 --> 02:10:53,500
|
|
|
|
and then you can edit, add the references and then you can add specific references.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3594
|
2022-02-06 17:25:12 +01:00
|
|
|
02:10:53,500 --> 02:10:57,500
|
|
|
|
In this case it doesn't make sense to make a second reference but that's basically how you do it
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3597
|
2022-02-06 17:25:12 +01:00
|
|
|
02:10:57,500 --> 02:11:01,500
|
|
|
|
then you select your relationship type and you can add your reference.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3599
|
|
|
|
02:11:01,279 --> 02:11:04,479
|
2022-02-06 17:25:12 +01:00
|
|
|
It's not the only way to do it, there's a, I would say current-based representation
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3602
|
2022-02-06 17:25:12 +01:00
|
|
|
02:11:06,78 --> 02:11:11,500
|
|
|
|
where you can do it, we can even show it so you have to go
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3604
|
2022-02-06 17:25:12 +01:00
|
|
|
02:11:11,500 --> 02:11:13,0
|
|
|
|
It's much more difficult to understand what happens.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3606
|
2022-02-06 17:25:12 +01:00
|
|
|
02:11:13,0 --> 02:11:19,0
|
|
|
|
Yeah, so so there the reference that you created through the event graph is represented here
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3608
|
2022-02-06 17:25:12 +01:00
|
|
|
02:11:19,0 --> 02:11:25,500
|
|
|
|
so you see that this object has a reference so from email to impersonate
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3612
|
2022-02-06 17:25:12 +01:00
|
|
|
02:11:25,500 --> 02:11:29,0
|
|
|
|
and here's the opposite relationship that even describes the "Referenced by"
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3613
|
2022-02-06 17:25:12 +01:00
|
|
|
02:11:29,0 --> 02:11:31,0
|
|
|
|
and you have the "Referenced by" on this object
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3614
|
2022-02-06 17:25:12 +01:00
|
|
|
02:11:28,960 --> 02:11:38,500
|
|
|
|
so another just mention is I think less, I would say {inaudible} and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3618
|
2022-02-06 17:25:12 +01:00
|
|
|
02:11:38,500 --> 02:11:40,0
|
|
|
|
but sometimes you just when you are in the object
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3619
|
2022-02-06 17:25:12 +01:00
|
|
|
02:11:40,0 --> 02:11:45,500
|
|
|
|
you just want to see if you have any reference or a sign and you can quickly see that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3622
|
2022-02-06 17:25:12 +01:00
|
|
|
02:11:48,500 --> 02:11:58,500
|
|
|
|
So let's add an attachment now and upload the sample that was included in the original email.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3625
|
2022-02-06 17:25:12 +01:00
|
|
|
02:11:58,500 --> 02:12:03,0
|
|
|
|
Sso we just click on add attachment we select the file that you want to upload.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3628
|
2022-02-06 17:25:12 +01:00
|
|
|
02:12:03,0 --> 02:12:06,500
|
|
|
|
yeah so for the attachment in MISP you have really two models,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3630
|
2022-02-06 17:25:12 +01:00
|
|
|
02:12:06,500 --> 02:12:08,0
|
|
|
|
you have the model that an attachment is basically something
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3631
|
2022-02-06 17:25:12 +01:00
|
|
|
02:12:08,0 --> 02:12:15,500
|
|
|
|
completely benign, safe and you can basically share it directly.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3635
|
2022-02-06 17:25:12 +01:00
|
|
|
02:12:13,118 --> 02:12:19,0
|
|
|
|
So for example you have attachment like reports and stuff like that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3637
|
2022-02-06 17:25:12 +01:00
|
|
|
02:12:19,0 --> 02:12:21,500
|
|
|
|
In our case what we want to share here,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3638
|
2022-02-06 17:25:12 +01:00
|
|
|
02:12:21,500 --> 02:12:30,500
|
|
|
|
it's a malicious sample so and that's I will take a sample somewhere.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3644
|
2022-02-06 17:25:12 +01:00
|
|
|
02:12:34,0 --> 02:12:42,500
|
|
|
|
Press on one {inaudible} interesting there {inaudible} windows executables
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3647
|
2022-02-06 17:25:12 +01:00
|
|
|
02:12:42,500 --> 02:12:45,0
|
|
|
|
and then you have to select if the sample is malicious
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3648
|
2022-02-06 17:25:12 +01:00
|
|
|
02:12:44,158 --> 02:12:48,0
|
|
|
|
if you don't do anything, what it will be, it will be something
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3649
|
2022-02-06 17:25:12 +01:00
|
|
|
02:12:48,0 --> 02:12:54,0
|
|
|
|
like saving report, a pdf report, something that's like supporting you in contextualization
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3654
|
2022-02-06 17:25:12 +01:00
|
|
|
02:12:54,0 --> 02:12:56,600
|
|
|
|
could be a screenshot for example things like that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3656
|
2022-02-06 17:25:12 +01:00
|
|
|
02:12:56,600 --> 02:13:00,500
|
|
|
|
But if you share a sample you have to select "Is a malware sample"
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3657
|
2022-02-06 17:25:12 +01:00
|
|
|
02:13:00,500 --> 02:13:05,0
|
|
|
|
because like that MISP will encrypt and hash a file
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3658
|
2022-02-06 17:25:12 +01:00
|
|
|
02:13:05,0 --> 02:13:09,500
|
|
|
|
so that means you have a zip file encrypted with a default password "infected"
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3663
|
2022-02-06 17:25:12 +01:00
|
|
|
02:13:08,719 --> 02:13:13,500
|
|
|
|
but I got to avoid classical mistake of clicking on a link
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3664
|
2022-02-06 17:25:12 +01:00
|
|
|
02:13:13,500 --> 02:13:17,0
|
|
|
|
executing binaries on your analysis machines and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3667
|
2022-02-06 17:25:12 +01:00
|
|
|
02:13:17,0 --> 02:13:21,500
|
|
|
|
you don't want to do that, so if it's malicious always click malware samples
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3670
|
2022-02-06 17:25:12 +01:00
|
|
|
02:13:21,500 --> 02:13:38,500
|
|
|
|
then you have one below "Advanced extraction", MISP can do a lot of things behind the scene
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3673
|
2022-02-06 17:25:12 +01:00
|
|
|
02:13:38,500 --> 02:13:33,500
|
|
|
|
when you receive a file, in this case it's a window portable executable files
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3676
|
2022-02-06 17:25:12 +01:00
|
|
|
02:13:33,500 --> 02:13:37,500
|
|
|
|
so we have particular advanced extraction for those files
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3677
|
2022-02-06 17:25:12 +01:00
|
|
|
02:13:37,500 --> 02:13:43,500
|
|
|
|
and we can expand completely the files including resources, code segment, and stuff like that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3679
|
2022-02-06 17:25:12 +01:00
|
|
|
02:13:44,0 --> 02:13:45,500
|
|
|
|
So I will upload the files.
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
3682
|
2022-02-06 17:25:12 +01:00
|
|
|
02:13:53,0 --> 02:13:57,0
|
|
|
|
Okay in this case this one was just like a very simple one.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3684
|
2022-02-06 17:25:12 +01:00
|
|
|
02:13:57,0 --> 02:14:00,500
|
|
|
|
So in this case, what do we have? We have an object
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3685
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:00,500 --> 02:14:05,500
|
|
|
|
with the file name, the size-in-bytes and then the hash file,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3686
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:01,279 --> 02:14:08,500
|
|
|
|
so automatically MISP will do the hashing of the different files
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3690
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:08,500 --> 02:14:12,0
|
|
|
|
the sample itself is attached so you can basically use it
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3691
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:12,0 --> 02:14:14,880
|
|
|
|
and some additional ones like ssdeep for example, mimetype are automatically extracted
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3695
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:18,880 --> 02:14:22,0
|
|
|
|
just maybe for the sake of it I will just take maybe another binary
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3696
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:22,0 --> 02:14:27,500
|
|
|
|
just for showing you what could happen with other binaries.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3697
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:27,500 --> 02:14:32,500
|
|
|
|
Maybe that's for later for different events so we don't have the objects in this one
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3701
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:32,500 --> 02:14:34,500
|
|
|
|
because it's easier to see for the graph
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3703
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:34,500 --> 02:14:35,0
|
|
|
|
That's fine too.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3704
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:35,0 --> 02:14:37,0
|
|
|
|
You can show it afterwards
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3705
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:37,0 --> 02:14:41,0
|
|
|
|
Yeah, okay so now we have this again this kind of object attached
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3707
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:41,0 --> 02:14:43,0
|
|
|
|
and there's a relationship to create obviously.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3708
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:43,0 --> 02:14:48,0
|
|
|
|
Indeed. So in this case the relationship is to the email itself so we know that the email contained
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3711
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:48,0 --> 02:14:55,500
|
|
|
|
this file so what we can do is we can just create relationship between the email and the file
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3714
|
2022-02-06 17:25:12 +01:00
|
|
|
02:14:54,479 --> 02:14:57,500
|
|
|
|
and see that email contain that file
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3716
|
2022-02-06 17:25:12 +01:00
|
|
|
02:15:00,500 --> 02:15:03,500
|
|
|
|
So you see, it it's again the same model.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3717
|
2022-02-06 17:25:12 +01:00
|
|
|
02:15:06,500 --> 02:15:08,500
|
2021-12-27 05:45:03 +01:00
|
|
|
contains
|
|
|
|
|
|
|
|
3719
|
2022-02-06 17:25:12 +01:00
|
|
|
02:15:15,0 --> 02:15:16,500
|
|
|
|
There we go.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3720
|
2022-02-06 17:25:12 +01:00
|
|
|
02:15:16,500 --> 02:15:19,500
|
|
|
|
So now what we can do is if you look further in the email
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3721
|
2022-02-06 17:25:12 +01:00
|
|
|
02:15:19,500 --> 02:15:21,0
|
|
|
|
we see that there is a bunch of other stuff still described
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3722
|
2022-02-06 17:25:12 +01:00
|
|
|
02:15:21,0 --> 02:15:25,500
|
|
|
|
so what we can do is we can just, now for exercise sake, just take
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3723
|
2022-02-06 17:25:12 +01:00
|
|
|
02:15:25,500 --> 02:15:31,0
|
|
|
|
at least the next few lines or the next paragraph
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3724
|
2022-02-06 17:25:12 +01:00
|
|
|
02:15:31,0 --> 02:15:35,500
|
|
|
|
and drop the entire paragraph into something called the free text importer.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3729
|
2022-02-06 17:25:12 +01:00
|
|
|
02:15:35,500 --> 02:15:39,500
|
|
|
|
What this will do is it will try to parse this text blob
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3730
|
2022-02-06 17:25:12 +01:00
|
|
|
02:15:39,500 --> 02:15:43,0
|
|
|
|
and it will try to extract anything that looks like an indicator out of that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3733
|
2022-02-06 17:25:12 +01:00
|
|
|
02:15:43,0 --> 02:15:47,500
|
|
|
|
So this is another method of basically entering attribute into MISP.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3737
|
2022-02-06 17:25:12 +01:00
|
|
|
02:15:47,500 --> 02:15:52,500
|
|
|
|
So "Freetext Import", we just paste it in there and we just hit "Submit".
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3739
|
2022-02-06 17:25:12 +01:00
|
|
|
02:15:54,000 --> 02:15:57,500
|
|
|
|
So MISP will tell us in this case it didn't extract everything actually,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3741
|
2022-02-06 17:25:12 +01:00
|
|
|
02:15:57,679 --> 02:16:00,500
|
|
|
|
so we need to still go back to it and refined a bit more
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3742
|
2022-02-06 17:25:12 +01:00
|
|
|
02:16:00,500 --> 02:16:02,500
|
|
|
|
but it extracted some of those things that were in there already.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3745
|
2022-02-06 17:25:12 +01:00
|
|
|
02:16:03,118 --> 02:16:05,500
|
|
|
|
So that's fine, we can just already add those to the event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3747
|
2022-02-06 17:25:12 +01:00
|
|
|
02:16:08,0 --> 02:16:13,500
|
|
|
|
so how does it work behind the scenes is we have a bunch of regex in MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3748
|
2022-02-06 17:25:12 +01:00
|
|
|
02:16:13,500 --> 02:16:18,0
|
|
|
|
automatically extracting information from natural text, it's one way to do it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3752
|
2022-02-06 17:25:12 +01:00
|
|
|
02:16:18,0 --> 02:16:21,500
|
|
|
|
There's another tool for doing it which is part of the event report
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3755
|
2022-02-06 17:25:12 +01:00
|
|
|
02:16:21,500 --> 02:16:26,500
|
|
|
|
but it's usually a quick way to automatically extract information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3756
|
2022-02-06 17:25:12 +01:00
|
|
|
02:16:26,500 --> 02:16:27,500
|
|
|
|
and to see if it's already known for example.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3758
|
2022-02-06 17:25:12 +01:00
|
|
|
02:16:28,500 --> 02:16:34,500
|
|
|
|
So what we see here already is that evil provider was basically,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3759
|
2022-02-06 17:25:12 +01:00
|
|
|
02:16:31,198 --> 02:16:40,500
|
|
|
|
according to the email text, the place that was used to download the secondary payload from
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3760
|
2022-02-06 17:25:12 +01:00
|
|
|
02:16:40,500 --> 02:16:46,0
|
|
|
|
so we can take evil provider and we also know that we got an IPv6 address to it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3766
|
2022-02-06 17:25:12 +01:00
|
|
|
02:16:44,558 --> 02:16:49,500
|
|
|
|
So we're going to add that to it as well and convert this into an object again.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3769
|
2022-02-06 17:25:12 +01:00
|
|
|
02:16:51,0 --> 02:16:54,500
|
|
|
|
So we're going to to just select that one convert to object
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3770
|
2022-02-06 17:25:12 +01:00
|
|
|
02:16:54,500 --> 02:17:00,0
|
|
|
|
and the object that we're going to convert it to is going to be a "URL" object.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3774
|
2022-02-06 17:25:12 +01:00
|
|
|
02:17:01,599 --> 02:17:04,500
|
|
|
|
Yep. all the way down there. Perfect.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3775
|
2022-02-06 17:25:12 +01:00
|
|
|
02:17:04,799 --> 02:17:08,0
|
|
|
|
Let's just do the conversion and then we edit the object afterwards
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3776
|
2022-02-06 17:25:12 +01:00
|
|
|
02:17:08,0 --> 02:17:10,500
|
|
|
|
and we add the additional information that we have about it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3779
|
2022-02-06 17:25:12 +01:00
|
|
|
02:17:11,500 --> 02:17:25,500
|
|
|
|
So we have an IPv6 that it resolves to. We also have a port.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3780
|
2022-02-06 17:25:12 +01:00
|
|
|
02:17:25,500 --> 02:17:32,500
|
|
|
|
So once we're done with that IP destination, perfect.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3784
|
2022-02-06 17:25:12 +01:00
|
|
|
02:17:32,500 --> 02:17:41,500
|
|
|
|
We can also add the port. It was communicating on port 443.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3786
|
2022-02-06 17:25:12 +01:00
|
|
|
02:17:41,500 --> 02:17:51,500
|
|
|
|
and again everything i'm currently doing there can be done through the API obviously.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3788
|
2022-02-06 17:25:12 +01:00
|
|
|
02:17:51,500 --> 02:17:56,500
|
|
|
|
Yeah and and finally we also have a domain evilprovider.com
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3790
|
2022-02-06 17:25:12 +01:00
|
|
|
02:18:03,0 --> 02:18:07,500
|
|
|
|
now let's deal with referencing this to the other objects later on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3792
|
2022-02-06 17:25:12 +01:00
|
|
|
02:18:07,500 --> 02:18:12,500
|
|
|
|
We can still still add the additional information that we have in there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3795
|
2022-02-06 17:25:12 +01:00
|
|
|
02:18:12,500 --> 02:18:14,500
|
|
|
|
and then we do the linking afterwards.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3796
|
2022-02-06 17:25:12 +01:00
|
|
|
02:18:14,500 --> 02:18:16,500
|
|
|
|
Again, we have the same problem here on this
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3797
|
2022-02-06 17:25:12 +01:00
|
|
|
02:18:16,500 --> 02:18:20,500
|
|
|
|
because for example you see that the comment has the port
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3799
|
2022-02-06 17:25:12 +01:00
|
|
|
02:18:20,500 --> 02:18:24,0
|
|
|
|
so that means we can just convert it as an object again.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3800
|
2022-02-06 17:25:12 +01:00
|
|
|
02:18:24,0 --> 02:18:26,500
|
|
|
|
Yeah and the IP belongs to that one as well by the way
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3801
|
2022-02-06 17:25:12 +01:00
|
|
|
02:18:26,500 --> 02:18:28,500
|
|
|
|
Okay great, it's even better.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3802
|
2022-02-06 17:25:12 +01:00
|
|
|
02:18:28,500 --> 02:18:30,500
|
|
|
|
Yeah exactly.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3803
|
2022-02-06 17:25:12 +01:00
|
|
|
02:18:30,500 --> 02:18:33,500
|
|
|
|
Just my screen that is a bit small. Okay.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3805
|
2022-02-06 17:25:12 +01:00
|
|
|
02:18:40,0 --> 02:18:42,500
|
|
|
|
So in this case, it's again a url.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3806
|
2022-02-06 17:25:12 +01:00
|
|
|
02:18:48,0 --> 02:18:54,500
|
|
|
|
And the things that we have this time the port is actually a high port.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3808
|
2022-02-06 17:25:12 +01:00
|
|
|
02:18:54,500 --> 02:18:59,500
|
|
|
|
So while in the other one we do not correlate on on the port because port 443 is common
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3811
|
2022-02-06 17:25:12 +01:00
|
|
|
02:18:59,500 --> 02:19:03,500
|
|
|
|
this is one of those ports that we might want to correlate on already.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3813
|
2022-02-06 17:25:12 +01:00
|
|
|
02:19:03,500 --> 02:19:06,500
|
|
|
|
So we don't want to disable correlation for this one.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3815
|
2022-02-06 17:25:12 +01:00
|
|
|
02:19:09,840 --> 02:19:15,500
|
|
|
|
Where as for the other one we we should disable the correlation for the other port 443.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3819
|
2022-02-06 17:25:12 +01:00
|
|
|
02:19:21,0 --> 02:19:26,500
|
|
|
|
Okay. Now the other thing that we have at this point is we have a secondary sample
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3821
|
2022-02-06 17:25:12 +01:00
|
|
|
02:19:26,500 --> 02:19:30,0
|
|
|
|
so if you have a second one that you can upload now.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3822
|
2022-02-06 17:25:12 +01:00
|
|
|
02:19:30,0 --> 02:19:36,500
|
|
|
|
Yeah I just just add the domain so I get {inaudible}. Okay.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3824
|
2022-02-06 17:25:12 +01:00
|
|
|
02:19:36,500 --> 02:19:39,500
|
|
|
|
so what do you want {inaudible}
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3825
|
2022-02-06 17:25:12 +01:00
|
|
|
02:19:39,500 --> 02:19:44,500
|
|
|
|
So we still have another file to update and we have a CVE that was also mentioned in the email.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3828
|
2022-02-06 17:25:12 +01:00
|
|
|
02:19:44,500 --> 02:19:51,0
|
|
|
|
Okay. CVE is an interesting one, we have single attributes for CVE
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3830
|
2022-02-06 17:25:12 +01:00
|
|
|
02:19:51,0 --> 02:19:53,500
|
|
|
|
but sometimes you want to have some more information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3831
|
2022-02-06 17:25:12 +01:00
|
|
|
02:19:53,500 --> 02:19:57,500
|
|
|
|
so what you could do there is to create a simple attribute
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3832
|
2022-02-06 17:25:12 +01:00
|
|
|
02:19:57,500 --> 02:20:01,500
|
|
|
|
so the CVE is "Payload delivery" in this case.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3836
|
2022-02-06 17:25:12 +01:00
|
|
|
02:20:02,719 --> 02:20:07,500
|
|
|
|
We have "Type" which is "Vulnerability" and usually a "Vulnerability" is defined by CVE
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3838
|
2022-02-06 17:25:12 +01:00
|
|
|
02:20:07,500 --> 02:20:13,500
|
|
|
|
you can use other value but the best practice is the obviously to use CVE.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3841
|
2022-02-06 17:25:12 +01:00
|
|
|
02:20:13,500 --> 02:20:19,500
|
|
|
|
It's a very old CVE, those kind of attackers are always reusing those kind of old things
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3843
|
2022-02-06 17:25:12 +01:00
|
|
|
02:20:19,500 --> 02:20:23,500
|
|
|
|
but you know, it works. You know people never patch their Windows.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3846
|
2022-02-06 17:25:12 +01:00
|
|
|
02:20:23,500 --> 02:20:26,0
|
|
|
|
This one is interesting because you know it was exploited
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3847
|
2022-02-06 17:25:12 +01:00
|
|
|
02:20:26,0 --> 02:20:33,500
|
|
|
|
so I would add the IDS flag because it may be interesting to look into your system for additional ones.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3851
|
2022-02-06 17:25:12 +01:00
|
|
|
02:20:33,500 --> 02:20:35,0
|
|
|
|
So in this case, what do we have?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3852
|
2022-02-06 17:25:12 +01:00
|
|
|
02:20:35,0 --> 02:20:41,500
|
|
|
|
We have again, a single attribute, which is not the nice thing that you want to have
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3853
|
2022-02-06 17:25:12 +01:00
|
|
|
02:20:41,500 --> 02:20:45,500
|
|
|
|
is basically you want to have as much context as you want for those kind of investigation.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3857
|
2022-02-06 17:25:12 +01:00
|
|
|
02:20:45,500 --> 02:20:52,500
|
|
|
|
Luckily on this instance, we have one of those expansion modules
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3860
|
2022-02-06 17:25:12 +01:00
|
|
|
02:20:52,500 --> 02:20:56,500
|
|
|
|
and why the "CVE Advanced" is empty, that is quite interesting.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3861
|
2022-02-06 17:25:12 +01:00
|
|
|
02:20:56,500 --> 02:21:01,500
|
|
|
|
Ok, great. So and then you have some additional information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3862
|
2022-02-06 17:25:12 +01:00
|
|
|
02:21:01,500 --> 02:21:07,500
|
|
|
|
in this case we have some description, so what I can do in this in this one is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3866
|
2022-02-06 17:25:12 +01:00
|
|
|
02:21:07,500 --> 02:21:13,0
|
|
|
|
so you see that we have either the overlay thing
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3867
|
2022-02-06 17:25:12 +01:00
|
|
|
02:21:13,0 --> 02:21:17,0
|
|
|
|
so in MISP modules, someone was asking about extension of MISP.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3870
|
2022-02-06 17:25:12 +01:00
|
|
|
02:21:17,0 --> 02:21:20,500
|
|
|
|
This is one way. You have this overlay things where you can basically just do expansions
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3873
|
2022-02-06 17:25:12 +01:00
|
|
|
02:21:20,500 --> 02:21:23,500
|
|
|
|
and see okay contextual information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3874
|
2022-02-06 17:25:12 +01:00
|
|
|
02:21:23,500 --> 02:21:27,500
|
|
|
|
but sometimes you just want to have a bit more than just contextual information.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3876
|
2022-02-06 17:25:12 +01:00
|
|
|
02:21:27,500 --> 02:21:33,500
|
|
|
|
You want to have the associated object there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3878
|
2022-02-06 17:25:12 +01:00
|
|
|
02:21:31,200 --> 02:21:39,500
|
|
|
|
so there you have this kind of explosion there and you can add the enrichment
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3881
|
2022-02-06 17:25:12 +01:00
|
|
|
02:21:39,500 --> 02:21:41,500
|
|
|
|
I'll give a try on that one
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3883
|
2022-02-06 17:25:12 +01:00
|
|
|
02:21:41,500 --> 02:21:45,500
|
|
|
|
Okay great. So there's something wrong on this machine
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3884
|
2022-02-06 17:25:12 +01:00
|
|
|
02:21:45,500 --> 02:21:51,500
|
|
|
|
That's great. I'll take the other one but this is not an object but that's fine we can just like...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3887
|
2022-02-06 17:25:12 +01:00
|
|
|
02:21:51,500 --> 02:21:57,0
|
|
|
|
Yeah, we got some attribute in this case so we have basically the description
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3890
|
2022-02-06 17:25:12 +01:00
|
|
|
02:21:57,0 --> 02:22:04,500
|
|
|
|
that coming from the enrichment and what we can do is to then make an object called "Vulnerability"
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3894
|
2022-02-06 17:25:12 +01:00
|
|
|
02:22:05,520 --> 02:22:09,500
|
|
|
|
and "id", it's not a "credit" in this case is the "description"
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3896
|
2022-02-06 17:25:12 +01:00
|
|
|
02:22:09,500 --> 02:22:15,500
|
|
|
|
and make an object of it. Usually you should have a full expansion there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3898
|
2022-02-06 17:25:12 +01:00
|
|
|
02:22:15,500 --> 02:22:20,500
|
|
|
|
but I didn't test it on the training instance maybe something is broken on that instance.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3901
|
2022-02-06 17:25:12 +01:00
|
|
|
02:22:20,500 --> 02:22:25,500
|
|
|
|
Okay so now what do we have is more contextual information.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3904
|
2022-02-06 17:25:12 +01:00
|
|
|
02:22:27,500 --> 02:22:30,500
|
|
|
|
We start with a story and we see that we have an email we have a first url,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3905
|
2022-02-06 17:25:12 +01:00
|
|
|
02:22:30,500 --> 02:22:33,500
|
|
|
|
a second one which is a download and a specific CVE.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3907
|
2022-02-06 17:25:12 +01:00
|
|
|
02:22:33,500 --> 02:22:36,0
|
|
|
|
So maybe now we can go back to the...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3908
|
2022-02-06 17:25:12 +01:00
|
|
|
02:22:36,0 --> 02:22:40,500
|
|
|
|
We still miss one thing which was a secondary file that was downloaded.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3909
|
|
|
|
02:22:38,79 --> 02:22:42,239
|
|
|
|
|
|
|
|
3910
|
2022-02-06 17:25:12 +01:00
|
|
|
02:22:40,500 --> 02:22:43,500
|
|
|
|
Oh okay. The secondary files, yes.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3912
|
2022-02-06 17:25:12 +01:00
|
|
|
02:22:43,500 --> 02:22:51,500
|
|
|
|
Yeah. So according to story what happens was the initial sample was when executed
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3915
|
2022-02-06 17:25:12 +01:00
|
|
|
02:22:51,500 --> 02:22:55,500
|
|
|
|
was downloading a secondary sample and that one was basically
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3919
|
2022-02-06 17:25:12 +01:00
|
|
|
02:22:55,500 --> 02:23:00,500
|
|
|
|
then used to exfiltrate data from from the system.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3920
|
2022-02-06 17:25:12 +01:00
|
|
|
02:23:00,719 --> 02:23:07,0
|
|
|
|
Yes, so this was a {inaudible} malicious file okay then I will add...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
3923
|
2022-02-06 17:25:12 +01:00
|
|
|
02:23:07,0 --> 02:23:12,0
|
|
|
|
Yeah just another file and we just pretend it's the one that we were supposed to use.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3926
|
2022-02-06 17:25:12 +01:00
|
|
|
02:23:12,0 --> 02:23:19,0
|
|
|
|
Why is this one makes sense, it's an Emotet one {inaudible}, that makes sense.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3930
|
2022-02-06 17:25:12 +01:00
|
|
|
02:23:21,0 --> 02:23:24,0
|
|
|
|
so now we have all these different objects in our event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3931
|
2022-02-06 17:25:12 +01:00
|
|
|
02:23:24,0 --> 02:23:26,0
|
|
|
|
and it's time to build the story out of it as Alex has mentioned.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3932
|
2022-02-06 17:25:12 +01:00
|
|
|
02:23:26,0 --> 02:23:29,500
|
|
|
|
So it's time to go back to our event graph.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3935
|
2022-02-06 17:25:12 +01:00
|
|
|
02:23:34,0 --> 02:23:38,500
|
|
|
|
And basically so far the story is that we got an email.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3938
|
2022-02-06 17:25:12 +01:00
|
|
|
02:23:38,500 --> 02:23:44,500
|
|
|
|
The email was impersonating a person and we basically got a primary sample out of it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3939
|
2022-02-06 17:25:12 +01:00
|
|
|
02:23:44,500 --> 02:23:52,500
|
|
|
|
That primary sample then reaches out to evilprovider.com to download a secondary sample.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3942
|
2022-02-06 17:25:12 +01:00
|
|
|
02:23:52,500 --> 02:24:03,500
|
|
|
|
So we have a relationship between the file which "downloads-from". "downloads-from" yeah.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3946
|
2022-02-06 17:25:12 +01:00
|
|
|
02:24:03,500 --> 02:24:05,500
|
|
|
|
Perfect.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3947
|
2022-02-06 17:25:12 +01:00
|
|
|
02:24:05,500 --> 02:24:12,500
|
|
|
|
from "evilprovider" and then "evilprovider" downloads the secondary sample
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3950
|
2022-02-06 17:25:12 +01:00
|
|
|
02:24:19,0 --> 02:24:40,0
|
|
|
|
which is in this case "index.html.1" and this one then exfiltrates to another evilprovider url.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3953
|
2022-02-06 17:25:12 +01:00
|
|
|
02:24:51,0 --> 02:24:55,500
|
|
|
|
Now there's one thing we missed in the story here is that the first one try
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3955
|
2022-02-06 17:25:12 +01:00
|
|
|
02:24:55,500 --> 02:25:59,0
|
|
|
|
so in this case "trilog.exe" was actually abusing the CVE that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3956
|
2022-02-06 17:25:12 +01:00
|
|
|
02:25:59,0 --> 02:25:08,500
|
|
|
|
that Alex has already expanded so we have an abuser's relationship from "trilog.exe" to vulnerability.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3961
|
2022-02-06 17:25:12 +01:00
|
|
|
02:25:14,0 --> 02:25:17,0
|
|
|
|
So and once we're done with this we already see the entire story in this graph.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3963
|
2022-02-06 17:25:12 +01:00
|
|
|
02:25:17,0 --> 02:25:22,500
|
|
|
|
So even if you have no idea about what happened in the report and you don't read the original report
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3966
|
2022-02-06 17:25:12 +01:00
|
|
|
02:25:22,500 --> 02:25:29,0
|
|
|
|
by just looking at this graph you can clearly read it out in simple sentences.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3969
|
2022-02-06 17:25:12 +01:00
|
|
|
02:25:29,0 --> 02:25:33,500
|
|
|
|
We see email impersonator a person, John. Email contains "trilog.exe"
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3970
|
2022-02-06 17:25:12 +01:00
|
|
|
02:25:31,520 --> 02:25:40,500
|
|
|
|
and that exploits the vulnerability. Downloads from evilprovider.com, "index.html.1".
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3974
|
2022-02-06 17:25:12 +01:00
|
|
|
02:25:40,500 --> 02:25:43,0
|
|
|
|
which exfiltrates to a url.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3975
|
2022-02-06 17:25:12 +01:00
|
|
|
02:25:43,0 --> 02:25:48,500
|
|
|
|
So it's a very simple story to comprehend without us knowing the original data information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3978
|
2022-02-06 17:25:12 +01:00
|
|
|
02:25:48,500 --> 02:25:53,500
|
|
|
|
and without us having even having to look at the individual indicators further below.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3982
|
2022-02-06 17:25:12 +01:00
|
|
|
02:25:53,500 --> 02:25:58,500
|
|
|
|
So this is when we're talking about information sharing we're basically sharing on two layers.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3985
|
2022-02-06 17:25:12 +01:00
|
|
|
02:25:59,40 --> 02:26:03,500
|
|
|
|
One of the layers is sharing with machines so informing an IDS about things to alert on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3988
|
2022-02-06 17:25:12 +01:00
|
|
|
02:26:04,79 --> 02:26:06,500
|
|
|
|
and at the same time we're sharing with analysts
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3989
|
2022-02-06 17:25:12 +01:00
|
|
|
02:26:06,500 --> 02:26:09,500
|
|
|
|
that want to really understand what the threat actor was doing in this case
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3992
|
2022-02-06 17:25:12 +01:00
|
|
|
02:26:09,500 --> 02:26:11,500
|
|
|
|
and what happened during the incident.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3993
|
2022-02-06 17:25:12 +01:00
|
|
|
02:26:11,500 --> 02:26:17,500
|
|
|
|
However at this stage, we have described our event but we're still missing something at this point.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3996
|
2022-02-06 17:25:12 +01:00
|
|
|
02:26:17,500 --> 02:26:23,0
|
|
|
|
We still haven't actually contextualized the information with everything else that we know about it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
3999
|
2022-02-06 17:25:12 +01:00
|
|
|
02:26:23,0 --> 02:26:30,0
|
|
|
|
So we have vocabularies at our disposal, we have the ATTACK matrix at our disposal
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4002
|
2022-02-06 17:25:12 +01:00
|
|
|
02:26:30,0 --> 02:26:32,0
|
|
|
|
So let's start going through the individual attributes
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4004
|
2022-02-06 17:25:12 +01:00
|
|
|
02:26:32,0 --> 02:26:35,500
|
|
|
|
and let's start to attach those different labels to the data
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4007
|
2022-02-06 17:25:12 +01:00
|
|
|
02:26:35,500 --> 02:26:42,500
|
|
|
|
so first of all if we look at perhaps, which one should we start with?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4010
|
2022-02-06 17:25:12 +01:00
|
|
|
02:26:42,500 --> 02:26:45,500
|
|
|
|
Let's not do everything. Let's look at the original email for example.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4012
|
2022-02-06 17:25:12 +01:00
|
|
|
02:26:45,500 --> 02:26:48,500
|
|
|
|
We know that the original email deals with phishing.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4014
|
2022-02-06 17:25:12 +01:00
|
|
|
02:26:48,500 --> 02:26:51,500
|
|
|
|
Now ATTACK has a pattern that describes phishing
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4015
|
2022-02-06 17:25:12 +01:00
|
|
|
02:26:51,500 --> 02:26:57,500
|
|
|
|
so we can just attach the galaxy cluster of attack to the attributes in there.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4018
|
2022-02-06 17:25:12 +01:00
|
|
|
02:26:57,500 --> 02:27:01,500
|
|
|
|
So we use cluster yeah.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4019
|
2022-02-06 17:25:12 +01:00
|
|
|
02:27:01,500 --> 02:27:06,0
|
|
|
|
and we can just use ATTACK. mitre-attack, perfect.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4020
|
2022-02-06 17:25:12 +01:00
|
|
|
02:27:06,0 --> 02:27:09,500
|
|
|
|
and we can click on "Attack Pattern" then we get the attack matrix
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4023
|
2022-02-06 17:25:12 +01:00
|
|
|
02:27:11,200 --> 02:27:17,500
|
|
|
|
and here we can select "Phishing". It should be in...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4026
|
2022-02-06 17:25:12 +01:00
|
|
|
02:27:18,500 --> 02:27:20,500
|
|
|
|
Yeah there it is perfect.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4027
|
2022-02-06 17:25:12 +01:00
|
|
|
02:27:20,500 --> 02:27:28,500
|
|
|
|
So we attach it. We refresh and there we see it is now attached to the attribute
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4030
|
2022-02-06 17:25:12 +01:00
|
|
|
02:27:28,500 --> 02:27:32,500
|
|
|
|
and if we generate a heat map now out of the events if we scroll up.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4033
|
2022-02-06 17:25:12 +01:00
|
|
|
02:27:32,500 --> 02:27:36,500
|
|
|
|
We have an attack matrix view next to the event graph.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4035
|
2022-02-06 17:25:12 +01:00
|
|
|
02:27:36,500 --> 02:27:43,0
|
|
|
|
If we click on that one now we now see that as a first overview already we know
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4036
|
2022-02-06 17:25:12 +01:00
|
|
|
02:27:43,0 --> 02:27:46,500
|
|
|
|
without looking at any of the details we see that we're dealing with phishing here.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4040
|
2022-02-06 17:25:12 +01:00
|
|
|
02:27:46,500 --> 02:27:49,500
|
|
|
|
So this is one of the attack patterns that we've described.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4041
|
2022-02-06 17:25:12 +01:00
|
|
|
02:27:49,500 --> 02:27:52,0
|
|
|
|
let's see what other attack patterns from attack we can describe
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4043
|
2022-02-06 17:25:12 +01:00
|
|
|
02:27:52,0 --> 02:27:55,0
|
|
|
|
You also see that there is automated exfiltration happening.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4046
|
2022-02-06 17:25:12 +01:00
|
|
|
02:27:55,0 --> 02:28:00,0
|
|
|
|
So if we go to the secondary url, so another evilprovider.com.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4049
|
2022-02-06 17:25:12 +01:00
|
|
|
02:28:03,0 --> 02:28:05,500
|
|
|
|
We can attach the pattern there as well.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4050
|
2022-02-06 17:25:12 +01:00
|
|
|
02:28:05,500 --> 02:28:10,500
|
|
|
|
now we can choose to do a single attribute what we're doing or we can just select all 4
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
4053
|
2022-02-06 17:25:12 +01:00
|
|
|
02:28:10,500 --> 02:28:13,500
|
|
|
|
and attach the cluster to all 4 for let's just do one for now, it's enough.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4056
|
2022-02-06 17:25:12 +01:00
|
|
|
02:28:15,500 --> 02:28:24,0
|
|
|
|
Watch out it's... Yeah, perfect. And just pick "Automated Exfiltration".
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4058
|
2022-02-06 17:25:12 +01:00
|
|
|
02:28:24,0 --> 02:28:27,0
|
|
|
|
It's the first one on the... Yeah.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4060
|
2022-02-06 17:25:12 +01:00
|
|
|
02:28:30,0 --> 02:28:35,500
|
|
|
|
Okay so now we've attached some attack patterns, we could attach it to the sample as well.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4063
|
2022-02-06 17:25:12 +01:00
|
|
|
02:28:35,500 --> 02:28:39,0
|
|
|
|
What the sample is doing but we're not going to go through all that effort
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4065
|
2022-02-06 17:25:12 +01:00
|
|
|
02:28:39,0 --> 02:28:43,500
|
|
|
|
Let's look at some type of contextualization for example...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4069
|
2022-02-06 17:25:12 +01:00
|
|
|
02:28:47,120 --> 02:28:47,500
|
|
|
|
maybe this then it's a matter of taste again regarding
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4073
|
2022-02-06 17:25:12 +01:00
|
|
|
02:28:47,500 --> 02:28:51,500
|
|
|
|
at which level you want to attach the galaxy
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4074
|
2022-02-06 17:25:12 +01:00
|
|
|
02:28:51,500 --> 02:28:58,500
|
|
|
|
there is really the topic is a matter of phishing at a global level, usually we can add a galaxy there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4075
|
2022-02-06 17:25:12 +01:00
|
|
|
02:28:58,500 --> 02:29:03,500
|
|
|
|
and then for example add MITRE ATTACK directly there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4076
|
2022-02-06 17:25:12 +01:00
|
|
|
02:29:03,500 --> 02:29:09,500
|
|
|
|
and select the pattern phishing then the techniques there directly.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4078
|
2022-02-06 17:25:12 +01:00
|
|
|
02:29:09,500 --> 02:29:14,500
|
|
|
|
so you have different options usually we recommend to make it at attribute level
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4081
|
2022-02-06 17:25:12 +01:00
|
|
|
02:29:14,500 --> 02:29:21,500
|
|
|
|
but in some case you don't even know which attribute level it applies then you select the event level.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4084
|
2022-02-06 17:25:12 +01:00
|
|
|
02:29:21,500 --> 02:29:26,500
|
|
|
|
Exactly. So that's indeed a good point if you know that the entire chain of what you're describing
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4087
|
2022-02-06 17:25:12 +01:00
|
|
|
02:29:26,500 --> 02:29:34,500
|
|
|
|
references to a single contextualization, be it label, be it a galaxy cluster then indeed
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4090
|
2022-02-06 17:25:12 +01:00
|
|
|
02:29:34,500 --> 02:29:39,500
|
|
|
|
what we assume is anything that you label on the event level is inherited by all
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4091
|
2022-02-06 17:25:12 +01:00
|
|
|
02:29:39,500 --> 02:29:43,500
|
|
|
|
data contained within unless explicitly overwritten by the opposite tag basically.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4095
|
2022-02-06 17:25:12 +01:00
|
|
|
02:29:43,500 --> 02:29:51,500
|
|
|
|
So indeed that's the case. In this case we're kind of in a weird situation
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4096
|
2022-02-06 17:25:12 +01:00
|
|
|
02:29:51,500 --> 02:29:55,500
|
|
|
|
because we're describing the full chain of the attack which includes initial phishing attempt
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4100
|
2022-02-06 17:25:12 +01:00
|
|
|
02:29:55,500 --> 02:29:59,500
|
|
|
|
but also includes the secondary payload and the exfiltration and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4103
|
2022-02-06 17:25:12 +01:00
|
|
|
02:29:59,500 --> 02:30:03,500
|
|
|
|
and if we do this on the attribute level as oppose to the event level
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
4106
|
2022-02-06 17:25:12 +01:00
|
|
|
02:30:03,500 --> 02:30:08,0
|
|
|
|
then you're really only describing which part deals with the phishing
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4107
|
2022-02-06 17:25:12 +01:00
|
|
|
02:30:08,0 --> 02:30:11,500
|
|
|
|
which part deals with the actual exfiltration and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4111
|
2022-02-06 17:25:12 +01:00
|
|
|
02:30:11,500 --> 02:30:16,0
|
|
|
|
So this is really up to you. What we generally recommend is don't just do it on the event level.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4114
|
2022-02-06 17:25:12 +01:00
|
|
|
02:30:16,0 --> 02:30:19,500
|
|
|
|
So if you're describing more concepts in a single event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4115
|
2022-02-06 17:25:12 +01:00
|
|
|
02:30:19,500 --> 02:30:22,0
|
|
|
|
make sure that you contextualize individual parts of it
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4118
|
2022-02-06 17:25:12 +01:00
|
|
|
02:30:22,0 --> 02:30:26,500
|
|
|
|
because one of one of the things that we use these labels for as well is Searches.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
4120
|
2022-02-06 17:25:12 +01:00
|
|
|
02:30:26,500 --> 02:30:29,500
|
|
|
|
so if I were to search for all indicators that relate to phishing
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4121
|
2022-02-06 17:25:12 +01:00
|
|
|
02:30:29,500 --> 02:30:36,500
|
|
|
|
I might not want to get the secondary payloads artifacts included in that response.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4125
|
2022-02-06 17:25:12 +01:00
|
|
|
02:30:35,920 --> 02:30:40,500
|
|
|
|
because that was just the initial vector of getting into the network of the victim
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4128
|
2022-02-06 17:25:12 +01:00
|
|
|
02:30:40,500 --> 02:30:44,500
|
|
|
|
whatever happens afterwards is not directly related to the phishing.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4130
|
2022-02-06 17:25:12 +01:00
|
|
|
02:30:44,500 --> 02:30:47,500
|
|
|
|
So keep that in mind as well. something else...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4132
|
2022-02-06 17:25:12 +01:00
|
|
|
02:30:47,500 --> 02:30:52,500
|
|
|
|
Yeah so just something that you have to keep in mind too it's about
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4133
|
2022-02-06 17:25:12 +01:00
|
|
|
02:30:52,500 --> 02:30:58,500
|
|
|
|
which classification to choose or which contextualization source you want to use.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
4138
|
|
|
|
02:30:58,500 --> 02:31:01,500
|
|
|
|
On this instance, we have already a lot of things enabled
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
4139
|
|
|
|
02:31:01,500 --> 02:31:07,500
|
|
|
|
and if for example you go for taxonomy. You have a lot of taxonomy that is describing phishing.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
4143
|
|
|
|
02:31:07,500 --> 02:31:15,500
|
|
|
|
For example you have even a complete taxonomy about the kind of phishing you have and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4147
|
2022-02-06 17:25:12 +01:00
|
|
|
02:31:15,500 --> 02:31:20,500
|
|
|
|
So when you install your MISP instance and you start to make it operational
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4149
|
2022-02-06 17:25:12 +01:00
|
|
|
02:31:20,500 --> 02:31:24,500
|
|
|
|
you really have to decide what kind of taxonomy you want to use
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4151
|
2022-02-06 17:25:12 +01:00
|
|
|
02:31:24,500 --> 02:31:29,500
|
|
|
|
in this case we have already a lot of things are available by default
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4153
|
2022-02-06 17:25:12 +01:00
|
|
|
02:31:29,920 --> 02:31:36,500
|
|
|
|
so the phishing taxonomy itself is a complete one coming from I think {inaudible} academic paper
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4155
|
2022-02-06 17:25:12 +01:00
|
|
|
02:31:35,200 --> 02:31:38,0
|
|
|
|
where we have all the techniques that are used.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4157
|
2022-02-06 17:25:12 +01:00
|
|
|
02:31:38,0 --> 02:31:45,500
|
|
|
|
So for example you can say that this one is coming from a spearphishing
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4159
|
2022-02-06 17:25:12 +01:00
|
|
|
02:31:45,500 --> 02:31:51,500
|
|
|
|
which was described there and you have the different techniques.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4161
|
2022-02-06 17:25:12 +01:00
|
|
|
02:31:51,500 --> 02:31:53,500
|
|
|
|
So in this case it's email spoofing
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4162
|
2022-02-06 17:25:12 +01:00
|
|
|
02:31:53,500 --> 02:31:57,760
|
|
|
|
and you can go deeper there into the description of what is exactly the phishing.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4165
|
2022-02-06 17:25:12 +01:00
|
|
|
02:31:58,719 --> 02:32:05,500
|
|
|
|
and you can mix match both. I mean Andras selected the ATTACK phishing techniques
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4167
|
2022-02-06 17:25:12 +01:00
|
|
|
02:32:05,500 --> 02:32:07,0
|
|
|
|
at specific indicator level
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4169
|
2022-02-06 17:25:12 +01:00
|
|
|
02:32:07,0 --> 02:32:12,500
|
|
|
|
Maybe another analyst would want to classify it and maybe the objectives might be different.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4172
|
2022-02-06 17:25:12 +01:00
|
|
|
02:32:12,500 --> 02:32:16,500
|
|
|
|
Maybe on one, for example it's more specific for tools.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4174
|
2022-02-06 17:25:12 +01:00
|
|
|
02:32:16,719 --> 02:32:21,500
|
|
|
|
But if you want to run out statistics at the end of, I don't know, quarterly meetings
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4177
|
2022-02-06 17:25:12 +01:00
|
|
|
02:32:21,500 --> 02:32:25,500
|
|
|
|
and say okay, how many spearfishing that you receive or maybe emails spoofing.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4179
|
2022-02-06 17:25:12 +01:00
|
|
|
02:32:25,600 --> 02:32:30,0
|
|
|
|
For example if you can control better emails spoofing, the SPF record and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4181
|
2022-02-06 17:25:12 +01:00
|
|
|
02:32:30,0 --> 02:32:34,0
|
|
|
|
you can just look at the current technique that are used by by the attacker.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
4184
|
2022-02-06 17:25:12 +01:00
|
|
|
02:32:34,0 --> 02:32:39,500
|
|
|
|
So you see that those kind of, it's full of taxonomies that can be used
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4187
|
2022-02-06 17:25:12 +01:00
|
|
|
02:32:39,500 --> 02:32:44,0
|
|
|
|
and obviously we usually recommend to not enable everything
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4189
|
2022-02-06 17:25:12 +01:00
|
|
|
02:32:44,0 --> 02:32:47,500
|
|
|
|
but just pick what you really want and some are very generic,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4191
|
2022-02-06 17:25:12 +01:00
|
|
|
02:32:47,500 --> 02:32:53,0
|
|
|
|
some are more advanced but that's maybe something that we dig into more afterwards
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4193
|
2022-02-06 17:25:12 +01:00
|
|
|
02:32:53,0 --> 02:32:58,500
|
|
|
|
but just be careful of which kind of taxonomy you want to use because it will be the language
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4196
|
2022-02-06 17:25:12 +01:00
|
|
|
02:32:58,500 --> 02:33:05,500
|
|
|
|
that you use with the community and your partners for sharing this information.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4200
|
2022-02-06 17:25:12 +01:00
|
|
|
02:33:09,0 --> 02:33:13,500
|
|
|
|
Maybe something interesting to look into the email and that's linked to classifications
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4202
|
2022-02-06 17:25:12 +01:00
|
|
|
02:33:13,500 --> 02:33:15,500
|
|
|
|
but there's this comment there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4204
|
2022-02-06 17:25:12 +01:00
|
|
|
02:33:16,0 --> 02:33:19,0
|
|
|
|
"Please be mindful that this is an ongoing investigation
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4206
|
2022-02-06 17:25:12 +01:00
|
|
|
02:33:19,0 --> 02:33:24,0
|
|
|
|
and we would like to avoid informing the attacker of the detection
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4207
|
2022-02-06 17:25:12 +01:00
|
|
|
02:33:24,0 --> 02:33:30,0
|
|
|
|
and kindly ask you to to only use the contained information to protect your constituents".
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4211
|
2022-02-06 17:25:12 +01:00
|
|
|
02:33:30,0 --> 02:33:37,500
|
|
|
|
So this is kind of your language describing to you what kind of classification it is.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4214
|
2022-02-06 17:25:12 +01:00
|
|
|
02:33:37,500 --> 02:33:47,0
|
|
|
|
And so now which one should we use so if we are FIRST members, if we are using the FIRST community
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4217
|
2022-02-06 17:25:12 +01:00
|
|
|
02:33:47,0 --> 02:33:51,500
|
|
|
|
obviously the classification that we will use is not the NATO one,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4218
|
2022-02-06 17:25:12 +01:00
|
|
|
02:33:48,639 --> 02:33:55,0
|
|
|
|
or the Ministry of Defense in whatever country, it's really TLP.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4222
|
2022-02-06 17:25:12 +01:00
|
|
|
02:33:55,0 --> 02:34:05,500
|
|
|
|
So then again based on that, we will look into different taxonomy that we have
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4223
|
|
|
|
02:34:01,840 --> 02:34:09,200
|
|
|
|
|
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
4224
|
|
|
|
02:34:05,500 --> 02:34:11,500
|
|
|
|
we can look for TLP and I should not do that like that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4226
|
2022-02-06 17:25:12 +01:00
|
|
|
02:34:12,0 --> 02:34:20,0
|
|
|
|
I go for the TLP library and then I have the specific taxonomy TLP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4227
|
2022-02-06 17:25:12 +01:00
|
|
|
02:34:20,0 --> 02:34:22,500
|
|
|
|
and then you have the different one.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4230
|
2022-02-06 17:25:12 +01:00
|
|
|
02:34:22,500 --> 02:34:26,0
|
|
|
|
In this case they say you have to share it with your constituents only
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4231
|
2022-02-06 17:25:12 +01:00
|
|
|
02:34:26,0 --> 02:34:31,500
|
|
|
|
so TLP amber seems to be the most appropriate one.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4234
|
2022-02-06 17:25:12 +01:00
|
|
|
02:34:31,500 --> 02:34:34,500
|
|
|
|
We say that the TLP Amber information is given to organization
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4236
|
2022-02-06 17:25:12 +01:00
|
|
|
02:34:34,500 --> 02:34:37,500
|
|
|
|
sharing limited within organization to basically act upon.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4238
|
2022-02-06 17:25:12 +01:00
|
|
|
02:34:38,0 --> 02:34:45,0
|
|
|
|
If we have the extended classifications from FIRST it includes the constituent too.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4241
|
2022-02-06 17:25:12 +01:00
|
|
|
02:34:45,0 --> 02:34:49,500
|
|
|
|
So I will just use a TLP but I mentioned something else that is interesting.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4244
|
2022-02-06 17:25:12 +01:00
|
|
|
02:34:49,500 --> 02:34:59,500
|
|
|
|
In the email they mentioned that this is an ongoing investigation, to avoid informing the attacker.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4245
|
2022-02-06 17:25:12 +01:00
|
|
|
02:34:59,500 --> 02:35:06,0
|
|
|
|
In this case, how would you inform the attacker but if you do actions on specific indicators and attributes
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4251
|
2022-02-06 17:25:12 +01:00
|
|
|
02:35:06,0 --> 02:35:10,0
|
|
|
|
you might want to restrict that so there is another classification,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4252
|
2022-02-06 17:25:12 +01:00
|
|
|
02:35:10,0 --> 02:35:11,500
|
|
|
|
I don't know if this one is enabled.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4254
|
2022-02-06 17:25:12 +01:00
|
|
|
02:35:11,500 --> 02:35:18,500
|
|
|
|
It's called PAP which is exactly that, it's similar to TLP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4256
|
2022-02-06 17:25:12 +01:00
|
|
|
02:35:18,500 --> 02:35:21,500
|
|
|
|
but describing what you can do with this information.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4257
|
2022-02-06 17:25:12 +01:00
|
|
|
02:35:21,500 --> 02:35:28,500
|
|
|
|
If we don't want to at least notify the attacker that we are doing some further investigations.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4260
|
2022-02-06 17:25:12 +01:00
|
|
|
02:35:27,439 --> 02:35:34,0
|
|
|
|
Maybe we want to restrict that and the PAP is really telling you
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4261
|
2022-02-06 17:25:12 +01:00
|
|
|
02:35:34,0 --> 02:35:36,500
|
|
|
|
what are the permissive action that you can do.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4265
|
2022-02-06 17:25:12 +01:00
|
|
|
02:35:36,500 --> 02:35:43,500
|
|
|
|
In our case, "PAP: RED" for example, non-detectable actions only and that's really what we wants
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4268
|
2022-02-06 17:25:12 +01:00
|
|
|
02:35:43,500 --> 02:35:48,500
|
|
|
|
because the reporter say okay we have an ongoing investigation
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4269
|
2022-02-06 17:25:12 +01:00
|
|
|
02:35:48,500 --> 02:35:51,500
|
|
|
|
so you don't want the other parties are informed.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4272
|
2022-02-06 17:25:12 +01:00
|
|
|
02:35:51,500 --> 02:35:56,500
|
|
|
|
So in this case, I will use RED and again this is used at event level
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4274
|
2022-02-06 17:25:12 +01:00
|
|
|
02:35:56,500 --> 02:36:00,500
|
|
|
|
and that's something quite important because MISP will take care of that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4276
|
2022-02-06 17:25:12 +01:00
|
|
|
02:36:00,478 --> 02:36:04,500
|
|
|
|
You don't need to set "PAP: RED" on every single attribute.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4278
|
2022-02-06 17:25:12 +01:00
|
|
|
02:36:04,639 --> 02:36:11,500
|
|
|
|
Behind, it's really at event level so it's automatically allocating on all attributes
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4281
|
2022-02-06 17:25:12 +01:00
|
|
|
02:36:11,500 --> 02:36:15,500
|
|
|
|
We don't show it on the interface because it will be too cramp.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4283
|
2022-02-06 17:25:12 +01:00
|
|
|
02:36:16,0 --> 02:36:21,500
|
|
|
|
You know, overloaded with information but we do it in a way that's on the API level.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4285
|
2022-02-06 17:25:12 +01:00
|
|
|
02:36:21,600 --> 02:36:25,500
|
|
|
|
If you do {inaudible} search. for example on event level or attribute level
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4287
|
2022-02-06 17:25:12 +01:00
|
|
|
02:36:25,500 --> 02:36:32,500
|
|
|
|
"PAP: RED" will be included there if you have an attribute containing some information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4288
|
2022-02-06 17:25:12 +01:00
|
|
|
02:36:32,500 --> 02:36:38,500
|
|
|
|
automatically tags like "PAP: RED" will be then included into the information.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4292
|
2022-02-06 17:25:12 +01:00
|
|
|
02:36:38,500 --> 02:36:41,500
|
|
|
|
So that's something to keep in mind when we have information from third party
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4294
|
2022-02-06 17:25:12 +01:00
|
|
|
02:36:41,500 --> 02:36:45,0
|
|
|
|
is to to wonder okay what is the classification scheme
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4295
|
2022-02-06 17:25:12 +01:00
|
|
|
02:36:45,0 --> 02:36:49,500
|
|
|
|
so sometimes they don't say a specific classification to use that you just use natural language
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4299
|
2022-02-06 17:25:12 +01:00
|
|
|
02:36:49,500 --> 02:36:54,500
|
|
|
|
or just a normal sentence to describe all the information should be shared.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4300
|
2022-02-06 17:25:12 +01:00
|
|
|
02:36:54,500 --> 02:36:58,500
|
|
|
|
So the interesting thing here is that what we've seen now is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4303
|
2022-02-06 17:25:12 +01:00
|
|
|
02:36:58,500 --> 02:37:01,0
|
|
|
|
we've contextualized information in many different aspects
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4306
|
2022-02-06 17:25:12 +01:00
|
|
|
02:37:01,0 --> 02:37:07,500
|
|
|
|
and this is just scraping the top layer basically
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4307
|
2022-02-06 17:25:12 +01:00
|
|
|
02:37:07,500 --> 02:37:09,0
|
|
|
|
we could go much much further with contextualization.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4308
|
2022-02-06 17:25:12 +01:00
|
|
|
02:37:09,0 --> 02:37:14,500
|
|
|
|
Imagine for example describing how this information is relevant to whether it's used.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4311
|
2022-02-06 17:25:12 +01:00
|
|
|
02:37:14,500 --> 02:37:18,0
|
|
|
|
What sort of mechanisms they should have in place to be able to block this information?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4313
|
2022-02-06 17:25:12 +01:00
|
|
|
02:37:18,0 --> 02:37:21,500
|
|
|
|
How can you make this useful? Think of different maturity organizations as well
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4316
|
2022-02-06 17:25:12 +01:00
|
|
|
02:37:21,500 --> 02:37:26,500
|
|
|
|
when you're sharing information. You could also describe information about who's behind it,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4318
|
2022-02-06 17:25:12 +01:00
|
|
|
02:37:26,500 --> 02:37:29,0
|
|
|
|
what the motivations are? So we did not describe the threat actor
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4321
|
2022-02-06 17:25:12 +01:00
|
|
|
02:37:29,0 --> 02:37:32,0
|
|
|
|
because we haven't done any analysis yet.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4323
|
2022-02-06 17:25:12 +01:00
|
|
|
02:37:32,0 --> 02:37:36,500
|
|
|
|
This is the initial information we got from a CSIRT that just reported an incident to us
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4325
|
2022-02-06 17:25:12 +01:00
|
|
|
02:37:36,500 --> 02:37:41,500
|
|
|
|
but we could go further and if we did our analysis we would find who's behind this
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4327
|
2022-02-06 17:25:12 +01:00
|
|
|
02:37:41,500 --> 02:37:46,500
|
|
|
|
we could go for information with the threat actor, we could look at target sectors
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4330
|
2022-02-06 17:25:12 +01:00
|
|
|
02:37:46,500 --> 02:37:53,500
|
|
|
|
we could look at a lot of different information in regards to to further contextualizing the information.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4334
|
2022-02-06 17:25:12 +01:00
|
|
|
02:37:58,0 --> 02:38:00,500
|
|
|
|
So in this case we could also, for example say that's in the {inaudible} where
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4336
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:00,500 --> 02:38:04,500
|
|
|
|
because we know that this is something that was targeting an organization in Luxembourg.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4339
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:04,500 --> 02:38:09,500
|
|
|
|
We know there is also a sector taxonomy that you can use
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4340
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:09,500 --> 02:38:12,500
|
|
|
|
so that's not a galaxy but the taxonomy.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4343
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:12,500 --> 02:38:16,0
|
|
|
|
So we can also add for example information about the financial sector
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4345
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:16,0 --> 02:38:19,500
|
|
|
|
We know the CEO is a CEO of a financial sector organization.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4347
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:20,79 --> 02:38:23,500
|
|
|
|
So we could also say that it's probably has to do with that as well.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4349
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:23,760 --> 02:38:25,500
|
|
|
|
Maybe it's not enabled, sorry about that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4350
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:25,500 --> 02:38:32,0
|
|
|
|
Yeah this one never. But if you search... Yeah, exactly, there.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4351
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:32,0 --> 02:38:34,500
|
|
|
|
If you just search for "sector", it should be there.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4353
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:34,500 --> 02:38:40,500
|
|
|
|
Yeah but I'm... Yeah there's something that you can do talk about it later but it's...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4355
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:40,500 --> 02:38:45,0
|
|
|
|
"sector" so we have different one.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4357
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:45,0 --> 02:38:50,500
|
|
|
|
Maybe you find that so if... there was one for finance you can just pick that, yeah.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4360
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:50,500 --> 02:38:56,500
|
|
|
|
Yeah, something else you can do and this one is important too,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4361
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:56,500 --> 02:39:00,500
|
|
|
|
it's going a bit further than the email. So for example, as a source
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4363
|
2022-02-06 17:25:12 +01:00
|
|
|
02:38:59,40 --> 02:39:04,0
|
|
|
|
we receive emails from various people, I mean if I receive an email from,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4366
|
2022-02-06 17:25:12 +01:00
|
|
|
02:39:04,0 --> 02:39:07,000
|
|
|
|
I don't know, from an analyst from, I don't know, he is at Mcafee and so on,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4367
|
2022-02-06 17:25:12 +01:00
|
|
|
02:39:07,000 --> 02:39:13,500
|
|
|
|
that I'm working with them for years my confidence on this information is quite high.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4372
|
2022-02-06 17:25:12 +01:00
|
|
|
02:39:13,500 --> 02:39:19,0
|
|
|
|
On the other hand, if I receive an email from someone unknown maybe my confidence will be a bit different.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4376
|
2022-02-06 17:25:12 +01:00
|
|
|
02:39:19,0 --> 02:39:23,500
|
|
|
|
So in MISP, you have plenty of taxonomies to express confidence.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4378
|
2022-02-06 17:25:12 +01:00
|
|
|
02:39:23,500 --> 02:39:31,500
|
|
|
|
For example, the one that is actively used, for example, the military network is Admiralty Scale or NATO scale
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4381
|
2022-02-06 17:25:12 +01:00
|
|
|
02:39:31,500 --> 02:39:36,500
|
|
|
|
where you can basically define the credibility of the source.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4383
|
2022-02-06 17:25:12 +01:00
|
|
|
02:39:36,500 --> 02:39:43,500
|
|
|
|
In this case, we can say that we know the source and is usually reliable so that's the source itself.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4387
|
2022-02-06 17:25:12 +01:00
|
|
|
02:39:43,500 --> 02:39:51,500
|
|
|
|
and we can say for this specific information that is probably true because they send us some evidence.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4391
|
2022-02-06 17:25:12 +01:00
|
|
|
02:39:51,500 --> 02:39:59,500
|
|
|
|
Now if I have like three emails talking about the same case maybe my level of credibility will increase
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4395
|
2022-02-06 17:25:12 +01:00
|
|
|
02:39:59,500 --> 02:40:03,500
|
|
|
|
because we have multiple people that have seen exactly the same kind of thing
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4397
|
2022-02-06 17:25:12 +01:00
|
|
|
02:40:03,500 --> 02:40:06,500
|
|
|
|
So in this case I will have those kind of information there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4398
|
2022-02-06 17:25:12 +01:00
|
|
|
02:40:06,500 --> 02:40:11,500
|
|
|
|
Again it's a way to really contextualize information and the quality of the information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4402
|
2022-02-06 17:25:12 +01:00
|
|
|
02:40:11,500 --> 02:40:19,500
|
|
|
|
and you have, for example, additional one like, for example, we have one called "estimative-language".
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4403
|
2022-02-06 17:25:12 +01:00
|
|
|
02:40:19,760 --> 02:40:23,500
|
|
|
|
so this one is more coming from DNI and the CIA.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4407
|
2022-02-06 17:25:12 +01:00
|
|
|
02:40:23,500 --> 02:40:26,500
|
|
|
|
It's like the likelihood of probability that this happen.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4409
|
2022-02-06 17:25:12 +01:00
|
|
|
02:40:27,439 --> 02:40:31,0
|
|
|
|
So we can say that this one has been almost certain and then we can even qualify
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4412
|
2022-02-06 17:25:12 +01:00
|
|
|
02:40:31,0 --> 02:40:37,0
|
|
|
|
or own analysis judgment on this and I can say that it was like quickly done
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4414
|
2022-02-06 17:25:12 +01:00
|
|
|
02:40:37,0 --> 02:40:40,500
|
|
|
|
and it's not perfect, I will just say low for example.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4417
|
2022-02-06 17:25:12 +01:00
|
|
|
02:40:40,500 --> 02:40:43,500
|
|
|
|
So then you can have this kind of information.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4418
|
2022-02-06 17:25:12 +01:00
|
|
|
02:40:42,318 --> 02:40:47,500
|
|
|
|
And you can either use it as an event level again or a specific attribute.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4420
|
2022-02-06 17:25:12 +01:00
|
|
|
02:40:46,318 --> 02:40:52,500
|
|
|
|
So for example, if one of the emails it was like, not properly collected or it was skirts,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4423
|
2022-02-06 17:25:12 +01:00
|
|
|
02:40:52,500 --> 02:40:55,500
|
|
|
|
or someone modified the headers and so on, maybe you can reduce
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4425
|
2022-02-06 17:25:12 +01:00
|
|
|
02:40:55,500 --> 02:40:59,500
|
|
|
|
the summative language of the confidence level that you have
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4429
|
2022-02-06 17:25:12 +01:00
|
|
|
02:40:59,500 --> 02:41:06,500
|
|
|
|
in the analytic judgment of the specific evidence or element by tagging that at the attribute level.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4431
|
2022-02-06 17:25:12 +01:00
|
|
|
02:41:06,500 --> 02:41:11,500
|
|
|
|
So again, those kind of information that we are putting there are factors and so on and more like event level.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4434
|
2022-02-06 17:25:12 +01:00
|
|
|
02:41:11,500 --> 02:41:15,500
|
|
|
|
But if you have really specific things that need to be changed
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4436
|
2022-02-06 17:25:12 +01:00
|
|
|
02:41:15,500 --> 02:41:22,500
|
|
|
|
or that are specific to the attribute or object then you can change it at the attribute level.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4439
|
2022-02-06 17:25:12 +01:00
|
|
|
02:41:26,0 --> 02:41:29,500
|
|
|
|
Just some other thing on the user interface that might be useful too that we skipped.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4442
|
2022-02-06 17:25:12 +01:00
|
|
|
02:41:29,500 --> 02:41:34,500
|
|
|
|
On the metadata of the event you have plenty of information there.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4444
|
2022-02-06 17:25:12 +01:00
|
|
|
02:41:35,840 --> 02:41:39,0
|
|
|
|
Why that is interesting regarding "organization only" and "distribution",
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4446
|
2022-02-06 17:25:12 +01:00
|
|
|
02:41:39,0 --> 02:41:41,500
|
|
|
|
In this case, we just distribute to the organization
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4449
|
2022-02-06 17:25:12 +01:00
|
|
|
02:41:41,500 --> 02:41:45,500
|
|
|
|
but if you have pretty large event at some point in time and you want to distribute.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4450
|
2022-02-06 17:25:12 +01:00
|
|
|
02:41:45,500 --> 02:41:51,500
|
|
|
|
You have this kind of overview there which is helping you to see at which level you share this information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4453
|
2022-02-06 17:25:12 +01:00
|
|
|
02:41:51,500 --> 02:41:56,500
|
|
|
|
In this case, it's super easy. We just distribute it to the training organization, that's fine.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4456
|
2022-02-06 17:25:12 +01:00
|
|
|
02:41:56,500 --> 02:42:00,500
|
|
|
|
But if you have a pretty large instance with a lot of organization and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4458
|
2022-02-06 17:25:12 +01:00
|
|
|
02:42:00,500 --> 02:42:06,500
|
|
|
|
It will display you a full graph of where the information will flow and will be distributed.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4461
|
2022-02-06 17:25:12 +01:00
|
|
|
02:42:08,0 --> 02:42:14,500
|
|
|
|
Okay. Now going back to our event, basically the reason why we went so deeply into the contextualization part
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4464
|
2022-02-06 17:25:12 +01:00
|
|
|
02:42:14,500 --> 02:42:21,500
|
|
|
|
is looking at this event we can already use this right away when feeding our tools,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4467
|
2022-02-06 17:25:12 +01:00
|
|
|
02:42:20,0 --> 02:42:26,500
|
|
|
|
when doing our searches, to basically search for anything targeting the financial sector for example.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4472
|
2022-02-06 17:25:12 +01:00
|
|
|
02:42:26,500 --> 02:42:34,0
|
|
|
|
we can search for anything related to phishing and find the data contained in this particular event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4475
|
2022-02-06 17:25:12 +01:00
|
|
|
02:42:34,0 --> 02:42:46,500
|
|
|
|
So this already helps us with our filtering mechanisms.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4476
|
2022-02-06 17:25:12 +01:00
|
|
|
02:42:46,500 --> 02:42:46,500
|
|
|
|
As for PAP and TLP, those tags we can use when we make decisions on which tools we feed the data to
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4480
|
2022-02-06 17:25:12 +01:00
|
|
|
02:42:46,500 --> 02:42:49,500
|
|
|
|
or which partners we share the information within the case of TLP.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4482
|
2022-02-06 17:25:12 +01:00
|
|
|
02:42:49,500 --> 02:42:54,500
|
|
|
|
So we're going to see that more tomorrow when we're creating synchronization links with other instances.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4486
|
2022-02-06 17:25:12 +01:00
|
|
|
02:42:54,500 --> 02:43:01,0
|
|
|
|
We can for example set restrictions on TLP when we're pushing data to another node and we can say
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4489
|
2022-02-06 17:25:12 +01:00
|
|
|
02:43:01,0 --> 02:43:07,500
|
|
|
|
okay, no matter what distribution setting don't send anything TLP Amber in this direction for example.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4493
|
2022-02-06 17:25:12 +01:00
|
|
|
02:43:07,500 --> 02:43:13,500
|
|
|
|
Yeah, as an example there's a very good open source tool called TheHive for threat hunting
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4497
|
2022-02-06 17:25:12 +01:00
|
|
|
02:43:13,500 --> 02:43:17,0
|
|
|
|
and they use PAP to know which kind of actions they can do on the data.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4498
|
2022-02-06 17:25:12 +01:00
|
|
|
02:43:17,00 --> 02:43:24,0
|
|
|
|
So if you synchronize MISP with TheHive instance you can really be sure that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4501
|
2022-02-06 17:25:12 +01:00
|
|
|
02:43:24,0 --> 02:43:30,0
|
|
|
|
what you set as PAP for example "RED" on the MISP instance will not generate issues
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4503
|
2022-02-06 17:25:12 +01:00
|
|
|
02:43:30,0 --> 02:43:34,500
|
|
|
|
when you are starting to expansion within Cortex on TheHive
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4506
|
2022-02-06 17:25:12 +01:00
|
|
|
02:43:34,500 --> 02:43:38,500
|
|
|
|
to be sure that the information is not basically flowing somewhere else.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4508
|
2022-02-06 17:25:12 +01:00
|
|
|
02:43:38,500 --> 02:43:45,500
|
|
|
|
So at this point something that we didn't do so far is we did not include the initial email.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4510
|
2022-02-06 17:25:12 +01:00
|
|
|
02:43:45,500 --> 02:43:48,0
|
|
|
|
So what we're going to do now is we're going to use another functionality of MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4513
|
2022-02-06 17:25:12 +01:00
|
|
|
02:43:48,0 --> 02:43:52,500
|
|
|
|
that we haven't talked much about called the report, the event report.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4514
|
2022-02-06 17:25:12 +01:00
|
|
|
02:43:51,200 --> 02:44:00,0
|
|
|
|
We can also include clear text information such as a report description and so on together with the event.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4518
|
2022-02-06 17:25:12 +01:00
|
|
|
02:44:00,398 --> 02:44:04,500
|
|
|
|
So what we're going to do now is something very simple, we're not going to write our own report.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4520
|
2022-02-06 17:25:12 +01:00
|
|
|
02:44:04,500 --> 02:44:07,500
|
|
|
|
We have a report already available from the original source
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4523
|
2022-02-06 17:25:12 +01:00
|
|
|
02:44:07,500 --> 02:44:11,0
|
|
|
|
so we're just going to paste that entire email in.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4525
|
2022-02-06 17:25:12 +01:00
|
|
|
02:44:14,0 --> 02:44:17,0
|
|
|
|
Okay. Just submit for now.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4527
|
2022-02-06 17:25:12 +01:00
|
|
|
02:44:26,0 --> 02:44:33,500
|
|
|
|
So now if you look at our email report we just have a simple report here in clear text.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4529
|
2022-02-06 17:25:12 +01:00
|
|
|
02:44:33,500 --> 02:44:36,500
|
|
|
|
We're going to see an example what you can do with this. So this is all in markdown
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4531
|
2022-02-06 17:25:12 +01:00
|
|
|
02:44:36,500 --> 02:44:41,500
|
|
|
|
so you could go into edit mode and pretty it up, add additional information there.
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
4535
|
2022-02-06 17:25:12 +01:00
|
|
|
02:44:41,500 --> 02:44:46,0
|
|
|
|
We're not going to do that now because we're going to just look at an example that already has that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4538
|
2022-02-06 17:25:12 +01:00
|
|
|
02:44:46,0 --> 02:44:51,0
|
|
|
|
but before we do that let's get back to our event and let's assume that we're done this entire process.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4541
|
2022-02-06 17:25:12 +01:00
|
|
|
02:44:51,0 --> 02:44:55,500
|
|
|
|
We have our report, we have our event we have contextualized all our data
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4542
|
2022-02-06 17:25:12 +01:00
|
|
|
02:44:55,500 --> 02:44:57,500
|
|
|
|
and let's publish it now to the community.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4546
|
2022-02-06 17:25:12 +01:00
|
|
|
02:44:57,500 --> 02:45:04,500
|
|
|
|
So when it comes to publishing we have different ways of achieving that in MISP.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4549
|
2022-02-06 17:25:12 +01:00
|
|
|
02:45:04,500 --> 02:45:07,500
|
|
|
|
By default, when we create an event like this, at this stage
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4550
|
2022-02-06 17:25:12 +01:00
|
|
|
02:45:07,500 --> 02:45:11,500
|
|
|
|
we have all the data contained that we want to share out and that we want to use
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4553
|
2022-02-06 17:25:12 +01:00
|
|
|
02:45:11,500 --> 02:45:18,500
|
|
|
|
however MISP considers this to be non-final, it is not to be used by automation tools connected to MISP,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4557
|
2022-02-06 17:25:12 +01:00
|
|
|
02:45:18,500 --> 02:45:24,500
|
|
|
|
it is not going to be synchronized out to other instances and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4560
|
2022-02-06 17:25:12 +01:00
|
|
|
02:45:25,500 --> 02:45:31,500
|
|
|
|
And what we can do now is first of all we need to decide how we shared it out
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4562
|
2022-02-06 17:25:12 +01:00
|
|
|
02:45:31,500 --> 02:45:35,500
|
|
|
|
it is the organization only for now so even if we were to publish it
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4564
|
2022-02-06 17:25:12 +01:00
|
|
|
02:45:35,500 --> 02:45:40,500
|
|
|
|
would still only be pushed to our own tools that connect to our MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4565
|
2022-02-06 17:25:12 +01:00
|
|
|
02:45:40,500 --> 02:45:45,500
|
|
|
|
but it would not be made visible to other organizations but we want to change this, in this case.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4569
|
2022-02-06 17:25:12 +01:00
|
|
|
02:45:45,500 --> 02:45:51,500
|
|
|
|
However, let's assume that we are an organization that does not wish to reveal
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4572
|
2022-02-06 17:25:12 +01:00
|
|
|
02:45:51,500 --> 02:45:58,500
|
|
|
|
that we were involved in this entire incident. We just want to entrust the third party with doing it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4575
|
2022-02-06 17:25:12 +01:00
|
|
|
02:45:58,500 --> 02:46:02,500
|
|
|
|
So as you see there, where Alex is hovering. We basically have several options here.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4578
|
2022-02-06 17:25:12 +01:00
|
|
|
02:46:02,500 --> 02:46:07,0
|
|
|
|
We can either publish the event which means we initiate the entire exchange with other instances
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4580
|
2022-02-06 17:25:12 +01:00
|
|
|
02:46:07,0 --> 02:46:12,500
|
|
|
|
if the distribution allows it. It will alert everyone that we have published this
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4584
|
2022-02-06 17:25:12 +01:00
|
|
|
02:46:12,500 --> 02:46:17,0
|
|
|
|
or alternatively we can delegate the publishing to third party and stay anonymous ourselves
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4586
|
2022-02-06 17:25:12 +01:00
|
|
|
02:46:17,0 --> 02:46:22,0
|
|
|
|
So let's do that option for now. So what we're doing now is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4590
|
2022-02-06 17:25:12 +01:00
|
|
|
02:46:22,0 --> 02:46:25,500
|
|
|
|
we're entrusting a third party to take over this event for us
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4591
|
2022-02-06 17:25:12 +01:00
|
|
|
02:46:25,500 --> 02:46:29,500
|
|
|
|
so let's say that we would entrust, say for example CIRCL, to take over this event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4593
|
2022-02-06 17:25:12 +01:00
|
|
|
02:46:29,500 --> 02:46:35,0
|
|
|
|
and we tell CIRCL that we want to share this event, to be shared with the entire community.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4596
|
2022-02-06 17:25:12 +01:00
|
|
|
02:46:35,0 --> 02:46:37,500
|
|
|
|
so we've collected..
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4597
|
2022-02-06 17:25:12 +01:00
|
|
|
02:46:45,0 --> 02:46:50,500
|
|
|
|
Yeah and you can see "This community only" for example or a sharing group whatever you prefer.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4600
|
2022-02-06 17:25:12 +01:00
|
|
|
02:46:50,500 --> 02:46:55,0
|
|
|
|
Okay, so this is again a suggestion to the other organization saying
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4602
|
2022-02-06 17:25:12 +01:00
|
|
|
02:46:55,0 --> 02:46:59,500
|
|
|
|
okay, we want you to share this out and we want you to share this to this community.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4605
|
2022-02-06 17:25:12 +01:00
|
|
|
02:46:59,500 --> 02:47:04,0
|
|
|
|
Once we click "Yes", even though the event was your organizationa and only visible to us.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4607
|
2022-02-06 17:25:12 +01:00
|
|
|
02:47:04,0 --> 02:47:08,500
|
|
|
|
It now becomes visible to two organizations, ourselves and the other organization
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4608
|
2022-02-06 17:25:12 +01:00
|
|
|
02:47:08,500 --> 02:47:12,500
|
|
|
|
that we entrust in this case CIRCL. So CIRCL would get an email saying
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4610
|
2022-02-06 17:25:12 +01:00
|
|
|
02:47:12,500 --> 02:47:17,500
|
|
|
|
Okay, there's this delegation request someone wants you to take over their event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4613
|
2022-02-06 17:25:12 +01:00
|
|
|
02:47:17,500 --> 02:47:19,500
|
|
|
|
are you willing to take it over and publish it under your name.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4616
|
2022-02-06 17:25:12 +01:00
|
|
|
02:47:19,500 --> 02:47:23,0
|
|
|
|
This will look something like this with slightly different text we're cheating here now
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4619
|
2022-02-06 17:25:12 +01:00
|
|
|
02:47:23,0 --> 02:47:28,500
|
|
|
|
since we're doing a training, we're site administrators so we see both sides of the story,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4622
|
2022-02-06 17:25:12 +01:00
|
|
|
02:47:28,500 --> 02:47:33,500
|
|
|
|
so we can either accept or discard this request. Keep in mind if you accept such a request,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4624
|
2022-02-06 17:25:12 +01:00
|
|
|
02:47:33,500 --> 02:47:37,500
|
|
|
|
the event becomes your event a copy of it is created under your name
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4628
|
2022-02-06 17:25:12 +01:00
|
|
|
02:47:37,500 --> 02:47:42,500
|
|
|
|
and basically you are taking responsibility for the event from now on,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4629
|
2022-02-06 17:25:12 +01:00
|
|
|
02:47:42,500 --> 02:47:45,500
|
|
|
|
so also make sure that you're not pushing junk under your name.
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
4630
|
2022-02-06 17:25:12 +01:00
|
|
|
02:47:45,500 --> 02:47:48,500
|
|
|
|
So in this case let's just discard it
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4631
|
2022-02-06 17:25:12 +01:00
|
|
|
02:47:48,500 --> 02:47:52,500
|
|
|
|
but we could have accepted it and then it would have become our event.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4634
|
2022-02-06 17:25:12 +01:00
|
|
|
02:47:52,500 --> 02:47:56,500
|
|
|
|
Okay. Let's go back to the event.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4635
|
2022-02-06 17:25:12 +01:00
|
|
|
02:48:00,0 --> 02:48:04,0
|
|
|
|
Okay, so now the other alternative is if you want to publish it under our name,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4637
|
2022-02-06 17:25:12 +01:00
|
|
|
02:48:04,0 --> 02:48:08,500
|
|
|
|
what you would need to do is you would need to raise the distribution level first
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4640
|
2022-02-06 17:25:12 +01:00
|
|
|
02:48:08,500 --> 02:48:12,0
|
|
|
|
if you wanted to involve any other parties
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4642
|
2022-02-06 17:25:12 +01:00
|
|
|
02:48:12,0 --> 02:48:15,500
|
|
|
|
So we need to edit the event in that case and raise the distribution level
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4645
|
2022-02-06 17:25:12 +01:00
|
|
|
02:48:15,500 --> 02:48:20,500
|
|
|
|
to say "This Community" or "Connected Communities". Let's go with "Connected Communities".
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4647
|
2022-02-06 17:25:12 +01:00
|
|
|
02:48:20,500 --> 02:48:24,500
|
|
|
|
connected communities means anyone that has access to my MISP instance
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4648
|
2022-02-06 17:25:12 +01:00
|
|
|
02:48:24,500 --> 02:48:29,500
|
|
|
|
and all the directly interconnected instances including all their members as well.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4652
|
2022-02-06 17:25:12 +01:00
|
|
|
02:48:29,500 --> 02:48:34,500
|
|
|
|
So in the case, for example, of us publishing something like this in the FIRST instance
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4654
|
2022-02-06 17:25:12 +01:00
|
|
|
02:48:34,500 --> 02:48:37,0
|
|
|
|
we as CIRCL have our instance connected to it
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4655
|
2022-02-06 17:25:12 +01:00
|
|
|
02:48:37,0 --> 02:48:42,0
|
|
|
|
so all the members of the CIRCL instance will automatically also be included in the exchange.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4658
|
2022-02-06 17:25:12 +01:00
|
|
|
02:48:42,0 --> 02:48:45,500
|
|
|
|
Here we see a graph of that so we see the event would
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4659
|
2022-02-06 17:25:12 +01:00
|
|
|
02:48:45,500 --> 02:48:50,0
|
|
|
|
be also visible to all the directly connected instances which we only have one of
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4664
|
2022-02-06 17:25:12 +01:00
|
|
|
02:48:50,0 --> 02:48:57,0
|
|
|
|
which is a loopback connection to "iglocska.eu" so not that interesting
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4666
|
2022-02-06 17:25:12 +01:00
|
|
|
02:48:57,0 --> 02:49:00,500
|
|
|
|
and to everyone that has access to this current instance
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4668
|
2022-02-06 17:25:12 +01:00
|
|
|
02:49:00,500 --> 02:49:07,0
|
|
|
|
Okay. Once we're done we can click publish and then the event gets synchronized.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4671
|
2022-02-06 17:25:12 +01:00
|
|
|
02:49:08,0 --> 02:49:14,500
|
|
|
|
So what happens at this stage is first of all the event will jump over to directly connected instances.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4674
|
2022-02-06 17:25:12 +01:00
|
|
|
02:49:14,500 --> 02:49:19,500
|
|
|
|
MISP will send out a bunch of emails to everyone that subscribes to publish alerts
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4675
|
2022-02-06 17:25:12 +01:00
|
|
|
02:49:19,500 --> 02:49:22,500
|
|
|
|
that there is a new event with all the data contained within.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4678
|
2022-02-06 17:25:12 +01:00
|
|
|
02:49:22,500 --> 02:49:30,500
|
|
|
|
it will push the event down various local channels to other tools using ZeroMQ, Kafka and so on and syslog.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4681
|
2022-02-06 17:25:12 +01:00
|
|
|
02:49:30,500 --> 02:49:36,200
|
|
|
|
So if you have any tools that are subscribed to these published feeds
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4684
|
2022-02-06 17:25:12 +01:00
|
|
|
02:49:36,200 --> 02:49:41,500
|
|
|
|
and they will ingest the data and it will also make it available to the API
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4686
|
2022-02-06 17:25:12 +01:00
|
|
|
02:49:41,500 --> 02:49:44,500
|
|
|
|
and to make it available to all the integration tools out there.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4689
|
2022-02-06 17:25:12 +01:00
|
|
|
02:49:44,500 --> 02:49:52,500
|
|
|
|
so if you have your SIEM connected to MISP, it will now be able to fetch the data contained in this event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4691
|
2022-02-06 17:25:12 +01:00
|
|
|
02:49:52,500 --> 02:50:00,0
|
|
|
|
So this is basically the publishing process however if at this point we noticed that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4696
|
2022-02-06 17:25:12 +01:00
|
|
|
02:50:00,0 --> 02:50:06,500
|
|
|
|
okay we've now shared this event out but we've actually made a typo in the title we wanted to include
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4699
|
2022-02-06 17:25:12 +01:00
|
|
|
02:50:06,500 --> 02:50:17,500
|
|
|
|
I don't know, a trailing period at the end of the sentence {inaudible} something like that.
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
4702
|
2022-02-06 17:25:12 +01:00
|
|
|
02:50:17,500 --> 02:50:23,500
|
|
|
|
in the title and we edit the event. wWat happens now is, there is a modification to the event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4703
|
2022-02-06 17:25:12 +01:00
|
|
|
02:50:23,500 --> 02:50:29,500
|
|
|
|
so even though it was published, it becomes unpublished again and it needs to be to be republished.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4707
|
2022-02-06 17:25:12 +01:00
|
|
|
02:50:29,500 --> 02:50:33,500
|
|
|
|
now the reason why we do this is whenever there is a change
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4708
|
2022-02-06 17:25:12 +01:00
|
|
|
02:50:33,500 --> 02:50:36,500
|
|
|
|
we need to synchronize it out to the other instances out there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4710
|
2022-02-06 17:25:12 +01:00
|
|
|
02:50:36,500 --> 02:50:40,0
|
|
|
|
and if you have a publishing process in place
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4711
|
2022-02-06 17:25:12 +01:00
|
|
|
02:50:40,0 --> 02:50:44,500
|
|
|
|
where so only certain users have access to publishing rights for example
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4714
|
2022-02-06 17:25:12 +01:00
|
|
|
02:50:44,500 --> 02:50:47,500
|
|
|
|
then anytime your organization is pushing out information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4715
|
2022-02-06 17:25:12 +01:00
|
|
|
02:50:47,500 --> 02:50:52,500
|
|
|
|
it can go through the irregular vetting process so any change will unset the publishing of the event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4719
|
2022-02-06 17:25:12 +01:00
|
|
|
02:50:52,500 --> 02:50:55,500
|
|
|
|
now in this case this is a very small change that we've made
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4720
|
2022-02-06 17:25:12 +01:00
|
|
|
02:50:55,500 --> 02:50:58,500
|
|
|
|
so we don't want to actually send out emails to all the other users.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4722
|
2022-02-06 17:25:12 +01:00
|
|
|
02:50:58,500 --> 02:51:02,500
|
|
|
|
We don't want to spam them with data that is pretty irrelevant for them
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4723
|
2022-02-06 17:25:12 +01:00
|
|
|
02:51:02,500 --> 02:51:08,0
|
|
|
|
so we can do the publishing again but this time using the "Publish (no email) option.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4727
|
2022-02-06 17:25:12 +01:00
|
|
|
02:51:09,0 --> 02:51:11,500
|
|
|
|
So it will also synchronize the data
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4728
|
2022-02-06 17:25:12 +01:00
|
|
|
02:51:11,500 --> 02:51:15,500
|
|
|
|
it will again make it available to all different means of ingesting the data
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4730
|
2022-02-06 17:25:12 +01:00
|
|
|
02:51:15,500 --> 02:51:18,500
|
|
|
|
but it will not spam our users with emails.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4732
|
2022-02-06 17:25:12 +01:00
|
|
|
02:51:18,500 --> 02:51:24,500
|
|
|
|
Okay so that's basically it for the publishing and perhaps one thing that is interesting
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4735
|
2022-02-06 17:25:12 +01:00
|
|
|
02:51:24,500 --> 02:51:26,500
|
|
|
|
and that we didn't talk much about is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4736
|
2022-02-06 17:25:12 +01:00
|
|
|
02:51:26,500 --> 02:51:31,500
|
|
|
|
we have now raised the distribution level of this event to "Connected Communities".
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4740
|
2022-02-06 17:25:12 +01:00
|
|
|
02:51:31,500 --> 02:51:36,500
|
|
|
|
So the event is synchronized out but we actually had an attribute if you look further down
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4743
|
2022-02-06 17:25:12 +01:00
|
|
|
02:51:36,500 --> 02:51:41,500
|
|
|
|
that's had a different distribution level. So that one is actually going to be removed
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4745
|
2022-02-06 17:25:12 +01:00
|
|
|
02:51:41,500 --> 02:51:42,500
|
|
|
|
from the synchronized button.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4747
|
2022-02-06 17:25:12 +01:00
|
|
|
02:51:42,500 --> 02:51:51,0
|
|
|
|
So we had one that the impersonated person's email address that was set to organization only.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4750
|
2022-02-06 17:25:12 +01:00
|
|
|
02:51:51,0 --> 02:51:54,500
|
|
|
|
So whenever we're talking about synchronization that thing will,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4753
|
2022-02-06 17:25:12 +01:00
|
|
|
02:51:54,500 --> 02:51:57,500
|
|
|
|
in this case, not synchronize out. So that will be redacted from the event.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4755
|
2022-02-06 17:25:12 +01:00
|
|
|
02:51:59,0 --> 02:52:04,0
|
|
|
|
Okay something else that we can do at this point once we have created our event is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4757
|
2022-02-06 17:25:12 +01:00
|
|
|
02:52:04,0 --> 02:52:08,500
|
|
|
|
we can also extract it in different formats, so if you click on "Download as..." on the left side.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4760
|
2022-02-06 17:25:12 +01:00
|
|
|
02:52:09,40 --> 02:52:13,0
|
|
|
|
You will see that we can basically convert this automatically to a bunch of different formats
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4762
|
2022-02-06 17:25:12 +01:00
|
|
|
02:52:12,79 --> 02:52:17,500
|
|
|
|
and extract it in those formats directly. This is also what we would be accessing by the API
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4765
|
2022-02-06 17:25:12 +01:00
|
|
|
02:52:16,559 --> 02:52:22,500
|
|
|
|
if you were to search for this event. We can also mark whatever response format we want.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4768
|
2022-02-06 17:25:12 +01:00
|
|
|
02:52:23,520 --> 02:52:27,500
|
|
|
|
just very briefly we won't go very deeply into this. These formats are coming partially
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4770
|
2022-02-06 17:25:12 +01:00
|
|
|
02:52:26,559 --> 02:52:32,500
|
|
|
|
from our predefined hard-coded list of formats that we support in MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4773
|
2022-02-06 17:25:12 +01:00
|
|
|
02:52:32,500 --> 02:52:38,500
|
|
|
|
but some of these formats also come from the different export modules that we have
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4776
|
2022-02-06 17:25:12 +01:00
|
|
|
02:52:40,0 --> 02:52:44,500
|
|
|
|
So if you want you can either build your own native modules for exporting and converting data
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4779
|
2022-02-06 17:25:12 +01:00
|
|
|
02:52:44,500 --> 02:52:51,500
|
|
|
|
or you can build modules that are sitting in another tool called MISP modules,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4782
|
2022-02-06 17:25:12 +01:00
|
|
|
02:52:51,500 --> 02:52:55,500
|
|
|
|
side by side with MISP that will ingest the data and then convert it to other formats.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4785
|
2022-02-06 17:25:12 +01:00
|
|
|
02:52:55,500 --> 02:52:59,500
|
|
|
|
So here's a PDF report that was created directly out of the event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4786
|
2022-02-06 17:25:12 +01:00
|
|
|
02:52:59,500 --> 02:53:05,500
|
|
|
|
and that you can just share out directly for the event.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4789
|
2022-02-06 17:25:12 +01:00
|
|
|
02:53:05,500 --> 02:53:11,500
|
|
|
|
Something else that you can do is anything that we do in MISP, so all the process of adding attributes,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4792
|
2022-02-06 17:25:12 +01:00
|
|
|
02:53:11,500 --> 02:53:16,500
|
|
|
|
all the process of viewing data, you can also do that in a machine {inaudible} way
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4793
|
2022-02-06 17:25:12 +01:00
|
|
|
02:53:16,500 --> 02:53:19,500
|
|
|
|
by just appending .json at the end of any of the url.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4797
|
2022-02-06 17:25:12 +01:00
|
|
|
02:53:19,500 --> 02:53:24,500
|
|
|
|
So in that case in this event we're going to get the json representation of the event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4800
|
2022-02-06 17:25:12 +01:00
|
|
|
02:53:24,500 --> 02:53:26,500
|
|
|
|
Okay.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4801
|
2022-02-06 17:25:12 +01:00
|
|
|
02:53:28,0 --> 02:53:32,500
|
|
|
|
So that's basically for creating an event.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4804
|
2022-02-06 17:25:12 +01:00
|
|
|
02:53:32,500 --> 02:53:37,500
|
|
|
|
Just maybe one thing that is interesting we have a very good question from Martin {inaudible}.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4806
|
2022-02-06 17:25:12 +01:00
|
|
|
02:53:37,500 --> 02:53:44,500
|
|
|
|
It's a quite complex one but maybe we can already partially answer it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4808
|
2022-02-06 17:25:12 +01:00
|
|
|
02:53:44,500 --> 02:53:51,500
|
|
|
|
So when you create an event and in this case the creator of the training.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4811
|
2022-02-06 17:25:12 +01:00
|
|
|
02:53:51,500 --> 02:53:59,500
|
|
|
|
People can contribute on that one but if you have an ISAC and you want to distribute back the information and so on,
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
4815
|
2022-02-06 17:25:12 +01:00
|
|
|
02:53:59,500 --> 02:54:05,500
|
|
|
|
one of the options that you have is to try to create extended events for example out of it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4818
|
2022-02-06 17:25:12 +01:00
|
|
|
02:54:05,500 --> 02:54:14,0
|
|
|
|
So you can out of an event, you can create a new one which would be for example with additional information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4822
|
2022-02-06 17:25:12 +01:00
|
|
|
02:54:14,0 --> 02:54:22,0
|
|
|
|
like validations, additional things that you want to add. So you have this kind of extend event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4825
|
2022-02-06 17:25:12 +01:00
|
|
|
02:54:22,0 --> 02:54:27,0
|
|
|
|
and you will create automatically a new event based on that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4826
|
2022-02-06 17:25:12 +01:00
|
|
|
02:54:27,0 --> 02:54:39,0
|
|
|
|
A thing that is interesting there, the thing is you can really create something completely new out of it
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4832
|
2022-02-06 17:25:12 +01:00
|
|
|
02:54:39,0 --> 02:54:46,500
|
|
|
|
and then see, so for example, for this case I can say that we did a kind of session with additional information.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4836
|
2022-02-06 17:25:12 +01:00
|
|
|
02:54:46,500 --> 02:54:51,500
|
|
|
|
There the distribution is "Your organization only"
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4838
|
2022-02-06 17:25:12 +01:00
|
|
|
02:54:51,500 --> 02:55:01,500
|
|
|
|
and I would add for example a specific attribute which is for example "Targeting data"
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4841
|
2022-02-06 17:25:12 +01:00
|
|
|
02:55:01,500 --> 02:55:08,500
|
|
|
|
and I can say "target-user", the son of the prime minister.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4843
|
2022-02-06 17:25:12 +01:00
|
|
|
02:55:08,500 --> 02:55:13,500
|
|
|
|
So it may be information that you really don't want to share with others.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4844
|
2022-02-06 17:25:12 +01:00
|
|
|
02:55:13,500 --> 02:55:19,500
|
|
|
|
So this one is basically a normal event with additional information there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4845
|
2022-02-06 17:25:12 +01:00
|
|
|
02:55:19,500 --> 02:55:23,500
|
|
|
|
and it's only shared within your organization.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4850
|
2022-02-06 17:25:12 +01:00
|
|
|
02:55:23,500 --> 02:55:29,500
|
|
|
|
Nevertheless, if you go to the original event, you have this kind of extended view there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4853
|
2022-02-06 17:25:12 +01:00
|
|
|
02:55:29,500 --> 02:55:36,500
|
|
|
|
and we can have what we call an extended view and not an atomic view
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4855
|
2022-02-06 17:25:12 +01:00
|
|
|
02:55:36,500 --> 02:55:41,500
|
|
|
|
and the two information is combined and you can see there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4856
|
2022-02-06 17:25:12 +01:00
|
|
|
02:55:41,500 --> 02:55:46,500
|
|
|
|
that we have one with the information about the son of the prime minister
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4859
|
2022-02-06 17:25:12 +01:00
|
|
|
02:55:46,500 --> 02:55:52,500
|
|
|
|
which is the extended event there. So just to answer the question of Martin
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
4861
|
|
|
|
02:55:52,500 --> 02:55:59,500
|
|
|
|
about the question about adding information on existing event, this is one way of doing it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
4865
|
|
|
|
02:55:59,500 --> 02:56:07,500
|
|
|
|
So using extended event is a way to qualify or extend event with additional information and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4868
|
2022-02-06 17:25:12 +01:00
|
|
|
02:56:07,500 --> 02:56:12,500
|
|
|
|
It's actively used, for example, for when you have two different view of the information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4871
|
2022-02-06 17:25:12 +01:00
|
|
|
02:56:12,500 --> 02:56:17,500
|
|
|
|
because one is distributed and another one is like the private information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4872
|
2022-02-06 17:25:12 +01:00
|
|
|
02:56:17,500 --> 02:56:20,500
|
|
|
|
like the forensic evidence that you cannot share for example,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4873
|
2022-02-06 17:25:12 +01:00
|
|
|
02:56:20,500 --> 02:56:24,500
|
|
|
|
you can create this kind of thing. It's one way of doing it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4877
|
2022-02-06 17:25:12 +01:00
|
|
|
02:56:24,500 --> 02:56:28,500
|
|
|
|
It's not answering completely the question of Martin but we can even go deeper later on that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4878
|
2022-02-06 17:25:12 +01:00
|
|
|
02:56:28,500 --> 02:56:33,500
|
|
|
|
but it's one way of... because tomorrow we talk about synchronization
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4883
|
2022-02-06 17:25:12 +01:00
|
|
|
02:56:33,500 --> 02:56:39,500
|
|
|
|
there are some specific options for ISAC like unpublishing events if we do synchronization and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4887
|
2022-02-06 17:25:12 +01:00
|
|
|
02:56:39,500 --> 02:56:46,500
|
|
|
|
that can be used in some some cases for ISAC. There are many options but that's one way of
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4890
|
2022-02-06 17:25:12 +01:00
|
|
|
02:56:46,500 --> 02:56:54,500
|
|
|
|
partially solving this kind of issues of not owning the data. It is to extend the information.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4894
|
2022-02-06 17:25:12 +01:00
|
|
|
02:56:54,500 --> 02:56:58,500
|
|
|
|
So I know you have something you want to add on Alexandre.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4896
|
2022-02-06 17:25:12 +01:00
|
|
|
02:56:58,500 --> 02:57:02,0
|
|
|
|
No, no, that makes sense.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4898
|
2022-02-06 17:25:12 +01:00
|
|
|
02:57:03,0 --> 02:57:08,500
|
|
|
|
Again for the collaboration on this one, we can do various things so
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4899
|
2022-02-06 17:25:12 +01:00
|
|
|
02:57:08,500 --> 02:57:13,500
|
|
|
|
in the case of, you have a typo for example in the specifications and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4901
|
2022-02-06 17:25:12 +01:00
|
|
|
02:57:13,500 --> 02:57:19,500
|
|
|
|
you can make proposal, another thing with on the interface here you see that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4905
|
2022-02-06 17:25:12 +01:00
|
|
|
02:57:19,500 --> 02:57:26,500
|
|
|
|
you can basically make either an edit or you see that you can make a proposed edit.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4907
|
2022-02-06 17:25:12 +01:00
|
|
|
02:57:26,500 --> 02:57:31,500
|
|
|
|
So what is the use case for that? It's not like for fundamental changes
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4911
|
2022-02-06 17:25:12 +01:00
|
|
|
02:57:31,500 --> 02:57:34,500
|
|
|
|
but for I would say minor challenges on a specific report.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4912
|
2022-02-06 17:25:12 +01:00
|
|
|
02:57:34,500 --> 02:57:40,0
|
|
|
|
Imagine that you don't agree on this IP Address, there's a typo
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4915
|
2022-02-06 17:25:12 +01:00
|
|
|
02:57:40,0 --> 02:57:46,500
|
|
|
|
and it's not D5 but E5 in the ipv6 address, so you propose the change.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4916
|
2022-02-06 17:25:12 +01:00
|
|
|
02:57:46,500 --> 02:57:50,500
|
|
|
|
in this case i'm playing both roles here but what do I have here,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4920
|
2022-02-06 17:25:12 +01:00
|
|
|
02:57:50,500 --> 02:57:56,500
|
|
|
|
it's basically an attribute with a proposal of the change and I'm playing the both roles
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4922
|
2022-02-06 17:25:12 +01:00
|
|
|
02:57:56,500 --> 02:58:04,500
|
|
|
|
contributor roles and the original creator then I can say, okay I accept the change there indeed,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4925
|
2022-02-06 17:25:12 +01:00
|
|
|
02:58:04,500 --> 02:58:12,500
|
|
|
|
this proposal makes sense or basically discard and this is a way to get updates
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4926
|
2022-02-06 17:25:12 +01:00
|
|
|
02:58:12,500 --> 02:58:19,500
|
|
|
|
from supportive other members, other organizations and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4930
|
2022-02-06 17:25:12 +01:00
|
|
|
02:58:19,500 --> 02:58:25,500
|
|
|
|
It's one way to to update the information in this case I will discard it because it's not correct.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4933
|
2022-02-06 17:25:12 +01:00
|
|
|
02:58:25,500 --> 02:58:31,500
|
|
|
|
We were talking about contributions, this is another way of contributing is the sighting itself.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4936
|
2022-02-06 17:25:12 +01:00
|
|
|
02:58:31,500 --> 02:58:37,0
|
|
|
|
So for example for this indicator if for example we have an intrusion detection system
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4937
|
2022-02-06 17:25:12 +01:00
|
|
|
02:58:37,0 --> 02:58:40,500
|
|
|
|
and we have seen it like three times in a row
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4939
|
2022-02-06 17:25:12 +01:00
|
|
|
02:58:40,500 --> 02:58:49,0
|
|
|
|
we can add on the interface, with the API, through the user interface, and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4943
|
2022-02-06 17:25:12 +01:00
|
|
|
02:58:49,0 --> 02:58:59,500
|
|
|
|
that you have seen that multiple times and like that you can share this kind of details about the sharing aspect
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4947
|
2022-02-06 17:25:12 +01:00
|
|
|
02:58:59,500 --> 02:59:03,500
|
|
|
|
So what we have seen that at this specific amount of times we have the three counts
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4948
|
2022-02-06 17:25:12 +01:00
|
|
|
02:59:01,200 --> 02:59:09,500
|
|
|
|
saying this is a sighting and you have seen it and you can do it per organization
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4949
|
2022-02-06 17:25:12 +01:00
|
|
|
02:59:02,799 --> 02:59:14,500
|
|
|
|
or it could be even anonymously you get different configuration in the model of sighting in MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4956
|
2022-02-06 17:25:12 +01:00
|
|
|
02:59:15,439 --> 02:59:20,0
|
|
|
|
but it's a way to see that an indicator has been seen or not.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4957
|
2022-02-06 17:25:12 +01:00
|
|
|
02:59:18,159 --> 02:59:26,500
|
|
|
|
If one specific {inaudible} for example a false positive you can see the negative one,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4961
|
2022-02-06 17:25:12 +01:00
|
|
|
02:59:25,600 --> 02:59:33,500
|
|
|
|
negative sightings which basically tell others that okay this one is generating a lot of false positives
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4962
|
2022-02-06 17:25:12 +01:00
|
|
|
02:59:33,840 --> 02:59:36,500
|
|
|
|
sometimes not every organization agrees on the false positive
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4965
|
2022-02-06 17:25:12 +01:00
|
|
|
02:59:35,840 --> 02:59:40,500
|
|
|
|
because they have different views coming from different networks and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4968
|
2022-02-06 17:25:12 +01:00
|
|
|
02:59:40,799 --> 02:59:51,500
|
|
|
|
That's a way to provide feedback, so one is delegations proposals or another way is to basically get sighting.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4972
|
2022-02-06 17:25:12 +01:00
|
|
|
02:59:57,0 --> 02:59:59,0
|
|
|
|
Okay.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4973
|
2022-02-06 17:25:12 +01:00
|
|
|
03:00:01,0 --> 03:00:04,0
|
|
|
|
I'm just trying to go through the questions
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4974
|
2022-02-06 17:25:12 +01:00
|
|
|
03:00:04,0 --> 03:00:06,500
|
|
|
|
yeah maybe there are some...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4976
|
2022-02-06 17:25:12 +01:00
|
|
|
03:00:07,279 --> 03:00:10,500
|
|
|
|
Yeah there are some that are repeating so perhaps it's good to call them out
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4978
|
2022-02-06 17:25:12 +01:00
|
|
|
03:00:10,559 --> 03:00:14,500
|
|
|
|
So there was a bit of confusion about how to add the email object.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4981
|
2022-02-06 17:25:12 +01:00
|
|
|
03:00:16,0 --> 03:00:20,0
|
|
|
|
So it is a little bit confusing so when you're in an event and you click on add objects,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4984
|
2022-02-06 17:25:12 +01:00
|
|
|
03:00:20,0 --> 03:00:24,0
|
|
|
|
first you need to select the scope from which you choose from
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4985
|
2022-02-06 17:25:12 +01:00
|
|
|
03:00:24,0 --> 03:00:26,0
|
|
|
|
So it's going to be climate file and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4986
|
2022-02-06 17:25:12 +01:00
|
|
|
03:00:26,0 --> 03:00:30,500
|
|
|
|
Just click on all objects if you're unsure and then you can search for whatever.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4989
|
2022-02-06 17:25:12 +01:00
|
|
|
03:00:30,500 --> 03:00:35,500
|
|
|
|
So after you click on all objects and you type email, it's going to show email object.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4992
|
2022-02-06 17:25:12 +01:00
|
|
|
03:00:35,500 --> 03:00:39,500
|
|
|
|
Here the first step is more like finding out the category of an object
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
4994
|
|
|
|
03:00:39,500 --> 03:00:44,500
|
|
|
|
Yeah so some sometimes you just know the category but you don't know what is really available there for you
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4997
|
2022-02-06 17:25:12 +01:00
|
|
|
03:00:44,500 --> 03:00:49,500
|
|
|
|
So you want to see okay what sort of objects can I use in network contacts
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
4999
|
2022-02-06 17:25:12 +01:00
|
|
|
03:00:49,500 --> 03:00:50,500
|
|
|
|
and I would click on network first
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5000
|
2022-02-06 17:25:12 +01:00
|
|
|
03:00:50,500 --> 03:00:54,500
|
|
|
|
and then you get a list of of all tangently related objects
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5002
|
2022-02-06 17:25:12 +01:00
|
|
|
03:00:54,500 --> 03:01:01,500
|
|
|
|
that will have to do with network connectivity but not necessarily describing the same concept at all
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5006
|
2022-02-06 17:25:12 +01:00
|
|
|
03:01:01,500 --> 03:01:06,500
|
|
|
|
but if you don't know which domain you want to pick it from
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5007
|
2022-02-06 17:25:12 +01:00
|
|
|
03:01:06,500 --> 03:01:11,500
|
|
|
|
or if you know exactly already what you want and you just want to search by name
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5010
|
2022-02-06 17:25:12 +01:00
|
|
|
03:01:11,500 --> 03:01:14,500
|
|
|
|
Just click on all objects first and then you will find what you're looking for
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5013
|
2022-02-06 17:25:12 +01:00
|
|
|
03:01:14,500 --> 03:01:19,500
|
|
|
|
by just typing it. So email is easy to find that way.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5015
|
2022-02-06 17:25:12 +01:00
|
|
|
03:01:19,500 --> 03:01:24,0
|
|
|
|
Okay so just type email and that's it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5016
|
2022-02-06 17:25:12 +01:00
|
|
|
03:01:24,0 --> 03:01:32,500
|
|
|
|
Okay, other questions that were there. Okay perfect.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5018
|
2022-02-06 17:25:12 +01:00
|
|
|
03:01:33,0 --> 03:01:37,0
|
|
|
|
And there there were a few other questions that I answered in the ...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5020
|
2022-02-06 17:25:12 +01:00
|
|
|
03:01:37,0 --> 03:01:40,500
|
|
|
|
Meanwhile, maybe it's a good idea to read some of them out.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5021
|
2022-02-06 17:25:12 +01:00
|
|
|
03:01:40,500 --> 03:01:45,500
|
|
|
|
Yeah, indeed there was a good one about correlation graph and filtering on it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5025
|
2022-02-06 17:25:12 +01:00
|
|
|
03:01:45,500 --> 03:01:48,500
|
|
|
|
Indeed, we don't have a way to filter the correlation graph
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5026
|
2022-02-06 17:25:12 +01:00
|
|
|
03:01:48,500 --> 03:01:52,500
|
|
|
|
but it's something that we've discussed for a while already and we want to do it at one point
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5030
|
2022-02-06 17:25:12 +01:00
|
|
|
03:01:52,500 --> 03:01:54,500
|
|
|
|
so that you can add some filter rules in there.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5032
|
2022-02-06 17:25:12 +01:00
|
|
|
03:01:54,500 --> 03:01:59,00
|
|
|
|
Yes, the only way to to do it here is through the api
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5034
|
2022-02-06 17:25:12 +01:00
|
|
|
03:01:59,00 --> 03:02:05,500
|
|
|
|
so that means you done creating one and then you have to do a filtering {inaudible priority/proactively}
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5037
|
2022-02-06 17:25:12 +01:00
|
|
|
03:02:05,500 --> 03:02:10,500
|
|
|
|
but it needs something there to be added
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5039
|
2022-02-06 17:25:12 +01:00
|
|
|
03:02:10,500 --> 03:02:13,500
|
|
|
|
I don't know if you have an issue on that one.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5041
|
2022-02-06 17:25:12 +01:00
|
|
|
03:02:13,500 --> 03:02:16,500
|
|
|
|
Yeah I think we do. Yes, yes, I think we should be good.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5042
|
2022-02-06 17:25:12 +01:00
|
|
|
03:02:16,500 --> 03:02:23,500
|
|
|
|
So maybe you know what sometimes what we do is just to add the one on this one
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5045
|
2022-02-06 17:25:12 +01:00
|
|
|
03:02:23,500 --> 03:02:28,500
|
|
|
|
If i can find it back so I guess you can see what kind of issue that we have and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5048
|
2022-02-06 17:25:12 +01:00
|
|
|
03:02:28,500 --> 03:02:32,0
|
|
|
|
A lot of the issue that we have is more like
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5049
|
2022-02-06 17:25:12 +01:00
|
|
|
03:02:32,0 --> 03:02:26,500
|
|
|
|
I mean around 25 percent, 30 percent are basically installation problem.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5052
|
2022-02-06 17:25:12 +01:00
|
|
|
03:02:26,500 --> 03:02:43,500
|
|
|
|
That's something that you can discuss maybe tomorrow about recommendation on the system
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5056
|
2022-02-06 17:25:12 +01:00
|
|
|
03:02:43,500 --> 03:02:48,0
|
|
|
|
We don't need a lot of requirements but at least you need to have a LAMP system working
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5059
|
2022-02-06 17:25:12 +01:00
|
|
|
03:02:48,0 --> 03:02:51,500
|
|
|
|
So MariaDB, linux systems and Redis running.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5061
|
2022-02-06 17:25:12 +01:00
|
|
|
03:02:51,500 --> 03:02:59,500
|
|
|
|
So obviously, for example, an Ubuntu distribution out of the box is working without any problems.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5064
|
2022-02-06 17:25:12 +01:00
|
|
|
03:02:59,500 --> 03:03:04,500
|
|
|
|
Now if you try to install a MISP on the MAC OS, you might run into problems obviously.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5067
|
2022-02-06 17:25:12 +01:00
|
|
|
03:03:04,500 --> 03:03:11,500
|
|
|
|
But what we recommend is we have automatic install script for ubuntu for example
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5070
|
2022-02-06 17:25:12 +01:00
|
|
|
03:03:11,500 --> 03:03:13,500
|
|
|
|
and this one works works quite well.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5072
|
2022-02-06 17:25:12 +01:00
|
|
|
03:03:13,500 --> 03:03:19,0
|
|
|
|
I wanted to search the issue for...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5073
|
2022-02-06 17:25:12 +01:00
|
|
|
03:03:19,0 --> 03:03:21,500
|
|
|
|
You can just search the correlation graph, for correlation.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5074
|
2022-02-06 17:25:12 +01:00
|
|
|
03:03:21,500 --> 03:03:24,500
|
|
|
|
Yeah. correlation filtering.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5075
|
2022-02-06 17:25:12 +01:00
|
|
|
03:03:24,500 --> 03:03:30,500
|
|
|
|
Nah, that will be a bit too specific I think. No maybe not. Maybe yes.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5078
|
2022-02-06 17:25:12 +01:00
|
|
|
03:03:30,500 --> 03:03:32,500
|
|
|
|
We're filtering by correlation on {inaudible}.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5081
|
2022-02-06 17:25:12 +01:00
|
|
|
03:03:32,500 --> 03:03:51,500
|
|
|
|
Oh this one maybe. Yes. Yeah, yeah okay, this one, okay. So... One sec.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5082
|
2022-02-06 17:25:12 +01:00
|
|
|
03:03:51,500 --> 03:04:07,500
|
|
|
|
So that's how it works so if you see a component issue that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5086
|
2022-02-06 17:25:12 +01:00
|
|
|
03:04:07,500 --> 03:04:09,500
|
|
|
|
or a feature that is really interesting for you
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5087
|
2022-02-06 17:25:12 +01:00
|
|
|
03:04:09,500 --> 03:04:14,500
|
|
|
|
don't hesitate to take an existing issue about specific requests and add some comments there.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5090
|
2022-02-06 17:25:12 +01:00
|
|
|
03:04:14,500 --> 03:04:20,500
|
|
|
|
Like for example, it's really the feature that you want, is it important for you, why and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5093
|
2022-02-06 17:25:12 +01:00
|
|
|
03:04:20,500 --> 03:04:23,500
|
|
|
|
and then we use that as a source of of doing a feature request
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5095
|
2022-02-06 17:25:12 +01:00
|
|
|
03:04:23,500 --> 03:04:29,500
|
|
|
|
As an example, we do a release of MISP every three weeks usually
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5098
|
2022-02-06 17:25:12 +01:00
|
|
|
03:04:29,500 --> 03:04:35,0
|
|
|
|
and there are many new features on each release
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5100
|
2022-02-06 17:25:12 +01:00
|
|
|
03:04:35,0 --> 03:04:43,0
|
|
|
|
As an example we had a request like that someone just fixed two days ago about the events...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5102
|
2022-02-06 17:25:12 +01:00
|
|
|
03:04:43,0 --> 03:04:49,500
|
|
|
|
Oh we didn't even show it. Event timeline and then
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5103
|
2022-02-06 17:25:12 +01:00
|
|
|
03:04:49,500 --> 03:04:51,500
|
|
|
|
we wanted to have something that is easy to set the number of days
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5104
|
2022-02-06 17:25:12 +01:00
|
|
|
03:04:51,500 --> 03:04:55,500
|
|
|
|
and then he added the new feature. So sometimes it makes a lot of sense
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5105
|
2022-02-06 17:25:12 +01:00
|
|
|
03:04:55,500 --> 03:05:00,500
|
|
|
|
so don't hesitate to create an issue and and propose a new feature.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5113
|
2022-02-06 17:25:12 +01:00
|
|
|
03:05:00,500 --> 03:05:08,500
|
|
|
|
Which remind me of showing you the event timeline because we didn't really show it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5116
|
2022-02-06 17:25:12 +01:00
|
|
|
03:05:08,500 --> 03:05:18,500
|
|
|
|
So you see that on this one we have nearly everything on the same time
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5118
|
2022-02-06 17:25:12 +01:00
|
|
|
03:05:18,500 --> 03:05:28,500
|
|
|
|
which is basically the time when we create the different object we just set the time for one so...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5120
|
2022-02-06 17:25:12 +01:00
|
|
|
03:05:28,500 --> 03:05:34,500
|
|
|
|
and then I can basically look at this one and this one is like the..
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5125
|
2022-02-06 17:25:12 +01:00
|
|
|
03:05:34,500 --> 03:05:38,500
|
|
|
|
Yeah, I don't know why we don't have the expansion on that one.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5127
|
2022-02-06 17:25:12 +01:00
|
|
|
03:05:38,500 --> 03:05:45,0
|
|
|
|
so for example if you have a specific time we can expand it and even change it in the graph
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5130
|
2022-02-06 17:25:12 +01:00
|
|
|
03:05:45,0 --> 03:05:47,500
|
|
|
|
so that means if we have for example this email,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5134
|
2022-02-06 17:25:12 +01:00
|
|
|
03:05:47,500 --> 03:05:54,0
|
|
|
|
a thing that we can do is expand it and change when this has been seen
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5135
|
2022-02-06 17:25:12 +01:00
|
|
|
03:05:54,0 --> 03:06:00,0
|
|
|
|
and we can even change at which time this specific model has been seen.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5138
|
2022-02-06 17:25:12 +01:00
|
|
|
03:06:00,0 --> 03:06:10,500
|
|
|
|
But that's again a good point to do is to automatically create a first thing last seen on your element.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5141
|
2022-02-06 17:25:12 +01:00
|
|
|
03:06:10,500 --> 03:06:16,0
|
|
|
|
Because every time you do that you will get an automatic timeline and actually a quick
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5142
|
2022-02-06 17:25:12 +01:00
|
|
|
03:06:16,0 --> 03:06:19,500
|
|
|
|
I would say quick win when you do analysis.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5146
|
2022-02-06 17:25:12 +01:00
|
|
|
03:06:23,0 --> 03:06:28,500
|
|
|
|
So if there are no more questions about event creation perhaps one of the things we can do is show the searching.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5149
|
2022-02-06 17:25:12 +01:00
|
|
|
03:06:28,500 --> 03:06:33,0
|
|
|
|
How to search for stuff in your MISP.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5150
|
2022-02-06 17:25:12 +01:00
|
|
|
03:06:36,0 --> 03:06:40,0
|
|
|
|
okay so this is something that we're going to show very briefly now
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5152
|
2022-02-06 17:25:12 +01:00
|
|
|
03:06:40,0 --> 03:06:42,500
|
|
|
|
and we're going to go in a bit more detail into this tomorrow
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5154
|
2022-02-06 17:25:12 +01:00
|
|
|
03:06:42,500 --> 03:06:47,500
|
|
|
|
when we're also going to look at the api but generally whenever you're searching in MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5157
|
2022-02-06 17:25:12 +01:00
|
|
|
03:06:47,500 --> 03:06:52,500
|
|
|
|
the main question you need to ask yourself is what scope am I searching on?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5159
|
2022-02-06 17:25:12 +01:00
|
|
|
03:06:52,500 --> 03:06:56,500
|
|
|
|
Am i searching for individual attributes or am I searching for events?
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
5160
|
2022-02-06 17:25:12 +01:00
|
|
|
03:06:56,500 --> 03:07:01,500
|
|
|
|
The search filters very often overlapping or are almost the same
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5164
|
2022-02-06 17:25:12 +01:00
|
|
|
03:07:01,500 --> 03:07:03.500
|
|
|
|
but one of the things you need to keep in mind is for example
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5165
|
2022-02-06 17:25:12 +01:00
|
|
|
03:07:03.500 --> 03:07:08,500
|
|
|
|
if i'm searching for bitcoin addresses in my MISP instance, bitcoin wallets.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5169
|
2022-02-06 17:25:12 +01:00
|
|
|
03:07:08,500 --> 03:07:14,500
|
|
|
|
Am I searching for any event that contains at least one bitcoin address
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5171
|
2022-02-06 17:25:12 +01:00
|
|
|
03:07:14,500 --> 03:07:18,500
|
|
|
|
or am I searching for just the bitcoin addresses themselves?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5173
|
2022-02-06 17:25:12 +01:00
|
|
|
03:07:18,500 --> 03:07:21,0
|
|
|
|
So this is when we decide between different scopes
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5174
|
2022-02-06 17:25:12 +01:00
|
|
|
03:07:21,0 --> 03:07:26,500
|
|
|
|
so generally attribute scope will only give you the individual attributes that match the criteria
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5178
|
2022-02-06 17:25:12 +01:00
|
|
|
03:07:26,500 --> 03:07:31,500
|
|
|
|
and the event scope will give you everything that contains at least one matching value.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5180
|
2022-02-06 17:25:12 +01:00
|
|
|
03:07:31,500 --> 03:07:39,0
|
|
|
|
So here what Alex did, he just searched using the attribute search for all the bitcoin addresses in the instance
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5184
|
2022-02-06 17:25:12 +01:00
|
|
|
03:07:39,0 --> 03:07:41,500
|
|
|
|
and we see we get a bunch of them from different sources,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5186
|
2022-02-06 17:25:12 +01:00
|
|
|
03:07:41,500 --> 03:07:47,500
|
|
|
|
we see which events they're from which organization has created that information and so on and so forth
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5190
|
2022-02-06 17:25:12 +01:00
|
|
|
03:07:47,500 --> 03:07:54,500
|
|
|
|
If we're happy with the search results and we've set up all our features and we're getting exactly what we were looking for
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5192
|
2022-02-06 17:25:12 +01:00
|
|
|
03:07:54,500 --> 03:07:57,500
|
|
|
|
maybe even several pages of it like here.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5195
|
2022-02-06 17:25:12 +01:00
|
|
|
03:07:57,500 --> 03:08:00,500
|
|
|
|
We can download the results in any of these supported formats
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5196
|
2022-02-06 17:25:12 +01:00
|
|
|
03:08:00,500 --> 03:08:03,0
|
|
|
|
so we could say okay now we have all these bitcoin addresses out there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5197
|
2022-02-06 17:25:12 +01:00
|
|
|
03:08:03,0 --> 03:08:07,500
|
|
|
|
generate the csv out of it and it will generate a massive csv
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5200
|
2022-02-06 17:25:12 +01:00
|
|
|
03:08:07,500 --> 03:08:11,500
|
|
|
|
with all the attribute information for each of these.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5203
|
2022-02-06 17:25:12 +01:00
|
|
|
03:08:13,0 --> 03:08:17,500
|
|
|
|
I hope you're not running my time instance out of memory.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5205
|
2022-02-06 17:25:12 +01:00
|
|
|
03:08:19,0 --> 03:08:20,500
|
|
|
|
There it is.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5207
|
2022-02-06 17:25:12 +01:00
|
|
|
03:08:20,500 --> 03:08:28,500
|
|
|
|
So if you open it. Just to see the results quickly. There we go.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5209
|
2022-02-06 17:25:12 +01:00
|
|
|
03:08:28,500 --> 03:08:35,500
|
|
|
|
So in this case, we now downloaded our search results as csv.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5212
|
2022-02-06 17:25:12 +01:00
|
|
|
03:08:35,500 --> 03:08:38,500
|
|
|
|
Now keep in mind whenever you're dealing with integration of MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5213
|
2022-02-06 17:25:12 +01:00
|
|
|
03:08:38,500 --> 03:08:42,500
|
|
|
|
with other tools or exports keep in mind that certain formats don't really cater
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5216
|
2022-02-06 17:25:12 +01:00
|
|
|
03:08:42,500 --> 03:08:44,0
|
|
|
|
to exporting certain types of data.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5218
|
2022-02-06 17:25:12 +01:00
|
|
|
03:08:44,0 --> 03:08:50,500
|
|
|
|
So if you're searching for ransomware payout wallets.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5220
|
2022-02-06 17:25:12 +01:00
|
|
|
03:08:50,500 --> 03:08:55,500
|
|
|
|
you could, for example, specify as a tag, all the different ransomware related tags that you have
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5224
|
2022-02-06 17:25:12 +01:00
|
|
|
03:08:55,500 --> 03:09:01,0
|
|
|
|
and as a type select BTC like what Alex has done here and export the information.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5226
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:01,0 --> 03:09:03,500
|
|
|
|
Now when you're deciding what format to download in,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5228
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:03,500 --> 03:09:08,500
|
|
|
|
again, some don't make any sense so don't download bitcoin addresses in STIX format
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5229
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:08,500 --> 03:09:12,500
|
|
|
|
because STIX doesn't have a way to express bitcoin addresses for example.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5233
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:12,500 --> 03:09:17,0
|
|
|
|
So just make sure that you also take that into consideration when exporting data
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5235
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:17,0 --> 03:09:18,500
|
|
|
|
so that it's not {inaudible}.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5236
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:18,500 --> 03:09:24,500
|
|
|
|
Besides that we can do the same on the event level, we can also do searches on the event level.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5239
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:24,500 --> 03:09:28,500
|
|
|
|
If we go back to our event index, we have a little magnifying glass icon
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5240
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:28,500 --> 03:09:34,500
|
|
|
|
where you can add additional filter options to the index and filter the database on that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5245
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:34,500 --> 03:09:39,500
|
|
|
|
So let's just do "CIRCL", we're going to just filter on events coming from CIRCL
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5248
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:39,500 --> 03:09:42,500
|
|
|
|
and we can also add, for example, events that are not published.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5250
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:42,500 --> 03:09:46,500
|
|
|
|
If you wanted to do some final checks on whether...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5251
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:46,500 --> 03:09:49,500
|
|
|
|
We need to add the organization again.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5253
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:49,500 --> 03:09:52,500
|
|
|
|
whether we have any events that need to be vetted.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5254
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:52,500 --> 03:09:56,500
|
|
|
|
For example for our own organization, then we could use this filter for it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5257
|
2022-02-06 17:25:12 +01:00
|
|
|
03:09:56,500 --> 03:10:02,0
|
|
|
|
On the event index, all of these search filters that you apply generate a specific url
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5259
|
2022-02-06 17:25:12 +01:00
|
|
|
03:10:02,0 --> 03:10:06,500
|
|
|
|
and you can bookmark it, so if you have recurring queries that you want to monitor
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5263
|
2022-02-06 17:25:12 +01:00
|
|
|
03:10:06,500 --> 03:10:10,0
|
|
|
|
then you can just bookmark the url and you can go back to it later on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5265
|
2022-02-06 17:25:12 +01:00
|
|
|
03:10:10,0 --> 03:10:13,500
|
|
|
|
and see if there is anything that popped up that matches your search criteria.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5267
|
2022-02-06 17:25:12 +01:00
|
|
|
03:10:14,0 --> 03:10:21,0
|
|
|
|
now generally like I think 90% of our searches do not actually happen via the UI
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5270
|
2022-02-06 17:25:12 +01:00
|
|
|
03:10:21,0 --> 03:10:25,500
|
|
|
|
they happen via the API, so very often you have tools that you search through
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5272
|
2022-02-06 17:25:12 +01:00
|
|
|
03:10:25,500 --> 03:10:30,500
|
|
|
|
So if you have a tool that acts as a front-end for your MISP for certain searches that works as well.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5276
|
2022-02-06 17:25:12 +01:00
|
|
|
03:10:32,0 --> 03:10:36,500
|
|
|
|
We're going to talk more about those type of searches and how you integrate with other tools tomorrow more
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5279
|
2022-02-06 17:25:12 +01:00
|
|
|
03:10:36,500 --> 03:10:39,0
|
|
|
|
When we go into the api
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5280
|
2022-02-06 17:25:12 +01:00
|
|
|
03:10:39,0 --> 03:10:42,500
|
|
|
|
There is a question about soft delete attribute search
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5282
|
2022-02-06 17:25:12 +01:00
|
|
|
03:10:42,500 --> 03:10:44,0
|
|
|
|
I just lost the Q&A page.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5283
|
2022-02-06 17:25:12 +01:00
|
|
|
03:10:44,0 --> 03:10:49,500
|
|
|
|
So Martin asks "is there a way to do a global search for soft delete attributes?"
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5285
|
2022-02-06 17:25:12 +01:00
|
|
|
03:10:49,500 --> 03:10:54,500
|
|
|
|
Yes, sorry, where is it? For soft delete attributes? Yes there is.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5288
|
2022-02-06 17:25:12 +01:00
|
|
|
03:10:54,500 --> 03:11:01,0
|
|
|
|
So not via the UI but via the API which you can also access via the UI by the way.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5290
|
2022-02-06 17:25:12 +01:00
|
|
|
03:11:01,0 --> 03:11:04,500
|
|
|
|
We have a tool. We have a built-in tool. We can even show this example there.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
5291
|
|
|
|
03:11:04,500 --> 03:11:07,500
|
|
|
|
we didn't show the delete
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5294
|
2022-02-06 17:25:12 +01:00
|
|
|
03:11:07,500 --> 03:11:08,500
|
|
|
|
Haha, that's a good point.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
5294
|
|
|
|
03:11:08,500 --> 03:11:14,500
|
|
|
|
Let's start with the question first and then we go to the delete
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
S296
|
|
|
|
03:11:14,500 --> 03:11:20,500
|
|
|
|
so we have this built-in tool called the "REST client" that allows us to run searches directly from the interface.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5299
|
2022-02-06 17:25:12 +01:00
|
|
|
03:11:20,500 --> 03:11:25,500
|
|
|
|
So generally indeed we have a soft delete mechanism in MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5300
|
2022-02-06 17:25:12 +01:00
|
|
|
03:11:25,500 --> 03:11:31,500
|
|
|
|
that allows you to to not fully remove an attribute but mark it for deletion.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5304
|
2022-02-06 17:25:12 +01:00
|
|
|
03:11:32,238 --> 03:11:36,500
|
|
|
|
The reason why we do this in general is whenever we're synchronizing information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5306
|
|
|
|
03:11:36,159 --> 03:11:38,799
|
2022-02-06 17:25:12 +01:00
|
|
|
and we delete an attribute we want to inform all the other instances
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5307
|
2022-02-06 17:25:12 +01:00
|
|
|
03:11:37,439 --> 03:11:41,500
|
|
|
|
that an attribute needs to be removed, it is revoked.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5310
|
2022-02-06 17:25:12 +01:00
|
|
|
03:11:42,159 --> 03:11:47,500
|
|
|
|
So this is why we do the soft delete where we hide it from the interface, we hide it from the exports
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5313
|
2022-02-06 17:25:12 +01:00
|
|
|
03:11:48,478 --> 03:11:53,500
|
|
|
|
but we still keep the data and we inform the other instances that they need to also mark it for deletion.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5316
|
2022-02-06 17:25:12 +01:00
|
|
|
03:11:54,0 --> 03:11:59,500
|
|
|
|
Now if the question is how do we do a global search for all the soft deleted attributes.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5318
|
2022-02-06 17:25:12 +01:00
|
|
|
03:11:58,799 --> 03:12:04,500
|
|
|
|
So first of all what we need to do using our little REST search tool is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5321
|
2022-02-06 17:25:12 +01:00
|
|
|
03:12:04,478 --> 03:12:09,500
|
|
|
|
by the way we have the Modern APIs here, so to create a new API unless you know yours by heart
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5324
|
2022-02-06 17:25:12 +01:00
|
|
|
03:12:12,0 --> 03:12:22,500
|
|
|
|
so alex because... So just quickly, so in the meanwhile what Alex is doing now is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5327
|
2022-02-06 17:25:12 +01:00
|
|
|
03:12:20,478 --> 03:12:28,500
|
|
|
|
he's going to generate a new api key for himself so that we can actually test the api queries.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5331
|
2022-02-06 17:25:12 +01:00
|
|
|
03:12:28,500 --> 03:12:31,500
|
|
|
|
Oh that won't work.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5332
|
2022-02-06 17:25:12 +01:00
|
|
|
03:12:31,500 --> 03:12:37,500
|
|
|
|
Yeah you can add another key from here as well, this will work.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5333
|
2022-02-06 17:25:12 +01:00
|
|
|
03:12:37,500 --> 03:12:39,500
|
|
|
|
Yeah that works.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5335
|
2022-02-06 17:25:12 +01:00
|
|
|
03:12:59,0 --> 03:13:02,500
|
|
|
|
Global action, my profile, by the way if you want to find your profile.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5337
|
2022-02-06 17:25:12 +01:00
|
|
|
03:13:17,0 --> 03:13:19,500
|
|
|
|
Okay, so now we have our api key.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5338
|
2022-02-06 17:25:12 +01:00
|
|
|
03:13:19,500 --> 03:13:23,500
|
|
|
|
Now we go to REST client we just paste it in there now in the authorization field.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5341
|
2022-02-06 17:25:12 +01:00
|
|
|
03:13:27,0 --> 03:13:30,0
|
|
|
|
Here we go and now what we're going to do is we're going to run a search
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5343
|
2022-02-06 17:25:12 +01:00
|
|
|
03:13:30,0 --> 03:13:34,500
|
|
|
|
for all soft delete attributes so we're going to search for attribute restSearch.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5345
|
2022-02-06 17:25:12 +01:00
|
|
|
03:13:34,500 --> 03:13:38,500
|
|
|
|
So that is a scope that allows us to search on the attribute level.
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
5347
|
2022-02-06 17:25:12 +01:00
|
|
|
03:13:38,500 --> 03:13:42,500
|
|
|
|
we'll see more of this tomorrow, just a small example.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5349
|
2022-02-06 17:25:12 +01:00
|
|
|
03:13:42,500 --> 03:13:47,0
|
|
|
|
For return format, let's pick something like JSON
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5350
|
2022-02-06 17:25:12 +01:00
|
|
|
03:13:54,0 --> 03:14:00,0
|
|
|
|
and perhaps set a page under limit or take one limit 100 or something like that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5354
|
2022-02-06 17:25:12 +01:00
|
|
|
03:14:01,120 --> 03:14:03,500
|
|
|
|
I don't know how much was deleted here but it might be a lot
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5356
|
2022-02-06 17:25:12 +01:00
|
|
|
03:14:04,639 --> 03:14:07,500
|
|
|
|
and then just add another key deleted, there we go
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5358
|
2022-02-06 17:25:12 +01:00
|
|
|
03:14:07,500 --> 03:14:16,0
|
|
|
|
and then deleted set to 1
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5359
|
2022-02-06 17:25:12 +01:00
|
|
|
03:14:16,0 --> 03:14:19,0
|
2021-12-27 05:45:03 +01:00
|
|
|
and we don't need anything else
|
|
|
|
|
|
|
|
5360
|
2022-02-06 17:25:12 +01:00
|
|
|
03:14:19,0 --> 03:14:26,500
|
|
|
|
and this will return the first 100 hits from the instance of attributes that are deleted.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5363
|
2022-02-06 17:25:12 +01:00
|
|
|
03:14:30,0 --> 03:14:35,0
|
|
|
|
There we go And now if you wanted to paginate through all these attributes
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5364
|
2022-02-06 17:25:12 +01:00
|
|
|
03:14:33,600 --> 03:14:37,500
|
|
|
|
you would have to just raise the page number.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5367
|
2022-02-06 17:25:12 +01:00
|
|
|
03:14:37,500 --> 03:14:40,500
|
|
|
|
Go back and and get page 2, page 3, page 4, and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5369
|
2022-02-06 17:25:12 +01:00
|
|
|
03:14:40,500 --> 03:14:44,500
|
|
|
|
or if we have enough memory certainly my training instance definitely doesn't
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5371
|
2022-02-06 17:25:12 +01:00
|
|
|
03:14:44,500 --> 03:14:47,500
|
|
|
|
then we could just say give us everything in one shot.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5373
|
2022-02-06 17:25:12 +01:00
|
|
|
03:14:49,0 --> 03:14:53,500
|
|
|
|
Okay so I hope that answers your question Martin.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5375
|
2022-02-06 17:25:12 +01:00
|
|
|
03:14:53,500 --> 03:14:58,500
|
|
|
|
There is also a question, is there an official MISP docker image?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5377
|
2022-02-06 17:25:12 +01:00
|
|
|
03:14:58,500 --> 03:15:04,500
|
|
|
|
There are actually several, they're not maintained by us but by contributors
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5380
|
2022-02-06 17:25:12 +01:00
|
|
|
03:15:04,500 --> 03:15:08,500
|
|
|
|
that are very active and working closely with us.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5382
|
2022-02-06 17:25:12 +01:00
|
|
|
03:15:08,500 --> 03:15:12,500
|
|
|
|
So I've pasted one example in the zoom group chat.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5384
|
2022-02-06 17:25:12 +01:00
|
|
|
03:15:12,500 --> 03:15:18,500
|
|
|
|
I don't know if maybe it's not visible to everyone. I can just drop it as an answer here.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5387
|
2022-02-06 17:25:12 +01:00
|
|
|
03:15:18,500 --> 03:15:20,500
|
|
|
|
Yeah, it's better.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5388
|
2022-02-06 17:25:12 +01:00
|
|
|
03:15:20,500 --> 03:15:25,500
|
|
|
|
So this one is done by coolacid, so why are there are so many docker MISP?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5390
|
2022-02-06 17:25:12 +01:00
|
|
|
03:15:25,500 --> 03:15:34,0
|
|
|
|
That's I think the specialty of docker, not everyone agrees on a model with docker
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5392
|
2022-02-06 17:25:12 +01:00
|
|
|
03:15:34,0 --> 03:15:38,0
|
|
|
|
so there are at least as far as I know four or five different dockers
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5394
|
2022-02-06 17:25:12 +01:00
|
|
|
03:15:38,0 --> 03:15:43,500
|
|
|
|
there's one managed by DCSO, one by CoolAcid, one by Xavier Mertens and
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5397
|
2022-02-06 17:25:12 +01:00
|
|
|
03:15:43,500 --> 03:15:47,00
|
|
|
|
one by HarvardSecurity and I'm sure I'm missing some.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5399
|
2022-02-06 17:25:12 +01:00
|
|
|
03:15:47,00 --> 03:15:55,500
|
|
|
|
So the thing is for the docker images it's depending on I would say your taste
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5402
|
2022-02-06 17:25:12 +01:00
|
|
|
03:15:55,500 --> 03:15:59,500
|
|
|
|
so have a look at what the different contributors are doing
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5404
|
2022-02-06 17:25:12 +01:00
|
|
|
03:15:59,500 --> 03:16:05,500
|
|
|
|
and you'll see that you pick the one that is matching what you really want to do with docker.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5408
|
2022-02-06 17:25:12 +01:00
|
|
|
03:16:05,500 --> 03:16:12,500
|
|
|
|
Some are really more separated container wise some are more like one single container with everything
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5412
|
2022-02-06 17:25:12 +01:00
|
|
|
03:16:12,500 --> 03:16:16,500
|
|
|
|
Again it's a maker of taste and how you want to operate one
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5414
|
2022-02-06 17:25:12 +01:00
|
|
|
03:16:16,500 --> 03:16:18,500
|
|
|
|
we don't maintain one as MISP project
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5415
|
2022-02-06 17:25:12 +01:00
|
|
|
03:16:18,500 --> 03:16:22,00
|
|
|
|
but there are some that are under our MISP project {inaudible} position.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5418
|
2022-02-06 17:25:12 +01:00
|
|
|
03:16:27,0 --> 03:16:32,0
|
|
|
|
Someone is asking about API key to invoke cortex analyzer.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5420
|
2022-02-06 17:25:12 +01:00
|
|
|
03:16:32,0 --> 03:16:39,500
|
|
|
|
For the cortex analyzer, it's a separate toolset part of the HIVE project
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5423
|
2022-02-06 17:25:12 +01:00
|
|
|
03:16:39,500 --> 03:16:42,500
|
|
|
|
and then you have specific API keys.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5424
|
2022-02-06 17:25:12 +01:00
|
|
|
03:16:42,500 --> 03:16:48,500
|
|
|
|
Cortex extension is like MISP module so it works for the expansion services
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5426
|
2022-02-06 17:25:12 +01:00
|
|
|
03:16:48,500 --> 03:16:53,500
|
|
|
|
Be careful, cortex analyzer are not supporting objects and stuff like that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5428
|
2022-02-06 17:25:12 +01:00
|
|
|
03:16:53,500 --> 03:16:58,500
|
|
|
|
which is the case for MISP modules so you might have expansion on the interface
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5431
|
2022-02-06 17:25:12 +01:00
|
|
|
03:16:58,500 --> 03:17:00,500
|
|
|
|
but if you want full-blown expansion with relationship and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5433
|
2022-02-06 17:25:12 +01:00
|
|
|
03:17:00,500 --> 03:17:04,500
|
|
|
|
then you can use MISP modules. A lot of organizations are mixing both
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5434
|
2022-02-06 17:25:12 +01:00
|
|
|
03:17:04,500 --> 03:17:09,500
|
|
|
|
so you can have cortex-enabled and MISP modulus enabled on the same MISP instance
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5438
|
2022-02-06 17:25:12 +01:00
|
|
|
03:17:09,500 --> 03:17:14,500
|
|
|
|
But going back to the question if you already have the Cortex API encoded in your MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5440
|
2022-02-06 17:25:12 +01:00
|
|
|
03:17:14,500 --> 03:17:19,0
|
|
|
|
and you want to invoke a lookup through the API through MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5442
|
2022-02-06 17:25:12 +01:00
|
|
|
03:17:19,0 --> 03:17:24,500
|
|
|
|
then you can use your MISP API to tell your MISP to run a query against Cortex.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5445
|
2022-02-06 17:25:12 +01:00
|
|
|
03:17:27,0 --> 03:17:33,500
|
|
|
|
But with the new api key models usually it's better to have dedicated API key per {inaudible}.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5447
|
2022-02-06 17:25:12 +01:00
|
|
|
03:17:35,0 --> 03:17:41,500
|
|
|
|
Okay, there is something else, is there a way.. we had that already
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5450
|
2022-02-06 17:25:12 +01:00
|
|
|
03:17:44,0 --> 03:17:47,500
|
|
|
|
Could you touch on how we could use one event to add multiple attributes
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5451
|
2022-02-06 17:25:12 +01:00
|
|
|
03:17:47,500 --> 03:17:50,500
|
|
|
|
and how would correlation work here?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5453
|
2022-02-06 17:25:12 +01:00
|
|
|
03:17:50,500 --> 03:17:53,500
|
|
|
|
Configure event one to fetch all records from a feed
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5455
|
2022-02-06 17:25:12 +01:00
|
|
|
03:17:53,500 --> 03:17:55,0
|
|
|
|
Would this work with correlation?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5456
|
2022-02-06 17:25:12 +01:00
|
|
|
03:17:55,0 --> 03:17:59,500
|
|
|
|
Show all instances where any of those attributes match with other events from other organization events
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5459
|
2022-02-06 17:25:12 +01:00
|
|
|
03:17:59,500 --> 03:18:05,500
|
|
|
|
Well okay if I understand it correctly, indeed so if you do that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5461
|
2022-02-06 17:25:12 +01:00
|
|
|
03:18:05,500 --> 03:18:10,0
|
|
|
|
you create an event for a phishing feed and you have those attributes in there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5464
|
2022-02-06 17:25:12 +01:00
|
|
|
03:18:10,0 --> 03:18:15,500
|
|
|
|
and you have cached other instances, then within that that feed's event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5466
|
2022-02-06 17:25:12 +01:00
|
|
|
03:18:15,500 --> 03:18:21,500
|
|
|
|
you will see correlations both to other events created locally on your instance by other organizations
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5470
|
2022-02-06 17:25:12 +01:00
|
|
|
03:18:21,500 --> 03:18:27,500
|
|
|
|
as well as links to other instances that have the data as long as you have cached those events
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5474
|
2022-02-06 17:25:12 +01:00
|
|
|
03:18:27,500 --> 03:18:31,500
|
|
|
|
so we're going to talk more about that tomorrow about the synchronization
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5475
|
2022-02-06 17:25:12 +01:00
|
|
|
03:18:31,500 --> 03:18:34,500
|
|
|
|
but when you're interconnecting with another instance you can do it in two ways,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5479
|
2022-02-06 17:25:12 +01:00
|
|
|
03:18:34,500 --> 03:18:37,500
|
|
|
|
one I want to start exchanging data, pushing data, pooling data
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5481
|
2022-02-06 17:25:12 +01:00
|
|
|
03:18:37,500 --> 03:18:41,500
|
|
|
|
or two I can just tell my MISP to go crawl that other instance
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5484
|
2022-02-06 17:25:12 +01:00
|
|
|
03:18:41,500 --> 03:18:46,500
|
|
|
|
hash all the values that they have and if I ever get the correlation
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5486
|
2022-02-06 17:25:12 +01:00
|
|
|
03:18:46,500 --> 03:18:51,500
|
|
|
|
then it flags it for me then it shows me that the instance already knows about this value
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5488
|
2022-02-06 17:25:12 +01:00
|
|
|
03:18:51,500 --> 03:18:57,500
|
|
|
|
and I can pivot over to previewing the data. So I hope that answers that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5489
|
2022-02-06 17:25:12 +01:00
|
|
|
03:18:57,500 --> 03:19:02,500
|
|
|
|
Yeah, and then the correlation of feeds for example if you just enable the caching
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5493
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:02,500 --> 03:19:07,500
|
|
|
|
you just see that it's correlating with specific values without providing the full feed
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5495
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:07,500 --> 03:19:11,0
|
|
|
|
sometimes it's quite handy when you have for example feed that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5499
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:11,0 --> 03:19:14,500
|
|
|
|
you cannot show the data but you can show the correlation,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5500
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:16,0 --> 03:19:18,500
|
|
|
|
There's another one, do you recommend using MISP alone
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5501
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:18,500 --> 03:19:21,500
|
|
|
|
or using the Hive MISP Cortex integration
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5502
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:21,500 --> 03:19:26,500
|
|
|
|
I mean generally if you need a case management tool then using the Hive for that is great
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5506
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:26,500 --> 03:19:34,500
|
|
|
|
So it makes absolute sense to use them together and integration is really smoothly done
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5509
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:34,500 --> 03:19:37,500
|
|
|
|
so that means that no matter where you start your process,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5510
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:37,500 --> 03:19:39,500
|
|
|
|
whether you start by creating an event in MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5511
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:39,500 --> 03:19:42,500
|
|
|
|
or whether you start by creating a case in the Hive
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5512
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:42,500 --> 03:19:45,500
|
|
|
|
you can basically propagate the data to the other tool
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5513
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:45,500 --> 03:19:50,0
|
|
|
|
and work on both tools and data. So yeah, so absolutely
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5519
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:50,0 --> 03:19:55,0
|
|
|
|
Yeah, absolutely it's pretty smooth, just be careful if you use the expansion on MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5521
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:55,0 --> 03:19:59,0
|
|
|
|
and you have MISP modules enabled I would prefer to have MISP modules enabled
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5523
|
2022-02-06 17:25:12 +01:00
|
|
|
03:19:59,0 --> 03:20:05,500
|
|
|
|
because you basically have all the features of MISP like relationship, objects and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5526
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:05,500 --> 03:20:10,500
|
|
|
|
with the cortex integration is basically just a layover with the Cortex
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5528
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:10,500 --> 03:20:12,500
|
|
|
|
Yeah but one of the things that you can do is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5531
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:12,500 --> 03:20:16,500
|
|
|
|
if you start for example from the Hive perspective and you push the data afterwards to misp
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5533
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:16,500 --> 03:20:21,500
|
|
|
|
you can then go through this process like what we've done here with enriching the information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5536
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:21,500 --> 03:20:25,500
|
|
|
|
creating objects that affect attributes so you can do it as a secondary step
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5538
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:25,500 --> 03:20:28,500
|
|
|
|
before you share it out to community to refine the data in MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5539
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:28,500 --> 03:20:30,500
|
|
|
|
that you've created in the Hive for example
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5540
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:30,500 --> 03:20:34,500
|
|
|
|
and the same thing if you've used cortex to fetch additional information in the Hive
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5544
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:34,500 --> 03:20:38,500
|
|
|
|
you can then take that data and further enrich it with MISP modules once it's in MISP.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5547
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:38,500 --> 03:20:43,500
|
|
|
|
Yeah this is a good question from Muhamad Junaid about
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5549
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:43,500 --> 03:20:47,500
|
|
|
|
when I try to import the data from STIX to MISP it's called lossy
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5551
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:47,500 --> 03:20:50,500
|
|
|
|
like can you please explain that a bit and this one is interesting
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5553
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:50,500 --> 03:20:54,0
|
|
|
|
because it's... I was saying a long long long discussion
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5554
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:54,0 --> 03:20:59,500
|
|
|
|
and that even influence how MISP evolved and the standard behind MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5557
|
2022-02-06 17:25:12 +01:00
|
|
|
03:20:59,500 --> 03:21:05,500
|
|
|
|
so STIX is really focusing on cybersecurity and cyber threat intelligence
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5558
|
2022-02-06 17:25:12 +01:00
|
|
|
03:21:05,500 --> 03:21:11,500
|
|
|
|
and the problem is you might have at some point in time
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5559
|
2022-02-06 17:25:12 +01:00
|
|
|
03:21:11,500 --> 03:21:14,500
|
|
|
|
data that are basically not defined anywhere
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5564
|
2022-02-06 17:25:12 +01:00
|
|
|
03:21:14,500 --> 03:21:20,500
|
|
|
|
so it's more for the export of data so for example if you export in a MISP event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5566
|
2022-02-06 17:25:12 +01:00
|
|
|
03:21:20,500 --> 03:21:25,0
|
|
|
|
and you have for example an object with the person and stuff like that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5568
|
2022-02-06 17:25:12 +01:00
|
|
|
03:21:25,0 --> 03:21:27,500
|
|
|
|
it won't be in the STIX to export for example.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5570
|
2022-02-06 17:25:12 +01:00
|
|
|
03:21:27,500 --> 03:21:32,500
|
|
|
|
So it means that in MISP even if you get all the information
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5571
|
2022-02-06 17:25:12 +01:00
|
|
|
03:21:32,500 --> 03:21:35,500
|
|
|
|
but it's bound to the limitation of the standards and the format
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5574
|
2022-02-06 17:25:12 +01:00
|
|
|
03:21:35,500 --> 03:21:38,500
|
|
|
|
where you export and it's exactly the same for any format
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5575
|
2022-02-06 17:25:12 +01:00
|
|
|
03:21:38,500 --> 03:21:42,500
|
|
|
|
I mean if you export a person in Suricata format
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5576
|
2022-02-06 17:25:12 +01:00
|
|
|
03:21:42,500 --> 03:21:47,500
|
|
|
|
obviously you don't have any field or things like that with person and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5580
|
2022-02-06 17:25:12 +01:00
|
|
|
03:21:47,500 --> 03:21:50,500
|
|
|
|
so that's why we call it lossy because sometimes when you import data
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5582
|
2022-02-06 17:25:12 +01:00
|
|
|
03:21:50,500 --> 03:21:57,500
|
|
|
|
it's bound to a specific set of fields that are supported and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5584
|
2022-02-06 17:25:12 +01:00
|
|
|
03:21:57,500 --> 03:22:00,500
|
|
|
|
Another thing that is quite important with STIX,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5585
|
2022-02-06 17:25:12 +01:00
|
|
|
03:22:00,500 --> 03:22:06,500
|
|
|
|
you might have a lot of peculiarities or specialities depending on the vendor
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5589
|
2022-02-06 17:25:12 +01:00
|
|
|
03:22:06,500 --> 03:22:10,500
|
|
|
|
some vendors are adding some specific custom objects things like that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5591
|
2022-02-06 17:25:12 +01:00
|
|
|
03:22:10,500 --> 03:22:13,500
|
|
|
|
that are not bound to any existing one
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5593
|
2022-02-06 17:25:12 +01:00
|
|
|
03:22:13,500 --> 03:22:19,500
|
|
|
|
so we are importing them as kind of you know generic one but it is basically like lossy again
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5596
|
2022-02-06 17:25:12 +01:00
|
|
|
03:22:19,500 --> 03:22:23,500
|
|
|
|
so you have to be careful when you use a specific format
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5598
|
2022-02-06 17:25:12 +01:00
|
|
|
03:22:23,500 --> 03:22:27,500
|
|
|
|
to be sure that you properly map an existing different one.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5600
|
2022-02-06 17:25:12 +01:00
|
|
|
03:22:27,500 --> 03:22:31,200
|
|
|
|
So it's more for the export, MISP quite flexible on that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5601
|
2022-02-06 17:25:12 +01:00
|
|
|
03:22:31,200 --> 03:22:36,500
|
|
|
|
so you can basically have any object you like but when we export for example in STIX one
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5603
|
2022-02-06 17:25:12 +01:00
|
|
|
03:22:36,500 --> 03:22:42,00
|
|
|
|
we just export what is existing in STIX even if we start we added some custom objects too
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5607
|
2022-02-06 17:25:12 +01:00
|
|
|
03:22:42,00 --> 03:22:49,500
|
|
|
|
some which are on to the MISP object but some tools will not recognize obviously the custom object
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5610
|
2022-02-06 17:25:12 +01:00
|
|
|
03:22:49,500 --> 03:22:53,500
|
|
|
|
because they are just having a profile for a specific set of known objects.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5614
|
2022-02-06 17:25:12 +01:00
|
|
|
03:22:53,500 --> 03:22:58,500
|
|
|
|
Yeah I think that's exactly the point that maybe is different from
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5615
|
2022-02-06 17:25:12 +01:00
|
|
|
03:22:58,500 --> 03:23:01,500
|
|
|
|
when we described the text in those import and export fields.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5619
|
2022-02-06 17:25:12 +01:00
|
|
|
03:23:01,500 --> 03:23:06,500
|
|
|
|
we say lossy but in reality what we do is we do try to capture everything
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5620
|
2022-02-06 17:25:12 +01:00
|
|
|
03:23:06,500 --> 03:23:09,500
|
|
|
|
and we do try to map everything but a lot of it will end up in custom objects.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5624
|
2022-02-06 17:25:12 +01:00
|
|
|
03:23:09,500 --> 03:23:16,500
|
|
|
|
Now what Alex mentioned is the problem even if we export bitcoin addresses for example
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5626
|
2022-02-06 17:25:12 +01:00
|
|
|
03:23:16,500 --> 03:23:19,500
|
|
|
|
whenever we're pushing in STIX2 format as custom objects
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5627
|
2022-02-06 17:25:12 +01:00
|
|
|
03:23:19,500 --> 03:23:23,500
|
|
|
|
no other tool will pick up on it because we're just using custom objects
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5628
|
2022-02-06 17:25:12 +01:00
|
|
|
03:23:23,500 --> 03:23:26,500
|
|
|
|
unless the other tool specifically looks for them
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5629
|
2022-02-06 17:25:12 +01:00
|
|
|
03:23:26,500 --> 03:23:30,500
|
|
|
|
they will just either store it as is or not know what to do with it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5630
|
2022-02-06 17:25:12 +01:00
|
|
|
03:23:30,500 --> 03:23:38,500
|
|
|
|
Yeah and that that's why we recommend a feed provider or vendors and so on to actively support the MISP format
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5637
|
2022-02-06 17:25:12 +01:00
|
|
|
03:23:38,500 --> 03:23:42,500
|
|
|
|
then they can they can really import a full set of objects
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5638
|
2022-02-06 17:25:12 +01:00
|
|
|
03:23:42,500 --> 03:23:44,500
|
|
|
|
and {inauidble, either some already exist in MISP/some are resisting it}.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5643
|
2022-02-06 17:25:12 +01:00
|
|
|
03:23:44,500 --> 03:23:47,500
|
|
|
|
Yeah in some cases however you don't really care about having the full set
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5645
|
2022-02-06 17:25:12 +01:00
|
|
|
03:23:47,500 --> 03:23:50,500
|
|
|
|
and that's where for example specialized formats are really cool
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5647
|
2022-02-06 17:25:12 +01:00
|
|
|
03:23:50,500 --> 03:23:56,500
|
|
|
|
so whenever we're feeding for example an ids for example we don't care about bitcoin addresses.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5649
|
2022-02-06 17:25:12 +01:00
|
|
|
03:23:56,500 --> 03:24:03,500
|
|
|
|
So in those cases STIX and MISP both are very expressive exchange formats
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5653
|
2022-02-06 17:25:12 +01:00
|
|
|
03:24:03,500 --> 03:24:06,500
|
|
|
|
but whenever you're dealing with feeding tools for example
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5654
|
2022-02-06 17:25:12 +01:00
|
|
|
03:24:06,500 --> 03:24:10,500
|
|
|
|
you don't care about about losing, 90% even, of the data set
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5655
|
2022-02-06 17:25:12 +01:00
|
|
|
03:24:10,500 --> 03:24:16,500
|
|
|
|
as long as you capture those type of data points that your tool can process in the end.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5659
|
2022-02-06 17:25:12 +01:00
|
|
|
03:24:16,500 --> 03:24:19,500
|
|
|
|
So this is why generally what we recommend is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5660
|
2022-02-06 17:25:12 +01:00
|
|
|
03:24:19,500 --> 03:24:21,500
|
|
|
|
if you have the option for example to export data from MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5663
|
2022-02-06 17:25:12 +01:00
|
|
|
03:24:21,500 --> 03:24:24,500
|
|
|
|
is for your IDS for your SIEM and so on and you have the option between
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5665
|
2022-02-06 17:25:12 +01:00
|
|
|
03:24:24,500 --> 03:24:28,500
|
|
|
|
for example STIX or Snort or Surikata go with Snort or Surikata
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5666
|
2022-02-06 17:25:12 +01:00
|
|
|
03:24:28,500 --> 03:24:34,500
|
|
|
|
because those are much more catering to what your tools can actually understand
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5670
|
2022-02-06 17:25:12 +01:00
|
|
|
03:24:34,500 --> 03:24:38,500
|
|
|
|
Yeah, for example for Yara the same you prefer to have like a
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5671
|
2022-02-06 17:25:12 +01:00
|
|
|
03:24:38,500 --> 03:24:44,500
|
|
|
|
good Yara rule set that you can run into another anti-virus or your endpoint protection device
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5675
|
2022-02-06 17:25:12 +01:00
|
|
|
03:24:44,500 --> 03:24:48,500
|
|
|
|
and having a generic one that will not help you to lose the detection.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5677
|
2022-02-06 17:25:12 +01:00
|
|
|
03:24:52,0 --> 03:24:55,0
|
|
|
|
Are there any other questions?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5678
|
2022-02-06 17:25:12 +01:00
|
|
|
03:24:56,0 --> 03:24:59,500
|
|
|
|
You already took that one that is there that is longer.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5681
|
2022-02-06 17:25:12 +01:00
|
|
|
03:24:59,500 --> 03:25:02,500
|
|
|
|
I think we took most of them unless they missed one.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5682
|
2022-02-06 17:25:12 +01:00
|
|
|
03:25:03,500 --> 03:25:09,500
|
|
|
|
Yeah, perhaps we should show the deletions because we we didn't actually show it, indeed.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5685
|
2022-02-06 17:25:12 +01:00
|
|
|
03:25:09,500 --> 03:25:10,500
|
|
|
|
Yeah, exactly.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
2022-02-06 17:25:12 +01:00
|
|
|
5686
|
|
|
|
03:25:13,0 --> 03:25:18,500
|
|
|
|
Okay, oh and now we have some more questions but we can take those after.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5688
|
2022-02-06 17:25:12 +01:00
|
|
|
03:25:18,500 --> 03:25:23,500
|
|
|
|
Yeah let's quickly show the deletions so if we go to an event.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5691
|
2022-02-06 17:25:12 +01:00
|
|
|
03:25:23,500 --> 03:25:25,500
|
|
|
|
yeah I'll take a hundred events.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5692
|
2022-02-06 17:25:12 +01:00
|
|
|
03:25:25,500 --> 03:25:29,500
|
|
|
|
So this is a massive gotcha basically in MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5694
|
2022-02-06 17:25:12 +01:00
|
|
|
03:25:29,500 --> 03:25:33,500
|
|
|
|
which we have some protective measures in place to avoid this
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5695
|
2022-02-06 17:25:12 +01:00
|
|
|
03:25:33,500 --> 03:25:37,500
|
|
|
|
but one of the things that you really need to watch out for is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5698
|
2022-02-06 17:25:12 +01:00
|
|
|
03:25:37,500 --> 03:25:40,500
|
|
|
|
when you when you add data to MISP and you noticed
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5700
|
2022-02-06 17:25:12 +01:00
|
|
|
03:25:40,500 --> 03:25:45,500
|
|
|
|
oh crap I should not have added a piece of information that is either confidential information,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5702
|
2022-02-06 17:25:12 +01:00
|
|
|
03:25:45,500 --> 03:25:48,500
|
|
|
|
information about the victim that I shouldn't share and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5705
|
2022-02-06 17:25:12 +01:00
|
|
|
03:25:48,500 --> 03:25:53,500
|
|
|
|
First delete the attribute, that attribute might still be contained in the event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5707
|
2022-02-06 17:25:12 +01:00
|
|
|
03:25:53,500 --> 03:25:58,500
|
|
|
|
in a soft deleted format. You can always toggle and see the deleted attributes within an event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5710
|
2022-02-06 17:25:12 +01:00
|
|
|
03:25:58,500 --> 03:26:04,500
|
|
|
|
So I will create an event from scratch as you can see
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5712
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:04,500 --> 03:26:10,0
|
|
|
|
Okay so before I move forward on that so we have two protective measures in place
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5714
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:10,0 --> 03:26:14,500
|
|
|
|
to avoid accidental information leakage violation.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5715
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:14,500 --> 03:26:19,500
|
|
|
|
One is basically that by default we do not use the soft delete method for
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5717
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:19,500 --> 03:26:24,500
|
|
|
|
anything that was unpublished at first so we're going to show it as an example
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5720
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:24,500 --> 03:26:27,500
|
|
|
|
so here's some sensitive information, if Alex were to delete this now
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5723
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:27,500 --> 03:26:29,500
|
|
|
|
this attribute, this would get hard deleted,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5724
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:29,500 --> 03:26:34,500
|
|
|
|
So this will not create a soft deletion, MISP already tells us
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5725
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:34,500 --> 03:26:37,500
|
|
|
|
are you sure you want to hard delete the attribute? So when you read the text
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5728
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:37,500 --> 03:26:39,500
|
|
|
|
you will see the difference there in the wording.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5729
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:39,500 --> 03:26:43,500
|
|
|
|
The reason for that is the event has not been published yet
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5730
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:43,500 --> 03:26:45,500
|
|
|
|
we know that it has not probably been propagated to other instances.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5734
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:45,500 --> 03:26:49,500
|
|
|
|
There is absolutely no reason to inform anyone that this has been deleted
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5736
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:49,500 --> 03:26:52,500
|
|
|
|
so we can immediately just hard delete it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5738
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:52,500 --> 03:26:56,0
|
|
|
|
So when we do that, it will get hard deleted.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5739
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:56,0 --> 03:26:58,500
|
|
|
|
However, if the event has already been published
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5740
|
2022-02-06 17:25:12 +01:00
|
|
|
03:26:58,500 --> 03:27:01,500
|
|
|
|
this has already been shared out to other instances potentially.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5742
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:01,500 --> 03:27:04,0
|
|
|
|
So in this case, if we were to delete it, MISP will tell us
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5743
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:04,0 --> 03:27:07,500
|
|
|
|
oh are you sure you want to soft delete this attribute
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5744
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:07,500 --> 03:27:09,500
|
|
|
|
because this is already a published event.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5747
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:09,500 --> 03:27:14,0
|
|
|
|
Now it looks like our event is empty but if you look at the deleted flag
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5748
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:14,0 --> 03:27:16,500
|
|
|
|
you will see that the sensitive attribute is still there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5751
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:16,500 --> 03:27:19,500
|
|
|
|
and if I were to publish the event now, this sensitive attribute
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5753
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:19,500 --> 03:27:23,500
|
|
|
|
would get propagated along with the event.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5754
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:23,500 --> 03:27:29,500
|
|
|
|
If you want to avoid this altogether, there is a way to mangle any attribute that gets self-deleted.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5757
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:29,500 --> 03:27:32,500
|
|
|
|
What happens in that case is a category will be set to Other
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5759
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:32,500 --> 03:27:36,500
|
|
|
|
type will be set to Other and value will be set to Redacted.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5761
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:36,500 --> 03:27:40,500
|
|
|
|
This is a server-wide setting so your administrator or if you are the administrator
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5762
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:40,500 --> 03:27:43,500
|
|
|
|
then you yourself can set this setting in the server settings.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5765
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:43,500 --> 03:27:48,0
|
|
|
|
The downside of that is if you are mangling attributes that you're soft deleting
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5767
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:48,0 --> 03:27:52,0
|
|
|
|
it will still inform the other instances, they will still remove the data
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5768
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:52,0 --> 03:27:54,500
|
|
|
|
soft delete the data because the uid is reserved.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5771
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:54,500 --> 03:27:57,500
|
|
|
|
However, you cannot recover the attribute anymore.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5772
|
2022-02-06 17:25:12 +01:00
|
|
|
03:27:57,500 --> 03:28:02,500
|
|
|
|
So in this case right now we deleted attribute, Alex could now click on the recover button
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5776
|
2022-02-06 17:25:12 +01:00
|
|
|
03:28:02,500 --> 03:28:07,500
|
|
|
|
and the attribute will be recovered as a normal attribute so if you made a mistake you can recover it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5779
|
2022-02-06 17:25:12 +01:00
|
|
|
03:28:07,500 --> 03:28:12,500
|
|
|
|
So there are two different mindsets, I want to make my data recoverable
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5781
|
2022-02-06 17:25:12 +01:00
|
|
|
03:28:12,500 --> 03:28:15,500
|
|
|
|
and that I want to always inform others
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5783
|
2022-02-06 17:25:12 +01:00
|
|
|
03:28:15,500 --> 03:28:19,500
|
|
|
|
versus I want to always hard delete data that I delete.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5784
|
2022-02-06 17:25:12 +01:00
|
|
|
03:28:19,500 --> 03:28:25,500
|
|
|
|
Both of them have a setting so just pick and choose whichever makes sense for your community.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5787
|
2022-02-06 17:25:12 +01:00
|
|
|
03:28:25,500 --> 03:28:31,500
|
|
|
|
Whether you prefer secrecy or prefer convenience basically so that's it's basically.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5790
|
2022-02-06 17:25:12 +01:00
|
|
|
03:28:31,500 --> 03:28:37,0
|
|
|
|
-Yeah that's delete for attribute so if we delete an event that's another story.
|
|
|
|
-Yeah
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5792
|
2022-02-06 17:25:12 +01:00
|
|
|
03:28:37,0 --> 03:28:42,500
|
|
|
|
And this one is interesting because now we have these options where we say
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5795
|
2022-02-06 17:25:12 +01:00
|
|
|
03:28:42,500 --> 03:28:46,500
|
|
|
|
I want to delete this event and obviously it will be deleted on your instance.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5798
|
2022-02-06 17:25:12 +01:00
|
|
|
03:28:46,500 --> 03:28:53,500
|
|
|
|
Nevertheless this even has been already synchronized, copy on different MISP instances
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5802
|
2022-02-06 17:25:12 +01:00
|
|
|
03:28:53,500 --> 03:28:56,500
|
|
|
|
so that means at the next synchronizations the event should be pulled
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5805
|
2022-02-06 17:25:12 +01:00
|
|
|
03:28:56,500 --> 03:28:59,500
|
|
|
|
but to avoid such kind of of issue
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5806
|
2022-02-06 17:25:12 +01:00
|
|
|
03:28:59,500 --> 03:29:04,500
|
|
|
|
MISP is automatically generating a block list of all those deleted events
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5808
|
2022-02-06 17:25:12 +01:00
|
|
|
03:29:04,500 --> 03:29:09,500
|
|
|
|
so if you are the administrator you can see at the "Blocklist events",
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5810
|
2022-02-06 17:25:12 +01:00
|
|
|
03:29:09,500 --> 03:29:14,500
|
|
|
|
you can see the the one that I just deleted. So why we do that?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5812
|
2022-02-06 17:25:12 +01:00
|
|
|
03:29:14,500 --> 03:29:19,500
|
|
|
|
It's very simple. We don't want to re-import the event that has been deleted
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5814
|
2022-02-06 17:25:12 +01:00
|
|
|
03:29:19,500 --> 03:29:21,500
|
|
|
|
because locally we don't want this event.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5816
|
2022-02-06 17:25:12 +01:00
|
|
|
03:29:21,500 --> 03:29:27,500
|
|
|
|
So it's a blocklist of all the {inaudible} but there is a catch there.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5818
|
2022-02-06 17:25:12 +01:00
|
|
|
03:29:27,500 --> 03:29:31,500
|
|
|
|
Sometimes we have people, oh i'm doing some tests and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5820
|
2022-02-06 17:25:12 +01:00
|
|
|
03:29:31,500 --> 03:29:33,500
|
|
|
|
I'm synchronizing with MISP but I can't seem to get my event back
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5822
|
2022-02-06 17:25:12 +01:00
|
|
|
03:29:33,500 --> 03:29:36,500
|
|
|
|
and obviously yes because it's there in this block list.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5824
|
2022-02-06 17:25:12 +01:00
|
|
|
03:29:36,500 --> 03:29:40,500
|
|
|
|
So if you have some tests and you're running some tests, don't forget to look at the block list
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5826
|
2022-02-06 17:25:12 +01:00
|
|
|
03:29:40,500 --> 03:29:46,0
|
|
|
|
and maybe you want to just remove the event from the blocklist
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5827
|
2022-02-06 17:25:12 +01:00
|
|
|
03:29:46,0 --> 03:29:48,500
|
|
|
|
and then you can synchronize back the event.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5830
|
2022-02-06 17:25:12 +01:00
|
|
|
03:29:48,500 --> 03:29:52,0
|
|
|
|
there's something to keep in mind it's there, it's done automatically
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5831
|
2022-02-06 17:25:12 +01:00
|
|
|
03:29:52,0 --> 03:29:56,500
|
|
|
|
but in some cases you want to manage the blocklist so that's something to keep in mind.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5835
|
2022-02-06 17:25:12 +01:00
|
|
|
03:29:56,500 --> 03:30:05,500
|
|
|
|
Yep something else that we perhaps should touch on here is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5838
|
2022-02-06 17:25:12 +01:00
|
|
|
03:30:05,500 --> 03:30:09,500
|
|
|
|
for the event deletions besides just a blocklist part
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5840
|
2022-02-06 17:25:12 +01:00
|
|
|
03:30:09,500 --> 03:30:12,0
|
|
|
|
there is one thing that comes up as a question very often is.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5841
|
2022-02-06 17:25:12 +01:00
|
|
|
03:30:12,0 --> 03:30:14,500
|
|
|
|
how do I inform others that an event needs to be removed?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5843
|
2022-02-06 17:25:12 +01:00
|
|
|
03:30:14,500 --> 03:30:19,500
|
|
|
|
We don't have a mechanism in place for that so while we can revoke attributes for events
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5845
|
2022-02-06 17:25:12 +01:00
|
|
|
03:30:19,500 --> 03:30:22,500
|
|
|
|
We don't have that and there's a reason for that.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5847
|
2022-02-06 17:25:12 +01:00
|
|
|
03:30:22,500 --> 03:30:27,500
|
|
|
|
In general whenever it comes to events we don't want to give the power
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5848
|
2022-02-06 17:25:12 +01:00
|
|
|
03:30:27,500 --> 03:30:34,500
|
|
|
|
to just outright delete events remotely this way so this might change in the future.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5853
|
2022-02-06 17:25:12 +01:00
|
|
|
03:30:34,500 --> 03:30:39,500
|
|
|
|
We're having discussions on that whether we want to enable that or not but currently that's not the case.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5855
|
2022-02-06 17:25:12 +01:00
|
|
|
03:30:39,500 --> 03:30:45,500
|
|
|
|
Yeah and usually we take as an example emails I mean you can remove emails from your personal mailbox
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5858
|
2022-02-06 17:25:12 +01:00
|
|
|
03:30:45,500 --> 03:30:48,500
|
|
|
|
but from the remote mailbox if someone already receives the emails
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5861
|
2022-02-06 17:25:12 +01:00
|
|
|
03:30:48,500 --> 03:30:52,500
|
|
|
|
you want to have the control over third parties on the mailbox
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5862
|
2022-02-06 17:25:12 +01:00
|
|
|
03:30:52,500 --> 03:30:56,0
|
|
|
|
that might be one of the drawback I would say.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5864
|
2022-02-06 17:25:12 +01:00
|
|
|
03:30:56,0 --> 03:31:01,500
|
|
|
|
So there are two new questions one of them is basically can you demonstrate
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5866
|
2022-02-06 17:25:12 +01:00
|
|
|
03:31:01,500 --> 03:31:06,500
|
|
|
|
the progressive enrichments of events by the shared communities over time with correlations.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5869
|
2022-02-06 17:25:12 +01:00
|
|
|
03:31:06,500 --> 03:31:10,500
|
|
|
|
This one is tough I mean i'm not sure how we could demonstrate that because
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5871
|
2022-02-06 17:25:12 +01:00
|
|
|
03:31:10,500 --> 03:31:15,500
|
|
|
|
we're not dealing with live instances with live data sets and active sharing
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5875
|
2022-02-06 17:25:12 +01:00
|
|
|
03:31:15,500 --> 03:31:21,500
|
|
|
|
but perhaps for tomorrow we will prepare an example where we can show it off
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5877
|
2022-02-06 17:25:12 +01:00
|
|
|
03:31:21,500 --> 03:31:28,500
|
|
|
|
and choose an event that we can show on one of the operational instances
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5879
|
2022-02-06 17:25:12 +01:00
|
|
|
03:31:28,500 --> 03:31:34,500
|
|
|
|
but I can show one on, you know what I can go on just one second
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5880
|
2022-02-06 17:25:12 +01:00
|
|
|
03:31:34,500 --> 03:31:42,500
|
|
|
|
I'm going on an instance. So it was.. oh we are flexible
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5881
|
2022-02-06 17:25:12 +01:00
|
|
|
03:31:42,500 --> 03:31:49,500
|
|
|
|
So it's not simple to do it no but so it's maybe something interesting there.
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
5888
|
2022-02-06 17:25:12 +01:00
|
|
|
03:31:49,500 --> 03:31:56,500
|
|
|
|
So I'm connecting an instance where I have more expansion services active and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5892
|
2022-02-06 17:25:12 +01:00
|
|
|
03:31:56,500 --> 03:32:01,500
|
|
|
|
I'll just keep it for "My Organization Only" so i'm creating an event there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5894
|
2022-02-06 17:25:12 +01:00
|
|
|
03:32:01,500 --> 03:32:08,500
|
|
|
|
so what happens on progressively enriching event by shared communities
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5896
|
2022-02-06 17:25:12 +01:00
|
|
|
03:32:08,500 --> 03:32:11,0
|
|
|
|
I mean it's going back and forth to different communities
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
5898
|
2022-02-06 17:25:12 +01:00
|
|
|
03:32:11,0 --> 03:32:14,500
|
|
|
|
but I can imitate what the community is doing usually.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5900
|
2022-02-06 17:25:12 +01:00
|
|
|
03:32:14,500 --> 03:32:24,500
|
|
|
|
so if I'm creating an attribute for example I will create a hostname with some network activity.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5903
|
2022-02-06 17:25:12 +01:00
|
|
|
03:32:24,500 --> 03:32:37,500
|
|
|
|
So we have specifically a test that we created with this kind of...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5905
|
2022-02-06 17:25:12 +01:00
|
|
|
03:32:37,500 --> 03:32:41,0
|
|
|
|
so what would be your community and sharing?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5907
|
2022-02-06 17:25:12 +01:00
|
|
|
03:32:41,0 --> 03:32:42,500
|
|
|
|
So it could be for example in the same organization
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5908
|
2022-02-06 17:25:12 +01:00
|
|
|
03:32:42,500 --> 03:32:47,500
|
|
|
|
in my case it's just shared to the organization so if I publish event here
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5910
|
2022-02-06 17:25:12 +01:00
|
|
|
03:32:47,500 --> 03:32:53,500
|
|
|
|
it will be shared with all different instances maybe the different members of CIRCL
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5914
|
2022-02-06 17:25:12 +01:00
|
|
|
03:32:53,500 --> 03:33:01,500
|
|
|
|
and one of my colleagues is taking one of the indicators there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5916
|
2022-02-06 17:25:12 +01:00
|
|
|
03:33:01,500 --> 03:33:07,500
|
|
|
|
and then he's going on the Faresight database doing a full-blown expansion
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5917
|
2022-02-06 17:25:12 +01:00
|
|
|
03:33:07,500 --> 03:33:09,500
|
|
|
|
so that means he's basically doing a full-blown expansion.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5921
|
2022-02-06 17:25:12 +01:00
|
|
|
03:33:09,500 --> 03:33:17,500
|
|
|
|
What do I have here? I have a a complete set of objects for a specific domain
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5922
|
2022-02-06 17:25:12 +01:00
|
|
|
03:33:17,500 --> 03:33:24,500
|
|
|
|
so you see again I'm going to the event graph now I enter my domain name
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5923
|
2022-02-06 17:25:12 +01:00
|
|
|
03:33:24,500 --> 03:33:27,500
|
|
|
|
and I have all the passive DNS records associated to that one
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5929
|
2022-02-06 17:25:12 +01:00
|
|
|
03:33:27,500 --> 03:33:32,500
|
|
|
|
and in this one I think I will have the event timeline
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5930
|
2022-02-06 17:25:12 +01:00
|
|
|
03:33:32,500 --> 03:33:36,0
|
|
|
|
I have a completely different timeline of the different expansion and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5932
|
2022-02-06 17:25:12 +01:00
|
|
|
03:33:36,0 --> 03:33:44,500
|
|
|
|
So then I will have one of my... it will be published again with the data.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5937
|
2022-02-06 17:25:12 +01:00
|
|
|
03:33:44,500 --> 03:33:51,0
|
|
|
|
If it's a collaboration I would say in the same team that's a thing
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5939
|
2022-02-06 17:25:12 +01:00
|
|
|
03:33:51,0 --> 03:33:56,500
|
|
|
|
so it's sometimes people are working on the same event and publishing it
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5942
|
2022-02-06 17:25:12 +01:00
|
|
|
03:33:56,500 --> 03:34:03,500
|
|
|
|
Sometimes they are sharing it and doing additional expansion on the things
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5945
|
2022-02-06 17:25:12 +01:00
|
|
|
03:34:03,500 --> 03:34:07,500
|
|
|
|
until to reach a specific point that is like I would say
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5946
|
2022-02-06 17:25:12 +01:00
|
|
|
03:34:07,500 --> 03:34:15,500
|
|
|
|
accessible or at least publishable in a publishing state that is acceptable by various people.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5950
|
2022-02-06 17:25:12 +01:00
|
|
|
03:34:16,0 --> 03:34:23,500
|
|
|
|
Now we can make proposal too. So that means if we are again with a different organization,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5952
|
2022-02-06 17:25:12 +01:00
|
|
|
03:34:23,500 --> 03:34:28,500
|
|
|
|
i don't know if in this example it will work but I can take...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5956
|
2022-02-06 17:25:12 +01:00
|
|
|
03:34:28,500 --> 03:34:31,500
|
|
|
|
do I have something interesting there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5958
|
2022-02-06 17:25:12 +01:00
|
|
|
03:34:33,760 --> 03:34:38,500
|
|
|
|
Yeah, for example I see an interesting IP address, this one.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5960
|
2022-02-06 17:25:12 +01:00
|
|
|
03:34:38,500 --> 03:34:46,500
|
|
|
|
So what I could do is i could add..
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5961
|
2022-02-06 17:25:12 +01:00
|
|
|
03:34:46,500 --> 03:34:52,500
|
|
|
|
What's going on here?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5964
|
2022-02-06 17:25:12 +01:00
|
|
|
03:34:52,500 --> 03:34:57,500
|
|
|
|
{inaudible}
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5965
|
2022-02-06 17:25:12 +01:00
|
|
|
03:35:04,0 --> 03:35:13,500
|
|
|
|
Okay just a demo effect, typical.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5967
|
2022-02-06 17:25:12 +01:00
|
|
|
03:35:13,500 --> 03:35:22,500
|
|
|
|
What's going on? Okay, just going back to this one I just want to add a proposal.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5970
|
2022-02-06 17:25:12 +01:00
|
|
|
03:35:22,500 --> 03:35:27,500
|
|
|
|
Yes I cannot just...
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5971
|
2022-02-06 17:25:12 +01:00
|
|
|
03:35:27,500 --> 03:35:30,500
|
|
|
|
you wanted but you're admin.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5972
|
2022-02-06 17:25:12 +01:00
|
|
|
03:35:30,500 --> 03:35:37,500
|
|
|
|
You can cheat if you really want, you can do it.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5974
|
2022-02-06 17:25:12 +01:00
|
|
|
03:35:37,500 --> 03:35:44,0
|
|
|
|
Yeah, wait, fine. It's just like okay so I don't know for {inaudible} if we answered your question
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5977
|
2022-02-06 17:25:12 +01:00
|
|
|
03:35:44,0 --> 03:35:50,500
|
|
|
|
but I mean a full-blown step would be like that, if you work on an event it's not a single person obviously.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5980
|
2022-02-06 17:25:12 +01:00
|
|
|
03:35:50,500 --> 03:35:54,500
|
|
|
|
When you do an investigation, you do like multiple steps but the question is more like
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5984
|
2022-02-06 17:25:12 +01:00
|
|
|
03:35:54,500 --> 03:35:59,500
|
|
|
|
if you do it within a team usually you edit the current event in the same organizations
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5987
|
2022-02-06 17:25:12 +01:00
|
|
|
03:35:59,500 --> 03:36:05,500
|
|
|
|
if you do inter-team, you do proposal, extend it even like we showed before
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5988
|
2022-02-06 17:25:12 +01:00
|
|
|
03:36:05,500 --> 03:36:09,500
|
|
|
|
and then you start to work on this thing, so it's really depending on the case.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5992
|
2022-02-06 17:25:12 +01:00
|
|
|
03:36:09,500 --> 03:36:15,0
|
|
|
|
so I hope you can see what are the capabilities there
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5993
|
2022-02-06 17:25:12 +01:00
|
|
|
03:36:15,0 --> 03:36:22,500
|
|
|
|
but it's really the progressive approach of collaboration usually depends on how people are working together.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5994
|
2022-02-06 17:25:12 +01:00
|
|
|
03:36:22,500 --> 03:36:25,500
|
|
|
|
If they are really external it's more proposal, extended event.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
5999
|
2022-02-06 17:25:12 +01:00
|
|
|
03:36:25,500 --> 03:36:30,500
|
|
|
|
If it's within the same team it could be extended event or within the same event,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6001
|
2022-02-06 17:25:12 +01:00
|
|
|
03:36:30,500 --> 03:36:35,500
|
|
|
|
that's usually the two way of working. Andras, if you want to add something on that?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6003
|
2022-02-06 17:25:12 +01:00
|
|
|
03:36:35,500 --> 03:36:43,500
|
|
|
|
No yeah, that's perfect. Perhaps another question if you're okay with switching.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6007
|
2022-02-06 17:25:12 +01:00
|
|
|
03:36:43,500 --> 03:36:49,0
|
|
|
|
Yeah when speaking of feeding tools what would be the automatic way of doing it?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6009
|
2022-02-06 17:25:12 +01:00
|
|
|
03:36:49,0 --> 03:36:52,500
|
|
|
|
So normally when we're talking about feeding tools there are two separate ways of doing it
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6011
|
2022-02-06 17:25:12 +01:00
|
|
|
03:36:52,500 --> 03:36:56,500
|
|
|
|
and we'll go way way deeper into this tomorrow when we talk about integration
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6013
|
2022-02-06 17:25:12 +01:00
|
|
|
03:36:56,500 --> 03:36:58,500
|
|
|
|
but generally tools can either fetch data from MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6014
|
2022-02-06 17:25:12 +01:00
|
|
|
03:36:58,500 --> 03:37:02,500
|
|
|
|
so this is a more common way where a tool would use REST search API
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6015
|
2022-02-06 17:25:12 +01:00
|
|
|
03:37:02,500 --> 03:37:06,0
|
|
|
|
that we mentioned before where you define your search patterns
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6016
|
2022-02-06 17:25:12 +01:00
|
|
|
03:37:06,0 --> 03:37:10,500
|
|
|
|
for example give me everything that is newer than 30 days,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6017
|
2022-02-06 17:25:12 +01:00
|
|
|
03:37:10,500 --> 03:37:16,500
|
|
|
|
everything that is not coming from say OSINT sources
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6025
|
2022-02-06 17:25:12 +01:00
|
|
|
03:37:16,500 --> 03:37:21,500
|
|
|
|
or perhaps not something, nothing that comes related to a certain topic
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6027
|
2022-02-06 17:25:12 +01:00
|
|
|
03:37:21,500 --> 03:37:26,500
|
|
|
|
for example I'm not interested in Ransomware when feeding my tools, just a stupid example.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6031
|
2022-02-06 17:25:12 +01:00
|
|
|
03:37:26,500 --> 03:37:28,500
|
|
|
|
So you set up your filter options
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6032
|
2022-02-06 17:25:12 +01:00
|
|
|
03:37:28,500 --> 03:37:32,500
|
|
|
|
and then your tool would fetch data from MISP every 60 minutes, for example.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6035
|
2022-02-06 17:25:12 +01:00
|
|
|
03:37:32,500 --> 03:37:40,500
|
|
|
|
and then replace the data set there. You can also do sliding time window searches
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6037
|
2022-02-06 17:25:12 +01:00
|
|
|
03:37:40,500 --> 03:37:43,500
|
|
|
|
where you say give me everything from the past 60 minutes that is new
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6040
|
2022-02-06 17:25:12 +01:00
|
|
|
03:37:43,760 --> 03:37:50,500
|
|
|
|
and then you keep concatenating your dataset on the SIEM side, IDS side, whatever tool you're feeding.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6043
|
2022-02-06 17:25:12 +01:00
|
|
|
03:37:50,500 --> 03:37:53,500
|
|
|
|
the alternative, if you want to have the data push automatically as it comes in
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6046
|
2022-02-06 17:25:12 +01:00
|
|
|
03:37:53,500 --> 03:37:56,500
|
|
|
|
you have different channels in MISP that your tools can latch on to.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6048
|
2022-02-06 17:25:12 +01:00
|
|
|
03:37:56,500 --> 03:38:01,500
|
|
|
|
The downside being that you still need to do the conversion in those cases.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6050
|
2022-02-06 17:25:12 +01:00
|
|
|
03:38:01,500 --> 03:38:08,500
|
|
|
|
So if you were not using the APIs to fetch the data from MISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6053
|
2022-02-06 17:25:12 +01:00
|
|
|
03:38:08,500 --> 03:38:12,0
|
|
|
|
then MISP can push using the MISP JSON format data down
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6054
|
2022-02-06 17:25:12 +01:00
|
|
|
03:38:12,0 --> 03:38:19,500
|
|
|
|
via different channels ZeroMQ or the Kafka channel or this blog and so on
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6059
|
2022-02-06 17:25:12 +01:00
|
|
|
03:38:19,500 --> 03:38:25,500
|
|
|
|
and then your tools automatically feed on that data so you have these two different ways of interacting with it
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6062
|
2022-02-06 17:25:12 +01:00
|
|
|
03:38:25,500 --> 03:38:28,0
|
|
|
|
There's also a third way where you can basically
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6063
|
2022-02-06 17:25:12 +01:00
|
|
|
03:38:28,0 --> 03:38:33,500
|
|
|
|
either build an export module or an enrichment module where an analyst can trigger
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6064
|
2022-02-06 17:25:12 +01:00
|
|
|
03:38:33,500 --> 03:38:38,500
|
|
|
|
a direct push of a certain data point to another tool, so that's another option.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6069
|
2022-02-06 17:25:12 +01:00
|
|
|
03:38:38,500 --> 03:38:44,500
|
|
|
|
We'll talk about these different strategies when to use which and how to mix those tomorrow more.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6072
|
2022-02-06 17:25:12 +01:00
|
|
|
03:38:44,500 --> 03:38:50,0
|
|
|
|
So I hope that answers it in a brief fashion.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6073
|
2022-02-06 17:25:12 +01:00
|
|
|
03:38:50,0 --> 03:38:57,500
|
|
|
|
Yeah what i'm showing here is it's just like on the REST search client
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6076
|
2022-02-06 17:25:12 +01:00
|
|
|
03:38:57,500 --> 03:39:01,500
|
|
|
|
for example you want to feed your Suricata and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6078
|
2022-02-06 17:25:12 +01:00
|
|
|
03:39:01,500 --> 03:39:15,500
|
|
|
|
Just take page and a specific limit. So what you can do is
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6079
|
2022-02-06 17:25:12 +01:00
|
|
|
03:39:15,500 --> 03:39:18,0
|
|
|
|
if you have a python script and so on you can pull directly the data.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6080
|
2022-02-06 17:25:12 +01:00
|
|
|
03:39:18,0 --> 03:39:24,500
|
|
|
|
So the rest client, so you see in this case I have the Suricata rule set
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6081
|
2022-02-06 17:25:12 +01:00
|
|
|
03:39:24,500 --> 03:39:28,500
|
|
|
|
but if you want to feed your specific tools and and so on,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6088
|
2022-02-06 17:25:12 +01:00
|
|
|
03:39:28,500 --> 03:39:36,500
|
|
|
|
automatically we are generating curl and python card so it could be a bootstrap to see okay,
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6090
|
2022-02-06 17:25:12 +01:00
|
|
|
03:39:36,500 --> 03:39:40,500
|
|
|
|
how should I create my own tool for feeding my IDS and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6092
|
2022-02-06 17:25:12 +01:00
|
|
|
03:39:40,500 --> 03:39:45,500
|
|
|
|
For Suricata, for example a lot of management interface have already MISP connector
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6096
|
2022-02-06 17:25:12 +01:00
|
|
|
03:39:45,500 --> 03:39:52,500
|
|
|
|
So you can even like feed the data directly from the interface if they have the ability
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6100
|
2022-02-06 17:25:12 +01:00
|
|
|
03:39:52,500 --> 03:39:55,500
|
|
|
|
Splunk for example, there's a specific application
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6101
|
2022-02-06 17:25:12 +01:00
|
|
|
03:39:55,500 --> 03:40:01,500
|
|
|
|
which is an external tools part of the app store of Splunk
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6102
|
2022-02-06 17:25:12 +01:00
|
|
|
03:40:01,500 --> 03:40:03,500
|
|
|
|
that you can install for doing the connection
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6105
|
2022-02-06 17:25:12 +01:00
|
|
|
03:40:03,500 --> 03:40:08,500
|
|
|
|
and some other people are using their own python script to feed other SIEM.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6107
|
2022-02-06 17:25:12 +01:00
|
|
|
03:40:08,500 --> 03:40:15,500
|
|
|
|
So again it's a matter of taste if you are curious about the different kind of integrations
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6110
|
2022-02-06 17:25:12 +01:00
|
|
|
03:40:15,500 --> 03:40:22,500
|
|
|
|
or you can do it in Python for example on PyMISP itself there are plenty of examples.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6113
|
2022-02-06 17:25:12 +01:00
|
|
|
03:40:22,500 --> 03:40:29,0
|
|
|
|
So if you go in the example directory of PyMISP
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6115
|
2022-02-06 17:25:12 +01:00
|
|
|
03:40:29,0 --> 03:40:38,500
|
|
|
|
you have quite significant set of default scripts that you can use
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6116
|
2022-02-06 17:25:12 +01:00
|
|
|
03:40:38,500 --> 03:40:42,500
|
|
|
|
and that's I think usually a good basis
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6117
|
2022-02-06 17:25:12 +01:00
|
|
|
03:40:42,500 --> 03:40:47,500
|
|
|
|
if you want to start to write your own custom custom tool set for
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6118
|
2022-02-06 17:25:12 +01:00
|
|
|
03:40:47,500 --> 03:40:52,500
|
|
|
|
feeding your systems or existing software in your infrastructure.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6124
|
2022-02-06 17:25:12 +01:00
|
|
|
03:40:52,500 --> 03:41:04,500
|
|
|
|
Yep, I don't know if we should jump on a new topic
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6125
|
2022-02-06 17:25:12 +01:00
|
|
|
03:41:04,500 --> 03:41:07,500
|
|
|
|
or we just push the Copalos example for tomorrow?
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6128
|
2022-02-06 17:25:12 +01:00
|
|
|
03:41:07,500 --> 03:41:11,500
|
|
|
|
yeah I think we can do maybe tomorrow.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6130
|
2022-02-06 17:25:12 +01:00
|
|
|
03:41:11,500 --> 03:41:16,500
|
|
|
|
I think that would be stretching it a little bit if we were to start with that
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6133
|
2022-02-06 17:25:12 +01:00
|
|
|
03:41:16,500 --> 03:41:24,500
|
|
|
|
So quick summary of today, so today we showed how to create an event
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6134
|
2022-02-06 17:25:12 +01:00
|
|
|
03:41:24,500 --> 03:41:28,500
|
|
|
|
the basis of MISP like what is an attribute, an object and so on.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6138
|
2022-02-06 17:25:12 +01:00
|
|
|
03:41:28,500 --> 03:41:35,500
|
|
|
|
How to create it, how to make proposal, delete and stuff like that, so it's really a simple example.
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
6142
|
2022-02-06 17:25:12 +01:00
|
|
|
03:41:35,500 --> 03:41:40,500
|
|
|
|
Tomorrow, we want to show you more the event report aspect
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6144
|
2022-02-06 17:25:12 +01:00
|
|
|
03:41:40,500 --> 03:41:46,500
|
|
|
|
and automatic imports into into MISP with a practical example of an original report.
|
|
|
|
|
2021-12-27 05:45:03 +01:00
|
|
|
6147
|
2022-02-06 17:25:12 +01:00
|
|
|
03:41:46,500 --> 03:41:51,500
|
|
|
|
and we will discuss tomorrow about how to build sharing communities
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6148
|
2022-02-06 17:25:12 +01:00
|
|
|
03:41:51,500 --> 03:41:55,500
|
|
|
|
and especially we will share our experience of things that worked
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6149
|
2022-02-06 17:25:12 +01:00
|
|
|
03:41:55,500 --> 03:42:00,0
|
|
|
|
and things that didn't work in the past years when creating sharing communities.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6153
|
2022-02-06 17:25:12 +01:00
|
|
|
03:42:00,0 --> 03:42:05,500
|
|
|
|
So if you are ISAC members or creating your own sharing community even within your organization
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6157
|
2022-02-06 17:25:12 +01:00
|
|
|
03:42:05,500 --> 03:42:09,500
|
|
|
|
It's something good to participate because we will share with you
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6158
|
2022-02-06 17:25:12 +01:00
|
|
|
03:42:09,5000 --> 03:42:15,500
|
|
|
|
some of the things that are interesting of building and bootstrapping such kind of of community.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6163
|
2022-02-06 17:25:12 +01:00
|
|
|
03:42:15,500 --> 03:42:20,500
|
|
|
|
I don't know Andras if you want to add something
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6164
|
2022-02-06 17:25:12 +01:00
|
|
|
03:42:20,500 --> 03:42:26,500
|
|
|
|
No and that's basically it thanks for everyone for sticking through this
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6167
|
2022-02-06 17:25:12 +01:00
|
|
|
03:42:26,500 --> 03:42:30,500
|
|
|
|
through it's a very condensed session so we said we didn't make as much progress
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6170
|
2022-02-06 17:25:12 +01:00
|
|
|
03:42:30,500 --> 03:42:33,500
|
|
|
|
as we hoped so we have quite a bit left for tomorrow
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6172
|
2022-02-06 17:25:12 +01:00
|
|
|
03:42:33,500 --> 03:42:35,500
|
|
|
|
and hope to see you all here tomorrow.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6173
|
2022-02-06 17:25:12 +01:00
|
|
|
03:42:35,500 --> 03:42:40,500
|
|
|
|
Thank you very much, take care and don't hesitate to ask questions
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6175
|
2022-02-06 17:25:12 +01:00
|
|
|
03:42:40,500 --> 03:42:45,0
|
|
|
|
either later on directly contact us, thank you very much, see you tomorrow.
|
2021-12-27 05:45:03 +01:00
|
|
|
|
|
|
|
6177
|
2022-02-06 17:25:12 +01:00
|
|
|
03:42:45,0 --> 03:42:49,500
|
|
|
|
Thank you all see you tomorrow
|