This policy outlines: 1) Your security obligations and 2) Neptune's security practices and resources.
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!
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"
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:
- Fire detection and suppression systems
- Redundant power systems, backed by Uninterruptible Power Supply units and generators
- Climate and temperature controls
- 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
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
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
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:
- Physically separated
- Located in lower-risk flood plains
- Equipped with independent uninterruptable power supplies and onsite backup generators
- Fed via different grids from independent utilities, and
- 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.