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