Security

Contents

Introduction

AskNicely is a SaaS platform used to collect and analyse customer feedback and NPS. AskNicely's development team is based in Auckland, New Zealand. This is a collection of topics that describe how we run AskNicely securely. They're intended as a high-level introduction to how we deal with security, in order to help you with your decision making process. More details are available on request - just ask your sales representative.

Overview

As a very high-level summary:

  • AskNicely has strong application, network and infrastructure-level security controls in place to ensure your data is safely stored and processed
  • AskNicely serves multiple tenants from the same application codebase, but uses effective isolation techniques to keep tenant data separate
  • AskNicely observes New Zealand privacy laws, which are broadly compatible with many other jurisdictions (for example, we support the rights of access and rectification for data subjects)
  • AskNicely is hosted on AWS, in multiple regions, using VPC

You'll find more information on each of these points in the detailed chapters documents below.


Infrastructure Security

Datacenters

AskNicely’s products are hosted with the world’s leading data centre provider, Amazon Web Services (AWS). Access to these datacenters is strictly controlled and monitored by 24x7 on-site security staff, biometric scanning and video surveillance. AWS maintains multiple certifications for its data centres, including ISO 27001 compliance, PCI Certification, and SOC reports. For more information about their certification and compliance, please visit the AWS Security website and the AWS Compliance website.

Availability and Resiliency

All services (databases, application servers, web servers, etc.) that make up the AskNicely system are highly-available. We use a combination of clustering (e.g. Elasticsearch), load-balancing (e.g. HTTP), and replication (e.g. MySQL) in order to ensure that there are no single points of failure in the system. Each of our regions makes use of three or more availability zones, with redundancy across them.

Configuration Management

We have a configuration management system based on Puppet, Ansible and Terraform. The entire configuration of all of our infrastructure is captured in version control, so we have a full record of every change made to the infrastructure. It also allows us to ensure all our servers have the same, appropriate configuration, and that they are all kept up to date with the latest changes (we have CI/CD pipelines for our infrastructure codebases too). We use a "cattle not pets" approach to infrastructure; any server can be completely replaced with another (or a new one) very easily. This allows us to rapidly provision new infrastructure when necessary; server instances can be built and torn down within minutes as needed to size the infrastructure appropriately and respond to customer needs. This makes our service more resilient to failures, and more reliable for the end user.

Patching Policy

All of AskNicely's production servers are up to date with the latest security patches from their upstream operating system vendors. Security patches are applied immediately, as they become available upstream; they are installed automatically and don't require human intervention to be applied. We also regularly install non-security update patches, but those are not applied immediately without supervision, and are instead tested before being rolled-out cluster-wide.

Server Authentication

Our main way of administering our servers is via tools that operate over SSH (such as Ansible). To keep such SSH connections secure:

  • AskNicely servers have remote password authentication disabled - only key-based authentication is allowed.
  • Login as root is disabled to force attackers to guess an account name as well as a password.
  • None of the servers that process customer data are directly or externally accessible; all access to production machines is via a gateway.

Monitoring

AskNicely uses several third-party services for monitoring the performance of the application. These monitoring methods include:

  • Syslog-style distributed logs, which are collected for centralized analysis
  • Statsd-style emitted metrics over UDP
  • Specific monitoring agents running on some servers (e.g. the NewRelic agent, AWS agent etc.)
AskNicely has an on-call engineer at all times. In the event of degraded performance or a similar issue, the on-call engineer will update AskNicely's status page with details of the investigation and fix

Automated Scanning

AskNicely makes use of several forms of automated scanning throughout its infrastructure, in an attempt to provide real-time detection and monitoring of threats and attacks.

Vulnerability Scanning

While our unattended patching system keeps our software packages up to date with security fixes, we also run Amazon Inspector regularly. This both checks for packages that have vulnerabilities (providing a double-check of our patching systems), and also checks for common misconfigurations. The rulesets we use with Amazon Inspector are:

  • CVE 1.1
    • Checks for vulnerable software installed on systems
  • Security Best Practices 1.
    • AskNicely servers have remote password authentication disabled - only key-based authentication is allowed.
    • Login as root is disabled to force attackers to guess an account name as well as a password.
    • None of the servers that process customer data are directly or externally accessible; all access to production machines is via a gateway.

