Security Policy

Version 3.5 – February 2017
This policy outlines: 1) SNX Consulting’s security practices and resources, and 2) your security obligations. This policy is incorporated by reference into the SNX Consulting Terms of Service.

Your Obligations

Our documentation may specify restrictions on how Applications may be built or configured. You agree to comply with any such restrictions as specified.
You are responsible for properly configuring and using the Services and taking your own steps to maintain appropriate security, protection and backup of Your Content, which may include the use of encryption technology to protect Your Content from unauthorized access and routinely archiving Your Content. 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.
SNX Consulting access credentials and private 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 private key to your agents and subcontractors performing work on your behalf.
Pursuant to Section 2 of the SNX Consulting Terms of Service, you will not use the Services to create, receive, maintain, or transmit electronic protected health information, as defined in 45 C.F.R. § 160.103, without a Business Associate Agreement in place between you and SNX Consulting.

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 SNX Consulting 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

SNX Consulting 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

SNX Consultingruns 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: – 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. Network Security

Please see our Reference Architecture Diagram and FAQ for an explanation of the terms in this section.

2.A – Secure Architecture

SNX ConsultingEnclave stacks run in separate AWS Virtual Private Clouds. Each stack is an isolated network. Most services run in a private subnet. Only SSL/TLS endpoints and a bastion host are exposed to the Internet. Backend users connect to the stack through the bastion host, which restricts access to stack components and logs activity for security review.

2.B – Firewalls

All stack hosts run mandatory inbound firewalls configured in deny-all mode. HTTP, HTTPS, and SSH ports are opened as necessary.

2.C – DDoS Protection and Mitigation

Enclave’s VPC-based approach means that most stack components are not accessible from the Internet, and cannot be targeted directly by a DDoS attack.
Enclave 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 your app layer.
Should you need to add capacity to deal with a potential attack, you can instantly scale your stack using the SNX Consulting dashboard or command line tool.

2.D – Port Scanning

AWS monitors and stops unauthorized port scanning. Because most of an Enclave stack is private, and all hosts run strict firewalls, port scanning is generally ineffective.

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

2.F – Intrusion Detection & Prevention

You may choose to run a host-based intrusion detection or prevention system that can be managed externally, such as Threat Stack, as an add-on. SNX Consulting will ensure the host agents run and can connect to your external management service. You are responsible for procuring a license and operating the system.

2.G – Network and Host Vulnerability Scanning

SNX Consulting scans both the Internet-facing network and private network of each customer VPC and its hosts monthly. SNX Consulting is responsible for network and host security, and remediates adverse findings without customer intervention.

2.H – Host Hardening

Enclave host operating systems are hardened based on the Center for Internet Security’s Security Configuration Benchmark for the OS and version in use. For all operating systems:

• Operating systems are installed on hosts only from bare images, and only via automated configuration management. Services installed can be enumerated upon request.
• Host password logins are disabled. SSH root keys are not permitted.
• No user SSH keys are permitted on hosts by default. SNX Consulting internal workforce user access is configured only on a per-user basis, and only when necessary to provide customer support.
• Swap is disabled to avoid writing in-memory secrets to unencrypted volumes.
• Command history for shell sessions is disabled.
• Non-default SSH ports are used.
• No password-based services are installed automatically. Password-based services (such as PostgreSQL) are provisioned only with unique, per-resource, SNX Consulting-generated passphrases. No default passwords are permitted.
• Host security updates are automated.
• All host ports are opened only via whitelist.

3. Platform Security

3.A – Configuration and Change Management

For app services that have an SSL/TLS endpoint attached, Enclave performs a health check on the container set before promoting it to the current release. If the health check fails, the container set is not promoted. Either way, the deploy is zero-downtime.
For any deploy, you can roll back to a previous codebase by pushing a different ref to your app’s Git endpoint.

3.B – Isolation

Dedicated, PHI-ready environments are deployed on stacks isolated at the customer level. The VPC, network, underlying instances, and AWS virtual infrastructure are not shared with any other tenant.

3.C – Access Management and Restrictions

SNX Consulting workforce members are only granted administrative privileges on customer stacks on an as-needed, least-privilege basis. Access reviews are performed on a regular basis.

3.D – Logging and Monitoring

SNX Consulting logs AWS and SNX Consulting API activity, and host activity within your stack. Enclave monitors performance indicators such as disk, memory, compute, and logging issues, and automatically resolves them on your behalf.

3.E – Security Assessments

SNX Consulting 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. Our security team receives regular notifications of vulnerabilities and patches on a continuous basis.
SNX Consulting also operates a responsible disclosure program for security vulnerabilities, with cash bounties.
You are responsible for app-level security of the apps you deploy to SNX Consulting.

3.F – Customer Code

 
SSH public key authentication is used to limit access to your authorized backend users during git-based deploys. Following a successful push to an SNX Consulting git endpoint, code is copied down to your stack’s build layer. The resulting images are pushed to a private stack registry, backed by AWS S3, which provides redundant, access-controlled storage.

3.G – Databases

Databases run in the database layer of your stack, on a private subnet accessible only from app or bastion layer. SSL/TLS is required if the database protocol supports it. Disk volumes backing databases are encrypted at the filesystem level using SNX Consulting-managed AES encryption. You can check whether your database uses AES-192 or AES-256 in the Enclave dashboard.

4. Contingency Planning

4.A – Backups

The SNX Consulting platform automatically backs up several different types of data:

• Customer app code and the container images built from that code are stored in private, redundant, access-controlled registries. SNX Consulting recommends that customers maintain the canonical version of their codebase in a distributed version control system, such as GitHub. In the event of an app-level outage, the SNX Consulting platform automatically restores services from registry backups.
• Customer metadata is stored in the SNX Consulting operational API, backed by the Amazon Relational Database Service. This metadata includes customer account data (passwords, permissions, SSH keys), and app configuration data, such as environmental variables. Backups are taken nightly and retained for one week.
• Customer database disks are automatically backed up nightly and retained daily for 90 days, and monthly for 6 years. No customer action is required. Two backup copies are kept: One in the region where the database runs, to facilitate fast disaster recovery; One in a separate geographic region to protect against loss of the original region. Customers may also take on-demand backups.
• For databases like PostgreSQL that support intermediate backups (e.g., write-ahead logs), SNX Consulting configures these intermediate backups to span at least the time between daily backups, to enable fine-grained, point-in-time disaster recovery.

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

For PHI-ready environments, SNX Consulting automatically distributes app containers across availability zones when a service is scaled to more than one container.

4.C – High Availability

Enclave allows you to set up high-availability clustering for databases that support it.
App services on v2 stacks are automatically distributed across AWS availability zones as soon as they are scaled to more than one container.

4.D – Disaster Prevention and Recovery

SNX Consulting monitors the stability and availability of customer infrastructure and automatically recovers from disruptions, including app and database failures. In the event of a disaster, SNX Consulting restores apps from the last healthy build image and restores data from the last backup. In the event of a database outage, Enclave will automatically recover the underlying database instance and disk. If the disk is unavailable, Enclave will restore from a backup. Raw database snapshots and restored database clones are available upon request for testing and recovery.