Security and compliance whitepaper

If you need a hard-copy, please print/save to PDF/HTML.

Understanding privacy regulation

Application Performance Management (APM) solutions are designed to capture and retain transaction data that typically contains personal information, such as Social Security numbers and credit card information. APM solutions handles this data carefully and does not inhibit your company’s compliance with industry regulations. For this reason, you should consider APM products and practices within the context of your organization’s security and risk management practices. 

The table below provides brief summaries of key data-protection laws and how they influence APM processes.

Table 1. Important Privacy Regulations

Regulation Description Impact on APM
PCI DSS The Payment Card Industry Data Security Standard is a proprietary information security standard for organizations that handle cardholder information (for example, credit card numbers). The standard was created to reduce credit card fraud. All vendors that conduct financial transactions over the internet must comply with PCI standards. APM solutions must not leak credit card information.
SOX The Sarbanes-Oxley Act of 2002 is a United States federal law that sets standards for the accuracy of financial information for all U.S. public company boards, management, and public accounting firms. SOX is focused on the prevention of financial data manipulation. Leaking of financial records through APM can lead to insider stock manipulation and other SOX violations. Therefore access to APM information must be controlled and all APM data must be encrypted.
HIPAA The Health Insurance Portability and Accountability Act of 1996 is a United States federal law that defines standards for electronic health care transactions. HIPAA addresses the security and privacy of patient data and social security numbers. Data transmission must be encrypted and access to health data must be protected.
CSB 1386 Introduced in 2003, California Senate Bill 1386 is a California law that regulates the privacy of personal information. It requires anyone working with computerized personal information to disclose any security breaches related to the release of unencrypted personal data. In most cases, “losing” personal data means a laptop was stolen or lost with personal data on its hard drive. If the disk is not encrypted, organizations must inform agencies and all affected Californian customers about the loss. Affected customers must also be notified if their personal data is published to an insecure location. Hard disk encryption should be considered in regulated industries. The relevance of this law to APM is low, because the risk of losing a server hard disk is low.
201 CMR 17.00 Concerned about identity theft, Massachusetts introduced the 201 CMR 17.00 law in 2010. It requires anyone who stores or uses personal information about a Massachusetts resident to plan and demonstrate technical, physical, and administrative protection of the information. An APM solution needs to be considered in the context of overall personal information protection. All data transmission must be encrypted, and access to personal data must be restricted.
EU Directive 2002-58 and 95/46/EC EU Directive 2002-58 and 95/46/EC are European Union directives that regulate the processing of personal data within the EU. These EU directives go beyond the protection of personal data (which requires encrypted transmission and access restrictions). They also require privacy considerations for user tracking (for example, cookies).
PIPEDA The Personal Information Protection and Electronic Documents Act of 2000 is a Canadian law that promotes data privacy in electronic commerce. The act is intended to reassure the European Union that Canadian privacy laws adequately protect the personal information of European citizens. PIPEDA requires that APM solutions carefully manage personal data, including credit card data.

Payment card industry data security standard

A good starting point for a security discussion is the Payment Card Industry Data Security Standard. Its principles can easily be applied to other security regulations. PCI DSS is an information security standard for organizations that handle cardholder information for major debit, credit, prepaid, e-purse, ATM, and POS cards. Defined by the Payment Card Industry Security Standards Council, the standard increases controls around cardholder data.

Requirements overview and applicability to APM

The following table provides a high-level overview of PCI DSS requirements:

Table 2. PCI DSS Requirements

Requirement Details Applicability to APM
Build and maintain a secure network. Install and maintain a firewall to protect cardholder data. n/a1 
Do not use vendor-supplied defaults for system passwords and other security parameters. applicable 
Protect cardholder data Protect stored cardholder data. applicable
  Encrypt transmission of cardholder data across open, public networks. applicable
