►
From YouTube: OpenShift Commons Briefing # 113: OpenShift Security & Forensics Best Practices with Knox Anderson
Description
Learn how to simplify and strengthen your security posture by combining deep kernel-level container visibility with metadata from your Openshift deployment to define your security policies. SysDig’s Knox Anderson covers how the security landscape is changing, the architecture of Sysdig Secure, and even covers a live security instrumentation of a containerized environment.
The live demo will walk you through what Sysdig Secure can do:
– Implement application and OpenShift aware policies
– Block incoming attacks and container break-ins
– Audit executed commands
– OpenShift forensics: pre and post-attack investigation
– Unify monitoring & security workflows
A
A
Well,
hello,
everybody
and
welcome
again
to
another
openshift
Commons
briefing:
I,
have
my
good
friend
Knox
from
systick
who's,
going
to
give
us
a
briefing
on
security
and
porins.
It's
best
practices
on
OpenShift
and
tell
us
all
kinds
of
WTF
things:
I'm
I'm,
loving
that
you
use
that
in
the
title,
because
I
think
it's
the
first
time
anyone's
ever
use
that
so
that's
great
and
I'm
gonna,
let
Knox
introduce
himself
he'll
do
a
good
job
of
it.
He's
promised
a
pretty
lively
demo.
A
If
you
want
to
ask
questions,
ask
them
the
chat
will
make
him
pause
and
take
a
breath,
and
you
can
answer
questions,
but
otherwise
we'll
have
a
live
Q&A
at
the
end.
Anything
that
doesn't
get
answered
in
the
chat
will
will
reiterate
them
and
we
are
recording
this
session
so
not
take
it
away.
Awesome.
B
Thanks
Diane,
so
hey
everyone,
I'm
Knox
from
systick
I
work
on
the
product,
marketing
side
for
cystic
secure
and
we've
actually
got
some
awesome
content
for
you
today.
We're
going
to
be
covering
mainly
a
live
demo
I'm
gonna
go
in
cause
some
vulnerabilities
to
happen
and
then
look
at
a
live
open
shift
environment.
How
you
can
do
forensics
in
there
and
do
a
bunch
of
other
stuff,
so
I'm
gonna
try
to
get
through
these
slides
as
quickly
as
possible
and
then
get
down
and
dirty
in
the
command
line
and
show
you
everything
else.
B
Look
a
little
bit
more
about
the
Cystic,
secure
capabilities,
how
we
can
help
you
deliver
secure
services
through
open
ship
and
then
go
into
the
live
demo
and
Instrumentation
their
high
level
and
Cystic
we're
the
container
intelligence
company
and
we're
gonna,
provide
unified
security,
monitoring
and
troubleshooting
from
a
single
instrumentation
point
and
a
background
on
us.
Our
founder
was
the
co-creator
of
a
popular
Network
packet
analyzer
that
many
of
you
guys
have
probably
used
called
Wireshark
from
there.
B
We've
launched
our
container
intelligence
platform,
which
is
made
up
of
Cystic,
monitor
assisting
secure,
and
we
have
300
plus
enterprise
customers
I'm
using
that
to
kind
of
safely
and
securely
deploy
containers
into
production,
and
we
have
really
deep
integrations
with
OpenShift
and
you
said,
major
enterprises.
So
we
take
all
that
open
ship
metadata
to
heart
and
allow
you
to
really
layer
that,
on
for
service
performance
monitoring,
service-oriented
security,
all
those
kind
of
things.
So
what
we're
gonna
really
talk
about
today
is
the
convergence
of
two
challenges.
B
First,
the
one
of
kind
of
operating
containers
in
production.
What
that
means,
how
how
it
looks
for
different
groups
and
then
go
from
there
and
look
at
how
you
can
enable
effective
scaleable
security
of
these
diverse
pass
workloads
that
you're
running
on
openshift
all
right
so
containers
are
everyone
refers
to
them
as
black
boxes
and
they're
great
for
development
and
great
for
operations.
But
what
does
that
mean
for
your,
like
your
NOC
or
your
sock
teams
that
are
really
there
to
focus
on
how
do
I
get
visibility
into
those
systems?
B
So,
on
the
development
side,
containers
are
awesome,
they're
black
boxes,
you
can
put
your
code
in
them.
You
can
execute
execute
that
they're
repeatable
and
then
on
the
operation
side.
You
can
move
these
around
really
easily.
Now
my
database
doesn't
have
to
be
on
one
node.
Multiple
notes
can
be
scattered
out
through
OpenShift
and
there's
all
these
layers
of
orchestration
that
are
making
it
really
easy
to
deploy
applications
in
multiple
locations
locations.
B
But
how
do
you
keep
track
of
all
those
containers
as
they're
moving
in
they're
scaling
without
going
and
putting
in
a
sidecar
container
or
something
like
that?
And
then
how
do
you
also
make
sense
of
these
services
that
are
now
scattered
across
multiple
nodes
and
and
make
sense
of
them
as
that
single
logical
service
or
that
OpenShift
deployment
and
the
pods
that
roll
up
into
them?
B
So
this
is
kind
of
some
of
the
challenges
that
you'll
face,
but
with
challenges
always
come
opportunities,
and
we
really
think
that
containers
offer
an
opportunity
for
you
to
have
better
security,
so
there's
controllable
attack
services,
it's
a
single,
isolated
container
that
black
box
that
we
looked
at
before
should
really
only
have
one
process
running
inside
of
it.
So
it
makes
it
a
whole
lot
easier
to
kind
of
lock
that
down
get
that
isolation
through
your
different
seed
groups
and
namespaces
as
well.
For
that
control
will
attack
circles.
B
Isolation
also
makes
it
really
easy
for
you
to
do
anomaly
detection.
So
if
you've
got
an
index
container
and
it's
communicating
through
non-standard
ports
or
if
there's
some
other
process
besides
internet
running
inside
that
container,
it's
a
whole
lot
easier
to
go
and
spot.
Ok
something's
going
wrong
inside
this
container,
rather
than
this
VM,
where
you'd
have
tens
or
hundreds
of
processes
running
on
top
of
it.
B
And
then
it
also
really
lends
an
opportunity
with
contain
is
an
open
ship
to
do
more
of
that
zero
day
threatened
and
behavioral
monitoring
to
looking
at
the
activities
that
are
coming
from
those
containers
and
running
those
through
a
pipeline
so
that
there's
easily
baseline
of
activities,
you
can
then
spot
anomalies
against
and
really
look
for,
fundamentally,
malicious
behavior
what's
happening
on
those
systems.
So
how
can
you
really
deliver
that
security
to
your
to
your
environment?
And
you
can
really
do
that
if
your
security
stack
is
architected
for
containers?
B
B
Next,
you
need
to
have
kind
of
automated
adaptive
security
policies,
the
policies
that
you
can
scope
to
a
certain
open
ship
deployment
or
even
the
individual
pods
that
roll
up
into
a
deployment
and
have
those
policies
that
are
going
to
scale
as
new
services
come
out
and
really
rely
on
the
metadata
and
the
different
things
that
your
Orchestrator
like
open
ship
is
providing.
The
thing
that
I
think
is
probably
the
most
important.
Is
this
non-disruptive
unified
instrumentation?
B
So
if
you're
deploying
tens,
tens
to
20s
of
containers
per
host
and
we're
really
seeing
the
density
kind
of
grow
up
as
more
and
more
companies
are
moving
to
use
containers
in
production,
you
really
don't
want
to
have
a
sidecar
container
or
go
and
inject
some
process
inside
each
one
of
your
containers.
So
you
kind
of
need
a
single,
unified
instrumentation
that
isn't
gonna,
go
and
mess
with
the
docker
demon
or
be
going
and
sitting
as
a
sidecar
to
each
container.
B
So
now
that
we've
kind
of
gone
to
okay,
what
do
we?
What
do
we
need
to
think
about
with
open
shift
and
the
containers
that
are
running
there
and
how
am
I
going
to
deploy
and
operationalize
security?
Let's
go
and
look
at
our
architecture
and
how
kind
of
we've
addressed
some
of
these
problems
so
before
we
get
into
that
I'm
gonna
just
talk
a
bit
a
little
bit
about
where
Cystic
secure
it
fits
in
your
security
stack.
So
we're
really
focused
on
two
main
aspects
here:
runtime
security
and
forensic
security,
so
runtime
security.
B
Doing
your
intrusion,
detection,
lateral
movement
data
exfiltration
so
seeing
if
your
database
has
spawned
an
unexpected
outbound
connection,
if
sensitive
data
was
read
from
that
and
really
looking
for
kind
of
fundamentally
malicious
behavior
happening
on
your
host
and
that
can
be
through
system
calls
processes
boards
pretty
much.
Everything
that
makes
a
system
call
will
be
able
to
pick
up
and
then
layer
on
this
runtime
security
and
then
the
other
side
with
containers
is
forensics
and
a
lot
of
times
when
a
container
gets
killed.
You're,
basically
screwed
you've
lost
all
your
data.
B
Someone
starts
a
shell
inside
that
container.
You
can't
really
see.
What's
going
on,
they
fill
the
container.
It's
all
gone.
We've
really
built
a
unique
way
to
get
a
buffering
capture
of
all
the
system,
activity,
pre
and
post
any
security
violation.
So
you
have
the
full
breadcrumb
trail.
Every
single
thing
that's
been
happening
in
your
environment,
and
this
is
something
we'll
go
in
much
deeper
to
kind
of
in
the
demo.
B
On
top
of
that,
we're
gonna
integrate
with
your
existing
platform,
security
and
IT
security,
so
we'll
integrate
with
cloud
forms,
be
able
to
pull
an
events
from
there.
If
you
have
vulnerabilities
that
are
discovered,
auerbach
things
like
that,
we
integrate
with
those
set
up
user
credentials,
can
ingest
events
from
those
into
kind
of
our
events
API
and
allow
you
to
have
a
really
tight
integration
with
us
and
open
ships
there
and
then
for
your
existing
IT
security.
B
Our
product
is
entirely
REST,
API,
driven
so
sending
out
every
single
executed
command
from
that
open
shift
environment
to
your
existing
sim
or
logging
tool,
or
just
doing,
and
all
your
user
tracking
to
your
governance
committees
and
things
like
that.
All
the
data
that
we
collect
can
be
fully
exported
out
to
any
other
system,
all
right
so
now,
I'm
gonna
get
into
the
architecture.
B
The
art
container
intelligence
platform
is
really
built
up
of
two
main
components
that
I'm
going
to
be
getting
into
further
the
first,
this
container
vision-
and
this
is
our
ability
to
see
all
app
activity,
network
activity
host
activity
without
going
and
instrumenting
any
of
your
containers
from
here.
We're
also
will
automatically
discover
any
application.
Metrics
system
metrics
all
that
kind
of
stuff
on
the
monitoring
side.
B
Okay,
so
from
there
that's
single
instrumentation
and
that's
single
back
in
we
actually
layer
on
three
different
products,
so
you
can
use
Cystic,
secure,
Cystic,
monitor
or
Cystic
inspect
and
there's
no
performance
impact
of
using
any
of
those
on
top
of
each
other.
So
you
just
are
really
gonna.
Have
that
single
container
per
host?
That's
gonna,
give
you
full
visibility
into
everything.
That's
running,
so
I've
talked
a
lot
about
how
we
use
this
data,
the
data
that
you
want
to
collect
from
containers.
But
how
do
you
actually
go
about
doing
it?
B
So
what
we're
looking
at
now
is
a
simple
host.
I've
got
a
host
OS
running
here.
I've
got
a
custom
container
I've
got
an
open-source
app,
so
something
like
in
genetics
running
here
and
what
we
do
is
deploy
our
agent
as
a
container
or
a
process
running
on
that
host.
Our
containers,
Red,
Hat
and
openshift
certified
and
from
there
that
container
is
going
to
load
a
unique
kernel.
Instrumentation
that
we
have.
This
instrumentation
is
part
of
our
open
source
tool.
B
It's
part
of
our
open
source
security
tools,
Cystic
falco
and
is
used
in
kind
of
millions
of
machines,
government
agencies
all
that
kind
of
stuff
and
that
kernel
instrumentation
is
going
to
see
every
single
system
call
happening
from
every
single
container
through
non-blocking,
read
and
then
put
that
into
a
ring
buffer
where
agent
can
go
and
process
that
at
user
space
to
see
all
commands
events
take
get
performance,
metrics,
basically
anything
that's
happening
on
that
host.
We
can
see
and
detect,
protect
and
troubleshoot
from
that
single
instrumentation
point.
B
On
top
of
that,
we've
layered
on
a
rules
engine
so
rules
for
kind
of
any
any
file,
access
port
scanning
any
connection
or
executed
program.
That's
running
on
that
host
or
within
that
container
will
detect
at
the
agent
level
and
then
allow
you
to
do
policy
enforcement
so
killing
a
container
pausing
a
container
committing
a
container
to
then
quarantine.
It
run
it
through
workloads
later
all
from
that
from
that
agent,
that's
running
on
the
host
and
then
the
last
component
of
the
of
our
architectures
service
vision.
B
So,
typically
you
go
and
you
look
at
your
infrastructure
from
the
physical
view,
I
mean
if
you're
looking
at
an
open
ship
infrastructure.
It's
gonna
look
a
lot
like
this,
so
you've
got
multiple
different
VMs,
there's
a
bunch
of
different
scattered
containers
running
across
them.
But
how
do
you
make
sense
of
that
as
logical
services
and
that's
where
we're
gonna,
integrate
with
open
ship
directly
and
allow
you
to
think
of
a
logical
service
based
on
any
piece
of
that
open,
openshift
metadata?
B
So
you
can
enforce
and
explore
policies
based
on
any
piece
of
this
metadata,
and
this
is
something
that
we've
done
for
kind
of
hundreds
of
different
companies
with
openshift
on-premise
using
SAS,
really
whatever
you
want.
That's
something
that
we're
here
to
support
you
with
your
open
ship
journey
and.
B
A
B
Cool
all
right,
so
what
I'm
gonna
do
now
is
something
that
you'll
definitely
never
see
from
any
other
security
or
monitoring.
Vendor
live
on
a
demo
and
I'm
actually
gonna
do
an
instrumentation
of
our
container
intelligence
platform
running
on
a
containerized
toast.
So,
as
you
can
see
now,
we've
got
kind
of
node.
No
data
coming
in
I've
got
cystic
monitor
running
here.
I've
got
cystic,
secure,
running
really
nothing's
going
on
in
these
environments.
So
now
I
can
pull
up
my
instance
run
a
quick
docker
PS.
You
can
see.
B
So
I
can
copy
it
right
here
and
let's
switch
over
and
a
Cystic
monitor.
So
we
can
kind
of
see
the
real-time
data
stream
in
and
I'm
actually
going
to
just
going
to
remove
the
dash
D.
So
then
we
can
see
the
output
here
all
right.
So
what
this
is
doing
is
it's:
it's
loading
our
kernel,
module
via
DKMS,
so
we're
gonna,
look
at
the
exist
version
of
your
kernel,
build
the
module
on
top
of
that.
So
it's
not
gonna
require
a
kernel,
restart
or
anything
like
that.
B
And
then,
if
we
scroll
up
within
here,
you
can
see
we're
doing
a
bunch
of
different
checks
for
if
kubernetes
is
running
stats,
the
metrics,
if
they're
in
the
environment,
JMX
sampling,
all
of
that
all
automatically
pulling
any
any
certificates
searching
out
for
any
AWS
metadata,
MSS
metadata
and
then
pulling
pulling
all
of
that
automatically,
and
so
now,
if
we
look
kind
of
over
into
cystic
monitor,
you
can
see
all
the
different
containers
that
we're
running
have
pulled
up.
We
can
drill
down
into
something
like
this.
B
Wordpress
container,
see
the
performance
of
those,
but
let's
actually
go
and
kind
of
look
at
it
from
a
topology
perspective.
This
is
one
of
the
things
that
kind
of
anyone
in
the
PCI
compliance
space
will
see.
You
need
to
see
every
single
network
connection
that's
going
on
in
your
in
your
environment.
So
if
I
go
over
to
hosting
containers
here,
really
quickly,
look
back
on
entire
infrastructure.
I
can
see
every
single
connection.
That's
coming
into
this
host,
then
drill
down
see
all
the
containers
that
are
running
there.
B
I
can
even
actually
see
the
SSH
process,
that's
running
on
this
host
from
the
ISP
provider
that
we
have
in
our
office
and
then
I
can
actually
go
down
all
the
way
into
all
these
containers
and
see
the
individual
process
that's
running
inside
and
the
network
impact
and
all
the
network
connection.
So
this
is
something
we
installed
our
agent
on
the
host.
It
automatically
discovered
all
this
had
this
pre-built
mapping
and
then
you
can
actually
go
down
a
step
further
and
let
me
switch
this
to
container
name
really
quickly.
B
To
something
like
my
sequel
and
we're
gonna
automatically
detect
that
my
sequels
running
start
pulling
things
like
number
request:
number
of
errors,
top
query
slowest
query
slowest
tables
all
automatically
without
you
needing
to
do
any
other
additional
instrumentation,
so
here
we're
actually
decrypting
that
TCP
connection
and
then
reading
the
file
descriptor.
So
you
just
install
the
agent
and
all
this
is
discovered
out
of
the
box.
B
B
B
B
B
I've
essentially
gone
in
and
replaced
kind
of
LS
with
curl
and
I've
kind
of
masqueraded
that
as
a
different
process.
So
let's
go
over
and
look
at
this
into
secure
and
see
kind
of
what
we've
detected
so
first
off.
No
one
should
ever
be
able
to
shell
in
a
container
from
what
we've
just
seen,
because,
basically
now
I
can
hide
everything
inside
that
container
execute
stuff
across
my
entire
system,
once
I
got
access
inside.
B
So
let's
look
at
what
actually,
we
discovered
insisting
secure
first
off,
there's
a
whole
lot
more
red
than
before,
and
I
can
actually
open
up
that
host
click
on
that
WordPress
one
container
and
then
switch
over
to
this
list
view,
and
we
can
see
all
right
first
there's
this
terminal,
shell,
that
was
running
and
tanked
in
a
container.
We
had
that
right
below
a
binary
directory,
and
then
there
were
system
processes
that
had
unexpected
networked
activity.
B
So
I
can
click
on
any
one
of
these
get
full
details
about
kind
of
the
scope
where
it
happened,
the
individual
container,
the
host
and
then
actually
the
full
output
here
with
user
commands
and
everything
else.
That
was
right.
I
can
also
hop
over
to
the
commands
history,
click
on
the
host
B,
every
single
command
that
was
executed,
with
full
scoping
of
where
it
happened
in
my
environment
as
well.
B
B
So
we
can
see
kind
of
some
of
the
high
severity
policies
that
are
running
in
my
environment,
different
file
policies,
network
policies,
things
like
that,
but
since
you're
using
open
shift
or
any
and
deploying
services
and
managing
services
and
exposing
those
to
developer
groups,
you
really
want
to
think
of
those
as
your
logical
entities
that
you're
trying
to
protect
I
can
go
and
look
at
my
entire
environment
based
on
scope
and
see
the
policies
that
are
running
across
to
my
entire
infrastructure.
Protecting
the
hosts
and
containers.
B
Well,
then,
actually
drill
down
into
kind
of
specific
deployments,
so
I
can
go
in
where
we're
using
the
deployment
name
equals
Redis
and
trying
to
detect
if
there's
some
unexpected
and
outbound
connection
for
Redis.
So
your
database,
you
don't
want
it
hanging
out
to
the
outside
world
and
kind
of
tuning.
These
policies
on
a
deployment
wide
deployment
basis
I
can
also
go
in
and
add
other
data
services
to
this
if
I
wanted.
B
B
This
is
kind
of
like
a
TCP
dump
of
your
kernel,
where
you're
gonna
see
every
single
system
call
pre
and
post
that
security
violation,
and
then
control
will
shoot
that
later
and
we'll
go
through
some
of
those
examples,
and
then
from
here
you
can
send
it
out
to
kind
of
pay
tribute.
Ii
slack
big
drops
option
II,
send
it
to
cloud
forms
via
web
hook,
kind
of
all
all
automatically
there
all
right.
B
B
But,
like
we've
talked
about
before
with
open
shift,
you
really
want
that
service-oriented
security,
and
we
can
switch
over
to
this
deployments
view
here
and
then
drill
into
something
like
this
java
namespace
and
one
of
the
easier
ways
to
actually
look
at
this
is
to
go
back
to
that
topology
map
and
go
in
and
explore
where
violations
have
happened.
Kind
of
based
on
that
logical
infrastructure.
So
here
we've
drilled
down
into
a
specific
namespace.
B
We
can
see
all
the
deployments
that
are
running
in
them
drill
into
a
specific
deployment
and
then
actually
see
where
the
event
happened
at
a
pod
or
container
level
and
all
the
different
network
connections
and
the
dependencies
that
have
happened
there.
So,
let's
drill
into
kind
of
this
policy
violation
that
happened
with
Redis
and
we
can
see
okay,
there's
an
unexpected
outbound
connection
and
then
a
sensitive
files
right.
B
The
really
cool
thing
here
is
I.
Have
the
full
scoping
of
where
this
happened
from
a
logical
perspective
as
well
as
that
host
and
container,
so
if
I
need
to
go
and
quarantine
that
host
I
can
do
that,
but
then
I
also
have
full
knowledge
of
where
this
actually
went
and
affected.
My
open
ship
deployments
pods
or
any
services
that's
rolling
up
into.
B
We
can
drill
down
further
and
look
at
the
output
here,
so
we
can
see
all
right,
there's
an
unexpected
outbound
connection
from
this
f-test
command
and
then,
after
that,
a
sensitive
file
was
open
for
reading.
By
that
same
app
tests
can
command
and
they're
actually
going
and
reading
from
etsy
shadow,
so
they've
immediately
come
in
got
access
to
my
hash
passwords
and
are
going
and
reading
from
it.
So
this
is
kind
of
one
of
your
classic
data,
exfiltration
examples
that
could
be
happening
in
New
York
and
from
here.
You
can
kind
of
tune
this.
B
So,
okay,
if
I
ever
see
something
like
this
happen
again,
I
can
kill
the
container
or
customize
any
of
the
out-of-the-box
policies
that
we
have
in
our
Empire
and
kind
of
all.
These
policies
have
been
pulled
in
from
the
our
rule.
Engine
integrates
with
our
open
source
tool,
Cystic
falco,
so
we
have
tons
of
policies
that
have
come
in
from
the
open
source
community
things
that
cloud,
gov
or
Yahoo
is
using
to
protect
their
infrastructure.
B
A
B
B
Great
question,
so
our
back-end
architecture
is
really
made
up
of
two
main
technologies:
the
first
to
be
Cassandra.
So
all
of
our
time,
series,
metrics
and
things
like
that-
are
all
sent
to
our
Cassandra
database
and
then
all
the
commands
history.
Events
on
the
monitoring
side.
We
also
pull
in
any
docker
event
or
kubernetes
event.
So
if
you've
got
a
crash
loopback
or
something
like
that,
all
of
that
data
is
sent
to
elasticsearch
and
those
are
the
two
kind
of
main
components
both
of
those
have
REST
API.
B
B
Cool
that
was
a
good
good
break
before
we
get
into
some
forensics.
So
thanks
for
thanks
for
sending
those
in
alright.
So
now,
I
can
go
into
this
WordPress
environment.
This
namespace
here
and
drill
down
into
this
specific
WordPress
deployments
deployment
that's
running
there.
So
we
can
see
this
policy
violation.
That
happened
where
there's
a
shell
in
a
container
kind
of
the
same
thing
that
I'd
shown
before
I
can
click
on.
It
see
kind
of
that
same
logical
information
that
we
saw
earlier.
B
But
here
with
this
policy
we
actually
recorded
a
capture
and
then
there's
commands
that
are
associated
with
it
as
well,
so
I
can
go
click
on
View
commands-
and
this
is
gonna
drop
me
back
in
time
to
that
point
in
time
when
the
event
happened
and
give
me
all
the
commands
that
were
executed
around
that
specific
security
violation.
So
from
here
I
can
see
all
right.
The
user
spawned
a
shell,
they
curl
down
over
a
URL
and
then
uncharted
so
from
here.
B
I
can
actually
click
on
any
row
and
get
really
deep
information
about
that
specific
command.
So
we
can
see
from
the
full
command
line
here.
They
actually
curl
down
a
rootkit,
so
this
looks
sketchy
I'm.
Definitely
gonna
want
to
do
further
forensic
analysis.
Here
we
we
can
see
the
working
directory,
the
paid
user
ID
shell
distance,
all
that
kind
of
stuff
automatically
and
then
that
user
uncharred
that
command
and
so
they've
done
they've
done
some
pretty
malicious
stuff
here.
B
I
can
click
over
onto
captures
now
and
do
further
analysis
of
that
capture
at
that
point
in
time
when
the
event
happened.
So
if
I
click
on
this
button
here,
we're
gonna,
open
up,
Cystic,
inspect
and
Cystic
inspect
is
kind
of
our
forensics
tool
to
do
full
analysis
of
kind
of
every
single
thing.
That's
been
happening
in
your
environment,
so
you
can
see
kind
of
all
file
access
patterns,
Network
activity,
network
gaps,
app
log
messages,
your
full
HTTP
requests
and
payloads.
B
All
of
this
data
is
gonna,
be
captured
here
and
it
really
easy
to
filter
way.
So,
let's
set
this
stage
first
with
looking
at.
When
did
that
notification
happen
and
then
I
can
isolate
a
specific
time
around
that
notification.
So
we
can
actually
look
at
kind
of
sub
second
granularity
in
here.
If
you
wanted
to
and
then
start
overlaying
things
like
kind
of
file
access
patterns,
Network
bytes
in
and
then
those
executed
commands
that
we
saw
earlier
in
the
commands
history.
B
So
this
is
right
here
when
that
user
spawned
the
shell
and
then
we
can
see
probably
okay.
This
is
when
they
curl
down
that
URL.
There's
a
bunch
of
different
file
access
things
like
that.
So
any
one
of
these
tiles
you
can
drill
down
into
and
get
really
rich
information
kind
of
about
that
tile
and
use
that
as
a
jumping
off
point.
B
So
right
now
we
can
see
those
same
executed
commands
so
I
can
see
the
user
started
a
shell
curl
down
that
rootkit
and
then
on
target
and
then
from
here
I
can
actually
drill
down
in
and
do
further
analysis
of
what
actually
happened
when
that
tar
process
was
executed.
So
if
I
double
click
on
that
tar
process
and
then
switch
over
to
this
files
for
you
now,
I
can
see
every
single
file
that
was
written
at
that
point
in
time
when
that
tar
process
was
executed.
So
we
can
see
basically
that
rootkit
was
unzipped.
B
B
Awesome
and
then
you
you
can
get
your
four
counts
fork
trees,
all
that
kind
of
stuff
all
within
here.
If
you
want
to
see
all
the
different
processes
that
were
running
drill
down
into
kind
of
the
individual
system
calls
from
a
process
all
the
way
down
into
really
every
single
thing
that
made
a
system
call
during
that
point
in
time.
B
A
B
Actually,
don't
have
one
of
those
slides
prepared
right
now,
the
easiest,
the
easiest
way
to
always
contact
us
is
on
our
website.
So
within
here
you
can
actually
start
a
free
trial
of
cystic,
monitor
or
cystic
secure
requests.
A
further
demo
do
all
that
kind
of
stuff.
So
if
you
go
to
cystic,
calm,
you'll
have
full
access
and
then,
if
you
want
to
follow
with
me
directly,
my
emails
really
easy.
It's
just
Knox
KO
x-axis
dig
calm.
B
So
Falco
it's
got
its
own
github
page,
so
Falco
is
really
the
rules
engine,
so
it
doesn't
allow
you
to
take
actions,
pull
in
any
of
that
open
ship
metadata
or
things
like
that.
But
it's
an
open
store
security
rule
engine,
that's
kind
of
similar
to
like
if
you
had
combined
like
some
things
from
selinux
some
things
from
a
sex
and
stuff
from
ashtrays
and
built
it
for
containers,
that's
that's
kind
of
where
cystic
fibrosis
it's
it's
really
that
behavioral
Activity
Monitor,
so
it'll
just
send
alerts
to
standard
out
and
things
like
that.
A
Right
well,
I
am
not
seeing
any
questions
and
your
demo
was
awesome
and
it
didn't
crash
in
any
way
shape
or
form
so
I'm
pretty
impressed
with
that.
Since
you
said
this
was
the
first
time
you
were
doing
this
variation
on
it
so
kudos
to
you
for
pulling
it
off.
Gonna
give
people
a
couple
more
minutes
couple
seconds
here:
there's
any
questions,
a
bunch
of
people
on
there,
but
they're
they've
asked
most
of
their
questions
during
your
presentation,
so
I
just
say.
Thank
you
very
much
for
your
presentation.
A
A
There's
one
person
asking
a
question
now
talking
about
how
sort
of
product
differentiation
between
some
of
the
other
security,
apps
or
applications
like
twistlock
or
aqua
security
that
you
you
feel
confident
about
about
that
or
if
you
like
to
hold
that
we
could
maybe
have
a
panel
on
that
sometime
soon.
That's.
B
A
great
panel
question
and
the
high/low
just
doing
the
highest
level,
and
then
we
can
follow
up
directly
a
little
bit
more
about
individual
features
and
functions,
we're
a
container
intelligence
platform,
so
you're
really
gonna.
Have
this
single
agent
that's
running
on
your
host.
That's
gonna
be
able
to
give
you
that
full
monitoring
visibility,
full
troubleshooting
visibility
and
security,
visibility
from
that
single
instrumentation
point.
B
So
it's
really
one
way
to
get
full
insight
into
every
single
thing
in
your
system
than
having
separate
monitoring
agents
and
things
like
that
that
are
adding
more
attack
services
or
more
of
a
performance
hit.
So
that's
a
high
level
of
how
we
would
compare
against
those
and
then
directly
with
more
information
about
individual
features
and
how
they'd
be
comparing
I.
A
Think
that's
a
good
one
for
a
panel
at
an
upcoming
gathering
or
event
interesting
to
hear
that.
But
I
do
appreciate
you
taking
the
time
today
and
everybody
who's
joined
us.
We
will
put
the
slides
up
on
blog
openshift
comm
shortly
along
with
the
video,
and
it
will
be
up
on
our
YouTube
channel.
Is
it's
processed
and
ready
so
probably
about
a
day
so
I'm?
Thank
again.
Thank
you
again.
Knox
for
joining
us
awesome.