[#id5326b191-bf23-4545-bc05-620d113bf54d]
== Define Enterprise and Anomaly Settings

Set the enterprise level settings to set up the browser timeout when inactive, user attribution for alerts, and build training models for anomalies and define thresholds for alerts.

Set the enterprise level settings to build standard training models for anomaly detection, alert disposition, and some other global settings such as the timeout before the user is locked out for inactivity, and user attribution for alerts.

* <<inactivity-timeout>>
* <<global-settings>>
* <<enable-alarms>>
* <<access-keys>>
* <<audit-logs>> 
* <<unsubscribe-chronicles>>
* <<anomaly-thresholds>> 


[#inactivity-timeout ]
=== Set Up Inactivity Timeout

Specify a timeout period after which an inactive administrative user will be automatically logged out of Prisma Cloud. An inactive user is one who does not interact with the UI using their keyboard and mouse within the specified time period.


. Select *Settings > Enterprise Settings*.

. *User Idle Timeout*
+
If you modify the timeout period, the new value is in effect for all administrative users who log in after you make the change; the previous timeout applies for all currently logged in users.



[#global-settings]
=== Set Up Global Settings for Policy and Alerts

These settings apply to all Prisma Cloud policies. The *Critical* severity policies are enabled out-of-the-box. For Anomaly policies, you have more customizable settings, see xref:#anomaly-thresholds[Set Up Anomaly Policy Thresholds].

. *Auto enable new default policies of the type*.

.. Select *Settings > Enterprise Settings*.

.. Granularly enable new *Default* policies of severity *Critical*, *High*, *Medium*, *Low* or *Informational*.

While some high severity policies are enabled to provide the best security outcomes, by default, policies of medium or low severity are in a disabled state. When you select the checkbox to auto enable policies of a specific severity, you can either retroactively enable all policies that match the severity or only enable policies that are added to Prisma Cloud going forward.

image::administration/auto-enable-default-policies.png[]

//Source is “define-prisma-cloud-enterprise-settings.xml”

[NOTE]
====
If you enable policies of a specific severity, when you then clear the checkbox, the policies that were enabled previously are not disabled; going forward, policies that match the severity you cleared are no longer automatically enabled to scan your cloud resources and generate alerts. If you want to disable the policies that are currently active, you must disable the status of each policy on the *Policies* page.
====

image::administration/enterprise-settings-policies-disable.png[]

. Enable *Make Alert Dismissal Note Mandatory*, to mandate the users to dismiss alerts only after specifying a reason.

. Enable *Populate User Attribution in Alerts Notifications*.
+
User attribution data provides you with context on who created or modified the resource that triggered the alert. Select this option to make sure that the alerts include user attribution data in the alert payload, so that it is sent as part of the JSON data to xref:administration/configure-external-integrations-on-prisma-cloud/integrations-feature-support.adoc#ide75ce39a-81e2-4458-a23b-9a4e96b08f22[notification channels] such as SQS or Splunk. Enabling this option can result in a delay of up to two hours in the generation of alerts because the relevant user information may not be instantly available from the cloud provider.
+
The policies that support user attribution in alert payload are:

.. AWS Security Group allows all traffic on RDP port (3389)

.. AWS EBS snapshots are accessible to public

.. AWS RDS snapshots are accessible to public

.. AWS RDS instance is not encrypted

.. AWS Security Group allows all traffic on SSH port (22)

.. AWS Security Group overly permissive to all traffic

.. AWS Amazon Machine Image (AMI) is publicly accessible



[#enable-alarms]
=== Enable Alarms

Prisma Cloud generates health notifications called *Alarms* that notify you about system-level issues and errors. After you enable Alarms, Prisma Cloud automatically generates alarms related to external Integrations status and onboarded Cloud Accounts status. You can configure rules to receive email notifications for the generated alarms so that you do not need access to the Prisma Cloud console to know when an error or issue occurs.


. Select *Settings > Enterprise Settings*.
+
[NOTE]
====
You must have the System Administrator role on Prisma Cloud to view, enable, and disable Alarms.
====

. Enable *Alarms Configuration*.
+
Later if you disable Alarms Configuration, all the alarms that were generated previously are deleted.
+
image::administration/alarms-configuration-1.png[]

. *Save*.

[#access-keys]
=== Set up Access Key Settings

Prisma Cloud allows you to create and manage API keys to facilitate programmatic access to our features and functionality. Use the *Access Key Maximum Validity* settings to establish the platform limit for the maximum number of days for access key validity.

Select a value in the *Maximum time before access keys expire* drop-down to complete set up.

image::administration/access-key-settings.png[]

To ensure uninterrupted access to Prisma Cloud APIs, you can also set up the following *Access Key Expiration Notifications*:

- Email notifications for named user Access Keys
- Alarm Center notifications for Service Account Access Keys
 
Select a value under *Access Key Expiration Notifications > Notification Threshold* to set a notification threshold prior to access key expiration. 

[NOTE]
====
Updates to *Access Key Expiration Notifications* settings may take up to 24 hours to take effect.
====

[#audit-logs]
=== Enable Audit Log Forwarding 

Prisma Cloud generates Audit logs to help prepare your organization for regular audits. All actions, with some exceptions, initiated by Prisma Cloud administrators are captured in the Audit logs. This data can be forwarded to any previously configured supported notification channel or external integration of your choice. Follow the steps below to enable Audit log forwarding:

[NOTE]
====
To minimize "noise" and log flooding, Prisma Cloud does not forward "Successful login" type audit log messages to external integrations. All other audit log types can be sent to any supported external integration such as Webhook or SQS. For example, the following audit log message will not be forwarded. screen:['xxx@paloaltonetworks.com'(with role 'System Admin':'System Admin') logged in via password]
====

. Select *Settings > Enterprise Settings*.
+
[NOTE]
====
You must have the System Administrator role on Prisma Cloud to enable, and disable Audit log forwarding.
====

. Enable *Send Audit Logs to integration*
+
image::administration/audit-log-to-integration.png[]

. Select a supported integration (Webhook or SQS) from the drop-down menu. If you have not already set up one, click *Add Integration* to configure a new integration.

. *Save*.

[#unsubscribe-chronicles]
=== Unsubscribe from  Prisma Cloud Chronicles

Prisma Cloud Chronicles is the weekly email update that summarizes your team’s Prisma Cloud usage, informs you of release updates, and provides recommendation on how you can improve your security posture with adopting Prisma Cloud.  
If you have more than one Prisma Cloud tenant and want to unsubscribe all your administrators from receiving the newsletter you can disable globally.

. Select *Settings > Enterprise Settings*.
. Select *Opt out of receiving the Prisma Cloud Chronicles newsletter for all Prisma Cloud System Administrators*.
+
An email is sent to all administrators notifying them that a System Administrator has opted them out. Each administrator can edit their profile settings on Prisma Cloud to opt in and receive the newsletter, if they want to stay informed of the latest updates. 

[#anomaly-thresholds]
=== Set Up Anomaly Policy Thresholds

Prisma Cloud allows you to define different thresholds for anomaly detection for Unusual Entity Behavior Analysis (UEBA) that correspond to policies which analyze audit events, for unusual network activity that correspond to policies which analyze network flow logs, for DNS analytics, and for identity. You can also define your preference for when you want to alert notifications based on the severity assigned to the anomaly policy.

If you want to exclude one or more IP addresses or a CIDR block from generating alerts against Anomaly policies, see xref:trusted-ip-addresses-on-prisma-cloud.adoc[Trusted IP Addresses on Prisma Cloud].


. For UEBA policies:

.. Select *Settings > Anomaly Settings > Alerts and Thresholds*.
+
image::administration/anomaly-policies-ueba-settings-1.png[]

.. Select a policy.

.. Define the *Training Model Threshold*.
+
The Training Model Threshold informs Prisma Cloud on the values to use for setting the baseline for the machine learning (ML) models.
+
[NOTE]
====
For production environments, set the *Training Model Threshold* to *High* so that you allow for more time and have more data to analyze for determining the baseline.
====
+
*For account hijacking attempts:*
+
... Low: The behavioral models are based on observing at least 10 events over 7 days.

... Medium: The behavioral models are based on observing at least 25 events over 15 days.

... High: The behavioral models are based on observing at least 50 events over 30 days.*For anomalous compute provisioning activity:* None.
+
*For unusual user activity:*
+
... Low: The behavioral models are based on observing at least 25 events over 7 days.

... Medium: The behavioral models are based on observing at least 100 events over 30 days.

... High: The behavioral models are based on observing at least 300 events over 90 days.

.. Define your *Alert Disposition*.
+
Alert Disposition is your preference on when you want to be notified of an alert, based on the severity of the issue —low, medium, high. The alert severity is based on the severity associated with the policy that triggers an alert.
+
You can profile every activity by location or user activity. The activity-based anomalies identify any activities which have not been consistently performed in the past. The location based anomalies identify locations from which activities have not been performed in the past.
+
Choose the disposition (in some cases you may only have two to choose from):
+
... Conservative:
+
For unusual user activity—Reports on unknown location and service to classify an anomaly.
+
For account hijacking—Reports on location and activity to login under travel conditions that are not possible, such as logging in from India and US within 8 hours.
+
For anomalous compute provisioning activity—Reports on high severity alerts only when an unusual number of instances are created within a short time interval, impossible time travel, and belonging to a TOR anonymity network.

... Moderate:
+
For unusual user activity—Report on unknown location, or both unknown location and service to classify an anomaly.
+
For anomalous compute provisioning activity—Reports on medium and higher severity alerts.

... Aggressive:
+
For unusual user activity—Reports on either unknown location or service, or both to classify an anomaly.
+
For account hijacking—Reports on unknown browser and Operating System, impossible time travel, or both.
+
For anomalous compute provisioning activity—Reports on low and higher severity alerts.
+
[NOTE]
====
Set the *Alert Disposition* to *Conservative* to reduce false positives.

When a Prisma Cloud administrator modifies the *Alert Disposition* or *Training Model Thresholds* for detecting anomalies that relate to UEBA, existing alerts associated with UEBA policies will no longer be resolved, but instead, remain as-is. Additionally, an audit log is generated to record who made the configuration change and when, to help you track and monitor changes.
====

. For unusual network activity.
+
For anomalies policies that help you detect network incidents, such as unusual protocols or port used to access a server on your network, you can customize the following for each policy.
+
.. Select *Settings > Anomalies > Alerts and Thresholds*.

.. Select a policy.
+
image::administration/anomaly-policies-network-settings.png[]

.. Define the *Training Model Threshold*.
+
The Training Model Threshold informs Prisma Cloud on the values to use for various parameters such as number of days and packets for creating the ML models. These thresholds are available only for the policies that require model building such as Unusual server port activity and Spambot activity.
+
... Low: The behavioral models are based on observing at least 10K packets over 7 days.

... Medium: The behavioral models are based on observing at least 100k packets over 14 days.

... High: The behavioral models are based on observing at least 1M packets over 28 days.

.. Define your *Alert Disposition*.
+
Alert Disposition is your preference on when you want to be notified of an alert, based on the severity of the issue —low, medium, high. The alert severity is based on the severity associated with the policy that triggers an alert. You can choose from three dispositions based on the number of ports, hosts or the volume of traffic generated to a port or host on a resource:
+
... Aggressive: Reports High, Medium, and Low severity alerts.
+
For example, a Spambot policy that sees 250MB traffic to a resource, or a port sweep policy that scans 10 hosts.

... Moderate: Reports High and Medium severity alerts.
+
For example, a Spambot policy that sees 500MB traffic to a resource, or a port sweep policy that scans 25 hosts.

... Conservative: Reports on High severity alerts only.
+
For example, a Spambot policy that sees 1GB traffic to a resource, or a port sweep policy that scans 40 hosts.


. For unusual usage of workload credentials.
+
For anomalies policies that help you detect when a credential that has been assigned to a compute resource, such as an EC2 instance, is used from inside the cloud service provider. 
+
.. Select *Settings > Anomalies > Alerts and Thresholds* and scroll down to *Identity*.

.. Select a policy.
+
image::administration/anomaly-policies-identity-settings.png[]

.. Define your *Alert Disposition*.
+
Alert Disposition is your preference on when you want to be notified of an alert. For unusual usage of workload credentials policies, this only applies when the suspicious IPs are inside the cloud because the policy is more prone to false positives when the suspicious IPs are inside the cloud provider’s IP space. When the suspicious IPs are outside the cloud provider’s IP space, alerts are always generated irrespective of the alert disposition setting.
+
... Aggressive: Alerts are generated only when the suspicious IP is inside the cloud and it resides within or outside the monitored cloud accounts.

... Moderate: Alerts are generated only when the suspicious IP is inside the cloud and it is a private IPv4 or it is outside the monitored cloud accounts.

... Conservative: Alerts are generated only when the suspicious IP is inside the cloud but outside of the monitored cloud accounts.