Monitoring

AskNicely uses several third-party services for monitoring the performance of the application. These monitoring methods include:

  • Syslog-style distributed logs, which are collected for centralized analysis
  • Statsd-style emitted metrics over UDP
  • Specific monitoring agents running on some servers (e.g. the NewRelic agent, AWS agent etc.)
AskNicely has an on-call engineer at all times. In the event of degraded performance or a similar issue, the on-call engineer will update AskNicely's status page with details of the investigation and fix

Automated Scanning

AskNicely makes use of several forms of automated scanning throughout its infrastructure, in an attempt to provide real-time detection and monitoring of threats and attacks.

Vulnerability Scanning

While our unattended patching system keeps our software packages up to date with security fixes, we also run Amazon Inspector regularly. This both checks for packages that have vulnerabilities (providing a double-check of our patching systems), and also checks for common misconfigurations. The rulesets we use with Amazon Inspector are:

  • CVE 1.1
    • Checks for vulnerable software installed on systems
  • Security Best Practices 1.
    • Checks e.g. password complexity, ASLR use, etc.
  • Runtime Behaviour Analysis 1.0
    • Checks e.g. for insecure ports in use, DEP use, etc.

We fix any issues these rulesets reveal with a severity higher than informational.

Intrusion Detection

We make use of Amazon GuardDuty to detect abnormal or suspicious use of our systems that may indicate an intrusion by attackers. GuardDuty monitors network flows, administrative events and DNS lookups throughout our production systems. It identifies suspected attackers through integrated threat intelligence feeds and uses machine learning to detect anomalies.

Data Leak Scanning

AskNicely regularly (and in real-time) scans for leaks of personally identifiable information in its production file storage systems. For this purpose, AskNicely uses Amazon Macie. Macie uses machine learning to classify files and detect personal information that may be at risk of exposure.

Data Security

Privacy

We will only use the Customer Information that you have provided to us for the purpose of obtaining your Net Promoter Score and other customer feedback about you, or to provide any other service that you have requested. For the avoidance of doubt, we can say explicitly that we will never sell or trade Customer Information provided by you to third parties. You are solely responsible for ensuring that your provision of Customer Information to us complies with all applicable privacy or data protection laws and agreements that you have entered into and that you are authorised to provide it to us. AskNicely complies with the provisions of the New Zealand Privacy Act. You can read our privacy policy online.

General Data Protection Regulation (GDPR)

At AskNicely, we welcome the data privacy and security principles that GDPR emphasises, and we’re committed to achieving compliance with the GDPR by 25 May 2018.​ ​For full details on what we're doing to comply, see our GDPR Guide.

If you want to​ ​access, update, or delete your data with AskNicely, see how here​.​

Data Sovereignty

When you sign up for AskNicely, we can give you the option of having your data hosted in one of the following regions: Oregon (US), Canada, Sydney (Australia), or Frankfurt (Germany). Further regions may be available if requested; ask your sales representative if you have a need to be hosted in a specific region for data sovereignty or legal purposes.

Leaving AskNicely

When you stop using AskNicely, we'll immediately delete all your customer and response data from our main databases. Your customer and response data will still be contained within our data backups (see our backup policy for details). This data will be deleted at the end of a full backup rotation - this process currently takes 15 days. After this period, all your customer and response data will be gone, and AskNicely will retain no access to it at all.

Support Access

In order to to help with any problems you’re having, our customer service representatives have access to your account. Our staff are prohibited from using this access except where necessary, or where you’ve requested assistance. We keep a log of every access of a customer's account by our support representatives.

Audit Logs

As part of our security and compliance program we keep a centralized log of user activity within your account for auditing. Examples of events that are audit logged are as follows: log-on failed-attempts & successes, data accessed, scheduling and administrative configuration changes. This is immutable, time synced, and accessible on request by account admins.

Web Application Security

Change Management

CI/CD

