Runtime Protection
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »

Video Transcription
00:01
>> Cloud guard monitors in real time,
00:01
the kernel system calls that
00:01
>> workload containers perform.
00:01
>> Runtime protection is a combination of
00:01
two engines, signatures and profiles.
00:01
The Signature Engine monitors
00:01
the kernel system calls performed and
00:01
compares them with known signatures
00:01
that potentially indicate malicious behavior.
00:01
For example, execution of
00:01
processes associated with crypto mining software.
00:01
The profile engine detects
00:01
anomalies and behavior compared to a baseline profile,
00:01
which is based by default on
00:01
a learning period of 24 hours.
00:01
Every time one of the containers of a given pod group
00:01
performs an operation not
00:01
observed during the profiling phase,
00:01
a violation is detected and an alert is generated.
00:01
Runtime protection includes the following resources.
00:01
The runtime policy agent.
00:01
This agent is responsible for retrieval of
00:01
user-defined configurations and policies
00:01
from the cloud guard backend.
00:01
The rough runtime daemon.
00:01
This is a Kubernetes Daemon set which is as explained,
00:01
runs the two runtime protection engines.
00:01
The daemon monitors the kernel system calls.
00:01
The last runtime protection resource
00:01
is custom resource definitions,
00:01
also known as CRDs.
00:01
These are runtime protection policies
00:01
which define allow,
00:01
deny, and exclusions.
00:01
These CRD policies are present
00:01
on any cluster our solution resides.
00:01
Once deployed, the flow would look like this.
00:01
The nodes runtime daemon
00:01
requests information from the clusters API server to
00:01
determine which pods are running in
00:01
the cluster and the processes that are running.
00:01
These processes are basically system
00:01
calls to the clusters kernel.
00:01
Meantime, the CRDs are constantly
00:01
updated with valid signatures and profiles.
00:01
The runtime policy agent
00:01
retrieves from the cloud guard backend.
00:01
When a kernel system call is made
00:01
by protected acid within the cluster,
00:01
it's runtime daemon monitors the call and examines
00:01
its validity against the CRD definitions.
00:01
If there is a deviation from
00:01
the policies defined in the CRDs,
00:01
an alert is sent to the cloud guard backend.
00:01
When on-boarding a Kubernetes cluster
00:01
with runtime protection,
00:01
cloud guard automatically adds
00:01
a default security policy and
00:01
rule sets for the cluster environment.
00:01
You do not need to perform
00:01
any additional actions unless you would
00:01
like to create specific exclusions.
Up Next
Instructed By
Similar Content