Table of Contents

Vulnerability testing policy for applications on Pega Cloud Services

This content applies only to Pega Cloud Services environments.

Overview

Pega Cloud Services (PCS) clients can conduct security assessments for applications on Pega Cloud Services when such assessments are preauthorized and performed within the guidelines described in this article. Application-tier vulnerability scanning is allowed when clients need to assess and report on the security of their cloud-delivered applications, client-directed development, and services for internal audit or compliance programs.

Environments that may be tested

PCS clients are permitted to conduct application vulnerability tests on their Pega Platform applications that are deployed in Preproduction (large sandbox) and Production environments.  PCS clients are not permitted to conduct application vulnerability tests on any trial environments.

PCS clients are also permitted to conduct application vulnerability tests on their Pega applications that are deployed in Development and Test (small sandbox) environments.  However, PCS clients must realize that Development and Test environments, by definition, are more open than Production environments, and may show issues that will not be present in Production environments.

Testing should focus on PCS clients’ applications rather than the Development environment. Testing of the Development environment itself is not recommended for several reasons:

  • The Development environment, by design, allows for software development and modification of the running system.  (For example, RuleSets may be unlocked in a Development and Test environment, as development is still occurring and changes to rules are being made; in a Production environment, all RuleSets should be locked.)  If testing is performed, then vulnerabilities may be found which are inherent to a Development and Test environment - testers and scanners will find issues in the Development environment that would be high risk in a Production environment, but are necessary on a Development system.
  • Penetration testing can damage the system being tested; this can include the application rules themselves.  Be sure to completely back up your applications before doing any testing.
  • The Pega Platform portals (AppStudio, DevStudio, etc.) are much larger in scope than most user-facing applications, and will take more time and expense to test.

Development and Test environments should not be used for production services or for hosting sensitive or production data.

Policy Terms and Conditions

Each requestor must abide by and agree to the following terms outlined by Pegasystems prior to receiving an authorization for conducting any security assessment or penetration testing. All Security Testing must be in line with the Pegasystems Security Testing Term and Conditions.

Security Testing (the "Testing"):

  1. Testing is not authorized until Pega Cloud Security validates the information and returns a fully-executed authorization form with an authorization number to the requesting party.
  1. Testing will be limited to the services, network bandwidth, requests per minute, instance-type, and duration outlined in this agreement, the client's services agreement, and the Pega Cloud Acceptable Use Policy.
  1. The client is only permitted to test their Pega applications.  The client is not permitted to attempt to penetrate beyond their applications, or to attempt to breach the PCS infrastructure or supporting services.
  1. The client is responsible for any damages to Pega Cloud or other PCS clients that are caused by their penetration testing activities.
  1. If the client discovers any vulnerabilities or other security issues which are rated “very high” or “critical” within any Pega Cloud Services in the course of their security assessment, they must cease the vulnerability test and contact  Cloud-Vulnerability-Notifications@pega.com within 24 hours of discovery. The client is not permitted to continue testing or take advantage of any suspected vulnerability.
  1. Upon completion of their testing, the client must submit an executive summary report (at minimum) to Pega GCS via a Service Request through the Support Portal, and request a review of the findings. Sending a full report is recommended. 
  1. Distribution of the report beyond Pegasystems and the client is subject to mutual written agreement.
  1.  To extend or modify the agreed-upon testing period, the client must submit a new request.

Permitted Services:  Using Security Assessment Tools and Services

There are a variety of public, private, commercial, and/or open-source tools and services to choose from for the purposes of performing a security assessment of the client's Pega Cloud Services environments. The term "security assessment" refers to all activity engaged in for the purposes of determining the efficacy or existence of security controls, such as:

  • Port-scanning
  • Vulnerability scanning/checks
  • Penetration testing
  • Exploitation
  • Web application scanning
  • Any injection, forgery, or fuzzing activity, whether performed remotely against the client's PCS environments, amongst/between the client's PCS environments, or locally within the virtualized assets of any of the client's PCS environments

The client is not limited in their selection of tools or services to perform a security assessment of their PCS environments. However, the client is prohibited from utilizing any tools or services in a manner that perform Denial-of-Service (DoS) attacks or simulations of such against any PCS environments, their own or otherwise. For a list of prohibited activities, see the next section.

A security tool that solely performs a remote query of their PCS environments to determine a software name and version, such as "banner grabbing," for the purpose of comparison to a list of versions known to be vulnerable to DoS, is not in violation of this policy.

Additionally, a security tool or service that solely crashes a running process on the client's PCS environment, temporary or otherwise, as necessary for remote or local exploitation as part of the security assessment, is not in violation of this policy. However, this tool may not engage in protocol flooding or resource request flooding, as mentioned in the Prohibited Activities section.

A security tool or service that creates, determines the existence of, or demonstrates a DoS condition in any other manner, actual or simulated, is expressly forbidden.

Some tools or services include actual DoS capabilities as described, either silently/inherently if used inappropriately or as an explicit test/check or feature of the tool or service. Any security tool or service that has such a DoS capability, must have the explicit ability to disable, disarm, or otherwise render harmless, that DoS capability. Otherwise, that tool or service may not be employed for any facet of the security assessment.

It is the sole responsibility of the PCS client to: (1) ensure the tools and services employed for performing a security assessment are properly configured and successfully operate in a manner that does not perform DoS attacks or simulations of such, and (2) independently validate that the tool or service employed does not perform DoS attacks, or simulations of such, prior to security assessment of any PCS environments. This PCS client responsibility includes ensuring that contracted third-parties perform security assessments in a manner that does not violate this policy.

Furthermore, the client is responsible for any damages to PCS environments or other PCS clients that are caused by the client's testing or security assessment activities.

Prohibited Activities

Some penetration-testing activities could trigger a number of security events or affect resources for other clients.  Therefore, activities that can damage resources or cause harm to any clients’ environments are prohibited, including but not limited to the following activities:

  • DNS zone walking
  • Denial of Service (DoS), Distributed Denial of Service (DDoS), Simulated DoS, Simulated DDoS or other activity with the intent to overload, flood, or spam any part of the services
  • Port flooding
  • Protocol flooding (for example, SYN flooding, ICMP flooding, UDP flooding)
  • Request flooding (login request flooding, HTTP request flooding, API request flooding)
  • Testing of environments, domains or URLs not specifically contracted for by the client
  • Excluding the uploading of an EICAR file to test anti-malware or anti-virus effectiveness, intentionally sending, injecting or uploading a virus or a corrupt file, Trojan horse or worm is prohibited

 

Suggest Edit

85% found this useful

Have a question? Get answers now.

Visit the Pega Support Community to ask questions, engage in discussions, and help others.