Prevent the exploitation of security vulnerabilities by using up-to-date versions of the agent and third-party software.

Review and follow the Ping Identity security advisories. Follow similar lists from all of your vendors.

When browsers and web proxies cache pages that are accessed by a user, the cache can include sensitive information. Caching pages in browsers and web proxies increases risk of unwanted disclosure, especially in shared browsing environments.

Similarly, when web server responses are cached, sensitive information can be accessed by attackers. Caching web server responses is a common method to improve loading times and reduce server load.

To manage caching, set Add Cache-Control Headers so that HTTP responses generated by the agent include the Cache-Control HTTP header.

When the Cache-Control HTTP header is present, the response cannot be cached. The header uses the following values: max-age=0, no-cache, no-store, must-revalidate.

If you need the Cache-Control header for each page, set it in the application or in the web server.

In your decision to set this property, consider the impact on the performance of customer applications. Setting this property can reduce performance because browser pages are not cached.

For more information about caching, see HTTP caching.

The initial phase of an attack sequence is often reconnaissance. Limit the amount of information available to attackers during reconnaissance, as follows:

For more protection against cross-site scripting attacks, configure Composite Advice Encode.

POST data is stored temporarily in the agent file system before a user is authenticated. Therefore, any unauthenticated user can POST a file that is then stored by the agent. Consider the following points when you configure POST data preservation:

For information about configuration properties, see POST data preservation.

Use secure passwords for server administration. For information about how to create the agent profile password, see Preinstallation tasks.

Misconfiguration can arise from bad or mistaken configuration decisions, and from poor change management. Depending on the configuration error, features can stop working in obvious or subtle ways, and potentially introduce security vulnerabilities.

For example, if a configuration change prevents the server from making HTTPS connections, many applications can no longer connect, and the problem is detected immediately. However, if a configuration change allows insecure TLS protocol versions or cipher suites for HTTPS connections, some applications negotiate insecure TLS, but appear to continue to work properly.

To guard against bad configuration decisions, implement good change management:

Some Java servers, such as those based on J2EE and Spring, use path parameters (also known as matrix parameters) in URL paths. These servers can process requests in a non-standard way that is unsafe for the agent forwarding the request. As a result, bad actors can make use of these parameters for path traversal attempts to access protected resources.

The agent requires the URL path to be normalized consistently to be able to effectively enforce rules.

Web Agent rejects unsafe uses of path parameters with an HTTP 400 in the following scenarios:

Data theft can occur when access policies are too permissive, and when the credentials to gain access are too easily cracked. It can also occur when the data is not protected, when administrative roles are too permissive, and when administrative credentials are poorly managed.

Threats can arise when plans fail to account for outside risks. To mitigate risk, develop appropriate answers to at least the following questions:

For critical services, test expected operation and disaster recovery operation.

Over the lifetime of a deployment, the operating system might be subject to vulnerabilities. Some vulnerabilities require system upgrades, whereas others require only configuration changes. All updates require proactive planning and careful testing.

For the operating systems used in production, put a plan in place for avoiding and resolving security issues. The plan should answer the following questions:

Software providers often do not communicate what they know about a vulnerability until they have a way to mitigate or fix the problem. Once they do communicate about security issues, the information is likely to become public knowledge quickly. Make sure that you can expedite resolution of security issues.

To resolve security issues quickly, make sure that you are ready to validate any changes that must be made. When you validate a change, check that the fix resolves the security issue. Validate that the system and Web Agent software continue to function as expected in all the ways they are used.

System audit logs make it possible to uncover system-level security policy violations that are not recorded in Web Agent, such as unauthorized access to Web Agent files. Such violations are not recorded in Web Agent logs or monitoring information.

Also consider how to prevent or at least detect tampering. A malicious user violating security policy is likely to try to remove evidence of how security was compromised.

By default, operating systems include many features, accounts, and services that Web Agent software does not require. Each optional feature, account, and service on the system brings a risk of additional vulnerabilities. To reduce the surface of attack, enable only required features, system accounts, and services. Disable or remove those that are not needed for the deployment.

The features needed to run and manage Web Agent software securely include the following:

Consider the minimal installation options for your operating system, and the options to turn off features.

Consider configuration options for system hardening to further limit access even to required services.

For each account used to run a necessary service, limit the access granted to the account to what is required. This reduces the risk that a vulnerability in access to one account affects multiple services across the system.

Make sure that you validate the operating system behavior every time you deploy new or changed software. When preparing the deployment and when testing changes, maintain a full operating system with Web Agent software that is not used for any publicly available services, but only for troubleshooting problems that might stem from the system being too minimally configured.

Server protocols such as HTTP, LDAP, and JMX rely on TLS to protect connections. To enforce secure communication, see Configure SSL communication between the agent and AM.

Communication between the agent and clients is managed by the web server in which the agent runs. For information about how to secure connections, see the web server documentation.

The more features you have turned on, the more features you need to secure, patch, and audit. If something is not being used, uninstall it, disable it, or protect access to it.

Make sure that only authorized people can access your servers and applications through the appropriate network, using the appropriate ports, and presenting strong-enough credentials.

Make sure that users connect to systems through the latest versions of TLS, and audit system access periodically.

Provide access only as necessary; restrict to required users, and limit their access to the information they need.

Prevent the exploitation of security vulnerabilities by using up-to-date versions of the agent and third-party software.

Review and follow the Ping Identity security advisories. Follow similar lists from all of your vendors.

Increase the security of cookies generated by Web Agent or the protected application in the following ways:

Small keys are easily compromised. Use at least the recommended key size.

For more information about strong encryption, see the documentation for the web server where the agent runs. For NGINX, for example, see Security controls.

Rotate keys regularly to:

For security, troubleshooting, and regulatory compliance, agents are able to audit information for allowed and/or denied requests.

The agent audit logging service adheres to the log structure common across the ForgeRock Identity Platform. For information, see Auditing.

Web Agent supports propagation of the transaction ID across the ForgeRock Identity Platform, using the HTTP header X-ForgeRock-TransactionId. Consider configuring this header to prevent malicious actors from flooding the system with requests using the same transaction ID header to hide their tracks. For information, see Configuring the trust transaction header system property in AM’s Security guide.

Agent logs contain informational, error, and warning events, to troubleshoot and debug transactions and events that take place within the agent instance.

Protect logs from unauthorized access, and make sure they contain a minimum of sensitive or personally identifiable information that could be used in attacks.

Make sure that Agent Debug Level is the lowest level of logging necessary. For example, consider logging at the ERROR or WARNING level, instead of TRACE or MESSAGE. For more information, see logging configuration properties.