Maintain a Vulnerability Management Program Use and regularly update anti-virus software or programs, n/a1
Develop and maintain secure systems and applications. n/a1
Implement Strong Access Control Measures Restrict access to cardholder data by business need to know. applicable
Assign a unique ID to each person with computer access. applicable
Restrict physical access to cardholder data. applicable
Regularly Monitor and Test Networks Track and monitor all access to network resources and cardholder data. applicable
Regularly test security systems and processes. Include APM systems and processes in the tests.
Maintain an Information Security Policy Maintain a policy that addresses information security for all personnel. Include APM standards in the policy.

1 While these requirements are not directly applicable to APM, any APM solution must operate using PCI DSS compliant infrastructure, firewalls, and anti-virus solutions.

PCI compliance relates to business management processes and environments, not to individual products and tools used in these environments. In this way, PCI is like CMM or ISO — these are process certifications, not product certifications.

Some PCI DSS requirements are not applicable to APM; for example, operating a virus scanner, maintaining a firewall, and managing usage and access control for IT systems. While APM vendors have no influence over these processes, they should provide tools and means that allow for proper implementation of these processes where applicable.

Other PCI DSS requirements, including those listed below, are directly relevant to core APM practices. For these requirements, it’s important for organizations to verify that the products they rely on to improve and monitor application performance are not unwittingly compromising data privacy or PCI DSS compliance.

Organizations should ask the following five questions of any APM vendor. Each question is followed by a response that is specific to AppMon Application Monitoring:

  • Can the solution operate efficiently within network firewalls? AppMon software is designed to operate within secure firewalled networks in all security zones. By bundling the Agent traffic, AppMon Collectors simplify configuration. You only need to configure the firewalls for the Collectors and not for the individual Agents.
  • Does the solution allow for customization of vendor-supplied system passwords and parameters? AppMon tools allow for customization of system accounts, passwords, and other security related parameters.
  • Will the solution work with anti-virus software, file integrity checking software, and similar utilities? You are encouraged to install any software required to achieve compliance with your organization’s security regulations. Note that when you contact Customer Support, it may be necessary to temporarily disable such third-party software if it interferes with AppMon operations.
  • Is a mechanism available for maintaining applications and applying patches to keep systems secure? When software’s complexity increases, the chance of bugs quickly increases and some bugs may be exploited. Therefore, it is important that security patches be applied to applications in a timely manner. AppMon Application Monitoring provides fixes, especially security patches, as quickly as possible to its customers with active maintenance contracts.
  • Does the product support audit best practices through console access and a record of configuration changes?
    AppMon Application Monitoring products record configuration changes to an audit log. However, auditing is a process that needs to be performed by the customer.

Security scanning as part of product development and quality assurance

Automated and manual security scans are part of the AppMon release cycle. AppMon Application Monitoring software is also checked for PCI readiness. As part of the system development life cycle (SDLC), Nessus and Qualys are used to conduct security scans on infrastructure and web application basis. Many corporations use these tools as part of their PCI DSS compliance-testing process. Additionally, an in house security team is responsible for performing penetration tests and coordinate the remediation of identified vulnerabilities.

In the event of an audit request or if you need more information, contact your AppMon Account Manager or Customer Support.

AppMon Application Monitoring implementation best practices

AppMon Application Monitoring is part of a new generation of lightweight, always-on application monitoring tools that allow organizations to move from reactive crisis mode to proactive management. AppMon Application Monitoring delivers 24/7 visibility into transactions and infrastructure with zero sampling, zero configuration, and less than 2% overhead.

AppMon, with its patented PurePath and PureStack technologies, is a key capability that powers the AppMon product family. To capture performance information, AppMon injects Agents into system components. This functionality includes the ability to record confidential information and other security-relevant data.

It is important that you understand the security concepts integrated into AppMon so that your organization can set up AppMon securely and adhere to regulatory compliance standards.

Before delving further into security details, take a look at a typical web shop implementation of AppMon Application Monitoring, along with its security features and options.

Figure 1. System Overview of Web Application with AppMon

Figure 1. System Overview of Web Application with AppMon

