►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
And
I'd
like
to
thank
everyone
joining
us
today,
welcome
to
the
cncf
webinar,
hacking
monitoring
for
fun
and
for
profit,
I'm
libby
schultz
I'll
be
moderating
today's
webinar
and
we
would
like
to
welcome
our
presenter
omar
levy,
hevroni
application
security,
engineer
at
sync,
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
talk
as
an
attendee
there's
a
q,
a
box
at
the
bottom
of
your
screen.
A
Please
feel
free
to
drop
your
questions
in
there
and
we'll
get
to
as
many
as
we
can
and
we're
just
going
to
do
this
throughout
so
go
ahead
and
add
them
whenever
you
have
one.
This
is
an
official
webinar
of
the
cncf
and
as
such
as
a
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct
and
please
be
respectful
of
all
of
your
fellow
participants
and
presenters.
A
B
Are
going
to
talk
about
today,
we
are
going
to
start
with
defining
the
terms.
What
is
that
modeling?
What
is
monitoring?
Why
do
we
need
them,
and
then
we
are
going
to
do
something
that
at
least
I
think
it's
fine
and
we
are
going
to
apply
threat
modeling
to
our
existing
monitoring
system,
to
learn
how
hackers
can
use
what
we
build
to
exploit
us.
B
So
this
is
the
idea,
and
let's
start-
and
the
first
thing
we're
going
to
do-
is
talk
about
threat
modelling
and
before
we
talk
about
the,
what?
Let's
talk
a
bit
about
the?
Why
why
do
we
even
need
to
talk
about
trademark
so
terminating
is
a
tool
that
help
us
to
find
security
issues
in
a
system
before
we
build
them.
This
is
a
graph.
I
really.
A
B
It
talked
about
how
easy
it
is
to
fix
bug
and
how
hard
it
will
it
become
or
how
expensive
it
become
if
we,
if
we
find
it
later
in
the
in
in
the
development
life
cycle,
and
the
same
is
true
for
security
issues.
If
we
find
them
when
we
are
just
discussing
a
feature
or
something
we
want
to
build,
it
will
be
a
lot
easier
to
fix
than
if
we
find
it
after
we
listed
and
we
released
it
in
its
production
and.
B
B
The
link
is
down
here
and
I
really
recommend
you
to
check
it
out
because
it
really
set
the
ground
to
what
is
threat
modeling,
how
to
go
to
how
to
do
it.
What
to
try
to
avoid
and
the
user
framework
I
really
like,
which
is
based
on
a
four
very,
very
simple
question:
adam
charlstak
is
the
first
person
who
defined
him
and
he
has
a
really
really
good
book
about
it.
B
The
second
question
is:
where
the
fun
begin:
what
can
go
wrong?
How
hackers
could
use
that?
What
we
didn't
think
about
when
we
designed
the
system
and
then
once
we
have
the
list
of
issues
we
can
discuss
what
we
do
about
it.
And
finally,
the
next
question
is
kind
of
self-review
and
look
back
make
sure
we
find
all
the
things
that
are
relevant
and
also
to
remind
us
that
threat
modeling
is
never
over,
and
if
we
go
over
it
again,
we'll
probably
find
something
new
that
we
didn't
think
about.
B
So
let's
take
a
quick
peek
at
the
manifesto
just
so
that
you
get
a
feeling
of
what
they
have
there.
These
are
examples
of
how
to
do
that,
modeling
in
a
good
way
and
some
tips
around
it,
and
this
is
the
part
I
really
like
some
handy
patterns.
For
example,
everyone
can
do
treadmill
if
it's
done
properly
using
similar
framework
like
this,
and
this
is
something
that
take
me
to
something
that
I
hear
about
when
people
thinking
about
that
modeling.
B
B
B
B
B
A
B
What
is
cost
and
what
is
monitoring
the
best
is
to
go
to
the
bible
or
the
monitoring
bible,
which
is
this
book
by
google,
a
really
really
good
book
about
sre
and
a
lot
of
good
practice.
And,
of
course,
there
is
a
full
chapter
there.
They
get
dedicated
to
monitoring
it
and
how
to
do
it
properly,
and
it
defines
two
kinds
of
monitoring
black
box
and
white
box
where
black
box
is
when
you're
monitoring
something
without
knowing
what
is
inside
and
white
box
is
when
you're
monitoring
is
a
well
of
the
underlying
systems.
B
B
This
is
the
definition,
a
form,
a
destiny
book,
and
we
are
now
going
to
see
how
a
system
that
is
based
on
this
kind
of
monitoring
look
like
and
what
can
happen
with
it
and
we're
going
to
focus
a
bit
for
meters,
but
the
next,
the
rest
of
the
the
rest
of
it
will
cover
also
other
systems,
and
so
pointless
is
a
very
huge
monitoring
system.
It.
B
And
it
supports
also
auto
discovery.
It
can
escape
targets
in
various
orchestration
systems
that
basically
expose
metrics
and
if
I
had
to
describe
it
in
a
diagram,
this
is
an
example
for
a
data
flow
diagram.
We
have
an
actor
user,
the
user
interact
with
cofauna.
We
have
found
escape
formations
that
skype
the
service,
so
the
user
can
view
the
metrics
on
their
funnel
and
the
user
can
also
attract
directly
with
the
service,
and
this
is
a.
A
B
That
it
doesn't
really
matter
as
long
as
the
diagram
is
full
and
tell
the
whole
story
like
we
have
here.
We
have
other
participants,
trust
boundary,
that
explain
where
is
our
stuff
and
where
it's
not,
and
now
that
we
have
better
understanding
of
what
we
are
building.
We
can
talk
about
what
can
go
wrong
and.
B
B
B
B
B
So
I,
as
the
service
owner,
I
know
how
many
services
access
my
service
and
during
which
time
and
all
the
things
I
might
want
to
do
a
bit
like
tracing
using
parameters,
and
this
is
the
code
behind
it
again.
Look
very
very
simple.
I
can
say
that
I
once
wrote
something
like
that,
and
this
is
a
problem
and
it's
a
problem
because
of
how
palmetto
sandal
cardinality.
B
B
B
So,
for
example,
if
we
talk
about
the
metrics,
we
can
easily
fix
that
with
nginx,
just
block
all
access
to
slash,
metrics
and
the
eagles
definition,
and
we
solve
the
issue
to
protect
the
permitted
address
from
one
service
bombing
it.
We
can
define
a
limit
on
how
many
metrics
a
specific
service
can
expose
and
for
the
other
things
we
talk
about,
there
are
other
things
to
do,
for
example,
joke
from
check
for
non-verbatis
and
all
the
stuff
we
run
in
the
cluster.
A
B
B
Blackbox
monitoring
basically
aim
to
mock
how
users
interact
with
our
system,
so
our
monitoring
system
would
basically
try
to
be
a
user
and
try
to
view
a
different
movies.
We
have
to
make
sure
that
our
system
is
still
functional
and
this
time
it's
a
bit
harder
to
think
about
what
can
happen.
Let's
see.
B
B
B
B
If
we
have
issue
with
tampering,
someone
is
able
to
change
a
request
in
the
fly,
we're
missing
integrity
checks.
If
we
have
a
potential
issues,
you
can
make
a
request
and
then
deny
that
you
are
the
one
you
didn't.
We
missing
audit
or
non-affiliation,
and
it's
go
like
that
in
the
table
and
what
we
are
going
to
do
now
is.
We
are
going
to
some
examples
of
how
we
can
use
stride
to
think
about
different
attacks
that
could,
and
it
could
happen.
B
B
B
Will
be
we
will
we
be
able
to
know
that
it
happened,
or
in
this
case,
how
do
we
easily
distinguish
between
a
quest
coming
from
the
black
box,
monitoring
and
request
coming
from
a
hacker
in
person?
I
think
this
system
and
it's
not
an
easy
thing
to
solve,
and
we
need
really
really
good
audit
logs
starting
from
the
black
box
to
the
server,
but
it's
possible
and
finally,
which
is
always
fun,
is
the
narrative
service.
B
B
We
can
do
things
like
list
prevalence
and
so
that
the
black
box
has
all
the
information
it
need,
probably
doesn't
need
to
run
its
admin
underneath
permissions
to
view
movies,
or
it
doesn't
even
need
to
be
accessible
from
the
internet
if
we
have
point
to
together
a
test
and
we
can
use
tracing,
yaga
and
stuff
like
that,
for
a
repudiation
and
finally,
which
is
really
really
cool
thing
to
do,
is
to
ensure
that
the
test
bot
can
view
only
test
movies.
So,
even
if
I
was
able
to
spoof
the
test
bot,
I
cannot.