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, refer to 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, refer to POST data preservation.

Use secure passwords for server administration. For information about how to create the agent profile password, refer to 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:

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 you can expedite resolution of security issues.

To resolve security issues quickly, make sure 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 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, refer to 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, refer to 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 only authorized people can access your servers and applications through the appropriate network, using the appropriate ports, and presenting strong-enough credentials.

Make sure 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.

On startup, Web Agent uses the following properties to obtain a session from AM:

The session lifetime is defined by the AM version and configuration, and is essentially indefinite. Consider the following points when you configure the agent session lifetime in AM:

To set the agent session lifetime in AM, add the property com.iplanet.am.session.agentSessionIdleTime to the JVM properties in the AM container, and restart the container. The following example sets the agent session lifetime to 1440 minutes (24 hours):

To minimize the time an attacker can attack an active session, set expiration timeouts for every Advanced Identity Cloud and AM session. Set timeouts according to the context of the deployment, balancing security and usability, so that the user can complete operations without the session frequently expiring.

Learn more from OWASP’s Session Management Cheat Sheet.

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, refer to the documentation for the web server where the agent runs. For NGINX, for example, refer to Security controls.

Rotate keys regularly to:

Learn more in Rotate keys.

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 Ping Identity Platform. Learn more in Audit the deployment.

Web Agent supports propagation of the transaction ID across the Ping 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. Learn more in Trust transaction headers 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 Agent Debug Level is set to the lowest level of logging necessary. For example, consider logging at the ERROR or WARNING level, instead of TRACE or MESSAGE. Learn more in logging configuration properties.

The SSL key log file contains potentially sensitive TLS transaction data. Protect this file from unauthorized access.

Only enable TLS logging when troubleshooting TLS issues between the agent and AM, and remove the SSL key log file after you have completed troubleshooting. Learn more in TLS key logging.