PEGACPLSA23V1 Security Design

Security Design Detailed Explanation

Security in Pega applications ensures data and system integrity, protecting against unauthorized access, breaches, and misuse. It comprises authentication (verifying users), authorization (controlling access), data security, and audit and compliance measures.

7.1 Authentication

Authentication verifies a user's identity to allow secure access to Pega applications. Pega supports multiple authentication methods to accommodate enterprise requirements and industry standards.

Key Authentication Methods in Pega

1. LDAP Authentication
2. SAML Single Sign-On (SSO)
3. OAuth 2.0 for API Authentication
4. Multi-Factor Authentication (MFA)

7.1.1 LDAP Authentication

What is LDAP Authentication?

LDAP (Lightweight Directory Access Protocol) is a protocol used to authenticate users against a centralized directory service, such as Microsoft Active Directory or OpenLDAP.

How LDAP Authentication Works

1. A user attempts to log in to the Pega application.
2. Pega sends the user's credentials (username and password) to the LDAP server.
3. The LDAP server verifies the credentials and returns a success or failure response.
4. Pega grants or denies access based on the LDAP server's response.

Example of LDAP Authentication

Scenario: A company uses Active Directory for centralized user management.

Steps:

1. The user enters their corporate username and password.
2. Pega forwards these credentials to the Active Directory server.
3. If credentials are correct, the user is authenticated, and the system loads their Access Group.

Steps to Configure LDAP Authentication in Pega

1. Create an Authentication Service:

   • Go to Records → SysAdmin → Authentication Service.
   • Select LDAP as the authentication type.

2. Configure LDAP Server Details:

   • Specify the LDAP server hostname and port (e.g., ldap.company.com:389).
   • Define the Base DN (Distinguished Name) for user lookups, such as dc=company,dc=com.

3. Map User Attributes:

   • Map LDAP attributes (e.g., sAMAccountName) to Pega properties like Operator ID.

4. Test the Configuration:

   • Use the Test Connectivity option to verify the LDAP server connection.

5. Assign Access Groups:

   • Map LDAP users to Pega Access Groups to control their roles and permissions

Advantages of LDAP Authentication

1. Centralized management of user credentials.
2. Users can log in with their corporate credentials.
3. Simplifies user provisioning and de-provisioning.

7.1.2 SAML Single Sign-On (SSO)

What is SAML SSO?

SAML (Security Assertion Markup Language) Single Sign-On enables users to authenticate once using an identity provider (IdP), such as Okta, Azure AD, or Google, and access multiple systems (including Pega) without re-entering credentials.

How SAML SSO Works

1. The user accesses the Pega application.
2. Pega redirects the user to the SAML Identity Provider (IdP) for authentication.
3. The IdP verifies the user's credentials and sends a SAML Assertion back to Pega.
4. Pega grants access based on the assertion.

Example of SAML SSO

Scenario: A company uses Okta as the Identity Provider (IdP).

Flow:

1. The user logs in to Okta.
2. Okta sends a SAML Assertion to Pega, confirming the user’s identity.
3. Pega grants access and assigns the appropriate Access Group.

Steps to Configure SAML SSO in Pega

1. Create a SAML Authentication Service:

   • Go to Records → SysAdmin → Authentication Service.
   • Select SAML 2.0 as the authentication type.

2. Configure Identity Provider Details:

   • Enter the Issuer URL and SSO Endpoint URL provided by the IdP.
   • Import the IdP Certificate for secure communication.

3. Map User Attributes:

   • Map SAML attributes (e.g., email, role) to Pega properties like Operator ID and Access Group.

4. Test SSO Login:

   • Attempt login through the SSO flow and verify successful authentication.

Advantages of SAML SSO

1. Users log in once and access multiple applications.
2. Enhances user experience with seamless authentication.
3. Centralized management of user credentials.

7.1.3 OAuth 2.0 for API Authentication

What is OAuth 2.0?

OAuth 2.0 is an industry-standard protocol for API authentication. It allows secure access to APIs by using access tokens rather than user credentials.

How OAuth 2.0 Works

1. A client application requests an access token from an OAuth Authorization Server.
2. The server issues a token upon verifying the user’s identity and permissions.
3. The token is passed with API requests to authenticate access.
4. The resource server (Pega) validates the token and grants access.

Example of OAuth Authentication

Scenario: A third-party application wants to access a Pega REST API.

