Security and Availability  

Keeping Neptune secure and highly available is fundamental to our business and we take both of them very seriously


Responsible Disclosure

We are dedicated to maintaining the security and privacy of the Neptune platform. We welcome security researchers from the community who want to help us improve our services. If you discover a security vulnerability, please give us the chance to fix it by emailing us at security@neptune.io. Publicly disclosing a security vulnerability without informing us first puts the rest of the community at risk. When you notify us of a potential problem, we will work with you to make sure we understand the scope and cause of the issue. Thank you for your work and interest in making the community safer and more secure!

Bounty Program

Neptune rewards security researchers for reporting vulnerabilities. Please email security@neptune.io to report an issue. If you would like to be eligible for a bounty, please read this carefully.

Rules

  1. NEVER attempt to gain access to another user's account or data.
  2. NEVER attempt to degrade the services.
  3. NEVER impact other users with your testing.
  4. Test only on in-scope domains, listed below.
  5. Do not use fuzzers, scanners, or other automated tools to find vulnerabilities.
  6. Doing any of the above will render you ineligible for cash bounties.

Scope

Only the following services are in-scope:
  1. www.neptune.io
  2. neptune.io
The following types of reports/attacks are out of scope. Do not attempt them:
  1. DOS attacks
  2. Brute forcing login/account management pages
  3. Physical vulnerabilities
  4. Social engineering attacks (e.g. phishing)
The following types of bugs do not qualify for bounties:
  1. CSRF on forms that are available to anonymous users (e.g., signup, login, contact, Intercom)
  2. Self-XSS and issues exploitable only through Self-XSS
  3. Clickjacking and issues only exploitable through clickjacking
  4. Functional, UI and UX bugs and spelling mistakes
  5. Descriptive error messages (e.g. stack traces, application or server errors)
  6. HTTP 404 codes/pages or other HTTP error codes/pages
  7. Banner disclosure on common/public services
  8. Disclosure of known public files or directories, (e.g. robots.txt)
  9. Presence of application or web browser "autocomplete" or "save password" permission

This Neptune Service Level Agreement ("SLA") between Neptune, Inc. ("Neptune", "us" or "we") and users of the Neptune Services ("you") governs the use of the Neptune Services under the provisions of the Neptune Terms of Service (the "Terms"). This SLA applies separately to each of your Dedicated Environments, as defined in the Terms. This SLA does not apply to shared environments. Unless otherwise provided herein, this SLA is subject to the provisions of the Terms. Capitalized words and phrases have the meaning specified in the Terms. We reserve the right to change the terms of this SLA in accordance with the Terms.

Service Commitment: 99.9% Uptime

Neptune will use commercially reasonable efforts to make the Neptune Services available with a Monthly Uptime Percentage of at least 99.95% during any monthly billing cycle (the "Service Commitment"). Subject to the Neptune SLA Exclusions, if we do not meet the Service Commitment, you will be eligible to receive a Service Credit. A Monthly Uptime Percentage of 99.9% means that we guarantee you will experience no more than 43.8 minutes/month of Unavailability.

Definitions

"Neptune Services" mean your apps and databases running on Neptune internal Environments. "Maintenance" means scheduled Unavailability of the Services, as announced by us prior to the Services becoming Unavailable. "Monthly Uptime Percentage" is calculated by subtracting from 100% the percentage of minutes during the month in which the Neptune Services were Unavailable. Monthly Uptime Percentage measurements exclude downtime resulting directly or indirectly from any Neptune SLA Exclusion. "Service Credit" means a credit denominated in US dollars, calculated as set forth below, that we may credit back to an eligible account. "Unavailable" and "Unavailability" mean: For apps, when all of your apps have no external connectivity For databases, when all of your databases have no connectivity, as confirmed by our monitoring.

Service Commitments and Service Credits

Service Credits are calculated as a percentage of the total charges paid by you (excluding one-time payments, e.g. for training, etc.) for the monthly billing cycle in which the Unavailability occurred in accordance with the schedule below: For Monthly Uptime Percentage less than 99.9% but equal to or greater than 99.0%, you will be eligible for a 10% Service Credit. For Monthly Uptime Percentage less than 99.0%, you will be eligible for a 30% Service Credit. We will apply any Service Credits only against future payments for the Services otherwise due from you. At our discretion, we may issue the Service Credit to the credit card you used to pay for the billing cycle in which the Unavailability occurred. Service Credits will not entitle you to any refund or other payment from Neptune. A Service Credit will be applicable and issued only if the credit amount for the applicable monthly billing cycle is greater than one dollar ($1 USD). Service Credits may not be transferred or applied to any other account.

