Starred security documentation
This document is a comprehensive detailing of all of Starred’s security policy and practices. It covers: infrastructure security, configuration management, vulnerability scanning, monitoring, data security, data sovereignty, support access, web application security, user authentication, encryption, network security, backups, and provides a list of Starred’s data sub-processors.
While this doc should cover all your security-related questions, we’d be more than happy to provide more detail. Just reach out to Customer Happiness through in-app chat.
We use Amazon AWS, the leader in Cloud computing, and the longest running Cloud provider. As the longest running solution, they also have the most experience in the field when it comes to securing their locations.
Security at AWS facilities is described well in Amazon’s security whitepaper in the “Physical and Environmental Security” section. It includes 2x Two-Factor authentication, intrusion detection systems, and 24 hour surveillance by professional security staff.
On Amazon’s compliance page, you can find details on which certifications they hold, and laws they follow. They include:
- ISO 9001, 27001, 27017, 27018
- SOC 1, 2, 3
Your data are stored in Ireland in the EU, and furthermore Amazon is EU-U.S. Privacy Shield listed.
All changes to infrastructure are performed in the same way that changes to our software are performed, that is to say, we treat infrastructure as code. We do this using Ansible, Terraform, and Packer.
Since no manual work is necessary in order to bring up resources of a needed configuration, it is almost entirely (save for the databases) an automatic process, and our infrastructure will scale to meet the demands of our users.
For non-database servers, security patches to used software are installed automatically, as they become available. No manual intervention is required. When patches are needed for database servers, an alert is triggered, and a schedule is planned for its application based on the severity of the bug.
Infrastructure Resource Access
Access to infrastructure resources (such as servers, for example) is managed by AWS IAM roles, and configuration management.
Each IAM role is clearly defined, and only gives its members access to the resources they need to do their work, and only at the level they need. For example, a frontend developer only needs read access to the staging environment’s CDN S3 bucket, and not full read/write access. Our servers’ access to resources is similarly structured, with clearly defined IAM roles.
Access to any of our machines is secured with the following measures:
- Not possible directly via the internet. All machines have private addresses only, and are only accessible via a gateway
- Access to machines is monitored
- Access is only given to a small number of senior engineers
- Password logins are disabled
- Standard Linux user logins are disabled (root, ubuntu, etc.)
Outpost24 is a Swedish security company specialising in automated and manual penetration testing. They continuously scan our application for vulnerabilities with their Secure Web Application Tactics vulnerability management solution, and try to find weaknesses in the way we operate. If anything is found we are informed immediately and prioritise a fix, based on the given threat level.
Our infrastructure and services are monitored in a variety of ways, including:
- System and application metadata to a centralised logging service for analysis and alerting (Logz.io and NewRelic)
- Internally written tools, tailored to our systems
- AWS alerting of events such as instance scaling and spikes in traffic / changes in application performance
Here at Starred we handle personal data with the utmost care and security.. We process privacy-sensitive and personal data through our website www.starred.com and our feedback application. We do this on request of our clients, as well as for our own purposes.
We comply with the obligations as set out in the General Data Protection Regulation (GDPR). That means among others:
- we clearly state with what purpose we process personal data. We do that in this Privacy Statement;
- we limit the collection of personal data to the personal data needed for legitimate purposes;
- we will ask you for explicit consent to process your personal data when explicit consent is required. Given consent can be withdrawn at all times, but not retroactively;
- we take the appropriate level of security measures to protect your personal data and demand the same from parties processing personal data on our request;
- we respect your right to access, rectification and erasure of your personal data on your request.
We as Starred act as processor of the personal data that are processed via www.starred.com and as processor of the personal data that are collected on the request of our clients via the Starred feedback-application. In our Privacy Statement we set out which personal data we collect- and use with what purpose. Please take the time to read it carefully.
We receive and stored data solely within the EU, and almost entirely in one location; Ireland (AWS: eu-west-1). For the purposes of redundancy and disaster recovery, we also stored encrypted backups in Germany (AWS: eu-central-1).
As a client – as soon as you terminate an agreement with Starred, in any way or for any reason whatsoever, Starred will keep available all your personal data stored for up to thirty (30) days after the termination. This gives you the opportunity to access to your customer and response data via your account and download it if needed. After this thirty (30) day period, all your personal data will be erased, and we at Starred 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 absolutely necessary, or where you’ve requested assistance. We keep a log of every access to a customer’s account by our support representatives.
Web Application Security
Changes to the product are introduced solely by the Starred development team (we don’t allow third-party access to the codebase). The team uses continuous integration and delivery:
The flow for any given change to the application is as follows:
- A request for the change is made in the form of a ticket, the ticket is evaluated from many angles, including whether it adds to the user experience and security.
- A branch is made from our master branch, linked to the ticket.
- An engineer will work on the branch, test it, put it through Quality Assurance, and finally submit it for code review.
- Two other engineers will review the branch, and may ask for changes as many times as necessary.
- Once the branch is approved, it is merged back into the master branch, and our CI pipeline packages it up for deployment (as a Docker image).
- A engineer then logs in to our deployment tool and deploys the new version of the service.
None of these steps are skippable, or optional, since they are part of programmed policies. It should also be noted that our build tool will refuse to build deployable packages unless the code is signed by a trusted engineer, and all its functional tests have been passed.
Failing services are self-healing, determined by a health check. Similarly, if somehow after all the tests, a non-working service is deployed to production, the service will roll itself back to the last working version.
We offer Two-factor authentication (2FA), often referred to as two-step verification. It’s a security process in which the user provides two authentication factors to verify they are who they say they are.
We never transmit data externally in plaintext. We always opt for the strongest encryption. We disable weak ciphers and weak protocols. As a result, we have an “A” score with Qualys.
Encryption In Transit
Starred supports full encryption in transit. No non-encrypted data leaves our datacenter. 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
All data is encrypted at rest on our AWS EBS disks. Backups sent to our private S3 buckets are encrypted using 4,096 bit GPG keys.
Our networks are all segregated into their own VPCs. Currently we have 3 networks; management, staging, and production. There are peering links between management and the other two, for the purposes of management services having access to those environments, but not between staging and production.
We utilise EC2 Security Groups to control access between subnets, networks, and the internet. By default, no access between machines is given, ports are only opened between them when necessary.
The only machine in any of our networks that has a public IP address is the VPN, everything else has no direct connection. Even our web servers, which are accessed via HTTPS only via a loadbalancer. Our internal IPs are only accessible via SSH via a gateway, and the gateway is only accessible via the VPN.
Our VPN is protected with multifactor authentication. The first (the “possession factor”) is a revocable certificate, attached to a username. The second is (the “knowledge factor”) is a (very) strong password for that certificate. And the third (the “inherence factor”) is an OTP token, regenerated every minute by passing a biometric scan.
Backups and Business Continuity
List of data sub-processors
|Third Party Service/ Vendor||Purpose||Entity Country||Website|
|AWS Amazon||Data hosting||Ireland||https://aws.amazon.com/|
|Mailchimp||Email service provider||USA||https://mailchimp.com|
|Redis||Infrastructure Database provider||Ireland||https://redis.io/|
|RabbitMQ||Message Queueing Infrastructure||Ireland||https://www.rabbitmq.com/|
|New Relic||Digital Performance Monitoring and Management||USA||https://www.newrelic.com|
|Logz.io||AI-Powered ELK as a Service||Ireland||https://logz.io/|