Create and update runtime policies, and then apply policies to instrumented images. Apply a policy to an instrumented image in order to enforce certain behavioral restrictions and secure the container spawned from the image.
See: Create policies | Manage policies | Set policy enforcement | Apply policies to instrumented images
A runtime policy contains one or more rules of different types along with the mode the policy operates on, the default action for various rule types, whether to enable or disable the behavioral learning mode and more. New policies can be created from scratch or by auto-generating a behavioral profile policy from a running container (see Behavioral Learning). When defining a policy, you can change the default action for each rule type.
The core technology behind most policy rules is the idea of a “function-level” (syscall) firewall; a policy rule can specify whether a program should or should not be able to execute a particular function (syscall), given a specific set of arguments. Each rule specifies a program that the rule matches, along with a rule type, whether the rule is enabled or disabled, and then the arguments that are required for that type of rule.
There are three basic policy rule types: network, file and application.
A network rule at first glance can provide “standard” firewall capabilities – allowing or denying inbound or outbound IP connectivity between the container and a given IP address and port to block lateral or external communication. The network rule has these types: Network Outbound and Network Inbound.
File rules control what files can be accessed by a specific program. The file rule has these types: Read and Write.
Application rules are in a way a superset of the other rule types. With application rules, one can directly specify the system call that should be filtered. With the other types, Container Runtime Security (CRS) translates the rule to the appropriate one or more system calls. For example, a file rule to deny a file translates to syscall 0 (sys_read) and 2 (sys_open). The application rule has one type: Syscall.
See Create runtime policies to learn more about the rule types.
Note: This feature is available via the CRS API only for advanced users. Refer to the Qualys Container Runtime Security API Guide for complete details.
Container Runtime Security can automatically learn the behavior of the application in your environment by recording the activities being performed in the container. It captures all the network communication whether it is lateral or external, all the files read by any programs, program/processes and the system calls called in the container to create a baseline security policy template that can be a new policy or merged with the existing policy applied to the container.
Customers can start with enabling behavioral learning for their images in the test environment to understand the basic expected behavior of the container and how it differs from the build image. You can use CRS to create a policy template based on the learned behavior and get alerted if any violations occur.
Note: Behavioral logging, logging mode and policy mode can be changed for a specific container.