Exply Security Concept

Our IT security concept describes how we at Sandstorm deal with the topics of IT security and data protection, which safeguards we implement and how we protect our own and our customers' data.

• Transparency: Our customers and partners can see how we handle data protection and data security.
• Internal consistency: This document is also the handbook for all team members at Sandstorm.

We welcome feedback of any kind on this document!

Protection goals

• Confidentiality: Data entrusted to us should never fall into the hands of unauthorized individuals.
• Availability: Our team members must be able to work with all data relevant to them.
• Integrity: Data must not be altered unnoticed - especially our hardware (laptops) must not have any viruses, backdoors, etc.

Threat Model

We want to protect against the following threats in particular:

• Non-team members visiting the office
• Devices (cell phone, laptop, Yubikey, backup hard drive) are lost, stolen or broken
• Viruses and backdoors on laptops
• Attempts to break into servers, e.g. via HTTP and/or SSH

Technical and organizational measures for IT security

1. Entrance Control

Company premises must always be locked and not accessible to the public.

• In Dresden, access is controlled by means of personalized key cards. Team members are instructed on how to proceed in the event of card loss (card is blocked). Building services staff in Dresden also have access to the premises (via personalized key cards).
• In Darmstadt, we work in CoWorking spaces; i.e., only the tenants of the CoWorking space have access to the premises.
• Work equipment (e.g. laptops, backup hard drives) is stored in locked cabinets in all locations when not in use.
• Personal data in printed form is kept in locked cabinets in all locations and is only taken out when in use.

We rent our servers from professional hosters whose data centers employ certified security concepts.

2. Access Control

One compromised system must not lead to access to all other systems.

• Sensitive data is stored only on company property (company laptops, backup hard drives, company USB sticks).
• We do not use iCloud backup for our Macs.
• All company devices are encrypted.
  • Mac OS X: Encryption via File Vault. Recovery key is stored in Recovery Vault in our password manager.
  • Backup hard drive: encryption via File Vault. The recovery key is stored in the Recovery Vault in our password manager in order to be able to read the data again in the event of a system crash.
  • Company cell phone: (security code, unlock pattern, ...)
  • USB sticks: use FileVault or Veracrypt
• Company laptops and PCs lock themselves automatically within a few minutes when not in use.
• When a team member leaves their laptop, they must lock the laptop. The password must be entered immediately after locking.
• Access to systems is only possible with personalized accounts.
• We use multi-factor authentication (MFA) for important domains:
  • There is one password to secure the services.
  • Additionally there is a One Time Password; either by cell phone (Google Authenticator) or by Yubikey (U2F).
  • There must be at least two devices involved in MFA (e.g. laptop, Yubikey). MFA functionalities of password managers (e.g. 1Password) must not be used.
  • The second factor (Yubikey) should always be carried on the key ring, in particular it must not remain permanently in/on the laptop.
  • The Yubikey must not be used as the only authentication factor; thus, it must not be used for laptop login.
• We use a password manager.
  • a new password must be assigned for each service, so that in the event of a leak from one service, the other services are not affected.
  • Certain passwords (especially to non-critical tools) can be shared with individual or all sandstormers.
  • Ideally, passwords are not shared. The more sensitive shared passwords are, the fewer Sandstormers will have access to them. For example, hardly any Sandstormers have access to the Recovery Vault.
  • The password for the Password Manager must not be stored in any place.
  • Passwords are stored and transmitted using a zero-knowledge server. Encryption and decryption is done locally. An admin user on this server is not able to access passwords.
  • A password manager admin is also not able to access passwords that are not shared by the creator.
• Password policy: Strong passwords are to be used as a matter of principle. Passwords are never used more than once.
• System updates are applied regularly.

2.1 Security Zones

There are different security zones, each of which must be protected with a different password:

• System user on the laptop
• Password Vaults of the user
• Mail/Slack credentials (may be stored in the personal password vault)
• Intranet login (may be stored in the personal password vault)

Security zone A - laptop system user

• This zone contains all the user's data on the laptop, stored in encrypted form.
• This is the basic protection for all our data.
• Once the user is logged in, this security zone is unlocked.

Security Zone B - Password Vault

• This zone contains the user's password vaults, stored separately in encrypted form.
• The Password Manager is set to lock the vault again after some time without password entry.
• This zone offers a bit more security than zone A, because the vault is only unlocked when a password is actually needed (and locks again automatically). Additionally, login is only possible with 2nd factor (usually Yubikey).
• All access to passwords is logged centrally.

Security Zone C - SSH Private Key

• Since the SSH key is stored on the Yubikey, it can be prevented that e.g. by viruses the private SSH key is read.
• If the Yubikey is lost or stolen, it must be ensured that the SSH key cannot be used by other persons.
• for this reason there is a PIN and a PUK - if the PIN is entered incorrectly 3 times + the PUK is entered incorrectly 3 times, the SSH key will be irretrievably destroyed. (Theft protection)
• The PIN is stored in the OSX keychain so that it does not have to be entered every time. Thus, an attacker would have to 1) steal the OSX keychain, 2) steal the Yubikey (in hardware). In our view, this is a workable middle ground that balances usability and security.
• The Yubikey is configured in such a way that every use of the private key must be confirmed with a keystroke on the Yubikey. This protects against viruses/backdoors - these could send an encryption command to the Yubikey, but the user would have to press the key separately.
• If the yubikey is lost/stolen, the corresponding public keys on the servers must be exchanged by a sandstormer whose yubikey allows access.

