Infinity Next Deployment and Configuration

This section details how to configure the policy and install the Nano-Agents to enforce it.

Configuring Infinity Next Policy

Assets, Zones, Practices and Rules

It is not necessary to define rules. When you define Assets/Zones, practices are defined for each of them, which generates automatic rules that you can view in the applicable page.

Notes:

  • The details for the configuration of some Assets and Zones to apply security to and use for configuration in your security settings are described for each security practice in other parts of this guide. This section gives a general explanation for the definition of an Asset or a Zone with security practices.

  • Some of the asset types, when added, prompt a unique wizard that guides you through the definition process. The wizards are explained later in this document for each asset type.

  • If you plan to use as your enforcement point, the CloudGuard Infinity Next Gateway (explained later in this guide), it is necessary to define web application assets to configure the reverse proxy functionality of the product. See CloudGuard Infinity Next Gateway.

Define a New Asset or Zone

Browse to the Assets or Zones page below Cloud, or IoT > click Add. For Assets, it is necessary to also select the type of asset that you want to define.

Define a required name for your new object and additional fields when needed, as explained later in this document, for each object type.

Defining the Practices for Assets and Zones

In the right menu field, below Practices, select the Practices that you want to apply on this Asset/Zone.

Roadmap - In a later release, you will also be able to define a custom practice that you created in the Practices page.

  • For each of the practices, their configuration appears under the applicable tab, which enables you to edit them:

  • In the Behaviors tab, you will be able to configure additional exceptions such as trusted sources relevant for this specific Asset/Zone.

  • In the corresponding Access Control and Threat Prevention web pages in the side menu, you will be able to see automatic rules generated by this configuration.

Triggers

A Trigger is another action bound to a rule that occurs when there is security practice match to a relevant event.

When a rule is fired and the security practice found a match, it starts a trigger.

To configure a trigger:

  1. Click Triggers.

    A trigger configuration window opens.

  2. Select Add and select the trigger type.

    A window opens with tabs to define a new trigger.

    Example Log trigger:

    Name - (Required) Give your trigger object a useful name.

Managing configuration via APIs

The Infinity Next management application provides APIs for all configuration actions. It provides them through using GraphQL APIs.

A user must first authenticate using API keys provided in the Infinity Portal as explained below, and then use the Infinity Next application’s APIs.

What is GraphQL?

GraphQL is a strongly typed API query language. It allows clients to define the structure of the data required, and exactly the same structure of the data is returned from the server. This avoids both the problems of over and under-fetching data, while also allowing for a more powerful and flexible API.

Note - before reading further into our GraphQL documentation we strongly recommend you familiarize yourself first with GraphQL and GraphQL queries via the official GraphQL documentation.

Authentication to Infinity Portal

Creating API Keys

Go to Global Settings->API Keys and create a new API Key for the Infinity Policy service. Configure the Expiration date.

After clicking on Create your Client ID and Secret Key will be shown for a single time. Copy it to a secure location as they are not retrievable once the window will be closed.

Important - The KEY provides allow access to your account from the Internet. Secure your keys very carefully. We strongly recommend to use a vault solution for holding your keys and to rotate them periodically.

For further information see the Infinity Portal Administration Guide > Global SettingsAPI Keys.

Using API Key to authenticate

Before using the specific GraphQL API, you first need to create a valid token to Infinity Portal.

Infinity Portal uses REST API. Use the POST <server address>/auth/external API using the relevant server address as documented here, to generate a JSON Web Token (JWT).

This token allows temporary usage of the application API using Bearer Authentication (as explained in RFC 6750) until token expiration or revocation. It should be used as Authorization: Bearer [token] header for each API call.

Example of adding the authorization bearer token "abcde-f12345f" to an API call using curl:

curl -H "Authorization: Bearer abcde-f12345f" https://<infinity portal address>/app/i2/graphql

Viewing and using Infinity Next API

View and usage without an external client (using GraphiQL)

