Security and privacy

AppMon gives you insight into behavior of your application. That includes user experience, allowing you to see how your application performs from the user's point of view. In order to achieve it, you have to capture some information on the user side. The ability to capture data on the user's side means that you are able to capture user's personal information.

Many countries protect personal information by law. You can still capture it under certain conditions. See the Privacy regulation section to learn which data should be considered as private and the User Experience Management section to learn how AppMon captures such data, and how can you fulfill privacy regulations.

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 handle this data carefully and do 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.

Regulation Description Impact on APM
GDPR The General Data Protection Regulation for EU citizens defines EU citizens rights regarding their personal data. Read more at the GDPR compliance page.
PCI DSS The Payment Card Industry Data Security Standard is an 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 credit card transactions over the internet must comply with PCI standards. APM solutions must not leak credit card information.
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.

User Experience Management

User Experience Management (UEM) measures how fast an application performs from the perspective of the end user. It captures transactions triggered within browsers (desktop or mobile) or mobile apps from end to end: browser or app, over web server and application server, into the database. UEM lets you track user behavior on web pages. It helps you identify user problems before your user complains. It also lets you receive business analytics data like the geographic distribution of your web page visitors and average session duration. See User experience management to learn more about UEM.

The metrics for UEM measurements are captured 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. Then AppMon sends these metrics back to the server side.

Configuration

To fulfill data protection laws, mentioned above, you have to configure AppMon in a certain way. See Security and privacy configuration to learn how to protect personal information of end users.

In the nutshell, you need to:

  • Configure which data you're capturing. Don't capture the personal information unless it's absolutely necessary. Respect user's privacy settings, and never capture credit card details.
  • Protect captured data on its way between your application and AppMon and in AppMon storage.
  • Configure the rights to access AppMon. Only let AppMon users to see what they need. Limit the number of users who can configure your AppMon installation, and who can perform audit of it.

Security

You have to take care about safety of captured data. You have to make sure that your AppMon installation is secure, and only right people has the access to it. The AppMon insight section discuss technical means, used by AppMon to deliver user-related metrics. The Third party compatibility section talks about third-party instruments which help you to increase security of your AppMon installation. The Threat models section gives an overview of how well-known attack vectors are mitigated.

AppMon insight

To deliver user-related metrics, AppMon has not just measure them, but also link the measurement to a certain user session and return the measured data to the AppMon Server.

XML HTTP requests

Page actions are client-side actions performed by the user that triggers 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 the JavaScript Agent is to collect information about the application and actions within the user's browser, and then to report the information.

AppMon uses the XML HTTP request (XHR) to return 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.

Cookies

To identify a user session, AppMon uses cookies. Therefore it is a technical necessity that a Webserver 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.

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 shop needs to know who you are, otherwise you can't pay and the shop 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.

AppMon uses only 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 using the first-party cookie is standard technical and business practice.

Third party compatibility

Third party software can make your AppMon installation safer. You can and you should use those instruments to protect your AppMon environment and captured data.

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.

Anti-virus

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.

Full disk encryption

Operating system permissions deployed on the Session Store, combined with physical access controls, are the minimum requirements for protecting stored 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.

Threat models

Automated and manual security scans are part of the AppMon release cycle. As part of the system development life cycle (SDLC), security scans are conducted on infrastructure and web application basis. Additionally, an in house security team is responsible for performing penetration tests and coordinate the remediation of identified vulnerabilities. Below you can find information regarding the most prominent attack vectors, and some background information about those mitigations.

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.

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.

SQL injection

An SQL injection is not possible. The Web Server Agents don't access databases. Instead, they transmit received data by 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

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.