Security Overview New Relic Application Performance Management June - - PDF document
Security Overview New Relic Application Performance Management June 2014 This paper serves as an overview of the security and privacy considerations for New Relics Application Performance Management service. It addresses the most common
June 2014
This paper serves as an overview of the security and privacy considerations for New Relic’s Application Performance Management service. It addresses the most common concerns customers may have about security and privacy, while outlining the security controls available within New Relic.
About New Relic
New Relic is a privately held and venture capital backed company based in San Francisco, California, USA. As of January 2012, New Relic has received four rounds of venture funding from prominent venture capital firms Allen & Co., Benchmark Capital, DAG Ventures, Four Rivers Group, Tenaya Capital, and Trinity Ventures. New Relic’s executive team includes industry veterans and visionaries Lew Cirne CEO/Founder and Chris Cook COO/President. New Relic is the all-in-one web application management provider for the cloud and the
in production each day. Fully implemented in just minutes, New Relic provides 24x7 real user monitoring and code-level diagnostics for web apps deployed on dedicated infrastructures, the cloud, or hybrid environments. New Relic provides support for Ruby, Python, PHP, Java, .NET and Node.js platforms and related frameworks. New Relic also partners with leading cloud management, platform, and hosting vendors to provide their customers with instant visibility into the performance of deployed applications.
SOC 2 Compliance
New Relic completes an annual SOC 2 type II audit of processes and controls relevant to security and availability. Officially, a SOC 2 is an audit that reports on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or
unlike SAS 70, which only verified that the controls and processes that a company had put in place were actually followed, the SOC 2 actually provides a minimal set of security standards that must be followed. This set of standards is known as the Trust Services Principles and Criteria. By putting ourselves through the SOC 2 audit process and by holding ourselves accountable to the Trust Services Principles and Criteria, New Relic is able to provide both ourselves, and more importantly, our customers an independent, third-party assurance that we are in fact taking the appropriate steps to protect our systems and
Security
New Relic is committed to using certain technical measures to enhance the security of your application’s performance data. We use a variety of industry-standard security technologies and procedures to help protect your information from unauthorized access, use, or disclosure.
How New Relic Works
New Relic collects performance metrics from applications and systems, uploads those metrics to the New Relic service, and presents application performance information through a secure
certified datacenter.
password-protected website: https://rpm.newrelic.com
Figure 1: How New Relic Works
Data Collected
While it is important to understand how New Relic securely handles the data collected, it is equally important to understand what type of data is collected. New Relic only collects performance data for the applications and/or servers where the New Relic agent is installed. In general, this includes time measurements for application transactions and web page loading, application errors and transaction traces, and server resource utilization statistics. New Relic was not architected to collect any data used or stored by a monitored application during the normal course of operation. For example, if a monitored application collects and stores credit card information, New Relic does not collect or store that information. Below is a summary of the data collected by the New Relic agents. New Relic collects the following aggregate metric data for all applications with a New Relic application monitoring agent installed:
This aggregate metric data summarizes calls to specific methods in an application, how many times each one was called, and various response time statistics (average, minimum, maximum, and standard deviation). New Relic will display the class and method names along with the aggregated metrics. New Relic Pro customers have the option to have the application monitoring agent collect:
trace from requests that result in an uncaught error -- an error not specially handled by your application. It will also collect the errors from requests that do not return a successful HTTP status to your customer, such as a 404 or 500 errors. In addition, New Relic can be configured to collect HTTP parameters of the requests that result in an error. HTTP parameter collection is not enabled by default in New Relic - it can be enabled by editing the proper setting in config/newrelic.yml. New Relic recognizes filter_parameters, which can be used to indicate sensitive parameters to be
excluded from being sent to the New Relic service, just as they would be filtered from log
knowledge base at http://support.newrelic.com.
that New Relic perceives to be a slow transaction. Optionally, New Relic can collect the SQL statements called within the application transaction. SQL collection is configured by setting the record_sql parameter in the newrelic.yml file to one of the following three modes:
“where” clause with obfuscated patterns. This is the default setting and provides a measure of security while still providing good visibility of the SQL queries in your application.
service. By default, New Relic is configured with record_sql set to obfuscated. For transactions slower than a user-customizable threshold, New Relic can also collect data from SQL
newrelic.yml file. Note, New Relic can collect stack traces when errors or slow SQL statements are found within a transaction trace. This option can be disabled in the newrelic.yml file. New Relic collects the following server utilization data for all servers with the server monitoring agent installed:
Data Transmission
There are two scenarios in which New Relic transmits the application performance data of monitored applications. The first scenario, referred to as outbound transmission, is when the New Relic agent that is installed on a monitored application or server collects performance metrics and transmits that data to the New Relic service. The second scenario, referred to as inbound transmission, is when application performance information is displayed on the https://rpm.newrelic.com website for monitoring, analyzing, and optimizing application performance. Outbound Data Transmission By default, data transmission from the New Relic agent to the New Relic service uses SSL
to potentially serious security attacks) via the SSL parameter in the newrelic.yml file. The New Relic agent communicates with two hosts: collector.newrelic.com and one of collector-[09].newrelic.com, where the numbered host is fixed for each account. Which numbered host each account uses is displayed in the log/newrelic_agent.log at startup. New Relic uses JSON for sending data from the agents to the New Relic service and for the responses back from the New Relic service to the agents. Inbound Data Transmission New Relic users access the service either by visiting https://rpm.newrelic.com via a web browser
SSL-encrypted using HTTPs. Website and API access both require username and password
Access Controls
New Relic allows for an unlimited number of authorized users to be associated with an individual
account can add additional users at any time and are able to modify the settings for some New Relic features (e.g. alert thresholds) and the kinds of data collected. Regular users are able to view the data collected by New Relic but are not permitted to add other users or to change account settings. Restricted users are able to view the data collected by New Relic but are not permitted to make any configuration changes, create any notes, or delete any items. User accounts are associated to an email address and are secured by a password selected by the
New Relic recommends restricting Administrative accounts to a small number of trusted users within an organization in order to keep user accounts constrained within your intended policies.
Physical Security
New Relic’s servers are hosted in a world-class Tier 3 SSAE 16 certified datacenter in order to provide the highest level of security for our infrastructure and our customers. This includes fully redundant power backup systems, fire suppression systems, security guards, and biometric authentication systems.
Regulatory Compliance
Payment Card Industry Data Security Standard (PCI)
The PCI security standard aims to reduce fraud by reducing the exposure of credit card data handled by organizations that process credit card transactions. As an application performance tool, New Relic does not process or store credit card information in any way. When a New Relic account is set up, the user may elect to pay for the service using a credit card. The data is sent
available to New Relic employees unless the account owner provides it to a New Relic employee directly. Many New Relic customers are subject to the highest level of PCI standards. Use of New Relic does not affect our customers’ PCI compliance in any way. To ensure our customers’ data remains private customers should not enable the collection of HTTP parameters or of raw SQL as described in the Data Collection section above.
Health Insurance Portability and Accountability Act (HIPAA)
HIPAA was created to encourage electronic data interchange within the US healthcare system, while establishing regulations on the use and disclosure of protected health information (PHI). Title II of HIPAA includes a Security Rule that outlines the administrative, physical and technical safeguards that must be in place for HIPPA compliance.
To ensure our customers’ applications do not expose personal health information to New Relic, customers should not enable the collection of HTTP parameters or of raw SQL as described in the Data Collection section above.
Applications with Acute Security and Privacy Considerations
Some applications may contain such highly confidential information that it is perceived that a SaaS tool is not a viable option. However, it has been our experience, along with many of our customers in a variety of industries including financial services, that most applications can enjoy the benefits of New Relic with no additional risk. For especially sensitive applications using New Relic, the following are recommended configuration settings for the newrelic.yml file:
sent to the New Relic service
sent to the New Relic service With this configuration, only class names, action names, errors and performance metrics will be exposed for monitored applications.
Security Contacts
New Relic takes security very seriously. If you have a security question or potential vulnerability to discuss, please contact us immediately:
Disaster Recovery and Data Backup
New Relic performs full offsite backup of all customer data daily. In addition, we have a Disaster Recovery plan in place that is tested annually.
EU Considerations
New Relic is U.S. Department of Commerce Safe Harbor Certified. All customer data is stored in the United States.
Conclusion
New Relic uses a variety of industry standard security technologies and procedures to help protect our customers’ data from unauthorized access, use, or disclosure. These safeguards enable companies to tune the service to the right level of security for your business. Using these security settings in addition to our secure infrastructure provides a high-value performance tool that suits any business.
For More Information
If you have additional questions or need further clarification, please contact us by phone at +1 888 643 8776 (Outside North America +1 650 777 7600) or by email support@newrelic.com.
New Relic, Inc. 188 Spear St., Suite 1200, San Francisco, CA 94105 (888) 643-8776 • sales@newrelic.com • newrelic.com