►
Description
Speaker: Mark Peters
Many organizations attempt adopting DevOps and Agile practices only to crash against a compliance wall such as Risk Management Framework (RMF), PCI-DSS, or even GDPR. Even Gene
After being a Product Owner on an Agile team, I transferred to a security lead, operating the RMF with an org newly committed to Agile. My team worked through a mindset change without the breakdown, incorporating small compliance goals, integrating with developers, shifting security left, and building cooperative risk ownership. This session shares my experiences incorporating an Agile workplace with U.S. Government compliance.Kim’s “The Unicorn Project'', shows a security officer experiencing a complete breakdown before becoming a DevOps enthusiast. But really, it’s not that hard.
Get in touch with Sales: http://bit.ly/2IygR7z
B
Good
morning,
I'm
dr
mark
peters,
with
the
technic
corporation,
I'm
here
with
the
briefing
agile
compliance
risk
operations
at
get
lab,
commit
2020
excited
to
be
part
of
the
conference,
excited
to
be
part
of
the
you
belong
here
so
I'll
offer
you,
the
standard
government
caveat
going
in
these
views
represent
me
and
not
my
corporation
or
the
government
as
a
speaker.
They
do
represent
the
team
and
the
team
that
I
was
working
with
over
the
past
several
months
and
some
of
the
things
we
found
is
really
working
together.
B
So
with
that
I'll
jump
right
into
it
and
talk
some
about
devops
and
government
contract.
So
first
a
little
bit
about
me,
I
used
to
work
in
the
air
force
I
retired
after
22
years
in
the
air
force
as
an
intelligence
operator,
which
gave
me
oodles
of
experience
with
compliance
practices.
I've
seen
compliance
at
all
levels,
I've
seen
compliance
to
the
personal
level,
I've
seen
compliance
at
the
security
level,
I've
seen
compliance
with
flight
operations,
I've
seen
compliance
with
cyber
operations,
so.
B
B
I
was
one
I
worked
as
a
project
engineer
and
now
I
work
as
a
product
owner
now
I
work
as
the
lead
security
engineer,
it's
more
of
a
grasp
on
how
that
security
has
to
roll
in
overall
and
how
we
have
to
do
our
development
work
in
compliance
with
everything
else.
I'm
also
a
devops
institute
ambassador,
where
I
get
a
chance
to
talk
to
a
lot
of
great
people
at
the
devops
institute.
I
learn
a
lot
of
things,
which
is
where
I
get
a
lot
of
these
practices
from
just
about
me.
B
I'm
an
avid
reader.
I
read
a
little
bit
of
everything,
sci-fi
fantasy
and
then
all
the
work
related
stuff
along
the
way.
I
did
write
a
book
about
cashing
in
on
cyber
looking
at
our
cyber
power
looking
at
10
years
of
economic
attacks,
and
I
do
have
a
doctorate
strategic
security,
I'm
not
an
arithmetic,
but
it
was
good
at
the
time
so
with
that
I'll
jump
right
into
our
our
story
about
why
we
belong
how
we
fit
our
security
into
belonging
in
our
overall
team.
B
The
problem
that
we
were
facing
as
we
sat
down-
and
we
looked
at
this
program
we
were
coming
into-
is
how
does
my
security
team,
my
small
security
team,
four
people
on
the
security
team
referenced
about
100
developers
or
so,
and
probably
about
40
or
50
out
in
the
opps
community?
How
do
we
ensure
compliance?
How
do
we
enforce
those
standards?
How
do
we
remain
agile
along
the
way,
so
we
faced
this
problem
daily
because
we
wanted
to
be
agile.
We
wanted
to
be
more
flexible.
B
B
So
I'm
looking
at
this
problem
and
looking
at
this
problem
looking
at
this
problem,
we
started
to
categorize
what
it
was
that
we
needed
to
do
to
be
both
agile
and
compliant,
and
we
saw
that
we
had
the
nist
853,
the
national
institute
for
standards
and
technology
that
the
government
uses
so
with
that
they
had
about
19
categories
of
control,
families
and
with
those
they
have
about
a
thousand
different
indicators.
So,
instead
of
looking
at
those
indicators
as
risk
management,
the
government
looks
at
those
that
you
have
to
answer
everyone
and
in.
B
You'll
manage
the
risk,
which
is
an
ideal
solution
for
an
administratively
heavy
organization,
but
not
so
ideal
for
agile.
So
we
had
to
match
that
into
agile.
We
had
to
look
at
our
four
principles
of
taking
people
over
processes
of
delivering
functional
software
and
we
looked
at
our
scrum
guide
to
move
us
forward,
and
then
we
tried
to
categorize
the
problem
because
looking
at
that
is
a
problem
that
people
have
been
trying
to
solve
for
a
long
time.
B
So
we
tried
to
standardize
to
whatever
parameters
and
we
came
up
that
we
needed
to
standardize
through
those
standards
through
those
nest
standards
we
had
to
be
able
to
manage
risk
and
then,
of
course,
we
had
to
look
at
whether
we
could
just
buy
a
solution
whether
it's
somebody
had
already
solved
this
problem
for
us,
and
we
could
move
forward
from
that
point
to
the
next
step
so
to
be
compliant
or
agile.
As
we
move
forward,
compliant
and
agile
are
normally
seen
as
opposite
ends
of
the
same
row.
They
pull
on
each
other.
B
You
can
be
one,
but
not
the
other.
If
you
go
to
agile
the
thought,
is
you
go
so
fast
that
you're
not
compliant?
If
you
try
to
be
compliant,
the
thought
is
there's
so
much
standards
there
that
you
can't
be
agile.
Compliance
is
normally
seen
as
a
legally
prescribed
method,
something
someone
comes
in
from
the
outside.
Who
has
no
idea
what
you're
doing
and
assigns
this
to
you
and
tells
you.
B
This
is
what
you
have
to
do,
these
things
like
fips,
fisma,
socks
and
various
other
degrees
of
various
standards,
whether
they're
organizationally
prescribed
in
terms
of
what
your
organization
or
your
group
of
organization
tells
you
to
do,
or
their
government
prescriber
the
government
comes
in.
Tells
you
hey?
You
have
to
do
this
because
it's
a
statute.
We
need
to
be
careful
because
we
want
to
protect
people's
privacy.
We
want
to
protect
their
situation,
so
we
see
a
lack
of
freedom
of
blockers
in
most
compliance
standards.
B
This
can
lead
to
high-level
success
but
sometimes
ceases
getting
the
job
done
at
all
costs,
and
sometimes
people
feel
that
being
agile
drops
that
compliance
behind.
So
we
have
to
deal
with
risk
in
dealing
with
the
government.
We
work
at
risk.
We
look
at
risk.
We
try
to
look
at
where
that
risk
is.
We
have
to
be
able
to
talk
to
our
customers
about
risk,
because,
ultimately,
what
compliance
wants
is
to
reduce
the
risk
of
your
organization.
They
want
to
look
at
something:
that's
a
threat
they
want
to
take
that
down.
B
B
So,
in
order
to
reduce
the
risk,
you
have
to
know
the
elements
you
have
to
look
at
the
various
elements
you
have
to
look
at
where
risk
becomes
threat,
times,
vulnerability,
times
exposure
and
that's
the
little
math
that
we
have,
but
I
don't
like
using
the
numbers,
so
we
don't
use
the
numbers.
We
talk
about
those
things.
So
we
talk
about
those
things
in
combination.
We
talk
about
how
a
new
threat
or
a
new
vulnerability
creates.
That
threat
creates
that
risk,
and
then
we
talk
about
whether
or
not
it's
exposed.
B
Obviously,
if
your
firewall
is
behind
multiple
other
solutions,
behind
a
vpn
behind
connections
behind
two-factor
authentication
behind
other
security
rules,
you
don't
have
that
exposure
that
you
would
for
a
web
api
for
being
out
there
in
a
space
that
everyone
could
see
it.
So
how
do
you
manage
those
things?
How
do
you
make
that
its
awareness
and
not
try
to
reduce
everything
to
the
lowest
element
possible,
but
to
work
through
the
compliance
through
the
various
elements
and
get
to
the
place
where
you
need
to
be
in
order
to
move
forward?
So.
B
Compliance
in
our
attempt
to
deliver
agile
compliance,
what
we
wanted
to
do
was
we
wanted
to
maintain
that
compliance.
We
want
to
make
sure
that
we
answer
those
new
standards
without
sacrificing
the
flexibility
and
find
a
way
that
we
could
do
that,
and
we
also
wanted
to
have
a
risk
operation
right.
We
wanted
to
effectively
manage
multiple
risks
across
the
way
because
everybody
has
their
own
risks
and
everybody
has
a
different
set
of
security.
We
have
to
understand
everyone's
risk
because
everyone's
problem
becomes
a
necessary
problem.
B
They
come
to
you
and
say:
I've
got
this
new
vulnerability,
it
just
popped.
Last
week
you
came
out
on
the
cve
list
and
you
know
you
need
to
take
care
of
it
and
we
need
to
be
able
to
say
well
it's
great.
We
understand
your
vulnerability
but
being
agile,
we're
going
to
deal
with
that
in
time
and
right
now
we
think
we've
got
you
a
limited
exposure.
B
B
That
can
already
offer
us
a
method
to
do
things
and
we
see
scaled
agile
for
enterprise,
so
the
scaled,
agile
frameworks-
and
we
see
that
somebody
already
has
a
solution
or
they
at
least
they
have
the
steps
of
the
solution,
but
you
still
have
to
implement
those
solutions
and
you
have
to
find
a
way
to
work
through.
Actually,
you
look
at
discipline,
agile,
which
is
the
program
management,
professional's
view
of
agile
and
how
they
make
agile
work
in
a
framework
for
them
how
they
make
agile
work
against
those
standard.
B
Five
characteristics
of
the
program
management,
how
they
work
it
through
the
steps
and
the
families.
And
then,
of
course,
you
have
companies
that
want
to
come
in
and
just
sell.
You
bring
you
an
expert
and
show
you,
the
experts
say:
they'll
come
in
they'll
fix
all
your
problems,
they'll
give
you
all
the
solutions
and
then
they'll
leave
you
with
a
problem
to
still
fix
on
your
own.
At
the
end
of
the
day,
we
also
see
overlays
a
number
of
companies
overall
and
the
overlays
are
great.
B
You
answer
the
questions
to
those
processes
again
at
various
levels,
because
you
can
always
get
a
company
to
come
in
and
use
that
certification
for
you
and
associate
your
maturity
overall
and
then,
who
wants
to
sell
you
just
experts
who
wants
to
give
you
an
expert
for
your
organization
and
in
full
disclosure?
As
I
mentioned
earlier,
I
am
a
contractor
for
a
government
organization
for
an
organization
that
contracts
to
the
government
and
supplied
as
an
expert
in
one
of
those
positions.
B
B
Is
very
waterfall
heavy
and
has
been
waterfall
heavy
for
a
long
time
and
they
do
have
reasons
to
be
waterfall
heavy,
because
for
a
lot
of
times,
this
stuff
is
important.
It
matters
to
people's
lives
and
it
matters
to
the
defense
of
the
nation
and
they
wanted
to
be
careful
about
everything
they
put
out
there.
B
They
didn't
want
to
introduce
vulnerabilities
and
they
didn't
want
to
introduce
exposure,
so
they
came
back,
but
we
looked
at
our
philosophy
for
our
security
team
and
for
our
local
team,
with
the
constraints
of
what
we
were
trying
to
do
for
the
government,
and
we
look
at
it
as
a
security
user
story
who
uses
security
who
needs
to
use
security,
and
in
talking
about
that,
we
decide
that
our
devs
are
our
users
because
they
need
to
have
secure
products.
If
they
don't
have
a
secure
product.
B
It
won't
create
value
for
the
customer
at
the
end
of
the
day
and
then
all
the
work.
However
neat,
however
exciting,
however
creative
they
get
doesn't
get
that
value
out
of
the
government
and
we
looked
at
our
devs
from
their
perspective.
What
was
their
user
story
and
they
saw
us
as
enablers,
so
we
had
to
be
enablers,
that
means
being
part
of
the
process.
They
can
get
involved
with
them
understanding
their
terms,
understanding
their
language
and
talking
to
it
overall,
and
we
had
to
talk
about
the
product
over
story,
because
compliance
adds
value.
B
I
had
somebody's
finger
poking
in
my
chest,
saying
that
I
turned
it
off
and
I
was
risking
everything
and
I
was
threatening
the
whole
process
and
we
needed
to
get
to
a
better
place.
I
needed
to
find
a
way
to
re-enable
it
and
we
did
and
we
worked
through
it,
but
we
found
a
way
that
was
compliant
and
that
was
compliant
in
a
hurry
to
get
to
that
place,
because
that
compliance
adds
value
and
make
sure
that
we're
doing
the
right
things.
And
with
that
we
need
to
manage
multiple
users
through
a
risk
operation.
B
Everybody
who
comes
in
every
different
dev
has
a
different
risk
and
they
want
to
manage
their
risk
or
they
may
not
want
to
manage
the
risk
they
may
want
to
produce
their
product.
But
we
need
to
make
sure
that
the
product
adds
risk
in
a
careful,
measured
way
to
the
entire
structure
that
we
understand
how
that
fits
into
our
agile
and
with
that
we
suggested
solutions
without
really
having
leverage,
because,
as
we
mentioned
on
the
security
team,
the
devs
are
the
users.
B
So,
while
we're
shooting
for
long-term
success,
we're
looking
for
short-term
compliance
because
we're
trying
to
be
agile
so
we're
trying
to
manage
that
compliance
in
small
bits
in
small
pieces
that
help
us
move
forward
in
part
of
that
understanding,
part
of
being
able
to
move
forward
in
small
bits,
is
being
able
to
understand
the
tools.
When
we
jump
into
the
government,
we
try
to
understand
what
tools
we
have
and
what's
there
and
whether
or
not
they're
the
right
ones,
because
we
want
to
know
if
we
can
use
those
tools.
B
So
we
can
take
those
tools
to
challenge
the
old
models
to
use
those
tools,
help
generate
transparency
along
the
way,
help
us
get
involved
in
the
scrum
process
and
as
security
understand,
what
the
developers
are
doing
without
having
to
get
in
their
faces
all
the
time
and
tell
them.
No,
you
just
can't
do
it.
So
we
looked
at
the
tools
we
have.
B
We
looked
at
testing
utools.
We
looked
at
di2qe
for
kubernetes.
We
looked
at
trello
for
workflows
as
opposed
to
the
di2e.
That's
the
defense
intelligence
that
we
use
for
workflows
through
jira
and
confluence.
We
looked
at
clara
for
containers,
we
looked
at
salt
stack
for
automations.
We
looked
a
lot
of
these
things
and
we
look
at
these
things
all
the
time,
because,
as
security,
we
want
to
know
what
the
newest
tool
is
out
there
and
not
just
from
a
security
perspective.
B
B
It's
going
to
be
involved
and
I
went
back
to
our
devs
and
I
said
it's
great.
We
can
turn
on
all
these
security
features.
I
got
the
hey,
we
didn't
buy
that
package,
so
you
have
to
talk
all
the
way
along
the
way
and
we
try
to
talk
about
the
right
things.
We
try
to
talk
about
security,
but
that
transparency
is
making
everyone
along
the
stream
understand
how
things
work.
B
So
when
we
launched
in
part
of
our
solution
was
that
we
were
a
new
team,
we
were
a
new
contract.
We
tried
to
figure
out
where
we
started
and
what
occurred
before.
We
tried
to
delve
into
the
previous
events
in
the
previous
story,
so
we
can
find
out
exactly
where
we
were
on
our
risk.
Matrix
and
being
part
of
the
government
means
we
needed
access.
B
We
needed
to
be
able
to
get
into
those
things,
and
sometimes
that
takes
time
and
the
government
had
to
verify
everyone
and
get
everyone
into
their
computer
systems
and
get
everyone
to
their
networks
and
their
property
and
try
to
help
us
all.
But
along
that
process
we
saw
that
resistance
to
change
that
initial
reluctance
to
make
the
changes
to
be
more
transparent,
to
open
things
up.
B
When
we
look
at
it,
we
know
that
change
creates
error
if
things
change,
if
things
are
different
than
they
were
before,
there's
some
error
involved,
there's
some
exposure
and
there's
some
vulnerability
and
there's
some
threat,
and
that
creates
the
risk.
But
overall
indecision
creates
disaster.
If
you
don't
make
the
decisions
and
you
just
let
it
go,
it's
going
to
break
eventually.
So
what
we
wanted
to
do
with
our
agile
compliance
mindset
is
we
wanted
to
try
to
create
small
decisions
in
small
increments
along
to
the
right?
You
can
see
one
of
the
pipeline
structures.
B
We
create
transparency
and
metrics
that
are
good,
not
just
for
the
devs
to
develop
their
products,
but
that
we
could
use
a
security
and
we
could
take
them
back
so
that
we
could
actively
see
the
risk
and
we
could
quantify
the
risk
and
we
could
talk
to
the
devs
about
that
small
steps
where
in
the
testing
they
were
having
problems
rather
than
coming
in
at
the
end
and
saying:
well,
it's
not
compliant
just
step,
but
just
stop
right.
It's
not
the
right
thing.
So
we
had
to
communicate.
B
We
had
to
communicate
all
the
time
with
these
different
folks
to
make
sure
that
they
were
getting
the
message
and
they
were
being
compliant
with
what
we
needed
to
do,
but
it
wasn't
just
our
team
that
needed
to
make
solutions.
We
needed
to
make
an
organizational
solution.
We
needed
to
come
in
across
the
process
and
we
needed
to
look
at
how
we
could
fix
our
our
contractor
process.
So
we
had
a
complete
devops
solution
for
our
average
agile
compliance
and
our
risk
operation.
B
B
We
had
to
go
and
we
had
to
advocate
security
all
the
time
and
we
had
to
advocate
security
in
a
way
that
built
transparency,
but
also
creating
value.
Again.
I
talk
to
stories
because
part
of
belonging
is
telling
you
write
stories
and
telling
the
stories
in
the
right
place.
I
had
a
senior
mentor
years
and
years
ago
and
one
of
the
things
he
told
me
was
he
said
he
was
going
out
and
this
was
a
flag
level
officer
in
the
military.
So
he
was
making
these
speeches.
He
had
an
individual
come
up
to
him.
B
He
said
hey
every
time
you
go
out,
you
make
a
speech,
you
say
the
same
things,
you
say
the
same
three
things
and
I've
got
it.
I
heard
the
first
time
I'm
really
invested.
I'm
really
excited.
Why
do
you
say
the
same
three
things?
I
want
to
hear
something
different.
I
want
to
hear
something
new
and
he
said
he
turned
to
him
and
he
said
look.
He
said
I
figure
that
10
of
the
people
hear
me
10
of
what
I
say
10
of
the
time.
So
to
get
the
message
across,
I
figure.
B
I've
got
to
say
the
same
thing
or
to
get
the
message
across
to
everyone.
I've
got
to
say
it
at
least
30
times,
and
I've
got
to
keep
on
those
messages.
So,
rather
than
switching
my
messages
and
switching
what
we're
talking
about
what
I
do
is
I
focus
and
that
way
by
saying
it
enough
times.
I
can
show
that
everyone
hears
me.
B
Everyone
gets
the
message
and
we
can
move
forward
and
that's
what
we're
trying
to
do
by
talking
about
security
all
the
time
by
talking
about
how
we
intend
to
be
actually
complaining
by
talking
about
the
risk
by
talking
about
creating
value
about
moving
forward,
and
we
do
that
through
linking
the
items
and
tasks
linking
the
items
in
our
workflow.
Again,
we
see
a
cicd
pipeline.
We
see
how
that
workflow
includes
security.
B
It
includes
a
static
at
the
front
and
the
acas
scans
at
the
end,
so
that
we
get
both
levels
of
security
and
we're
working
on
integrating
more
tools
all
across
the
step.
So
we
get
more
visibility
into
how
these
tools
work
and
we
build
those
through
a
backlog.
When
something
fails
a
test,
it
doesn't
just
stop.
It
goes
back
into
the
backlog.
B
We
find
a
way
to
fix
it.
We
find
a
way
to
move
it
forward
and
we
prioritize
the
way
it
creates
value
for
the
customers
for
the
things
they
want
to
do
so.
Our
organizational
takeaways
first
off
practice
practice
practice
right.
Malcolm
gladwell
wrote
a
paper
called
outliers
back
in
the
90s.
He
talked
about
using
deliberate
practice
to
get
better,
he
suggested
that
you
had
to
do
something
500
times
for
familiarity,
5
000
times
for
confidence
and
possibly
up
to
50
000
times
to
get
mastery
of
that
single
task
that
you're
looking
for.
B
So
if
we
considered
scrum
to
be
a
task
to
think
you
would
do
it
50
000
times,
it's
just
an
unrealistic
expectation,
so
you
really
have
to
work
on
the
deliberate
practice.
How
do
we
get
it
better?
How
do
we
work
it
every
day
and
how
do
we
focus
on
those
things?
Those
small
things
that
are
important
to
us
in
order
to
move
forward
and
make
our
organization
get
better
and
part
of
that
practice?
Is
our
never
stop.
Learning
we
work
through
our
backlog,
we
work
for
our
prioritization,
we
learn
about
what
is
going
on.
B
We
learn
about
the
product
we
learn
about
the
customer.
We
learn
about
how
we
can
manage
our
risk
and
what
each
risk
is
individually,
so
that
we
understand
that
risk
and
talking.
We
can
talk
about
the
threat.
We
can
talk
about
the
vulnerability,
we
can
talk
about
the
exposure
and
we
can
innovate
through
those
processes
to
create
a
way
that
creates
the
right
key
performance
indicators
for
us
that
we
can
measure
each
risk
separately
and
individually
to
produce
a
collective
answer
that
generates
value
as
a
multiple
rather
than
as
an
individual.
B
And
then,
as
I
mentioned,
we
got
to
advocate,
you
got
to
beat
the
street,
you
got
to
say
it
all
the
time
and
saying
it.
We
have
to
be
doing
it
ourselves
that
we
convince
others.
We
have
to
be
talking
about
where
our
risk
exists
and
the
risk
that
we're
managing
for
us
as
we
attempt
to
get
compliance,
because
there's
always
a
risk
in
that
as
well.
B
If
we
don't
meet
our
compliance
standard,
then
we
can
get
shut
down
by
other
pieces
of
the
government,
and
that
loses
the
program
for
everybody,
not
just
for
the
compliance
folks,
but
it
mainly
starts
with
the
compliance
folks
of
having
the
right
process
in
place
and
we
try
to
build
relationships
over
processes.
We
want
to
be
involved
and
that's
kind
of
the
edge
of
101
theory.
B
You
always
want
to
make
things
better.
I
would
shift
more
security
processes
to
the
left.
I'd
have
more
scans
in
the
ci
cd
pipeline.
I'd
be
able
to
integrate
the
software.
I'd,
be
able
to
talk
about
the
risk
and
I'd
introduce
people
as
they
started
into
this
risk
operations
and
agile
compliance
as
our
devs
started.
B
I
move
more
security
checks
to
the
right,
and
I
say
to
the
right,
but
not
all
the
way,
to
the
right
just
a
little
bit
to
the
right
as
the
devs
complete
their
stories
as
they
move
forward
and
they
do
their
features
and
they
do
development.
I've
had
them
get
to
the
mindset
to
get
to
the
cultural
mindset
where
they
think
about
compliance
as
one
of
their
acceptance
criteria.
They
have
to
move
it
through
the
government,
so
it
has
to
be
compliant,
so
they
need
to
think
about
it
early.
B
But
that
means
they
need
to
be
just
as
familiar
with
what
the
compliance
standards
are
looking
for.
Is
I
and
that
talks
me
talking
to
them
and
working
with
them
and
working
them
through
how
they
bring
up
these
definitions.
You've
done,
president
reagan
used
to
say
in
the
old
cold
war
days
used
to
say,
trust
but
verified,
and
it's
a
lot
of
that.
We
trust
everyone,
but
we
need
to
verify
that
the
compliance
is
there
and
it's
not
us
doing
the
verification.
B
It's
the
government
doing
the
verification,
because
the
government
needs
to
know
we're
compliant
and
they've
established
a
standard
that
says
here's
what
you'll
be
compliant
with
for
everyone
and
since
that's
a
standard
for
value
for
the
product,
that's
what
we'll
use
and
then.
Finally,
we
talk
about
integrating
processes,
I
like
to
say
no
meetings
every
board,
one
of
my
pet
peeves
is
people
come
in
and
say:
hey.
This
meeting
is
boring.
I
don't
get
it,
I
don't
like
it,
I'm
not
going
in.
B
It's
just
boring,
but
no
meeting
is
boring
because
no
one's
issue
is
unnecessary,
especially
from
risk
and
compliance.
You
have
to
know
what
the
threats
are
and
you
have
to
know
what
the
vulnerability
and
the
exposure
are.
You
don't
get
those
without
going
to
the
meetings.
Everybody
has
something
that
they
need
to
bring
and
whether
that
directly
applies
on
your
situation
or
not
it's
up
to
you
to
kind
of
make
that
connection
to
come
in
with
an
agenda
to
come
in
with
a
set
of
things.
B
You
want
to
talk
about
and
be
able
to
create
value
out
of
the
meaning
if
it
doesn't
create
value,
there's
no
sense
in
having
that
meaning.
But
a
lot
of
meetings
do
and
it's
up
to
us
to
really
make
those
changes
in
that
process
and
that's
what
we
did:
security
integrating
with
the
devs.
We
made
the
changes
we
made
the
integration
and
then
finally,
we
want
to
manage
risk
on
threat
and
exposure,
not
just
vulnerability.
We
don't
just
want
to
talk
about
the
factors
of
vulnerability.
We
want
to
reduce
our
threat
through
reducing
our
exposure.