Configure API security from end to end

Secure your API landscape through third-party integrations and agent-based protection policies.

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
• 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 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 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.
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_<gw ID>/<stage name>”
   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:

   ($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. 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:

   aws logs put-subscription-filter \
       --log-group-name "<YOUR_LOG_GROUP_NAME>" \
       --filter-name "<any_filter_name>" \
       --filter-pattern "" \
       --destination-arn "arn:aws:firehose:region:123456789012:deliverystream/<YOUR_DELIVERY_STREAM>" \
       --role-arn "arn:aws:iam::<ACCOUNT_ID>:role/<YOUR_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

Notice

Requires the Data Collection add-on.

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.

Note

Microsoft Azure APIM service must be running before starting to configure the integration.

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.
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 .

      The Policies screen opens. There are three sections:

      • <inbound>
      • <backend>
      • <outbound>

      The <inbound> includes the request before it's sent to the <outbound>. The parameters are saved before they're sent.

      Add the following inside the <inbound>:

       <!-- Save the request body and headers to be sent to Cortex. This should always be placed at the very beginning of the inbound element. -->
              <set-variable name="requestBody" value="@((context.Request?.Body?.As<string>(preserveContent: true)) ?? string.Empty)" />
              <set-variable name="requestHeaders" value="@(JsonConvert.SerializeObject(context.Request.Headers))" />
              <!-- End of setting variables for sending to Cortex -->

      Note

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

      The <outbound> includes the request before it returns a response.

      Add the following inside the <outbound> element, at the end, after the other child elements:

       <!-- Send data to Cortex. This should always be placed at the very end of the outbound element. -->
              <send-request mode="new" response-variable-name="mirrorMessage">
                  <set-url>{{cortex-api-url}}</set-url>
                  <set-method>POST</set-method>
                  <set-header name="Content-Type" exists-action="override">
                      <value>application/json</value>
                  </set-header>
                  <set-header name="Authorization" exists-action="override">
                      <value>{{cortex-api-key}}</value>
                  </set-header>
                 <set-body>@{
                              string requestBody = context.Variables.GetValueOrDefault<string>("requestBody");
                              string responseBody = context.Response.Body.As<string>(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<string>("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,
                              });
                          }
                  </set-body>
              </send-request>
              <!-- End of sending data to Cortex -->

      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

Notice

Requires the Data Collection add-on.

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).

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.

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.

   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:

   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:

      export DOMAIN_EXCLUSION_LIST="domain1,domain2"

7. Discontinue the integration:

   1. Edit undeploy.sh:

      export PROJECT_ID=example-project-id
      export ORG=$PROJECT_ID
      export ENVIRONMENT=example-env

   2. Run the undeploy.sh script:

      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.

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.

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.

     targetUrl=<Cortex collector url>
     projectID=<GCP project id of apigee>
     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.

      Input:

      gcloud config config-helper --force-auth-refresh --format

      Output:

      configuration:
        active_configuration: 
        properties:
          compute:
            region: 
            zone:     
      core:
            account: 
            disable_usage_reporting: 
            project: 
      credential:
        access_token: <Copy this value>
        id_token: 
        token_expiry: 
      sentinels:
        config_sentinel: 

   2. Copy the <access_token> value from the output.
3. Upload the property set to Apigee:

   curl --silent -X GET 
   "https://apigee.googleapis.com/v1/organizations/
   <ORG>/environments/<ENVIRONMENT>/resourcefiles/
   properties" -H 
   "Authorization: Bearer <access_token from above>"

4. Generate Key Value Map (KVM), which stores the Cortex API key that's encrypted

   curl --silent -X POST 
   "https://apigee.googleapis.com/v1/organizations/
   <ORG>/environments/<ENVIRONMENT>/keyvaluemaps" -H 
   "Authorization: Bearer <access_token from above>" 
   -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.

   curl --silent -X DELETE 
   "https://apigee.googleapis.com/v1/organizations/
   <ORG>/environments/<ENVIRONMENT>/keyvaluemaps/
   $APISEC_KVM_NAME" -H "Authorization: Bearer 
   <access_token from above>"

   Add the Cortex API key entry to the created KVM.

   curl --silent -X POST "https://apigee.googleapis.com/
   v1/organizations/<ORG>/environments/<ENVIRONMENT>/
   keyvaluemaps/$APISEC_KVM_NAME/entries" -H 
   "Authorization: Bearer <access_token from above>" 
   -H "Content-Type: application/json" --data-raw 
   '{"name": "api-key","value": "'"<Generated key 
   from cortex env>"'"}'

5. Upload the shared flows:

   Shared flows:

   • sf-api-sec-extension-postflow
   • sf-api-sec-extension-preflow

   Upload

   Replace the <sf> with the shared flows:

   curl --silent -X POST --data-binary "<sf>.zip" -H 
   "Content-Type: application/octet-stream" -H 
   "Authorization: Bearer <access_token from above>" 
   "https://apigee.googleapis.com/v1/organizations/$ORG/
   sharedflows?action=import&name=<sf>"

   Deploy

   Input:

   curl --silent -X GET "https://apigee.googleapis.com/
   v1/organizations/<ORG>/sharedflows/<sf>" -H 
   "Authorization: Bearer <access_token from above>"

   Output:

   {
     "metaData": {
       "createdAt": "1736952161610",
       "lastModifiedAt": "1736952161610",
       "subType": "SharedFlow"
     },
     "name": "sf-api-sec-extension-postflow",
     "revision": [
       "1" // This is the revision number
     ],
     "latestRevisionId": "1"
   }

6. Deploy <sf>:

   curl --silent -X POST -H "Authorization: 
   Bearer <access_token from above>" 
   "https://apigee.googleapis.com/
   v1/organizations/$ORG/environments/<ENVIRONMENT>/
   sharedflows/$sf/revisions/<REVISION>/
   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 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 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

Notice

Requires the Data Collection add-on.

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.

Note

Contact support to obtain the custom plugin file.

Provision Kong API gateway with the custom plugin

To deploy the custom plugin, refer to the Kong API documentation online:

• Kong Gateway
• Kong Konnect
• Kong Ingress Controller

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.

   -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:

   -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:

   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

Notice

Requires the Data Collection add-on.

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:

     "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
     • 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.

       "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

Note

Web and API Security (WAAS) profiles and policies are currently a Beta feature.

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
2. Task 2: Apply Web and API Security profiles to workloads
3. (Optional) Task 3: Configure exception rules, such as legacy exception rules and support exception rules. Disable prevention rules 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

Note

Web and API Security profiles and policies are currently a Beta feature.

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.

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.

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

Note

Web and API Security profiles and policies are currently a Beta feature.

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.

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.

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.