Under Support->API we provide a GraphiQL interface for:

  1. Viewing all available functions, divided into query functions that are available for Read-Only users as well, and mutations functions which change configuration and are not available for Read-only Users.

  2. Running custom requests and seeing the result received from the backend.

    Note - Configuration changes (mutation functions) done using this API will still require clicking on the Publish button in order to be saved in the database and unlocked for usage of other administrators, or by running the publishChanges API request.

The left hand screen allows you to modify GraphQL JSON queries. The middle screen shows the response upon clicking the play button. The right hand screen is the GraphQL documentation of all available functions.

Sending GraphQL requests from external sources

If you have a JWT temporary token using the authentication API described above, and you are familiar with creating a query or a mutation operation JSON body, then you can post such a JSON to the following URL with the JSON as the request body:

https://<infinity portal address>/app/i2/graphql

Note - The infinity portal address depends on the region you are working with, and can be seen in the Infinity Portal REST API documentation.

Several clients (e.g. Postman) have a GraphQL mode that allows easily constructing the exact request body from the GraphQL JSON.

GraphQL methods

Most methods documented are about CRUD operations vs object in the database.

Read operations (queries) usually start with get* prefix, and GraphQL allows you to modify what exact fields you are interested in viewing. There are also read operations with the suffix *UsedBy which allow you to check for an object if it used by other objects (for example, a practice that is used by multiple assets and zones).

All non-Read operations are methods that are called mutations (as opposed to queries). For Create, Update and Delete operations on objects, the prefixes are usually new*, update* and delete*.

add*, move* and remove* are parallel prefixes for connecting between existing objects (for example, adding a practice to an asset).

share* methods are explained better in the objects structure overview – they are used for taking an existing object, which up until now has been used and owned by a single other object, and making them available to be used and shared by other objects as well (for example, taking an existing practice owned by a specific asset object, and making it globally available to be reused by additional assets and zones).

There are also additional special actions:

  • Agent revocationrevoke* methods

  • Publish configuration – A critical method to activate when the changes are completed, otherwise the objects will be locked for other administrators. There is also a method for discarding all changes.

  • Policy enforce operations – Sending a request to enforce the latest published policy by agents. The query method isEnforcePolicy provides information if a published policy is waiting to be enforced.

Overview of the Infinity Next Management objects structure

Object structure overview

The main hierarchy of objects in Infinity Next Management starts with an asset object (which can come in a variety of types) or a zone object (which represents a usually-dynamic group of assets according to a query).

This object can own other objects according to the following hierarchy:

Note - In GraphQL an object can be owned by another object, or can be owned by a connection between 2 objects (and then it will have 2 owning IDs).

When creating an object that should be owned by a parent object, run the relevant get* method on the owning object to get its ID value prior to the object creation method call.

There are several objects in the behavior family. Some can be owned by an asset/zone object and some can be owned by the connection between an asset/zone and a practice.

  • The connection between an Asset/Zone and a Practice can own the following behavior object types:

    WebUserResponseBehavior

    ExceptionBehavior

  • A Web API or a Web Application asset can own the following behavior object type:

    TrustedSourceBehavior

Object sharing (visibility field)

Practices and behavior objects also have a visibility field that can have either the value of “Local” or “Shared”. A “Local” visibility object must contain an owning object ID and cannot be used by any other object in parallel. It will be deleted when the parent object is deleted as it is wholly owned by it.

However, through the share* methods you can make a “Local” visibility object into a “Shared” one which can be owned by multiple objects – Basically you are turning it into a globally used object which will not be deleted if any of the parent objects are deleted. The “Share” action is irreversible – A Shared object cannot be turned into a “Local” visibility object.

When creating a practice or a behavior object make sure you have IDs of the parent object/s by using the relevant get* method/s if the visibility is set to “Local”. An empty owning ID can only exist if the visibility is set to “Shared” during the object creation.

