Runtime defense for hosts
Without secure hosts, you cannot have secure containers. Host machines are a critical component in the container environment, and they must be secured with the same care as containers. Runtime defense employs machine learning to build models of known good activity so that anomalous runtime behavior can quickly be detected. Prisma Cloud applies our model-based approach to runtime defense to protect the hosts in your environment.
Whereas container runtime protection creates models for images, host runtime protection creates models for systemd services. When Defender is installed on a host, it automatically creates runtime models for every service and container that runs on the host.
When a new service is detected, Prisma Cloud creates a new model for it, and puts the model into learning mode. Baseline models are provided for common Linux services, such as httpd (Apache) and sshd. All services, whether they have baseline models or not, are subject to a learning period before their models are fully activated.
There is one model per service, and models are global. A model for one host service is shared and reused amongst all hosts. For example, consider a service
foo, which runs on host-A and host-B. If foo acquires the DOCKER capability on host-A and the USERS_ADMIN capability on host-B, then the model, shared across both hosts, would enumerate both capabilities.
You can view all runtime models for your host service in Console under
Monitor > Runtime > Host Models. The table on this page has two pivots points:
- Host — Lists all the hosts in your environment. Click on a host to see the services on the host and their associated models.
- Service — Lists all the services in your environment. You can review the state of the models, and either relearn a model, or activate a manual learning mode for a model. Clicking on a service shows you the capabilities that have been whitelisted for it.
Host models map capabilities to services. Capabilities are Prisma Cloud-curated units of process and file system actions that express the things that services routinely need to do. They can be independently enabled or disabled on a per-service basis, and provide fine-grained control over what a service can and cannot do.
Capabilities encapsulate the intersection of what services need to do and what attackers want to do. Capabilities were borne from the following observations:
- Attacker objectives are well known. They need to gain a footprint on the host, establish persistence, elevate permissions, and so on.
- The path to achieving these objectives is also well known. Attackers must use specific utilities and manipulate specific files in order to advance their position. In many cases, these are the same utilities and files that legitimate services need to use.
By selectively assigning capabilities to services so that thet can do their job, but nothing more, Prisma Cloud can limit what an attacker can do when they hijack a service and try to exploit it to run in non-legitmate ways.
Capabilities have two key traits:
- Processes they can run.
- Files they can access.
For example, the USER_ADMIN capability permits user management. The following process and configuration files fall under its purview:
Processes: - adduser - useradd file system: - /etc/group - /etc/passwd
List of capabilities
The following capabilities can be applied to a service model. The last column in the table provides representative examples of files and processes that are associated with each capability.
Reading and changing system logs
Access to Docker socket
Changing Docker configuration
Changing Kubernetes configuration
Changing OpenShift configuration
Reading users and groups
Changing users and groups
All files in the USERS capability, but these files are monitored for write activity.
Changing sshd configuration
Running a shell
Changing network configuration
Changing host configuration
Changing Google Cloud configuration
Running privileged processes
When a service requests a capability that isn’t in its model, Prisma Cloud generates an audit. Audits can be viewed under
Monitor > Events > Host Audits.
Consider an HTTP server that executed the useradd command. There should be no reason for an HTTP server to execute the useradd command. The useradd command is part of the USERS_ADMIN capability, and the http-server service’s model won’t have this capability whitelisted. As a result, you get an audit:
Service http-server attempted to obtain capability USERS_ADMIN by executing /usr/sbin/useradd
You can create rules that prevent a service from running a process or accessing a file that is part of a capability (the default action is alert). Create a new host runtime rule, select the
Capabilitiestab, and set the action for the capability to
Prevent. In the
Generaltab, be sure to scope the rule to a specific service Otherwise, you will disrupt other services.
With this rule in place, further attempts to exploit http-server are blocked.
Enabling host runtime protection
Runtime protection for hosts is enabled by default. When Defender is installed on a host, it automatically starts building runtime models for all services. Prisma Cloud ships with a default rule named
Default - alert on suspicious runtime behavior, which alerts on all anomalous activity. To see the rule, open Console, then go to
Defend > Runtime > Host Policy.
As part of the default rule, Prisma Cloud Advanced Threat Protection (TATP) is enabled. TATP supplements runtime protection by alerting you when:
- Malware is found anywhere on the host file system.
- Connections are made to banned IP addresses.
Create new rules to enhance host protection.
Do not whitelist or blacklist capabilities globally by setting the host filters to a wildcard because it can interrupt the execution of legitmate services.
Anomalous app detection
Prisma Cloud learns the normal set of apps running on your hosts (a so-called app baseline), and automatically identifies apps added abnormally. After all running apps complete the learning phase, any subsequently started apps generate a one time audit.
Prisma Cloud lets you collect and analyze operating systems and application logs for security events. For each inspection rule, specify the log file to parse and any number of inspection expressions. Inspection expressions support the RE2 regular expression syntax.
A number of predefined rules are provided for apps such as sshd, mongod, and nginx.
Prisma Cloud lets you secure host networking. You can filter DNS traffic and alert on inbound and outbound connections.
When DNS monitoring is enabled, Prisma Cloud filters DNS lookups. By default, DNS monitoring is disabled. Dangerous domains are detected as follows:
- Prisma Cloud Intelligence Stream -- Prisma Cloud’s threat feed contains a list of known bad domains.
- Explicit whitelists and blacklists — Host runtime rules let you augment the Prisma Cloud’s Intelligence Stream data with your own lists of known good and bad domains.
In your runtime rules, set
Effectto configure how Defender handles DNS lookups from containers:
- Disable— DNS monitoring is disabled.
- Alert— DNS monitoring is enabled. Anomalous activity generates audits.
- Prevent— DNS monitoring is enabled. Anomalous activity generates audits. Anomalous DNS lookups are dropped.
You can raise alerts when inbound or outbound connections are established. Specify inbound ports, and outbound IPs and ports.
Outbound connections are event-driven, which means that as soon as a process attempts to establish a connection, you’ll be notified. Prisma Cloud polls inbound connections, which means you’ll be notified periodically, and not necessarily the moment an inbound connection is established.
Set up rules to audit host events.
File integrity management (FIM)
Changes to critical files can reduce your overall security posture, and they can be the first indicator of an attack in progress. Prisma Cloud FIM continually watches the files and directories in your monitoring profile for changes. You can configure to FIM to detect:
- Reads or writes to sensitive files, such as certificates, secrets, and configuration files.
- Binaries written to the file system.
- Abnormally installed software. For example, files written to a file system by programs other than apt-get.
A monitoring profile consists of rules, where each rule specifies the path to monitor, the file operation, and exceptions.
The file operations supported are:
- Writes to files or directories. When you specify a directory, recursive monitoring is supported.
- Reads. When you specify a directory, recursive monitoring isn’t supported.
- Attribute changes. The attributes watched are permissions, ownership, timestamps, and links. When you specify a directory, recursive monitoring isn’t supported.
Recommended For You
Recommended videos not found.