Company
Keeping our bases covered.
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.
Employees
Humans are often the weakest links in the chain of security. These are the steps we take to accustom everyone to security practices.
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.
Infrastructure
How we make sure our technical infrastructure is secure.
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 processing
How we make sure our technical infrastructure is secure.
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.
Code
How we make sure our coding practices are secure.
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).
Application
How we make sure our applications are secure.
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:
NPM audit
Sonatype OSS Index
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.
Product users
How we enable our clients and end users to follow high security standards.
We enforce a password policy
Our user accounts require complex passwords: mixed case, special characters, minimum length, etc.
Data protection officers
Our company has appointed two data protection officers.
The data protection officer maintains our GDPR guidelines (in consultation with management) and is responsible for implementing the internal processes that involve personal information.
Appointee
Dennis Tel & Rienk Prinsen - [email protected]