Flow:

1. The client application sends a request to the OAuth server to obtain an access token.

2. The OAuth server validates the request and issues a token.

3. The token is included in the API call to Pega:

   GET /api/v1/cases  
   Authorization: Bearer <AccessToken>
   

4. Pega validates the token and processes the API request.

Steps to Configure OAuth 2.0 in Pega

1. Set Up OAuth Authentication:

   • Go to Records → SysAdmin → Authentication Profile.
   • Select OAuth 2.0 as the authentication type.

2. Register a Client Application:

   • Define the client ID and client secret for the application.

3. Configure Token Validation:

   • Specify the OAuth Authorization Server and Token Endpoint URL.

4. Secure APIs:

   • Enable OAuth 2.0 protection for Pega REST services using the configured Authentication Profile.

Advantages of OAuth 2.0

1. Secure authentication for APIs using access tokens.
2. Eliminates the need to share user credentials with third-party applications.
3. Supports modern authentication standards for integration.

7.1.4 Multi-Factor Authentication (MFA)

What is Multi-Factor Authentication?

MFA adds an extra layer of security to user authentication by requiring two or more verification factors. This ensures that even if one factor (e.g., password) is compromised, unauthorized access is prevented.

MFA Verification Factors

1. Something You Know: Password.
2. Something You Have: OTP (One-Time Password) sent to a mobile device.
3. Something You Are: Biometrics (e.g., fingerprint, facial recognition).

Steps to Implement MFA in Pega

1. Use an external authentication provider (e.g., Okta, Azure AD) that supports MFA.
2. Configure Pega to redirect users to the external provider during login.
3. The external provider enforces MFA by sending an OTP or biometric verification.
4. Once verified, the provider redirects the user back to Pega.

Advantages of MFA

1. Protects against stolen or weak passwords.
2. Meets compliance standards for secure authentication.
3. Enhances overall security for sensitive applications.

Summary of Authentication

Authentication Method	Purpose	Use Case
LDAP Authentication	Verify users with a directory service.	Authenticate corporate users via LDAP.
SAML SSO	Enable single sign-on for applications.	Users log in once to access multiple systems.
OAuth 2.0	Secure API authentication with tokens.	Third-party apps access Pega APIs securely.
MFA	Add extra verification layers.	High-security applications (e.g., banking).

7.2 Authorization

Authorization determines the level of access a user has within a Pega application. It ensures that users can only view or interact with the parts of the application that are relevant to their roles and permissions.

Key Components of Authorization

1. Access Groups
2. Access Roles and Access Control
3. Privileges

7.2.1 Access Groups

What is an Access Group?

An Access Group is a Pega rule that defines the roles, application versions, and portal access for a group of users. It acts as a bridge between users and their permissions.

Features of Access Groups

1. Define Roles: Specify access roles to control user permissions.
2. Associate Applications: Link users to specific applications and versions.
3. Portals: Configure the default portal (e.g., Case Manager, User Portal) a user will access.
4. Customization: Define landing pages, home views, and workspaces.

Example: Access Groups for a Loan Application System

Access Group	Roles	Application	Portal
LoanAdminAccessGroup	AdminRole, ManagerRole	LoanApp 01.01.01	Admin Portal
LoanManagerAccessGroup	ManagerRole	LoanApp 01.01.01	Case Manager Portal
LoanUserAccessGroup	UserRole	LoanApp 01.01.01	User Portal

Steps to Configure Access Groups

1. Go to Records → Security → Access Group.
2. Create a new Access Group and configure:
   • Application: Specify the application and version.
   • Roles: Assign one or more Access Roles.
   • Portal: Select the portal the user will access (e.g., User Portal, Admin Portal).
3. Assign the Access Group to users:
   • Open the Operator ID record.
   • Set the Default Access Group and additional groups as needed.

Benefits of Access Groups

1. Centralize user role management.
2. Control which application version users can access.
3. Customize portals and workspaces for different user groups.

7.2.2 Access Roles and Access Control

What is an Access Role?

An Access Role is a collection of permissions that determines what actions a user can perform within an application. Roles are linked to Access Control rules that define these permissions.

Types of Access Control

1. Access Control Lists (ACLs)
2. Rule-Based Access Control

1. Access Control Lists (ACLs)

Access Control Lists (ACLs) are rules that specify the level of access (e.g., read, write, delete) a user has to specific classes or rules.

