►
From YouTube: CNCF SIG Security 2020-01-22
Description
CNCF SIG Security 2020-01-22
A
A
B
B
C
B
B
B
E
While
we're
waiting
for
things
to
work
out
I'm
kind
of
unclear
on
how
I'm
supposed
to
ask
for
some
time
in
this
meeting
or
subsequent
meetings,
myself
and
a
couple,
people
here
are
from
the
kubernetes
security
audit
working
group,
and
we
would
like
to
chat
with
you
guys.
But
we
don't
exactly
know
how.
So,
if
someone
could
guide
us
through
the
appropriate
process,
we
would
appreciate
it
right.
B
So
one
of
the
so
for
six
security
sessions
we
usually
have
every
month
it's
kind
of
a
mix
off
presentation,
so
I
should
work
in
meeting
sessions.
So
within
the
meeting
notes
dock
on
the
top,
you
will
see
the
time
meeting,
so
there'll
be
a
couple
that
that
will
have
their
and
so,
if
there's
a
topic
that
you'd
like
to
discuss
or
talk
about,
if
you
go
to
any
of
the
working
meetings
and
at
like
a
sentence
or
two
and
your
name
and
what
you'd
like
to
talk
about,
we
will
edit
the
agenda.
Okay,.
E
B
Yeah,
so
so
just
do
that
the
meeting
notes
is
I'm
gonna
pace
it
again
the
chat
in
case
you
can
see
it
I
guess
after
attendance.
Next
week
we
have
a
working
session.
So
if
there
any
issues
that
you'd
like
to
discuss
on
cars
and
things
like
that,
all
you
have
an
item
that
you'd
like
to
add
to
agenda.
You
can
put
it
under
the
three
nine
or
January
working
meeting
in
the
meeting
notes
in
two
weeks,
February
5th.
B
A
A
G
G
G
G
So
if
you
look
at
our
github
you'll
see
that
we've
got
a
number
of
the
focus
areas
that
we're
starting
to
look
into.
I.
Think
attendance
is
a
little
bit
sporadic
where
we're
really
continuing
to
bring
people
in
and
sort
of
solidify
the
agenda.
But
one
of
the
areas
that
we've
got
feedback
on
is
some
of
the
top
focus
areas
that
we've
managed
to
go
out
and
actually
start
coding.
So
the
top
two
items
are
really
around.
You
know
which
controls
can
we
actually
install
on
kubernetes
and
cloud
native
architectures?
How
can
we
test
them?
G
Something
that's
common
across
all
of
our
members
and
also
how
to
address
the
skills
gap,
what
a
training
out
there,
but
we're
also
competing
for
the
same
resources.
So
we've
been
looking
into
that,
so
those
are
two
top
ones
have
been
focusing
on
and
really
focusing
on
just
talking
about
them
and
exchanging
ideas,
but
trying
to
come
up
with
solutions
and
such
as
we
can
share
in
the
open
source
community
they're,
starting
off
with
the
controls.
The
approach
we
took
was
really
looking
at
threat,
modeling
the
kubernetes
infrastructure
itself.
G
So
it's
quite
an
ambitious
start,
but
really
using
that
as
a
mechanism
of
identifying
the
vulnerabilities
and
the
the
attacks
that
could
possibly
be
executed
against
kubernetes
and
get
a
real
understanding
in
weather,
controls
needed
to
be
applying
it.
At
that
time,
we
as
a
group
looked
out
to
see
if
there
was
anyone
doing
this
sort
of
work,
I
think
that
was
probably
early
last
year
and
we
couldn't
find
anyone
specifically
looking
at
it.
G
Subsequently,
we
found
two
or
three
people,
including
the
the
very
very
good
detail,
audit
from
trail
of
bits
that
have
also
got
some
threat
modeling
in
there.
But
at
that
point
we
didn't
have
any
anything
to
go
on,
so
we
were
really
starting
from
scratch
and
we
reached
out
to
some
of
the
chaps
at
control
plane,
who
are
with
me
here
today
as
well
Andy
Martin
to
ask
them
to
come
in
and
help
us
as
a
group
and
detail.
G
Now
what
we
were
doing
with
these
threat
models
and
we
started
to
use
attack.
Trees
is
trying
to
identify
these
attacks.
Who
are
then
using
that
as
a
mechanism
of
mapping
out
where,
within
that
attack
tree,
we
could
apply
particular
control,
whether
it's
a
detective,
preventive
or
responsive.
But
there
was
a
real
push
from
the
group
to
focus
on
how
we'd
actually
automate
those
regression
tests
and
nor
to
make
that
testing.
That's
something
that
we
started
to
build
out,
not
only
from
a
visual
representation.
G
We
can
show
you,
but
also
starting
to
write
tests
to
try
and
validate
that
threat
model
haven't
really
seen
many
other
people
do
that
yet
be
open
to
suggestions
and
and
sort
of
pointers
to
see.
If
someone
has
looked
at
it,
that's
really
one
of
the
focus
areas,
the
other
bit
that
it
really
helps.
Our
members
is
a
mechanism
of
demonstrating
the
threats
that
kubernetes
can
come
under
to
multiple
different
partners.
It's
not
just
the
blue
team
that
would
be
used
to
to
show
this.
G
It's
our
security,
operation
center
and
forensics
team,
and
this
has
actually
been
one
of
the
real
benefits
of
this
approach.
We've
been
able
to
show
how
attackers
getting
into
the
system
why
we
could
get
into
the
system
and
use
that
to
train
our
security
operations
team
on
what
to
look
for
and
start
to
map
out
on
the
tree.
Some
of
the
attack
vectors
as
they
come
through.
It's
really
helped
us
define
the
content
for
remediation
and
Incident
Response,
as
well
as
the
actual
training.
G
So
that's
something
we
didn't
really
anticipate
when
we
were
building
out,
but
it's
probably
one
of
the
main
benefits
at
this
point.
So
this
is
one
of
the
pieces.
We've
open-sourced
this
in
the
CNC
f
will
show
that
the
link
towards
the
end
we
started
with
mapping
out
the
trust
boundaries
around
the
different
components
within
kubernetes
I
think
this
has
been
very
instructive
to
our
teams,
how
kubernetes
truly
hangs
together
and
gives
a
better
understanding
of
the
general
architecture.
Although
was
the
people
were
training
reading
in
the
books
and
have
a
good
understanding
of
it?
G
D
Thank
you
right
so
yeah,
as
we've
said,
we're
looking
to
formally
and
producti
verify
at
the
world
describe
the
security
of
our
systems
and
then
verify
them
from
an
attackers
perspective.
So
we
are
all
very
focused
on
how
to
harden
the
cluster,
but
in
order
to
apply
those
controls,
we
need
to
understand,
of
course,
how
there
will
be
circumvented
and
what
the
routes
into
the
cluster
might
be.
D
So
apologies
to
those
of
you
that
are
familiar
attack,
trees
already
just
run
through
these
quickly,
and
these
are
typically
devised
using
a
top-down
approach.
These.
What
we'll
see
in
the
next
couple
of
slides,
are
sub
sets
simplified
from
the
main
tree
which
we'll
look
at
in
a
minute.
So
we
start
with
a
negative
outcome
that
we
would
like
to
avoid
at
the
top
of
this
tree
and
subsequently
we
asked
how
can
that
be
achieved.
D
Obviously,
we
have
a
key
here
on
the
left,
so
simply
antha
nodes
require
both
actions
and
conditions.
Joining
the
nodes
to
be
true
cost
or
notes
indicates
what
lies
beneath
can
be
realized
in
multiple
ways.
So
one
way
to
achieve
this
specific
example,
if
we
look
at
the
content
of
this
tree
now,
is
to
deploy
a
poison
container
image,
which
in
turn
requires
that
the
container
image
is
poisoned
within
the
container
of
registry.
D
Subsequently,
as
we
go
down
to
obtain
image
full
secret
here,
we
can
achieve
that
in
one
of
three
ways,
and
you
see
this
is
a
green
or
node.
We
can
obtain
it
by
the
cue
Nets
API
or
a
running
container
with
host
file
system
access
or
reading
correct,
like
unit
secret
from
a
mr.
configured
cubelets.
So
that
is
just
a
slice
through
one
of
possible
journeys
to
impact
tree.
We
can
also
invert
the
thing
and
run
the
bottom-up
approach.
D
D
G
Is
actually,
this
is
actually
really
useful
in
perhaps
not
the
standard
mechanism,
the
team
threatening
from
the
bottom-up
approach,
but
what
we
often
found
was
in
reality
we're
taking
it
from
the
perspective
of
well.
We
assume
attacker
has
already
got
to
this
point.
What
can
they
do
and
from
a
soccer
perspective
or
an
incident
response
standpoint?
It's
really
beneficial
for
us
to
look
at
it
this
way,
so
that
we
can
identify
right.
So
we've
we've
actually
covered
up
all
these
controls
or
we've
looked
at,
although
the
content
that
we
need
to
generate.
G
D
And
yeah,
certainly
in
terms
of
the
thought,
process
and
kind
of
mental
abstractions
that
went
into
this
exercise,
certainly
coming
from
the
top-down
and
the
bottom-up,
did
expose
some
gaps
in
our
thinking
the
first
time
around.
So
it
was
a
useful
in
certain
Quality
Assurance,
if
you
like
so
just
to
point.
G
Out
as
well
as
we
were
building
out
the
attack
tree
because
a
couple
of
areas
of
the
tree
that
we
sort
of
identified,
although
we
didn't
particularly
find
a
CBE,
there
were
certainly
areas
that
we
identified
that
subsequently,
someone
published
the
CBE
and,
as
we
were
building
it
out,
we
were
always
looking
at
right.
So
how
can
the
evidence
that?
G
How
can
write
a
test
case,
the
validate
that
we
are
or
not
susceptible
here
at
all,
and
it
turns
out
in
many
cases,
couldn't
quite
think
up
of
a
particular
idea,
the
lo
and
behold,
two
months
down
line.
Someone
else
did
and
it
was
actually
within
the
tree.
We
just
hadn't
figured
out
how
to
exploit
it.
So
I
think
that
was
that
was
interesting
from
a
blue
team
perspective
in
that
it's
probably
easy
to
actually
write
a
detective
control
to
see
if
someone
is
trying
to
do
a
certain
thing,
as
opposed
to
actually
execute
it.
D
So
subsequently,
if
we
move
further
up,
we
can
see
how
this
could
leave
pulling
pushing
images
from
an
imager,
posit,
Ori
or
unauthorized
access
of
data.
Crypto
locking
will
ransomware
all
that
good
stuff
that
we
haven't
necessarily
seen
in
keeping
that
is
yet,
but
we're
seeing
formal
widely
and
okay,
as
we
can
see,
these
attack
trees
and
not
especially
complex,
but
when
composed
into
a
greater
diagram,
are
useful
tool
to
communicate
our
understanding
of
the
security
of
a
system
and
I.
G
Think
it's
John,
probably
just
leaves
their
drones,
but
so
so
you
can
take
a
look
at
the
threat
models
at
the
Weaver
urban
system
for
a
while
now
that
they
are
quite
extensive,
we've
got
a
more
detailed
version
down
here.
They
are
in
Visio.
It
took
me
in
an
awful
long
time
putting
them
together
in
Visio
in
there's
a
number
of
different
major
scenarios.
You
can
take
a
look
at
in
terms
of
next
step,
though.
We've
really
started
to
look
at
how
we
could
automate
it.
G
We
did
look
at
it
from
the
start
and
we
were
trying
to
think
of
different
ways
of
doing
it
and
realistically,
we've
come
to
the
approach
you're
trying
to
create
these
automated
test
case.
We'll
continue
down.
I
certainly
want
to
do
less
physio,
because
my
concern
right
from
the
start,
was
as
soon
as
I
put
it
into
a
document.
In
document
effective,
you
become
stale.
How
do
I
keep
it
updated
and
that's
an
ongoing
challenge
really.
G
G
It's
not
a
huge
leap
to
to
think
of
them
as
effectively
exploit
code
as
we're
writing
an
actual
function
or
a
functional
test
to
try
and
validate
the
security
of
the
system.
The
way
you're
doing
that
is
effectively
writing
almost
an
exploit
so
not
particularly
comfortable
doing
that,
and
certainly
not
open
sourcing
that,
but
perhaps
there
is
purchasing
reaching
out
to
some
of
the
breach
simulation
companies.
G
I
get
huge
amounts,
better,
rotate
retention
when
people
are
actually
getting
the
hands
on
within
an
IDE
or
within
a
command
line
and
going
through
this.
So
we've
basically
built
out
a
hands-on
training
system
where
you
can
stand
up
the
infrastructure
for
kubernetes
loading
exercises
and
then
attempt
to
do
a
particular
training
training
exercise.
Now
it
is
sort
of
like
a
CTF,
but
the
real
idea
behind
it
is
more
on
the
remediation
and
blue
side.
G
Now,
ultimately,
the
goal
would
be
to
allow
the
same
exercise
to
be
deployed
to
a
user
and
they'd
go
in
and
do
the
the
red
team
approach
and
try
and
break
into
a
particular
exercise
that
same
exercise
would
then
be
saved
down
given
to
the
next
team.
Who
would
effectively
do
try
and
do
forensics
on
that
extra
same
exercise
and
then
back
to
the
blue
team.
G
D
Ultimately,
this
is
a
tool
that
allows
learning
and
practicing
on
production
bike
infrastructure
with
impunity,
because
it
is
our
shared
belief
that
DevOps
in
general
than
perhaps
SEC
Ops
in
particular,
really
only
rears
the
specter
of
reality
or
realism.
When
something
is
to
floor,
it's
in
a
nontrivial
environment,
so
simulated
those
few
things.
It
will
wrap
terraform
to
stand
up
a
dress
infrastructure
that
is
behind
the
bastion
to
avoid
drive-by
pwnage.
D
Then
there
is
scenario
runner
which
will
provision
one
of
currently
25
different
snows
on
to
the
cluster
that
has
incremental
hints
guidance
and
is
intended
to
cover
a
range
of
skill
sets.
This
tool
was
originally
built
as
part
of
control
claims
for
more
general
cluster
debugging
and
training
and
security
at
work.
D
What
we've
open-sourced
here
is,
very
specifically,
all
the
security
scenarios,
but
it
is
a
generalized
runner,
of
course,
there's
nothing
really
specific
about
the
hood
perturbations
that
security,
it's
just
a
byproduct
that
saved
a
different
code
path.
It
is
a
wall
command
line,
experience
which
means
you're
dropped
into
a
shell
and
you're.
Given
access
to
any
tooling
that
you
so
desire
that
shell
is
already
relatively
tooled
up,
but
should
you
want
to
pull
queue
punter
or
whatever
it
is,
then
there's
there
are
no
restrictions
and
then
yeah.
D
D
So,
of
course,
we're
attempting
to
communicate
what
we
consider
best
practice
for
these
things
again.
Reviewing
these
things
will
be
very
welcome,
because
some
extent
there
is
subjectivity
involved.
It
is
possible
to
run
all
of
this
open
source.
Of
course,
be
aware
of
doing
this
in
your
organization's
billing
accounts
that
he's
a
willfully
vulnerable
and
as
such.
G
So
is
quite
a
nice
sort
of
developer,
an
end
user
experience
and
a
lot
of
the
challenges
that
we've
implemented.
There
are
really
focused
on
the
mitigation,
but
I
I
strongly
believe
that
to
actually
get
to
the
point
where
you
understand
how
to
mitigate
appropriately,
you
have
to
understand
how
to
attack
in
the
first
place.
So
that's
why
the
hints
came
in
so
a
lot
of
the
people
aren't
seasoned
red,
teamers
or
pen
testers
so
worthwhile
at
least
having
a
try.
G
Then
the
next
steps
really
in
this
piece
are
really
centered
around
allowing
a
local
development
experience.
So
at
the
moment
it
does
deploy
all
of
the
functionality
in
2000.
You
asked
me:
have
a
bastion
host,
an
environment
we
deploy
it
to,
but
often
I'd
much
prefer
the
ability
to
use
to
do
on
the
train
or
give
developers
access
to
it
in
that
way.
G
So
so
those
those
are
really
just
the
the
two
focus
areas
we've
really
dug
into
so
far.
It's
it's
certainly
work
in
progress
and
it's
open
for
any
commentary
or
feedback
on
either
those
two.
We
have
a
whole
list
of
additional
focus
areas
that
we're
going
to
go
through
as
a
an
FSU
G
team.
I
think
the
next
ones
have
been
codifying
controls
which
I
know
a
lot
of
our
team.
G
Members
are
really
really
focused
on
and
we've
started
to
get
into
some
of
that
as
part
of
the
threat
modeling
threat,
modeling
work
so
I'll
hand.
It
back
I'd
really
be
interested
in
any
feedback
on
the
approaches
that
we've
taken
or
anything
that
is
of
interest
or
you've
seen
other
people
implement.
Some
of
this
work
around
threat,
modeling
or
automating.
The
testing
around
threat
modeling
just
look
to
do
up
to
your
thoughts.
B
G
H
G
H
C
So
there
you
have
a
situation
where
you'd
kind
of
have
to
either
break
it
down
and
add
additional
intermediate
nodes
or
other
things
like
that,
I'm
wondering
if
you've,
if
you
made
a
conscious
choice
to
choose
this
style
or
whether
this
was
something
that
happened
or
is
there?
Is
there
a
reason
to
do
this
or
the
other
way
I
wish.
G
Honestly,
I
think
we
were
learning
as
we
went
along
in
many
ways
as
long
as
it
means
that
I
don't
have
to
redo
those
Visio
diagrams
I'd
be
open
to
anything
really
so
I
I
get.
It
would
be
interesting
to
see
what
difference
that
makes
to
the
baby.
We
take
one
page
and
take
a
look
and
see
how
that
would
affect
it.
I.
G
Don't
know
is
the
answer.
I
haven't
tried
that
I
don't
know
the
answer,
but
it'd
be
interesting.
To
take
a
look,
I
think
a
lot
of
the
value
we
got
out
of
it.
We
thought
it
was
the
kind
of
the
discretion
discussion
and
the
creation
of
that
threat
model.
Just
the
the
conversations
that
were
spilling
out
of
that
those
sessions
were
you
know
it
really
got
us
thinking
about
actually
that's
a
real
issue.
They
needed
to
take
a
look
in
evidence
and
put
that
on
that
document
diagram
and,
if
there's
any
way
of
we're
efficiently.
C
Take
a
look
great
and
since
I
have
the
stole
on
the
floor
for
second
I
missed,
elect
for
one
second
longer
and
just
ask
kind
of
public,
which
is
that?
Have
you
looked
at
any
of
the
other
follow-on
things?
People
often
do
with
threat
modeling,
where
you
try
to
assign
like
risk
probabilities
to
nodes,
or
did
things
like
looked
at
collusion
cases
where
an
attacker
has
capabilities,
x
and
y
in
a
weird
way
that
may
allow
you
to
break
through
different
parts,
the
infrastructure,
anything
yeah.
G
G
Again
more
to
the
the
visualization
of
it,
we
were
able
to
highlight
the
value
of
some
tools,
so
we
looked
at
the
probability
of
what's
the
probability
of
X
and
Y
and
Zed
happening,
and
where
are
the
tools
that
we've
used
created
or
bought
and
where
are
they
actually
providing
that
value?
So
if
we've
got,
you
know,
eighty
percent
of
high
chance
that
this
is
going
to
happen.
Where
are
they
only
attack
tree
and
if
we've
bought
this
very
expensive
tool?
G
C
G
What
are
the
likelihood
of
me
getting
a
service
account
for
getting
this
key
or
that
key?
So
if
we
can
start
to
get
some
of
that
more
probability,
data
or
attack
based
data
into
it
to
evidence
some
of
the
probability
so
I
think
that'd
be
really
interesting,
but
the
points
were
made
it
was.
It
was
it's
pretty
illuminating
that
one
diagram
Ian
get
a
lot
out
of
it
right.
C
And
and
we
had
a
similar
problem,
we
actually
had
different
people
independently,
try
to
come
up
with
and
justify
a
different
score,
and
then
we
sat
together
and
discussed
and
we
didn't
ever
really
try
to
push
people
to
change
their
score.
But
if
you
do
some
information,
you
got
from
somebody
else
you
could
and
then,
in
the
end,
we
we
did
kind
of
a
median
sort
of
thing.
As
a
result
of
this
and
I
think
we
were
all
pretty
happy
with
with
how
that
came
out.
D
I
What
I
was
thinking
because
the
conversation
became
mathematically
inclined
and
we
were
talking
about
ands
and
ORS
and
then
the
boolean
logic
right,
but
we
also
talked
about
it
from
a
probabilistic
way.
What
I
was
thinking
was
more,
what
about
doing
some
kind
of
very
formally
verified
threat
model
right
like
because
and
Nora
like
boolean
logic.
So
how
do
we
get
there?
G
G
B
G
G
There
will
absolutely
be
differences
if
it's
multi-cloud
and
the
thing
I
was
really
really
interested
in
was
the
supply
chain,
security
and
sdlc
required
to
deploy
kubernetes
and
how
that
would
affect
it
that
if,
if
when
we
go
again,
we
will
go
again.
That's
where
that's,
where
I
think
the
next
focus
will
be
on
effectively
well,
first
of
all,
finding
out
as
anyone's
already
done
that
and,
secondly,
try
and
look
at
it
from
the
supply
chain
perspective
win
with
respect
to
communities.
J
C
Yeah
but
I
think
there's
a
you
know
all
kind
of
joking
aside.
You
know,
of
course,
others
like
the
people
in
SIG's
security
are
also
I.
Think
would
be
very
interested
in
this
and
I
know.
We've
also
done
a
lot
of
work
on
sort
of
the
threat,
landscape
and
things
like
that
that
we're
gonna
be
very
curious
to
do
a
deeper
dive
into
some
of
the
things
that
you
produce
there
because
they're
starting
to
look
a
lot
like
a
work
that
Brandon
and
I
has
been
doing.
C
G
K
K
It
seems
like
a
lot
of
the
work.
You've
done,
isn't
specific
to
financial
institutions,
and
so
I
think
that
if
you
know
if
you're
open
to
it
or
whatever
mechanism,
we
can
link
to
the
work
that
you're
doing
so
that
people,
because
people
come
to
six
security.
Looking
for
resources
like
this,
and
we
don't
have
as
many
resources
to
point
to
as
we'd
like,
and
it's
not
that
they're
not
out
there.
It's
just
a
process
of
you
know
highlighting
things
and
linking
things
so
it'd
be
great.
K
If
offline,
we
can
kind
of
brainstorm,
you
know
or
start
an
issue
where
we
can
be
like.
Where
would
be
a
good
place
to
put
this
so
that
so
we
can
make
people
aware
of
this
and
I
think
the
other
thing
that
I
want
to
like
I,
don't
know
the.
How
yet
I
think
that
one
of
the
things
that
brings
me
to
wanting
to
be
involved
in
this
group
is
in
reality.
This
is
unbounded.
K
Yet
there
are
frameworks
for
thinking
about
this
that
can
make
it
more
approachable
for
people
who
are
coming
from
a
traditional
security
background
into
cloud
native
or
the
creator.
Like
coming
into
the
cloud
and
then
adding
security
which
is
frightening
and
that
there
might
be
a
way
that
we
can,
you
know,
group
things
or
do
something
that
can
make
it
just
not
seem
like
a
3,000
point
list
which
is
itself
contributes
to
lack
of
security.
Because
if
you
execute
on
it,
then
you
can't
make
things
more
secure.
Maybe.
G
B
I
G
G
K
And
I
think
that
the
work
you're
doing
I
think
this
is
one
of
the
neat
things
about
this
group.
Is
that
it
can?
It
includes
the
people
who
make
the
software
as
well
as
the
people
who
you
know
the
red
team
people
who
make
sure
it's
break
it
and,
and
there
this
I
wonder
if
there
are
things
that
you
came
across
that
shouted
out
to
you,
like,
oh
wow.
If
this
was
built
differently,
this
wouldn't
be
so
hard.
G
There
were,
and
I
know,
did
a
couple
of
them
down
which
probably
sort
of
rehash
them,
and
that
was
actually
one
of
the
reasons
for
doing
some
of
this
work
is
that
actually,
if
we
identify
certain
issue
as
a
certain
areas,
we
could
have
a
discussion
with
teams
upstream
and
make
it
so
I
mean
the
the
one
Universal
aim
for
some
of
this
work
is
the
automated
testing
and
the
automated
sort
of
control
or
security
validation.
Yes,.
L
G
L
G
Instead
of
every
single
financial
institution
or
member
of
Epis
ug
standing
up
a
10-person
team
to
learn
how
this
work
and
run
it,
it's
just
not
competitive
advantage.
It's
do
it
once
do
it
upstream
and
again:
it's
not
financial
services.
Really,
it's
just
general
security
I'd
be
interested
in
seeing
if
we
can
push
that.
H
Yeah
I
totally
agree
with
that.
In
fact,
I
was
gonna,
interrupt
you
and
make
the
same
point.
In
fact,
you
could
argue
that
you
know
federated
DevOps
is
kind
of
a
key
thing
that
needs
to
happen.
If
you
can't,
you
know,
push
the
test
cases
through
the
supply
chain,
you
can't
keep
up
with
the
releases
that
are
happening
across
it,
and
this
is
central
to
doing
it
and
when
I
try
it.
H
I
Yeah,
but
it's
also
hard
for
them,
because
even
today,
I
was
talking
with
someone
and
they
were
saying
that
they
are
like
trying
to
adapt
this
kind
of
risk
frameworks.
But
then
it
doesn't
align
with
the
cognitive
security
capabilities
and
that's
a
huge
friction
for
them,
because
on
one
side
they
need
to
be
able
to
be
compliant
and
have
all
this
regulatory
right,
but
at
the
same
time,
like
the
cognitive
capabilities,
doesn't
provide
them
that
seamlessly
and
that's
a
friction
for
them.
I
I
D
G
Gets
to
the
point
where
how
do
you
write
an
automated
test
when,
and
maybe
this
is
because
we're
thinking
about
it
incorrectly?
But
how
do
you
write
an
automated
test
in
a
way
that
it
validates
the
intent
of
the
attack?
Not
the
configuration
of
your
server
I
prefer
the
intent
and
when
you
get
to
that,
you're
effectively
writing
an
exploit
which
then
moved
us
on
to
where
it's
talk
to
the
briefs.
Reach
assessment
teams,
because
that's
more
in
their
wheelhouse.
F
F
What
do
you
mean
exactly
by
exploit?
Because
what
I'm
hearing
regarding
the
test
for
the
control
is
that
you
are
basically
testing
both
the
positive
and
the
negative
right.
You
know
you're
testing,
to
ensure
that
the
control
is
in
place
and
it's
doing
what's
expected
or
it's
not
and
technically
speaking,
these
are
verifiable
without
necessarily
requiring
an
exploit,
because,
realistically
speaking,
you're,
not
necessarily
trying
to
test
an
exploit
for
that
control,
you're
trying
to
detect
the
presence
of
whether
or
not
it's
working
as
intended
or
not
I.
G
G
Configured
a
particular
security
parameter.
It's
a
better
test
for
me.
If
we
actually
try
to
perform
that
security
action,
so
I'll
stand
up
the
privilege
container
and
I
will
try
and
use
that
service
token
to
hit
the
API
server
and
pull
the
secret's
out
of
it
and
I'd
rather
do
it.
That
way,
then
do
a
test
that
would
validate.
G
Yes,
you've
got
a
pod
security
policy
that
has
the
preventative
control
in
there
and
you
don't
have
a
security
token,
because
if
we'd
make
a
mistake
or
it's
not
applied
to
the
appropriate
name,
space
or
kubernetes
has
changed
in
some
way.
That
means
that
the
security
feature
has
changed.
I
wouldn't
know
that
that's
the
case,
whereas
if
I
tried
to
simulate
the
attack,
it
gives
me
more
fidelity,
I,
don't.
F
Wondering
if
that
is
necessarily
what
would
be
a
bad
thing
per
se,
because,
like
typically
speaking,
if
you're
ensuring
that
control
is
in
place,
you're
gonna
have
to
test
both
the
positive
and
the
negative
and
that
effectively
classifies
underneath
so
I'm,
not
sure.
If
I'm
just
misunderstanding,
I.
G
I'm
really
sort
of
suggesting
is
a
an
F
su
G
Group.
We
probably
prefer
not
to
be
writing
explanations
of
how
to
sort
of
test
you
we're
not
writing,
exploit
or
security
penetration
testing
tools
as
part
of
the
FS
ug.
This
is
probably
a
great
group
that
would
be
able
to
do
that
or
be
able
to
discuss
that,
but
it's
probably
not
something
we'd
want
to
do
necessarily
happy
with
the
blue
team
tool.
I
think
it's
early
that.
K
We're
in
it
we
may
be
able
to
uncover
the
you
know
the
groups
or
projects
that
might
have
the
you
know
different
features
or
tooling.
That
would
be
useful
for
that,
like
I'm,
not
sure
we're
about
to
do
an
assessment
of
cloud
custodian,
and
that
might
be
a
framework
that
could
be
applied
to
this
problem
and
it
might
be
something
where,
like
looking
at
it
from
a
general
infrastructure
standpoint
more
like
well,
any
kubernetes
deployment
like
maybe
it
has
some
things
that
don't
need
to
be
authenticated
because
they
just
serve
public
and
right
other
stuff.
K
Let
me
tell
you
how
you
might
be
able
to
pack
into
my
bank
saying
you
know
if
we
decouple
them
a
little
bit
right,
then
we're
saying:
well,
you
have
private
things
and
public
things,
and
this
is
how
you
look
at
them
and
how
you
might
verify
that
the
private
thing
should
be
private
and
a
public
thing
should
be
public,
and
then
you
can
look
at
it
more
from
a
well
certain
things
need
to
be
very
private
and
other
things.
You
know
I.
G
Think
that's
the
way
to
disconnect
it.
What
were
you
referring
to
as
a
reputational
situation?
We
don't
want
the
financial
industry
writing
tools
that
can
it
turn
up
in
newspapers
where
you
can
and
other
people
if
the
communities
can,
but
it's
it's
something
that
it's
not
as
easily
powered
support
from
a
reputational
standpoint,
we'll
do
development
and
defense
all
day
long,
but
that's
that's
for
other
people
to
perhaps
develop
an
open
source.
Obviously,
we've
already
implemented
this
internally
but
multiple
banks,
but
it's
not
something
needed
open
source.
B
N
If
I
could
ask
a
question
to
these
speakers,
you
know
more
slightly
more
primitive
questions.
I
may
have
missed
it
earlier,
or
these
attack
trees
based
on
actual
tax
that
have
been
experienced
in
the
financial
service
industry
or
what
is
the
basis
of
the
origin
or
the
origin
for
the
attack,
trees,
composition.
Here
now,.
G
It's
a
it's
a
logical
exercise
of
every
possible
thing
we
could
think
of
way
of
attacking
the
kubernetes
system.
It's
a
full
threat,
modeling
exercise,
it's
no
specific
bearing
on
particular
attacks.
In
fact,
we
thought
about
those
TTP's
and
I
think
we
discussed
them
earlier.
Perhaps
firm,
The,
MITRE
attack
framework
with
evidence
some
of
this
information,
but
we
at
that
point
there
was
no
information
to
hand,
so
it
was
a
purely
logical
exercise.