Tasks to perform during development

Address security alerts promptly

At least weekly, review run-time security alerts weekly and take appropriate remedial actions to eliminate their causes.

For more information, see

• Security alerts.
• List of performance and security alerts in Pega Platform.

Securely authenticate attempts to access services

As you configure connectors to access external systems, ensure that you use appropriate authentication.

Ensure that each service package uses a strong authentication profile and requires TLSv1.2+.

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

• Using the Rule Security Mode Utility to secure rules in Pega Applications
• Authorization
• Editing authorizations for case type items in a single access group
• Editing authorizations for case type flows and flow actions in a single access group
• Viewing authorizations for case type flows and flow actions in a single access group
• Viewing authorizations for case type items in all access groups
• Reviewing user privileges for a role by using Access Manager
• Access Manager
• Learning about access groups
• Creating an access group

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

• Authorization
• Creating an access control policy
• Creating an access control policy condition

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 production-level application setting values.

Lock 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 like 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

• Defining security information for an operator
• Defining operator work groups, work queues, and schedules
• Enabling and disabling operators

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:

• Defining security information for an operator
• Enabling and disabling operators

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.

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

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 (CORS) policy.

Configure logging levels appropriately

Set the appropriate logging levels for production. There are 8 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.

Appropriately audit changes to data and user/developer actions

Configure auditing to document who changes your application data, and when and how the data has been changed. Auditing also enables you to:

• Monitor all security-related activity in the system.
• Create reports that analyze patterns of system usage.
• Identify patterns of suspicious behavior.
• Determine the scope of damage and apply remedial actions, if any vulnerabilities are exploited.