Sole Remedy

Unless otherwise provided in the Terms, your sole and exclusive remedy for any unavailability, non-performance, or other failure by us to provide the Neptune Services is the receipt of a Service Credit (if eligible) in accordance with the terms of this SLA.

Credit Request and Payment Procedures

To receive a Service Credit, you must submit a claim by emailing support@neptune.io. To be eligible, the credit request must be received by us by the end of the second billing cycle after which the incident occurred and must include: the words "SLA Credit Request" in the subject line; the dates and times of each Unavailability incident that you are claiming; the account handle(s); and logs that document the errors and corroborate your claimed outage (any confidential or sensitive information in these logs should be removed or replaced with asterisks). If the Monthly Uptime Percentage of such request is confirmed by us and is less than the Service Commitment, then we will issue the Service Credit to you within one billing cycle following the month in which your request is confirmed by us. Your failure to provide the request and other information as required above will disqualify you from receiving a Service Credit.

Neptune SLA Exclusions

The Service Commitment does not apply to any unavailability, suspension or termination of the Neptune Services, or any other Neptune Service performance issues: That result from a suspension or Remedial Action, as described in the Terms; Caused by factors outside of our reasonable control, including any force majeure event, Internet access, or problems beyond the demarcation point of the Neptune network; That result from any actions or inactions of you or any third party; That result from the equipment, software or other technology of you or any third party (other than third party equipment within our direct control); That result from failures of Neptune Services not attributable to Unavailability; or That result from any Maintenance. If availability is impacted by factors other than those used in our Monthly Uptime Percentage calculation, then we may issue a Service Credit considering such factors at our discretion.
This policy outlines: 1) Your security obligations and 2) Neptune's security practices and resources.

Your Obligations

Our documentation may specify restrictions on how your servers and applications may be configured. You agree to comply with any such restrictions as specified.

You are responsible for properly configuring the services and taking your own steps to maintain appropriate security, protection and backup of your content, which may include the use of encryption technologies to protect your content from unauthorized access. Where security controls or data backup are offered as part of the services, you are responsible for implementing those features according to our instructions. You are ultimately responsible for determining the sufficiency of the security controls applied to your applications and data.

Neptune access credentials including API keys generated by the services are for your internal use only. You may not sell, transfer or sublicense them to any other entity or person, except that you may disclose your relevant keys to your agents and subcontractors performing work on your behalf who are fully covered by confidentiality contracts.

Reporting Security Vulnerabilities

If you discover a potential security vulnerability, please see our policy on Responsible Disclosure. We strongly prefer that you notify us in private. Publicly disclosing a security vulnerability without informing us first puts the community at risk. When you notify us of a potential problem, we will work with you to make sure we understand the scope and cause of the issue. Thank you!

Our Obligations

Without limiting any provision of the Neptune Terms of Service, we will implement reasonable and appropriate measures designed to help you secure your content against accidental or unlawful loss, access or disclosure.

Our Security Practices

Neptune manages information security using the ISO/IEC 27001:2013 framework, which specifies the requirements for establishing, implementing, maintaining and continually improving a comprehensive information security management system and risk management capabilities.

1. Data Center Security

Neptune runs on the Amazon Web Services global infrastructure platform. AWS publishes an "Overview of Security Processes" whitepaper that serves as the reference material for this section. SOC 2 reports are available directly from AWS upon request.

1.A - Compliance

AWS computing environments are continuously audited, with certifications from accreditation bodies across geographies and verticals, including ISO 27001, FedRAMP, DoD CSM, and PCI DSS. Additionally AWS also has assurance programs that provide templates and control mappings to help customers establish the compliance of their environments running on AWS against 20+ standards, including the HIPAA, CESG (UK), and Singapore Multi-tier Cloud Security (MTCS) standards.

P. 6 - "Introduction to AWS Security - July 2015"

1.B - Physical Security

AWS data centers are housed in nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.

P. 8 - "Amazon Web Services: Overview of Security Processes - August 2015"

1.C - Environmental Security