(1)–(3): In a typical distributed environment, user transactions — for example, a purchase in a web shop or an e-banking transaction with a mobile app — are triggered on the client side (in the browser or in the app) and are processed by a number of servers, from front-end through back-end to databases. Most AppMon agents (2) are deployed within the application and its servers, and typically behind a firewall. Only a few (JavaScript and Browser Agents, and Mobile App Agents (1)) run on the client side. All those Agents capture performance metrics; they hook into processes and virtual machines for this purpose. The metrics, which include method arguments, are usually sent to the Collector (5), a server in the data center. The communication between Agents and Collector can be encrypted by using SSL. By default it is not encrypted for performance reasons: it is traffic inside the data center, and behind a firewall. The only exception is the Client Agent (1), which does not run inside the data center, but runs on client computers or mobile devices. Client Agents always use encryption to transmit their data securely to their recipients in the data center.

(4)–(7): A Collector (5) encrypts all received information and sends it to the AppMon Server (6), using SSL. The cipher selection during the SSL handshake is dependent on the Java virtual machines on both ends; Oracle and IBM Java implementations are slightly different in their SSL implementations. However, the AppMon Server discards unsecure or broken ciphers; the server’s cipher blacklist can be extended by configuration. The AppMon Server stores all transactional data first in the Session Store (7). This Session Store is used for tracking detailed information, including cardholder information, for example for customer complaint resolution or for problem tracking. Typically, the Session Store has a low retention time: its size is configurable and can be adapted to your needs. Performance metrics are displayed to the user by the AppMon Client (4). The communication between Server and Client can be encrypted via SSL.

Measures are recorded in the Performance Warehouse for a long period of time, allowing comparison of current performance with the years before. However, neither cardholder information nor any personally identifiable information is stored in the Performance Warehouse. The only exception to this is if a credit card number is used as a measure splitting ID; this practice needs to be avoided except for diagnosis in extreme cases. This unusual and rare usage scenario requires manual configuration, and by default does not occur.

Access to the AppMon Server is restricted to defined user accounts. Typically a corporate LDAP or Active Directory is used to perform user authentication and to provide access control rights.

How AppMon meets PCI DSS requirements

You can configure AppMon to capture cardholder data to provide richer performance insights (for example, with method arguments, SQL statements, bind values, exception arguments, etc.). When required, you can configure AppMon to prevent the capture of personally identifiable information, such as cardholder information.

AppMon implements strong security controls to meet the following PCI requirements:

  • Control of the capture and protection of confidential data.
  • Assurance that security measures are in place.

Best practices for governing confidential data

PCI DSS requires strong protection of credit card data. As soon as a credit card number (Primary Account Number, or PAN) is stored, processed, or transmitted, PCI DSS requirements must be fulfilled. Other credit card data such as cardholder name, expiration date, and service code must also be protected. PCI DSS also demands protection of sensitive authentication data. This includes magnetic strip data (which is not applicable for AppMon), card verification codes and values, passwords, and PINs. Sensitive authentication data must not be stored, except for support issues where there is a strong business justification for it.

