►
From YouTube: Defend Group Conversation (Public Livestream)
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
B
Hello,
everyone
and
welcome
to
the
defend
section
group
conversation
I'll,
be
your
host
David
de
Santa
I'm
director
of
product
for
secure
and
defend
I,
also
be
hearing
from
Wayne
haver.
He
is
the
director
of
engineering
for
defend
to
kind
of
give
some
people
some
time
to
throw
questions
into
the
document.
I
thought
I
would
just
highlight
a
couple
of
the
slides
within
the
deck.
So
let
me
share
my
screen.
B
B
B
One
of
the
focuses
of
this
fiscal
year
is
to
focus
on
depth
and
several
categories
for
defend
to
help
drive
adoption,
so
the
first
we're
looking
at
is
you
EBA
coming
up
this
year?
That's
a
user,
an
entity
behavior
analytics
of
monitoring
anomalies
that
may
be
occurring
within
the
gate,
lab
application
for
our
customers,
our
vulnerability
management.
We
talked
about
this
on
the
kickoff
call,
but
bringing
our
new
dashboard
and
M
our
widget
controls
and
adding
additional
functionality
to
them.
I
just
mentioned
the
container
network
security
and
we'll
talk
about
that
here.
B
In
a
second
and
then
we've
talked
about
the
lap
on
I
think
every
group
conversation
had
been
a
hit
lab,
but
focusing
on
continuing
to
round
out
what
that
can
do.
For
us.
The
Lester
I
just
wanted
to
highlight.
We
talked
about
this
on
the
last
call,
but
now
we're
mature
along
with
it.
So
we
are
contributing
upstream
to
cilium
and
improving
the
functionality
of
it.
C
They've
yeah
I
put
questions
in
before
the
before
the
meeting
started,
so
you'd
have
some
questions
to
start
off
with
I
think
we
should,
in
general,
try
to
get
more
people
to
do
that.
Just
start
five
minutes
early
get
some
questions
in
and
I
think
it's
super
helpful
to
kind
of
point
out
the
things
that
that
you
did,
you
think
are
highlights
and
give
some
more
context.
In
the
group
conversation
handbook
page.
C
B
C
B
So
first
I
agree,
we
said
I
think
would
be
great
if
people
could
start
any
questions
a
couple
minutes
beforehand
on
that
way,
there's
not
a
delay
of
noticing
other
group
conversations.
As
for
recording
a
video
ahead
of
time,
we
could
look
at
doing
that.
I
had
not
thought
about
doing
that,
I
think
as
defend
and
secure
become
more
complex.
It's
probably
worth
doing
that.
So
people
can
see
what
we're
playing
talking
about
and
get
a
little
bit
of
a
deep
dive
and
then
hopefully,
then
we
can
go
directly
into
questions.
C
Cool
yeah,
their
context
of
my
suggestion
is
that
this
time,
like
having
everyone
in
the
same
meeting,
the
synchronous
time
is
very
special
and
you
want
to
make.
We
want
to
be
an
asynchronous
company.
So
if
there's
something
we
can
do
asynchronous
so,
for
example,
recording
a
video.
Let's
do
that
not
in
the
presentation,
but
let's
do
that
in
a
fighh
another
medium
so
that
people
can
consume
it
beforehand.
C
C
D
Thanks
it
so
the
plans
for
dog
for
their
own
laugh
or
to
use
it
ourselves
initially
for
version
and
design
bucket
lab
comm.
We
had
it
in
place
for
those
and
actually
through
that
dog
fooding
and
a
couple
customer
reports.
There
were
some
availability
issues
in
the
applications
introduced
by
the
laughs,
so
we
pulled
it
back
out.
While
we
worked
on
those,
they
were
pretty
hard
to
reproduce
and
then
confirm.
We
resolved
the
seams
working
hard
on
that
and
we've
now
believed
with
high
confidence.
We
have
it
resolved,
so
we're
gonna
put
him
back.
D
Put
it
back
in
place,
you
might
ask:
why
do
we
want
to
laughs?
You
know
the
CloudFlare
wife
has
there
to
protect
us
from
attacks
on
the
internet.
Why
would
we
have
this
laugh
inside
you'll
behind
the
ingress
controller
on
kubernetes?
Is
that
I
think
it's
really
about
defense-in-depth?
It
still
makes
sense
to
do
it
for
that
reason,
and
it
will
help
us
detect
and
prevent
attacks
that
may
come
from
the
inside
versus
coming
from
the
outside
Philippe
and
Lucas.
Did
you
have
more
to
add
to
that
I
think
I.
E
F
Yeah
I
think
that
sums
it
up
pretty
well
in
the
case
of
version
design.
Those
are
both
applications
that
run
off
our
auto
dev
ops
pipelines.
So
it's
fairly
easy
for
us
to
get
in
front
of
it.
There
obviously
get
up
calm
in
terms
of
the
the
majority
of
the
product.
There
is
it's
a
bit
more
of
a
different
beast.
F
In
that
case,
we
have
to
actually
get
in
front
of
a
different
kind
of
traffic
than
there's
something
like
designed
version,
and
so
those
are
really
good
testing
grounds
for
us
to
work
off
that
there.
There
are
other
candidates
as
well,
and
we
link
this
issue
under
and
be
here
to
discuss.
Where
else
we
can
use
it
within
the
product.
C
D
E
Thanks,
yes
to
say,
I'm
working
on
this,
which
was
a
good
code,
because
we
had
a
huge
issue
with
the
wash
that
we
deploy
in
alteration
and
design
that
Capcom,
it
was
not
really
a
burden
or
site,
was
a
bug
in
the
absent
project
that
it's
fixed
in
thread
that
eight
so
I'm,
really
glad
that
was
outfitting
with
smaller
projects.
Instead
of
going
directly
with
Capcom
me.
C
D
First,
shot
at
that,
so
psyllium
is
to
implement
network
policies,
basically
a
firewall
inside
kubernetes.
What
pods
can
talk
to
what
other
pods
and
services
and
Falco
is
about?
Detecting
anomalous?
Behavior
could
be
at
the
kubernetes
level
of
the
kubernetes
api.
It
can
be
at
the
network
level.
We
just
there's
some
overlap
there
with
psyllium
a
little
bit,
and
it
also
is
at
the
host
level
the
virtual
host
running
inside
kubernetes.
B
C
Makes
sense
for
user
entity
behavioral
analytics
it's
cool
to
see
that
we're
gonna
do
that
for
gitlab
itself.
First!
Is
that
something
that
people
can
reuse
in
their
own
application,
their
non
get
lab
applications?
Are
we
making
super
sure
that
we
communicate
to
kind
of
customers
like
hey?
We
want
using
entity
behavior
analytics
for
your
applications,
not
just
forgive
lab
it's
just
that
we're
starting
with
your
phone,
because
we
want
a
dog
food
first,
how
I
stop
playing
out
so.
G
Still
in
kind
of
the
early
discovery
stages,
but
when
shopping
around
the
idea
that
we
already
have
some
of
these
tools
that
our
security
team
is
able
to
kind
of
use
to
look
for
things
like
this
inside
of
get
lab.
We've
had
very
positive
customer
response
by
baking
that
in
especially
on
the
federal
side,
so
people
like
that
as
a
starting
point.
If
we
roll
that
out
for
get
lab
itself,
that
should
be
common
across
all
customers
and
then
we'll
look
to
extend
that
out
into
the
application
side.
G
C
I
love,
I,
love
the
direction.
I
think
you
want
to
be
super
clear
how
we
communicate
that
so
that
we
that
at
no
point
our
customers
get
the
impression
like.
Oh
wait,
you
ad
a
they
mean
just
measuring
gitlab
stuff,
not
my
application,
and
because
of
where
we
start,
we
want
to
be
sure
that
we
be
communicated
appropriately.
I
do
love
the
direction
of
like
hey.
Are
our
security
teams
and
our
abuse
teams
already
generated
all
these
tools?
C
H
I
Yeah
yeah
I
can
take
that
one,
so
I'm
good.
So
for
that
one,
essentially,
what
we're
doing
there
is
we're
layering
in
a
firewall
around
the
pods
that
are
inside
of
the
kubernetes
cluster,
and
this
allows
you
to
write
firewall
rules
that
defend
against
other
pods
even
inside
of
the
same
kubernetes
cluster
as
well
as
attacks
coming
originating
from
the
internet.
So
I
put
a
few
examples
on
that
slide.
You
know
the
one
example
is
an
attack
coming
from
the
internet.
I
You
will
be
able
to
filter
the
traffic
there
so
that
the
traffic
coming
in
is
limited
to
the
ports
and
even
IP
addresses.
If
you
want
coming
that,
you
would
expect
coming
in
to
that
particular
application.
You
can
also
filter
the
traffic
between
pod
so
that
you
can
name
specific
pods
so
that
the
communication
should
occur
with
so
in
the
instance
that
an
attacker
was
able
to
get
control
of
the
kubernetes
cluster
and
instantiate.
A
new
road
was
compromised
pod.
I
H
H
I
H
I
H
J
Hey
there
so
I'm
trying
to
wrap
my
head
around
the
security
system.
On
my
background
is
standard
software
engineering
and
a
lot
of
times
are,
you
know,
fantastic
the
magic
with
the
security
behind
the
scenes
so
trying
I'm
in
discussions
for
the
customer
and
they're
there,
a
dead,
spec,
ops
manager,
and
so
they
kind
of
own
that
project
and
they're
very
interested
in
our
security
roadmap
and
they're
very
interested
in
our
laughs
capabilities
coming
down
the
pipeline
and
I'm
trying
to
help
build
angles
for
myself.
My
question
is
with
regards
to
that
discussion
with
them.
J
Are
we
aiming
to
do
kind
of
like
a
if
you're
familiar
with
the
80/20
rule
about
taking
a
large
portion
of
the
feature?
Sets
that
most
people
need?
Are
we
looking
to
do
that
or
with
our
single
platform
abilities?
Are
we
looking
at
capabilities
to
shift
less
that
others
are
not
going
to
be
and
I'm
really
what
I'm
looking
for
is
down
the
line?
Are
we
going
to
have
unique
differentiators
that
I
can
sell
now
and
if
so,
what
would
be
the
best
source
of
documentation
to
lean
on
those
differentiators
community.
B
Sure
so
I'll
take
a
first
I'm
answering
a
question.
I
would
like
to
have
Matt
and
Sam
also
add
a
little
bit
of
context.
So,
with
regard
to
shifting
luck,
that's
more
of
a
conversation
around
what
we're
doing
was
secure
and
so
moving
the
testing
closer
to
the
developer.
However,
with
the
lab
we
plan
on
leveraging,
our
shift
left
to
eventually
can
to
eventually
improve
the
policies
that
you
see
in
the
operation
side,
and
one
of
that
is
a
person
by
the
madera
quit
I,
don't
know
is
on
the
call.
B
I
Yeah,
so
I
definitely
agree
with
that.
I
would
say
that
you
know
we're
in
the
process
of
evaluating
what
our
strategy
is
here
and
exactly
how
we're
going
to
you
know
really
deliver
on
that
value
that
we
started
out
to
add.
You
know
I.
Think
some
of
our
key
differentiators
and
advantages
here
are
that
we
really
own.
I
You
know
this
whole
pipeline,
and
so
as
we
look
at
it
from
the
perspective
of
these
rules,
in
the
sense
are
a
piece
of
source
code
themselves
and
they
need
to
go
through
the
same
approval
process.
But
you
know
any
other
code
would
need
to
go
through
as
it
gets
checked
in.
We
definitely
have
some
advantages
and
you
know
keep
existing
capabilities
that
we
can
leverage
there.
You
know
where
we
can
put
any
changes
into
these
rules
through.
You
know
full
mr.and
approval
process,
so
you
don't
ever
have
one
person
making
a
change
in
isolation.
G
And
I'll
add
to
that
on
the
vulnerability
management
side.
Right
now,
it's
focused
on
identified
vulnerabilities
in
the
source
code,
so
we're
trying
to
do
all
the
testing
in
the
secure
stage
before
it
gets
out
to
production.
Ultimately,
there
will
be
anomalous
traffic
indicators
of
compromiser
attack
on
the
application
infrastructure.