How we secure domain names

Domain certificates for aiden.cx are renewed frequently and automatically.

How we secure critical services

If managed by ourselves we make sure they are always up-to-date running the latest software and updates.

If managed by a third party we make sure appropriate SLAs are in place.

How we secure WiFi

Sharing WiFi networks with guests or neighbors may give them the opportunity to gather information on our network, and allow them to access resources protected by source IP. That's why we use an isolated and dedicated guest WiFi network. We have also set up a calendar reminder to change the password every two months, since this password is shared.

We require 2FA

Our employees use 2-factor authentication on all services they use (whenever possible). If their password is stolen, the attacker cannot use it without the second factor.

We encrypt all employee laptops

By encrypting all laptops, we protect both our company’s assets, and our employees’ private files.

We never use physical carriers for data transport

USB sticks and the like are an absolute no go. If we need to receive or send large batches of data, we do so through safe, password protected digital means.

We ensure the team locks their machines while away

Our office is secured, but we also receive external people for meetings. That's why employees always lock their machines when they leave their desk.

We use a password manager to ensure everyone only uses strong passwords

Using a complex and unique password for every website is great advice, but it can be very difficult to remember all of them. Password managers are a great way to manage these, since they will remember everything for you with a master password. This is why every Aiden employee is instructed to use either OnePassword or Lastpass.

We follow an onboarding / offboarding checklist

These checklists contain a list of all the steps we need to enforce when an employee or intern joins our company. A similar list is also used when the someone is leaving our team, to ensure that they no longer have access to any of our company’s resources.

We do not share accounts

Sharing a user account makes it hard to understand who is using the service or to identify who has performed a given action. That's why user accounts are never shared between Aiden team members.

We use centralized account management

We use Google Admin as a centralized place with all Aiden authorizations, so as not to forget anything once we need to update a user profile (e.g. if an internship or employment contract came to its end).

We take special care of our non-tech employees

Non-tech employees are less used to technical trickery and can be deceived more easily than others, opening the door to ransomware or confidentiality issues. They are trained and empowered to be distrustful and to preserve the company’s assets.

We use SSL certificates

We use https on all our services. Encrypting communications is not only about privacy, but also about our users’ safety, since it will prevent most attempts at tampering with what they receive.

We store passwords and secrets centrally, and update them regularly

All passwords and secrets we use internally or in client projects are stored separately in a specialised, centralized service per implementation. The secrets are updated and backed-up regularly.

We isolate assets at the network level

Only our public APIs are exposed to the Internet. We isolate our networks as much as possible (e.g. separating client projects on different clusters), to prevent any unauthorized accesses to a database.

We keep our OS up to date

All employees must download all of their OS’s security updates and regularly update their machines.

We backup, then backup again

We continuously backup all our critical assets. Client implementations are backed up every hour and stored for 24 hours, as well as backed up daily and stored for 1 month. We also attempt to restore our backups frequently, so we can guarantee that they're working as intended.

We centralize and archive our logs and make them meaningful

Logs are necessary to trace what happened after an incident, find where the attacker came from, and possible even who they are. We use Google Stackdriver logging for our Google-hosted projects, and Application Insights for Azure-hosted projects. We also make sure that the system time configured on each of our machines is in sync, so that we can easily cross-correlate logs.

We watch for unusual patterns in our metrics

We detect possible takeovers by watching for unusual patterns in metrics such as network bandwidth, CPU and memory consumption, and disk usage. If an attack (e.g. DDos) is suspected, we are notified automatically and will take all necessary measures to mitigate any damage, in consultation with our client.

We know how to redeploy infrastructure from scratch

This allows us to quickly spawn new infrastructure and populate it with data from our backups. This is the perfect use case for disaster recovery.

Data security

If the data contains any form of possibly personally identifiable information we encrypt the data at rest.

All data in transit is encrypted through HTTPS.

Data access

Only employees that have a legitimate need to access the data we collect will have (limited) access to it. Should the data be downloaded to the employees device for analysis purposes it will be removed after the task is complete.

We use a static security code analysis tool

Static code analysis tools can quickly overwhelm you with a lot of meaningless false-positives. But switching on security-focused tools can help us discover vulnerabilities inside our code and most importantly increase the security awareness inside our team. We are currently integrating these tools within our workflow to reduce friction.

We maintain a backlog of security concerns

Every developer contributes to maintaining a list of security issues to be fixed in the future. Making them available to the rest of the team increases the security awareness in the company.

We never do encryption (cryptography) ourselves

Cryptography is an expertise. We always rely on existing mechanisms, libraries and tools and follow the latest best practices, as evaluated on a quarterly basis.

We keep secrets away from code

We never commit secrets in code. They should be handled separately in order to prevent them accidentally being shared or exposed. This allows a clear separation between our environments (development, staging and production).

We follow the principle of least privilege

In case an attacker successfully attacks one of our applications, having it running as a user with restricted privileges will make it harder for the attacker to take over the host and/or to bounce to other services. All applications and users are assigned only the roles or permissions required to function and nothing more.

We monitor our dependencies

Applications are built using third party libraries. We use the following tools to monitor our dependencies against vulnerabilities in these:

We do not log personal information in application logs

Any personal or identifiable information is kept out of application logs. If an application requires the logging of such data for compliance purposes, this is handled in the compliance server.

We enforce a password policy

Our user accounts require complex passwords: mixed case, special characters, minimum length, etc.