►
From YouTube: Defend Section 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
You
hey
welcome
to
the
very
first
defense
section
group
conversation,
so
we
have
presentation
this
just
a
little
bit
of
talk
track.
This
group
was
just
formed.
It
has
been
part
of
we've
seen
the
defend
category
on
our
homepage
for
almost
the
entire
year,
but
we
now
have
a
specific
set
of
individuals
working
on
defend
related
features
in
our
first
MBC
this
released.
So
we
wanted
to
have
start
having
regular
group
conversations
so
with
that
I
will
open
it
up
for
questions.
The
first
one
is
from
Cindy
I
believe.
B
Oh
answer
first
and
Sam
you
can
follow
up,
I
will
say
we
we
always
plan
ambitiously.
We
try
to
make
the
category
maturities
realistic,
though
I
will
say
that
the
I
think
of
the
category
maturity
increments,
so
from
plan
to
minimal
minimal
to
viable
as
increasingly
larger
efforts
per
one
like
an
NBC
is
just
like.
We
say
a
something
you
can
do
in
one
iteration
and
I
am
confident
that
Sam
and
the
team
can
think
of
very
small
iterations
for
each
one
of
those
I.
B
Have
this
thing
in
my
head
that
I
actually
wasn't
here
at
get
lab
for
so
maybe
somebody
else
can
comment
on
it.
But
I
know
that
when
we
started
the
secure
stage,
we
similarly
created
a
whole
bunch
of
NBC's
rather
quickly
for
entire
categories
of
standing
tools
and
so
I'm
I'm,
confidently
optimistic
that
we
can
do
the
same
in
defend
and
I
will
say
it's
we're
starting
today
and
we
have
the
official
and
is
at
January
our
calendar
year
or
our
fiscal
year
end.
So
it's
more
than
just
one
quarter.
D
Just
add
up
on
to
that
a
little
bit.
One
of
the
other
things
in
the
defense
stage
is
we're
gonna,
be
hiring
very
aggressively
to
build
out
this
team.
So
as
more
and
more
team
members
come
on
come
join,
you
know
we'll
be
able
to
move
much
more
quickly
as
well.
So
combined
with
the
fact
that
you
know
these
are
going
to
be
NBC's
first
iterations
on
these
different
capabilities.
You
know
we're.
D
E
Go
Christopher
here
the
next
question:
yeah
thanks
Kenny,
so
it's
kind
of
similar
to
Cindy's
question
just
looking
for
if
we
have
any
sense
for
Park
mark
priority
for
the
various
categories
and
I'm,
not
necessarily
looking
for
like
a
absolute
list
as
much
as
I'm.
Just
looking
for
like
yeah
like
these
are
the
two
or
three
that
really
customers
been
asking
for
or
are
giving
us
feedback
that
they're
really
interested
in.
D
Yeah
so
in
terms
of
rough
prioritization
for
the
different
categories
in
the
defense
stage,
we're
still
trying
to
get
feedback
and
make
sure
we're
focusing
on
the
most
important
ones.
First,
so
you
know
this
is
going
to
be
my
I
take
today,
but
could
change
in
the
future
as
we
learn
more
we're
going
to
be
starting
with
the
laughs,
because,
as
we
have
more
and
more
of
our
gitlab
users
and
use
cases
focusing
on
web
applications,
there's
a
real
opportunity
to
make
a
difference
in
securing
those
apps
by
Milwaukee,
malicious
traffic.
D
After
that,
what
I'm
thinking
for
our
second
category
to
emphasize
is
going
to
be
vulnerability.
Management
as
the
wife
capability
matures
we're
gonna
start
seeing
a
lot
more
data,
a
lot
more
information
about
live
attacks,
as
they
happen
so
being
able
to
manage
the
results
manage
the
vulnerabilities
we
were
able
to
identify
is
going
to
be
another
important
value
point
we
can
provide
to
our
users
and
then,
after
that
container
network
security
is
kind
of
what
I've
got
on
my
list
as
number
three
again
since
web
applications.
D
Kubernetes
and
clusters
are
going
to
be
key
use
cases
for
a
lot
of
our
users
being
able
to
make
sure
that
those
networks
aren't
being
exploited
or
used
inappropriately.
You
know
is
another
place
we
can
have
value,
but
it
has
been
interesting.
I've
had
a
couple
conversations
this
week
and
last
week
focusing
on
data
loss
protection,
so
that's
DLP
as
well
as
storage
security,
so
gonna
be
digging
into
that
some
more
in
the
near
future.
To
figure
out
you
know
is
that
an
area
that
we
need
to
emphasize
sooner
than
some
of
those
other
categories.
B
And
I'll
point
out
that
you
know
we're
talking
about
moving
from
planned
to
minimal
here.
So
these
are
all
NBC's.
Part
of
the
job
of
those
MVC's
is
to
also
get
some
additional
sensing
information
about
how
customers
feel
about
those
MVC's
and
where
what
direction
we
should
take
them
and
which
ones
we
should
focus
on.
So
do
you
think
there's
an
opportunity
as
we
as
Sam
stated
like
as
we
have
NBC's
in
the
wild
that
customers
are
using,
we
should
will
be
getting
great
feedback.
B
F
Yeah
thanks:
could
you
explain
a
bit
how
the
variety
management
category
will
play
with
what
is
currently
being
done
in
integer
with
the
dashboard
or
the
professional
abilities
workflow,
because
I'm
feeling
that
sis
can
this
kind
of
end
up
in
in
the
same
area,
whatever
it's
coming
from
live
venerable
Finnerty
from
the
live
application
of
morality
from
the
source
code
or
the
dependency
that
are
also
impacting
the
live
application?
But
it's
not
coming
from
the
live
environments,
but
we
still
have
the
same
process
dealing
with
the
Bernabeu
once
we
cut
them.
B
B
Think
the
natural
inclination
when
we
think
about
defend
is
to
equate
it
to
like.
We
should
use
and
leverage
some
of
the
same
tools
that
we
use
in
secure,
but
I
actually
wonder
if
the
more
natural
one
is
using
leverage
the
things
we
use
in
ops
or
configure
and
monitor.
So
maybe
a
vulnerability
comes
in
as
an
incidence,
not
as
a
vulnerability.
I,
don't
know
Sam
if
you
thought
much
about
that,
but
that
was
having
that
conversation
yesterday.
B
D
I
mean
similar
to
the
comment
you
made
Kenny
about
you
know
tying
it
with
monitor
or
ops.
Really
things
I
think
a
lot
of
the
defendant
capabilities.
We're
gonna
build
out
are
gonna,
be
very
closely
related
to
secure
capabilities
as
well
Olivier.
Your
your
questions
are
great
one
about
first
class
vulnerabilities
because
that's
actually
going
to
be
pivotal
to
the
MVC,
for
what
we're
gonna
call
vulnerability,
management
I,
don't
see,
secure
and
defend
having
a
separate,
workflow
or
entity
necessarily
for
a
vulnerability.
D
I
think
it's
get
labs
opportunity
to
use
the
same
experience
and
same
workflows
for
both
and
that's
actually
gonna,
be
really
powerful
and
unique
for
us
in
the
marketplace,
because
the
market,
when
you
talk
about
vulnerability
management,
is
really
focusing
on.
You
know:
live
production
applications
addressing
those
problems,
but
I.
Think
if
we're
able
to
broaden
that
definition
and
say
this,
how
everyone
else
does
it,
but
we
do
all
that
plus
more
that's
actually
going
to
be
much
much
better
for
us
as
a
company.
F
D
Exactly
and
I
I
think
that's
gonna,
be
one
of
the
things
we'll
need
to
talk
about
for
pretty
much
every
secure
capability.
How
can
we
make
it
amenable
to
defend
in
every
defend
capability?
How
can
we
make
it?
I
mean
able
to
secure
as
well,
because
they
are
separate
stages
in
their
different
use
cases,
but
they're
so
closely
related
that
I'm,
confident
there's
a
quick
jump
from
one
to
the
other.
In
most
cases,
thanks.
B
F
Think
it's
quite
different
when
it's
what
the
discussion
already
had
and
I
have
the
feeling
that
four
teeth
and
her
abilities
it
could
be
more
something
like
system,
availability
engineers
or
something
like
that.
More
than
developer
software
developer.
But
it's
cool
to
think
about
having
a
unique
tool
and
unique
place
to
see
all
the
possibilities.
I
think.
C
It
would
be
great,
though,
if
you,
if
you
capture
it,
if
the
vulnerability
started
in
secure
and
gets
exploited
in
production,
that
you're
able
to
to
still
see
that
the
this
particular
vulnerability
was
exploited
or
not.
So
maybe
it
becomes
like
a
flag
that
says
it's
a
vulnerability
that
has
or
has
not
been
exploited.
C
G
To
add
on
some
additional
thoughts
here,
because
I've
had
some
opinions
on
where
we
could
go
first
with
this,
the
one
of
the
advantages
we
have
within
get
lab
is
not
only
with
defend
and
secure.
If
we
think
of
them
as
a
better
together
a
kind
of
story,
we
have
the
advantage
of
knowing
what
has
been
deployed
to
production
environments
and
where
so
that
means
we
already
know
what
has
been
dismissed.
What
has
been
allowed
through
and
with
vulnerabilities
not
being
a
static
problem.
G
There
will
always
be
new
discoveries,
new
neural
phoner
abilities,
and
that
we
will.
That
will
happen
after
something
has
gotten
through.
One
of
the
questions
that
defends
can
answer
that
secure
cannot
well
secure,
can
answer
what
code
and
what
dependencies
and
what
potential
part
of
your
container.
What
part
of
your
application
is
vulnerable
defends
can
answer
what
servers,
what
containers
which
part
of
your
production
environment
is
vulnerable.
So
it's
not
just
what
application
it's
where
in
your
production
environment
needs
to
be
patched
after
it
has
been
let
through
so
there's
a
it's.
G
B
So
it
might
be
a
little
bit
of
if
you're
a
hammer
everything's
a
nail,
but
I
do
think
that
there's
some
overlap
between
those
same
workflows,
we're
talking
about
in
incident
management
and
what
you
just
described.
Thomas
you,
you
cool.
That
was
a
great
discussion
and
when
I
keep
adding
to
that
before,
we
moved
to
Scotts
one
which
is
kind
of
similar.
B
G
Me
add
one
more
item
on
this
place
for
a
defense.
We
don't
have
to
wait
on
the
exploit
because
we
know
what's
what
we
as
vulnerabilities
are
discovered.
We
know
what
has
been
let
through
and
what
party
application
is
vulnerable,
so
you
don't
need
the
exploit.
What
we
need
is
the
discovery
of
the
vulnerability
against
what
has
been
released.
That
was
the
full
that's
the
rest
of
what
was
in
my
head
that
it
didn't
didn't
escape
my
mouth,
so
just
want
to
make
sure
that
point
was
put
out
there
awesome.
H
First
of
all,
Kenney
Sam,
Thomas
Cindy.
It's
awesome
to
see
this
section
get
going
my
question,
so
you
have
themes
on
slide.
Five.
Thank
you
for
that.
One
of
them
is
called
inform
action
for
other
stages.
Could
you
give
me
an
example
of
where
defend
might
be
able
to
feed
cool
info
back
and
I
know
you
just
covered
some
ground
there,
but
if
you
want
to,
if
there's
a
different
example
that
her
that'd
be
fun,
yeah.
D
So
the
the
one
example
I
think
we'll
be
able
to
solve
actually
provide
very
soon
with
the
laughs.
Imagine
if
you've
deployed
a
web
application
that
has
a
sequel
injection
vulnerability.
So
that's
when
an
attacker
is
able
to
essentially
write
a
command
that
your
database
interprets
in
a
way
you
don't
intend.
If
the
waffe
is
able
to
identify,
hey,
a
sequel
injection
has
occurred
against,
say,
an
authentication
page.
D
We
can
protect
and
defend
against
that
attack
as
it's
occurring
live
and
then
I
want
us
to
be
able
to
create
an
issue
back
tag
it
against
that
relevant
piece
of
code
and
say
this
is
a
vulnerable
part
of
your
application
and
then
you
can
fix
it
during
development,
and
then
you
know
the
wife
will
continue
defending
against
sequel
injections.
But
at
that
point,
once
the
original
vulnerability
has
been
patched,
it
doesn't
matter,
even
if
the
wife
was
removed.
H
E
E
We're
gonna
go,
do
this
kind
of
mindset
of
you
know,
hey
we're
gonna
go.
Do
this
and
here's
how
we're
gonna
go
about
doing
it
and
there's
the
principal's
reviews,
but
the
mission,
my
questions
for
the
opposite,
which
is
what
are
the
things
we're
not
going
to
do,
or
you
know
things
that
maybe
we've
learned
from
other
stages
being
created
that
we
want
to
avoid.
B
I
haven't
been
here
for
a
stage
creation,
so
I'm
not
sure
if
I'm
the
best
to
answer
that
Phillippi
your
picture
is
on
my
screen
and
I,
don't
know.
If
maybe
you
could
speak
to
the
seeding
of
the
secure
stage,
any
kinds
or
recommendations
that
aren't
already
in
the
handbook
I
have
thoughts
on
this
is
where.
I
Yeah,
when
I
look
at
this
slide
at
the
slide
for
I
think
it's
it's
very
optimistic
to
think
that
we're
going
to
do
everything,
one
father.
What
was
one
of
the
problems
that
we
had
with
secure
beginning
with
try
to
grasp
as
much
as
possible,
and
we
did
a
lot
of
things,
but
it
was
kind
of
butterflying
over
all
the
features
that
we
wanted
to
add.
I
In
the
end
we
just
had
nbc's,
and
that
was
a
problem,
because
when
we
started
to
talk
to
customers,
they
were
puzzled
by
the
depth
of
of
the
features
we
were
we
were
proposing,
so
that
could
be
one
of
the
trap.
Trying
to
do.
Everything
at
once
would
be
cautious
about
that,
and
maybe
there
is
something
in
the
middle
bit
to
Brighton
death.
You
know,
but
that
would
be
my
advice
to
you
to
start
this
new
stage.
But
of
course
we
have
a
lot
more
experience.
B
I
just
want
to
challenge
that
assertion
about
breath
over
dev,
and
maybe
it
comes
down
to
like
do.
We
consider
the
path
we
took
in
the
secure
stage
of
success.
I
think
we
do
on
a
business
fundamentals,
perspective
I
think
we
certainly
do.
It
was
a
huge
contributor
to
our
revenue.
Growth
in
20
in
calendar
year,
2018
and
Henao
has
become
like
the
linchpin
in
our
ultimate
offer
and
contributing
I.
Think
it's
like
20
percent
incremental
iacv,
so
I,
wouldn't
it
was
probably
painful.
G
I
could
pivot
it
a
little
bit.
The
lesson
learned
from
secure,
specifically
that
should
be
applied
with
defense,
because
it
has
a
similar,
breadth
profile
that
secure
has
is
the
back-end
team
needs
to
be
split,
much
more
aggressively
and
much
sooner,
even
if
we,
even
if
it
is
a
logical
split.
The
one
of
the
challenges
that
secure
had
earlier
this
year
was
that
we
effectively
had
seven
back
in
engineers
trying
to
track
seven
back
in
top
level
features,
so
every
engineer
having
to
track
seven
things
at
once.
G
So
the
lesson
learned
from
secure
to
me
is
to
split
sooner,
even
if
there's
a
logical
split
and
that
we're
having
an
engineer
a
manager,
pull
double
or
triple
duty.
It
protects
the
engineers
and
will
allow
us
to
maintain
velocity
as
we
increase
the
breadth
and
the
depth
of
every
feature
that
we
are
trying
to
produce.
There
go.
B
G
Splitting
groups
within
the
defense
stage,
so
as
soon
as
one
back-end
engineering
team
within
defend
it's
established
and
as
we
go
breath
for
more
features,
split
them
as
we
add
features,
let's
not
repeat
the
track
of
five.
This
one
team
trying
to
track
five
to
six
features,
make
it
so
that
they're
tracking
two
to
three
and
and
do
a
logical,
split
aggressively
more
aggressively
that
we
did
was
secure.
B
Yeah
and
I'll
say
from
a
hiring
perspective,
just
my
observation
of
as
we've
been
splitting
teams
hiring
the
engineering
managers
to
then
be
able
to
focus
on
hiring
the
engineers
seems
to
like
really
accelerate
our
velocity.
So
in
the
instances
where
manager
is
doing
double
duty,
it
becomes
painful
for
them
to
both
ramp.
New
team
members
hire
a
massive
team
and
still
waiting
for
a
pure
counterpart.
J
Yeah
I
was
just
going
to
add
to
that
as
well
and
and
say,
while
I
haven't
been
here
all
that
long
I
feel
like
the
we
probably
should
have
started,
hiring
defend
people
a
lot
sooner,
and
perhaps
we
tried
that
and
we're.
You
know
we're
just
now
getting
the
the
people
coming
through,
but
yeah
I
guess.
I
would
like
to
have
seen
the
the
team
formed
a
few
months
before
our
first
MVC
as.
B
Sense
and
I
will
say
like
to
the
development
department
in
general.
There's
been
great
coordination
about
priority
between
and
across
stages
about
where
we
should
be
hiring
and
I'm,
not
I'm,
not
looking
backwards
and
saying
we
should
or
shouldn't
have
done
something
earlier
or
later,
I
think
we've
made
decisions
about
prioritization
and
they
were
the
correct
decisions.
I
really
think
going
forward,
though
we
should
just
think
about
maybe
focus
on
hiring
managers
first
and
Thomas's
point
splitting
teams
so
that
they
have
less
scope
and
kind
Tech.
B
E
Can
certainly
prioritize
hiring
managers
from
a
prioritization
perspective
of
visibility
to
make
sure
that
we're
going
after
that
one
thing
I'd
caution
is:
is
we
really
do
need
a
rhyme
hiring
of
managers
in
engineers
and
parallel
and
see
just
how
it
plays
out
for
two
reasons?
One
specifically,
if
you
daisy
chain
those
two
you're
going
to
even
be
later
and
everybody's
gonna
be
disappointed,
the
other
aspect
is
is,
is
as
engineering
managers
or
harder
to
find
than
engineers
are
just
strictly
by
the
fact
of
what
we
expect
them.
E
The
experience
levels
that
we
expect
associated
with
that
so
because
of
that
the
population
is
much
smaller
and
consequently,
we
have
to
think
about
those
terms
so
agree
with
prioritization
I.
Just
want
to
be
crystal
clear.
The
result
may
still
be
is
that
you
see
people's
either
showing
up
in
parallel
to
each
other
or
engineers
coming
first
and
that's
just
that's
just
the
nature
of
the
way
hiring
works
right
now,
I
get
lab
cool.
B
Make
sense
I,
don't
see
any
other
question
so
I'll
just
close
by
saying
this
is
an
awesome
conversation.
Thank
you
all
for
participating,
Sam
and
Todd,
and
Thomas
and
I
were
kind
of
like
we
don't
know.
We
don't
have
a
lot
of
contents,
we're
just
getting
started,
but
it's
great.
This
is
super
useful
to
me
and
I'm
sure
others.
So
thank
you
for
participating
and
take
care.
Thank.