3. Access Control

• We use individualized logins wherever possible to assign targeted user privileges and enable audit logging:
  • System users on laptops - Personal login; no guest account or shared "superadmin" account.
  • Intranet users (HTTPS)
  • Server SSH logins with individual users and individual SSH keys for each user
  • Users in external systems (e.g. at customers and partners)
• To get root rights on our servers via SSH, first a personalized user login via SSH (key on Yubikey) is done, then root rights can be obtained with sudo and a system specific user password (password manager). Thus, it can be controlled which users are allowed to log in as root. It is also possible to track when an individual user has logged in as root.
• For particularly sensitive data, an additional Veracrypt container should be used.
• SSH keys are particularly sensitive for us, as we not only use them to gain access to our own server infrastructure, but also to exchange source code via Git and often gain access to our customers' systems.
  • We only use key-based authentication.
  • We want to prevent a backdoor from reading the private SSH key. For this reason, the personal SSH key is generated on the Yubikey and cannot leave this device (secure enclave). Yubikey in PIV mode supports 2048 bit RSA keys, which we use.
  • The usage of Yubikeys is described in detail below.
• The servers are equipped with a firewall; only the necessary ports are enabled.

4. Disclosure Control

Here we explain how we handle aspects of sharing personal data.

• No cloud services are used for personal data of customers.
• Slack is the only cloud application we use in our daily work. No passwords, access, or personal data of customers may be communicated via Slack. Personal data of our team members is communicated via Slack.
• All internal services (mail, intranet, ...) are only accessible via HTTPS and/or SSH. Mails from external third parties sometimes arrive via unencrypted SMTP connections if the sending server chooses this transmission.
• When we access customer systems, this is done exclusively by encrypted means (via SSH; sometimes also with VPN).
• The Mac OS firewall is used by all team members. This prevents uncontrolled communication of the outside world with the laptop.
• Team members can use a personal firewall to restrict outgoing connections; Little Snitch is used here.

5. Input Control

• We use Git to store personal data within the company. This allows detailed traceability of when who entered or changed what data.
• In systems that process customer-related data, we keep an audit log. Here, too, it is thus possible to see which data was entered / changed by whom and at what time. 

6. order control

If we are a client:

• the processing of data is contractually regulated
• we oblige the contractor to comply with the legal provisions, in particular the data protection regulations
• and also select only those service providers who meet these standards.

If we are a contractor:

• the processing of data is contractually regulated
• we commit ourselves to compliance with the legal provisions, in particular the data protection provisions
• we again train the team members entrusted with implementation separately on the processing of personal data.
• In case of an incident, the contact person on the client side will be contacted within 3 working days.

7. availability control

• For the working laptops of the team members a regular (at least weekly) backup to external encrypted hard disks is performed (see above).
• On the server side, we use RAID1 systems to mirror the hard drives to protect data from accidental destruction or loss.
• We rent our servers from professional hosters whose data centers use established paradigms to prevent hardware failures with associated data loss (e.g. UPSs, RAID, backups).
• Server-side backups are performed in one of the following ways:
  • A backup is made to the hoster's backup server. This backup is encrypted with symmetric key via GPG and is transferred only in encrypted form. The keys are kept separately.
  • A backup is made to cloud storage service providers in Europe. This backup is equally encrypted with symmetric key and is transmitted only in encrypted form. The keys are kept separately.

8. Ensuring Purpose Limitation

We take the following measures, among others, to ensure that data collected for different purposes are processed separately:

• Use of different (partly physical, partly virtualized) systems for the different data collection purposes.
• Compartmentalization of the different systems so that they can only access the data assigned to them (e.g., by using virtualization, separate service accounts in databases, file system rights). 

Specific Attack Scenarios

• Stolen cell phone: part of the second factor in authentication is omitted; Yubikey can be used instead.
  • Confidentiality: not violated
  • Availability: guaranteed (by Yubikey as other second factor)
  • Integrity: not relevant
• Laptop stolen / breaks down
  • Confidentiality: not violated with secure system password, because hard disk is completely encrypted
  • Availability: limited guaranteed. A new laptop must be set up and the data restored from the backup hard drive. This requires an authorized team member to read the backup FileVault key from the Founders Vault.
  • Integrity: not relevant
• Backup hard disk stolen / broken
  • Confidentiality: not violated, because hard disk is completely encrypted
  • Availability: guaranteed
  • Integrity: not relevant
• Yubikey stolen / breaks down
  • Confidentiality: not violated, as SSH key is protected by PIN + PUK, and brute force attacks are prevented.
  • Availability: not guaranteed. SSH accesses have to be set up completely new.
  • Integrity: not relevant
• Yubikey + laptop stolen
  • Confidentiality: not violated if system password is secure. With insecure system password VIOLATED - SSH key usable!
  • Availability: not guaranteed. (see above)
  • Integrity: not relevant
• Backdoor on laptop
  • Confidentiality: not guaranteed for data on laptop, guaranteed for SSH key (because it is physically in the Yubikey).
  • Availability: guaranteed
  • Integrity: not guaranteed (because backdoor)
• Intrusion attempts on servers via HTTP and SSH
  • SSH Keys are specifically secured
  • for logged in areas we use HTTPS, ideally in combination with U2F
  • logging/auditing happens via root cause analysis system
  • Confidentiality / Availability / Integrity: no concrete statement can be made; depends on the type of attack.