Security Policies in PEGA

Before We Begin

Every organization which provides service to end-users/customers will have their own security policy requirements. Some of the commonly used examples are:

• We have to satisfy password complexity mentioned by banking organization while registering for a net-banking application.
• All social media platform applications like Facebook, LinkedIn, Twitter have password lock-out policy when users tries keying-in invalid passwords for “n” number of times.
• Many online shopping applications like Flipkart, Amazon performs additional validation by sending One Time Password to registered mobile number/ email-id when customers try updating their confidential details.
• Many third party websites have Captcha policies enabled to confirm that the users are humans and not robots or any automated machine inputs.

What is Security policy in PEGA?

PEGA provides various authentication types [PRBasic, PRSecuredBasic, Custom etc.] to secure our application. In addition to that, PEGA also provides us an option to implement security policies on top of authentication.

Security policies can be accessed from Designer Studio/DEV Studio by navigating to:

Below security policies are available OOTB, which can be customized/extended based on the organization needs.

• Password Policies
• Multi-factor authentication policies (using one-time password)
• Lockout policies
• CAPTCHA policies
• Operator disablement policy
• Audit policy

Pre-Requisites for implementing Security Policy

Below pre-requisites should be satisfied before implementing security policies in PEGA:

• Security policy must be enabled by selecting “Enable frequently required policies ” in the security policies landing page.
• Operator record should not be configured to use external authentication. Security policy will not be applicable if operator is configured to use external authentication.

Business Scenario

Let us consider a scenario of building Employee-Onboarding application for OSP Organization.

Every employee getting on-boarded will be created as an operator in the system. Successfully on-boarded employees can view payslips, e-letters, apply leaves, log time sheets, manage meetings etc. through their portal.

OSP organization has security requirements to authenticate their employees’ login using basic authentication. In addition to authentication, OSP also requires implementing below security policies during user login.

1. Each employee password should meet below requirements:
   • Minimum length of 10
   • At least 1 uppercase alphabet
   • At least 1 numeric value between[0-9]
   • At least 1 special character
   • Password should not be same as that of 5 historical passwords
2. Every password change/update should be additionally authenticated using One Time Password sent to employees contact email id/phone number. OTP should be valid only for one attempt and the validity duration is 5 minutes.
3. Account should be locked after 3 unsuccessful attempts.
4. CAPTCHA should be generated for every unsuccessful attempt and user should enter the CAPTCHA value shown on the screen during subsequent login attempts.
5. Operator ID should be disabled if employee is inactive for more than 10 days.
6. All the login attempts irrespective of success or failure should be recorded in the system for future auditing purpose.

Let us now see how to implement the above requirement using PEGA security policies.

Password Policies

Password policies section allows us to specify the expected pattern and complexity of the operator password. When password policies are used, all the new passwords will be evaluated to meet the specified pattern and system will throw error if the complexity is not met.

Navigate to Security Policies landing page and scroll down to password policies section.

Below configurations in password policies are required to satisfy the OSP security requirement.

When user tries to change the password either through login screen or directly through operator ID record, system evaluates if the newly provided password meets the configured complexity.

When we try re-setting the password with one of our older passwords, system restricts and throws error based on the value set for “Maximum unique historical operator passwords” which is 5 in our case.

Multi-factor authentication policies

Multi factor authentication policies allows us to define the configurations for enabling and sending One Time Password through email or phone. If this option is enabled, additional validation using OTP happens during password updates.

Navigate to Security Policies landing page and scroll down to multi-factor authentication policies section.

Below configurations in multi-factor authentication policies are required to satisfy OSP security requirements:

The above configuration will send OTP to the email id mentioned in the operator record and will be valid for 5 minutes. When SMS account is configured, the OTP will be sent to the phone number provided in the operator record.

OTP is sent as an email to the operator’s email ID as shown below:

When OTP gets expired [based on the interval mentioned in the policy], system throws OTP expiry message and user should generate a new OTP to reset password.

Lockout policies

Lockout policies allows us to define the number of failure attempts after which the password gets locked. Password lockout can be configured in two ways as mentioned below:

• Password Lockout: Account can be directly locked after “n” number of failure attempts. Unlocking the account can be done either manually or automatically.

• Password lockout penalty: Password lockout penalty will not lock the account, rather it delays the next login attempt as per the configured time duration.

Now let us navigate to Security Policies landing page and scroll down to lockout policies section to set the lockout policies to satisfy OSP security requirement.

Let us unlock the account by navigating to Operator Access landing page as shown below:

pyUnlockOperatorExtension activity can be customized to automatically notify the operator about the new password during unlock.

CAPTCHA policies

CAPTCHA presents an image of numbers and letters; prompts the users to enter the displayed characters into a field . This additional step of authentication ensures that the person trying to login is a human and not a bot.

Let us navigate to Security Policies landing page and scroll down to CAPTCHA policies to configure OSP’s CAPTCHA requirements.

System prompts the user to enter the CAPTCHA in the following scenarios:

• When user login fails.
• When user logs in into the system for the first time.
• When user logs in for the first time using a new system.

Operator disablement policy

Operator disablement policies allows system to automatically disable operators when they are inactive for “n” number of days.

List of operator IDs that are to be excluded from the disablement policy should be mentioned explicitly. Operator IDs used for basic authentication in service, model user for Mash ups etc. can be added to such exclusion list.

Let us navigate to the Security Policies landing page and scroll down to Operator disablement policies section to configure policy to satisfy OSP security requirement.

List of disabled operator IDs in system can be viewed from Operator access landing page.

Audit policy

The audit log records the login attempts. For each login, the log captures the following information:

• Create Date/Time – The time of the attempt
• Remote IP Address – The IP address of the system from which the attempt was made
• Remote Host – The name of the computer involved
• User Name – The operator ID used in the login attempt
• Message – The status message returned during authentication of the login
• Browser (User-Agent) – HTTP Request Header “User-Agent”
• Referrer – HTTP Referrer of the “User-Agent”
• Via – Records proxies through which the request was sent

Navigate to Security Policies landing page and scroll down to Audit policy section to implement Audit Policy as required by OSP.

1. Level of audit log level policy:
   • None – No log entry is added
   • Basic – Record failed login attempts only
   • Advanced – Record failed and successful login attempts
2. Select Display Audit Log on top right corner of security policy landing page to review the audit log. The log is displayed as a Report Definition report.

The default time period covered is one month. We can adjust the range as needed.

Conclusion

We can build a strong & secured application for an organization by extending & implementing Security Policies provided by PEGA in addition to authentication.

We are glad to publish the article requested by @ Matheswaran on “Security Policies in PEGA“.If you want us to publish any articles of your choice, please fill out this form & we will make sure that it gets published.

Stay tuned for more posts on Security – Authentication !!!