Access Level	Description
Read	View records or data.
Write	Modify or create records.
Delete	Delete records.
Execute	Run activities or specific rules.

Example: Access Role Configuration

Scenario: A loan system has the following roles:

Role	Permission
LoanAdminRole	Read/Write/Delete access to LoanApplication class.
LoanManagerRole	Read/Write access to LoanApplication class.
LoanUserRole	Read-only access to LoanApplication class.

Steps to Configure Access Roles and ACLs:

1. Go to Records → Security → Access Role.
2. Create a role (e.g., LoanAdminRole).
3. Configure Access Control:
   • Add ACL rules to define access levels for classes (e.g., LoanApplication).
4. Assign the role to an Access Group.

2. Rule-Based Access Control

Access Roles can control access to specific rules (like activities, sections, or data transforms). You can specify whether a role can execute, modify, or view the rule.

Benefits of Access Roles

1. Enforce fine-grained control over rules and data.
2. Limit user permissions to reduce security risks.
3. Enable role-based security across the application.

7.2.3 Privileges

What is a Privilege?

A Privilege is a security rule that restricts access to specific functionalities or rules within the application. Privileges are often used to control sensitive actions.

When to Use Privileges

• To protect sensitive rules (e.g., activities, flows) from unauthorized access.
• To restrict advanced actions like approving high-value loans or deleting cases.

Example: Restricting High-Value Loan Approvals

Scenario: Only managers can approve loans greater than $100,000.

Steps to Configure:

1. Create a Privilege:
   • Go to Records → Security → Privilege.
   • Name: ApproveHighValueLoan.
2. Assign Privilege to Rule:
   • Open the Flow Action rule for approving loans.
   • Add the ApproveHighValueLoan privilege.
3. Grant Privilege to Roles:
   • Go to the Access Role for managers (LoanManagerRole).
   • Add the ApproveHighValueLoan privilege.

Benefits of Privileges

1. Protect sensitive rules or actions.
2. Implement additional layers of security.
3. Control access to advanced functionalities for specific roles.

Summary of Authorization

Component	Purpose	Example
Access Groups	Define user roles, application versions, and portals.	LoanAdminAccessGroup for admin users.
Access Roles	Control permissions (read, write, delete) for rules.	LoanUserRole has read-only permissions.
Privileges	Restrict access to specific functionalities.	Privilege to approve loans > $100,000.

7.3 Data Security

Data Security ensures that only authorized users can access, view, or modify sensitive data within a Pega application. It applies to both application data and user-specific data. Data security is implemented at the following levels:

1. Row-Level Security
2. Field-Level Security
3. Encryption

7.3.1 Row-Level Security

What is Row-Level Security?

Row-Level Security controls access to specific records (rows) based on the user’s role, attributes, or context. This ensures that users only see or interact with data that they are authorized to access.

How is Row-Level Security Implemented in Pega?

Pega uses Access When Rules and Access Control Policies to implement Row-Level Security:

1. Access When Rules: Define conditions that determine whether a user can access a record.
2. Access Control Policies: Enforce row-level access rules using Access When Rules.

Example: Restrict Access to Loan Applications

Scenario:

• Loan Officers should only see loan applications assigned to them.
• Managers should see all loan applications within their region.

Steps to Implement Row-Level Security:

1. Create an Access When Rule:

   • Go to Records → Security → Access When.

   • Define the condition:

     .AssignedTo == pxRequestor.OperatorID  
     

   • This condition ensures that a record is visible only if it is assigned to the current user.

2. Create an Access Control Policy:

   • Go to Records → Security → Access Control Policy.
   • Set:
     • Class: LoanApplication.
     • Policy Type: Read.
     • Condition: Reference the Access When Rule.

3. Test Access:

   • Log in as a Loan Officer and verify that they can only see their assigned loan applications.
   • Log in as a Manager and confirm they see region-specific records.

Benefits of Row-Level Security:

1. Limits visibility of sensitive records based on user roles.
2. Ensures compliance with privacy and regulatory requirements.
3. Improves application performance by restricting data access.

7.3.2 Field-Level Security

What is Field-Level Security?

Field-Level Security controls access to specific fields (properties) within a record. It is useful for masking or hiding sensitive data from unauthorized users.

How to Implement Field-Level Security in Pega

