Table of Contents

Security Checklist

Please refer to the newest version of the Security Checklist.

 

 

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 does the following:

  • Provides best practices for securely deploying applications.
  • Helps protect the confidentiality, integrity, and availability of your application in production.
  • Identifies when each task should be performed: at or near the beginning of development, on an ongoing basis, or just before deployment.
  • Helps avoid expensive rework late in your development process.

To assist you in tracking the completion of the tasks in the checklist, Pega Platform™ automatically installs an application guideline rule instance that includes the tasks in the security checklist for each version of your application.

For more information, see Preparing your application for secure deployment.

If using deployment manager, starting in Pega Platform 8.5, completing the security checklist is required to move an application into production. 

Security is critical

Inadequate security can prevent your application from being deployed in two ways:

  • Most clients need approval from the IT security group who review the application’s security before the project team can put the application into production.
  • If a client is building their application with Deployment Manager, the application will be blocked if the  has not been completed.

Your responsibility as an administrator, senior system architect, or lead system architect is to ensure the confidentiality, integrity, and availability of your application. Unauthorized individuals should not be able to access or modify the application or the data it creates and stores. Further, they should only have access to those application functions and data that are necessary to perform their jobs.

Independent Security assessment

An independent assessment of your application’s security, and sign-off of that assessment, is always recommended and is required by most organizations’ IT Security groups.

Guardrail compliance: the basis of a secure application

The most important security requirement for all Pega Platform applications is to maintain guardrail compliance. Pega Platform security features cannot always be successfully enforced in custom code.

Use the built-in security configuration features in Pega Platform to protect your application, and do not rely on custom code built by developers who are not security experts.

Not all security tasks are required for all applications or releases

It’s important to understand the nature of the application and how it will be deployed when reviewing the tasks in the Security Checklist. Not all tasks will be required, depending on what Pega Platform features are used and depending on how and to whom the application will be deployed. For example:

  • Some tasks, are not required if your application is deployed on Pega Cloud, where they are performed automatically.
  • The criticality of some tasks depends on whether the users of the application are internal employees, clients, or the general public.
  • As noted in some tasks, the amount of sensitive data that will be created and stored within the application affects how critical they are.
  • The recommendations for some tasks may not apply to all Pega Platform releases.
  • Check each document linked to below to see which releases it applies to.
Security is one of several special considerations you should be aware of for public-facing applications. 

For more information, see Basic requirements for deploying public-facing applications.

Focus on task timing

The Security Checklist tasks are organized based on the timing of when they should be performed, and what key area (for example, authentication, authorization, auditing) is involved. Some should be performed near the beginning of development, some during development, and some just before deployment. Perform these tasks at the appropriate times during development to avoid significant rework and retesting later.

Security Checklist tasks

Review the list of security considerations and actions that you can take to strengthen the security of your application. Most of the actions have one-time implementation costs; some have performance costs. All these actions have significant benefits in terms of user convenience and security. Select the actions that are most applicable and beneficial to your situation.

Review the list of security considerations and actions that you can take to strengthen the security of your application. Most of the actions have one-time implementation costs; some have performance costs. All these actions have significant benefits in terms of user convenience and security. Select the actions that are most applicable and beneficial to your situation.

Assign responsibility for administering security

Monitor the security of ongoing application development

Securely authenticate all logins and REST API requests

Control access to specific data and functions

Appropriately audit changes to data and user/developer actions

Remove other vulnerabilities in your application environment

Prepare to securely migrate your application to production

Perform production testing in a production-like environment

Assign responsibility for administering security

At the beginning of application development, determine who is responsible for verifying the completion of the tasks in this checklist, and assign clear responsibility for each task.

Determine who is responsible for this checklist

Create a Security Administrator work queue. Add operators to this work queue who are responsible for verifying the completion of checklist tasks. Click the option on each task to create a corresponding user story, give it a high priority, and assign to this work queue.

For more information, see Notifying operators of work queue activity.

Monitor the security of ongoing application development

Before deploying an application in production, you must perform several monitoring activities. You can save time and reduce costs if you perform them regularly in development, when you can make changes without requiring extensive refactoring and retesting.

Keep application rules guardrail-compliant

Review the Application Guardrails landing page weekly and make changes to keep your application rules in compliance. Many security features can be enforced only in application rules that comply with Pega Platform guardrails.

Do not wait until deploying your application to eliminate non-compliant rules, because applying changes is costlier after deployment.

For more information, see Improving your compliance score.

Eliminate vulnerabilities in custom code

Run the Rule Security Analyzer weekly to search through custom (non-autogenerated) code in your rules. This utility finds specific JavaScript or SQL coding patterns that might indicate a security vulnerability.
Remove vulnerabilities immediately to avoid wasting time refactoring and retesting your work.

For more information, see Searching for security vulnerabilities in rules.

Address security alerts promptly

Review run-time security alerts weekly and take appropriate remedial actions to eliminate their causes.