AWS data center environmental controls include:
  1. Fire detection and suppression systems
  2. Redundant power systems, backed by Uninterruptible Power Supply units and generators
  3. Climate and temperature controls
  4. Active system monitoring
P. 8 - "Amazon Web Services: Overview of Security Processes - August 2015"

2. Agent Security Model

Please refer to agent security model and architecture white paper for more details. The document goes through various attack vector scenarios and threat models and Neptune’s defenses.

You can also refer to Agent FAQ for further details. Note that Neptune agent does not require any inbound access and it only requires outbound access on port 443 for all its communication. The entire communication between agent and Neptune service happens over an encrypted https channel.

3. Network Security

Please see our Reference Architecture Diagram and architecture white paper for an explanation of the terms in this section. Refer to product/security FAQ for common questions.

3.A - Secure Architecture

Neptune servers run in a separate AWS Virtual Private Cloud (VPC). Each VPC is a logical isolated section in Amazon Web Services. All of the data exchanged with Neptune is sent over secure (TLS/SSL) connections. Our layered architecture also isolates some of our internal servers from direct public access.

3.B - Firewalls

All hosts run mandatory inbound firewalls configured in deny-all mode. HTTP/HTTPS ports are opened for necessary customer communications. SSH ports are opened on a need only and supervised basis to troubleshoot issues if any.

3.C - DDoS Protection and Mitigation

Neptune's VPC-based approach means that most internal components are not accessible from the Internet except for basic http/https ports, and cannot be targeted directly by a DDoS attack.

Neptune SSL/TLS endpoints include an AWS Elastic Load Balancer, which only supports valid TCP requests, meaning DDoS attacks such as UDP and SYN floods will not reach our application layer.

At the application level, we have several mitigation plans in place to ensure a single customer cannot block actions for other customers. We ensure this by having a dedicated SQS action queue per customer. Similarly, we have an account-level throttling mechanism established at entry points of our system to ensure fairness on a best effort basis among our customers.

Should we need to scale up the capacity to deal with a potential attack, we can quickly scale up our stack using AWS Autoscaling capabilities.

3.D - Port Scanning

AWS monitors and stops unauthorized port scanning. Because most of the Neptune stack is in a separate VPC, and all hosts run strict firewalls, port scanning is generally ineffective.

3.E - Spoofing & Sniffing

The AWS network prohibits a host from sending traffic with a source IP or MAC address other than its own. The AWS hypervisor will also not deliver any traffic to a host the traffic is not addressed to, meaning even an instance running in promiscuous mode will not receive or be able to "sniff" traffic intended for other hosts.

P. 13 - "Amazon Web Services: Overview of Security Processes - August 2015"

3.F - Intrusion Detection & Prevention

We have mechanisms in place to detect for any intrusion activity on our internal servers. AWS provides network level prevention at a high level. We have strong application level controls, throttling mechanisms at all layers to alarm us of any suspicious activity. If needed, we will restrict and throttle a single customer's agent communications with Neptune to protect other customers.

However, Neptune doesn't have any intrusion detection or prevention system to monitor your Neptune agents since they are part of your infrastructure. You may choose to run a host-based intrusion detection or prevention system that can be managed externally. Neptune agent does monitor and audit all actions for auditing purposes and every rule has an inbuilt action caps that will ensure a particular action is not performed repetitively forever even if it's a valid action.

4. Data Security

4.A PCI Compliance for credit card payments

We use PCI compliant payment processor Stripe for encrypting and processing credit card payments.They regularly conduct audits and scans to meet the strict financial regulations and security requirements.

4.B Employee access

Employee access to our servers is restricted on a need-only basis and temporary credentials are granted which are automatically revoked after some time. And we use 2 factor authentication for all employees access to our production environments.

4.C Data encryption

All communication between the customer and Neptune systems is encrypted. Any confidential information that the user stores in our systems (e.g. AWS keys) is stored in an encrypted format.

5. Platform Security

5.A - Configuration and Change Management

Our deployments are performed in a staggered manner across multiple data centers and are zero-downtime deployments. All the deployments and configuration changes are logged internally through our deployment and change management platform for auditing purposes. We leverage Amazon Elastic Beanstalk for application deployments.

We leverage Amazon Linux Machine Image for our machines. This will ensure that our servers are upto date with any patches for handling security vulnerabilities. The image is also a proven standardize setup with best practices around limited priveleges and access.

