Requirements for securing an application

To secure the Rules in your application, perform the following tasks: 

• Verify that properties are the correct type, such as integers or dates, instead of just text. 
• Run the Rule Security Analyzer and address any identified issues. 
• Resolve any security issues found in the Guardrail report. 

Before you promote an application from the development environment, lock each Ruleset version except the production Ruleset. Restrict adding or updating Ruleset versions and the Ruleset rule by entering three distinct passwords on the Security tab of the Ruleset record. If you use Deployment Manager for automatic deployment, review additional considerations for locking Rulesets.

If your application can accept document uploads, perform the following tasks: 

• Install a virus checker to enforce which files can be uploaded. Use an extension point in the CallVirusCheck activity to ensure that a virus checker is installed. 
• Restrict file types 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 meets requirements and is thoroughly tested. Ensure that the production level in the System record is set appropriately. For the production environment, set the production level to 5. The production-level value affects Rule-Access-Role-Obj and Rule-Access-Deny-Obj rules, which control the classes that a requestor with an Access Role can read and update. If this setting restricts valid user access, add targeted Rule-Access-Role-Obj Rules instead of lowering the production level.

Enable the security policies in your application in Dev Studio. Security Policies are compatible with the following authentication types:

• SAML 2.0
• OpenID Connect
• Multi-factor authentication

If you require additional security policies, add a validation Rule. Set appropriate time-outs at the application server level, requestor level, and Access Group level. 

Collaborate with the application security team and external system teams to verify that connectors and services are appropriately secured.

If your installation of Pega Platform was deployed in secured mode from the very beginning, users are disabled by default. If your installation was not deployed in secure mode, you should disable any unused users. Then, enable security auditing for changes to operator passwords, access groups, and application Rules. 

Review the Unauthenticated Access Group to ensure that it has the minimum required access to Rules. 

Configure the dynamic system settings as described in the Security Checklist for a production environment. 

When deploying an application to an environment other than development, limit or block functionality for certain features and remove unnecessary resources. Default settings expose an application to risks because they provide a known starting point for intruders. Removing defaults 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 because 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 Java Database Connectivity connection pool approach through the application server, rather than setting up the database in the prconfig.xml file. 

Limit the features and roles that are available to the PegaRULES database account on environments other than development to reduce additional features that truncate tables, create or delete tables, or otherwise alter the schema. This limitation on features and roles might cause the View/Modify Database Schema tool to operate in read-only mode. 

Check your knowledge with the following interaction: