Privacy and Security Policies / Regulations

Version 1.0 – 15 May 2019

 

This policy outlines:

  1. Envizage’s security practices and resources, and
  2. your security obligations.

 

Obligations under this policy (both ours and yours) are ncorporated by reference into the Envizage Terms of Use

 

Our Obligations

Without limiting any provision of the Envizage 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.

Your Obligations

Our documentation may specify restrictions on how the API may be configured, or specifications for your instance. You agree to comply with any such restrictions or specifications.

You are responsible for properly configuring and using the Instance and taking your own steps to maintain appropriate security, which may include the use of strong passwords and secure storage of your client ID and client secret according to Oauth2 best practices.

Envizage access credentials generated by the API 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 client ID and secret to your agents and subcontractors performing work on your behalf.

You will not use the API to create, receive, maintain, or transmit GDPR Personal Data without the corresponding agreement legal agreement (GDPR data protection agreement) in place between you and Envizage.

 

Requesting Penetration Testing Authorization

You may conduct penetration tests of the API. To do so, please contact us with the following information:

  • Start and end times for the scan window (YYYY-MM-DD HH:SS format)
  • Environment(s) to be tested (dedicated stacks only please)
  • Source IPs (and owners of those IPs) for the scan
  • Expected peak requests per second
  • Whether you or the testing company have an NDA in place with AWS
  • Name, email, and phone for a point of contact for both you and the testing company

 

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!

 

1. Data Center Security

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

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

  1. 5 – “Amazon Web Services: Overview of Security Processes – May 2017”
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
  1. 5-8 – “Amazon Web Services: Overview of Security Processes – May 2017”

2. Envizage Network Security

Architectural Diagram

2.A – Secure Architecture

The Envizage platform is comprised of three separate AWS Virtual Private Clouds which are connected between them using VPC Peering. A VPC Peering connection is a networking connection between two VPCs that enables you to route traffic between them privately, inside the AWS infrastructure.

The three VPCs correspond to (a) a Kubernetes cluster running Ingress endpoints and performing orchestration of various microservices, (b) a MongoDB database cluster and (c) a RabbitMQ message oriented middleware cluster. Additionally, traffic between the microservices and the MongoDB database cluster and traffic between the microservices and the RabbitMQ message oriented middleware is performed only using SSL/TLS.

Exposure to the Internet is done only through SSL/TLS endpoints and a bastion host. Backend users connect to the system through the bastion host, which logs activity for review. User based encrypted traffic is first routed through the AWS Elastic Load Balancers, then through our Internal Ingress Controllers and finally reaches the microservices.

2.B – Firewalls

No public-facing EC2 instances except the bastion servers and those running our ingress controllers. The bastion host allows SSH traffic restricted to the Envizage Virtual Private Network (VPN).  

2.C – Intrusion Detection & Prevention

Envizage runs a series of services following security best practices for intrusion detection and prevention.

Amazon Cloudwatch monitors the hardened bastion hosts and will detect potential intrusions and other anomalous activities.

 

The Envizage Security Team monitors and investigates each event to determine the legitimacy of all activity. Crucially, the Envizage Security Team immediately responds to and resolves any issues that are discovered through investigation of anomalous activity and will notify you of any remediation steps taken.

2.D – DDoS Protection and Mitigation

Envizage’s VPC-based approach means that most components are not accessible from the Internet, and cannot be targeted directly by a DDoS attack.

Envizage 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 the API layer. Additionally, the Ingress controllers use the rate limiting capability of Nginx. We have in place both a limit for concurrent open connections per IP and a maximum number of requests per second for new connections.

2.E – Port Scanning

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

2.F – 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.

  1. 13 – “Amazon Web Services: Overview of Security Processes – May 2017”
2.H – Network and Host Vulnerability Scanning

Envizage partner Comsec is contracted for periodically scanning the perimeter network for vulnerabilities.

3. Envizage Platform Security

Technical Architecture diagram

3.A – API catalog encryption & session management

Our service catalog is served over SSL/TLS connections using SHA-2 certificate. SSL offloading happen on the kubernetes ingress controllers and requests are proxied back to the microservices over HTTP.

Envizage uses stateless session management leveraging JWT (JSON web tokens) signed with RSA 2048 bits key.

3.B – Client onboarding

Envizage installations are multi-tenant supporting multiple tenants on a single instance, each having its own users, configuration, analytics and service accounts.

 

The only supported authorisation mechanism is the OAuth 2.0. Each tenant will use the OAuth2 authorisation flows to access the API.

 

3.C – Audit Trails and Monitoring

All activity by accounts with elevated privileges (admins, client admins and client accounts) are automatically recorded in an audit trails database collection.

The activity is anonymised before it’s recorded by stripping out any personal identifiable data from the request.

3.D – Intrusion Detection & Prevention

Login attempts are being monitored and logged. Consecutive failed attempts will result in automatic blacklisting of the user’s IP for a period of time and notification will reach an email address that is monitored by the management team.

 

3.E – Authentication & Authorization

The Envizage platform implements the OAuth 2.0 specification, which defines a delegation protocol that is useful for conveying authorization decisions across a network of web-enabled applications and APIs. OAuth is used in a wide variety of applications, including providing mechanisms for user authentication and resource authorisation.

 

The Envizage platform defines a comprehensive list of admin and user authorities for fine grained access control.

3.F – Database

All tenants (clients) of our system use the same database instance. There is a rigorously tested logical layer which keeps the tenants isolated from each other. There is no hard segregation in the environment between clients. The segregation is ensured by a set of filters that act as a switch to authorise access to resources based on a client.

 

3.G – Inter-process communication

Inter-process communication may happen with 2 mechanisms

  1. HTTP-based REST access for synchronous requests between microservices.  Since microservices run on the same VPC we assume trusted network thus we use HTTP.
  2. Asynchronous message-based communication that happens via a managed RabbitMQ message broker running in a peered VPC network. As an additional security measure, connections are SSL/TLS.

 

4. Envizage Business Continuity

4.A – Load balancing and high availability

Envizage are running the service in a highly available kubernetes cluster. We run multiple instances (containers in kubernetes Pods) of each microservice for load balancing and high availability. Computational nodes that run our instances span across multiple availability zones.

 

4.B – Zero-downtime deployments

Readiness probes are configured on all microservices for zero-downtime deployments. Requests are only routed to newly spawned containers after readiness probe validates that the microservice is fully bootstrapped and ready to service requests.

 

4.C – Self-healing

Liveness probes are configured for all microservices. Malfunctioning pods are timely and automatically identified and restarted by the kubernetes replication controllers constantly getting the server to a stable state.

 

4.D – Rolling upgrades, Canary releases & Blue-Green deployments

Envizage employs rolling upgrades, canary releases and blue-green deployments when appropriate to ensure uninterrupted service even while doing multiple production releases each day.

Fully automated CI/CD pipelines ensure that each release will be promoted sequentially between testing, staging, pre-production and production servers running automated functional tests and manual tests on one or more stages of the pipeline before the final promotion to the production server is made.

4.E – Backups

MongoDB Atlas continuous backups take incremental backups of data in our cluster, ensuring your backups are typically just a few seconds behind the operational system. Atlas continuous backups allows for restore from stored snapshots or from a selected point in time within the last 24 hours.

 

4.F – 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 uninterruptible power supplies and onsite backup generators
  • Fed via different grids from independent utilities, and
  • Redundantly connected to multiple tier-1 transit providers

Microservice containers are scheduled by the kubernetes scheduler across multiple availability zones.

4.G – Disaster Prevention and Recovery

Envizage monitors the stability and availability of the infrastructure and will respond timely in the event of a disaster. Envizage will restore latest database backup that should be a few seconds behind the operational system. Precise cluster structure and docker image versions of each microservice is persisted in a git repository and can be recreated.