Changes to the product are introduced by the AskNicely development team only (we don't allow third-party access to the codebase). The team uses continuous integration and delivery:

  • Changes are made in short-lived and small-sized branches that begin from the master branch
  • When ready, the changes in a branch are reviewed by another developer, and merged into the master branch
  • When changes have been made to the master branch, these changes are automatically deployed into the production environment
Tests are run after every commit to any branch. The deployment of changes in master won't happen if this testing fails in any way.

Testing

AskNicely uses several forms of testing (unit, functional, etc.) to ensure changes are safe to be applied. We have several thousand tests that are run against every commit.

User Authentication

Password Storage

We never store passwords as plain text. Instead, all passwords are salted and hashed via bcrypt, with a suitable cost parameter.

Password Requirements

We offer the ability to enforce password requirements on end users of the AskNicely platform - ask your sales representative for information about turning this feature on (it's opt-in)

  • We use modern-style password complexity requirements, designed to avoid the problem of too many constraints causing users to use insecure or incrementing passwords
  • We enforce a strong password length and disallow repeating subsequences
  • We compare the password to a list of 20,000+ commonly used passwords (that would otherwise meet complexity requirements), obtained from previous data breaches (i.e. from haveibeenpwned.com data)

For example, the password "lemonandlime" would be disallowed. Even though it's long enough and doesn't directly appear in (most) wordlists, it is still a bad password because it is rather commonly used.

Google Authentication Support

As an alternative to logging in with an email address and password, we can enable Google OAuth authentication for your account; ask your sales representative for details on how to use this optional feature. This feature is often preferred by customers who are already using Google Apps to manage their organisation, because you can add and manage users in a single centralized place.

Two/Multi-factor Authentication

When Google Authentication support is enabled, we can completely disable regular password authentication for you. This allows you to enforce the use of a 2FA/MFA token in Google Apps. The token can be any sort supported by Google's login system (e.g. you could use a U2F hardware security key)

Encryption

HTTPS/TLS

AskNicely's TLS setup gets an overall score of A in the Qualys SSL Labs Test - we support forward secrecy, allow secure renegotiation, disallow downgrade attacks, have good protocol/preferred cypher suite settings etc.

  • Every account and page is available via TLS/HTTPS
  • New accounts will receive immediate 307/301 redirect responses to the secure version of the page, when they try to access a page using HTTP
  • We do not yet set HSTS headers for every subdomain (but will soon)
    • In the meantime, we are more than happy to set an HSTS header for your subdomain if requested

Encryption In Transit

AskNicely supports full encryption in transit. No non-encrypted data leaves our datacenter, except to a client explicitly requesting the HTTP version of a page (which can be disabled). All our monitoring and backend systems either send local traffic over the VPC, or they use transport-level encryption when communicating with the rest of the internet

Encryption At Rest

AskNicely encrypts customer data at rest in RDS when hosted in Canada or Europe, but not on our default plans (hosted in the US or Australia). This is available for an extra charge, let your sales representative know if this is a feature you'd like to investigate.

Network Security

Firewalls

We use AWS EC2 Security Groups extensively, with fine-grained groups and rules. For example, each individual network protocol/service (e.g. MySQL or Elasticsearch) is placed in a separate security group, and only other groups that need access to that resource are given access. (i.e. we follow the principle of least privilege carefully when configuring network access). We also ensure that no services are directly available to access, from outside the network, on any host. Instead, we do one of a few possible things:

  • For public services, place the service behind a load balancer and web application firewall
  • For services that don't need to be public, restrict the service to a known set of IP addresses used by the AskNicely operations team
    • Only services with strong authentication (usually based on OAuth from some other provider, e.g. Github) are opened to the set of IP addresses in this way.

Network Flow Monitoring

We have VPC flow logs enabled for all VPCs, and GuardDuty is monitoring those logs to identify threats.

Backups and Business Continuity

Database Backups

For our primary database we use a high availability multi-master solution managed by RDS. In the event of a network outage or similar problem, RDS will automatically fail over to a secondary master for redundancy. We also store backups of the data itself, for use in disaster recovery scenarios, in a couple of different ways:

Point In Time Recovery via Automated Backups

We store 14 days worth of daily snapshots and transaction logs along with them, allowing us to do full point-in-time recovery to any second in the last fortnight. This type of backup protects us from accidental data loss caused by accidental deletion of bulk amounts of data. It can also be used to completely restore the database server.

Other Backups

Other backups (e.g. for user-provided images) are stored in AWS S3 with full redundancy and versioning enabled.