Configure properties appropriately

When you create rules, minimize data corruption by applying the correct type for all properties.

For more information, see Property form: Completing the General tab - Value modes.

Securely authenticate all logins and REST API requests

Ensure that login attempts, and attempts to access data or functions through application services, are correctly authenticated and are from known, trusted users and systems.

Use login authentication services supplied by Pega Platform

You should only use the types of Authentication Services supplied by Pega Platform  (which all invoke the PRAuth servlet) for authentication login users, and avoid writing custom authentication services that can be difficult and risky to deploy. Pega Platform supports the following protocols for user logins.

  • SAML 2.0: User identity is verified through an external identity provider that supports the SAML 2.0 protocol, such as Microsoft Active Directory. 
  • OpenID Connect: User identity is verified through an external identity provider that supports the OpenID Connect (OIDC) protocol.
  • Anonymous: User identity is not verified until partway through a session. For example, an unauthenticated user can add items to a shopping cart, and enter credentials when they check out.
  • Token credentials:  User identity is verified through use of a token that is validated by an external identity provider or by the  OAuth 2.0 authorization layer; often used in offline mobile applications.
  • Basic credentials:  User identity is verified through a user ID and password that can be stored in the Pega database or another internal or external data source.

For more information, see Authentication Services

Configure authentication security policies

Configure the following authentications security policies for better user authentications and session management:

  • Password format policies defend your system against brute force attacks in which a hacker tries thousands of randomly generated credentials or popular passwords from a password dictionary to gain access to your application.
  • CAPTCHA policies guard passwords against brute force attacks by automated processes.
  • Session lockout policies guard against brute force attacks by locking out operator IDs with too many failed login attempts.
  • Policies for auditing login attempts can help identify patterns of suspicious behavior.
  • Multifactor authentication increases identity verification by requiring a second, one-time password that is sent to the operator from a separate device or account.
  • Operator access policies automatically disable operator IDs that are inactive for a specified number of days.

For more information, see Managing security policies.

Configure authentication time-outs

Set an appropriate authentication time-out for each access group according to corporate standards. Configure this setting on the Advanced tab of the Access Group form. For custom authentication, set this time-out to be longer than the time-out in the external authentication service.

For more information, see Configuring security settings for an access group.

Securely authenticate attempts to access services

Make application services to external systems and requestors secure by using appropriate authentication. Ensure that each service package uses a strong authentication profile and requires TLS. Do not put into production services that are unauthenticated or that use only basic authentication.

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

Control who is authorized to access specific data and functions

Limit access to sensitive data and your application’s functionality (especially the ability to change application data, and the application itself) to those who need it to perform their tasks, and prevent others from gaining unnecessary access.

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

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

It is critical to protect access to certain types of rules such as activities, reports, and flow actions which could provide access to sensitive data, or the ability to do harm within the application, by assigning privileges to them that are not available to unauthorized individuals. It is not recommended that you wait until application testing and deployment to do this, since 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 automate the process of adding appropriate privileges. 

Review all access groups, especially access groups for unauthenticated users, to make sure that it has 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 user privileges, credentials, or other information on the clipboard to properties in each instance of the restricted class.

For more information, see

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.

Audit changes to application data

Enable field-level auditing in History- tables, where appropriate, to track changes to key sensitive class properties.

For more information, see Enabling security auditing for a data class or rule type.

If you are deploying on Pega Cloud, for more information, see

Audit other types of user and developer actions

Configure security event logging to track user and developer actions that might be unauthorized or indicate suspicious patterns of behavior. If a security violation or breach occurs, the log can help you determine the level of exposure and risk, and identify remedial actions.

For more information, see Selecting a security event to monitor.

Remove other vulnerabilities in your application environment

In addition to configuring basic features for authentication, authorization, and auditing, remove other vulnerabilities in your environment.

Secure database access

Secure your database connections. In Designer Studio, in the Records Explorer, click SysAdmin > Database, and open the database instance. On the Database tab, in the How to connect field, select use JDBC Connection Pool setting. This setting allows the Pega Platform application to access databases through a Java Naming and Directory Interface (JNDI) server. Avoid using the Use configuration in Preferences setting to define databases, because it displays credentials in the database as clear text.

Limit the capabilities and roles in the Pega Platform database account to restrict the ability to truncate tables, create or delete tables, or otherwise alter the schema. This limit on capabilities and roles might cause the View/Modify Database Schema tool to operate in read-only mode.

For more information, see Creating a database data instance.

Secure file uploads

Pega Cloud Services environments automatically check uploaded files for viruses. If you do not have a Pega Cloud Services environment and documents can be uploaded into your application, we recommend you secure them as follows:

  • Use a virus checker to check the files that can be uploaded. You can use an extension point in the CallVirusCheck activity to check attachments.
  • Regularly update your virus checker to enable detection of new viruses.
  • Restrict the file type by adding a when rule or a decision table to the SetAttachmentProperties activity to evaluate whether a document type is allowed. If a file type is not allowed (evaluated as false), you can set up a message on the step page that stops the save attachment activity from being performed.
  • Verify that the XML/AllowDocTypes dynamic system setting is set to false.