Deploying Nano-Agents

The Infinity Next platform provides a variety of Nano-Agents that can attach to complex hybrid and dynamic environments. The installation usually uses a simple binary, called Nano-Egg, that creates a trust with Infinity Next's platform in the Cloud. It then deploys (the egg "hatches", in a manner of speaking) the relevant Nano-Agent services based on policy and the environment in which it is installed. In addition, it updates it automatically to the latest version (based on the configuration).

Note - Not all security capabilities are available in all Nano-Agents. See the applicable section and security capability to learn which agents to install to enforce a specific capability.

Agent Profile and Registration Tokens

To create a Nano-Agent profile:

  1. Connect to the Check Infinity Portal and navigate to Infinity Next.

  2. From the Navigation Toolbar, select Enforcement.

  3. Select Profiles > New.

    1. Give the profile a name.

    2. Select Agent as the profile's type.

    3. Enter the number of Nano-Agents to represent the maximum quantity of Nano-Agents that can register with this profile.

    4. Select Token as the registration attribute.

    5. Select how to create the token, either one unique token for each Nano-Agent or one reusable token for all Nano-Agents.

    6. Save the profile.

    7. Select the new profile > in the Profile Object's details click Copy to receive the token(s):

      1. For a profile defined with one token for each Nano-Agent, download a CSV file with all tokens.

      2. For a profile defined with a reusable token, in the Profile Object's details click Copy. You can use this type of token multiple times, until the limit in the Number of Agents field.

    Important - Keep the tokens secure as they serve as a method to establish a trust between the Nano-Agent and the Fog. In addition, it connects the Nano-Agent to the specific tenant in which the token was generated.

Supported Deployments

Deployment options for Check Point Infinity Next Nano-Agent:

  • Infinity Next Gateway is provided as a Virtual Machine that runs on a Check Point Gaia Operating System with a Reverse Proxy and Check Point Nano-Agent. This options is available for:

    • Amazon Web Services (AWS), available in the AWS Marketplace

    • Microsoft Azure, available in the Azure Marketplace

    • Standalone Virtual Machine that can be deployed inVMware

  • Infinity Next Container deployed in Docker Environments

  • An Embedded Nano-Agent deployed:

    Linux machine (for access control)

    Linux machines with any NGINX Webserver/Reverse Proxy (for AppSec)

    Example:

Roadmap - An Embedded Nano-Agent deployed on top of Apache, Envoy, and other Web Servers, API Servers, and Reverse Proxies.

Note - Downloads and Deployment links are documented for each type of profile object in the right hand screen, when you click on the profile object through Cloud > Profiles.

Basic Nano-Agent Deployment

