Security policies

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)

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.

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.

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.

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

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

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.

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.

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.

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

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.

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.