Field-Level Security is implemented using:

1. Property-Level Access Control.
2. Access Control Policies for specific properties.

Example: Masking Customer SSN for Non-Admin Users

Scenario:

• The SSN (Social Security Number) field should only be visible to Admins.
• For non-admin users, the SSN field should be masked (e.g., XXX-XX-1234).

Steps to Implement Field-Level Security:

1. Create a Property for SSN:

   • Property Name: CustomerSSN.

2. Configure Field Visibility in Section Rules:

   • Use Visibility Conditions:
     • Visible if CurrentUserRole == "Admin".
     • Mask or hide otherwise.

3. Apply Field Masking:

   • Add custom logic to display only the last 4 digits for non-admin users:

     return "XXX-XX-" + .CustomerSSN.substring(7);  
     

4. Add Access Control Policy:

   • Go to Records → Security → Access Control Policy.
   • Define the policy:
     • Class: CustomerDetails.
     • Policy Type: Read.
     • Field: CustomerSSN.
     • Condition: Only accessible if the user is an Admin.

Benefits of Field-Level Security:

1. Protects sensitive information like SSNs, credit card numbers, or salaries.
2. Supports compliance with data protection laws (e.g., GDPR, HIPAA).
3. Provides fine-grained control over data visibility.

7.3.3 Encryption

What is Encryption?

Encryption protects sensitive data by converting it into an unreadable format. It ensures that data remains secure at rest (stored in databases) and in transit (during communication between systems).

Types of Encryption in Pega:

1. Encryption at Rest: Protects data stored in the Pega database.
2. Encryption in Transit: Protects data transmitted between clients and servers.

1. Encryption at Rest

Pega supports database encryption to protect sensitive data fields stored in tables.

Steps to Enable Encryption at Rest:

1. Use Pega Platform Data Encryption:

   • Go to Records → SysAdmin → Keystore.
   • Configure a Keystore with encryption keys.

2. Enable Encryption for Specific Properties:

   • Use Encrypt checkbox when defining a property (e.g., CustomerSSN).
   • Specify the encryption key for the property.

2. Encryption in Transit

To ensure data security during communication:

• Use HTTPS/TLS for secure connections between clients and servers.
• Enable encryption for APIs and integrations.

Steps to Secure APIs:

1. Enable HTTPS on the Pega server.
2. Configure REST/SOAP services to require SSL/TLS encryption.

Example: Encrypting Customer SSN

1. Property: CustomerSSN.
2. Enable encryption:
   • Select Encrypt in the property configuration.
3. Keystore: Use a 256-bit encryption key to protect the field.

Benefits of Encryption:

1. Prevents unauthorized access to sensitive data.
2. Ensures data security at rest and in transit.
3. Supports compliance with regulatory requirements (e.g., PCI-DSS, HIPAA).

Summary of Data Security

Security Level	Purpose	Implementation
Row-Level Security	Restrict access to specific records (rows).	Access When Rules, Access Control Policies
Field-Level Security	Mask or hide sensitive fields from users.	Field masking, Access Control Policies
Encryption	Protect sensitive data at rest and in transit.	Database encryption, HTTPS/TLS

7.4 Audit and Compliance

Audit and compliance mechanisms ensure that user actions and data changes within a Pega application are tracked, monitored, and logged. These mechanisms are critical for maintaining accountability, transparency, and security while adhering to regulatory requirements.

Key Components of Audit and Compliance

1. Audit Trails
2. Logging

7.4.1 Audit Trails

What is an Audit Trail?

An Audit Trail records and displays a history of user actions, data changes, and case updates. It provides a detailed log of who performed an action, what the action was, and when it occurred.

Types of Audit Trail Information

1. Case-Level Audit Trail: Tracks actions and changes made within a case.
2. Field-Level Audit Trail: Tracks changes to specific fields within a case.

How Audit Trails Work

1. Pega automatically tracks case updates, such as:
   • Creating or updating a case.
   • Changing the value of fields.
   • Changing the case status.
2. Audit trails are stored and displayed in the History Tab of a case.

Example: Tracking Case Updates

Scenario: A loan application case is updated multiple times.

Audit Trail Details:

Date/Time	User	Action	Details
2024-06-10 10:00 AM	JohnDoe	Created Case	Loan ID: 001, Status: Pending
2024-06-10 11:00 AM	MarySmith	Updated Loan Amount	Changed LoanAmount: $50K → $75K
2024-06-10 12:00 PM	JohnDoe	Changed Case Status	Status: Pending → Approved

Steps to Enable and Configure Audit Trails

1. Enable History for Case Types:

   • In App Studio, open the Case Type.
   • Navigate to Settings → History.
   • Enable history tracking for case actions.

2. Field-Level Audit:

   • Go to the Property rule for the field you want to track.
   • Select the option Track Changes.

3. Customize the Audit Trail (Optional):

   • Use a History-Add method in an activity to log custom actions or events.

Benefits of Audit Trails

1. Provides transparency by tracking user actions.
2. Ensures accountability and data integrity.
3. Supports compliance with regulations (e.g., GDPR, HIPAA, SOX).
4. Helps troubleshoot and analyze system behavior.

7.4.2 Logging

What is Logging?

Logging records detailed information about system events, errors, and security-related activities. Logs help administrators monitor application health, identify security breaches, and troubleshoot issues.

Types of Logs in Pega

1. System Logs: Record system events, errors, and warnings.
2. Security Logs: Track authentication failures, access violations, and other security events.
3. Audit Logs: Record user activities and changes.

Key System Log Files

Log File	Purpose
PegaRULES.log	General log for system errors and exceptions.
PegaSecurity.log	Logs security-related events.
PegaAlert.log	Captures performance and alert information.
PegaStackTrace.log	Provides detailed stack traces for errors.

How to Monitor Logs in Pega

1. Access Logs in Admin Studio:

   • Open Admin Studio → Resources → Log Files.
   • View live log details or download log files.

2. Configure Logging Levels:

   • Use the Logging Level Settings tool to adjust logging levels for specific classes (e.g., DEBUG, ERROR, WARN).
   • Steps:
     • Navigate to Dev Studio → Configure → System → Operations → Logging Level Settings.
     • Set appropriate levels for troubleshooting.

3. Security Event Monitoring:

   • Monitor failed login attempts, unauthorized rule access, and other security breaches in the PegaSecurity.log.

4. Add Custom Log Messages:

   • Use the Log-Message method in an activity to write custom log entries:

     Log-Message "Loan application status updated to Approved by user: " + .OperatorID
     

Example: Logging Failed Login Attempts

Scenario: Track failed login attempts for a user.

• Log Entry in PegaSecurity.log:

  2024-06-10 12:05:00 [SECURITY] Login failed for user: JohnDoe.  
  IP Address: 192.168.1.10.  
  Reason: Invalid password.  
  

Benefits of Logging

1. Detects and alerts administrators about potential security breaches.
2. Helps troubleshoot errors and performance issues.
3. Provides a detailed audit trail of system events.
4. Ensures compliance by logging access and authentication activities.

Best Practices for Audit and Logging

1. Enable Audit Trails: Track user actions and field-level changes to ensure accountability.
2. Monitor Security Logs: Regularly review PegaSecurity.log for suspicious activities.
3. Set Appropriate Logging Levels:
   • Use ERROR for production environments to reduce log noise.
   • Use DEBUG temporarily for troubleshooting.
4. Secure Log Files: Protect log files with access controls to prevent tampering.
5. Archive Logs: Set up log rotation and archiving to manage disk space.
6. Alert on Security Events: Integrate logs with tools like SIEM (Security Information and Event Management) for proactive security monitoring.

Summary of Audit and Compliance

Feature	Purpose	Implementation
Audit Trails	Track user actions, case changes, and field edits.	Enable case history, use field-level tracking.
Logging	Record system events, errors, and security breaches.	Use system logs (PegaRULES.log, PegaSecurity.log).

Conclusion of Security Design

We have now covered all topics in Security Design:

1. Authentication: Secure user login with LDAP, SAML SSO, OAuth 2.0, and MFA.
2. Authorization: Control access using Access Groups, Roles, and Privileges.
3. Data Security: Implement Row-Level Security, Field-Level Security, and Encryption.
4. Audit and Compliance: Track actions with Audit Trails and monitor events with Logging.

These security measures ensure that Pega applications are protected against unauthorized access, data breaches, and misuse.

Security Design (Additional Content)

1. Authentication – Real-World Use Cases and Platform Capabilities

SAML vs OAuth: B2B vs B2C Contextual Usage

While both SAML and OAuth 2.0 are supported in Pega, they are generally suited for different use cases:

Protocol	Best Fit	Use Case Example
SAML SSO	B2B (Enterprise-level)	Employees accessing Pega via Okta or Azure AD
OAuth 2.0	B2C / API Integration	Mobile apps or 3rd-party systems consuming Pega APIs

Explanation:

• SAML is commonly used in enterprise (B2B) environments where centralized Identity Providers (IdPs) manage internal users.

• OAuth 2.0 is more flexible and lighter for consumer-grade or system-to-system (B2C/API) authentication, where token-based access is required.

MFA Support in Pega: Native vs External

Pega does not natively implement a full-featured MFA experience. Instead, it relies on external Identity Providers (IdPs) such as Okta, Azure AD, or Ping Identity, which enforce MFA as part of their login workflows.

Key Notes:

• MFA can be enforced before the user reaches the Pega application.

• Pega acts as the Service Provider (SP) in a federated authentication model.

• All verification (OTP, biometric) is handled by the IdP.

2. Authorization – Technical Details for ACL and Privilege Management

ACL Numeric Access Levels (0–5)

Pega uses numeric access levels (0 to 5) to define what a role can do within a class. Here's how they work:

Level	Permission Description
0	No access
1	View
2	Modify (limited)
3	Create
4	Modify (full)
5	Delete / Full Control

Best Practice:

• Only grant level 5 (delete access) when absolutely necessary.

• This numeric system is applied in Access of Role to Object (ARO) rules under each Access Role.

Privilege Combination Example (Multi-Factor Rule Gating)

In complex enterprise use cases, multiple privileges may be required simultaneously to access sensitive actions or rules.

Example Scenario: To approve a high-value loan over $250,000, a user must:

1. Have ApproveLoanPrivilege

2. AND possess FinanceManagerPrivilege

This is configured in the Flow Action or Activity using a condition such as:

@HasPrivilege("ApproveLoanPrivilege") && @HasPrivilege("FinanceManagerPrivilege")

This ensures fine-grained, layered authorization, often required in regulated industries like banking or insurance.

3. Data Security – Field Encryption, REST Transport, and Risk Considerations

Encrypting Sensitive Fields – Technical Constraints

When using the Encrypt checkbox on properties (e.g., SSN, credit card numbers), it’s critical to understand limitations:

• Encrypted fields cannot be used in indexes or referenced in report filters, as their stored values are unreadable to SQL.

• Encrypted properties should not be exposed in Search or Reporting unless decrypted at runtime in a secure UI layer.

Best Practice:

• Use encryption only for PII (Personally Identifiable Information) such as:

  • CustomerSSN

  • BankAccountNumber

  • NationalID

• Avoid encrypting high-usage keys like CaseID, Status, or LoanType.

REST API Transport Security – Enforcing HTTPS

For secure system-to-system integration:

• All external systems consuming Pega REST APIs should access endpoints via HTTPS only.

• Pega allows enforcement via:

  • Reverse proxy (e.g., Apache, NGINX)

  • API Gateway (e.g., Apigee, AWS API Gateway)

  • Direct server configuration (tomcat.xml or load balancer rules)

Why It Matters:

• Unencrypted API access (HTTP) exposes token and data payloads, violating compliance standards (e.g., PCI-DSS, HIPAA).

4. Audit and Compliance – Best Practices for Fine-Grained Logging and Performance

Field-Level Audit Trail – When NOT to Enable

While Field-Level Tracking provides visibility into specific data changes, it can degrade performance if applied to:

Field Type	Reason to Avoid Audit Trail
Large Text Areas	High storage & query load
Frequently Updated Fields	Excessive log volume
System-generated fields	No meaningful user activity

Best Practice:

• Limit field-level auditing to key business fields like ApprovalStatus, LoanAmount, or CustomerType.

Log Integration with SIEM Tools

To meet enterprise security and observability standards:

• Pega logs (PegaSecurity.log, PegaRULES.log) can be piped into SIEM tools such as:

  • Splunk

  • QRadar

  • Elastic Stack (ELK)

• This allows centralized monitoring, anomaly detection, and audit compliance.

Example Use Case: Detect repeated login failures across nodes and raise alerts via SIEM dashboard.

LSA Relevance:

• In large implementations, you may be asked to design a logging and monitoring architecture — knowing how Pega integrates with existing security infrastructure is crucial.