►
From YouTube: Threat Management Office Hours 2021-03-24
B
C
B
C
A
good
issue
to
reference
so
right
now
we
are
sitting
at
number
seven
on
the
list
for
the
first
step
of
the
refactor
start.
Taking
in
that
direction,
I
think
there
are
there's
going
to
be
several
things
that
roll
off
pretty
quickly.
If
you
look
at
that
so
stuff,
that's
been
in
flight
for
a
while,
like
large
projects
like
the
generic
security
report
still
sitting
at
the
top
there.
I
think
the
filtering
project,
vulnerability
report
by
vendor
name
that
just
barely
missed
the
last
release
and
then
bulk
updates
and
dismissal
type
reasons.
C
Yeah,
so
those
first
four,
I
think,
are
probably
looking
good
to
wrap
up,
hopefully
in
this
upcoming
1311
release,
which
is
going
to
bump
everything
up
a
lot
higher
and
then
looking
at
some
of
the
other
pieces
like
number
five,
the
additional
security
export
stuff.
Hopefully
that's
not
too
big
of
a
deal
just
adding
data
we
already
have
into
the
existing
csv
report,
so
it
looks
kind
of
far
down
there,
but
I
don't
think
it's
as
far
away
as
people
might
think.
B
C
B
C
Anybody
that
has
integrated
third-party
scanners.
I
think
it's
it's
helpful
to
them
to
see
the
difference,
and
it's
helpful
to
us
too.
So
we
can
offer
compare
contrast
during
demo
situations.
So
a
lot
of
our
scanners
that
we
provide
same
type
technology
from
third-party
vendors.
We
stack
up
very
well.
C
You
know,
usually
at
parity
some
cases
a
little
better,
some
cases
you
know.
Maybe
we
have
some
more.
You
know
false
positives
that
require
a
little
tuning,
but
if
you're
able
to
actually
toggle
between
the
vendors,
you
can
kind
of
see
what
is
coming
from
where
and
it's
just
that
extra
bit
of
visibility
too.
There
is
a
vulnerability
management
solution,
competitor
in
the
space.
C
B
A
Okay,
I
added
two
questions.
The
second
one
is
a
bit
confusing,
maybe
we'll
skip
it,
but
the
first
one
is
matt
for
matt.
You
keep
being
asked
about
a
nuke
button
for
the
vulnerabilities
somebody,
you
know,
tries
our
scanners
and
analyzes
and
creates
a
billion
findings
because
it
was
misconfigured
misconfigured
or
they
didn't
know
how
to
use
it
or
for
other
reasons
they
want
to
start
fresh
and
you've
been
very
reluctant.
So
my
question
is:
when
are
you
going
to
cave
in
and
just
do.
C
So
if
we
were
to
build
some
sort
of
large
function
around
that,
I'm
not
sure
that
there's
enough
utility
out
there
for
customers
on
the
test
mode
side.
So
what
I
kind
of
I
like
this
idea,
but
only
because
I
think
it
sort
of
solves
the
problem
hasn't
been
validated,
but
allowing
new
projects
to
be
put
into
a
test
mode,
potentially
even
just
an
option
when
you're
creating
it
and
it's
a
one-way
gate.
C
As
soon
as
you
turn
something
off
from
test
mode,
it
will
give
you
the
option
that
one
time
would
you
like
to
clear
out
all
the
existing
vulnerability
records.
If
you
say
yes,
they'll
delete
everything.
If
you
say
no,
it
basically
is
just
like
any
other
normal
project.
You
can
never
put
test
mode
back
on.
It's
like.
I
said
it
would
be
a
one-time
thing,
probably
limited
to
the
owner
of
that
project.
C
C
Right
so
I'd
say:
I've
heard
this,
maybe
half
a
dozen
times
over
the
last
year
or
so,
and
it
always
comes
down
to
customers
were
testing.
They
weren't
really
quite
sure
what
they
were
getting
into.
So
they
just
kind
of
they
lit
up
all
the
switches
and
things
started
happening,
and
there
was
all
this
stuff.
C
A
C
Yeah
so,
like
that's
kind
of
why
I'm
stuck
because
I
don't
think
it's
a
small
effort,
I
think
it
is
still
limited
in
terms
of
the
utility
for
people.
I
think
that
it's
also
dangerous
if
we
get
it
wrong
and
the
way
that
gitlab's
roles
are
set
up
today
in
a
permission
model,
it's
not
flexible
enough
for
most
organizations,
especially
large
organizations.
So
the
idea
that
you
would
need
to
restrict
this
to
only
a
select
few
individuals
is
very
difficult.
C
So
it's
I
don't
know,
there's
a
lot
that
could
go
wrong
if
we
didn't
do
it
well,
and
the
easiest
thing
to
do
is
just
do
nothing
and
say
it's
a
feature.
The
vulnerabilities
are
forever
in
the
product.
You
can
always
filter
out
what
you
don't
want
to
look
at
and,
as
you
close
things
out,
they'll
naturally
disappear
from.
You
know
your
default
view
and
we
provide
a
full
audit
history
for
the
lifetime
of
the
project.
C
C
I
screwed
up
the
entire
instance,
let's
just
let's
just
burn
it
to
the
ground
and
we'll
start
fresh
right.
So
again,
it
just
seems
like
it's,
it's
painful,
but
in
such
a
very
very
small
situation,
it
seems
like
maybe
just
education
during
the
setup
process
is
potentially
a
better
approach.
Saying
hey
before
you
turn
on
the
scanners.
Maybe
consider
doing
this
on
a
test
project
or
make
a
fork
see
what
this
does.
A
And
gerard,
if
anyone
ever
asks
about
that
in
support,
there
is
a
script
that
we
ourselves
used
it
you
do,
need
console
access
so
for
self-managed
instances,
it's
probably
easier
to
use,
but
does
come
with
the
usual
caveats
of
back
up
your
data.
Make
sure
you
know
you,
you
know
how
to
restore
it
and
then
you
can
blast
it
away.
A
C
C
Somebody
was
trying
stuff
out
with
the
scanners
for
the
first
time
and
just
didn't
configure
it
the
way
that
they
ultimately
would
want
it
and
then,
at
the
end
of
the
tuning
process,
they
have
the
scanners
correct,
but
then
they're
kind
of
looking
at
it
going
well.
There's
all
these
findings
that
maybe
I
don't
care
about
or
they're,
not
what
I
was
looking
for.
I
don't
think
I've
ever
heard
of
a
single
customer
having
that
problem
with
more
than
one
project.
C
A
A
When
you
click
on
them
and
you
go
in,
you
can
see
the
fields
that
are
not
available
on
sas,
so,
for
instance,
for
if
you,
if
you
create
a
sas
report,
you
usually
you
have
location
and
one
other
field
that
I
don't
remember
what
it
was,
but
then
for
containers
here.
Is
you
have
an
image
and
a
namespace?
A
So
if
you
click
in
you
see
those
and
the
thing
will
be
reported
assassed
and
it's
that's,
that's
not
possible.
So
one
of
the
things
that
we
were
talking
about
is
that
maybe
there
should
be
a
a
generic
one
that
says
you
know
what
this
this
analyzer.
This
scanner
is
generic
and
it
may
generate
sas
things
or
dash
things.
We
don't
know
it'll
come
in
what
do
you?
What
are
you
thoughts
about
that?
That
sort
of
area
orb
or
maybe
it's
none
and
that's
fine,
we'll
talk
about
it
later.
C
So
my
my
thinking
on
this
one
is
well.
First
of
all,
I
realize
that
as
we've
sort
of
evolved
vulnerability
management,
the
name
for
that
drop
down-
is
not
really
vendors,
probably
not
going
to
be
the
best
name,
long
term,
even
even
shorter
term,
because
we're
working
on
creation
of
vulnerability
objects
manually
in
the
ui.
C
C
I
think
we
could
still
list
them
as
such,
because
we
are
kind
of
calling
them
out
separately
or
we
might
be
able
to
rethink
that
and
say
you
know,
keep
vendor,
as
is
it
actually
get
lab
or
one
of
the
third
parties,
and
then,
when
you
select
method,
if
it's
a
third-party
vendor
that
uses-
let's
say
you
know,
sassed
and
you've
also
run
the
gitlab
sas.
You
would
actually
see
a
mixing
of
both
results
from
both
vendors,
for
instance,
and
this
is
kind
of
top
of
the
head
like.
C
C
We
need
to
know
if
it's
git
lab
or
something
else
I
do
see
a
potential
for-
and
this
goes
back
to
james's
original
brown
bag
on
this
month's
back
on
the
generic
concept,
creating
your
own
tools
that
could
just
run
inside
of
a
pipeline
job
and
output
us
something
so
it
may
not
be
a
traditional.
You
know
a
sas
finding
or
a
das,
binding
or
whatever,
and
we'll
need
to
make
sure
that
we
can
account
for
all
that
in
a
sensible
way.
So
in
that
case
the
method
might
just
be.
You
know,
custom
tool.
C
A
Yeah
that
was
really
powerful.
I
really
enjoyed
watching
that
brown
bag
from
from
james.
He
did
a
the
time,
traveler
git,
demo
and
and
some
some
other
sneaky
attacks
on
repositories
and
the
generic.
So
so
there
was.
There
was
a
bit
of
confusion
around
the
generic
schema
and
the
details
field
they're
related.
So
the
part
of
the
what
made
it
confused
is
that
the
generic
schema
was
meant
to
introduce
the
details
field,
but
then,
along
the
way
we
say:
hey,
we
can
introduce
the
generic
the
details
field
to
every
other
schema.
A
So
if,
if
you,
if
you're
a
sas
scanner-
and
you
want
to
add
some
some
other
details
that
are
that
fit
some
of
the
the
components
like
a
numbered
list
or
a
hash
or
diff
or
a
free
text
field,
you
can
go
ahead
and
do
that
and
then
they
sort
of
became
one
of
the
same,
but
they
still
different.
The
the
the
idea
of
of
a
truly
generic
report
goes
with
what
you're
saying
on
the
manually
entered
vulnerabilities.
A
C
Like
let's
say
that
I
decide
for
whatever
reason
I
want
to
run
nmap
against
a
particular
section
of
my
network.
Every
time
I
run
a
pipeline
just
to
make
sure
that
there's
nothing
new,
that's
appeared
right.
I
don't
know
whatever
using
the
generic
report.
That
I
think
would
be
a
great
use
case
for
something
like
that.
It's
not
one
of
our
code
analyzers,
but
it's
something
that
you
care
about
running
in
the
pipeline.
C
From
a
security
perspective
and
as
long
as
whatever
wrapper
you've
written
around
nmap,
you
could
just
pull
those
back
in
make
the
details.
You
know
the
output
of
nmap
put
that
into
the
structure,
details
field
and
then
now
you've
got
you
know.
What's
what's
the
new
detection
type
custom
nmap
wrapper
right,
you
select
that
you
see
all
the
things
just
like
you
would
in
any
other
vulnerability
in
the
report,
and
then
the
details,
of
course,
is
whatever
you've
decided
to
make.
That
transform.
Look
like.
A
B
C
C
A
B
C
C
Well,
so
it
depends
on
what
you
mean
by
next
step,
so
in
a
git
lab
kind
of
public-facing
marketing
sense
it's
to
continue
to
mature
the
vulnerability
management
category
of
threat
insights
to
complete,
like
that's,
that's
the
next
step,
so
we
already
did
minimal.
Then
we
were
viable.
I
think
for
most
stages.
C
I
don't
want
to
say
parody
because
we're
not
just
trying
to
do
one-for-one
features,
but
things
that
people
have
come
to
expect
out
of
a
solution
that
is
from
a
you
know,
a
point
solution
or
an
established
vendor.
I
think
that's
kind
of
the
case
for
vulnerability
management.
I
expect
at
least
18
months
from
when
we
hit
viable,
so
this
will
probably
be
you
know,
spring-ish
summer
of
next
year
before
we
would
really
be
able
to
say
we're
complete
from
that
perspective
to
slice
a
little
bit
differently.
C
Viable
was
not
going
to
be
achievable
unless
we
had
a
certain
amount
of
sort
of
foundational
capabilities
for
that
sec
team
right
I
mean
it's.
Typically,
the
security
team
they're,
the
ones
triaging
things
they've
got
a
you
know:
they're
remediating
it.
So
it's
not
workable
for
a
security
team.
We
don't
really
have
a
solution
in
that
area.
C
A
good
component
of
complete,
however,
is
going
to
be
focused
on
the
developer
side
of
it.
So
we
do
talk
a
lot
about
shifting
left
and
you
know
that's
that's
great.
We
have
all
these
scanning
tools
and
we
have
a
lot
of
things
that
we've
provided
for
development,
but
where
we
have
some
gaps
right
now
is
we
don't
necessarily
make
it
easier
to
understand?
What's
going
on
or
to
really
help
people
sort
of
engage
right?
So
it's
the
old
adage.
You
can
lead
a
horse
to
water,
but
you
can't
make
a
drink.
C
C
The
mr
redesign
is
one
of
the
big
steps
in
that
direction
is
just
making
the
experience
better
in
you
know
in
the
mr,
where
developers
spend
most
of
their
time
some
things
not
quite
ready
to
talk
about
publicly
yet,
but
having
some
conversations
with
some
vendors
that
could
provide
more
information
from
a
like
a
training
perspective.
So
that's
another
big
thing
that
I
hear
actually
a
lot
from
both
security
professionals
and
from
some
of
our
customers
is
cool.
C
The
developers
are
seeing
all
the
stuff
that's
in
the
code,
but
then
they
look
at
and
they're
like.
I,
I
don't
know
what
a
csrf
token
is
or
why
not
having
it
is
bad
or
how
do
I
fix
it,
and
so
it
requires
a
lot
of
involvement
from
the
security
teams,
and
that's,
I
think,
a
big
area
for
us
to
address
is
how
can
we
sort
of
help
elevate,
developer
security,
knowledge
in
the
product
and
really
reduce
a
lot
of
the
the
friction
and
the
time
spent?