To install the Nano-Agent:

  1. Prepare a token to use with this Nano-Agent installation.

  2. Start an SSH connection to the VM that you want to protect with a Nano-Agent.

  3. Download the Nano-Egg:

    wget https://checkpoint.com/nanoegg

  4. Provide execution privileges to the Nano-Egg run:

    chmod +x nanoegg

  5. Run the Nano-Egg installation file with this common usage:

    ./nanoegg [--uninstall] | [--install --token <token> [options...]

    Or, for a full list of proprieties, see these options:

    --uninstall - Removes the Nano-Agent installation

    --install - Selects the properties to install on a new Nano-Agent.

    --token <token> - Registration token taken from the profile in the Infinity Portal.

    --proxy [user:pass@]<proxy URL>:<proxy port> - Define the proxy details that you want to use. Or, select none if you do not want to use a proxy (default is taken from the OS configuration).

  6. Monitor the Nano-Agent's status with this command: cpnano -s

  7. Navigate to the Infinity Portal > Enforcement, go to the (Nano) Agents page and make sure it shows a new Nano-Agent.

Deploying a Nano-Agent as a Container

Prerequisite:

  • Linux host machine

This solution supports environment either with or without a NGINX container that is set to on.

Best Practice - If you do not already have a NGINX container in your environment, download Check Point's image with these steps.

In environments where the NGINX server is a container that acts as a reverse proxy for upstream locations and, or containers, you can use a Nano-Agent as a different container to receive a stream of all HTTP data from the NGINX container. To do this, the NGINX server loads a standard loadable module that communicates with a Nano-Agent container.

To Install the Nano-Agent as a container:

  1. Add the Nano-Agent container image to the deployment CI's applicable container management system.

  2. As part of your CI, use the registry that follows (in Docker Hub) to pull the Nano-Agent image:

    checkpoint/infinity-next-nano-agent

  3. Prepare a token in advance to use in the Nano-Agent installation.

  4. Run the Nano-Agent with this command (-e https_proxy parameter is optional):

    docker run -d --name=agent-container --ipc=host -v=<path to persistent location for agent config>:/etc/cp/conf -v=<path to persistent location for agent data files>:/etc/cp/data -v=<path to persistent location for agent debugs and logs>:/var/log/nano_agent -e https_proxy=<user:password@Proxy address:port> -it <agent-image> /cp-nano-agent --token <token>

  5. Create or replace the NGINX container using the registry that follows (in Docker Hub) to pull this NGINX image for this deployment:

    checkpoint/infinity-next-nginx

  6. Change the NGINX docker "\run" command, add the "--ipc=host" parameter.

  7. Run the execution commands for the two containers and make sure that it is running, use docker ps.

  8. Navigate to the Infinity Portal > Enforcement > go to the (nano) Agents page and make sure that the new Nano-Agent is added.

CloudGuard Infinity Next Gateway

You can deploy a full machine with a reverse proxy that contains a Nano-Agent already in it. This product is called CloudGuard Infinity Next Gateway and runs on Check Point's Gaia operating system.

You can define multiple web applications with their reverse proxy configuration in the Infinity Next app, and bind them to a specialized profile for CloudGuard Infinity Next Gateway deployments. To scale the machines with the same configuration, connect all instances in a scaling group to the same profile.

Deploying CloudGuard Infinity Next Gateway

Deployment options for the CloudGuard Infinity Next Gateway:

  • As a Virtual Machine on VMware ESXi 6.5 and later

  • As a Virtual Machine on Microsoft Hyper-V

  • Through the Azure Marketplace

  • Through the AWS Marketplace

Configuring the Dedicated Check Point Reverse Proxy

A Nano-Agent profile object (with a unique web application configuration) must be created for each Reverse Proxy.

  1. Go to Enforcement > Profiles.

  2. Create an AppSec Gateway profile.

    Note - The action adds a Reverse proxy tab.

  3. Do the steps in Deployment and Configuration > Agent Profile and Registration Tokens that describe how to define the registration tokens for the Nano-Agents installed as part of the deployment to the Infinity Next cloud.

For each web asset that you define through the Assets page and configure to use this profile, does that which follows:

Includes Reverse Proxy settings in its General tab, most importantly the upstream URL for that web asset. The upstream URL is the backend server’s URL, to which the reverse proxy redirects the relevant traffic sent to the exposed public URL.

The web asset is visible with its Reverse Proxy definitions in its Reverse Proxy tab.

Go to Environment -> Assets and define web applications similarly to the explanation in the "Configuring AppSec Assets" section in this guide.

But, for "Web application" type assets, it is also necessary to go to New Asset > Reverse Proxy and add the Reverse proxy configuration for that specific app. Each asset of this type can now be added to the appropriate Nano-Agent profile you created through the "Reverse Proxy" tab list.

Upstream URL - The defined upstream URL for this specific web application (the URL is translated into the external URL as defined in the General tab). The upstream URL is the backend server’s URL, to which the reverse proxy redirects the relevant traffic sent to the exposed public URL.

Proxy Settings:

Supported Keys Purpose

Allowed Values

setHeader

Allows to redefine or append fields to the request header passed to the proxied server. Use text, variables, or a combination of both.

<Header name>:< Header value>

For host header:

Host:<value>

Example:

Host:$host

connectTimeout

Defines a timeout to establish a connection with a proxied server.

Positive number

readTimeout

Defines a timeout to read a response from the proxied server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the proxied server does not transmit anything within this time, the connection is closed.

Positive number

proxySendTimeout

Sets a timeout to transmit a request to the proxied server. The timeout is set only between two successive write operations, not for the transmission of the whole request. If the proxied server does not receive anything within this time, the connection is closed.

Positive number

keepAliveTimeout

Sets a timeout in which a keep-alive client connection stays open on the server side. The zero value disables keep-alive client connections.

Positive number

accessLog

Activates the access.

true/false

healthCheck

Checks proxied server status, each minute.

true/false

dnsServer

Configures name servers used to resolve names of upstream URLs (the backend servers’ URL) into addresses.

Ip/<IP>:<Port>

For example:

172.15.14.8090

ProxySslName

Allow to override the server name used to verify the certificate of the proxied HTTPS server. And, allow it to pass through SNI when you establish a connection with the proxied HTTPS server

String of server name

ProxySSlVerify

Enables or disables verification of the proxied HTTPS server certificate.

On/off

nginxIncludeLines

Set of NGINX configuration lines separated by a ; to be added to this asset configuration file.

<line>; <line>;

certificateFilePath

Path to manually uploaded certificate file in the Infinity Next Gateway machine in VMWare and Hyper-V, or a non-scale set cloud solution.

Full path to a .pem file

certificateKeyPath

Path to manually uploaded certificate key file in the Infinity Next Gateway machine in VMWare and Hyper-V, or a non-scale set cloud solution.

Full path to a .key file

How to Manually Upload Certificates

Note - The UI does not support the transfer of customer certificate files from management to the agent. For the Nano-Agent to use the certificates, you must manually place them in Infinity Next Gateway.

To manually upload your certificates to the VM, complete steps:

  1. Log in to the CloudGuard Infinity Next Gateway machine.

  2. Transfer the certificate and key files to the machine.

  3. If you did not create a Nano-Agent profile object configured as the Infinity Next Gateway in the Check Point Portal, then create a new Nano-Agent profile before you do step 4. See Configuring the Dedicated Check Point Reverse Proxy.

    Important - Keep the name used in the -o flag. This name is used again.

  4. In the Check Point Portal, go to Environment > Assets > select the asset you want to edit.

  5. From the Reverse proxy tab, make sure that the check box Deploy certificate manually is selected.

  6. From Proxy Settings, click New.

  7. In the Key column, select certificateFilePath, and in the Value column enter the full path of the certificate file uploaded to the machine. The file must have a .key extension.

  8. Again, click New.

  9. In the Key column, select certificateKeyPath, and in the Value column enter the full path of the certificate key file you uploaded to the machine. The file must have a .pem extension.

  10. Click Save > Enforce.

Infinity Next Events

Event logs view

Use the Event log to see the list of events and get details about specific events.

To see the Event log:

From the Navigation Toolbar, select Monitor > All Events.

Or,

Drill down on a field in the AppSec dashboard.

When you click on an event, a Log Card shows details about the specific transaction based on the trigger used.

Example Log Card:

Event Severity Classification

Protect Web Service Name

HTTP Transaction Information

Threat Prevention

To perform a quick filter of the table:

  1. Right-click on a specific value in the table in the Log Card.

  2. Click Enter. The filtered Log Card window opens.

Infinity Next Event Viewer and Query Language

Time filter

Log filtering can be done using a query as explained below. However, time filtering is done via a separate UI configuration at the top left corner of the logs view screen.

Query Language Overview

A powerful query language lets you show only selected records from the log files, according to your criteria. To create complex queries, use Boolean operators, wildcards, fields, and ranges. This section refers in detail to the query language.

When you use SmartConsole to create a query, the applicable criteria show in the Query search bar.

The basic query syntax is [<Field>:] <Filter Criterion>.

To put together many criteria in one query, use Boolean operators:

[<Field>:] <Filter Criterion> {AND|OR|NOT} [<Field>:] <Filter Criterion> ...

Most query keywords and filter criteria are not case sensitive, but there are some exceptions. For example, "sourceip:<X>" is case sensitive ("SourceIP:<X>" does not match). If your query results do not show the expected results, change the case of your query criteria, or try upper and lower case.

When you use queries with more than one criteria value, an AND is implied automatically, so there is no need to add it. Enter OR or other boolean operators if needed.

Criteria Values

Criteria values are written as one or more text strings. You can enter one text string, such as a word, IP address, or URL, without delimiters. Phrases or text strings that contain more than one word must be surrounded by quotation marks.

One word string examples:

  • Accept

  • Medium

  • 192.168.2.1

  • www.urlexample.com

  • 4a6ad969-398c-4075-bba6-e30f931d0a4f

Phrase examples

  • "My Asset"

  • "Schema Validation"

  • "SQL Injection"

IP Addresses

IPv4 and IPv6 addresses used in log queries are counted as one word. Enter IPv4 address with dotted decimal notation and IPv6 addresses with colons.

Examples:

  • 192.0.2.1

  • 2001:db8::f00:d

You can also use the '*' wildcard character with IP addresses, as well as the standard network suffix, to look for all logs that match IP addresses within a range.

Examples:

  • 192.168.0.0/16 - shows all records for the source IP 192.168.0.0 to 192.168.255.255 inclusive.

  • 192.168.1.0/24 - shows all records for the source IP 192.168.1.0 to 192.168.1.255 inclusive.

  • 192.168.2.* - shows all records for the source IP 192.168.2.0 to 192.168.2.255 inclusive.

  • 192.168.* - shows all records for 192.168.0.0 to 192.168.255.255 inclusive.

NOT Values

You can use NOT <field> values with Field Keywords in log queries to find logs for which the value of the field is not the value in the query.

Syntax:

NOT <field>: <value>

Example

NOT src:10.0.4.10

Wildcards

You can use the standard wildcard characters (* and ?) in queries to match variable characters or strings in log records. You can use more than the wildcard character.

Wildcard syntax:

  • The ? (question mark) matches one character.

  • The * (asterisk) matches a character string.

Examples:

  • MyAsset? - shows MyAsset1 and MyAsset2, but not MyAsset12.

  • MyAsset* - shows MyAsset1, MyAsset12, and MyAsset209-d.

If your criteria value contains more than one word, you can use the wildcard in each word.

For example, “Asset* AZ*” - shows “Asset1 AZ45”, “Asset23 AZ90”, and so on.

Note - Using a single ‘*’ creates a search for a non-empty value string. For example assetname:*

Infinity Next Events Field Keywords

You can use predefined field names as keywords in filter criteria. The query result only shows log records that match the criteria in the specified field. If you do not use field names, the query result shows records that match the criteria in all fields.

This table shows the predefined field keywords alongside their view name in the logs table and log cards.

Field View Name Keyword

Description

Event Name

eventname

This field describes the event in text

Event Severity

eventseverity

Info, Low, Medium, High, Critical

Event Priority

eventpriority

Low, Medium, High, Urgent

Agent UUID

agentid

UUID of the agent creating the log, if applicable

Security Action

securityaction

The action taken by the security practice upon this event

Asset Name

assetname

The name of the asset, protected by the security practice that found a match and issued this log

Asset ID

assetid

The object ID of the asset, protected by the security practice that found a match and issued this log

Zone Name

zonename

The name of the zone, protected by the security practice that found a match and issued this log

Zone ID

zoneid

The object ID of the zone, protected by the security practice that found a match and issued this log. This can be used unique searches when given names are similar.

Practice Type

practicetype

The type of the security practice that found a match and issued this log (e.g. "Threat Prevention")

Practice SubType

practicesubtype

The subtype of the security practice that found a match and issued this log (e.g. "Web Application")

Practice Name

practicename

The name of the security practice that found a match and issued this log

Practice ID

practiceid

The object UUID of the security practice that found a match and issued this log. This can be used unique searches when given names are similar.

Source IP

sourceip

Source IP address of the network traffic that caused the matched event

Source Port

sourceport

Source TCP/UDP Port of the network traffic that caused the matched event

Source Country

sourcecountryname

Source country name of the network traffic that caused the matched event, if applicable

Destination IP

destinationip

Source IP address of the network traffic that caused the matched event

Destination Port

destinationport

Destination TCP/UDP Port of the network traffic that caused the matched event

Destination Country

destinationcountryname

Destination country of the network traffic that caused the matched event, if applicable

IP Protocol

ipprotocol

IP Protocol of the network traffic that caused the matched event

Source Identifier

httpsourceid

The source identifier as determined from the HTTP traffic according to configuration (according to the X-Forwarded-For header, a cookie, source IP address, etc.)

HTTP Host

httphostname

The source identifier as determined from the HTTP traffic according to configuration (according to the X-Forwarded-For header, a cookie, source IP address, etc.)

HTTP Method

httpmethod

HTTP Method as determined from the HTTP traffic (e.g. GET, POST, etc.)

HTTP URI Path

httpuripath

HTTP URI path as determined from the HTTP traffic

AppSec Incident Type

waapincidenttype

AppSec incident types (e.g. LDAP injection, SQL injection, etc.)

AppSec Incident Details

waapincidentdetails

A more granular description of the event caught by appSec

AppSec User Reputation

waapuserreputation

AppSec user reputation for the identified source

Matched Location

matchedlocation

The location within the HTTP traffic where an indicator, causing this event, was detected (e.g. "referer parameter")

Matched Parameter

matchedparameter

The parameter name within the HTTP traffic, where an indicator, causing this event, was detected (e.g. "uuid")

Matched Sample

matchedsample

The traffic data where the indicators were detected and created the event

AppSec Found Indicators

waapfoundindicators

The detected indicators which created the event

AppSec Override

waapoverride

Override configuration for this event

Syntax for a field name query:

<field name>:<values>

  • <field name> - One of the predefined field names

  • <values> - One or more filters

Examples:

  • sourceip:192.168.2.1

  • securityaction:(Prevent OR Drop)

You can use the OR Boolean operator in parentheses to include multiple criteria values.

Important - When you use fields with multiple values, you must:

  • Write the Boolean operator, for example AND.

  • Use parentheses.

Boolean Operators

You can use the Boolean operators AND , OR , and NOT to create filters with many different criteria. You can put multiple Boolean expressions in parentheses.

If you enter more than one criteria without a Boolean operator, the AND operator is implied. When you use multiple criteria without parentheses, the OR operator is applied before the AND operator.

Examples:

  • practicetype:"Threat Prevention" AND securityaction:Prevent

    Shows log records caused by “Threat Prevention” type security practices where traffic was blocked.

  • 192.168.2.133 10.19.136.101

    Shows log entries that match the two IP addresses. The AND operator is presumed.

  • 192.168.2.133 OR 10.19.136.101

    Shows log entries that match one of the IP addresses.

  • (assetname: "MyAsset1" OR assetname: "MyAsset2" AND NOT securityaction:PreventAccept

    Shows all log entries for assets “MyAsset1” and “MyAsset2” that are without the “Accept” security action. The criteria in the parentheses is applied before the AND NOT criterion.

  • sourceip:(192.168.2.1 OR 192.168.2.2) AND destinationip:17.168.8.2

    Shows log entries from the two source IP addresses if the destination IP address is 17.168.8.2. This example also shows how you can use Boolean operators with field criteria.