►
From YouTube: CNCF SIG-Security Meeting - 2018-03-23
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
B
B
F
D
B
So,
while
we're
waiting
and
everyone's
logging
in
and
getting
set
up,
we've
we've
grown
so
much
and
were
you
know,
heading
towards
the
TOC
in
April?
So
you
know
why
don't
I
go
around
the
virtual
room
and
you
know
just
just:
have
everyone
introduce
themselves?
So
you
know
the
new
folks
know
who's
here
and
the
new
folks
get
introductions.
B
E
Ray
Colleen
and
I've
been
at
Google
for
about
14
years
and
I've
done
various
bits
of
enterprise
pieces
throughout
my
career
here
and
lately
for
last
four
years
of
working
on
GCD
cloud,
trying
to
make
it
more
accessible
and
easier
to
do.
Policy
management
for
large
organizations
and
recently
turned
my
attention
towards
kubernetes
and
trying
to
do
the
same
thing.
They're
generally
concerned
about
administrators
and
I
have
a
place
in
my
heart
for
them
and
want
to
make
sure
that
that
we're
doing
things
right
by
them.
So.
G
F
F
B
D
H
B
I
I
B
B
Maybe
it
so
the
glaring
person
that
I'm
missing
is
mark,
who
is
our
presenter
today,
so
I
might
need
to
pivot.
From
that
Brad's
free
I
know.
You're
you've
been
beginning
to
work
on
the
the
the
white
paper.
Maybe
we
could
pivot
to
you,
know
sort
of
introducing
everybody
to
that
and
chickens,
see
how
that's
going.
E
B
D
B
So
the
the
white
paper
you
know
begins
to
go
in
building
on
the
the
use
cases
that
we've
been
hearing
and
taking
comes
distilling
down.
You
know
all
yes,
three
are
we
recording
we
are
so
this
is
recorded
for
posterity
and
I
will
post
that
to
the
the
meeting
dot
that
we
all
signed
in
on
when
we're
done.
Thank
you,
yeah
and
you
know,
I've
got
all
the
issues
worked
out
with
getting
getting
a
zoom
set
up
all.
E
Right,
yes,
sir,
what
we
what
we
do
is
we
talked
about
kind
of
where
to
start
with
this,
we
we
wanted
to
come
up
with
a
set
of
personas.
You
know
we
talked
about
the
enterprise
or
administrators
Bill
of
Rights,
and
you
know
it
was
an
interesting
discussion
and
then
various
people
said:
okay,
well,
that's
cool!
Well,
what
are
the
different
personas
and
what
are
their
needs?
E
So
we
wrote
the
administrators
bill
of
rights,
obviously
from
the
administrators
point
of
view
right
and
but
you
know,
hey,
there's
developers
and
compliance
folks
and
a
bunch
of
other
things,
so
Sheree
and
Nene
and
myself,
like
we
kind
of,
went
through
and
through
a
bunch
of
personas
into
a
document
to
kind
of
start-
and
you
know
on
my
team.
Currently
we
kind
of
give
these
people
name
so,
hopefully,
eventually,
maybe
we'll
start
talking
about.
Oh
hey,.
D
E
E
So
the
goal
is
is
to
define
what
these
people
are,
these
personas,
what
they
care
about
right,
and
this
really
should
be
a
group
effort-
everybody
here,
they're
just
you
know,
panini
or
King
JJ
for
coming
access,
we'll
share
it
out,
and
you
know,
or
and
just
start
suggesting
stuff
and
writing
personas
in
here.
As
you
see
other
we
can
know,
we
can
iterate
over
time.
So
this
is
a
living
document.
This
is
definitely
the
first
kind
of
go
around
and
you
know
probably
misses
some.
So
just
let
us
know
so.
E
Overall,
we
have
created
this
concept
of
a
Developer
and
Enterprise
operator,
a
resource
captain,
a
network
operator
and
user
which
I
find
it
the
infrastructure
operator
or,
and
then
compliance
security,
admin-
and
you
know
third
party
security,
product
system-
sure
what
that
is
off
to
that
one's
new
to
be
so
yeah.
So,
at
the
end
of
the
day,
I
want
to
kind
of
go
into
each
of
these
and
talk
about
them.
E
The
other
thing
to
consider
here
is
is
what
angle
are
we
looking
at
Gangji
and
I
had
an
interesting
comment
thread
we
said
hey
as
a
developer.
Developers
are
both
consumers
and
resources
and
they're
also
creating
resources
right,
and
so
you
know,
coming
from
my
background.
I
always
think
of
developers
is
consuming.
E
Those
sounding
two
different
personas,
like
a
developer,
acting
in
terms
of
consumer
and
developer,
acting
in
terms
of
creating
something
both
have
different
needs
right,
and
so
that
was
our
proposal,
but
so
I'll
talk
about
developers,
a
consumer
because
I
think
it's
a
little
bit
more
well
defined
and
in
you
know
in
this,
in
this
case
here
you
know
a
developer.
We
would
put
a
few
things
in
here
right,
I,
as
a
developer
need
to
provide
logs
for
any
changes
to
critical
resources,
so
ice
can
be
made
available
for
auditing.
E
So
I
think
this
is
talking
again
and
from
that
that
producer
review
about
creating
stuff,
right
and
I
think
as
a
developer.
I
need
to
be
able
to
tag
my
resources,
so
they
can
be
grouped
by
the
administrator
when
required
right.
So
again,
this
is
talking
about
for
the
producer.
Partly
right,
I
need
to
be
able
to
add
the
generalized
tagging
that
infrastructure,
so
administrators
have
one
view
of
my
resources,
right
and
and
laughs,
and
lastly,
I
think
at
the
developer.
I
can,
I
can
add
policy
checks
to
my
resources
right.
E
So
how
do
we
do
that?
And
how
do
we
make
that
easy,
so
thinking
about
developers,
if
I'm
living
in
the
ecosystem
of
the
safe
world
right?
How
do
I
end
up?
Integrating
with
that
and
I?
Think
you
know
that's
an
interesting
persona
and
I
haven't
we
haven't
written
down
the
developers
consumer
yet
we'll
get
there
soon?
E
Okay,
so
enterprise
operators,
who
are
these
people
right
and
and
we
tend
to
think
of
them
on
my
team,
we
think
of
them
as
as
Olivia
like
they're,
the
overall
kind
of
like
IT
they're,
centralized
teams
that
generally
are
watching
over
the
entire
universe
right.
They
are
generally
trying
to
create
a
safe
environment
for
all
they
want
safe
by
default.
This
is
generally
where
they're
coming
from
right
and
they
want
to
set
up
a
set
of
stuff
process.
Hey
you
just
come
into
the
system.
E
You
can
do
stuff
or
you're
able
to
be
productive,
but
you
also
not
but
you're.
Also,
you
know
restricted
from
doing
things
that
would
be
dangerous
to
our
company,
dangerous
to
our
brand
aid,
restore
data
right
and
so
operators.
Their
goal
is
to
effectively
have
no
people
call
them
right.
So
if
they
can
set
up
some
of
the
way,
so
they
can
basically
put
the
exceptions
in
place
and
put
everything
and
everybody
is
okay,
and
then
they
don't
call
for
things
that
are
everyday
mundane
things.
E
Then
the
enterprise
operators
planning
right
and
they
also
need
to
view
their
system.
They
need
to
be
able
to
troubleshoot
quickly
and
they
need
to
be
able
to
take
action
when
we're
required.
So
you
know
this
is
a
key
thing,
so
an
enterprise
operator.
You
know
they
need
a
central
way
to
look
at
all
their
organization's
resources,
and
so
they
can
administer
them
in
a
single
view.
E
Implicit
in
that
is
the
idea
that
there
is
no
shadow
IT
right,
so
anything
that
gets
created
must
be
visible
and-
and
you
know,
people
can't
go
over
here
and
just
spin
up
a
careers
cluster
and
administer
it
on
their
own
and
no
one
that
knows
that
exists.
That's
the
kind
of
stuff
that
makes
this
enterprise
operator
gives
them
a
lot
of
pause,
all
right
as
an
enterprise
operating
the
ability
to
see
what
has
what
has
changed
about
a
resource
when
it
changed
and
who
changed
right.
E
So
this
gets
into
audit
logging,
it's
about
making
sure
that
we
are
reporting
and
have
easy
ways
to
understand
the
state
of
the
system
and
how
it
got
there,
and
this
is
especially
important
during
incidents
right,
both
outages
and
in
security
incidents.
A
lot
of
times,
policy
changes
and
complete
changes,
cause
outages.
So,
knowing
who
and
when
made
changes
were
made,
you
can
a
lot
of
times
use
those
to
recover
from
outages.
E
It's
also
good,
for
you
know,
incident
response
and
and
certification
all
right,
PCI
in
particular,
is
very
clear
about
needing
to
know
who
has
access
to
what
right
and
prove
it
as
an
everybody's,
oper
I
need
a
way
to
delegate
my
policy
control
to
lower-level
admins.
Who
can
help
me
scale
again.
Enterprise
operators
at
the
top
level
are
trying
to
get
themselves
never
to
be
called,
so
they
want
to
be
able
to
delegate
stuff
to
lower-level
Emmons
who
have
more
knowledge
about.
E
What's
going
on,
so
you
know,
we
talked
to
Costco
a
while
back
and
one
other
things
that
they
were
always
afraid
of
is
look.
You
know
at
the
top
level
admins
what
someone
calls
us
to
change
your
bit,
we're
so
far
removed
from
that
bit
that
we
have
no
idea
what
it
does,
and
it
gives
us
a
lot
of
anxiety
so
by
being
able
to
delegate
to
people
who
actually
understand
what
those
bits
do.
E
That
is
a
very
important
feature
to
efficiency
and
safety
all
right
and
then,
as
an
enterprise
operator,
I
need
to
a
way
to
nominate
per
policy
type
operators,
both
at
the
higher
level
and
lower
levels
right.
So
the
enterprise
operator
is
kind
of
the
root
operator
you
can
think
of
them
as
route
in
your
company.
They
lots
of
times
take
on
many
hats
right,
sometimes
of
the
quoted
people.
Sometimes
the
access
control
people
sometimes
of
the
network,
happens,
but
in
a
big
org.
That's
too
much
for
one
person
to
do
so.
E
They
need
a
way
to
say:
hey
Dan
is
the
network
operator
in
this
company,
and
he
has
the
network
operator
privilege
at
the
root
level
and
hey
tree
is
the
is
the
quota
you
know
resource
captain
and
you
know
she's
able
to
determine,
spend
and
quotas.
For
you
know
the
company,
and
so
it's
both
a
horizontal
skin,
but
it's
also
a
vertical
scaling
in
terms
of
like
okay
Dan
is
the
you
know,
is
the
network
operator
for
the
you
know,
YouTube,
division
right
or
something
of
that
sort:
okay,
cool.
A
J
Talking
about
the
the
operators
in
a
big
enterprise,
they
are
belong
to
the
same
org,
but
sometimes
they
have
multiple
deployments
and
inside
one
department
is
possible.
They
will
have
another.
A
small
operation
team
represent
the
department,
so
is
there
any
distinguish
between
basically
I'm
asking
if
they're
another
division
I
between
the
operators
from
different
departments.
E
Yeah,
that's
a
good
question.
Is
we
the
this
particular
bullet
here?
I
need
a
way
to
delegate
policy
control
on
lower-level
admins
who
help
me
scale.
So
the
idea
here
is
is
you'll,
have
a
departmental
auditor
all
right
and
that
operator
can
be
given
full
control
over
their
compartment
right
and-
and
this
is
something
we
talked
about
in
the
administrators
Bill
of
Rights
right.
E
The
fact
that,
like
you
as
an
as
an
admin,
can
compartmentalize
your
resources
and
then
you
and
you
can
act
autonomously
right,
so
it
you
mean
that
the
enterprise
border
can
give
full
rights
away
to
you
as
a
lower-level
operator
in
a
department,
and
they
could
say
you
have
the
power
to
make
exceptions,
and
you
have
the
power
to
be
able
to
do
this
or
you
don't
right,
depending
on
the
corporate
policy.
Does
that
help
yeah
baby?
Thank
you.
Okay,.
B
B
E
So
the
way
I
think
about
that
is
is
that
the
enterprise
operator
think
of
the
route
you
know,
draws
a
rectangle
and
says
this
is
the
universe
right
and
the
universe
might
be
a
you
know,
just
to
get
down
to
brass
tacks:
a
set
of
networks,
a
set
of
DNS
domains
right.
You
know
a
set
of
you
know
kind
of
cloud
providers
set
up
to
use
those
networks
right
and
share
it
out
and
within
that
rectangle
we
do
not
want
people
to
be
able
to
create
things
and
hide
them
mm-hmm.
E
Right
now,
will
you
describe
like
a
query
company
who
has
another
whole
deployment
somewhere
else,
they're
outside
the
rectangle
right,
and
so
therefore
they
have
their
own
DNS
games.
They
have
their
own
networks,
and
things
like
that.
You
know
they.
You
know
eventually
will
want
to
become
part
of
the
rectangle,
but
they
can
be
protected
through
the
through.
You
know
the
base
the
base
components
of
security
right
into
our
walls
and
DNS,
and
things
of
those
sort
like
you
know,
for
example,
someone
in
shadow
tea
can
never
something,
let's
say
on
google.com
right
there.
E
E
Cool
okay,
so
we
could,
we
can
move
on
now.
I
think
you
know.
The
concept
here
is
when
we
get
into
the
enterprise
operator,
and
we
started
talking
about
like
per
policy
type
operators
right.
We
can
start
thinking
of
who
these
like
per
policy
type
operators
are,
and
so
one
of
them
is
the
resource
captain,
all
right
and
and
the
reason
why
I
particularly
like
this
one
is
because
I
think
it's
pretty
easy
in
in
authorization
to
really
concentrate
on
access,
control,
lists,
right
and
and
and
also
like.
E
E
So
we
can
you
know
we
can
talk
about
that,
but
I
think
you
know
as
a
resource.
Captain
I
need
a
way
to
constrain
how
many
resources
a
set
of
teams,
is
able
to
use
I
need
to
be
able
to
delegate
resource
quota
management
to
sub
captains
right.
You
know,
as
a
as
a
resource
craft
I
need
to
be
alerted.
If
resource
quota
allocation
exceeds
a
certain
amount
right,
people
go
out
of
spec
and
and
again
I
think
you
know
it's
interesting.
F
F
J
Yeah
I
want
to
ask
the
same
question
actually
I'm
thinking
about
something
more
than
the
resource
quota
and
access
control,
especially
in
communities.
There's
another
kinds
of
how
to
call
it
I'd
like
to
call
it
like
a
resource
privilege
like
you,
can
create
a
port
with
a
certain
privilege
or
clarity.
J
Some
some
capability
or
provision
would
be
harmful
to
a
system
like
a
privilege,
containers
that
kind
of
stuff
I'm,
not
sure.
If,
if
this
falls
into
this
category,
yeah.
E
E
E
This
is
more
of
like
constraint,
policies
or
things
of
that
sort.
I,
don't
know
what
the
generic
category.
If
anyone
here
who
has
a
lot
of
policy
experience
knows
what
those
things
are
called
I'd
love
to
know,
we
call
them
in
GCP.
We
call
them
organization
policies,
you
know,
I
think
you
know,
Windows
has
its
own.
You
know
domain
policies
and
things
like
that.
So
that's
a
very
important
use
case
and
it's
actually
one
that
I
think
firebase
rules
is
really
good
at
right.
I,
you
know,
I
think
what
they
do.
E
Is
they
look
at
every
incoming
request
and
they
can
validate
the
Mac
right
of
the
of
the
object
and
then
it
says:
hey
this
thing's
in
the
this
object
and
kick
it
out
right
and
that's
on
top
of
authorization
like
access
check.
So
it's
like.
Yes,
we
has
the
issue
a
has
the
ability
to
to
create
pods,
but
if
pod
spec
doesn't
look
like
this
we're
gonna,
kick
it
out
all
right,
son.
J
E
And
and
I
think,
the
question
we
have
to
ask
ourselves
is
is:
is
that
a
separate
policy
type
with
a
separate
policy
type
operator
right
or
is
it
part
of
the
access
control
system?
And
those
who
will
great
ACLs
are
the
ones
who
create
these
types
of
constraints
and
and
I
think
that
that's
a
raging
to
be
right?
I.
F
E
B
B
You
know
separate
implementation,
you
know
in
kubernetes
or
whatever.
If
we
can
footnote
these
sections
with,
you
know
in
kubernetes
it
you
know
this
is
you
know
called
this
and
you
know
done
how
then
I
think
we'll
be
very.
You
know
setting
ourselves
first
for
success
as
we
navigate.
You
know
the
name
bashing
that
will
invariably
take
place.
D
I
wanted
to
interrupt
for
a
second
I.
Think,
that's
a
great
idea,
then
mark
under
word
is
here
and
we're
at
the
half-hour
mark,
and
maybe
we
can
switch
gears
and
pick
this
up.
But
this
is
a
great
introduction
to
the
white
paper
just
wanted
to
chime
in
with
that.
If
you
want
to
go
back
to
the
originally
scheduled
presentation.
B
Thank
you,
sir
and
Mark.
You
know,
let's
have
an
open
discussion
around
that
I
know
you
have
one
of
your
peers,
the
inside
of
NIST
that
couldn't
make
it
today.
So
you
know
we
could
actually
take
this
either
way.
We
can,
you
know,
give
you
the
floor
and
you
know
have
the
miss
presentation
now
or
we
can
reschedule
that
and
continue.
K
B
So
you
can
find
the
screen
sharing
I,
think
it's
the
big
green
thing,
the
bottom
of
your
screen
and
zoom.
So
let's
go
ahead
and
switch
over
that.
Why
don't
rea?
Why
don't
you
drop
a
link
to
to
the
use
case,
talk
into
into
chat
and
into
the
minutes
and
we'll
pick
that
up
next
week
and
continue
that
that's
looking
really
good?
B
K
Sure
so
I'm
I
work
in
controls
and
countermeasures
in
synchrony
synchrony
is
a
sort
of
a
spin-off
of
g
e--'s,
retail
finance
group.
It's
a
big
company,
I
think
we're
fortune,
140
or
so
prior
to
that
I've
been
working
and
health
informatics
and
I'm
pretty
involved
in
these
in
the
ontology
space,
mostly
on
a
volunteer
basis,
I
co-chaired
the
2015
conference
on
ontology
for
IOT
I
have
a
book
chapter
out
in
on
security
for
IOT.
So
that's
kind
of
my
interest
in
it.
K
This
big
data
group
that
I'm
gonna
give
you
the
an
overview
of
today
started
working
in
2015
I'm,
one
of
about
fifteen
or
twenty.
So
it's
really
a
pretty
small
group,
not
much
bigger
than
the
one
that
we're
in
now.
That's
been
working
on
big
data
and
basically
just
trying
to
give
this
team
some
ideas
of
the
things
we
worried
about
in
that
group
and
it's
a
little
different
from
some
of
the
other
standards
group.
This
is
not
a
standard,
it's
just
a
special
report,
so
it's
not
telling
people
how
to
do
things.
K
It's
more
like
background
on
this.
Oh
I
forgot
to
mention
what
other
things
so
I'm,
also
pretty
engaged
with
I
Tripoli
working
groups
for
DevOps
security,
that's
2675
and
a
suite
if
you
want
to
call
them
that
of
the
7000
series,
which
is
trying
to
deal
with
ethical
issues
so
there's
some
overlap
with
security
and
privacy
issues
and
provenance
for
traceability
of
responsibilities.
For
if
you
look
at
this
Facebook
issue,
that's
out
that
people
are
looking
at
as
a
security
issue.
K
D
D
K
Right
so
the
home
page
has
the
URL
for
this
work
and
all
the
documents
that
are
in
draft
are
available
directly
with
download,
don't
have
to
sign
in
for
anything,
that's
one
thing
about
NIST
of
we're
paying
for
that
with
our
taxpayers,
not
through
the
contributions
of
members,
like
some
other
public
working
groups.
So
that's
that's
one
of
the
advantages,
so
the
we're
in
the
second
draft.
K
It's
a
multi-volume
enterprise
I
forget
how
long
it
is,
but
it's
pretty
long,
I'm
really
just
talking
in
this
venue
about
the
security
and
privacy
work
and
I'm
going
to
give
you
a
taste
at
the
end
of
this
I'm
gonna,
just
see
where
we
are
in
time.
That's
after
five
after
the
hour,
I'll
try
to
stop
by
a
quarter
after
and
show
you
a
few
pages
out
of
the
document
that
I
think
are
relevant.
K
So
the
special
report-
that's
in
draft-
has
already
gone
through
public
comment.
We
didn't
actually
get
a
whole
lot,
which
is
unfortunate,
but
it's
now
going
through
review
at
at
NIST
they've
got
some
things
they
want
us
to
make
changes
to,
but
I
expect
it'll
be
released
for
the
public
in
early
summer
at
the
latest,
if
not
sooner
so,
the
strengths
of
of
what
we've
done
in
volume
four
anyway
of
this
is
that
we've
been
at
it
for
a
while.
K
So
we've
gone
through
a
few
cycles
like
kubernetes,
didn't
even
exist
at
the
beginning
of
this
and
2013
I
mean
it
existed,
probably
internally
somewhere,
but
it
wasn't
in
the
common
discourse
very
much
then
at
least
not
in
our
working
group.
So
it's
been
around
seen
a
few
product
cycles
and
that's
been
good.
We
also
have
seen
the
emergence
of
IOT
during
that
time.
That
really
wasn't
part
of
the
discourse.
So
much,
then
that's
a
good
thing
for
reasons.
I
think
all
become
clear
later.
K
So
that's
a
benefit,
maybe
mainly
because
some
of
the
the
draft
writers
don't
use
the
same
language
across
all
the
documents,
so
it
gets
hard
to
know
in
the
security
document
what's
being
referred
to
in
the
architecture.
Side,
Oh
interesting.
The
weaknesses
of
the
documents
are
kind
of
all
the
same
things,
because
this
mature
it
doesn't
have
the
latest
stuff.
The
vendor
neutrality
often
hides
some
of
the
use
cases
that
are
the
really
interesting
ones.
K
Kubernetes
is
sort
of
an
example
of
that,
but
you
know
miso
and
some
of
the
other
orchestration
challenges
that
are
product
specific
are
really
good
ones.
To
wrestle
with
being
lightweight
can
be
a
problem.
It's
not
because
it's
not
a
standard.
It's
not
going
to
change
people's
behavior
and
how
they
built
build
things
and
a
lot
of
the
the
less
technical
people
involved
in
this
working
group,
because
it
wasn't
just
technology
people.
K
They
were
very
concerned
about
the
sort
of
thing
that
happened
with
Facebook
this
week
last
weekend:
the
public
disclosure-
but,
of
course,
what
happened
in
2016
with
that,
and
in
fact
they
talked
about
it
so
much
we
got
sick
of
hearing
about
it
from
them.
We
we
thought
we'd
addressed
it,
but
you
know
I
think
we
never
fully
satisfied
that
relatively
late
concerns
about
protections
put
around
public
data
in
the
for
the
folks
whose
public,
whose
business
models
are
built
around
consent,
driven
use
of
data
and
the
reference
models
pretty
simplistic.
K
You
know
I
think
this
group
will
probably
find
a
dismissive
or
dismissible,
but
that's
okay
least.
We
know
it
is
so
we
think
are
some
things
that
are
different
about
big
data
most.
Maybe
the
key
thing
is
that
multiple
security
schemes
have
to
be
addressed.
You're
looking
at
attack
vectors
that
vary
depending
on
whose
organization
it
is
countermeasures
are
not
going
to
be
the
same
for
small
companies
compared
to
big
companies,
the
the
people
that
originate
the
data
or
collate
it
may
not
be
the
same
institution
that
is
going
to
deploy
it.
K
There's
a
sensibility
about
how
to
deal
with
sensors
that
people
who
haven't
worked
in
real-time
systems
are
not
aware
of
real-time
stuff's,
not
new
in
computing,
but
it's
new
for
a
whole
generation
or
two
of
folks
who
who
basically
cut
their
teeth
on
transaction
driven,
kind
of
computing
and
relatively
static
database.
Work,
transaction
driven
databases,
and
that's
big
data
forces
you
to
deal
with
SPARC
and
that
sort
of
thing.
So
that's
important.
K
The
unintended
uses
and
the
anonymization
is
a
key
thing
that
just
because
you
don't
have
a
social
security
number
in
a
row
doesn't
mean
that
people
can't
figure
out
who
you're
talking
about
in
your
data
and
so
the
architecture
from
surprise
privacy
and
security.
Point
of
view
need
to
deal
with
D
on
the
anonymization
that
occurs
outside
of
your
own
organization
and
downstream.
When
the
data
is
consumed.
K
There
are
lots
of
problems
with
scale
and
complexity
cloud
magnifies
this.
Obviously
you
get
that
with
the
traceability,
the
veracity,
the
kind
of
content
that
you're
gonna
have
to
manage.
You
know
we
used
to
call
it
Balkan
in
the
early
days
of
databases
now
bulk
stuff
is
you
know
the
main
thing?
That's
moving
on
our
networks.
I.
Think
somebody
told
me
that
YouTube
was,
if
not
the
most
one
of
the
biggest
consumers
on
our
internal
networks,
which
I
find
surprising
because
I
don't
I'm
not
on
it
all
the
time.
K
Yes,
there
is
training
stuff
on
there,
that's
worth
having,
of
course,
and
then
there's
jurisdiction,
issues
that
data
is
shared
across
continents
and
that's
common,
not
uncommon,
and
so
you
have.
You
have
multiple
jurisdictions
that
are
responsible
for
the
data.
So
if
you're
gonna
share
both
data
and
code
in
your
networks
across
organizations
and
countries,
big
data
presents
you
with
problems.
You
probably
didn't
anticipate
in
systems
built
earlier.
Another
thing
that's
kind
of
interesting:
that's
is
that
big
data
power
is
now
wielded
by
smaller
organizations,
really
small,
as
one
person
can.
K
K
So
the
fluffy
part
of
talking
about
security
for
for
big
data
is
that
it's
affected
by
all
these
dimensions:
volume,
velocity,
variety,
veracity
and
volatility
and,
of
course,
cloud
so,
I
think
people
on
this
call.
You
know,
based
on
by
listening
to
this
call,
you
don't
need
to
be
told
why
this
matters,
but
it
might
be
interesting
if
you
think
through
each
one
of
these
and
the
frameworks
that
you're
currently
using
to
manage
them.
K
You
can
see
what
the
challenges
are
that
you
face
and
then
just
multiply
that
across
organizations
what's
left
less
fluffy
about
what
does
he
merge?
That
we
tried
to
worry
about?
Is
the
Big
Data
aspect
of
what
is
going
to
have
to
change
in
the
software
development
lifecycle?
So
agile
is
part
of
this.
The
API
first
architecture
is
part
of
this.
So,
but
you
know,
if
you
haven't
heard
that
lingo,
that's
the
build
to
a
specification.
K
First
before
you
write
any
code,
because
you
know,
if
you
need
a
geolocation
service,
you
probably
are
gonna
need
to
understand
how
to
get
data
from
Google
or
Microsoft
or
some
other
or
from
you
know,
a
government
service.
That's
publishing
that
micro
services
and
containers
are
going
to
be
important,
I
sort
of
see
these,
as
you
know,
children
of
the
components
and
composable
services
movement,
but
this
is
still
important
it.
K
It
matters
because
that's
this
is
going
to
be
a
new
way
that
we
need
to
manage
security,
software-defined
networks
and
5g
are
going
to
be
become
important
because
mobile
networks
are
providing
this
geolocation
service.
That
is
one
of
the
D.
The
principal
drivers
for
a
D
anonymization
of
datasets
left
shift
is
important
because
this
becomes
part
of
sac
ops.
K
So
the
orchestration,
if
you
want
to
call
that
a
play
books
to
run
the
tools
that
you
have
in
the
stack
in
in
the
security
group,
becomes
part
of
what
needs
to
be
coded
and
we're
gonna
push
that
responsibility
closer
to
the
developers
than
it
was
before.
So
people
have
coined
this
as
sec,
DevOps
or
deaths
a
cops,
but
it's
all
kind
of
that.
K
K
So
the
key
trends
we
tried
to
worry
about
in
the
in
the
draft
where
we're
cloud,
obviously
IOT
especially,
is
related
to
health
and
safety,
the
mobility
and
per
se
pervasive
computing.
So
that's
you
know
metrics
that
are
coming
off.
Individual
people,
including
you
know
the
new
voice,
driven
kinds
of
things,
but
also
the
geolocation
stuff.
That
goes
with
most
of
these
things,
the
data
center
automation-
that's
happening,
we're.
Basically,
you
know,
as
as
we're
rethinking
how
we
do
our
stack
and
rack
kind
of
processes
and
the
way
that
we
build
out
protected.
K
Sub
networks
inside
the
data
center
is
now
moving
into
software.
Increasingly,
so
that's
pushing
the
automation
process
further
down
onto
the
stack
with
routers
and
that
kind
of
thing
more
than
it
used
to
be
trusts
in
Federation
when
we
try
to
tackle
that
a
little
bit,
and
maybe
one
of
the
key
things
that
that
I
really
pushed
in
this
design
was
more
automation
on
domain-specific
processes,
either
through
domain-specific
languages
or
explicit
domain
models.
K
And
then
the
last
trend
is
moving
more
toward
attribute
based
access
models,
more
than
role
based
and
the
reason
for
that
is
not
that
role
based
is
gone,
but
that
you
really
can't
effectively
instrument
access
controls
against
only
a
purely
role
based
thing.
If
you
have
domain
based
models
that
are
using
an
attribute
based
model,
so
this
is
gets
a
little
involved.
But
basically,
if
you
want
to
consume
an
ontology
and
do
that
with
an
aid
that
kind
of
system
you're
better
off
using
attributes,
then
roles
mean
the
roles
can
be
derived
from
attributes.
J
K
That's
it's
like
saying:
can
you
build
something
without
admin?
So
I
have
a
standard
ranch
I
get
into
on
this,
but
you
know
it
seems
like
coders.
The
first
thing
they
want
to
do
is
is
is
build
an
admin
it's
like
deciding
to
build
a
bridge
with
that
has
a
guaranteed
single
point
of
failure,
you're
in
it,
and
it's
really
one
of
the
problems
that
we
face
with
this-
that
that
the
architecture
of
the
things
we
build
have
role-based
things
built
into
them
that
don't
need
to
be
there
and
so
yeah.
There
is
unavoidable.
K
You
can't
you
can't
have
that
if
you've
got
an
architecture
with
an
admin
role
in
it,
do
now
I've
got
to
deal
with
it,
but
I
would
argue
you
don't
have
to
have
that.
Now
how
you?
How
you
do
that
you
know
it
depends
on
the
on
the
domain
aspect
of
that,
but
yeah
you,
you
can't
do
one
without
the
other.
We
we
have
a
legacy
of
role
based
of
controls
that
are
not
just
in
our
hardware
systems
in
our
operating
systems,
but
in
the
security
frameworks
built
around
them
is
just
unavoidable.
Mm-Hmm.
K
I
knew
I
wouldn't
get
away
with
that,
so
an
ontology
is
a
model
and
how
you
get
from
an
ontology
to
a
model.
You
know
varies
a
lot,
so
there's
an
oasis
group,
that's
trying
to
develop
a
standard
for
doing
that.
So
an
example
of
that
might
be.
If
you
have
an
ontology
that
allows
you
to
make
an
inference
about
logs
coming
out
of
Splunk
that
represent
a
certain
kind
of
attack.
K
It
could
be
that
the
log
information
will
tell
you
that,
but
the
ontology
tells
you
which,
logs
to
examine,
which
features
you
know
which
of
the
fields
in
the
logs
are
the
ones
that
you
need
to
look
at
because
now
what's
happening
in
with
products
like
Splunk.
Is
you
have
not
just
tons
of
logs
by
volume
by
variety?
So
you
have
many
different
kinds
of
logs
that
need
to
be
looked
at
in
tandem
in
order
to
make
inferences.
K
D
D
K
K
K
White
paper
yeah.
Well,
it
is
a
longer
conversation,
so
yeah,
maybe
it's
more
important
how
we
got
here
for
this
short
conversation-
and
you
know,
if
there's
interest
more
interest,
you
know
you.
This
team
might
be
able
to
drive
some
real
solutions
that
are
still
floating
around
in
the
ether
and
limited
to
academic
spaces.
You
know
more
than
than
the
practitioner
or
space
that
we
really
would
rather
be
in
great.
K
Good
though
I
I
mean
that's
an
important
topic,
so
if
we
have
time
down
the
road,
that's
really
worthwhile
so
influences
that
drove
what
we
did
here,
the
obviously
the
NIST
80
53
because
of
its
prevalence,
not
so
much
the
content,
but
the
prevalence
of
its
adoption.
The
the
building,
automated
there's
a
smart
building,
ISO
standard
that
uses
ontology
zazz
the
base
for
it.
So
these
are-
and
these
are
public,
because
this
particular
ISO
standard
was
designed
to
be
public
like
a
lot
of
the
ISO
work.
K
So
if
you
go
to
this
URL
you'll
get
a
sort
of
background
on
that.
What's
interesting
to
me
about
this
is
how
you
take
that
obviously,
and
try
to
do
security
with
it.
I
mentioned
these
other
these
other
ISO
standards
that
are
driving
some
of
this
work
in
2675.
This
is
an
emerging
standard,
we're
still
I
think
in
18
months
into
working
on
this
standard,
but
it's
it's
already
got
a
lot
of
content.
That's
that
might
be
of
interest
to
this
group.
K
K
One
of
the
key
use
cases
for
Big
Data
is
network
protection.
So,
if
you're,
if
you're
having
to
rent
disk
space
from
Splunk,
you
already
know
about
this
C.
So
what
we
one
of
the
contributions
I
think
of
this
report
is
we
give
them
some?
We
give
the
users
checklists,
there's
a
pretty
long
bibliography
that
they
can
go
to
that.
It's
drawn
from
you
know
both
academic
sources
and
some
industry
sources.
We
did
a
deep
dive
on
hl7,
which
is
an
at
healthcare
standard
about
how
they
manage
consent.
K
Give
you
an
idea
about
that
consent
problem.
You
know
the
Facebook
one
is
one
that's
being
talked
about
today,
but
a
bigger
problem.
Is
you
know?
How
do
you
give
consent
for
somebody
to
make
decisions
about
when
to
pull
the
cord
on
you
in
in
a
hospital
setting?
What
do
you
do
if
your
your
ex-wife,
you
know
still
has,
has
that
consent,
because
you
never
got
around
to
repealing
it?
What
do
you
do
about
information
about
people
that
are
handicapped
in
a
building
this
bring
down?
K
So
if
you're
gonna
do
risk
and
the
availability
piece
of
CIA
that
you
are
gonna
have
to
do
simulations,
so
that's
another
reason
to
have
a
model
driven
kind
of
approach
to
this,
and
what
we
did
was
you
know,
try
to
go
after
the
safety
frameworks
like
the
materials,
eighties
data
safety
standards.
If
anyone
hears
were
through
that
we,
we
treat
the
data
elements
associated
with
PII
and
PCI
on
the
way
that
people
would
with
material
data
safety
records.
K
Lastly,
we
have
this
notion
of
the
system,
communicator,
which
is
a
sort
of
standard
software
artifact
that
needs
to
be
produced
in
a
big
data
system
to
allow
it
to
communicate
to
the
various
consumers.
So
if
you
want
to
know
what,
when
did
you,
you
provide
consent
for
us
to
use
your
data
for
this?
It
remembers
the
whole
session
associated
with
you
doing
that,
and
it
has
a
natural
language
sort
of
interface
on
a
public
website
to
do
that.
So
I'm
going
to
skip
these
diagrams
in
interest
of
time.
We
can
come
back
to
this.
K
What
I
want
to
show
you
is
the
what
we
did
with
the
the
safety
conformance
levels,
so
these
conformance
levels
are
people
who
choose
to
do
so.
Okay,
and
look
at
this
document
and
say
we're
attempting
you
know,
based
on
a
self-assessment,
to
follow
a
safety
level
of
one
two
or
three.
According
to
this
nist
big
data
security
standard.
So
at
the
highest
level,
which
is
what
I
think
this
group
might
want
to
be
interested
in-
is
that
it
looks
at
automated
use
of
these
domain
domain
models
for
security
operations
and
for
the
SDLC.
K
It
pushes
security
and
privacy
risk
to
the
the
developer
environment
directly
in
likewise
to
configuration
management
and
there's
a
continuous
test
environment
to
security,
not
just
for
code
scans,
but
for
things
like
whether
firewall
ports
get
open
and
closed
and
whether
containers
are
spun
up
and
shut
down
when
they're
supposed
to
be,
and
also
pushes
the
test
case
authoring
more
to
the
the
application
side.
So
those
are
kind
of
principles
from
DevOps
and
left
shift,
but
they
are
pushed
into
the
the
safety
standard.
K
K
K
K
That,
while
there
are,
you
know,
computationally
perfectible
solutions
to
certain
parts,
the
problems
like
you
know,
closing
a
firewall
port
or
patching
say
a
struts
module
on
there.
Other
parts
of
this
that
had
to
do
with
less
less
easily
protected
elements.
That
is
why
aviation
is
safe,
because
the
whole
supply
chain
is
involved
in
the
process
of
making
it
safety
making
things
safe.
So
you
know
the
risk
management
and
safety
approach
to
this
is
is
a
bit
novel
in
the
security
space,
even
though
really
is
kind
of
an
obvious
thing.
K
K
D
F
B
B
B
K
He
was
a
little
fuzzy
about
what
his
commitment
was
in
April.
He
was
trying
to
ask
for
time
in
April
without
naming
the
date,
so
I
need
to
nail
him
down,
but
he's
a
he's,
a
cryptology
PhD
at
Fujitsu
and
so
he's
on
top
of
the
blockchain
stuff
and
some
other
things
that
might
be
of
interest.
And
you
know
the
cryptology
stuff
enters
into
a
lot
of
this
Federation
and
trust
issues
in
kind
of
insidious
ways
and
people
have.
B
K
B
Well,
we
are
barreling
towards
a
presentation
at
the
cloud
native
computing
foundation:
TOC
teksu,
the
technical
Oversight
Committee,
sorry
break
down
my
acronyms
on
the
17th
of
April,
so
I
believe
we'll
probably
need
to
focus
in
the
coming
weeks
on
preparation
for
that
right,
making
sure
that
it
that
you
know
everyone's
aligned,
all
the
ducks
in
a
row
and
we're
ready
to
put
our
case
in
front
of
the
TOC
and
get
approval.
So
we
can
begin
you
know
operating
officially
as
a
CNC
F
working
group.
B
So
let's,
let's
you
know,
set
that
aside
for
now
and
come
back
and
potentially
have
that
as
a
discussion
for
some
date
later
than
the
17th
of
April,
which
I
believe
is
a
Tuesday,
and
that
probably
means
that
the
earliest
date
we
could
consider
would
be
not
that
Friday,
because
I'd
like
to
debrief
with
everybody,
the
27th
would
be
the
earliest.
Okay.
K
B
Sure
excellent,
all
right
well,
thank
you
Mark
and
thank
you
Ray
for
for
sharing
it
excited
about
the
the
white
paper
document.
That's
getting
rolling
over
the
the
course
of
this
next
week.
If
team
members
here
can,
you
know,
have
a
look
at
that
and
I'd
really
love
to
get
some
of
those
footnotes
put
in
about.
You
know
this
being
that
you
know
called
this
and
that
and
kubernetes
and
whatnot
I
I
think
that'll
go
a
long
way
to
helping
support
that
thanks.
Everybody
lefty
next
week.