For more information, see

Secure HTML if it exists in your application

Keep your application guardrail-compliant and do not include custom (non-autogenerated) HTML. However, if you do include custom HTML, follow Pega guidelines to minimize security vulnerabilities in your application.

For more information, see Security guidelines for custom HTML.

Prepare to securely migrate your application to production

Some security recommendations are most appropriate to perform when you move an application to a production environment. These recommendations are essential to avoid common security vulnerabilities.

Lock rulesets

Lock each ruleset version with a secure password by clicking Lock and 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.

If there are some rules in your application (for example, decision tables) that are intended to be modified in production, and are therefore in unlocked rulesets, you should then ensure that only rules intended to be modifiable are in these unlocked rulesets.

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

Block unnecessary roles and operators from production

In the production environment, eliminate or block any operators and roles used in development or test environments that 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, to prevent access by operators 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 salted bcrypt algorithm.

For more information, see Password hashing.

To prevent unauthorized access with default passwords, change the passwords for the default operators that you plan to use, and disable or delete the operator IDs that you do not plan to use. As a best practice, always change the passwords for IDs that end with @pega.com (including Administrator@pega.com, Batch@pega.com, and External@pega.com) and for the operator IDs that the external setup wizard creates during installation. You can also disable, delete, or customize default operators.

For more information, see

Secure web.xml

If you are not deploying your application to Pega Cloud, make the following changes to the web.xml deployment descriptor file:

  • Limit or block access to the  servlets that support only testing and debugging, including HeapDisplay, SecManServlet, and PRSOAPSimulator.
  • Remove unnecessary resources and servlets.
  • Set appropriate time-outs at the application server level and requestor level.
  • Block access to the prweb/PRServletservlet that allows users to log in using the older platform login process instead of the newer PRAuth-based authentication services.

For more information, see Application URL patterns for various authentication service types.

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 for application security.

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 Pega Platform 8.1 and later, 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.

Do not deploy checked-out rules

Run the Checked Out Rule Report and eliminate rules that are checked out.

Define appropriate Content Security Policies (CSPs)

Review and define an appropriate Content Security Policy (CSPs). Specify a policy for every production application to inform the user's browser of locations from which an application can load resources.

For more information, see Configuring a content security policy.

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.

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.

Configure logging levels appropriately

Set appropriate logging levels for production. Minimize the amount of detail in log files by setting the log level to INFO or lower to minimize security risks.

Configure your Pega Cloud environment

If you are deploying your application to Pega Cloud, you should perform these actions:

  • If appropriate, request a virtual private cloud (VPC) peering connection.

 For more information, see Requesting a virtual private cloud (VPC) peering connection.

  •  Complete other connectivity options required for your applications.

 For more information, see Completing your environment connectivity.

  • Set up a custom domain name (or “vanity” URL) that does not unnecessarily expose server information to users.

For more information on how to do this on Pega Cloud, see Requesting a custom domain name.

Perform production testing in a production-like environment

During production testing, configure your application and the test environment to mirror the intended production environment. Otherwise, your testing might not uncover serious security vulnerabilities.
The tasks in this section are not required if you are deploying your application to Pega Cloud, since it automatically performs these tasks.

Apply patches, updates, and hotfixes

Install the latest patches and updates to the operating system, application and web servers, proxies, database, and related applications. 

For Pega Platform 8.x releases, you should install the latest patch release. For earlier Pega Platform Releases you should be running the latest version, and planning to upgrade to Version 8.x in the near future. 

Regardless of what release you are running, you should frequently check for any recommended security updates, which are posted at https://collaborate.pega.com/discussion/essential-hotfixes.

Configure the database and communications to mirror production

Configure the system and database according to your company’s security policies as in the production environment to which the application will be deployed. This configuration should include the use of TLS for all communication between clients and the application.

If you use TLS, remove any cipher suites that have null ciphers. This action prevents the login credentials and password from traveling in clear text format between the client and server even over a TLS connection (if a server and client discover only a null cipher suite in common).

Configure authentication to mirror production

Configure the system to mirror the production authentication scheme. Verify that all client updates and patches are applied. When testing authentication from a browser, clear the browser’s password history and disable the browser’s autocomplete or autofill feature.

Configure the application server to mirror production

Configure the application server in your test environment to mirror the configuration in your production environment.

For more information, see Security guidelines for test environments.

Test monitoring and analyzing security events and alerts

Define the process for routinely monitoring security alerts and security events in production for your application. Test that process by intentionally generating alerts and events to verify that your process identifies and responds to them in a timely manner.


Related Content

Have a question? Get answers now.

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