►
From YouTube: The Dichotomy of Security (The Podlets, Ep 10)
Description
Security is inherently dichotomous because it involves hardening an application to protect it from external threats, while at the same time ensuring agility and the ability to iterate as fast as possible. This in-built tension is the major focal point of today’s show, where we talk about all things security. From our discussion, we discover that there are several reasons for this tension. The overarching problem with security is that the starting point is often rules and parameters, rather than understanding what the system is used for. This results in security being heavily constraining. For this to change, a culture shift is necessary, where security people and developers come around the same table and define what optimizing to each of them means. This, however, is much easier said than done as security is usually only brought in at the later stages of development. We also discuss why the problem of security needs to be reframed, the importance of defining what normal functionality is and issues around response and detection, along with many other security insights. The intersection of cloud native and security is an interesting one, so tune in today!
For the show notes and transcript: https://thepodlets.io/episodes/010-dichotomy-of-security
Feedback and episode suggestions:
https://twitter.com/thepodlets
https://github.com/vmware-tanzu/thepodlets/issues
info@thepodlets.io
Hosts
https://twitter.com/carlisia
https://twitter.com/bryanl
https://twitter.com/mauilion
https://twitter.com/apinick
A
Welcome
to
the
popplets
podcast
hello
and
welcome
back
to
the
cubelets
podcast.
My
name
is
Nicolas
Lane
and
this
time
we're
going
to
be
talking
about
the
dichotomy
of
security
and
to
talk
about
such
an
interesting
topic.
Joining
me
are
Duffy
Cooley,
hey
everybody,
Bryan
Liles,
hello
and
curlies
campus
glad.
A
Everybody
great
yeah,
so
this
I
think
is
a
interesting
topic.
Duffy.
You
introduced
us
to
this
topic
and
basically
from
what
I
understand.
What
you
wanted
to
talk
about
is
the
we're
calling
that
I
get
caught
of
me
of
security,
because
it's
the
relationship
between
security,
like
hardening
your
application
to
protect
it
from
attack
and
influence
from
outside
actors,
the
agility
to
be
able
to
create
something.
That's
useful,
I'd
be
able
to
to
it
iterate
as
fast
as
possible.
C
C
You
know
some
constraint
around
quota,
or
or
all
of
these
things
and
some
of
those
constraints
make
total
sense,
and
some
of
them
I
think
actually
do
impact
your
ability
to
design
the
systems
or
to
consume
that
platform
directly
right,
like
you're,
not
able
to
actually
make
use
of
the
platform
as
it
was
designed
to
be
made
use
of
when
those
constraints
are
too
tight.
Yeah.
A
I
totally
agree,
there's
kind
of
a
joke
that
we
have
in
certain
tech
fields,
which
is
the
primary
responsibility
of
security,
is
to
halt
productivity.
This
isn't
actually
true
right.
It.
There
are
trade
offs
right
and
if
security
is
too
tight,
you
can't
move
forward
right.
Some
things,
I
come
to
mind.
Examples
of
this
I
come
to
mind
are
like
if
you're
too
tight
on
your
firewall
firewall
rules,
where
you
can't
actually
use
anything
of
value.
D
It's
a
great
go
ahead.
Actually,
this
is
a
interesting
topic
just
in
general,
but
I
think
that
before
we
fall
prey
to
what
everyone
does
when
they
talk
about
security,
let's
take
a
step
back
and
understand
why
things
are
the
way
they
are
because
all
we
are
talking
about
are
the
symptoms
of
what's
going
on
and.
D
Example
of
why
I
say
this,
things
are
the
way
they
are
because
you
haven't
made
them
any
better
and
in
over
land.
Whenever
we
consume
external
resources,
what
we
were
supposed
to
do
and
what
we
should
be
doing,
but
what
we
don't
do
is
we
should
create
our
internal
interfaces,
only
program
to
those
interfaces
and
then
let
that
interface
for
that
adaptor
talk
to
the
external
service
and
insecurity
world.
We
should
be
doing
the
same
thing
and
we
don't
do
this.
So
my
canonical
example,
for
this
is
I,
am
on
AWS.
D
It's
hard
to
create
a
secure.
I
am
configuration,
and
it's
even
harder
to
keep
it
over
time,
and
it's
even
harder
to
do
it.
Whenever
you
have
150
100
5,000
people
dealing
with
this.
So
what
companies
do
is
they
actually
create
interfaces
where
they
can
describe
the
part
of
I?
Am
they
want
to
get
loose,
and
then
they
translate
that
over?
So
the
reason
I
bring?
C
C
So
I
think
for
my,
for
my
part,
I
think
it's
important
to
understand.
If
you
can
like
where
you
know
what
the
consumer
of
a
particular
framework
or
tool
might
need
right
and
then
to
take
it
from
there
and
figure
out
what
rash
constraints
are,
rather
than
the
opposite,
which
is
frequently
what
I
mean
where
people
you
know,
go
and
evaluate
a
set
of
rules
as
defined
by
some
particular.
You
know,
as
some
third-party
company,
like
that,
you
look
at
CIS
specs
and
you
look
at
like
a
lot
of
these
other.
C
A
lot
of
this
other
tooling
I
feel
like
a
lot
of
a
lot
of
people.
Look
at
those
eyes
like
those
these
are
the
hard
rules
we
must.
You
must
comply
to
all
of
these
things
and
legally,
in
some
cases,
that's
the
case,
but
but
frequently
I,
think
they're,
just
they're
just
kind
of
like
casting
about
for
for
some
simple
of
a
way
to
start
defining
constraint
and
they
go
too
far
because
they're
not
they're
no
longer
taking
into
account
with
what
the
consumers
of
that
particular
platform
might
need.
C
Right
and
kubernetes
is
a
great
example
of
this.
If
you
look
at
the
CIS
spec
for
kubernetes
or
if
you
look
at
a
lot
of
the
of
the
talks
that
I've
seen
kind
of
around
how
secur
kubernetes
we
define
like
best
practices
for
security
and
a
lot
of
them
are
incredibly
restrictive,
right
can
I.
Think
of
the
problem
there
is
that,
like
that
restriction
comes
at
the
cost
of
maturity,
you're
no
longer
able
to
use
kubernetes
as
a
platform
for
developing
micro
services,
because
you've
provided
so
much
constraint
that,
like
it,
it
breaks
the
model.
D
D
These
are
the
words
the
auditors
will
use
it
you
and
there
is
good
in
those
because
people
don't
like
the
assistant.
Missy
is
benchmarks,
because
sometimes
we
don't
understand
why
they're
there,
but
from
someone
who
is
starting
from
nothing.
Those
are
actually
great.
There's
at
least
that's
a
great
set
of
suggestions,
but
the
problem
is,
is
you
have
to
understand
that
they
are
only
suggestions
and
they.
D
A
better
place
than
you,
then
you
might
be,
but
the
other
side
of
this
is
that
we
should
never
start
with
NIST
or
CIS
or
FISMA.
But
we
really
should
do.
Is
our
RC
solo
or
Archer
Security
office
or
or
the
person
in
charge
of
security,
or
even
just
there
are
people
who
are
in
charge
of
making
sure
our
stack.
They
should
be
defining.
D
They
should
be
taking
what
they
know,
whether
it's
the
standards
and
they
should
be
building
up
the
security
posture
and
this
and
this
security
document
and
these
rules
that
are
built
to
protect
whatever
we're
trying
to
do.
And
then
the
developers
and
whoever
else
can
operate
within
that,
rather
than
everything
literally.
C
What
what
normal
access
between
applications
or
normal
access
of
resources
looks
like
and
I
think
that
your
point
earlier
like
BP
and
will
provide
some
extra
abstraction
in
front
of
a
secure
resource
such
that
you
can
actually
just
share
that
same
abstraction
across
all
the
things
that
might
try
to
consume.
That
extraordinary
is
a
great
example
of
the
thing
defining.
What
that
normal
access
looks
like
is
critical
to
us
to
to
our
ability
to
be
to
constrain
it
right
and
I.
Think
that
frequent
people
don't
start
there.
C
They
start
with
the
other,
the
other
side,
they're,
saying
you're,
all
the
constraints
you
need
to
tell
me,
which
ones
are
true
typed.
You
need
to
tell
me
which
ones
to
loosen
up
so
that
you
can
do
your
job.
You
need
to
tell
me
which
application
needs
access
to
which
other
applications
so
that
I
can
open
the
firewall
for
you
right
and
then
I'm
like.
We
need
to
turn
that
on
its
head.
We
need
it.
We
need
to.
C
D
A
good
example
of
that
would
be
large
organizations
does
this,
but
there
is
environments
for
running
your
application
where
there
are
really
no
rules
applied
and
and
what
we
do
with
that
is.
We
turn
them
auditing
in
those
environments.
So
you
have
two
applications
or
a
single
application
that
talks
to
something
and
you
let
that
application
run
in
another
application.
Runs
you
go.
Take
the
you
go,
take
a
look
at
the
audit
logs
and
then
you
determine
at
that
point
whether
what
a
good
profile
for
this
application
is.
So
whenever
it's
in
production.
A
D
Set
up
the
security
parameters,
whether
it
be
identity,
access
or
network,
based
on
what
you
saw,
an
auditing
in
your
pre-production
environment,
and
that's
all
you
can
run
because
we
tested
it
fully
in
our
pre-production
environment.
It
should
not
do
any
more
than
that
and
that's
and
that's
actually
I'm
something
I've
seen
tools
that
will
do
it
for
like
AWS
I
I
am
you
know,
I'm
sure
you
could
approve
for
anything
else
that
creates
auditing
log.
So
that's
it.
That's
a
good
way
to
get
started
so.
A
It
sounds
like
what
we're
coming
to
is
that
the
breakdown
of
security,
of
the
way
that
security
is
impacted
agility,
is
when
people
don't
take
a
rational
look
at
their
own
use
case.
Instead
rely
too
much
on
the
guidance
of
other
people,
essentially
like
following,
instead
of
like
using
things
like
the
CIS
benchmarking
or
NIST
or
FISMA.
B
A
One
that
I
I
knew
the
other
two
and
then
I
go
one
if
they
follow
them
less
as
guidelines
and
more
as
like
hard
set
rules.
That's
when
we
get
impacts
where
Jill
tea,
instead
of
like,
if
you're
like
hey.
This
is
what
my
application
needs
like
you're
saying:
let's
go
from
there
like
what
does
normally
look
like
defi
as
you're,
saying,
I'm
kind
of
curious.
Let's
flip
that
on
its
head,
a
little
bit.
Are
there
examples
of
times
when
agility
impact
security.
D
A
D
C
D
When
it
comes
down
to
is,
developers
are
gonna
want
to
develop,
and
then
security
people
are
going
to
want
to
secure
and
generally
and
I'm
looking
at
it
from
a
developer,
who
has
written
security
software
that
a
lot
of
people
have
used?
You
guys
didn't
know
that
really
there
needs
to
be
a
conversation.
It's
the
same
thing
is
like
we
had
this
DevOps
conversation
and
having
this
DevOps
conversation
for
a
year
and
then
in
over
the
last
couple
years.
This
whole
DevOps
conversation
has
been
happening.
D
D
D
So
that's
that's
actually,
where
a
lot
of
this
comes
from,
but
I
will
offer
up
that
the
only
default,
secure
posture
is
no
access
to
anything,
and
you
should
be
working
from
that
direction
to
where
you
want
to
be,
rather
than
working
from
flexibly
closed
down,
and
you
should
close
down
everything
and
then
you
you
work.
You
work
with
allow
list,
rather
than
blacklist
yeah.
C
Let's
back
up
for
a
second
I'm
like
I,
have
actually
worked
on
a
platform
that
supported
many
many
services
under
its
observances
right
now.
Clearly,
if
I
needed
to
define
what
normal
looks
like
for
100
services
or
or
a
thousand
services
or
2,000
services,
that's
gonna
be
difficult
in
the
way
that
I'm
in
the
way
that
people
approach
the
problem
right
like
because,
like
how
do
you
define
normal
for
each
individual
service?
I
need
to
have
some
declaration
of
intent.
C
I
need
the
developer
to
it
to
engage
here
and
tell
me,
like
you
know
what
they're
expecting
with
it
is
it
to
set
some
assumptions
about
the
application
like
what
it's
going
to
connect
to
as
dependencies
are
that
sort
of
stuff,
and
they
also
need
tooling
to
verify
that
I
need
to
be
able
to
kind
of
like
build
up
the
whole
thing
so
that
I
have
some
way
of
automatically.
You
know,
maybe
with
oversight
defining
what
that
security
context
looks
like
for
this
particular
service
on
this
particular
platform.
C
B
With
a
cognitive
architecture
in
infrastructure,
I
wonder
if
it
makes
it
more
is
more
restrictive
because
everything,
let's
say
things
like
burning
of
carbon
eighties,
everything
is
running
or
burning.
These
things
are
more
connected
because,
anyway,
it's
a
Cobra
Dennis
right.
It's
this
one,
huge
thing
that
you're
running
on
in
kubernetes
makes
it
easier
to
have
access
to
different
nodes
and
the
nodes
to
different
parts.
Of
course
you
have
to
define
those
connections,
but
still
it's
supposed
to
make
it
easy.
B
So
I
wonder
if
security,
as
from
a
perspective
of
somebody
needing
to
pull
restrictions
and
Anatomy,
for
example,
is
it
makes
it
it
makes
it
harder
or
if
it
makes
it
easier
to
just
delegate?
Okay,
you
have
this
entire
area
here,
free
for
you
and
as
our
core
is
constrained
to
this
space
or
namespace,
let's
say
or
this
father
there's
nodes,
then
you
can
have
as
much
as
much
access
as
you
need.
D
It's
exactly
the
same
thing
as
we
had
before
it's.
We
need
to
make
sure
that
applications
have
access
to
what
they
need
and
don't
have
access
to
what
they
don't
need
now.
Kubernetes
does
make
it
easier
because
you
can
have
network
policies
and
you
can
apply
those
and
they're
easier
to
manage.
Then,
who
knows
what
networking
management
tool
that
you'll
have?
The
kubernetes
also
has
pod
security
policies,
which
again
actually
kind
of
federates.
This
knowledge
around
my
pods
should
be
able
to
do
this.
It
should
not
be
able
to
run
it's
really.
D
It
shouldn't
be
able
to
do
that,
so
it's
still
the
same
practice
carlie
it,
but
the
the
way
that
we
can
control.
It
is
now
with
a
standard
set
of
tools.
We
still
have
not
cracked
the
whole
nut
because
hope
of
turning
auditing
on
to
understand
and
then
having
great
tool
that
could
read
audit
logs
from
kubernetes
just
still
aren't
there
and
just
to
add
one
more
last
thing
that
when
when
we
were
before,
we
were
being
where
we
were
hefty.
D
Oh,
we
had
a
co-worker
who
wrote
basically
dynamic
audit,
and
that
was
probably
one
of
the
first
steps
that
we
would
need
to
be
able
to
employ
this
at
scale.
So
we
are
early
early
super
early
in
our
and
our
journey
and
getting
this
right,
we
just
don't
have
all
the
necessary
tools
yet
so
that's
why
it's
hard
and
that's
why
people
don't
do
it
I.
C
So
when
you're,
when
you're
trying
to
resolve
like
I,
have
deployed
my
application
in
dev
and
it's
the
Wild
West,
there's
no
constraint
anywhere
I
can
do
anything
within
dev
right
and
then,
when
I'm
trying
to
actually
promote
my
application
in
staging.
It
gives
you
some
platform
around,
which
you
can
actually
like,
say:
okay
well,
when
I
get
to
staging
I,
do
have
to
enforce
these
things
and
I
have
a
way
and
against
they'll
all
still
part
of
that
same
API.
C
I
still
have
that
same
user
experience
that
I
had
when
just
deploying
or
designing
the
applications
of
getting
them
deployed.
I
can
still
look
again
and
understand
like
what
the
constraints
are
that
are
being
applied
and
make
sure
that
they're
reasonable
for
my
application
does
my
application
run
as
lawn?
Where
does
it
have
access
to
the
network
resources
that
I
have
that
it
needs
to,
and
if
and
if
not
you
know,
can
it
can
I
see
where
the
gaps
are?
You
know.
D
So
a
brain,
even
listening
to
this
kubernetes
doesn't
have
all
the
documentation
we
need,
and
no
one
is
actually
written
this
book
yet,
but
on
kubernetes
that
io
there
are
a
couple
of
documents
about
security
and
if
we
have
show
notes,
I
will
make
sure
those
get
included
in
our
show
notes,
because
I
think
there's
the
institution.
You
should
at
least
understand
in
a
pod
security
policy.
You
should
at
least
understand.
What's
in
a
network
security
policy,
you
should
at
least
understand
how
roles
and
role
bindings
work.
D
D
A
A
Things
like
well
now
cube
ATM.
You
can
reroll
certificate,
which
is
really
not
nice
hold
these
like.
We
are
getting
to
a
place
where
we
have
more
tooling
available
and
I'm
really
happy
about
it,
because
I
remember
using
kubernetes
a
year
ago
and
everyone's
like
well,
how
do
you
secure
a
secret
in
kubernetes
and
I'm
like
well?
It
sure
is
base64-encoded
and
it's
not
at
all
secured.
D
Credit
bitNami
has
been
doing
sealed
secrets-
that's
been
out
for
quite
a
while,
but
the
problem
is:
is
that
how
are
you
supposed
to
know
about
that,
and
how
are
you
supposed
to
know
if
it's
a
good
standard
and
then
also?
How
are
you
supposed
to
benchmark
of
against
that?
How
do
you
know
if
all
your
secrets,
hard?
How
do
you
know
if
your
secrets
are
okay
and
we've
been
talked
about
the
other
side,
which
is
like
response
or
detection
of
issues
we're
just
talking
about
starting
out?
What
do
you
do?
That's
right,
yeah.
A
It
is
a
district.
You
look
like
we're
saying
like
under
sending
all
the
avenues
that
you
could
be
impacted
is
kind
of
a
daunting
task.
I
mean
yeah.
So,
let's,
let's
talk
about
like
the
target
breach
that
occurred
a
few
years
ago.
So
if
anybody
doesn't
member,
this
basically
target
had
a
huge
credit
card
breach
from
their
database,
and
you
know.
Basically,
what
happened
is
that
there,
oh
I
D,
see
if
I
recall
properly
there.
A
Oh
I
D,
see
agent
or
their
token
had
not
expired,
but
the
audience
for
it
was
so
broad
that
someone
had
hacked
into
one
computer,
essentially
like
a
register
or
something,
and
they
had
they
were
able
to
get
the
OEC
token
from
the
local
machine
and
the
the
authentication
audience.
For
that
whole
token
was
so
broad
that
they
were
able
to
access
a
database
that
had
all
of
the
credit
card
information
into
it.
These
are
one
of
those
things
that
you
don't.
A
Sometimes
you
don't
think
about
when
you're
setting
up
security
when
you're,
just
maybe
just
getting
started,
or
something
like
that,
like
what
are
the
avenues
of
attack
right
and
you'd
say
like?
Oh,
oh,
a
DC!
Is
this
your
authentication
mechanism?
How
you
know?
Why
would
we
need
to
concern
ourselves
with
this
and
then,
but
not
understanding,
kind
of
what
we're
talking
about?
Let's
look
at
the
networking
isn't
the
broadcast
I
mean
what
is
the
blast
radius
of
something
like
this,
and
so
like
I
feel
like
this
is
a
good
example
of
its.
C
I
agree,
yeah
I
mean
getting
getting
started
and
actually
you
know,
and
even
and
even
mean
to
Brian's
point
it's
like
how
do
you?
How
do
you
test
against
this?
How
do
you
know
that
what
you
define
is
enough
right
like
we,
we
can
define
all
these
constraints
and
we
can
even
think
that
they're,
pretty
reasonable
or
rational
and
the
application
may
come
up
and
operate
but
like
how
do
you
know
like?
How
can
you?
How
can
you
verify
that
that
what
you've
done
is
enough.
A
D
And
then
also
remember
so:
what's
ID
see,
has
it
some
foundations
in
OAuth
and
you've
realized
that
it's
a
very
strong
door,
but
it's
only
a
strong
door.
It
also
that
you
can't
walk
around
the
wall
that
is
protecting
or
I'm
over
the
wall
that
it's
protecting,
and
so
there's
also
there's
a
bit
of
trust,
and
when
you
get
into
things
like
the
like
the
target
breach,
you
have
to
understand
that
you
really
have
to
understand
blast
radius
for
anything
you're
going
to
do
so.
D
D
So
really,
what
should
we
need
to
do
is
stop
looking
in
security.
Is
this
one
big
thing
and
we
need
to
figure
out
what
are
our
blast
radius?
You
know
a
firecracker
blowing
up
in
my
hand.
It's
gonna
hurt
me,
but
Nick,
it's
not
going
to
hurt
you,
but
you
know
if
someone
drops
a
huge
nuclear
bomb
on
the
United
States
of
the
West
Coast
United
States
I'm,
talking
to
myself
right
now.
D
So
we
got
to
think
about
that.
You
gotta
think
about
like
that.
What's
the
worst,
that
can
happen
if
this
thing
gets
busted
or
its
share
or
someone
finds
if
it
should
not
happen
and
every
piece
of
data
that
you
have
that
you
consider
secure
or
sensitive,
you
should
be
able
to
figure
out
what
that
means,
and
that's
how
you
know
whenever
you're
defining
a
security
posture,
that's
what
you're,
because
that's
why
you'll
notice
that
a
lot
of
companies,
some
of
them
do
run
open
within
a
contains
own.
D
So
but
there's
you
could
talk
to
whatever
you
wanted.
We
don't
actually
have
to
be
as
secure
here,
because
if
we
lose
one
we
lost
them
all.
So
who
cares
so
we
need
to
think
about
that,
and
how
do
we
do
that
in
kubernetes?
Well,
we
use
things
like
namespaces.
First
of
all,
and
then
we
use
things
like
this
network
policies.
Then
we
use
things
like
pod
security
policies.
We
can
lock
some
access
down
to
just
namespaces.
D
If
we
need,
if
need
be,
you
can
only
talk
to
pods,
your
namespace
and
and
what
you
need
to
do
and
I'm
not
telling
you
how
to
do
this,
because
you
need
to
figure
out
talking
with
your
developer
talking
out
their
security
people,
but
if
you're
in
security,
you
need
to
talk
to
your
your
product
management
staff
and
your
sleep
and
your
engineering,
your
software
engineering
stuff,
to
figure
out
really.
How
does
this
need
to
work?
C
Yeah
I
think
you
know
it's
I
feel
like
I'm
a
little
bit
of
a
broken
record
on
this
one,
but
I
I'm
gonna
go
back
to
chaos,
engineering
again,
because
I
feel
like
it's.
It's
critical
to
stuff
like
this,
because
it
enables
a
culture
in
which
you
can
explore
both
the
behavior
of
applications
itself,
but
but
why
not
also
use
this
model
to
explore
different
ways
of
accessing
that
information
or
coming
up
with
theories
about
the
way
the
system
might
be
vulnerable
based
on
a
particular
attack
or
a
type
of
attack.
C
Right,
like
you
know,
but
I
think
that
I
think
this
is
actually
one
of
the
movements
within
our
space.
That
I
think
provides
like
the
most
hope
in
this
particular
scenario,
because,
like
a
good,
a
reasonable
chaos,
engineering
practice
within
within
an
organization
enables
that
ability
to
to
explore
all
the
things
you
don't
have
to
be
red
team
or
blue
team.
You
could
just
be
somebody
who
understands
this
application
well,
and
the
question
for
the
day
is:
how
can
we
attack
this
application?
C
Let's
come
up
with
series
about
the
way
that
perhaps
this
application
could
be
attacked.
Think
about
the
problem
differently,
instead
of
thinking
about
it
as
an
access
problem,
think
about
it,
as
you
know,
think
about
it
as
the
way
that
you
extend
trust
to
the
other
components
within
the
cluster
like.
Are
they
or
within
your
particular
distributive
system?
C
C
Yet
a
third
system,
you
know,
like
you,
know,
start
playing
with
those
ideas
and
prove
them
out
within
your
application,
a
culture
that
embraces
that
I
think
is
going
to
be
by
far
a
more
secure
culture,
because
it
because
it
lets
developers
and
engineers
explore
these
systems
in
real.
You
know
in
ways
that
we
don't
generally
explore
them.
D
D
D
But
if
you
realize
you
have
to
realize
that
it's
another
piece
of
complexity
that
you
have
to
own
and
just
like
any
other
thing
in
security
world,
you
realize
you
need
to
rationalize
how
much
time
you're
going
to
spend
on
it
versus
the
bottom
line,
because
if
I
have
a
hello
world,
app
I,
don't
really
care
about
network
access
to
that.
Unless
it's
a
hello
world
app
running
on
the
same
subnet
as
some
doing
some
PCI
data,
then
you
know
it's
a
different
conversation.
C
Yeah
I
agree:
I'm,
not
I'm,
not
necessarily
I'm,
not
trying
to
position
it
as
a
panacea.
What
I'm
trying
to
describe
is
that
I
feel
like
having
a
culture
that
embraces
that
sort
of
thinking
uh-huh
is
it's
going
to
is
going
to
enable
us
to
to
be
in
a
better
position
to
secure
these
applications
or
to
or
to
handle
a
breach
or
to
deal
with
very
hard
that
hard
to
understand
or
resolve
problems
at
scale?
C
You
know
whether
that's
a
number
of
connections
per
second
or
whether
that's
you
know
the
number,
the
number
of
applications
that
we've
horizontally
scaled.
You
know
like
coming
up
with
being
able
to
embrace
that
sort
of
a
culture
where
we
ask
why
or
we
say
or
what,
if
or
if
we
actually
come
up.
You
know
embracing
the
idea
of
of
that
curiosity
that
got
you
into
this
field.
C
A
Seems
like
maybe
the
best
like
solution
to
the
dichotomy
between
security
and
agility
is
really
just
open
conversation
in
a
way
people
actually
reaching
across
the
aisle
that
well,
that's
not
a
great
phrase
but
whatever
to
talk
to
each
other
like
so.
If
you're
embracing
these
cultures,
you're
saying
Duffey,
the
security
team
should
be
having
constant
communication
with
the
application
team,
instead
of
just
like
yep
team,
doing
something
wrong
and
the
security
team
coming
down
and
like
smacking
their
hand
and
being
like.
A
D
But
my
developer
isn't
talking
well,
I
just
need
to
be
able
to
serve
this
data,
so
accounting
can
do
this
and
that's
what
happens
a
lot
in
security
conversations.
You
have
two
groups
of
individuals
who
have
wholly
different
goals
and
part
of
that
conversation
needs
to
be
aligning
one
jar
and
then
aligning
on
those
goals.
But
what
happens
with
pretty
much
everything
in
development
world?
D
We
always
bring
our
networking
our
security
and
our
operations,
people
in
right
at
the
end
right
when
we're
ready
to
ship
hey,
make
this
thing
work
and
really
well,
where
a
lot
of
our
problems
come
out
now,
security
either
could
or
want
it
to
be
involved
at
the
beginning
of
a
software
project.
What
we
actually
are
talking
about,
what
we're
trying
to
do?
You
know
we're
trying
to
open
up
this
service
to
talk
to
this
share.
This
kind
of
data
security
can
be
in
there
early
saying.
D
Oh
no,
you
know
we're
myth
we're
using
this
resource
and
our
cloud
provider
what
it
doesn't
matter,
really
matter
what
cloud
provider
and
we
need
to
protect
this.
This
data
is
sitting
here
at
rest.
If
we
get
those
conversations
earlier,
it
would
be
easier
to
engineer
solutions
that
could
be
hopefully
reused.
So
we
don't
have
that
conversation
in
the
future,
but.
B
Then
it
goes
back
to
the
issue
of
agility
right,
like
Sophie
was
saying:
well,
you
can
develop
on
develop
against
the
development
cluster,
which
has
much
less
restrictive,
restrictive
restrictions
can
I
believe
I
said
that
it
has
much
less
restrictions
and
they
moved
to
a
production
environment
with
the
proper
restrictions.
And
then
then
you
find
that
or
maybe
staging
environment,
let's
say,
and
then
you
find
out.
Oh
whoops,
no
bunch
of
restrictions,
I
didn't
deal
with,
but
I
didn't
move
a
lot
faster
because
I
didn't
have
them,
but
now
I
have
to
deal
with
them.
C
It
said
that
you
should
develop
your
monolith
first
and
then,
when
you
actually
have
the
working
you
know
when
you
actually
have
a
working
prototype
of
what
you're
trying
to
create,
but
then
consider
carefully
whether
it's
time
to
break
this
thing
up
too
into
it
into
a
set
of
distinct
services
right
and
consider
carefully
also
like
what
the
value
of
that
might
be
right
and
I.
Think
that's
that
the
reason
that
that's
said
is
because
it's
it
is
easier.
It's
maybe
like
a
lower
cognitive
load
with
everything's
all
right
there
in
the
same
code
base.
C
You
understand
how
all
these
pieces
interconnect
and
you
can
kind
of
like,
and
you
can
quickly
develop
a
prototype,
what
you're,
what
you're
working
on,
whereas,
if
you're
trying
to
develop
all
these
things
into
individual
micro
services.
First,
it's
harder
to
figure
out
where
the
line
is
like
work
where
to
divide
all
of
the
the
business
logic
up.
C
These
are
the
things
that
they're
going
to
access.
This
is
the
way
that
they're
going
to
go
about
accessing
them.
You
know
if
you
could
declare
that
intent
and
that's
actually
that's
a
reasonable
body
of
knowledge
for
which
the
security
people
can
come
along
and
say:
okay,
well,
you've
told
us,
you
know,
you've
informed
us.
You've
worked
with
us
to
tell
us
like
what
your
intent
is.
We're
gonna
enforce
that
intent
and
see
if
it's
reason
and
see
what
falls
out
you
know
and
we
can
iterate
there
yeah.
B
Everything
is
that
makes
sense
to
me,
starting
with
the
other
monolith.
First
I
mean
when
you
start
out.
Why
would
you
want
to
abstract
things
that
you
don't
really
I
mean?
You
think
you
might
think
you
know,
but
you
only
really
know
in
practice
what
you're
going
to
need
to
abstract.
So
don't
abstract
things
too
early
I'm,
big
fan
of
that
idea.
B
So
yeah
start
with
the
monolith
and
then,
if
we
figure
out
how
to
break
it
down
based
on
what
you
need
in
security
I
would
imagine
the
same
idea
resonates
with
me.
Don't
secure
things
that
you
don't
need,
you
don't
need
you
don't
know
just
yet
need
securing
accept
the
deal-breaker
things
like
there
are
some
things
we
know
like.
We
don't
want
production
data
being
accessed.
B
D
Right
but
I
was
still
iterating,
but
it's
always
it's
denied
by
default.
Just
remember
that
it's
securities,
it's
actually
the
opposite
way.
We
want
to
make
sure
that
we
have
the
least
amount
and
and
even
if
it
is
harder
for
us,
you
always
want
to
start
with
I
allowed
I
allowed
TCP
communication
on
port
443
or
UDP
as
well.
That's
that's
what
I
would
love
rather
than
saying.
D
C
Do
want
to
clarify,
though,
because
I
think
with
you
and
I
are.
We
are
like
representative
of
that
day.
Out
of
me
right
at
this
moment,
right,
shake
I
feel
like
what
you're
saying
is
that,
like,
like
the
constraint
should
be
the
normal
being
able
to
you,
know
drop
all
traffic,
do
not
allow
anything,
is
normal
and.
C
They
need
to
be
able
to
explore
what
normal
looks
like
by
developing
these
patterns
and
then
enforced
them
right,
which
is
which
is
kind
of
turning
the
model
on
its
head
and-
and
this
is
actually
I-
think
the
like
the
current.
The
kernel
that
I'm
trying
to
get
to
in
this
conversation
is
that,
like
there
has
to
be
a
place
where
you
can
go
play
and
learn
what
normal
is
and
then
you
can
move
into
a
world
in
which
you
can
actually
enforce
what
that
normally
looks
like
with
reasonable
constraint.
D
And
I
think
well,
I
think
what
I'm
trying
to
say
here
layer
on
top
of
this
is
that
yes
I
agree,
but
then
I
understand
what
what
a
breach
can
do
or
and
will
M
and
what
bad
security
will
do
so
I'll
say:
yeah
they'll
learn
go
play
all
you
want,
but
not
on
software
that
will
ever
make
it
to
production.
They'll,
learn
those
practices
but
you're
going
to
have
to
do
it
outside
of
your
gonna.
Have
a
sandbox
and
that
sandbox
is
gonna,
be
unconnected
from
the
world.
D
C
Right,
yeah
yeah,
you
don't
learn
to
ride
a
motorcycle
on
the
street.
You
know
you
don't
learn
to
write
ever
go
on
the
dirt
where
it
quick
and
then
you
could
take
those
skills
later.
You
know,
but
yeah
I
think
we're
in
agreement
like
production
is
a
place
where
we
where,
where
we
do
have
to
enforce
all
of
those
things
you
know
and
having
some
promotion
model
in
which
you
can
come
from
a
place
where
you've
learned
it
to
a
place
where
you're
beginning
to
enforce
it
to
a
place
where
it
is
enforced.
C
I
think
it's
also
important
and
I
I
frequently
describe
this
as
like
development.
Staging
and
production
right
staging
is
where
you're
gonna
hit
the
edges,
because
this
is
where
you're
actually
defining
that
constraint
and
it
has
to
be-
and
it
has
to
be
right
before
it
can
be
promoted
to
production
right
and
I
feel
like
the
middle
ground
is
also
important
and.
D
Remember
that
production
is
any
environment.
Production
can
reach
people's
right
in
any
environment
that
can
reach
production
is
production
and
that's
including
a
we
do.
We
do
data
backup
dumps
and
we
clean
them
up
from
production,
and
we
use
it
as
step
as
as
data
in
our
staging
environment.
If
production
can
directly
release
reach
staging
or
vice
versa,
it's
all
production
and
that's
how
your
attack?
That's
your
attack,
vector
that's
how
someone's
going
to
get
in
and
steal
your
production
data.
That's.
A
So
this
is
I'm
more
pausing.
This
is
a
question
because
I
don't
know
if
any
of
us
have
the
answer,
but
it's
I
wonder
how
they
secure
their
infrastructure,
their
environment,
well
enough
to
allow
people
to
play
to
learn
these
things
and
also
to
deploy
to
production
production,
to
deploy
production
level
code
all
on
the
same
area.
That
seems
really
kind
of
interesting
to
me
and
then,
if
I
understood
that
I,
probably
making
a
lot
more
money
well.
D
It's
simple:
really:
it's
a
huge
people
process
at
Google
that
stops
that
X's
gatekeeper
for
a
lot
of
this
stuff,
so
I
have
never
worked
at
Google.
I,
have
no
intrinsic
knowledge
of
Google
or
have
talked
to
anyone
who
was
giving
me
this
insight.
This
is
all
speculation
disclaimer
over,
but
you
can
actually
run
a
big
cluster
that
if
you
can
actually
prove
that
you
have
network
and
memory
and
CPU
isolation
between
between
containers,
which
they
can
in
certain
cases.
In
some
cases
they
can't
do
this.
D
What
you
can
do
is
you
can
use
your
people
process
and
your
approvals
to
make
sure
that
software
gets
to
where
it
needs
to
be
so
you
can
still
play
on
the
same
clusters,
but
we
have.
We
have
great
handles
on
network
that
you
can't
talk
to
these
networks
or
you
can't
use
this
much
network
data.
We
have
great
things
on
CPU
that
this
CPU
would
be
a
PCI
data.
We
will
not
allow
it
unless
it's
tagged
to
CPU
as
PCI
once
you
have
that
in
place.
D
You
do
have
a
lot
more
flexibility,
but
to
do
that,
you'll
have
to
have
some
pretty
complex
approval
structures
and
then
software
to
back
that
up,
so
the
burden
on
it
is
not
on
the
normal
developer
and
that's
actually
what
Google
is
done.
They
have
so
many
tools
and
they
have
so
many
processes
where,
if
you
use
this
tool
there
does
the
process
for
you,
you
don't
think
about
it
and
that's
what
we
want
our
developers
to
be.
D
A
One
thing
I
think
that
people
seem
to
bulk
on
I
feel
at
least
I
feel
is
developing
it
for
their
own
use
case
right.
People
want,
it
seems
to
people
want
a
overarching
tool
to
solve
all
the
use
cases
in
the
world
and
I
think
with
the
rise
of
cloud
native
applications
and
things
like
container
orchestration.
I
would
like
to
see
people
more
developing
for
themselves
and
their
own
processes
around
kubernetes,
and
things
like
that.
A
D
If
you
have
the
right
credentials.
Other
tools,
it's
super
hard
to
get
the
secret
out.
If
you
even
have
the
right
credentials
because
they
have
a
weird
API
or
they
just
make
it
very
hard
for
you
or
they
expect
you
to
go
click
on
some
GUI
somewhere
and
and
that's
what
we
need
to
do.
We
need
to
have
better
programming
interfaces
and
better
operator
interfaces
and
which
extends
to
better
security
people
interfaces
for
using
these
tools.
D
You
know
this
actually
is
the
I,
don't
know
how
well
this
works
in
practice,
but
the
Jeff
Bezos,
how
how
teams
it
it'll
be
us
or
Amazon
or
forums.
You
know,
teams
communicate
on
our
API
and
I'm,
not
saying,
but
you
don't
you
shouldn't
talk,
but
we
should
definitely
make
sure
that
our
API
is
between
teams
and
like
team
who
own
security
stuff
and
seems
who
are
writing
developer
stuff,
that
we
can
talk
on
the
same
level
of
fidelity
that
we
can
having
a
in-person
conversation.
C
D
A
A
C
Me
too,
I
think
I
think
that
you
know
I
I,
think
if
we're
gonna
explore
anything
else.
We'd
talk
about,
like
you,
know,
I
kind
of
get
it
more
into
that
state.
Where
we're
talking
about
like
that,
we
need
more
feedback
loops.
We
need
people
developers
to
talk
to
security,
people
who
need
security.
People
talk
to
developers.
We
need
like
some
way
of
actually
making
that
feedback
live.
C
In
that
context,
right,
if
you're
in
a
state
where
you're
a
you
know
twenty
percent
thirty
person,
security
team
and
your
responsibility
is
to
secure
a
platform
that
is
running
a
number
of
kubernetes
cluster,
so
number
of
vSphere
clusters
or
the
number
of
cloud
provider
implementations,
whether
they
be
AWS
or
GC.
You
like,
like
I,
mean
that's
a
set
of
problems
that
it's
that
it's
very
difficult
and
I'm.
It's
like
I'm,
not
sure
that
improving
a
feedback,
loop
really
solves
it.
I
know
that
it
helps
but
I.
Definitely,
you
know.
A
B
Forte
at
all,
because
whenever
I'm
developing
I
have
a
very
narrow
needs,
you
know,
I
have
to
access
a
cluster
I
have
to
access
a
machine
or
I
have
to
be
able
to
access
a
database,
and
it's
usually
not
a
no-brainer,
but
I
get
a
lot
of
the
issues
that
were
brought
up
and
but,
as
a
builder
of
software,
I
have
empathy
for
people
who
use
software
consume
software,
mine
and
others,
and
how
can
they
have
any
visibility?
You
know
as
far
as
security
goes
in,
for
example,
in
the
world
of
cognitive.
B
Let's
say
you
using
coconut
ease,
I,
sort
of
start
thinking
well
shouldn't
there
be
a
scanner
that
just
lets
me
declare
I,
think
we
I
think
I'm
starting
an
episode
right
now.
It
should
not
be
a
scanner
that
lets
me
declare.
For
example,
this
notes
can
only
access
this
set
of
notes,
sort
of
like
a
graph,
but
you
just
declare
and
then
you
run
it
periodically
and
you
make
sure
of
course
it.
This
goes
down
to
like
part
of
an
app
can.
B
Only
access
part
of
the
database
can
get
very
granular,
but
maybe
at
a
very
high
level,
I
mean
how
hard
can
this
be,
for
example,
maybe
a
name
like
this
part
can
only
access
that
part,
but
this
part
can
not
access
this
namespace
in
the
skip.
Checking
what
if
the
namespaces
changes
the
permission
changes
or,
for
example,
with
will
are
only
this
user.
These
users
can
do
a
backup
because
they
are
the
same
users
go.