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.
As a very high-level summary:
You'll find more information on each of these points in the detailed chapters documents below.
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.
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.
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.
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.
Our main way of administering our servers is via tools that operate over SSH (such as Ansible). To keep such SSH connections secure:
AskNicely uses several third-party services for monitoring the performance of the application. These monitoring methods include:
AskNicely has an on-call engineer at all times.
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:
We fix any issues these rulesets reveal with a severity higher than informational.
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.
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.
Read more about what we have done to become GDPR compliant here.
If you have been surveyed by AskNicely or an AskNicely customer and want to access, update or delete your data with AskNicely, see how here.
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), 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.
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.
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.
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.
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:
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.
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.
Passwords are encrypted using industry standard methods. Only the resulting hash (not the password itself) is stored securely alongside your other data and checked against during login.
We offer the ability to enforce password requirements on end users of the AskNicely platform.
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.
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.
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)
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.
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.
AskNicely encrypts customer data at rest in RDS when hosted in Australia or Europe, and on all new plans hosted in the US.
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:
We have VPC flow logs enabled for all VPCs, and GuardDuty is monitoring those logs to identify threats.
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:
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 (e.g. for user-provided images) are stored in AWS S3 with full redundancy and versioning enabled.