> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-cloud-runtime-security/web-and-api-security-waas/secure-your-api-landscape/configure-api-security-from-end-to-end.md). # Configure API security from end to end Implementing end-to-end API security means establishing comprehensive protection across the entire API lifecycle. This process begins by integrating with third-party cloud providers to enable thorough scanning of your APIs for threats and vulnerabilities. Following this, you'll configure profiles for agent-based protection, which actively safeguards your APIs in real-time. This ensures that every potential vulnerability, from authentication and authorization issues to data encryption and threat monitoring, is addressed across your entire API ecosystem. For more information on how to configure, refer to: * [Third-party integrations](/cortex-cloud-runtime-security/web-and-api-security-waas/secure-your-api-landscape/configure-api-security-from-end-to-end.md#third-party-integrations) * [Agent-based protection](/cortex-cloud-runtime-security/web-and-api-security-waas/secure-your-api-landscape/configure-api-security-from-end-to-end.md#agent-based-protection) ### Third-party integrations Easily configure the settings in both Cortex Cloud and your cloud service to retrieve and collect API data for further analysis by Cortex's comprehensive [API security](/cortex-cloud-runtime-security/web-and-api-security-waas/secure-your-api-landscape/gain-visibility-and-assess-risk-of-api-endpoints.md) capabilities, which provide a transparent view of API traffic, helping to identify potential security threats. **Ingest AWS API Gateway** Integrate AWS API Gateway with Cortex Cloud to begin scanning the APIs for potential threats and vulnerabilities.

Settings in Cortex Cloud

In Cortex Cloud, set up the **AWS API Gateway** data source to integrate with the AWS API Gateway. 1. From **Settings** → **Data Sources** , click ![add\_data\_source.png](/files/vzdVYm1DD2KIDGu3DfEO) and search for **AWS API Gateway** and then click **Connect** or **Connect Another Instance**. 2. In the **AWS API Collector** wizard, enter a relevant name and click **Create and Proceed**. 3. Copy the key and save it for later.

Note

You must generate a new key if you did not save.

4. Click **Close**.

Settings in AWS Management Console

