On January 11 and 12 we hosted the cLSA Security Excellence webinar as part of the CLSA Continuous Excellence Enablement (C2E) program that is focussed on targeted content on platform topics and from a Pega 8 perspective. This webinar was focussed on security and discussed authentication, authorization and security features in Pega. A number of questions was asked during the webinar that couldn't all be answered during the session. This discussion posts the questions with answers about Pega security features. 

The full webinar recording can be found: https://collaborate.pega.com/discussion/clsa-security-excellence-webinar-recording-handout-january-2021

What is the reason why Pega is not shipped secure by default?

This is to allow users to start creating applications directly and allow business users to learn the pega easy way of development. And every application and client need with respect to security is different. There is no one size fits all.

A base Pega installation is intentionally configured with limited security. This is appropriate for experimentation, learning, and application development. Not for production. Every project requires a proper security setup!

Use the security checklist to assure the right actions are being taken to secure the application.

How to manage production access on demand when required?

Unlimited access to a production environment to team members is risk full for multiple reasons; they can potentially influence the outcome of processing, they could (even unintentionally) make changes to the application and they can view actual production data. Most urgent are the legal and privacy concern around customer data. Most countries have strict privacy laws around PII (Personally Identifiable Data) not to be used and viewed outside the contract terms. And there are several laws giving inevitable importance to data security and privacy concerns.

Obviously by automating the delivery lifecycle and using DevOps best practices, you can eliminate the need to do manual deployments and the need to log in. But there can still be situations where temporary access is needed for example for retrieving more information about a defect that cannot be reproduced on other environments or for any environment specific actions.

Especially for organizations that are in a highly regulated industry and for applications that hold crucial personally identifiable data should build in a trackable process for just-in-time access to a production application. There are specialized tools (like CyberArk Priviliged Access Security) that can securely archive, transfer and track the administrative passwords and its use. Where you can get a one-time login and the actual event is trackable. This can be setup based on the needs of the organization.

It is important to leverage the security checklist from day 1 in your project as this contains a concise overview of the tasks necessary to assure a secure setup. This also names some of the obvious actions to take like preventing unauthorized access with default passwords and disable or delete the operator IDs that you do not plan to use.

Do all the checklist items have to be manually assessed or are some of these items automatically checked by Pega platform?

It’s manual for now and the roadmap contains ideas for automating it. However, you do not need to assess each item every time the security checklist gets reset. There is a distinction between the items that need checking every release -or every sprint- and tasks that need to be done only once.

In order to be able to use the checklist effectively it’s important to leverage a consistent application versioning strategy. With a new application version, the checklist gets reset, so you should version the application with every production go-live.

Do I need to harden my environment when I am working on Pega Cloud environment also or is it taken care?

Pegacloud does perform a number of hardening tasks but it remains a shared responsibility. So in pegacloud you still need to work on hardening the environment. Look at this: https://community.pega.com/knowledgebase/articles/pega-cloud-services-subscription-documentation/security-standards-pega-cloud-services

If you follow the security checklist, there are specific sets of tasks for PegaCloud and for on-premise setups.

Like cors, is it possible to restrict the number of service hits from the same domain?

Pega doesn’t support this. An option is to use an API Gateway to achieve this.

Can the enablement of CSRF impact application performance?

No. We have not seen any performance impact related to enabling CSRF. Although when working with LoadRunner in a Load and Performance system, it is best to disable as the scripts will want to replay and get errors with CSRF enabled.

In SAML the cookie could be stolen. What kind of security measures can we apply?

The session length is the most important and therefore you have to make sure your sessions timeout. Additonaly you can set prconfig/Cookie/HTTPOnly/default to limit the usage of the cookie

Is it possible to use 4 different keys for platform encryption, one for each application that all reside on the same environment. Can this be achieved?

If you are talking about the customer key in the context of Platform Encyryption and BYOK (bring your own key) then there can only be ONE active at anyone time for one system. See https://community.pega.com/knowledgebase/articles/security/85/encryption

When you say adding hardening settings to helm charts, does that means to add these settings to the prconfig.xml residing in the k8s configmap?

Yes, they are in the K8 config map. See https://community.pega.com/knowledgebase/articles/client-managed-cloud/85/about-client-managed-cloud