Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

Security Checklist core tasks

Updated on July 1, 2021

The Security Checklist provides Pega's leading practices for securely deploying applications. To assist you in tracking the completion of the tasks in the Security Checklist, Pega Platform shows the overall completion on the Dev Studio Home page, and built-in ways to track the status of each task.

The Security Checklist core tasks are critical and should be performed for every application.

Tasks to perform during development

Keep application rules guardrail-compliant
The most important security requirement for all Pega Platform applications is to maintain guardrail compliance.
Review the Guardrails landing page weekly and make changes to keep your application rules in compliance. Many security features can only be properly enforced in application rules that comply with Pega Platform guardrails. Applying changes to non-compliant rules is more costly after you deploy your application.
Address security alerts promptly
At least weekly, review run-time security alerts and take appropriate remedial actions to identify, and where possible, eliminate what caused the alerts.

For more information, see

Securely authenticate attempts to access services
Verify that all default service packages and custom authentication services are secured appropriately.
To prevent unauthorized access of services not in use, ensure that the Service Package instances have, at minimum, basic authentication enabled and require TLS.
Ensure that each service package uses a strong authentication profile and requires TLSv1.2 or later.
A new release may deprecate service packages. However, for those with custom applications that connect to a deprecated service, the service package will continue to work and remain available.
Do not put into production services that are unauthenticated or that use only basic authentication.

For more information, see Service Wizard: Configure Data Records.

Define appropriate roles and privileges to restrict access
Define roles for the users in your access groups.
For each application function that only certain users need, such as classes, screens, flows, flow actions, or tools, define an appropriate privilege to enable access to that function.
Use the Access Manager to manage the granting of these privileges to roles. Grant access only to users with a real business need for a business function or business data.
Note: It is critical to protect access to certain types of rules (such as activities, reports, and flow actions, all of which could provide access to sensitive data, or the ability to do harm within the application) by assigning privileges to rules that are not available to unauthorized individuals. It is not recommended that you wait until application testing and deployment to do this, because it may result in wasteful refactoring and retesting of your application. However, if you wait until production testing and deployment to protect these types of sensitive rules, Pega has provided the Rule Security Mode Utility tool to help you in Pega Platform releases prior to 8.5. This tool analyzes unprotected access to rules allowed by your application and automates the process of adding appropriate privileges.
Review all access groups, especially access groups for unauthenticated users, to verify that the access groups have the minimum required access to rules, case types, and data.

For more information, see

Define appropriate access control policies to restrict access
Use access control policies to enforce restrictions on access to application data at the row and column level; in other words, to restrict access to specific instances or properties in a class for different operators.
Define policy conditions that dynamically compare properties in each instance of the restricted class to user privileges, credentials, or other information on the clipboard.

For more information, see

Appropriately encrypt data
Protect sensitive data within Pega Platform data stores by encrypting all the data in a class or by encrypting individual property values.

For more information, see Encryption in Pega Platform.

Tasks to perform when deploying to production

Set the system production level to 5
To implement the highest restrictive security scheme, set the production level for the application to level 5.
You can change the production level in the navigation pane of Dev Studio by clicking Configure > System > General > Systems, Nodes, Requestors. The change takes effect the next time you start the system.
The production level value primarily affects privilege-based authorization through Access of Role Object and Access Deny rules, and your testing mirrors the authorization controls that are set for production. If the system production level setting interferes with access in your development environment, add more focused Access of Role to Object rules that grant access, instead of lowering the production level.

For more information, see Defining values for an application setting.

Lock application and rulesets
Lock each ruleset version with a secure password by clicking Lock and Save on the Version tab, and entering a hard-to-guess password. In each ruleset rule, click Use checkout? on the Security tab, and enter three distinct passwords to limit the ability to add versions, update versions, and update the ruleset rule.

For more information, see Versions tab on the Ruleset form.

You should also lock the application itself in the Application rule form. If a ruleset is intended to remain unlocked in production (for example, to store rules such as reports that end users can modify), then list it as a Production ruleset in the Advanced section of the Application rule form.
Do not deploy checked-out rules
Run the Checked Out Rule Report and eliminate rules that are checked out.

For more information, see Reporting on rules.

Block unnecessary roles and operators from production
In the production environment, eliminate or block any operators and roles used in development or test environments, but are not needed in production.

For more information, see

In addition, you should delete or disable any Authentication Service rules that are not intended to be usable in production, as these would allow access to your application through unauthorized methods.

Secure passwords
Verify that the system securely hashes and stores all passwords for production use.
  • In the database table that holds the operator ID instances, ensure that the column that contains the password property pyPwdCurrent is not exposed, and that the value for pyPwdCurrent is only in the pzPVStream or BLOB column.
  • Convert preexisting password hashes to use the bcrypt algorithm.

    For more information, see Password hashing.

To prevent unauthorized access with default passwords, change the passwords for all default operators. Disable or delete the operator IDs that you do not plan to use.
Note: The passwords should be changed for disabled operators as well.

For more information, see:

Configure dynamic system settings for production
Verify that the dynamic system settings are appropriate for a production environment.

For more information, see Dynamic system settings.

Define appropriate Configure Cross-Site Request Forgery (CSRF) settings
Configure Cross-Site Request Forgery (CSRF) settings to prevent unwanted actions on an application in which a user is currently authenticated.
Set these values by using the Cross-Site Request Forgery landing page.

For more information, see Enabling and configuring Cross-Site Request Forgery settings.

For Pega 7 and below, set the CSRF settings as described in Configuring CSRF protection.

Define appropriate Content Security Policies (CSPs)
Review and define an appropriate Content Security Policy (CSPs). Every production application should have a policy specifying which locations the user's browser can load resources from.

For more information, see Content security policies.

Define appropriate CORS policies for REST services
Configure cross-origin resource sharing (CORS) policies to control and secure access to the REST services in your application by external systems.

For more information, see Creating a cross-origin resource sharing policy.

Configure logging levels appropriately
Set the appropriate logging levels for production. There are eight logging levels. Error is the default setting. If system is running normally, very little information will be written to the logs. Information is only written to the logs when an exception is thrown.

For more information, see Logging Level Settings tool.

  • Service Wizard: Configure Data Records

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us