Requirements for securing an application

Perform the following tasks:

• Ensure that properties are of the correct type (integers, dates, not just text).
• Run the Rule Security Analyser and fix any issues.
• Fix any security issues in the Guardrail report.

Lock each ruleset version, except the production ruleset, before promoting an application from the development environment. Also, secure the ability to add versions, update versions, and update the ruleset rule itself by entering three distinct passwords on the security tab on the ruleset record.

If documents can be uploaded into the application, complete the following tasks:

• Ensure that a virus checker is installed to enforce which files can be uploaded. You can use an extension point in the CallVirusCheck activity to ensure that a virus checker is installed.
• Ensure file types are restricted by adding a when rule or decision table to the SetAttachmentProperties activity to evaluate whether a document type is allowed.

Verify that the authorization scheme is implemented and has been extensively tested to meet requirements. Ensure the production level is set to an appropriate value in the System record. Set the production level to 5 for the production environment. The production-level value affects Rule-Access-Role-Obj and Rule-Access-Deny-Obj rules. These rules control the classes that can be read and updated by a requestor with an access role. If this setting interferes with valid user needs, add focused Rule-Access-Role-Obj rules that allow access instead of lowering the production level.

Enable the security policies (Dev Studio > Configure > Org & Security > Authentication > Security Policies). Security Policies are compatible with the following Authentication Types:

• Basic Credentials
• SAML 2.0
• OpenID Connect

If additional restrictions are required by a computer security policy, add a validation rule. Set up time-outs at the application server level, requestor level, and access group level that are of an appropriate length.

Work with the application security team and external system teams to ensure connectors and services are secured in an appropriate way.

If the Pega Platform was deployed in secured mode out-of-the-box users are disabled by default. Disable any users not used if the platform was not deployed in a secure mode. Enable security auditing for changes to operator passwords, access groups, and application rules.

Review the Unauthenticated access group to make sure that it has the minimum required access to rules.

Configure the Dynamic System Settings in a production environment as described in the Security Checklist.

When deploying an application to an environment other than development, limit or block functionality to certain features and remove unnecessary resources. Default settings expose risks to an application because they provide a known starting point for intruders. Taking defaults out of the equation reduces overall risk dramatically.

Make the following changes to default settings:

• Rename and deploy prweb.war only on nodes requiring it. Knowing the folder and content of prweb.war is a high-security risk as it provides access to the application.
• Remove any unnecessary resources or servlets from the web.xml. Rename default servlets where applicable, particularly PRServlet and PRAuth.
• Rename prhelp.war and deploy it on a single node per environment.

Ensure that the system has been set up using a JDBC connection pool approach through the application server, rather than the database being set up in the prconfig.xml.

Limit the capabilities and roles that are available to the PegaRULES database account on environments other than development to reduce additional capabilities 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.