5.B - Isolation

The VPC, network, underlying instances, and AWS virtual infrastructure is a logically isolated section of Amazon Web Services.

5.C - Access Management and Restrictions

Neptune workforce members are only granted privileges on our servers on an as-needed, least-privilege basis. Some members will be granted administrator privileges on a purely selective basis. Access reviews are performed on a regular basis.

5.D - Logging and Monitoring

Neptune logs AWS and Neptune API activity, and host activity. We use Neptune internally to manage our own stack. The Neptune platform monitors performance indicators such as disk, memory, compute, and logging issues, and automatically resolves them.

5.E - Security Assessments

Neptune conducts regular security and vulnerability assessments of stack hosts and our applications. Code undergoes automated testing and manual code review prior to being deployed to production.Neptune also operates a responsible disclosure program for security vulnerabilities. Our security team diligently studies and responds to notifications of vulnerabilities and patches on a continuous basis.

5.F - Customer Code / Runbook repository

While you've an option to store runbooks on our platform, backed by AWS S3, which provides redundant, access-controlled storage, we strongly encourage you to keep your runbooks in your own github repository. Neptune doesn't require write access to your runbook repository. It just requires read-only access. This ensures runbooks executed by Neptune are versioned, code-reviewed and approved by you only.Performing code reviews and maintaining runbooks is fully the responsibility of the customer. We strongly urge you to do security reviews of your runbooks before pushing them to your private runbook repository.

5.G - Databases

Neptune always uses SSL/TLS protocol to communicate with our internal database, Amazon DynamoDB. DynamoDB provides consistent single digit millisecond latency at any scale while replicating data across multiple availability zones in a single region. This type of replication allows us to gracefully support single data center wide outages without impacting customers.

6. Contingency Planning

6.A - Backups

The Neptune platform automatically backs up several different types of data: Customer data is stored and replicated across multiple data centers automatically using our data store, DynamoDB. We have daily and weekly automatic backup jobs that replicate DynamoDB tables into AWS S3. In the event of an outage, we can replicate these tables in a different region other than us-east-1 and bring up DynamoDB in a different region. Backups are taken nightly and retained for one week. Weekly backups are retained for more than 2 months.

Data retention policies for customer data are applied according to the appropriate pricing plan. No customer action is required.

Neptune recommends storing your runbooks in a separate access controlled github repository.

6.B - Fault Tolerance

AWS data centers are clustered into regions, and sub-clustered into availability zones, each of which is designed as an independent failure zone, meaning they are:
  1. Physically separated
  2. Located in lower-risk flood plains
  3. Equipped with independent uninterruptable power supplies and onsite backup generators
  4. Fed via different grids from independent utilities, and
  5. Redundantly connected to multiple tier-1 transit providers

6.C - High Availability

Neptune supports high-availability and our SLA is 99.9%. Refer to our Service Level Agreement for more details. Neptune applications are designed to gracefully handle a single data center-wide outage (i.e. entire AWS availability zone is down). Neptune uses servers from AWS EC2 us-east-1 as a primary region. In the event of prolonged EC2 us-east-1 outage, Neptune has a backup environment setup in us-west-1 region and it can fail-over in under 30 minutes.

6.D - High Scalability

We have automated scaling policies setup for both web server and database tiers. EC2 instances are scaled automatically using Auto Scaling Groups. Similarly, DynamoDB provisioned throughput is increased automatically by bumping up read capacity and write capacity units. They scale automatically according to the customer traffic spikes up to a certain point. Beyond certain scaling limits, it requires manual action. Otherwise, for the most normal workloads, Neptune handles the load automatically. No human intervention is necessary.

6.E - Disaster Prevention and Recovery

Neptune monitors the stability and availability of its infrastructure and automatically recovers from disruptions, including app and database failures. In the event of a disaster in EC2 us-east-1, Neptune can failover to us-west-1 region for EC2 instances. We have a slave environment setup in us-west-1 region as a disaster recovery backup. Similarly, in the event of AWS us-east-1 DynamoDB database outage, it can come up in AWS us-west-1 region using daily database table backups. Raw database table backups are performed daily and weekly and daily backups are retained for one week and weekly backups are retained for 2 months.

Start your   Free trial  or   Book a demo slot