►
From YouTube: 12 Essential Requirements for Policy Enforcement and Governance with OSCAL - Robert Ficcaglia
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
12 Essential Requirements for Policy Enforcement and Governance with OSCAL - Robert Ficcaglia, SunStone Secure, LLC
An effective policy framework provides governance capabilities to Kubernetes and cloud native applications. Policy-as-code artifacts provide visibility and drive remediation for various security and configuration aspects to help Developers and Operators meet their security and compliance requirements. Working with the Kubernetes Policy Workgroup, cloud providers and tool maintainers have signaled support for OSCAL. OSCAL is a NIST control assessment syntax and model framework providing a standard set of schema for control catalogs, customization and parameterization, assessment and reporting. Using OSCAL as a model schema for control definition, we discuss the specifics of policy enforcement and management in a multi-cluster, multi-cloud environment for seamless traceability across technical configuration, organization security standards and external regulatory compliance requirements. We break down 12 specific requirements and policy-as-code practices in a highly fluid multi-cluster operating environment. Join this hands-on, live demo session to understand the battle-tested use cases, architecture, and practical implementation details, and the deployment and operational levers for managing control implementation, policy generation and assessment, and compliance reporting.
A
A
The
co-chair
of
the
kubernetes
policy
work
group
I've
been
working
for
the
last
several
years
with
the
cncf
tag
and
the
kubernetes
86
security
I
do
have
a
day
job
and
in
that
job
I
help
companies
through
their
sock,
2,
HIPAA,
Audits
and
things
like
fisma
sieges,
fedramp
and
in
that
Journey.
That's
where
I
encountered
something
we'll
be
talking
about
today,
oscow
and
then
in
my
copious
free
time.
I
do
play
a
lot
with
machine
learning
and
especially
with
graph
databases
and
you'll,
see
some
of
those
touch
points
in
the
presentation.
A
Just
a
quick
pitch
for
the
policy
work
group
itself
we
started
2019
we've
been
focused
on
what
we
like
to
call
big
p
policy
and
Little
P
policy.
So
big
p
is
kind
of
the
human
readable
human,
understandable
policy,
Concepts
and
Little
P
policy.
Is
that
configuration
policy
more
if
you're
in
the
devops
and
working
in
manifests
and
kubernetes?
These
are
the
types
of
policies
you're
probably
referring
to.
A
We
have
created
a
crd
and
we're
working
on
a
cap
for
that
that
is
aligned
with
oscow
and
I'll
get
into
what
Oscar
is
for
those
of
you
who
don't
know
and
that
helps
standardize.
The
output,
our
crd
and
cab,
is
to
help
standardize
the
output
of
various
configuration
and
policy
checking
tools
and
policy
policy
enforcement
engines.
So
you
can
get
a
consistent
aggregation
data
structure.
A
We've
done
several
white
papers
working
on
a
governance,
white
paper
and
some
of
the
folks
in
the
room
I
know
are
contributing
to
that
and
there's
been
some
open
source
dashboards
and
adapters
for
the
various
scanners
and
and
policy
Checkers
so
more
to
come.
We
are
working
as
best
we
can
with
nist
and
trying
to
do
more
with
oscow
in
kubernetes
and
provide
real
world
examples.
A
And
of
course
many
of
you
might
be
aware
of
a
common
expression.
Language
cap
that
was
recently
I-
think
it's
Alpha,
maybe
it's
beta
anyway.
It's
a
a
new
expression
language
for
admission
control.
In
kubernetes,
so
we're
definitely
trying
to
drill
down
on
what
we
can
recommend
around
using
that
best
practices
patterns
Etc.
A
So
let's
jump
into
this
talk,
though,
so
all
of
you
are
probably
familiar
if
you're
at
this
talk
with
basic
policy
questions,
so
these
are
questions
that
you
probably
deal
with,
especially
managing
a
team
or
interacting
with
Auditors
or
compliance
subject
matter
experts.
These
are
the
type
of
questions
you
might
get
at,
that
big
p
policy
level
about
your
kubernetes
cluster
or
even
your
infrastructure
as
code
or
infrastructure.
A
Broadly
I
would
like
to
highlight
the
last
point,
because
I
hear
this
even
most
recently
on
a
call
today
with
a
bunch
of
agency
folks,
a
bunch
of
audit
folks,
you
know,
there's
there's
this
lack
of
trust
in
what
they
see.
What
the
data
they're
presented
with
is
the
documentation,
and
so
you
know
this
is
a
foundational
concern
for
how
can
you
build
a
governance
program
around
your
policies
and
controls
which
we'll
get
into
and
build
that
trust
so
that
they
can
trust?
How
you're
presenting
the
system
to
the
auditor?
A
You
know
what
your
workloads
are
doing
in
Aggregate
and
how
you're
isolating
those
how
you're
defining
Network
policies
around
those
you
may
be
interested
in
verifying
the
identity
and
contents
of
those
workload
images.
So
these
are
the
the
policy
Little
P
policy
issues
that
we'll
be
wrestling
with
and
then
again,
I'll
call
it
that
last
as
as
kubernetes
itself
is
deploying
kubernetes
and
deploying
infrastructure
as
code
and
is
becoming
kind
of
a
meta,
provisioning
or
meta
admin
entity.
A
My
basic
view
of
how
I
look
at
the
the
model
here
is
we're
going
to
stick
to
that
declarative
configuration
idea
that
kubernetes
brought
to
the
Forefront
wasn't
the
first,
but
but,
as
certainly
arguably
been
the
most
successful
and
I
apply
that
in
in
the
realm
of
compliance
by
comparing
what
you
might
be
able
to
do
with
Git
Ops
and
what
we,
what
I
have
seen
done
with
githubs
versus
what
a
traditional
GRC
that
is
is
the
de
facto
reality
today.
So
I'll
talk
a
little
bit
more
about
what
that
future.
A
State
might
look
like,
so
a
obligatory
slide
on
what
oscow
is,
if
you,
if
you're
here
you
might
know
a
little
bit
but
Oscar,
is
an
initiative
from
nist
they've
been
developing
a
standardized
schema
for
expressing
controls.
So
these
are
configuration
checks
or
requirements
at
the
framework
level
for
what
you
must
do
as
a
system
owner
or
a
system
implementer
to
make
sure
that
you
conform
with
something
like
nist
853.
A
It's
not
necessarily
specific
to
nist
853
or
any
particular
compliance
framework,
but
they
they
are
a
niche,
so
they
started
with
that
and
it
has
a
broad
Acceptance
in
the
U.S
federal
government
and
even
elsewhere
in
in
healthcare.
High
trust
is
also
based
on
this
inter53,
so
it's
a
good
place
for
them
to
have
started
and
they
essentially
layer
on
different
schema
models,
a
catalog
of
all
the
controls
that
you
might
need
to
apply
to
your
system,
a
profile
we'll
talk
about
what
that
is.
A
A
component
model
is
kind
of
the
functional
things
in
your
system,
the
the
elements,
the
the
subsystems
you
have
to
coalesce
all
this
into
a
system
security
plan
now
and-
and
today
before
things
are-
are
all
git
Ops
and
automated.
The
system
security
plan
might
be
a
thousand
page
Word
document
that
expresses
all
of
the
diagrams
and
all
the
controls
that
you
have
collected
from
your
catalog
and
your
profile,
and
you
know,
verbose
human
descriptions
of
how
all
of
those
controls
are
implemented.
A
So
one
of
the
goals
is
to
put
that
in
machine,
readable
format
and
then
allow
organizations
to
exchange
that
internally
with
Auditors
reuse,
that
system
security
plan
to
get
authorizations
to
deploy
a
system
and
then
quickly,
just
Auditors
have
to
be
able
to
assess
this.
So
you
need
an
assessment
plan
and
then,
after
you've,
scanned
things,
you're
producing
an
assessment
result,
essentially
a
report
and
then
you'd
have
to
track
track
your
risks.
So
they
have
a
plan
of
action
Milestone.
A
So
those
of
you
familiar
with
the
government-led
kanman
activities
and
know
and
love
poems
and
managing
those
risk
logs
it.
Just
the
every
ASCO
file
has
a
hierarchical,
a
set
of
elements,
lots
of
linking
across
different
elements
and
they
have
a
universal,
unique
ID.
That
is
essentially
the
the
identifier
that
you
can
link
across
components
too,
and
you
can
add
various
supplemental
router
in
the
back
manner.
So
when
you
kind
of
merge
kubernetes
policy,
both
kind
of
the
big
p
and
Little
P
policy
with
Oscar
you,
you
get
essentially
a
compliance's
code.
A
If
you
can
express
your
system
in
a
machine,
readable
oscow
form-
and
you
can
merge
that
we'll
talk
about
various
ways-
merge
that,
in
with
your
policy
as
code
and
all
that
is
very
traceable.
Now
you
get
compliances
code
and
you
have
a
governance
structure
that
is
standardized
and
reusable
and
shareable
and
auditable,
and
just
to
call
out.
You
know
the
policy
report
CR
that
I
mentioned
earlier.
We
align
that
with
oscow
and
red
hat
and
IBM
contributed
some
code
to.
You
know
extract
from
that
an
oscow
assessment
report.
A
A
Related
projects
call
out
some
of
the
folks
from
defense
unicorns
who
are
working
on
open
source
as
well,
both
with
a
tool
they're
they're
building
in
the
caverno
open
source
engine,
and
then
myself
and
a
number
of
the
cncf
projects
are
open,
sourcing,
more
oscow
and
more
tooling,
around
oscow,
and
we
call
that
sledgehammer
local
education,
government,
Enterprise
and
health
care,
so
not
necessarily
specific
to
government,
but
highly
aligned
and
likeness
we'll
be
focusing
on
this.
853
and
I've
got
a
link
at
the
end
of
the
slide
to
that.
For
those
who
are
interested.
A
If
you
don't
know
why
you
would
need
to
manage
your
policies,
then
you
may
not
have
tried
to
run
a
kubernetes
cluster
under
a
compliance
regime
like
you
know,
fedramp
or
fisma
over
time.
These
policies
change
the
requirements,
change
incidents,
happen,
vulnerabilities
happen,
and
so
you,
you
have
to
be
proactive
in
how
you
govern
and
create
and
curate
these
policies
reacting
to
that.
A
It
just
amplifies
the
problem,
and
so
you
know,
especially
if
you're
talking
about
making
changes
to
kind
of
a
steady
stream
of
vulnerabilities,
you're,
never
going
to
catch
up,
I
think
again,
situations
almost
on
a
daily
basis
where
folks
are
trying
to
exchange
information
securely
and
is
that
again
sending
an
Excel
file
or
sending
a
Word
document
sending
yaml
or
Jason
I
mean
this
across
boundaries
across
agencies
across
organizations
or
may
or
may
not
have
different
levels
of
clearance.
You
know
this
is
a
real
problem,
so
you
know
having
a
standard
format.
A
They've
been
exchange
over
apis
is
very
important.
I
I
guess
last
point
there.
I
don't
have
to
convince
anybody
that
you
know
it's
much
more
cost
effective
to
identify
where
your
policies
are
going
to
need
to
change
and
control
that
change
early
in
the
process
than
later
when
you're
trying
to
operate
under.
You
know,
time
pressures
and
cost
pressures,
and
everything
has
to
be
reported
out
on
those
monthly
con.
One
calls
yeah
and
policy
at
large.
It
gives
you
you
know
consistency.
The
policies
code
gives
you
guard
rails,
I.
A
Think
most
of
you
have
seen
this,
and
there
are
various
reasons
that
you
want
to
centralize
controls
the
wrong
word,
centralized
governance
of
of
those
policies,
so
you
have
consistency
across
your
workload,
identities,
your
access
and
then
again,
this
notion
of
having
a
continuous
assessment
of
those
controls
and
those
implementations
and
and
another
number
of
other
things
here.
I'll
the
interest
of
time
skip
forward
and
then
I
think
one
one
real
world
problem
that
that
I
see
often
is
that
you
know,
as
their
kubernetes
clusters
grow.
Certainly
the
apps
in
those
clusters
grow.
A
A
Obviously,
we'll
have
benefits
on
the
tail
end,
especially
as
you
start
talking
about
secops
and
incident
response,
but
it's
not
always
a
silver
bullet
and
it's
not
always
fun
I'm
gonna.
Let
everyone
take
a
deep
breath
and
kind
of
Channel
their
inner
Bob
and
before
I
show
you
what
I'm
calling
the
the
compliance
canvas
and
we'll
dab
and
take
from
the
the
palette
and
as
we
kind
of
work
through
this
mess,
but
at
a
high
high
level
you
kind
of
want
to
understand
your
system
from
the
user
view.
A
So
you
know
on
that
left.
You've
got
the
mission.
You
know
how
are
we
going
to
accelerate
this?
You
know,
then.
We
have
to
worry
about
our
threats
and
I'm
going
to
talk
through
each
of
the
different
policy
Ops
that
we
observe
as
being
essential
and
make
sure
that
we
cover
at
least
some
high
level.
It's
it's
going
to
be
impossible
to
go
through
all
the
Deep
Dives
and
talk
through
various
concrete
examples
and
everything,
but
I'll
try
to
call
it
a
couple
and
then
on
the
bottom.
A
You
know
the
substrate
is
you
know,
as
oscow
tooling
becomes
better,
so
whether
it's
through
the
policy
work
group
or
some
of
the
other
open
source
projects,
I
mentioned
or
commercial
tools,
the
tooling
is
going
to
enable
the
generation
and
consumption
of
these
various
models.
The
catalogs,
the
you
know,
component
definitions,
we'll
talk
about
different
variations
of
that
and
then
ultimately
kind
of
that
system.
Security
plan
really
System
model
becomes
I,
think
the
central
governing
resource
that
that
unifies
everything
together
and
in
terms
of
security
operations.
Those
you
know
the
assessment
plan
assessment
results.
A
A
So
let's
talk
about
these
essential
ingredients
that
I've
called
out
so,
first
and
foremost
you
you
have
to
collect
and
curate
a
policy
library
right
and
and
this
very
much
maps
to
your
control
catalog.
That's
that
oscow
artifact
for
enumerating
all
the
different
controls
and
different
families
or
groups,
and
we'll
talk
a
little
bit
more
about
the
profile.
A
But
essentially
it's
a
a
tailoring
of
the
different
controls
that
you
might
have
under
different
Frameworks
or
for
different
systems
or
for
different
use
cases,
and
you
can
parametrize
that
the
current
benchmarks,
like
CIS,
even
some
of
the
more
cloud-specific
benchmarks,
are
useful
fodder
for
starting
this
curation
process.
They've
typically
mapped
all
their
Cloud
specific
or
kubernetes
specific
controls
to
an
sc853.
A
You
know:
eks
AKs,
Google,
config
they've,
all
done
some
mapping
to
initi853,
but
more
broadly,
they've
mapped
it
to
other
control
catalogs
via
PCI
or
others.
So
that's
a
great
way
to
kind
of
bootstrap
your
your
catalog
review
process
and
start
using
the
tooling
to
generate
oscow
catalogs
and
then
in
those
control,
sets
you're
going
to
obviously
look
at
preventive
controls.
Detective
controls
I'll
have
a
little
bit
more
about
the
kind
of
threat
modeling
around
that
and
ideally
again
getting
back
to
that
idea
of
git
Ops
versus
GRC.
A
All
of
this
is
being
managed
from
day
one
in
git
repo
you're
managing
PRS
to
change
the
oscow
catalogs
to
manage
your
profiles,
and
you
know
there
may
be
some
challenges
with
mono
repos
for
those
of
you
who
love
those
I.
Don't
recommend
that
folks
de
novo
create
policy
from
scratch
copy
and
paste
when
you
can.
There
are
various
strategies
for
this.
This
should
be
maybe
a
commonplace
for
kubernetes
resources
or
manifest
themselves.
So
the
different
mechanisms
of
the
the
policy
engine
support
the
policy
languages
and
then
there
are
different,
API
and
tooling
Frameworks.
A
Those
can
be
defined
at
deploy
time
or
at
even
post
to
play,
and
so
in
support
of
that,
you
know
all
of
the
major
policy
enforcement
engines
and
languages
support
some
form
of
some
form
of
templating
with
parameters.
So
gatekeeper
has
a
constraint.
Template
allows
you
then
Define
constraints
that
invoke
specific
parameter,
oops,
parameter
values.
Caverno
has
rules
that
support
kind
of
open,
API,
V3
and
ocm,
which
is
a
open
source.
Cluster
management
project
has
policy
templates
as
well.
A
Now
that
you've
got
kind
of
all
these
templates
and
parameters.
You've
got
to
kind
of
bind
it
together.
It's
what
I
call
policy
assembly,
so
you
can
map
controls
and
the
example
I'll
show
you
is
kind
of
mapping
it
to
threat
indicators,
so
you
can
annotate
your
controls
with
threats.
You
can
then
annotate
your
policies
by
mitigating
different
threads
right
and
then
that
way
you
can
kind
of
use
that
to
to
bind
the
two
together.
A
Let
me
just
see
if
this
will
cooperate
just
to
show
you
kind
of
what
that
could
look
like.
So
here
those
of
you
are
familiar
with
Rego,
it's
from
the
open
policy,
so
it
essentially
just
trans.
You
can
think
of
Rego
and
opa.
As
transforming
you
know,
one
Jason
to
another
Jason
right,
so
here,
for
example,
you
might
have
your
control
catalog,
and
this
is
very
kind
of
demo.
A
Oscow
pseudo-osco
I'll
call
it,
but
this
is
a
kind
of
a
typical
Json
look
for
what
a
control
might
look
like
and
then
what
we've
done
is
we've
broken
it
out
into
different
components,
and
some
of
those
components
are
functional
components,
but
some
of
those
components
we
actually
Define
as
security
capabilities.
So
there's
a
good
publication
if
you've
never
read
it.
Nist
IR
8011
goes
into
great
detail
around
this,
but
you're
defining
you
know
the
the
capabilities.
A
The
security
features
that
you
would
need
to
implement
this,
so
encryption
could
be
one.
Our
back
could
be
one
right
checking
integrity.
He
could
be
one
signature,
verification
in
this
case.
You
know
you
have
something
like
preventing
unauthorized
containers.
You
would,
you
know,
connect
that
to
different
threat,
IDs
or
TTP
name.
Hopefully
you
can
see
that
mitigation,
a
defensive
techniques
like
execution
prevention
and
then
you'd
map
that
up
with
your
controls.
So
let
me
just
go
to
the
next
set:
here's
where
I
was
talking
about
kind
of
mapping
with
heuristics
or
you
can
use.
A
You
know
different
types
of
modeling
for
threats,
but
you're
going
to
want
to
Define
in
in
Rigo
your
different
threat
scoring.
You
know
that
heat
map,
and
then
you
can
actually
Express
how
you're
doing
that
threat
mapping
in
code
right.
So
here
you're
looking
now
this
is
fairly
demo
hard-coded,
but
you
can
easily
call
this
from
external
data
or
call
an
API
but
you're.
Looking
for
a
specific
set
of
ttps
and
you're,
you
know
matching
that
up
to
the
security
capabilities
and
controls,
and
then
you
can
classify
that
further
into
you
know.
A
Is
this
a
product,
a
protective
control?
Is
this
a
detective
control,
or
is
this
a
responsive
control
right
and
then
you
can
map
that
to
your
your
particular
framework
and
then
after
you
have
that?
Where
is
the
sorry
yeah?
You
can
add
some
validation
rules
askal.
This
was
fairly
new,
I
think
in
the
last
four
or
six
months
the
validation
rules
has
become
a
new
part
of
the
schema
and
then
I
think
if
I
run
this,
let's
see
yeah.
So
here
now
on
the
output
side,
it's
it's
spitting
out.
A
What
would
be
components
that
you
would
insert
into
your
oscow?
You
know
typically
as
a
component
model
and
then
ultimately
will
generate
a
full
SSP
in
The,
Next
Step,
but
here
you're
you're
describing
how
you
enumerated
the
protect
the
respond,
the
different
rules
that
were
triggered,
and
then
you
know
what
the
threat
coverage
might
be,
and
you
know
you're
feeding
that
into
the
SSP
here.
A
What
were
my
big
p
policy
requirements?
What
rules
did
I
use
to
actually
determine
that
this
threat
and
this
capability
match
that
control?
And
then
you
know,
I
get
an
actual
oscow,
readable
definition
of
that
control
implementation
and
then,
at
the
very
end,
you
put
all
that
together.
You
can
actually
use
that
to
generate
your
assessment
plan,
and
so
this
again
as
another
oscow
artifact
gets,
gets
you
to
the
audit
phase,
where
now
you're
defining
how
am
I
mitigating
those
threats.
A
How
are
those
controls
providing
that
implementation
and
how,
as
a
tester,
can
I,
you
know,
write
validation,
rules
to
support
that
so
and
I?
Just
as
an
aside,
that
is
the
one
cool
thing
about
Rigo
that
I
like
is
it's.
It
can
generate
Jason
from
Json.
It
can
generate
Rigo
from
Rigo,
so
just
something
you
guys
might
be
interested
in
in
other
use
cases.
A
So
let
me
go
back
to
the
the
palette
here.
We
talked
about
those
profiles
and
and
base
and
parameters.
I.
Think
the
the
thing
to
call
out
all
of
the
languages
and
engine
support
some
sort
of
variabilization
parameterization,
but
again
managing
the
variables
gets
very
complex,
very
quickly
as
well.
So
while
what
helps
bend
that
Fibonacci
curve,
it
can
quickly
get
too
out
of
control.
I
wish
there
was
a
silver
bullet
answer
for
that.
A
I
think
it's
something
we
still
wrestle
with,
because
I've
seen
templates
that
are
just
nothing
but
variables,
and
it's
like
how
how
readable
is
that?
How
maintainable
is
that
you
obviously
want
to
do
policy
validation,
like
any
other
coding
exercise,
you
want
to
do
local
tests.
You
know
caverno
Opa
gatekeeper.
A
You've
got
to
distribute
this
out
and
again
Opa
gatekeeper,
governo
others
do
support
either
an
oci
bundle
or
you
know
kind
of
not
proprietary,
but
they're
Project
Specific
bundling.
You
could
obviously
manage
all
these
things
in
git
I.
Think
again,
it
goes
back
to
that
branching
strategy
and
you
know
how
how
you're
going
to
connect
that
up
to
your
policy
enforcement
point.
A
I'd
say
you
know:
oci
bundles,
probably
the
thing
I'd
recommend
sorry
ocm
has
their
version
of
this
was
just
placement
and
they
have
a
policy
generator
component
and
then
there
are
Cloud
specific
ways.
You
can
do
this
again:
Google
config,
you
can
use
S3
as
that
bucket
for
from
pulling
everything
from
get
into
the
bucket
and
then
Oppa
and
caberno
can
pull
it
from
there
and
there's
an
Azure
policy
extension
as
well.
A
I
would
note
that,
as
you
distribute
out,
policy
be
sure
to
sign,
digitally
sign,
cryptographically
sign
and
then
make
sure
verification
happens,
that
the
engines
support,
caverno,
oppa
I
should
say
opa
at
least
gatekeeper
support
it
all
of
the
engines
support
some
form
of
enrichment
where
you
can,
instead
of
statically
as
I
shoot
in
My,
Demo
statically
saying
you
know,
I'm
looking
for
this
TTP
idea,
I'm
looking
for
this
resource
attribute
I'm.
Looking
for
this
namespace
label
right,
you
can
you
can
pull
external
data
and
enrich
the
decision-making
process.
A
There
are
various
ways
to
do
this
kind
of
similar
to
the
policy.
Bundling
itself
you
can
you
can
layer
it
in.
You
can
have
separate
bundles.
You
can
put
into
Secrets
but
I
think
the
the
interesting
thing
in
kind
of
real
world
situation
is
that
you
can.
If
you
have
a
multi-tenant
environment,
a
multi-cluster
environment,
you
can
now
really
tailor
those
policies
to
different
deploy,
time
and
even
operational
time
policy
choices.
So
this
becomes
a
big
thing.
A
If
you
know
those
of
you
who
have
wrestle
with
say
data
isolation
for
gdpr
and
you
know
across
different
country
boundaries.
This
is
a
very
helpful
pattern
to
use
the
policy
assessment,
reporting
I
think
there
are
lots
of
tools
out
there.
We
obviously
as
a
publisher
work
group
like
the
ones
that
support
the
policy
report.
Cr
and
we've
tried
to
build
some
adapters
for
those
that
don't
have
it
we're
trying
to
get
it
into
that
cap.
So
hopefully
it
will
become
a
standard,
kubernetes
API,
and
then
everything
will
support
it.
A
There
are
Prometheus
metrics
other
ways
to
manage
your
assessment,
execution
and
aggregate
data
about
what
is
what
violations
you
have.
We
did,
as
I
mentioned,
there's
an
open
source
policy
dashboard,
but
there
are
a
number
of
of
other
open
source
and
Commercial
dashboards
that
can
roll
up
the
policy
violations
and,
as
oscow
support
becomes
more
prevalent
in
things
like
EMASS
other
grc's.
We
expect
to
see
more
of
that
display.
The
dashboard
display
of
your
assessment
results.
A
A
But
I
think
you
know
you
can
you
can
use
that
policy
report
output
or
the
gatekeeper
audit
output?
And
you
can
then
you
know,
generate
PRS,
and
then
that
would
create
new
Sandbox
rules.
Network
policies,
you
can
add
different
labels
in
response
to
different
attack
indicators
through
admission
control,
mutation,
yeah
and
then
you're.
Obviously,
gonna
have
to
track
your
your
poems
and
risks
over
time.
A
You
know
there
are
some
cross-cutting
concerns
that
that
will
obviously
be
touch
multiple
parts
of
that
policy
management
process.
So
you
know
those
heuristics
that
I
mentioned
you
know
they
really
do
cover
the
whole
miter
attack
framework,
so
you're.
Looking
at
this
some
you
know
slice
through
many
different
pillars.
It's
not
always
kind
of
neat
and
compartmentalized,
where
you
can
build
a
policy
snippet
for
you
know
your
your
volumes
and
a
policy
snippet
for
image
management.
A
A
lot
of
these
are
going
to
have
cross-cutting
concerns
and
and
this
where
having
a
good
model,
to
drive
that
that
policy
generation
helps.
So
you
know
static
analysis
very
infrequently,
but
starting
to
see
some
interest
in
formal
methods.
For
that
my
personal
area
is
graphs
and
kind
of
using
ml
to
do
graph,
embeddings
and
graph
mappings
and
actually
even
a
lower
level
model.
Large
language
models
from
machine
learning
have
actually
been
recently
shown
to
to
be
able
to
model
out
different
attack
paths
and
defense
sequences.
So
that's
interesting
area
research.
A
A
Oscar
is
new
for
everybody,
but
the
audit
Community
is
not
well
tuned
and
ready
to
receive
oscow,
and
certainly
not
in
a
kubernetes
cluster
environment,
right
or
Cloud
native
environment.
Even
so,
we're
hoping
that
this
will
be
a
resource
for
Auditors
and
if
there
are
any
in
the
audience,
please
I'd
love
to
talk
to
you,
but
getting
them
trained
up
and
familiar
with
oscow
with
kubernetes
and
Moscow,
and
then
how
to
consume
these
artifacts
and
with
that
I
will
open
it
up
to
questions.
A
A
Will
Oscar
home
library
is
that
I
I
think
so
I
think
there's
going
to
be
a
lot
of
competing
approaches.
You
know
everybody's
looking
at
the
same
problem
and
feeling
it
from
different
perspectives,
and
so
there
will
be
a
lot
of
competing
ideas.
Oscow
is
is
very
new.
It's
very
open
developers
are
very
flexible,
I
think
in
a
very
specific
segment.
I.E
government
has
a
very
strong
endorsement
and
that
nist
is
the
standards
body
that
most
agencies
use
and,
and
you
know,
I,
don't
think
it's
in
any
surprise.
A
Anyone
that
fedramp
is
a
very
popular
framework
for
cloud
Based
Services,
the
government
is,
are
procuring
and
fedramp
has
officially
adopted
oscow
as
its
emerging,
and
you
know
very
soon
required
format.
So
I
think
that
the
vendors,
the
open
source
projects,
Enterprises
homegrown,
if
you're
going
to
play
in
that
area,
you're
going
to
have
to
embrace
oscow,
but
the
good
news
is
they're
very
flexible.
A
So
lessons
learned
from
other
projects
and
other
approaches
should
be
incorporated
in
that
and
I
think
they
would
welcome
that
from
the
cncf
policy
work
group
I
mean
we're
we're
agnostic
to
you,
know
the
tooling,
the
the
specific
Frameworks.
But
again
we
just
look
at
oscow
as
a
very
nice
fit
to
the
problems
that
come
up
in
our
work
group.
A
A
I
I
see
if
I
can
go
back
and
if
it
will
pull
up
here
and
if
it
will
show
yeah
okay.
So
here
he
goes
we're
going
to
re-home
that
that's
in
my
current
GitHub,
so
we'll
we'll
when
we
file
the
sandbox
ticket
we'll
be
putting
in
another
kind
of
a
DOT
org
or
dot
IO.
But
oh
gosh,
it's
looking
be
readable,
probably
not
but
yeah.
A
So
essentially
we
want
to
deliver
all
the
oscow
and
and
any
tooling
that
we
create
or
any
you
know,
configuration
for
other
open
source
tools,
so
that
one
could
in
theory,
generate
all
the
oscow
or
use
the
templates
that
we
create
apply
it
to
a
fairly
vanilla,
kubernetes
cluster
and
then
use
that
either
in
an
agency
or
as
a
host
and
go
through
an
audit.
And
like
say
we
plan
to
put
as
much
as
we
can
from
a
real
world
third
party.
You
know
they
call
three.
A
We
call
them
three
Pals,
a
third-party
audit
organization
as
much
of
those
artifacts
out
onto
the
open,
repo
de-identified
from
any
actual
IP
addresses
or
sensitive.
You
know
vulnerabilities
output
Etc
so
that
in
theory,
especially
agencies,
we
talk
to
a
lot
of
agencies
who
are
just
getting
caught
up
on
devops
right
and
getting
their
head
draft
around
how
to
do
kubernetes
at
all
the
lift
to
go
from
nothing
today
or
very
little
today
to
a
full.
A
You
know:
reliable
production-ready,
kubernetes
operation
is
pretty
huge,
both
in
terms
of
staff
and
and
money,
but
really
it's
staff,
so
they're
looking
for
a
bit
more
of
an
easy
button
that
they
can
say,
give
us
some
some
best
practices
that
we
can
take
and
play
with
in
our
lab.
Or
you
know
another
ATO
cloud
provider
can
deploy.
You
know
again
similar
to
Platform
One
platform.
One
is
you
know,
pretty
restricted
and
who
can
use
it
and
it
has
some
significant
costs
which
again
May
price
out
some
of
the
smaller.
A
You
know,
Civ
agencies
so
I,
again,
I,
wouldn't
and
I
would
just
as
a
coder
to
that.
I
wouldn't
see
this
as
being
competitive
in
any
way.
I
think
it's
more
a
way
for
someone
to
dip
their
toes
to
really
understand
what
they're,
what
they're
getting
into
and
then
make
a
very
informed
decision.
You
know
maybe,
with
a
couple
of
pilot
projects,
get
success
and
then
say:
okay,
we
want
to
go
to
platform
one.
We
want
to
go
to
a
commercial
kind
of
software,
Factory
devsecops
platform,
engineering
substrate.
A
Now
we
know
what
we're
getting
into
and
more
important.
You
know
our
AO,
our
our
authorization
folks
know
what
to
expect
and
how
to
consume
that
Osco.
We
know
if
our
GRC
can
support
it,
so
they
do
the
discovery
with
Sledgehammer,
get
get
really
comfortable
with
the
the
operating
model
and
then
can
scale
up
onto
something
more
I
guess
you
know
Enterprise
scale
or
Enterprise
grid.
A
Maybe
to
answer
your
question:
deploy
the
cluster
run,
the
the
oscow
generation,
which
then
will
generate
the
Little
P
policy
run
your
your
conf
test
for
lack
of
a
better
word,
your
assessment
and
then
generate
your
your
SAR
and
then
figure
out
what
you
have
to
fix.
Could
that
be
done
in
GitHub
actions?
Or
you
know
some
some
other
CI,
CD
or
Argo
sure
I?
Don't
see
why
not?
So
as
long
as
because
it's
going
to
be
generated
code
as
much
as
possible
through
the
idea.
Is
that
it?
A
A
A
So
we,
if
you
can
model
the
specific
you
know
of
a
particular
framework
map,
that
to
your
threats
right
so
tdps
or
you
can
use
other
Frameworks,
but
specifically
right,
annotate,
those
to
specific
threats
and
on
the
mitigation
side
right,
you
you're,
annotating,
those
with
specific
Medicaid
mitigation
techniques,
defense
techniques
right
then
all
you
have
to
do-
is
maintain
that
mapping
of
these
these
threats
are
mitigated
by
these
defense
techniques
and
of
course,
miter
is
doing
that
for
you,
if
you're
using
their
framework
right.
So
that
becomes
the
glue.
A
So
if
you
want
to
drop
in,
if
I
understood
your
question,
if
you're
dropping
in
PCI,
you
want
to
drop
in
HIPAA
as
long
as
you've
annotated
your
requirements
and
then
the
specific
controls
for
those
requirements
with
those
threads.
Then
in
theory,
you
can
just
assemble
the
oscow
on
the
policies
from
from
that
mapping
of
threat
to
defense
IDs.
A
We
just
kind
of
added
extra
properties
to
the
oscale
yeah,
so
we
could,
but
we
should
maybe
submit
a
PR
to
get
that
formalized
we're
still
just
we
want
to
get
more
Comfort
again
through
the
sledgehammer
real
world
testing.
Before
we
probably
stand
up
and
say
this
is
the
exact
way
to
do
it,
let's
codify
it
in
oscom
I
know,
you've
had
your
hand
of
contacts.
A
A
Once
we've
got
that
full
oscow
component
model
the
policy
libraries
and
we
can
demonstrate
you
know
how
those
are
actually
running
so
I
think
I.
Hope
that
answers
your
question.
Basically,
we
need
a
little
bit
of
Dev
time
from
the
team
and
you
know
go
through
some
some
reviews
of
what
the
Oscar
looks
like
for
their
project.