Configure the settings in the AWS Management Console to integrate with Cortex Cloud: 1. Log in to the [AWS Management Console](https://aws.amazon.com/console/). 2. In AWS Management Console, navigate to **API Gateway**. 1. Expand the left-hand menu of the API project. 2. Go to **Settings** → **Logging** and click **Edit**. Verify that the **CloudWatch log role ARN** is filled. 3. Click **Stages** and from **Stages**, select the relevant stage. 4. From **Logs and Tracing**, click **Edit** and configure the following: * **CloudWatch Logs**: Select **Errors and info logs** * Select **Data tracing** * Select **Detailed metrics** 5. Click **Save**. This creates a unique log group inside CloudWatch. 3. Open CloudWatch in another window by typing **CloudWatch** in the search bar. 1. Go to **Logs** → **Log groups** and search for the log group just created. The group name follows the following format: `“API-Gateway-Execution-Logs_/”` 2. Click the log group, and from the **Log group details**, copy the **ARN**. 4. Return to **Edit logs and tracing**, go to **enable the custom access logging** , and paste the ARN without the \* in the **Access log destination ARN** field. Example 45. ARN: `arn:aws:logs:us-east-1:123456789012:log-group:API-Gateway-Execution-Logs_153tp249k2/Prod:*` Paste in **Access log destination ARN**: `arn:aws:logs:us-east-1:123456789012:log-group:API-Gateway-Execution-Logs_153tp249k2/Prod` 5. In **Log format**, type the following and click **Save**: ```programlisting ($context.requestId) accountID: $context.accountId; requestTimeMs: $context.requestTimeEpoch; path: $context.path; region: us-east-2; apiID: $context.apiId; stage: $context.stage; extensionVersion: 1.0 ``` 6. Click **Create Firehose stream**. 1. Configure the following: * **Source**: **Direct PUT** * **Destination**: **HTTP Endpoint** * **Firehose stream name**: Add a relevant name. 2. In **Destination settings**, configure the following: * **HTTP endpoint URL** : Add the API URL from Cortex Cloud. * **Authentication**: Select **Use access key**. * **Access key**: Paste the generated token from **AWS API Gateway**. * **Content encoding**: Select **GZIP**. 3. In **Backup settings**, configure the following: * **Source record backup in Amazon S3**: select **Failed date only**. * **S3 backup bucket**: select a bucket or enter a bucket URI. 4. Click **Create**. It takes up to 5 minutes for the stream to be activated. 7. Refer to [Subscription filters with Amazon Data Firehose](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#FirehoseExample). To create an IAM Role and provide CloudWatch with the appropriate permissions for the streaming, refer to steps 8-11. After the Data Firehose delivery stream is active and you have created the IAM role, you can create the CloudWatch Logs subscription filter. The subscription filter immediately starts the flow of real-time log data from the chosen log group to your Amazon Data Firehose delivery stream: ```programlisting aws logs put-subscription-filter \ --log-group-name "" \ --filter-name "" \ --filter-pattern "" \ --destination-arn "arn:aws:firehose:region:123456789012:deliverystream/" \ --role-arn "arn:aws:iam:::role/" ```

Important

Leave –filter-pattern empty as displayed above.

After you create the filter, go back to **Data Sources** → **AWS API Gateway** to see the logs starting to come in.

Note

If no logs are showing, send some API requests on Postman or CURL.

**Ingest Azure APIM** {% hint style="info" %} ### Notice Requires the Data Collection add-on. {% endhint %} Integrate Azure APIM with Cortex Cloud to start scanning its APIs for potential threats and vulnerabilities. You need to set up a policy that enables you to customize the behavior of managed APIs. You can configure the sending of HTTP request/response data to Cortex Cloud. The data is saved and analyzed by API security modules, which provide information on the security risks associated with the APIs. {% hint style="info" %} ### Note Microsoft Azure APIM service must be running before starting to configure the integration. {% endhint %}

Settings in Cortex Cloud

In Cortex Cloud, set up the **Azure API Management** data source to integrate with the Azure API Gateway. 1. From **Settings** → **Data Sources & Integrations** , click **+ Add New**, search for **Azure API Management**, then hover over it and click **Add** or **Add Instance**. 2. In the **APIM Collector** wizard, enter a relevant name and then click **Create and Proceed**. 3. Copy the key and paste it somewhere so that you can access it for later. If you forget to record the key and close the window, you must generate a new key and repeat this process. 4. Click **Close**.

Settings in Azure APIM policy

Configure an inbound and outbound policy to send HTTP traffic data of the APIs to Cortex Cloud. You can configure a policy for individual operations (endpoints) or all operations of a single API. Follow the steps to configure the policy. 1. Log in to [Microsoft Azure](https://portal.azure.com/). 2. Go to **API Management services** and select the relevant service. 3. From the left-hand menu, select APIs → Named values.

Note

From the URL, save the UUID and the resource group - /resource/subscriptions/<UUID>/resourceGroups/<ResourceGroup>.

The UUID is the Azure account/subscription ID and the resource group, which is the group where the APIM Service is defined.

4. Configure the settings in each of the sections. Follow the steps in the order they are listed.

Note

Use the search to navigate to the specific section.

**Named values**: Add the values: * cloud-account-id * **Type**: Plain * **Value**: The UUID you saved from the previous step. * cloud-resource-group * **Type**: Plain * **Value**: The resource group you saved from the previous step. * cortex-api-key * **Type**: Secret * **Value**: The token that you saved from data sources in Cortex. * cortex-api-url * **Type**: Plain * **Value**: The API URL from data sources in Cortex. * cortex-http-body-size-limit-bytes * **Type**: Plain * **Value**: 131072

Note

131072 bytes = 128 KB. This value determines the size (in bytes) of request and response bodies to send to Cortex. Any bytes beyond this limit are truncated.

**APIs**: From the left-hand menu, go to APIs → APIs. 1. You can create a policy on a specific API or choose to create a policy on all APIs. 2. From **Inbound Processing**, click ![code\_bracket.png](/files/yYZ3K1C58gh68C58oZC3). The Policies screen opens. There are three sections: * `` * `` * `` The `` includes the request before it's sent to the ``. The parameters are saved before they're sent. Add the following inside the ``: ```programlisting

```

Note

If any other inbound policies should be added, they must be added after these elements.

The `` includes the request before it returns a response. Add the following inside the \ element, at the end, after the other child elements: ```programlisting

POST

application/json

@{ string requestBody = context.Variables.GetValueOrDefault("requestBody"); string responseBody = context.Response.Body.As(preserveContent: true); int bodySizeLimit = {{cortex-http-body-size-limit-bytes}}; bool requestBodySizeExceedsLimit = requestBody.Length > bodySizeLimit; bool responseBodySizeExceedsLimit = responseBody.Length > bodySizeLimit; return JsonConvert.SerializeObject(new { accountId = "{{cloud-account-id}}", serviceId = context.Deployment.ServiceId, requestId = context.RequestId, url = context.Request.OriginalUrl, httpMethod = context.Request.Method, requestBody = requestBodySizeExceedsLimit ? requestBody.Substring(0, bodySizeLimit) : requestBody, requestBodyTruncated = requestBodySizeExceedsLimit, requestHeaders = JsonConvert.DeserializeObject(context.Variables.GetValueOrDefault("requestHeaders")), timestamp = new DateTimeOffset(context.Timestamp).ToUnixTimeMilliseconds(), requestIpAddress = context.Request.IpAddress, statusCode = context.Response.StatusCode, responseBody = responseBodySizeExceedsLimit ? responseBody.Substring(0, bodySizeLimit) : responseBody, responseBodyTruncated = responseBodySizeExceedsLimit, responseHeaders = context.Response.Headers, region = context.Deployment.Region, subscription = context.Subscription, }); }

```

Important

If you want to add additional data to the <outbound>, add it at the start of the <outbound> code.

3. Click **Save**. Your APIM traffic collection is now configured. Request and response data for the configured endpoints are sent to Cortex Cloud for inspection by API security modules. 5. Go to **Azure API Management** data source to validate that data is ingested from Azure APIM. 6. Do the following to remove the integration of Azure APIM with Cortex Cloud: * Remove the snippets you added to the policies. * Remove the named values from the API service. * Delete the HTTP log collector from **Data Sources & Integrations** in Cortex.

**Ingest Apigee Proxy** {% hint style="info" %} ### Notice Requires the Data Collection add-on. {% endhint %} Integrate Apigee Proxy with Cortex Cloud to begin scanning the APIs for potential threats and vulnerabilities. The integration uses the Apigee’s JavaScript (JS) policy, implemented within a shared flow and deployed as a pre-proxy and post-proxy flow-hook in selected environments. The JS policy is designed to capture both request and response data from all traffic entering and exiting the proxy.

Settings in Cortex Cloud

In Cortex Cloud, set up the **Apigee** data source to integrate with the Apigee Gateway. 1. From **Settings** → **Data Sources & Integrations** , click **+Add New**, search for **Apigee**, then hover over it and click **Add** or **Add Instance**. 2. In the **Apigee Collector** wizard, enter a relevant name and then click **Create and Proceed**. 3. Copy the key and paste it somewhere so that you can access it for later. If you forget to record the key and close the window, you must generate a new key and repeat this process. 4. Click the **Download Configuration Script** link to download the plugin, which you can then upload from the Apigee Gateway. 5. Click **Close**.

First, download the resource file and then select the method to set up the integration with Apigee.

Run an automated script to deploy configurations to Apigee

Use the script for full deployment (with or without connecting a flow hook). {% hint style="info" %} ### Note The steps include the prerequisites that run the automated script that deploys files and configurations to Apigee. For manual configuration, refer to the section Manual deployment. {% endhint %} 1. Edit `deploy.sh` and add values for the following: | Variable | Description | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | PROJECT\_ID | Google project ID where Apigee is provisioned. | | ORG | Apigee organization. By default, this is the same as PROJECT\_ID. | | ENV | In Apigee, from the left-side menu, click **Environments** and copy the name of the environment you want to use. | | TARGET\_URL | Copy the URL for your Apigee Collector from the **Custom Collectors** page. For example, `https://api-{tenant external URL}/logs/v1/event.` | | APIsec\_API\_KEY | Token generated from Cortex Cloud. | 2. Check that the GCP user running the script has `IAM` permissions. ```programlisting apigee.resourcefiles.list apigee.resourcefiles.create apigee.resourcefiles.update apigee.sharedflows.get apigee.sharedflows.create apigee.deployments.create apigee.sharedflowrevisions.deploy apigee.flowhooks.attachSharedFlow apigee.keyvaluemaps.create apigee.keyvaluemaps.delete apigee.keyvaluemapentries.create ``` 3. Run the `deploy.sh` script: ```programlisting chmod +x ./deploy.sh ``` 4. Verify that the JavaScript policies have been added to the shared flows: Go to **Apigee** → **Proxy development** → **Shared Flows** and check that the following policies have been added. * `sf-api-sec-extension-postflow` * `sf-api-sec-extension-preflow` 5. Validate data ingestion: Send a request to the gateway and go to **Apigee** data source to validate that the data has been received from Apigee. 6. (Optional) Exclude unwanted domains from being tracked by APIsec: 1. Uncomment: DOMAIN\_EXCLUSION\_LIST. 2. Add the domains to exclude. 3. Edit `deploy.sh` and set the following variables: ```programlisting export DOMAIN_EXCLUSION_LIST="domain1,domain2" ``` 7. Discontinue the integration: 1. Edit `undeploy.sh`: ```programlisting export PROJECT_ID=example-project-id export ORG=$PROJECT_ID export ENVIRONMENT=example-env ``` 2. Run the undeploy.sh script: ```programlisting chmod +x ./undeploy.sh ``` Go to **Apigee** → **Proxy development** → **Shared Flows** and check that the following policies have been removed. * `sf-api-sec-extension-postflow` * `sf-api-sec-extension-preflow`

Configure Apigee's JavaScript for manual deployment

You can customize the shared flow and apply it to an existing flow hook (pre-proxy, post-proxy). Set up Apigee's JavaScript policy to send Apigee Collector's API data to Cortex Cloud. {% hint style="info" %} ### Note If you have an existing hookand would like to integrate with the shared flow, run the `deploy.sh` script, and select `n`' and exit at the prompt to create a new hook. Refer to the section Connect to existing hook. {% endhint %} 1. Edit `panw-api-sec-extension-configuration.properties` file: * Enter the `targetUrl` and `projectID`. * You can update 127KB of `maxBodyInspectionSizeKB`. * For domain exclusion, uncomment the line and add the URL to exclude. ```programlisting targetUrl= projectID= maxBodyInspectionSizeKB=127 // This is default and can be modified if needed. commonBinaryContentType=audio/,video/,image/, application/octet-stream,application/ogg,application/ pdf,application/zip,application/gzip,application/ vnd.rar,application/x-7z-compressed #domainExclusionList=example.com,example2.com/shopping ``` 2. Upload the edited `property set`: 1. Get a token to upload updates via an API request. For more information, refer to [property sets](https://cloud.google.com/apigee/docs/api-platform/cache/property-sets). Input: ```programlisting gcloud config config-helper --force-auth-refresh --format ``` Output: ```programlisting configuration: active_configuration: properties: compute: region: zone: core: account: disable_usage_reporting: project: credential: access_token: id_token: token_expiry: sentinels: config_sentinel: ``` 2. Copy the `` value from the output. 3. Upload the `property set` to Apigee: ```programlisting curl --silent -X GET "https://apigee.googleapis.com/v1/organizations/ /environments//resourcefiles/ properties" -H "Authorization: Bearer " ``` 4. Generate Key Value Map (KVM), which stores the Cortex API key that's encrypted ```programlisting curl --silent -X POST "https://apigee.googleapis.com/v1/organizations/ /environments//keyvaluemaps" -H "Authorization: Bearer " -H "Content-Type: application/json" --data-raw '{"name": "'"APISec-KVM"'", "encrypted": true}' ``` If there's an error when creating the KVM because of an existing name, delete the KVM and recreate. ```programlisting curl --silent -X DELETE "https://apigee.googleapis.com/v1/organizations/ /environments//keyvaluemaps/ $APISEC_KVM_NAME" -H "Authorization: Bearer " ``` Add the Cortex API key entry to the created KVM. ```programlisting curl --silent -X POST "https://apigee.googleapis.com/ v1/organizations//environments// keyvaluemaps/$APISEC_KVM_NAME/entries" -H "Authorization: Bearer " -H "Content-Type: application/json" --data-raw '{"name": "api-key","value": "'""'"}' ``` 5. Upload the shared flows: **Shared flows**: * `sf-api-sec-extension-postflow` * `sf-api-sec-extension-preflow` **Upload** Replace the `` with the shared flows: ```programlisting curl --silent -X POST --data-binary ".zip" -H "Content-Type: application/octet-stream" -H "Authorization: Bearer " "https://apigee.googleapis.com/v1/organizations/$ORG/ sharedflows?action=import&name=" ``` **Deploy** Input: ```programlisting curl --silent -X GET "https://apigee.googleapis.com/ v1/organizations//sharedflows/" -H "Authorization: Bearer " ``` Output: ```programlisting { "metaData": { "createdAt": "1736952161610", "lastModifiedAt": "1736952161610", "subType": "SharedFlow" }, "name": "sf-api-sec-extension-postflow", "revision": [ "1" // This is the revision number ], "latestRevisionId": "1" } ``` 6. Deploy ``: ```programlisting curl --silent -X POST -H "Authorization: Bearer " "https://apigee.googleapis.com/ v1/organizations/$ORG/environments// sharedflows/$sf/revisions// deployments?override=true" ``` 7. Verify API security shared flows were created: Go to **Apigee** → **Proxy development** → **Shared Flows** and check that the following policies have been added. * `sf-api-sec-extension-postflow` * `sf-api-sec-extension-preflow`

Connect to an existing hook

Follow the steps if you have an existing hook and would like to integrate with a shared flow. 1. Check for existing flow hooks. 1. Go to **Apigee** → **Management** → **Environments** and select the environment to hook the shared flow. 2. In the **Flow Hooks** tab, select the relevant flow hook. 2. Configure policy for shared flow to the existing hook. 1. Go to **Apigee** → **Proxy development** → **Shared Flows** and select the flow hook from the relevant environment.

Note

Start with the hook in pre-proxy.

2. From the **Develop** tab, expand **Policies** and select **Flow Callout**. 3. Enter a meaningful name and select the **Sharedflow**: `sf-api-sec-extension-preflow` , and then click **Create**. 4. From the **Develop** tab, select **Shared flows** and expand **Default**. 5. From **Select policy**, select **Select existing policy**, and select the policy just created and then click **Add**. 6. Repeat the previous steps for the post-proxy hook. Select the **Sharedflow**: `sf-api-sec-extension-postflow`. 7. Click **Save and Deploy**. The steps automatically run without linking to the hooks.

Important

This should only be done when there are already existing hooks, and API security shared flows can't be hooked as a standalone. Run the deployment script, but skip step 9 by passing n. This step publishes API security shared flows to the desired Apigee environment without setting them to flow hooks.

3. Limitations: * The API security extension deployment scripts currently do not support archive-deployment Apigee environments. Refer to [Manage archive deployment](https://cloud.google.com/apigee/docs/api-platform/deploy/manage-archive-deployments) for more information.

Note

Archive deployments are currently in preview and are subject to change.

* The API security extension for Apigee relies on flow-hooks, which are available only with Intermediate or Comprehensive Apigee Environment types. Refer to [Environments](https://cloud.google.com/apigee/docs/api-platform/fundamentals/environments-overview#environment-types) for more information. * For requests/responses with binary payloads, the binary payload is not sent to the collector for analysis; only the metadata (for example, HTTP headers, query parameters, etc.) is sent.

**Ingest Kong** {% hint style="info" %} ### Notice Requires the Data Collection add-on. {% endhint %} Integrate Kong with Cortex Cloud to start scanning its APIs for potential threats and vulnerabilities. You need to integrate a dedicated Kong HTTP log plugin. This plugin enables seamless traffic ingestion from your Kong API gateway to Cortex Cloud, allowing for comprehensive security measures such as OWASP Top-10, bot detection, access control, and more.

Settings in Cortex Cloud

In Cortex Cloud, set up the **Kong** data source to integrate with the Kong API Gateway. 1. From **Settings** → **Data Sources & Integrations**, click **+ Add New**, search for **Kong**, then hover over it and click **Add** or **Add Instance**. 2. In the **Kong Collector** wizard, enter a relevant name and then click **Create and Proceed**. 3. Copy the key and paste it somewhere so that you can access it later. If you forget to record the key and close the window, you must generate a new key and repeat this process. 4. Click the **Download Custom Plugin** link to download the plugin, which you can then upload from the Kong API Gateway. 5. Click **Close**.

Follow the steps to integrate Kong's API gateway with Cortex Cloud.

Download the Cortex custom plugin

Download the custom plugin gzip file. The file includes the `handler.lua`, `utils.lua`, and `schema.lua` files that make up the custom plugin. {% hint style="info" %} ### Note Contact support to obtain the custom plugin file. {% endhint %}

Provision Kong API gateway with the custom plugin

To deploy the custom plugin, refer to the Kong API documentation online: * [Kong Gateway](https://docs.konghq.com/gateway/latest/plugin-development/distribution/) * [Kong Konnect](https://docs.konghq.com/konnect/gateway-manager/plugins/add-custom-plugin/) * [Kong Ingress Controller](https://docs.konghq.com/kubernetes-ingress-controller/latest/plugins/custom/) Example 46. Kong as docker container 1. Add the plugin by mounting the plugin directory, adding it to the `Lua` package path variable, and then adding the plugin name to Kong’s plugin list variable. This can be done by passing the following arguments to the `docker run` command, assuming `./plugin_directory/kong` is the directory containing the `plugins/panw-apisec-http-log/ directory`. ```programlisting -v "./plugin_directory/kong:/tmp/custom_plugins/kong" \ -e "KONG_LUA_PACKAGE_PATH=/tmp/custom_plugins/?.lua;;" \ -e "KONG_PLUGINS=bundled,panw-apisec-http-log" ``` You may want to adjust the size of the nginx body buffer which is used by Kong internally. This size sets the upper limit on the amount of HTTP body bytes that can be mirrored by the plugin. By default, this value is 8192 bytes (8 KB). To change it, another argument can be passed to the docker - for example, setting it to 128 KB: ```programlisting -e "KONG_NGINX_HTTP_CLIENT_BODY_BUFFER_SIZE=128k" ``` See the NGINX syntax documentation for information on the allowed values of this variable.

Important

The size of the buffer must be equal or larger than the max body size setting in the plugin configuration, on every data plane node.

2. To verify that the plugin is installed, query Kong’s Admin API using the following command: ```programlisting curl admin-api-hostname:8001 | jq .configuration.loaded_plugins.'"panw-apisec-http-log"' ``` This prints **true** to the terminal if the plugin is loaded into the Kong instance.

Add and configure the custom plugin

Add and configure the plugin. 1. From the Kong Manager menu, go to **Plugins**. 2. From the **Plugins** page, scroll down to the **Custom Plugins** section. 3. Select **panw-apisec-http-log** and click **Edit** to configure the panw-apisec-http-log plugin settings. | Configuration | Description | Example | | -------------- | -------------------------------------------------------------------------------------------------------------- | --------------------------- | | Protocols | The request protocols the plugin will be applied to. | Either http, https, or both | | Cloud Context | Cloud context, such as AWS Account ID, GCP Project ID, Azure Subscription or an appropriate value for on-prem. | 987654321000 | | Cloud Provider | Cloud provider where Kong API Gateway is installed. | AWS. | | Cloud Region | Cloud region. | us-east-2 | | Cloud API Key | The collector authorization key provided by the Cortex platform. | | | HTTP Endpoint | The Cortex collector's endpoint URL. | | 4. Click the **View Advanced Parameters** to configure optional settings.

Note

The queue parameters can be updated to change when the plugin mirrors data to Cortex.

| Configuration | Description | Example | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | Instance Name | A custom name for this plugin instance. This is useful when applying different instances to different scopes. | Empty | | Tags |

An optional set of strings for grouping and filtering,

Note

Use commas to separate tags.

| Empty | | Keepalive | An optional value in milliseconds that defines how long an idle connection will live before being closed. | 60000 (60 seconds) | | Timeout | An optional timeout in milliseconds when sending data to Cortex. | 10000 (10 seconds) | | Max body size | The maximum body size to mirror in bytes (for example: 1024 is 1KB). Any bytes beyond this size are omitted from the request and response bodies. Must be <= 4 MB and <= the value of Kong's **nginx\_http\_client\_body\_buffer\_size** setting. | 131072 (128 KB), or the nginx body buffer size if it’s smaller. | | Queue Concurrency Limit | The number of queue delivery timers. -1 indicates unlimited. | 1 | | Queue.Initial Retry Delay | Time in seconds before the initial retry is made for a failing batch. | 0.01 (10 milliseconds) | | Queue.Max Batch Size | Maximum number of entries that can be processed at a time. | 1 | | Queue.Max Bytes | Maximum number of bytes that can be waiting in a queue, requires string content | Unlimited | | Queue.Max Coalescing Delay | Maximum number of (fractional) seconds to elapse after the first entry was queued before the queue starts calling the handler. | 1 | | Queue.Max Entries | Maximum number of entries that can be waiting in the queue. | 10000 | | Queue.Max Retry Delay | Maximum time in seconds between retries, caps exponential backoff. | 60 | | Queue.Max Retry Time | Time in seconds before the queue gives up calling a failed handler for a batch. | 60 | 5. Go to **Kong** data source to validate that data is ingested from the Kong API Gateway.

Limitations

* The plugin supports HTTP and HTTP/S protocols. * The plugin supports Kong API Gateway version 3.4.x and above. * The nginx body buffer size on each data plane node must be equal or larger than the **max body size** setting. * Request and response bodies will not be mirrored if their size exceeds the nginx body buffer size. When this occurs, it is indicated in the metadata that is sent to Cortex along with the HTTP transaction data. * The mirrored response body is the body returned from the upstream service. This means that changes made to the response body by other plugins, is not reflected in the mirrored data.

**Ingest-F5** {% hint style="info" %} ### Notice Requires the Data Collection add-on. {% endhint %} Integrate F5 with Cortex Cloud to start scanning its APIs for potential threats and vulnerabilities. You need to integrate a dedicated F5 log plugin. This plugin enables seamless traffic ingestion from your F5 gateway to Cortex Cloud, allowing for comprehensive security measures such as OWASP Top-10, bot detection, access control, and more.

Settings in Cortex Cloud

In Cortex Cloud, set up the **F5** data source to integrate with the F5 API Gateway. 1. From **Settings** → **Data Sources & Integrations** , click **+ Add New**, search for **F5 BIG-IP LTM** , then hover over it and click **Add** or **Add Instance**. 2. In the **F5 BIG-IP LTM Collector** wizard, enter a relevant name and then click **Create and Proceed**. 3. Copy the key and paste it somewhere so that you can access it for later. If you forget to record the key and close the window, you must generate a new key and repeat this process. 4. Click the **Download iRules LX Plugin** link to download the plugin to upload it from the F5 Gateway. 5. Click **Close**.

Settings in F5 BIG-IP LTM

1. Log in to your F5 environment. 2. Verify that the following is configured: Navigate to **System** → **Resource Provisioning** and enable **iRules Language Extensions (iRulesLX)** . Check **Provisioning** and set to **Nominal**. 3. Navigate to **Local Traffic** → **iRules** → **LX Workspaces** and follow the steps under the relevant tab: **LX Workspaces**: * Click **Import**. In the **General Properties** page, enter a **Name** and for **Source**, select **apisec\_bigip\_plugin\_tar.gz** .

Note

Extract the files from the F5 plugin to a folder before selecting to upload to F5.

* In the **General Properties** page, enter: * **Name**: Enter the name **panw\_apisec\_workspace**. * **Source**: Select **apisec\_bigip\_plugin\_tar.gz**. * Select **Import** to import the plugin. **LX Plugins**: * Click **Create**. * In the **General Properties** page, enter: * **Name**: Enter **panw\_apisec\_plugin**. * **From Workspace**: Select **panw\_apisec\_workspace**. * Click **Finished**. 4. Navigate to **System** → **File Management** → **Data Group File List** → **Import**. * From **File Name**, select the **panw\_apisec\_config.txt** file that was extracted from the zip that was downloaded from Cortex Cloud. * In the **Name** field, select **Create New** and enter **panw\_apisec\_config**. * From **File Contents**, select **String**. * For **Data Group Name**, enter **panw\_apisec\_config**. * Click **Import**. 5. Navigate to **System** → **File Management** → **Data Group File List**. * Click **panw\_apisec\_config**. * In **Definition**, fill in the values for the following: ```programlisting "context_account_id" := "", "context_provider" := "", "context_region" := "", "cortex_collector_key" := "", "cortex_collector_url" := "", ``` * Paste the F5 VIG-IP LTM Collector key you copied from Cortex Cloud in the `"cortex_collector_key"`. * From Cortex Cloud, go to **Data Sources & Integrations** and from **F5 BIG\_IP LTM** , copy the API URL and paste it in the `"cortex_collector_url"`. ![F5\_data\_source.png](/files/3jJWYHfyx0rgYqT0xMSQ) * The `context_account_id`, `context_provider`, and `context_region` depend on the cloud environment. In this instance, AWS is the example:

Note

The provider for "context_provider" should always be uppercase.
Supported providers: AWS, GCP, Azure, On-prem.

```programlisting "context_account_id" := "12345", "context_provider" := "AWS", "context_region" := "us-east-2", "cortex_collector_key" := "collector key", "cortex_collector_url" := "API URL", ``` * Click **Update**. 6. Navigate to **Local Traffic** → **Virtual Servers** → **Virtual Server List** . The virtual server functions as an API Gateway, handling all incoming and outgoing requests and responses, then forwarding that data to the Cortex Cloud collector. * From the virtual server that serves as the gateway, click **Edit**. * In the **Resources** tab, under **iRules**, click **Manage**. * From the **Available** list, navigate to **/Common/panw\_apisec\_plugin** and select **panw\_apisec\_data\_collection** and **panw\_apisec\_set\_ssl\_data** , and then click the left arrow button to move them to the **Enabled** list.

Note

Select panw_apisec_set_ssl_data only if your client SSL profile is enabled.

* Click **Finished**. * Click the **Properties** tab. 7. Test the request/response and verify that the logs are sent to Cortex Cloud. This can be verified by checking that the counter has increased. The scanned API endpoint metadata from f5-bigip is ready for investigation in the API inventory.

### Agent-based protection {% hint style="info" %} ### Note Web and API Security (WAAS) profiles and policies are currently a Beta feature. {% endhint %} Cortex Cloud can protect your workloads from various types of injection attacks, exploitation attempts, known vulnerabilities, automated tools, and more. In addition, your cloud workloads can be protected against evolving threats aggregated from commercial threat feeds, open-source threat feeds, and input from the Palo Alto Networks Unit 42 research team. Web and API Security profiles provide comprehensive real-time detection and protection for web-based applications and APIs running on Linux-based workloads, to prevent cloud attacks. These profiles can be applied to policies for such workloads. You can configure Cortex Cloud to either monitor traffic for threats, or to actively block them. A fully configurable profile gives you the flexibility to protect your workloads based on specific needs for each type of threat. Follow these steps to configure profiles and policies for cloud workloads: 1. Task 1: [Set up Web and API Security profiles](/cortex-cloud-runtime-security/web-and-api-security-waas/secure-your-api-landscape/configure-api-security-from-end-to-end.md#set-up-web-and-api-security-profiles) 2. Task 2: [Apply Web and API Security profiles to workloads](/cortex-cloud-runtime-security/web-and-api-security-waas/secure-your-api-landscape/configure-api-security-from-end-to-end.md#apply-web-and-api-security-profiles-to-workloads) 3. (Optional) Task 3: Configure exception rules, such as [legacy exception rules](/cortex-cloud-runtime-security/web-and-api-security-waas/secure-your-api-landscape/configure-api-security-from-end-to-end.md#add-a-legacy-exception-rule-for-cloud-workloads) and [support exception rules](/cortex-cloud-runtime-security/web-and-api-security-waas/secure-your-api-landscape/configure-api-security-from-end-to-end.md#add-a-support-exception-rule-for-cloud-workloads). [Disable prevention rules](/cortex-cloud-runtime-security/web-and-api-security-waas/secure-your-api-landscape/configure-api-security-from-end-to-end.md#add-a-disable-prevention-rule-for-cloud-workloads) for specific use cases. The following table summarizes the workload protection features provided by Cortex Cloud prevention profiles and policies: | Module | Threat description | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Advanced Threat Protection | Advanced Threat Protection (ATP) is a comprehensive security feature designed to detect, prevent, and respond to sophisticated Web and API threats, ensuring robust protection for workloads against evolving risks. | | Authentication bypass | The Cortex Cloud authentication bypass module protects against attacks that attempt to circumvent authentication controls through session manipulation, token exploitation, or credential abuse. | | Automation tools | Cortex Cloud detects and protects against automated tools or services that scrape website contents such as Scriptable headless web browsers, command line tools, or HTTP libraries. | | Cross-Site Scripting (XSS) injection | Cortex Cloud protects against XSS attacks, in which malicious JavaScript snippets are injected into otherwise benign and trusted websites. In such attacks, attackers try to trick the browser into switching to a JavaScript context and executing arbitrary code. | | CVE exploits | Cortex Cloud protects against exploitation attempts of known vulnerabilities (Common Vulnerabilities and Exposures (CVEs)). | | Malformed Traffic | Cortex Cloud identifies and protects against HTTP requests with anomalies that are not expected from common web browsers. | | Injection attacks | Injection attacks are a form of attacks in which attackers attempt to insert malicious input into an application to manipulate its execution. For example, a code injection attack injects code which is interpreted by the application or other runtimes. Command and code payloads can either be injected as part of HTTP requests, or are included from local or remote files (also known as File Inclusion attacks). | | Known bots | Cortex Cloud can identify legitimate bots that properly declare their identity and purpose, such as search engine crawlers and authorized web indexers. These bots follow standard protocols and provide verifiable operator information, however some of them might cause undesirable behaviors, such as spam, and you might prefer to block such bots. | | Offensive tools | Cortex Cloud identifies offensive tools that scan web applications for known security vulnerabilities and misconfiguration, and exploit them. | | Sensitive data exposure | Cortex Cloud protects workloads from providing responses that could expose sensitive data found in critical system files, including password hashes (/etc/shadow), user account information (/etc/passwd), and private encryption keys. | | SQL injection (SQLi) | Cortex Cloud protects against SQLi attacks, which can occur when an attacker successfully inserts a malicious SQL query into the input fields of a web application. A successful attack can read sensitive data from the database, modify data in the database, or run arbitrary commands. |

Limitations

The following limitations currently exist for WAAS protection features: * Only Linux kernel version 5.13 and later, and cgroup v2 are supported. * The Linux kernel must be compiled with BPF support. * K8s network policy is not enforced. * Connections that were initiated before the XDR agent was started will not be inspected. * Inspection size is limited to 128 KB * In HTTP/2, XFF is only added when there is no existing XFF header. * The following are not supported: * localhost interface * K8s pod traffic between containers within the same node * Multiple NICs on K8s nodes (only traffic using the default route is supported) * Direct HTTPS connection (end-to-end encryption) * Service-Mesh based communication * UDP-based communication, including HTTP/3 and QUIC * gRPC

### Set up Web and API Security profiles {% hint style="info" %} ### Note Web and API Security profiles and policies are currently a Beta feature. {% endhint %} You can configure Web and API Security profiles to provide comprehensive real-time detection and protection for web-based applications and APIs running on Linux-based workloads. These profiles can be applied to policies for such workloads. For each setting that you want to override, clear the corresponding option to **Use Default**, and then select the setting of your choice. {% hint style="info" %} ### Note In this profile, the **Report** options configure the workload to report the corresponding malicious applications or APIs to Cortex Cloud, without blocking them. The **Disabled** options configure the workloads to neither analyze nor report the corresponding malware or behavior. {% endhint %} 1. Add a new profile and define basic settings. 1. From Cortex Cloud, select **Inventory** → **Endpoints** → **Policy Management** → **Prevention** → **Profiles**. Click **+Add Profile**, and select whether to create a new profile, or to import a profile from a file. 2. Select the **Linux** platform, and **Web & API Security** as the profile type. 3. Click **Next**. 4. Enter a unique **Profile Name** for the profile. The name can contain only letters, numbers, or spaces, and must be no more than 30 characters. The name will be visible from the list of profiles when you configure a policy rule. 5. (Optional) Enter a description that describes the intention or business purpose of the profile. 2. Configure **Action Mode** options. If you choose **Enable**, you can then configure each item separately. | Item | Options | More details | | -------------------------- | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Action Mode |

Enable
Disable

| When set to **Enable**, Cortex Cloud performs the configured action for each of the options. | | XSS |

Block
Report
Disable

When Cortex Cloud detects cross-site scripting (XSS) injection, it performs the configured action.

XSS attacks are attacks in which malicious JavaScript snippets are injected into otherwise benign and trusted websites. In such attacks, attackers try to trick the browser into switching to a JavaScript context and executing arbitrary code.

| | SQL Injection |

Block
Report
Disable

When Cortex Cloud detects SQL injection (SQLi) attempts, it performs the configured action.

(SQLi) attacks can occur when an attacker successfully inserts a malicious SQL query into the input fields of a web application. A successful attack can read sensitive data from the database, modify data in the database, or run arbitrary commands.

| | Injection Attacks |

Block
Report
Disable

When Cortex Cloud detects injection attacks, it performs the configured action.

Injection attacks are a form of attacks in which attackers attempt to insert malicious input into an application to manipulate its execution. Command and code payloads can either be injected as part of HTTP requests, or are included from local or remote files (also known as File Inclusion attacks).

| | CVE Exploits |

Block
Report
Disable

| When Cortex Cloud detects known vulnerabilities (Common Vulnerabilities and Exposures (CVEs)), it performs the configured action. | | Sensitive Data Exposure |

Block
Report
Disable

When Cortex Cloud protects workloads from exposing sensitive data, it performs the configured action.

This module protects workloads from providing responses that could expose sensitive data found in critical system files, including password hashes (/etc/shadow), user account information (/etc/passwd), and private encryption keys.

| | Authentication Bypass |

Block
Report
Disable

When Cortex Cloud detects attempts to bypass authentication controls, it performs the configured action.

This module protects against attacks that attempt to circumvent authentication controls through session manipulation, token exploitation, or credential abuse.

| | Advanced Threat Protection |

Block
Report
Disable

When Cortex Cloud detects evolving threats, it performs the configured action.

Advanced Threat Protection (ATP) is a comprehensive security feature designed to detect, prevent, and respond to sophisticated web and API threats, ensuring robust protection for workloads against evolving risks.

| | Offensive Tools |

Block
Report
Disable

| Cortex Cloud can identify offensive tools that scan web applications for known security vulnerabilities and misconfiguration, and exploit them. When such tools are found, this module can block or report them. | | Malformed Traffic |

Block
Report
Disable

| When Cortex Cloud detects HTTP requests with anomalies that are not expected from common web browsers, it performs the configured action. | | Automation Tools |

Block
Report
Disable

When Cortex Cloud detects automated tools, it performs the configured action.

Malicious automated tools or services can scrape website contents such as Scriptable headless web browsers, command line tools, or HTTP libraries.

| | Known Bots |

Block
Report
Disable

When Cortex Cloud detects known bots, it performs the configured action.

Cortex Cloud can identify legitimate bots that properly declare their identity and purpose, such as search engine crawlers and authorized web indexers. These bots follow standard protocols and provide verifiable operator information, however some of them might cause undesirable behaviors, such as spam, and you might prefer to block such bots.

| 3. To save the profile, click **Create**. What to do next If you are ready to apply your new profile to endpoints, you do this by adding it to a policy rule. If you still need to define other profiles, you can do this later. During policy rule creation or editing, you select the endpoints to which to assign the policy. There are different ways of doing this, such as:

Create a policy rule from the Prevention Profiles page

1. Navigate to **Inventory** → **Endpoints** → **Policy Management** → **Prevention** → **Profiles**. 2. Right-click your new profile, and select **Create a new policy rule using this profile**. 3. Configure the policy rule.

Edit an existing policy rule from the Policy Rules page

1. Navigate to **Inventory** → **Endpoints** → **Policy Management** → **Prevention** → **Policy Rules**. 2. Right click an existing policy and select **Edit**. 3. Add your new profile to the policy rule.

Create a new policy rule from the Policy Rules page

1. Navigate to **Inventory** → **Endpoints** → **Policy Management** → **Prevention** → **Policy Rules**. 2. Click **Add Policy**. 3. Configure a new policy that includes your new profile.

### Apply Web and API Security profiles to workloads {% hint style="info" %} ### Note Web and API Security profiles and policies are currently a Beta feature. {% endhint %} Cortex Cloud provides out-of-the-box protection for all registered workloads with a default security policy. To customize your security policy, create or edit one or more security profiles, and then attach the profiles to one or more policies. Each policy you create must apply to one or more workload or workload groups. The **Prevention Policy Rules** table lists all the policy rules per operating system. Rules associated with one or more targets that are beyond your defined user scope are locked and cannot be edited. 1. From Cortex Cloud, create a policy rule. Do one of the following: * Select **Inventory** → **Endpoints** → **Policy Management** → **Prevention** → **Policy Rules**, and select **+ New Policy** or **Import from File**.

Note

When importing a policy, select whether to enable the associated policy targets. Rules within the imported policy are managed as follows:

New rules are added to the top of the list.
Default rules override the default rule in the target tenant.
Rules without a defined target are disabled until the target is specified.

* Select **Inventory** → **Endpoints** → **Policy Management** → **Prevention** → **Profiles**, right-click the profile that you want to assign, and click **Create a new policy rule using this profile**. 2. Enter a policy name, and a description (optional) that describes the purpose or intent of the policy. 3. Select the **Platform** for which you want to create a new policy. 4. Select the desired profiles that you want to apply in this policy. If you do not specify a profile, the default profiles are used. 5. Click **Next**. 6. Use the filters to assign the policy to one or more workloads or workload groups. Cortex Cloud automatically applies the platform filter you selected and, if it exists, the **Group Name** according to the groups within your defined user scope. 7. Click **Done**. 8. In the **Policy Rules** table, change the rule position, if needed, to order the policy relative to other policies. The Cortex XDR agent evaluates policies from top to bottom. When the Cortex XDR agent finds the first match, it applies that policy as the active policy. To move the rule, select the arrows and drag the policy to the desired location in the policy hierarchy. Right-click to display and use one of the following options **View Policy Details**, **Edit**, **Save as New**, **Disable**, and **Delete**. 9. If you want to export policies, select one or more policies, right-click, and select **Export Policies**. You can include the associated **Policy Targets**, **Global Exceptions**, and workload groups.

Note

The exported file is encoded in Base64 and cannot be edited.

**Manage Web and API Security prevention profiles** After you create and customize your Web and API Security prevention profiles, you can manage them from the **Prevention Profiles** page as needed.

View the prevention policy rules that use a specific prevention profile

Before you modify or delete a profile, you can check which policy rules, if any, use the profile. * From **Inventory** → **Endpoints** → **Policy Management** → **Prevention** → **Profiles**, right-click the profile and select **View policy Rules**. Cortex Cloud opens the **Prevention Policy Rules** page on a new tab. This page is filtered, and only displays the rules that use the profile that you selected.

Edit, export, duplicate, or delete a prevention profile

Edit a profile: 1. From **Inventory** → **Endpoints** → **Policy Management** → **Prevention** → **Profiles**, right-click the profile and select **Edit**. 2. Make your changes, and then click **Save**. Export a profile: 1. From **Inventory** → **Endpoints** → **Policy Management** → **Prevention** → **Profiles**, right-click the profile and select **Export Profile**. 2. Click **Export**. The profile is downloaded to your computer. Duplicate a profile: 1. From **Inventory** → **Endpoints** → **Policy Management** → **Prevention** → **Profiles**, right-click the prevention profile and select **Save as New**. A new profile is displayed, containing the values from the profile that you selected. 2. Edit the profile name and description, edit any values that you want to change, and then click **Create**. 3. Populate a new prevention policy rule with your new profile. Delete a profile: 1. If necessary, delete or detach any policy rules that use the profile before attempting to delete it. 2. From **Inventory** → **Endpoints** → **Policy Management** → **Prevention** → **Profiles**, locate the profile that you want to remove. The profile's **Usage Count** cell must have a 0 (zero) value. 3. Right-click the prevention profile and select **Delete**. 4. To confirm the deletion, click **Yes**.

Populate a new prevention policy rule with a prevention profile

1. From **Inventory** → **Endpoints** → **Policy Management** → **Prevention** → **Profiles**, right-click the profile and select **Create a new policy rule using this profile**. Cortex Cloud automatically populates the **Platform** selection based on your profile configuration, and assigns the profile based on the profile type. 2. For **Policy Name**, enter a meaningful name, and optionally, add a description for the policy rule. 3. Assign any additional profiles that you want to apply to your policy rule, and click **Next**. 4. Select the target workloads for the policy rule, or use the filters to define criteria for the policy rule to apply, and then click **Next**. 5. Review the policy rule summary, and then click **Done**.

**View information about your Web and API Security prevention profiles** The following table displays the fields that are available on the **Prevention Profiles** page, in alphabetical order. The table includes both default fields and additional fields that are available in the column manager. To view this page, go to **Inventory** → **Endpoints** → **Policy Management** → **Prevention** → **Profiles**. | Field | Description | | ------------------ | --------------------------------------------------------------------------------------------------------------------- | | Associated Targets | The endpoints or endpoint groups to which the profile is assigned | | Created By | The administrator who created the prevention profile | | Created Time | The date and time at which the prevention profile was created | | Description | An optional description entered by an administrator to describe the prevention profile | | Modification Time | The date and time at which the prevention profile was modified | | Modified By | The administrator who modified the prevention profile | | Name | The prevention profile name | | Profile ID | The ID assigned to to the profile by Cortex Cloud | | Summary | Summary of prevention profile configuration | | Type | The prevention profile type | | Usage Count | The number of policy rules that use the profile. If you want to delete a profile, ensure that this cell displays "0". | ### Add a disable prevention rule for cloud workloads You can create granular exceptions to prevention actions defined for your workloads. These exception rules may be useful when you have processes that are essential to your organization, and must not be terminated. To cover all your workloads, you can configure different exception rules per platform. Cortex Cloud still generates issues from the disabled rules. {% hint style="info" %} ### Important * All applicable prevention actions are skipped for the files and process that match the properties defined in the rule. * Consider the consequences of disabling a prevention rule before you add the exception, and monitor it over time. {% endhint %} 1. Go to **Settings** → **Exceptions Configuration** → **Disable Prevention Rules**. 2. Click **Add Rule**, and select **Web and API Security**. 3. For **Rule Name**, enter a meaningful name for the rule. 4. (Optional) Enter a description for the business reason or intent for the rule. 5. Click **Next**. 6. For **Exception Effect**, choose an option: * **Disable prevention and report**: Disable the prevention modules included in this rule and report on it. * **Disable prevention and do not report**: Disable the prevention modules included in this rule but do not report on it. 7. For **Platform**, select the operating system that you require. 8. Under **Target Properties**, you can configure any combination of parameters. If a parameter is not specified, all values are allowed. You can use wildcards for matching. Press Enter to add the target properties. Repeat this step for additional target properties. When you specify two or more values, the exception is applied only if the file satisfies all the specified target properties. * **Domain**: Specify a domain. * **IP**: Specify an IP address. * **User Agent**: Specify the application's User-Agent ID that is used in the headers of an API request. For example, if the user agent is `"User-Agent:paypal.com"`, enter `paypal.com` here. * **Path**: Specify the path to the required files or folders. 9. For **Modules**, select one or more security modules that won't trigger prevention actions. The actions triggered by the other modules are not affected. 10. For **Scope**, select the scope for the rule: * If you want to apply the rule to all workloads, select **Global**. * If you want to apply the rule to only specific exception profiles, click **Exception Profiles**, and then select them from the list. 11. Click **Next**. 12. Review the configurations for the exception, and if the risks are acceptable to you, select **I understand the risk**, and then click **Create**. ### Add a support exception rule for cloud workloads You can define and manage exceptions based on files received from the customer support team. You can apply the rule across all of your workloads or to specific profiles. 1. From **Settings** → **Exceptions Configuration** → **Support Exception Rules**, click **+ Import from file**. 2. Locate the JSON file that you received from the customer support team, and either drag and drop the file to this dialog box, or click **Browse** to locate the file. 3. Select **Profile/s** to apply the rule to one or more specific profiles, or select **Global** to apply to all workloads. * If you want to apply the rule to existing profiles, select them from the list. * If you want to apply the rule to a new profile, click **New Profile**, and enter the name of the new profile. 4. Click **Import**. ### Add a legacy exception rule for cloud workloads Legacy Exception rules enable you to configure an exception to prevention and protection modules on workloads for selected profiles. Items included in allow lists may continue to generate Cortex Cloud security events. If you want to exclude event reporting, configure this on the **Issue Exclusions** page (**Settings** → **Exception Configurations** → **Issue Exclusions**). 1. Select **Cases & Issues** → **Issues**. 2. Locate an issue from which you can create an exception rule, and right-click it. 3. Select **Manage Issue** → **Create Issue Exception**. 4. Select the items that you want to be included in the exception rule: * **Domain**: The domain to be excluded by the rule. For example, google.com * **Path**: The path to files or folders to be excluded by the rule. * **User-Agent**: The application's User-Agent ID to be excluded by the rule. For example, a User-Agent ID for the curl application could be `curl/7.68.0` * **IP address**: The IP address to be excluded by the rule. 5. Select an option for **Exception Scope**: * **Global**: Apply the exception rule globally for all workloads. * **Profile**: Apply the rule only to workloads mapped to the profile selected in the next step. 6. If you selected **Profile**, select a profile from the **Exception Profile Name** list. 7. Click **Create**. Your rule is created, and can be viewed at the following location: **Settings** → **Exceptions Configuration** → **Legacy Agent Exceptions**. **Additional workload management tasks** Several management activities that can be performed on workloads are accessible from **Inventory** → **Endpoints** → **All Endpoints** and from **Inventory** → **Endpoints** → **Groups**. On these pages, select one or more workloads, and right-click to access the available actions and configuration options. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-cloud-runtime-security/web-and-api-security-waas/secure-your-api-landscape/configure-api-security-from-end-to-end.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.