►
From YouTube: Threat Insights Weekly Group Discussion
Description
Weekly meeting for the Secure:Threat Insights group
A
Welcome
to
the
threat,
insights,
weekly
group
discussion,
we've
got
a
few
items
on
the
agenda.
The
first
thing
I'm
going
to
call
out
is
that
we
moved
our
accomplishments
list
to
the
threat
management
staff
meeting
that
occurred
just
before
this.
So
if
you
weren't
there,
matt
you're
always
welcome.
I
think
you're
on
the
internet,
for
that,
if
not.
B
A
A
Jonathan
is
not
here
and
he
was
just
on
the
last
call.
So
I
was
expecting
him
to
be
here.
So
he's
got
the
first
demo
item
listed
here.
We
don't
have
anything
for
previous
discussions.
There's
a
window
here,
if
you
guys
want
to
bring
up
a
previous
discussion
that
you
hadn't
thought
about
ahead
of
time.
A
Okay,
so
I
hope
everyone
had
a
chance
to
look
at
jonathan's
demo,
video
I
have
not.
I
will
check
it
out
after
this
and
we'll
get
right
into
planning
breakdown
and
again
we
don't
have
anyone
from
the
front
end
team
here.
So
we
can
try
and
talk
about
some
of
this
or
I
don't
know.
Maybe
we
should
have
considered
the
time
of
day
for
this
one
there's
been
some
discussion
around
the
dismissal
types
and
reasons
against
the
bulk
dismissal
and
the
order
in
which
we
approach
those.
A
C
A
Sorry,
most
of
it
looks
like
it
took
place
in
the
bulk
dismissal
issue,
so
I
can
share-
or
I
mean
is
this
something
that
we
should
get
into
right
now,
given
the
audience
that
we
have.
I
guess
is
my
first
question
matt.
What
do
you
think?
I
know
we?
This
is
one
of
our
things
that
we
want
to
have
ready
for
13
7,
along
with
the
jira
issue,
creation.
B
Yeah,
I
think
between
so
the
updates
to
the
dismissal
types
or
the
reasons
on
the
vulnerability
list
page
versus
the
individual
dismissal
dismissal
options
for
a
vulnerability
object,
it's
kind
of
half
of
half
a
dozen
of
one
six
of
another.
I
think
we'll
have
to
do
them
both.
So
I
would
say
the
discussion
has
mostly
been
around.
Let's
do
whichever
one
makes
the
most
sense
from.
I
guess:
a
technical
feasibility
or
ease
of
implementation,
because
they'll
be
in
alignment
once
both
pieces
are
done
so
either
one
is
a
good
enhancement.
A
My
last
suggestion,
which
was
three
days
ago
that
we
haven't
heard
any
feedback
on,
was:
let's
take
care
of
the
dismissal
types
and
reasons
first
and
include
that
database
change
as
part
of
that
work,
because
it's
more,
I
don't
know
it
seems
more
focused
and
consolidated
and
then
once
that's
complete,
do
the
bulk
status
change,
which
would
include
the
the
expansion.
What
no
it
would.
The
dismissal
reason
issue
would
cover
making
those
dismissal
reasons
consistent
across
all
the
various
places
right.
A
So
we've
got
the
pipeline
modal,
the
standalone
vulnerability
page
and
then
the
current
bulk
dismissal
feature
that's
available
in
the
dashboard,
so
those
reasons
would
become
consistent
and
then
we'd
also
have
a
standalone
database
field
to
capture
those
dismissal
reasons
and
stop
populating
those
in
the
comment
field
and
then,
once
that's
done,
we'd
shift
our
gears
and
look
at
the
bulk
status
change,
which
would
harness
that
work
and
kind
of
change.
The
the
interaction
with
that
dismissal
reason
on
the
dashboard,
so
that's
where
we
stand
with
that.
A
I
don't
know
if
we
have
the
right
audience
to
agree
with
this
decision,
but
I'll
follow
up,
asynchronously
savage
and
who
is
the
back,
and
I
don't
know
if
there's
the
need
for
a
back-end
person
to
help
make
this
decision
right
now
and
alan.
You
were
part
of
this
conversation.
I
see
your
name
on
it.
You're
part
of
every
conversation,
though
so
it's
hard
not
to
so.
A
A
A
B
A
So
the
next
priority
that
matt
would
like
us
to
have
refined
or
broken
down
and
refined
is
the
template,
ties
vulnerability,
details
page
so
taking
the
generic
schema
concept
that
james
put
forward
and
we've
focused
on
you
know
the
display
of
the
details
and
absorb,
and
I
don't
what
I'm
unclear
of,
and
I
think
me
how
and
alan
can
help
make
this
more
clear.
For
me,
right
now
is
what
back
and
work
have
you
had?
A
A
It's
been,
we've
been
talking
about
it
for
way
too
long,
and
we
need
to
make
some
action
on
it.
I
mentioned
that
yesterday
it's
been
a
few
months
and
that's
going
to
be
kind
of
frustrating
for
james
who
put
his
ideas
forward
and
we've
already
missed
the
opportunity
for
it
to
get
used
by
things
like
the
fuzz
testing
scan
results.
So
what
I'm
a
little
confused
about
is
what
back-end
work
is
required
to
adjust.
How
we're
storing
this
data,
based
on
this
generic
report,
schema.
D
So
if
you
look
at
the
design,
there's
like
evidence
which
has
registers
section-
which
I
am
not
sure,
where
did
that
come
up
from,
I
do
not
recall,
we
have
any
scanner
that
returns
information
about
registers
involved
in
the
in
the
vulnerability.
D
So
the
question
is
like:
should
we
have
all
the
information
or
where?
Where
does
the
mockup
come
from?
Where
does
the
data
come
from?
Because
there
are
some
sections,
I'm
not
sure
we
actually
have
so
like
just
this
registered
part,
so
some
information
might
not
show
up
and
we
need
to
have
a
clear
picture
of
what
scanners
are
we
currently
expecting
to
have
and
what
scanners
we
will
have
in
the
future?
So
we
can
anticipate
maybe
changes
in
sections
or
whatever.
B
B
B
B
Yeah,
I
I
think
maybe
I'll
get
andy
or
I
can
even
add
some
annotations
here.
So,
like
the
register
itself,
I
don't
think
there's
actually
something
called
a
register.
It's
actually
a
or
maybe
there
was
a
register.
I
think
this
is
just
showing
a
table.
D
Yeah,
this
shows
the
table
this.
This
section
shows
a
table
of
registers,
values
and
notes
which
yeah
I
was
wondering
because,
like
I'm
looking
at
the
modified
data-
and
this
shows
like
div
so
this
is,
this
will
require
yeah,
front-end
work
and
I
think
back
and
work
as
well
in
in
this
case,
since
we
need
to
present
the
data
in
this
really
nice
approach
nice
way
and
we
need
to
get
the
format
in
which
we
return.
C
Yeah,
I
I
haven't
been
checking
the
single
vulnerability
page
if
it's
already
like
rendering
on
the
front-end
side
or
on
the
back-end
side,
because
I
remember
right
now,
but
still
that's
still
the
backhand
okay.
So
we
need
to
unders
like
there's.
Definitely
a
discussion
needed
between
front
and
back
and
to
discuss
what
we'd
like
and
how
we'd
like
to
achieve
that,
because
it's
really
relatively
easily
on
for
the
back
end,
because
we
will
prepare
something
in
a
markdown
and
it
will
be
rendered
then
by
buy
some
like
markdown
parser
or
something
like
that.
C
But
at
the
same
time,
if
you
would
like
to
make
it
rendering
on
the
front-end
side,
that
means
we
need
to
return
that
information
in
the
format
that
front
that
will
be
satisfied
with
and
and
it'll
be
easy
to
render
on
the
front-end
side.
So
these
are
two
things
that
we,
I
don't
believe
we've
been
discussing
before,
because,
like
all
the
technique,
like
all
the
let's
say,
details
about
the
future
are
easy
to
understand
and
the
rationale
it's
it's
all
great.
C
But
we
still
don't
know
how
we
would
like
to
and
who,
who
needs
to
lead.
The
whole
discussion
in
terms
of
how
we,
how
to
present
the
data
yeah.
A
Sounds
like
that,
it
would
be
best
student
for
a
synchronous
discussion
based
on
the
complexity
of
it
yeah
and
this
half
hour
call.
You
know
it's
not,
maybe
not
the
right
time,
given
that
we
have
other
agenda
items
and
we
don't
always
have
the
right
audience.
I
think
it's
something
we
need
a
targeted
audience,
maybe
an
hour
period
of
time,
really
good
notes
and
recordings
for
people
who
can't
be
there.
I
could
take
the
action
to
get
that
scheduled
this
week
and
identify
who
the
right
front-end
person.
A
That
being
said,
I'll,
just
I'll
figure,
I'll
work
with
you,
I'm
gonna
figure
out
who
the
right
individuals
are
because
I
know
people
are
busy
doing
things.
So
that's
great
information
and
just
a
reminder
that
we
do
have
sort
of
this
proof
of
concept
to
refer
to
and
the
author
of
it
here
to
talk
to
him.
So
you
know
james
did
have
some
approaches
on
how
to
solve
this.
I'm
not
saying
we
need
to
use
all
of
his
code
and
all
of
his
solutions,
but
one
one
source
there
for
us.
A
Okay,
let
me
put
a
note
here
and
I
did
try
to
get
some
assistance
from
neil
mccarson
to
secure
front
end
team
they're,
pushing
forward
with
some
of
the
other
scanners,
because
this
hasn't
been
put
in
place.
So
it's
kind
of
a
chicken
and
an
egg
scenario
here,
but
it
sounds
like
it's
going
to
be
on
our
team
to
get
this
implemented,
which
is
just
fun
so
and
this
I
don't
know
if
this
is
even
true
anymore,
based
on
what
you
guys
were
saying.
A
C
C
A
A
So
the
next
issue
that
we
have-
and
we
definitely
still
have
time
to
talk
about
it-
is
c
on
this
list,
which
is
indicating
if
vulnerabilities,
are
new
or
not
jonathan,
created
this
a
few
months
ago
and
I
believe,
there's
a
lot
of
relationships
with
other
work.
That's
been
going
on
around
uuids
and
location
fingerprints
and
it's
become
completely
unclear
to
me.
D
C
D
I
did
take
a
look
at
it,
but
I
am
not
sure
because
there
is
a
problem
in
which
we
have.
We
will
create
vulnerabilities
based
on
findings.
So
if
we
determine
that
the
finding
is
identical
in
a
subsequent
scan,
then
we
will
not
create
a
vulnerability
for
it.
We
won't
create
a
vulnerability
for
that
one.
D
D
D
Because
the
the
basic
assumption
is
that
the
scans
work
like
in
a
deterministic
way,
so
they
scan
the
they
scan
the
wall
application
in
the
same
same
way,
every
time
which
is
not
true.
So
we
might
have
a
difficulty
recognizing
that
hey.
This
is
a
new
vulnerability
or
we
did
fix
it,
and
we
should
mark
it
as
fixed
and
show
how
many
times
we
do
fix
that.
A
B
Probably-
and
I
had
actually
moved
it
to
the
backlog
because
I'm
not
100
sure
if
it's
still
going
to,
I
guess-
be
valid
or
be
relevant
with
some
of
the
other
work
ongoing.
I
guess
I
wasn't.
I
get
the
intent,
but
I'm
not
sure
if
there
was
anything
specifically
actionable
about
it
kind
of
reading
through
the
description
in
the
history.
A
And
I
admit,
I'm
not
sure
who
put
these
last
three
items
on
the
agenda
if
it
was
myself
or
thiago,
so
we
can
just
defer
this
one.
A
There's
a
bigger
topic
here
around
location
fingerprints
that
you
know
is
clearly
set
in
the
back
end.
You
know
I
don't
want
to
be
taking
over
areas
that
you
know
are
not
part
of
my
responsibility,
but
we
should
be
following
up
on
them.
I'm
not
sure
matt.
If
you
have
any
issues
already
refined
or
in
the
you
know
that
are
dedicated
to
that.
B
B
A
Given
that
this
was
created
three
months
ago,
it
was
right
around
that
time
when
the
the
ui
changed
and
brought
visibility
into
that
piece
of
the
mr
widget
and
we
removed
the
word
new
to
address.
It
was
the
big
solution
in
place,
so
I'm
sure
it's
in
line
with
that,
so
matt
I'll.
Let
you
and
thiago
decide
what
the
correct
issue
is
to
get
put
into
our
workflow
to
represent
the
breakdown
and
refinement
so
that
if
there
are
changes
that
need
to
be
made
which,
on
whatever
scale,
we're
prioritizing
those.
B
Yeah,
we
can
definitely
leave
that
one
off
and
the
other
one.
Honestly,
I
don't
really
even
remember
it
looks
like
it
was
something
that
mike
and
seth
had
opened
a
long
time
ago,
and
the
next
one
to
three
probably
should
come
off
there
I'll
blame
thiago.
That's
that's
who
said
he
put
that
on
there.
I
think
it's.