1. Home
    2. Prisma
    3. Prisma Cloud
    4. Prisma Cloud Compute Edition Administrator’s Guide
    5. Runtime defense
    6. Custom runtime rules
    End-of-Life (EoL)

    Custom runtime rules

    Prisma Cloud’s approach to scaling runtime defense in big, fluid environments is to model runtime behavior with machine learning. Machine learning reduces the effort required to manually create and maintain loads of rules to secure running software. When machine learning doesn’t fully capture the range of acceptable runtime behaviors, rules provide a way to declaratively augment models with exceptions and additions.
    Custom rules offer another, additional mechanism to protect running software. Custom rules are expressions that give you a precise way to describe and detect discrete runtime behaviors. Runtime sensors in your environment already detect process, file system, and network activity, then pass those events to Prisma Cloud for processing. Expressions let you examine various facets of an event in a programmatic way, then take action when they evaluate to true. Custom rules can be applied to both hosts and containers.
    For example, the expression grammar supports the following logic:
    "If user Jake runs binary netcat with parameter -l, log an alert"

    Rule library

    Custom rules are stored in a central library, where they can be reused. Besides your own rules, Prisma Cloud Labs also distributes rules via the Intelligence Stream. These rules are shipped in a disabled state by default. You can review, and optionally apply them at any time.
    Custom rules are written and managed in Console under
    Defend > Custom configs > Runtime
    . Click
    Add rule
     to bring up the online editor. The compiler checks for syntax errors when you save the rule.
    There are four types of rules, but only three are relevant to runtime:
    • processes
    • filesystem
    • networking-outgoing

    Expression grammar

    Expressions let you examine the contents of process, file system, and network events.
    For example, any time a process is forked on a host protected by Container Defender or Host Defender, a process event fires. The following very simple expression looks for processes named netcat:
    proc.name = "netcat"
    Expressions have the following grammar:
    • term
       --
      integer | string | keyword | event | '(' expression ')' | unaryOp
    • op
       --
      and | or | > | < | >= | ⇐ | = | !=
    • in
       --
      '(' integer | string (',' integer | string)*)?
    • unaryOp
       --
      not
    • keyword (similar to wildcards)
       --
      startswith | contains
    • string
       --
      strings must be enclosed in double quotes
    • integer
       --
      int
    • event
       --
      process, file system, or network

    Expressions examples:

    net.outgoing_ip = "169.254.169.254" or net.outgoing_ip = "169.254.170.2"
    proc.pname in ("mysql", "sqlplus", "postgres") and proc.pname != proc.name
    file.path startswith "/etc"

    Process events

    Process events fire when new processes are forked. Expressions can examine the following attributes of a new process.
    Attribute
    Type
    Description
    proc.name
    string
    Process name.
    proc.pname
    string
    Parent process name.
    proc.path
    string
    Full path to the program.
    proc.user
    string
    User to whom the process belongs.
    proc.interactive
    bool
    Interactive process.
    proc.cmdline
    string
    Command line.
    proc.service
    string
    Only for host rules.

    Filesystem events

    Filesystem events fire when there are writes to disk. All properties of the process doing the writes are accessible from this context. Expressions can examine the following attributes of file system write activity.
    Attribute
    Type
    Description
    file.path
    string
    Path of the file being written.
    file.dir
    string
    Directory of the file being written.
    file.type
    enum
    File type. Supported types are: elf, secret, regular, and folder.

    Networking events

    Network events fire when a process tries to establish an outbound connection. Expressions can examine the following attributes when network events fire:
    Attribute
    Type
    Description
    proc.name
    string
    Name of process initiating the outbound network connection.
    net.outgoing_port
    string
    Outbound port.
    net.outgoing_ip
    string
    Outgoing IP address. The following expression looks for outbound connections to a range of IP addresses: net.outgoing_ip ⇒ "1.1.1.1" and net.outgoing_ip ⇐ "1.1.1.9"
    net.private_subnet
    bool
    Private subnet.

    Example expressions

    The Prisma Cloud Labs rules in the rule library are the best place to find examples of non-trivial expressions.
    1. In Console, go to
      Defend > Custom configs > Runtime
      .
    2. In the
      Type
       column, filter add a filter for processes, filesystem, or network outgoing.
    3. Click on any rule that starts with
      Prisma Cloud Labs
       to see the implementation.

    Activating custom rules

    Your runtime policy is defined in
    Defend > Runtime > {Container Policy | Host Policy}
    , and it’s made up of models and rules. Your expressions (aka custom rules) can be added to runtime rules, where you further specify what action to take when expressions evaluate to true. Depending on the event type, the following range of actions are supported: allow, alert, prevent, or block. Also, you can deteremine whether you want to log the raised event as audit or as incident.
    Custom rules are processed like all other rules in Prisma Cloud: the policy is evaluated from top to bottom until a matching rule is found. After the action specified in the matching rule is performed, rule processing for the event terminates.
    Within a runtime rule, custom rules are processed first, and take precedence over all other settings. Be sure that there is no conflict between your custom rules and other settings in your runtime rule, such as allow and deny lists.
    1. Open Console, and go to
      Defend > Runtime > {Container Policy | Host Policy}
      .
    2. Click
      Add rule
      .
    3. Enter a name for the rule.
    4. Click the
      Custom Rules
       tab.
    5. Click
      Select rules
      , choose the rules to add, and click
      Apply
      .
    6. Specify an effect for each rule.
    7. Specify how to log the event for each rule.
    8. Click
      Save
      .

    Limitations

    There are number of things that custom rules cannot do:
    • The proc.cmdline and file.type fields are not supported in prevent mode. You’ll get an error if you try to attach a custom rule to a runtime rule with these fields and the action set to prevent.
    • Prisma Cloud cannot inspect command line arguments before a process starts to run. If you explicitly deny a process and set the effect to
      Prevent
       in the
      Process
       tab of a runtime rule, the process will never run, and Prisma Cloud cannot inspect it’s command line arguments. The same logic applies to custom rules that try to allow processes that are prevented by other policies. For example, consider process 'foo' that is an explicitly denied by a runtime rule, with the effect set to
      Prevent
      . You cannot allow 'foo -bar' in a custom runtime rule by analyzing proc.cmdline for for '-bar'.
    • Prisma Cloud doesn’t support prevent on write operations to existing files. For example, consider the following expression:
      file.path = "/tmp/file"
      If this expression is added to a runtime rule, and the effect is set to prevent, then Prisma Cloud will prevent the creation of such a file. If the file already exists, however, Prisma Cloud won’t prevent any write operation to it, but will raise an alert.