Notification Subscription Log

Add Notification Profiles

1. From the Incidents & AlertsPrisma Access Incidents & AlertsNotification Profiles page, select Add Notification Profile. The New Profile window appears.

2. Under General:
   • Name—Enter a profile name.
   • Sub-Tenant ID—For Email or Webhook Notifications, select one or more subtenants.
   • Description (optional): Enter an optional description of up to 72 characters.
3. Under Notification Method, select Email, Webhooks, or ServiceNow:
   • To use Email:
     1. Under Email Contacts, select Add Contacts.
     2. Enter a valid Email and an optional Name, and press Enter.
     3. You can add multiple email contacts using the Add Contacts button.
   • Webhooks are custom HTTP callbacks that you define. They are triggered by an event, such as pushing code to a repository or posting a comment on an issue. When the event occurs, the source app makes an HTTP request to the URI configured for the webhook.
     You can create one webhook notification per profile.
     To use Webhooks:
     1. Enter a webhook name and a valid URL.
        Use only standard web ports. Custom web ports are not allowed.
     2. Under Auth Type, select None, Basic, or Token.
        • None—You don’t need to add any more information.
        • Basic—Enter the username and password of the webhook.
        • Token—Enter the webhook token.
   • To use ServiceNow:
     1. Enter a Name for the profile.
     2. Enter an optional Description.
     3. Under Configure Incident Management Details, enter:
        • A profile Name.
        • A valid Table URL that links to your ServiceNow table. The URL to connect the ServiceNow instance through the ServiceNow Table APIs must include the entire domain name and table name in the following format:
          https://<domain name>/api/now/table/myTable
          where myTable is the name of the Table on ServiceNow where the tickets will be created.
        • The Auth Type.
        • A Username.
        • A unique Password.
     4. Enter your ServiceNow fields in this table to make sure ServiceNow pushes the correct data for a SASE incident. Enter data in the mandatory fields marked with asterisks (*).
     5. The Custom Field enables you to customize a static field to use in any way you want. For example, you can set up the Custom Field to show PANW as a static entry in all your rows. This can be especially useful if you're using a master table for integrations with several vendors. It helps you identify the source of the incidents and tickets more easily.
     6. Under SASE Mapping, move the Do you want to visualize ServiceNow incident updates on the Prisma Sase dashboard? toggle to Yes for a bidirectional integration with ServiceNow. As part of a bidirectional integration, Strata Cloud Manager not only automatically generates incidents on ServiceNow but also gets incident updates from ServiceNow back to the Strata Cloud Manager dashboard.
        Enter ServiceNow Mapped Field data in the mandatory fields (with asterisks), and select Run Test Case to create a dummy incident. The test case helps verify whether your ServiceNow integration is working.
     7. The Please Authorize ServiceNow Integration pop-up appears whether you're using a bidirectional or unidirectional integration. Select Authorize to confirm that you want to have your Strata Cloud Manager incidents appear on your ServiceNow instance and ServiceNow incident updates appear on your Strata Cloud Manager interface.
     8. After you have successfully saved your ServiceNow profile, it appears in the Notification Subscriptions table, with Yes in the ServiceNow column. The ServiceNow column says Yes (Test Successful) if you ran a successful test case, and Yes (Test Not Executed) if you did not run a test case at all.
4. Under Subscription, you can select all alerts present under an alert category, or you can select > to the left of the alert category name to expand the category and specify the alerts for which you want to be notified. To receive alert notifications through email or notifications streamed through webhooks, based on alert severity for an alert category of interest, select Low, Medium, or High severity.
   The default profile receives Informational alerts for the tenant. In other notification profiles, you can elect to receive informational alerts or not.
5. Save your changes.
6. For ServiceNow: After you successfully save your ServiceNow profile, it appears in the Notification Subscriptions table, with Yes in the ServiceNow column. The ServiceNow column says Yes (Test Successful) if you ran a successful test case, or Yes (Test Not Executed) if you did not run a test case at all.
7. You can have only one active ServiceNow integration at a time. The State column in the Notification Subscriptions table shows your active ServiceNow integration is Enabled.

Edit an Existing Profile

Webhook Data Schema for Incidents

{
  "kind": "incident",
  "data": {
    "incident_id": "", #UUID to uniquely identify an incident. Unique across all the incidents generated by Cosmos
	"event_type":"", INC_CREATED, INC_CLEARED, INC_AL_ASSOCIATE, INC_HAS_PARENT
    "title": "", #Incident description. Should be used for only display purposes
    "severity":  "", #Valid values High/Medium/Low
    "status": "", #Valid values are Raised/Cleared/RaisedChild/ClearPending
    "clear_reason": "", #Valid values are Auto/Manual/No Data Timeout
    "code": "", #Unique alert code across Cosmos alerts. It is in a flat namespace (ex: AL_SC_PRIMARY_TUNNEL_DOWN, etc)
    "category": "", #Alert category (Example: RN, SC, etc)
    "sub_category": "", #Alert sub category
    "tenant_id": "",
    "sub_tenant_id": "",
    "sub_tenant_name": "",
    "resource_keys": { # json string These keys identify an unique resource. These fields vary depending on the alert code
      "tenant_id": "",
      "sub_tenant_id": "",
      "tunnel_name": "SanJoseTunnel",
      "node_type": "51",
      "site_name": "SanJose",
	  "bgp_peer_name": "",
    },
    "resource_data": { # json string These fields vary depending on the incident code
        "state": "Down"
    },
	"correlated_alerts" : {
	[{"alert_id":"", "state":"", "updated_time":"", "message":""}],
	},
	"parent_incidents" : {
	[{"incident_id":""}],
	},
 	"child_incidents" : {
	[{"incident_id":""}],
	},
    "version": "1.0", #Alert model version. It will be 1.0
    "raised_time": "2021-07-02 23:12:13 UTC",
    "updated_time": "2021-07-03 23:12:13 UTC",
    "cleared_time": "2021-07-03 23:12:13 UTC"  
  }
}