Prevent the capture of confidential data (PCI DSS Requirement #3)

The easiest way to comply with the PCI DSS requirements for protecting cardholder data is to prevent its capture in the first place. Authentication information should not be recorded at all.

Use the sensor configuration capabilities of AppMon to prevent the capture of cardholder data. Specifically, prepare the checkout process and instrument-critical methods that contain cardholder information. For example, don’t capture method parameters.

Data can also be collected via memory dumps. AppMon collects memory dumps for diagnostic purposes when a Java virtual machine or .NET instance runs out of memory. Such memory dumps can contain confidential strings.

You can turn off the automatic generation of memory dumps. Additionally, you can use permissions to restrict the manual generation of memory dumps. Permissions for analyzing memory dumps can also be restricted.

Note that it is not always possible to prevent the capture of cardholder data. Issue tracking is one exception, for example. Cardholder data must be protected in such cases, as discussed in the following sections.

Secure data storage (PCI DSS Requirement #3)

The AppMon Server, which in production environments is always located behind a firewall, stores and processes cyclic measures and PurePath metrics data in a Session Store. Session Stores contain a number of bulk files that are kept in plain format for performance reasons. Plain means that AppMon does not encrypt the data. However, Session Store information has a short retention time based on the available storage and configuration.

Operating system permissions deployed on the Session Store, combined with physical access controls, are the minimum requirements for protecting cardholder information from direct access. Additionally, you can use external tools to encrypt the Session Store. Full disk encryption is recommended because it normally does not interfere with performance. You can use dm-crypt on Linux servers or BitLocker on Windows servers for the encryption of data partitions. Self-encrypting hard drives are also an option. You should configure the size of your Session Store reasonably so that it does not keep data longer than is necessary.

It is not easy to retrieve cardholder information directly from a Session Store. Session Store files are highly compressed and the various fields for cardholder information cannot be easily linked together by an attacker because they are strewn amidst millions of data points. The risk that an attacker will be able to retrieve complete credit card data is fairly low. An attacker would need to either copy huge data files or use an analysis tool (for example, the AppMon Viewer) to distill credit card data from the large amount of metrics data. Both cases normally can be prevented, or at least detected, with secure system design.

The Performance Warehouse, which stores performance metrics over a longer period of time in a relational database, is less likely to hold confidential data. PurePath information that contains confidential strings is usually stripped out. Access controls and encryption may also be applied to the Performance Warehouse database system.

Business transactions can be defined in AppMon to capture a variety of data and parameters, including parameters that hold confidential values. For example, you can intentionally generate a business transaction that stores cardholder data. Measures to avoid such situations include:

  • Implementing permissions that restrict the rights for creation of business transactions.
  • Regular monitoring of all business transactions and deletion of business transactions that can contain cardholder information.
  • Hiding confidential strings.
Secure data transmission (PCI DSS Requirement #4)

Most AppMon Agents are located inside the application infrastructure, either on the web or on application servers. For performance reasons, the communication between the Agent and the Collector is in plain format. For the same performance reasons, the Collector should be located in the same network and behind a firewall.

Because data transmission between Agents and Collectors is not encrypted by default, you must either restrict physical access on the network or put a Collector on the same machine as the Agent. If the AppMon Server is located outside the application infrastructure, place Collectors in the local network and enforce SSL encryption between Collectors and the AppMon Server. You can also use encrypted SSL connection between Agents and Collectors. When using the OneAgent for AppMon, traffic is encrypted end-to-end via https.

AppMon Agents that are located on the client side always encrypt their communication to either their Web Server Agent counterpart or to the next Collector.

Best practices for ensuring security measures are in place

PCI DSS requires reliable identification of users, working with permissions and access controls to authorize users and track their activities. This is necessary to implement the policies that restrict access to cardholder data.

Restrict access on a “need-to-know” basis (PCI DSS Requirement #7)

Operators can use the AppMon Client to inspect recorded metrics and thus, potentially access confidential information such as cardholder data.

Best practice is to restrict the access to confidential information. Configure AppMon with access permissions, so only people who need to know are able to inspect confidential strings (method arguments, SQL statements). All other users see this information blanked out.

Figure 2. AppMon Server Settings -Permission to Read Confidential Strings

Figure 2. AppMon Server Settings -Permission to Read Confidential Strings

Figure 3. AppMon Server Settings - Confidential Strings: Selecting What Gets Hidden

Figure 3. AppMon Server Settings - Confidential Strings: Selecting What Gets Hidden

Figure 4. System Profile Preferences - Data Privacy Settings

Figure 4. System Profile Preferences - Data Privacy Settings

Figure 5. Confidential Strings in SQL Statements

Figure 5. Confidential Strings in SQL Statements

Figure 6. Confidential Strings in a PurePath

Figure 6. Confidential Strings in a PurePath

Restrict export control. When you export a session (for example, to allow a developer to review an erroneous session), blank out all parameters. If it is necessary to see the method arguments, you can use a screen sharing or web conference tool to give screen access and record the session for auditing purposes. This recommendation meets PCI DSS requirement #10: track and monitor all access to network resources and cardholder data.

Restrict permissions (PCI DSS Requirement #7)

In addition to access controls, constitutes PCI DSS requirement #7 concerns permissions that control who is authorized to define which users are able to access cardholder data and also who can change configuration settings. Remember that the most effective way to restrict access to credit card data is not to capture it at all. If you don’t capture sensitive data, then the combination of access controls and permissions can prevent ad-hoc changes to data capture policy.

Enforce User identification (PCI DSS Requirement #8).

To comply with PCI DSS requirements for reliable user identification, a best practice is to reuse an existing LDAP or Active Directory for AppMon user identification.

Integrate AppMon with an LDAP or Active Directory. Specify an LDAP group to which AppMon users must belong. Activate SSL encryption for LDAP authentication.

Enable Log Audits (PCI DSS Requirement #10)

You can log changes to AppMon System Profiles for auditing. Therefore it is impossible for users to change configuration or permission settings without leaving traces of the changes.

Figure 7. Auditing Logs

Figure 7. Auditing Logs

Note that it is not possible to log which users had access to sensitive cardholder data.

If cardholder data capturing is required, we recommend that you use permissions to strictly limit access to method parameters and SQL statements.

PCI DSS conclusion

When you use proper configuration and follow all these recommendations carefully, AppMon Application Monitoring and User Experience complies with the PCI DSS requirements and you can still manage the performance of your business-critical applications.

User experience monitoring (UEM) security and privacy

Real User Monitoring (RUM), also known as User Experience Management (UEM), measures how fast an application performs from the perspective of the end user. The metrics for these measurements must be taken on the user’s side in the browser or in the app, because the user experience data must include the browser’s rendering time, the time it takes to load objects from Content Delivery Networks (CDN), and other variables outside of direct application control.

Page actions are client-side actions performed by the user that trigger one or more web requests, such as AJAX requests. A page action starts with a user interaction such as clicking a link or entering a URL into the browser’s address bar, and ends when all the web requests and render operations caused by the interaction are complete. To measure page actions, AppMon injects a JavaScript Agent into the HTML code using a simple script tag that is no longer than a single line of code. The purpose of this small JavaScript is to collect information about the application and actions within the user’s browser, and then to report the information. By using the XML HTTP request XHR, AppMon is the only solution in the APM market that returns metrics securely to its originating server, not to a third-party server in the Cloud (for example, Google). Gathered metrics are used by the UEM correlation engine to identify page actions.

When AppMon measures performance for the end user, it needs to collect data on the client side and report it back to the server side. This means that some of the PurePath metrics are captured outside the server infrastructure, outside the data center. Is this approach secure? Can this approach be used to inject something fraudulent into the server? What about cookies and privacy? Answers to these questions are discussed below.

Cross-site scripting

One possible attack scenario is to send fake information to Web Server Agents in the hope that the information triggers a failure and thereby allows for unauthorized code injection.

The chance that such an attack could be successful is low, because a Web Server Agent checks and validates all incoming data. If incoming data does not match reference data (for example, time stamps, request IDs, and cookie information), the data is immediately discarded.

Even if an attacker overcomes this obstacle, the risk of unauthorized code injection still remains extremely low:

  • An attacker probably would be able to manipulate the APM data. This could result in a smaller or higher load, but the manipulation would likely be detected and would not do any serious harm. Such an attack would seem to offer little benefit.
  • A SQL injection is not possible. The Web Server Agents don’t access databases. Instead, they transmit received data via an AppMon Collector to an AppMon Server instance. The Server itself does not write the received information to a database. It writes the data to the Session Store, into a consecutive file.
  • Code injection is unlikely. The Web Server Agent is designed for performance and security, and therefore it is very lean. It only checks the parameters and then hands them over to the Collector instance. Additionally, AppMon does automatic unit tests to verify that such a situation does not happen.

Another potential attack scenario is through JavaScript. However, although AppMon does inject JavaScript, such an approach cannot be used for a cross-site scripting attack. For instance, an attacker who wanted to replace the JavaScript in the HTML code would need to attack the web server directly: It makes no difference if AppMon is installed.

User experience monitoring (UEM) and security


AppMon UEM requires cookies to identify sessions. Therefore it is a technical necessity that a web server agent set a temporary session cookie; otherwise UEM cannot measure a user’s performance experience. This cookie is sent on the first web request and expires when the browser is closed. It is non-persistent and is not used for ad tracking. AppMon sets these first-party cookies for the sole purpose of application performance management, not for tracking a user’s purchasing bias or click behavior.

Regulations like EU Directive 2002-58, which is about the processing of user data and protection of privacy, allow for first-party cookies. First-party cookies are defined as cookies that are directly used for communication between a website and a user. For example, if you purchase goods in a web shop, the shop uses first-party cookies to identify you and keep track of your shopping cart; you have a direct business relationship with the web shop. The vendor needs to know who you are, otherwise you can’t pay and the vendor can’t deliver your purchase to you.

In contrast, third-party cookies are cookies that communicate with other websites, for example advertising services or analytics engines. If a website asked to share your address data with another company, you might not agree to the transaction. Regulations therefore rely on the opt-in concept, in which a user has to explicitly authorize the sharing of their data with a third-party.

Unlike other APM solutions, AppMon is the only compliant vendor that uses first-party cookies. Real-user metrics are returned securely to their originating URL (the web server behind the URL) and not to a different server in the Cloud that is not under the vendor’s control. The session identification via the first-party cookie is standard technical and business practice. Other APM vendors, which send metrics to a server in the Cloud, create third-party cookies that must require user opt-in to enforce EU directives.

User tracking

Modern browsers support the “do not track” feature, which is a technology that enables end users to opt out of tracking by websites. Although accepting a user’s tracking opt-out setting is not activated by default, you can configure AppMon to accept the opt-out. In such instances, AppMon UEM respects the user’s privacy, does not set a cookie, and does not measure that user’s performance experience.

The “do not track” feature can be activated through System Profile > Data Privacy.

Figure 8. Do Not Track Privacy Setting

Figure 8. Do Not Track Privacy Setting

Identifying users

Although cookies are used to identify all web requests of a user, as required for the UEM correlation engine, the user remains anonymous by default. Out of the box, AppMon captures the user anonymously, based on the user’s IP information and device type.

To capture additional information, you must configure AppMon using the visit tagging features. For example, if a user logs on to your web shop, you can identify the user by account data and then see what the user does on your web page. This function is helpful for user complaint resolution: If the user has a problem and contacts your support desk, Customer Support can identify the user’s session and find out exactly what happened.

You can configure visit tagging through System Profile > User Experience > <application name> > General. In the Tag visits with field, specify the measure that allows the tagging.

Figure 9. Visit Tagging

Figure 9. Visit Tagging

Specify how to identify a user, for example the login method and the parameter that contains the user ID.

To obey privacy requests, do not instrument visit tagging or select a parameter that does not allow direct user identification: for example, the department or location instead of the account ID.

Although this feature offers a powerful means of providing high service levels to external visitors, it violates privacy regulations if you configure it for use on your Intranet applications. In European countries, it is illegal to track employees.

To comply with privacy regulations, do not identify internal users directly. Use aggregation information instead; for example, track the department or site that the user comes from.

Privacy conclusions

AppMon UEM’s high business value is derived from its ability to measure end users’ experience of a website. It provides insight into an individual user’s session to see how quickly the web pages render and measures overall performance on the client side. The built-in features of AppMon allow you to configure and operate APM in accordance with privacy regulations.