Skip to main content
This content has been updated. Click here to continue your progress on the latest version.

Requirements for securing an application

Find out who is responsible for application security in the organization and engage them from the start of the project to find out any specific requirements and standards, and what level of penetration testing is done.

Rules

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.

Rulesets

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.

Documents

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.

Authorization

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.

Authentication

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.

Integration

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

Operators and access groups

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.

Dynamic System Settings

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

Note: Do not configure the Dynamic System Settings related to Security for a development environment, because they restrict the Tracer tool and other developer tools.

Deployment

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.

Database

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.

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice