8.4 The Security Checklist & Secure Deployment
Key Takeaways
- The Security Checklist is Pega's built-in set of best practices for deploying an application securely, and completing it is a prerequisite for moving an application to production.
- Checklist tasks are sequenced by phase: some belong at project initiation, some are performed continuously during development, and some are performed immediately before deployment.
- Core checklist tasks include not deploying checked-out rules, removing unnecessary roles and operators from production, securing passwords, and setting production-appropriate application and system settings.
- The checklist also covers web-tier protections: cross-site request forgery settings, Content Security Policies, CORS policies for REST services, and appropriate logging levels.
- Security policies such as password composition, lockout, and session controls are configured at the system level and complement, rather than replace, the per-application checklist.
8.4 The Security Checklist & Secure Deployment
Sections 8.1 through 8.3 covered who can do what — authentication, access groups, roles, access of role to object, privileges, and attribute-based access control. This section covers the complementary discipline the blueprint names separately: the Security Checklist, Pega's structured set of tasks for taking an application to production safely.
1. What the Security Checklist Is
The Security Checklist offers Pega best practices for the secure deployment of applications. It exists to safeguard the confidentiality, integrity, and availability of an application once it is in production.
Two properties make it exam-relevant:
- It is built into the platform, not a document someone writes. The checklist is part of the application record, so progress is tracked per application and is visible during reviews.
- It gates deployment. Failure to complete the application Security Checklist blocks the application's deployment. Security is not a post-launch cleanup task on a Pega program.
The benefit statement the exam wants is straightforward: by following the checklist you address security concerns at the outset, stay vigilant throughout development, and avoid expensive rework late in the project, when insecure defaults are far more costly to unwind.
2. Timing: Three Classes of Task
The checklist tells you when each task should be performed, and that sequencing is itself testable.
| Phase | Nature of the work | Representative tasks |
|---|---|---|
| At or near project initiation | Decisions that are cheap now and expensive later | Define and map authentication services to the application; decide the authorization model; plan audit requirements |
| Ongoing throughout development | Habits that prevent debt from accumulating | Keep rule check-outs disciplined; review access groups and roles as they are added; keep logging levels sane |
| Immediately before deployment | Environment hardening | Remove unnecessary operators and roles from production; secure passwords; configure production application and system settings; verify no checked-out rules ship |
A scenario that says "the team plans to review all security configuration in the week before go-live" is describing an anti-pattern. The checklist is deliberately front-loaded and continuous.
3. Core Checklist Tasks
The checklist spans monitoring, authentication, authorization, auditing, and production testing. The tasks that recur in CSA scenarios are:
- Do not deploy checked-out rules. A checked-out rule in production means the running application may execute a private, unreviewed version of a rule. Rules must be checked in before the product package is built.
- Block unnecessary roles and operators from production. Development-only operators, sample data operators, and broad administrative roles must not survive into production.
- Secure passwords. Replace default credentials, apply password policies, and confirm no passwords are stored in plain text in dynamic system settings or connector configurations.
- Configure application settings and system settings for production. Environment-specific values belong in dynamic system settings and application settings so that the same rules behave correctly in each environment without editing rules.
- Configure cross-site request forgery (CSRF) settings. Prevents an authenticated user's browser from being tricked into submitting unintended requests.
- Define appropriate Content Security Policies. Restricts which script, style, and frame sources the browser will honor for the application.
- Define appropriate Cross-Origin Resource Sharing (CORS) policies for REST services. Controls which external origins may call the application's services — essential when a Constellation front end or a mashup is hosted on a different domain.
- Configure logging levels appropriately. Verbose debug logging in production leaks data and degrades performance.
- Define and map authentication services to the application. Connects the application to the enterprise identity provider rather than leaving it on basic platform authentication.
4. Security Policies vs the Security Checklist
Candidates frequently conflate these. They operate at different levels.
| Security policies | Security Checklist | |
|---|---|---|
| Scope | System-wide authentication behavior | Per-application deployment readiness |
| Examples | Password composition rules, lockout after failed attempts, session timeout, CAPTCHA settings | Remove dev operators, set CSP, verify no checked-out rules |
| Who owns it | System administrator, usually in Dev Studio security landing pages | The application's lead architect, tracked on the application record |
| Relationship | Provides the enforcement mechanisms | Confirms the mechanisms are actually configured for this application before release |
Both are required. Strong password policies on a system that still ships a development operator with broad access has not achieved a secure deployment.
5. Auditing and Tracking Data Changes
Secure deployment is also about knowing what happened after go-live. Pega supports field-level auditing, which records the old value, new value, operator, and timestamp whenever an audited property changes, and a history record for the case itself. The checklist's auditing tasks confirm that the properties the business and its regulators care about — monetary amounts, decisions, status changes, personal data — are actually configured for tracking before the application handles live data.
6. Exam Framing
Questions in this area rarely ask you to recite tasks. They describe a team about to deploy and ask what must happen first, or they describe a symptom — an external domain cannot call a REST service, a browser blocks an embedded script, a user's session never expires — and ask which checklist item addresses it. Map the symptom to the control: cross-origin call blocked → CORS policy; embedded script blocked → Content Security Policy; forged request from another site → CSRF settings; session never expires → security policies.
A team is two days from a production release. The lead architect discovers that three rules are still checked out to a departed developer, two sample data operators created during a demo still exist, and the application has never had its Security Checklist completed. What is the correct characterization of the situation?
A Constellation front end hosted at app.example.com must call REST services exposed by a Pega application at pega.example.net. The browser blocks the calls. Which Security Checklist item addresses this requirement?
How do system-level security policies relate to the per-application Security Checklist?