►
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.
Delivering Secure Healthcare Applications with OSS - Robert Wood, Centers for Medicare and Medicaid Services (CMS) & Gedd Johnson, Defense Unicorns
Every year the Centers for Medicare and Medicaid Services (CMS) spends thousands of engineering hours to ensure its hundreds of applications are compliant with healthcare-specific security controls. The vast majority of this work is redundant across app teams and the complexity is magnified due to a lack of standardization amongst deployment strategies and technology decisions. This talk will highlight the effectiveness of using exclusively OSS to build, deploy and accredit a secure, standardized K8s-based platform in regulated cloud environments at CMS. The presentation will cover OSS technical implementation, how it achieves security requirements and the culture change that is necessary to utilize open source effectively. The goal of this talk is to share, collaborate, and learn how open source software enables teams to deliver secure, OSS platforms in regulated environments.
A
Good
morning,
everyone
almost
lunch
time
and
I
just
want
to
say
thank
you
for
taking
the
time
to
come
here
today.
We're
going
to
be
talking
about
this
platform
as
a
service,
abstraction
known
affectionately
as
Batcave,
and
we're
going
to
be
talking
about
how
it
is
used
in
one
of
the
largest
Federal
Healthcare
organizations,
one
of
the
largest
federal
agencies.
But
specifically,
we
are
focused
on
delivering
Health,
Care
oriented
applications
and
and
how
we're
doing
our
software
security
supply
chain
security.
B
A
And
so
CMS
for
anyone
who
is
not
familiar
with
it,
it
is
the
centers
for
Medicare
and
Medicaid
services.
So,
basically,
what
we
do
is
we
manage
the
back
end,
the
payment
backbone
for
all
the
payments
that
flow
through
the
Medicare
and
Medicaid
systems,
along
with
some
other
supporting
programs
like
chip,
which
is
a
focused
on
childhood,
or
a
child
Insurance
programs.
A
We
do
clinical
clinical
standards
for
hospitals
across
the
U.S,
all
like
6,
000
or
so
of
them,
and
as
well
as
a
bunch
of
other
things,
and
so
all
in
all,
our
programs
cover
over
130
million
people
across
the
U.S,
which
is
a
pretty
decent
amount
of
Phi
pii,
just
sensitive
stuff
that
we
have
to
make
sure
we
are
protecting.
So.
A
As
you
might
imagine
doing
that
at
scale
inside
the
federal
context
comes
with
challenges,
there
are
challenges
from
the
federal
compliance
standpoints.
You've
got
fedramp,
you've
got
atos,
you've
got
lots
of
bureaucracy,
you
know
it's
it's
almost
it's
almost
a
meme
or
I'm
sure
people
have
meme
that
all
of
the
all
of
the
red
tape
that
you're
kind
of
swimming
through
to
do
anything
in
a
large
Enterprise,
let
alone
the
largest
Enterprise
in
at
least
the
country
potentially
the
world.
That
is
the
U.S
federal
government.
A
And
so
you
know
we
have
a
lot
of
developers,
thousands
of
developers
all
working
across
different
parts
of
the
organization.
It's
Federated.
It's
disconnected
Loosely
coupled
different
missions,
different
priorities,
all
of
that
stuff
and
there's
a
lot
of
a
lot
of
waterfall
development
still
happening.
A
We're
aiming
to
actually
enable
faster,
more
efficient,
more
secure
software
development,
so
our
solution
or
part
of
our
solution
to
this
problem
is
the
bat
cave
which,
because
every
good
government
program
needs
an
acronym,
it
is
the
continuous
authorization
and
verification
engine
we
just
needed
something
that
mapped
to
something
fun
and
exciting
for
Branding
purposes.
So
that's
what
we
came
up
with,
and
so
this
is
really
CMS
has
one
of
the
largest
cloud
footprints
in
the
world,
mostly
on
AWS
I'm
on
Azure,
and
so
there
is.
A
There
is
a
very
large
Cloud
footprint
that
we're
already
working
with,
and
the
Batcave
is
really
an
opinionated
abstraction.
On
top
of
the
CMS
Cloud
program,
that's
Tech!
That's
process,
that's
onboarding!
That's
people!
That's
policy!
All
of
that,
but
it's
an
opinionated
abstraction
trying
to
alleviate
some
of
the
the
double
work
and
and
leg
work
and
prep
work
for
compliance
and
authorization
processes
that
people
have
to
go
through
in
order
to
get
something
done
and
built
on
like
inside
of
the
the
Enterprise
and
so
some
of
our
goals.
A
We
have
many,
but
we
want
to.
We
want
to
help
people
move
faster.
Naturally,
we
want
to
help
people
do
it
more
securely.
Naturally,
we
want
to
make
sure
that
things
are
compliant,
because
we
have
office
of
inspectors,
General
to
reckon
with
and
Audits
and
and
all
of
this
stuff
that
we
have
to
deal
with.
That's
all
important
in
the
federal
context,
but
really
at
the
end
of
the
day,
if
I
could
draw
your
eyes
to
the
bottom.
Right
of
this
slide
is
about
empowering
and
enabling
continuous
delivery.
A
Like
true
continuous
delivery
in
the
federal
context.
Not
we
want
to
deliver
something
so
we're
going
to
pause
and
wait
a
month
and
do
a
security
impact
assessment
and
make
sure
we
do
a
controls
like
a
mini
audit.
That's
not
continuous
delivery,
like
you
need
to
make
a
change
because
log4j
just
came
out.
You
know,
like
the
log
for
Shell
issue,
just
got
released
and
you
need
to
change
your
application
right
now.
A
We
want
to
be
able
to
do
that
without
the
bureaucracy
getting
in
the
way,
so
Tech
supported
and
process
supported,
so
I
want
you
to
kind
of
rewind
yourself
in
time
back
to
like
March
2020.,
so
we're
all
sitting
around.
Maybe
we're
in
an
office,
maybe
you're.
You
know,
you're
out
at
the
mall
you're
out
at
a
bar
and
covid-19
is
just
starting
to
kind
of
float
around
the
world.
That's
coming
to
the
US.
A
It's
there's
like
10
to
20
cases
and
then
the
White
House
issues,
a
decree
Nationwide
shutdowns,
Nationwide
shutdowns
everything
is
going
into
lockdown
mode,
so
businesses
stop
businesses,
stop
bringing
people
in
all
of
that.
Stuff
happened
really
really
fast
worldwide,
especially
in
the
US
and
so
now
imagine
you're
inside
of
a
federal
agency,
and
you
want
to,
like
you,
have
a
responsibility,
an
imperative
to
start
contributing
to
the
problem
to
the
solution
in
some
meaningful
way.
A
So
you
go
through
and
you
do
your
ideas,
you
start
generating
things
and
in
the
federal
contact,
at
least
in
CMS,
we
are
heavily
supported
by
contract
partners
and
so
to
get
to
a
contract
partner.
You
can't
just
you
can't
just
sign
up
with
a
credit
card.
You
actually
have
to
prepare
a
proposal
like
a
procurement
package.
Put
it
out,
people
have
to
submit
bids
to
it
all
of
it
like
that
is
a
whole
long
process
in
and
of
itself.
A
You
kind
of
keep
evolving.
Now,
let's
say:
you've
awarded
your
contract
you're
starting
to
do
design
work
and
onboarding
people
and
background
checking,
and
the
contractors
then
hiring
the
folks
that
are
going
to
staff
the
project
and
you're
starting
to
really
like
this
idea
is
really
starting
to
come
together,
and
so
you
know
from
there
you're
starting
to
like
set
up
the
infrastructure.
A
You
need,
you
start
to
make
some
some
design
decisions
around
what
you're
doing
and
then
rewind
all
the
way
into
the
future
and
you've
got
your
thing
built,
and
now
you
have
to
go
through
a
three
to
six
month,
ATO
process,
which
is
also
like.
That's
that's
somewhat
quick
in
some
agencies
and
what
I
want
to
really
try
to
drive
home
here.
A
The
assumptions
that
you
made
then
and
the
assumptions
that
you
now
have
when
you're
when
your
app
is
live,
are
radically
different,
we're
talking
Millions
upon
millions
of
people
affected
or
potentially
facing
like
lethal
outcomes
because
of
one
one
strain
of
a
virus
in
covid-19,
and
this
is
like
one
Healthcare
emergency
sort
of
situation
that
agencies
like
CMS,
are
contributing
to
there's
the
opioid
epidemic.
There's
there's!
A
You
know
these
more
bespoke
diseases
that
are
starting
to
have
like
outbreaks
again,
and-
and
this
is
the
kind
of
thing
that
federal
agencies
need
to
be
able
to
responsively
and
nimbly
respond
to
situations.
So
let's
say
we
get
all
the
way
to
the
end
of
that,
and
we
need
to
start
making
changes
quickly
in
the
in
the
order
of
magnitude
of
hours
and
days.
A
Not
weeks
to
months
to
quarters,
we
need
to
be
able
to
do
that
and
do
so
in
a
way
that
doesn't
throw
the
baby
out
of
the
bathwater
of
all
the
compliance
security
resiliency
requirements
that
are
necessary
in
operating
in
the
business
of
the
government.
That
is
like.
We
can't
forego
that
because
real
people,
you
know
it's
not
like
you're
going
to
lose
your
you
know
your
cat
videos
or
your.
A
You
know
your
food
logs
or
whatever,
like
you're
gonna,
like
we're
in
the
business
of
the
government,
so
we
have
very
real
things
to
reckon
with
and
contend
with,
and
you
know
like
presidents
come
and
Congress
comes
and
they
you
know,
there's
hell
to
pay.
If
you
don't
do
something
that
you
were
asked
to
do
from
those
upper
echelons
of
government.
A
That
is
inevitable,
like
that's,
typically
how
it
goes
in
security
when
security
teams
start
going
in
not
empathizing
with
who
their
stakeholder
or
customers
a
customer
is
on
the
other
side
and
just
making
demands,
you
might
get
short-term
compliance,
but
long
term
people
are
going
to
hate.
You
resent
you,
ignore
you
and
so
you're
not
going
to
really
move
the
needle,
and
so
we're
really
leaning
in
on
this
concept-
and
this
is
more
like
this-
is
part
of
a
broader
culture
shift
inside
of
CMS
inside
of
our
cyber
security
organization.
A
That
is
focused
on
empathy
over
the
person.
On
the
other
side
of
the
of
the
conversation,
the
developer
enablement,
the
person
who's
struggling
to
just
get
something
done,
because
the
app
that
we
provided
them
sucks
because
it
takes
20
seconds
to
load
a
page
because
it's
not
accessible
from
some
Network
segment
you're
in
all
of
that
stuff,
like
focusing
on
value,
invest
in
value
start
to
spread.
The
word
like
really
trying
to
build
something
that
people
find
valuable
and
letting
that
create
virtuous
Cycles
is
really
the
kind
of
Cornerstone
of
our
particular
flywheel.
A
B
B
So
when
we
think
about
what
all
is
necessary
to
build
a
platform,
things
like
logging
and
monitoring,
runtime
security
pipeline,
tooling,
Etc
Big
Bang
provides
secure,
hardened
containers
and
configurations
for
these
core
platform
components
right
out
of
the
box
and
additionally,
these
hardened
containers
and
configurations.
They
come
with
oscout
documents.
B
B
There's,
always
this
option
available
to
create
a
fork
of
the
product,
and
while
there
are
cases
when
Forks
are
warranted.
In
our
case,
it
is
an
organizational
strategic
imperative
that
we
contribute
back
Upstream.
So,
for
example,
I
mentioned
that
big
bang
provides
hardened
containers
of
Open
Source
Products.
So
let's
say
we
want
to
use
grafana
to
visualize
some
metrics
data
grafana.
B
If
we
were
to
create
a
fork
of
either
Big,
Bang
or
grafana.
This
would
effectively
double
the
work
on
our
teams
in
because
now
we
would
be
the
we
would
be
the
ones
monitoring
that
Upstream
grafana
repo
for
updates
and
we
would
be
the
ones
maintaining
this
secure,
grafana
Helm
chart
so
contributing
to
these
Upstream
repos
and
building
the
relationships
in
the
open
source.
B
So
first
we
Deploy
on
AWS
eks
and
once
we
have
this
bare
eks
cluster
up
and
running.
The
first
thing
we
do
is
install
flux
and
flux
is
our
continuous
delivery
tool
for
deploying
the
platform
we
use
flux
to
take
all
of
these
CMS
bat
cave
specific
configurations.
We
overlay
them
onto
a
big
bang,
Helm
chart
and
then
deploy
it
all
as
a
flux,
Helm
release
and
this
single
flux,
Helm
release
will
deploy
the
entirety
of
our
platform.
B
So
next
the
platform
stack
is
deployed
in
a
particular
order
such
that
we
establish
a
security
Baseline
before
installing
anything
else
in
the
cluster.
So
to
do
this,
the
first
thing
we
do
is
install
kyverno.
As
our
admissions
controller
and
kyverno
allows
us
to
write
policy
as
code
that
all
of
the
other
resources
in
the
cluster
have
to
adhere
to
so
then
we
install
a
service
mesh
using
istio.
This
allows
us
to
regulate
all
Ingress,
egress
and
lateral
Network
traffic,
and
finally,
we
install
our
monitoring
and
Metric
stack,
which
is
Prometheus
and
grafana.
B
And
lastly,
once
all
of
these
core
services
are
deployed
and
healthy,
we
use
Argo
CD
to
deploy
an
app
teams.
Application,
Argo
CD
will
aggressively
reconcile
drift.
So
if
someone
attempts
to
modify
an
application's
configuration
once
it's
been
deployed,
Argo
will
automatically
revert
it
back
to
the
state
defined
inversion
control,
so
in
other
words,
we
use
Argo
CD
to
deploy
tenant
applications
using
this
declarative,
git
Ops
model.
B
Okay.
So
at
this
point
all
of
the
infrastructure
and
configuration
this
code
has
been
written.
It's
all
sitting
up
in
GitHub
and
the
big
question
is:
how
do
we
want
to
deliver
this
platform
to
the
app
teams
and,
depending
on
what
app
team
you
talk
to?
You
know,
people
want
different
things.
Some
application
teams
already
have
platform
engineers
and
they
feel
comfortable,
managing
an
AWS
account
and
operating
a
kubernetes
cluster.
Other
app
teams
don't
have
any
platform
engineers
and
they
would
rather
have
a
platform
as
a
service,
fully
managed
type
of
experience.
B
B
We
have
is
this
single
tenant
platform
as
a
service,
and
in
this
scenario
each
app
team
has
their
own
cluster
that
we,
the
Batcave
team,
will
manage
and
operate,
and
this
model
is
really
meant
for
app
teams
who
maybe
have
limited
cloud
or
platform
expertise,
and
also
maybe
they
have
a
higher
budget
and
I
mentioned
the
budget
piece,
because
you
can
imagine
running
your
own
eks
cluster,
including
all
those
utility
built
apps.
You
just
saw
plus
your
own
app
like
this,
can
get
super
expensive
right.
B
That
said,
like
many
app
teams,
don't
need
this
level
of
isolation.
For
example,
if
you're
running
a
relatively
low
traffic
internal
facing
web
app,
you
probably
don't
need
an
entire
eks
cluster
to
yourself.
So
in
order
to
be
a
competitive
option
for
this
other
Market
segment
of
app
teams,
we
also
have
a
multi-tenant
platform
as
a
service
model.
This
model
Works
especially
well
for
entire
organizations
that
want
to
migrate
their
entire
Suite
of
applications
to
run
in
the
Batcave
and,
of
course,
the
cost
is
just
going
to
be
considerably
less
than
that
single
tenant
option.
B
Technically
speaking
with
this
multi-tenant
model,
each
app
is
separated
by
namespace
and
each
app
has
its
own
dedicated
node
by
separating
the
apps
by
node.
This
allows
us
to
mitigate
the
blast
radius
in
case
one
of
the
apps
malfunctions.
So,
for
example,
if
one
of
the
apps
has
a
memory
leak
and
it
eats
up
all
the
memory
in
one
of
the
nodes
and
that
node
becomes
unhealthy
and
goes
down,
the
rest
of
the
apps
running
in
the
cluster
should
be
unaffected.
B
We
can
just
give
them
an
overview
of
the
Batcave
platform,
Point
them
to
our
code
up
in
GitHub,
and
let
them
dig
in
now
looking
at
these
three
models
as
one
of
the
engineers
who
has
to
implement
these
different
delivery
models
and
then
operate
all
of
these
very
different
clusters.
I
can
tell
you
firsthand
like
this
is
too
much
right.
B
That
phrase
like
multi-tenant
is
actually
a
bit
of
a
marketing
faux
pas
on
our
end,
for
example,
when
you
deploy
an
app
on
Heroku
or
even
AWS,
do
you
know,
or
even
care,
if
it's
multi
or
Singleton
on
the
back
end
for
things
like
databases,
yeah
sure
you
might
care,
but
for
the
stateless
application
itself?
Probably
not
all
you
care
about
is
that
your
app
is
deployed
it's
healthy
and
it's
accessible
and
that's
the
beauty
of
those
platforms.
B
This
enables
us
to
give
those
app
teams
the
the
flexibility
and
the
control
where
it
matters
most,
which
we
believe
is
at
the
app
tier
and
that's
the
real
value
out
of
Batcave.
We
want
to
enable
an
app
team
to
inherit
as
many
security
controls
as
possible
to
reduce
this
amount
of
redundant
toil
all
across
CMS.
A
A
This
one
doesn't
apply
all
of
that
stuff,
as
opposed
to
having
this
more
modular
approach
and
so
having
our
own
full
and
independent
ATO
is
one
of
those
examples
of
a
back-end
process
enabler
for
our
teams.
Now,
right
now,
we're
heavily
focused
on
that
production
level.
Multi-Tenancy
model.
This
is
also
something
fairly
new
for
CMS.
Most
of
the
time,
segmentation
has
sort
of
been
a
very
rigid
construct.
We're
going
to
segment
you
into
different
AWS
accounts.
A
That
is
just
it's
way
more
efficient
way,
more
cost
effective,
and
so
we're
leaning
pretty
heavily
into
that,
because
we
have
a
lot
of
groupings
of
systems
that
are
fairly
on
the
same
they're
in
the
same
sort
of
bucket
and
category
with
regards
to
risk
and
functionality
and
portfolio
owner,
like
that.
The
person
who
pays
the
budget
for
that
thing,
and
so
like
this
is
something
that
we're
really
really
trying
to
optimize
for
right
now.
A
That
also
is
a
huge
strain
on
development
teams,
and
it's
just
not
as
just
not
as
gnarly
or
you
can't
say
it
as
easily
as
ATO,
and
so
so
we're
really
trying
to
make
sure
that
all
of
those
other
things
those
orthogonal
pieces
are
integrated
through
this
sort
of
middleware
Enterprise
API
that
we're
that
we're
building
right
now
and
then
the
last
thing
which
you'll
see
on
the
top
here
is
our
security
data
Lake
integration.
So
this
is
part
of
a
broader
cyber
security
objective
that
we
have
right
now.
A
So
the
show
hands
of
folks
who
are
familiar
with
like
Splunk
deployments
and
stuff
like
that,
all
right,
so
normally
my
condolences
normally
the
the
way
you'd
like
deploy.
One
of
these
things
is
it's
like
it's
anchored
in
these
little
pockets
of
the
owner
of
the
thing
of
the
team
that
manages
the
Splunk
cluster.
Now,
that's
not
a
limitation
of
Splunk.
A
All
those
organizational
silos
around
how
they
manage
their
data
into
you
know
think
like
big
data,
Lake
tools,
data
breaks,
snowflakes,
redshift
things
like
that
and
they're
optimizing
more
on,
not
like
building
detection
and
response
capabilities
in
cluster,
but
rather
the
streaming
ingestion
pipes,
the
ETL
pipelines
that
are
bringing
data
in
so
that
way
they
have
good
structured
data
with
which
to
work,
and
then
they're
focused
on
re-skilling
upskilling
their
teams
to
be
more.
Like
data
analysts,
data
Engineers,
for
example,
the
last
startup
that
I
was
in
was
this
company
Simon
data.
A
It
was
a
marketing
company.
You
might
think
why
why
in
the
world,
does
marketing
have
anything
to
do
with
federal
health
care
and
it
doesn't,
except
for
the
fact
that
I
think
most
so
I'm
wearing
all
birds
right
now
now
I
could
buy
my
all
birds
off
of
an
Instagram
ad
I
could
buy
them
off
of
I
could
go
to
their
website,
I
might
buy
them
in
a
retailer.
I
might
see
a
Facebook
ad
instead
of
an
Instagram
ad
and
marketing
similar
to
security,
and
this
is
a
dynamic
that
exists
in
almost
every
industry.
A
Is
you
know
all
those
things
represented
different
pockets
of
data?
They
lived
in
different
places,
they
didn't
synchronize
with
one
another
and
insight.
Glean
from
Instagram
did
not
yield
to
insights
or
more
targeted
advertising
in
the
website
or
in
Google,
or
what
have
you
and
marketers
the
team
that
was
marketers
were
more
like
copywriters
they're,
buying
ads
they're
doing
stuff
like
that,
similar
to
cyber
security.
We
had
a
lot
of
policy
people
and
a
lot
of
operations.
People
we
didn't
have
a
lot
of
data
engineers
and
software
Engineers.
A
So
really
we're
trying
to
take
that
same
concept.
Think
all
the
data
that
we,
as
cyber
security
people
operate
with
and
and
will
operate
with
in
the
near
future.
S-Bombs
compliance
like
scan
data
you've
got
vulnerability.
Scan
data
you've
got
pipeline.
Outputs
you've
got
you've,
got
like
like
configuration
like
scan
data
on
your
SAS
tools.
You've
got
Asset
Management
data,
both
from
specific
tools
as
well
as
normalized
in
in
some
means.
A
So
one
of
the
big
things
here
is
making
sure
that
the
Batcave
natively
integrates
with
as
a
data
producer
onto
the
data
Lake
and
then
eventually,
as
a
data
consumer
pulling
stuff
out
of
the
data
Lake
to
enrich
the
stuff
that
we
present
back
to
the
dashboards
and
things
like
that
to
the
app
teams.
So
next
slide
all
right.
So
a
couple
of
the
big
accomplishments
that
we're
pretty
proud
of
at
this
stage,
80
of
that
says,
100,
it's
not
100.
It's
80,
Chris.
A
There
we
go
okay,
I
like
that
answer
better.
It
looks
nicer,
so
80
fully
inherited
of
our
853
Baseline,
which
we
refer
to
as
ARS,
because
you
know
we
can't
just
call
things
consistent
names,
so
there's
also
a
lot
of
correlation
and
connection
points
happening
between
Batcave
and
platform
of
service
and
Engineering
emphasis
and
policy.
A
So
one
of
the
things
that
falls
under
my
group
is
we
write
policy
that
informs
the
agency
and
so
starting
to
write
policy
that
aligns
with
the
road
map
that
we
have
at
Batcave
and
and
other
parts
of
these
of
the
security
organization
like
when
and
where
we're
going
to
start
ingesting
s-bombs,
where
you're
going
to
be
sending
your
logs,
how
you
should
be
doing
like
if
you're
doing
continuous
delivery.
How
should
that
work,
and
so
basically
laying
the
groundwork
for
adoption
and
value
creation
here
and
then
also.
A
A
So
this
was
I'm
going
to
spend
a
ton
of
time
on
this
slide,
but
this
was
a
one
of
the
lead
Engineers
for
one
of
our
early
adopter
customers.
Now
this
particular
customer
was
they
were
working
in
in
an
on-prem
environment,
so
deploying
all
their
stuff
in
a
brick
and
mortar
Data
Center,
and
they
were
planning
a
transition
into
AWS
and
so
right
off
the
gates
like
they
were.
A
They
were
looking
at
like
an
18-month
time
frame
to
do
all
of
that
stuff
to
re-architect
some
things,
re-architect
their
app
to
embrace
and
work
with,
like
Cloud
native
Solutions
stuff,
like
that
set
up
their
new
build
deployment,
pipelines
and
all
of
that
stuff.
So
we
got
our
Clause
into
them
early
on
in
these
planning
migration
discussions.
We
knew
some
people
there,
and
this
is
part
of
our
like
early
marketing
strategies.
A
Internally
and
like
we
took
their
18-month
road
map
and
we
ended
up
shrinking
that
down
into
like
two
and
a
half
three
months
and
like
that
alone,
like
is,
is
awesome
and
so
something
we're
really
proud
of.
We
hope
that
it
can
go
even
faster
than
that
for
future
migrations
for
future
customers,
because
we
learned
a
lot
we're
a
little
clunky
like
going
through
this
initial
engagement.
A
You
know,
because
we're
like
basically
working
within
this
broader
construct
of
other
oit
office
of
Information,
Technology
resources
and
so
like
figuring
out
how
best
to
work
and
collaborate
with
them
in
the
service
of
the
customer
is
something
that,
like
we've,
learned
a
lot
through
this
initial
engagement.
Others
like
it
and
we're
just
folding
that
back
into
the
program,
so
every
single
run
we're
going
to
get
faster,
faster,
faster
and
more
efficient,
all
right.
A
So
a
big
thing
like
throughout
this
whole
talk,
we've
been
emphasizing
people
and
Partnerships
and
teamwork
and
collaboration,
and
so
this
is
like
this
is
part
of
like
part
of
this
is
doing
inside
of
like
doing
it
inside
of
the
CMS
context,
then
part
of
it
is
working
across
other
agencies,
so
across
HHS
I.
Think
HHS
is
a
collective
cabinet
agency,
is
one
of
the
biggest
in
the
government.
A
I
think
FDA,
CDC,
NIH
and
HHS
proper,
like
that,
covers
a
lot
of
the
federal
budget
and
a
lot
of
basically
everything
like
any
time
that
you're
interacting
with
anything
in
the
healthcare
space
in
a
hospital
or
or
what
have
you.
One
of
these
agencies
touches
something
about
that
and
CMS
inclusive,
so
like
sharing
out
code
Lessons
Learned
getting
like
design
Partners
in
early,
so
we
can
start
like
thinking
about
what
other
operating
divisions
slash.
A
Agencies
are
gonna
like
the
needs
they're
gonna
have
so
we
can
fold
that
in
that's
really
really
important,
and
then
this
other
bit
like
really
leaning
into
a
culture
of
openness.
So
this
is
something
that's
important
for
our
security
team
writ
large.
It's
been
uncomfortable
for
a
lot
of
people,
just
being
more
transparent,
being
open
sharing
my
deputy
and
I,
for
example.
A
We
do
monthly,
ask
me
anythings
we're,
like
all
of
you,
if
you
wanted,
could
could
join
next
next
month,
like
we,
don't
restrict
them
to
anybody
and
we
do
and
nothing
is
off
the
table.
Like
you
know,
we've
talked
about
wine
and
whiskey,
and
some
of
them
we've
talked
about
career
advice.
We've
talked
about
security
policy,
we
talked
about
tech,
stuff
people
try
to
like
stump
the
chump
on
you
know
like,
and
we
do
all
these
things
live
and
that
it
makes
people
really
uncomfortable.
A
So
with
that,
we
just
wanted
to
say
thank
you
for
taking
the
time
this
morning
to
spend
with
us.
These
are
all
LinkedIn
links.
If
you
have
any
interest
in
following
along
with
any
of
the
rants
that
we
do
or
things
that
we
post
on
there
and
I
think
we
have
some
yeah,
we've
got
a
little
bit
of
time
for
questions
and
yeah.
Thank
you
so
much.
Everyone.
A
Like
a
tenant
application
that
would
have
operate
in
that
space
right
now,
right
now,
I,
don't
think
so,
they're
more
like
they're,
more
like
a
traditional
apis
or
web
applications.
Stuff
like
that
I.
Imagine
that,
like
yes,
we
will
get
to
that
like
get
to
that
place,
because
those
sort
of
applications
do
exist
in
CMS.
A
And
so
you
know
we
don't
want
to
get
muddled
down
in
like
a
super
complicated
deployment
early
on
and
we're
we're
not
going
to
learn
a
lot
of
like
replicable,
lessons
and
stuff
like
that
to
other
customers.
But
you
know
we're
trying
to
so
we're
trying
to
be
very
intentional
now
so
that
we
can
layer
like
lay
the
groundwork
for
scaling
and
I
feel
like
you
know
that
we'd
have
to
kind
of
pull
out
like
what
are
the
what
are
going
to
be
the
bits
that
are
very
applicable
to
a
pipeline.
A
A
You
know
like
that.
Runtime
sort
of
security,
introspection
stuff
and
it's
it's
it's
a
growth
area
for
us
in
terms
of
like
doing
like
basically
layering
those
in
more
places,
and
it's
not
even
about
in
my
mind
like
blocking
you,
know,
malicious
traffic
I,
think
one
of
the
big
benefits
is
being
able
to
create
like
these
virtual
patches.
It's
like
you
find
something
and
before
you
can
fix
it
in
code,
you
can
get
like
a
virtual
patch
out
to
like
prevent
a
thing
from
happening
or
like
block.
A
You
know
a
cluster
of
ips
that
are
that's
doing
something
or
a
pattern
of
of
traffic,
and
then
you
know
basically
buy
yourself
some
time
to
fix
the
issue
in
code
and
so
like.
That's
something
that,
like
generally
speaking,
not
just
for
Batcave
deployments,
is,
is
like
quite
relevant
for
our,
like
security
engineering
teams,
yeah.