Skip to main content
Verify the version tags to ensure you are consuming the intended content or, complete the latest version.

Security policies

Application-level and feature security

The time to consider application security is early on, such as during the Prepare phase of your project, before you begin to build and configure the application. To protect your application from hackers and prevent unauthorized access and use, you need to manage two types of security: application-level and feature security.

Application-level security

Application-level security focuses on protecting the application from outsiders and unauthorized users. For example, with application-level security you:

  • Reduce the risk of unauthorized users getting into or stealing data from your application
  • Identify authorized users who need access to the application
  • Create password and authentication policies

Application-level security considers all the ways you can protect the application, such as using third-party security tools or setting up multi-factor authentication. The goal of application-level security is to make it impossible for non-authorized users to break into, read, or otherwise access your application.

Feature security

Feature security focuses within the application by determining the case types, features, and data that authorized users can or cannot access. For example, with feature security you:

  • Set up security roles for personas identified in each case type so that authorized users can access the application features they need
  • Prevent users from viewing features or accessing data to which they should not have access
  • Design both role-based access control (RBAC) and attribute-based access control (ABAC)
Note: To review setting up users and roles, see Inviting users to an application

For example, in a Payroll application, the business owner wants each manager to be able to view the pay history of their direct report employees, but not view the pay history of peers or other staff members. In addition, no manager can manually change the pay rate of the employee. However, the payroll manager and the CFO can view pay history for all employees as well as update pay rates. As you document the manager user story, consider what payroll features the manager can and cannot access.

Note: As a best practice, SSA and LSA team members should identify security needs during the Discover (Sales) phase of a project and document them during the Design phase. For more detail on phases within Pega Express, see to Pega Community topic Pega Express Delivery

Application security configuration on Pega Platform

One way to limit unauthorized access to your applications is to configure the settings on the Security Policies tab of the Authentication landing page in App Studio. In Dev Studio, open the Configure menu and select Org & Security > Authentication > Security Policies to view and update the security policies for the entire Pega Platform™ server.

Caution: Settings for a specific authentication service may override settings on the Authentication landing page.

After you update a setting, click Submit at the bottom of the page to record an update. Changes to security policies become active immediately on form submission.

Note: Applying appropriate security policies is only one aspect of securing an application. For a complete list of security leading practices, consult the Security Checklist awareness module and the Security Checklist for Pega Platform deployment. 

Frequently required policies

The settings in the Frequently required policies section of the Security Policies tab allow you to implement policies for password strength, limits on incorrect guesses, and logging levels for login attempts. The Frequently required policies section is divided into four parts.

  • Password policies govern the strength of user passwords
  • CAPTCHA policies test whether a person entered the password
  • Lockout policies define system behavior when users enter an incorrect password
  • Audit policy determines the amount of detail written to the system log for a security issue

Other policies

The settings in the Other policies section of the Security Policies tab allow you to implement multi-factor authentication and disable access for unused user accounts.
Tip: For a detailed explanation of the settings for each type of policy, including minimum and maximum allowed values, see the help topic Security policies settings.

Password policies

Use the Password policies section to customize requirements for password length, complexity, and predictability.

Caution: Unlike length and complexity, which you can manage well through the policies in this section, predictability depends upon sound judgment by users.

In the following image, click the + icons to learn more about the available settings.

CAPTCHA and lockout policies

To stop or slow a brute-force attack, limit the number of failed login attempts. For example, you can require that after a third failed attempt, further attempts are blocked for 15 minutes. Two approaches to limiting users after too many incorrect guesses are CAPTCHAs and lockouts.

CAPTCHA policies

A CAPTCHA is a challenge-response test to determine whether users are human. A CAPTCHA typically presents users with one or more images and asks users to identify a specified detail. For example, a CAPTCHA may present users with an image of a sequence of letters and numbers, which users must type into a text field. The image may stretch or skew the characters to increase the difficulty of reading the characters with automated character recognition techniques. The following image shows Pega Platform prompting a user with a CAPTCHA.

Example of a CAPTCHA test upon login

Use the CAPTCHA policies section to enable and configure a CAPTCHA to challenge login attempts. When enabled, you can:

  • Choose between the default implementation or a custom implementation.
  • Enable the use of a CAPTCHA on the initial login.
  • Set the likelihood that users receive a CAPTCHA after a failed login.

Lockout policies

Lockouts enforce a waiting period after users attempt a specified number of failed login attempts to prevent another login attempt until the waiting period ends. Lockouts can slow or prevent a brute-force attack.

Use the Lockout policies section to customize when and how long users must wait after a failed login attempt. The options listed depend on whether the lockout policy is enabled or disabled. When a lockout penalty is enabled, you can:

  • Set a threshold value for failed login attempts.
  • Set the initial lockout penalty period in seconds. Repeated login failures increase the penalty period automatically.
  • Maintain a log of login failures for a specified number of minutes.

When a lockout policy is disabled, you can:

  • Set the number of allowed failed login attempts before an account is locked.
  • Set the time in minutes for when the user's account is locked.

In the center of the following image, slide the vertical line to compare enabled and disabled lockout policies.

Audit policy

Use the Audit policy section to customize the level of detail captured for login attempts. To record login failures only, set the logging level to Basic. To record both the failed and successful attempts, set the logging level to Advanced.

Consider the Audit policy in the Payroll scenario. The Business Owner may want to audit a payroll manager's changes to the pay rate of an employee to ensure payroll increases do not occur without proper approval.

Multi-factor authentication policies

Passwords represent one way to authenticate users. To increase security, enable multi-factor authentication to authenticate users. With multi-factor authentication, users gain access only after providing multiple factors, or pieces of evidence, to verify their identity.

  • Knowledge – Something that only users know, such as a password
  • Possession – Something that only users have, such as a mobile device
  • Inheritance – Something that represents a characteristic of users, such as their location
Note: Two-factor authentication is a subset of multi-factor authentication, in which users provide two pieces of evidence at login.

Pega Platform provides a default multi-factor authentication feature that sends a one-time password to users by either email or SMS text message. To complete the login process, users must enter the one-time password within the allowed time. Use the Multi-factor authentication policies (using one-time password) section to configure the settings for this one-time password.

In the following image, click the + icons to learn more about multi-factor authentication settings.

Operator disablement policy

Use the Operator disablement policy section to automatically disable access for users who are inactive for the specified number of days. To prevent the system from disabling access for users who need access, add the operator ID record for the user to the Exclusion list of operator IDs list.

An example of operator disablement might be a situation in which a community content contributor user has not added content to a WordPress site in over a year or when an employee on medical leave has not accessed the employee training portal as an admin in over 90 days. Or, the ID for a CFO is not disabled even if she only accesses the system during the year-end audit.

Note: Decide which users need to retain access even if they use the system infrequently.

Check your knowledge with the following interaction.

Check your knowledge with the following interaction.

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